smartfoxserver.com

Version 1.7.1

The Client connected by BlueBox seems to never trigger the CONNECTION_LOST and thus my client stays alive.

I am currently making a simple bot programm to make a few clients (1000+) and let them connect and play on our server to test some issues. Some of them are connected normaly, others with BlueBox. When for some reason the connection dies, the BlueBox clients never seem to get the event for that, while the other clients just get the CONNECTION_LOST event and I can handle it however is needed for testing.

A way to reproduce this is:
- Start server
- Start a client with bluebox connection (e.g. set wrong port in config)
- Stop server

Am I doing something wrong there? The client first logs
"ERROR sfs2x.client.bitswarm.BitSwarmClient - ## BlueBox Error: Connection refused"
and then just keeps spamming
"WARN sfs2x.client.bitswarm.bbox.BBClient - BB sending error: can't send data, BlueBox connection is not active" on my pings
with no event fired after stopping the server.

Hi,
testing your scenario does indeed return a disconnection event, but it doesn't do it immediately if you use BlueBox.
The reason is that since the BlueBox is based on HTTP (thus not using a persistent connection) you don't have a realtime reaction to a connection lost, rather you will have to wait the underlying TCP stack to timeout and give an error back. Hence the longer delay.

Testing locally requires around 1 minute before the timeout activates, triggering the CONNECTION_LOST event.

Am I doing something wrong there? The client first logs
"ERROR sfs2x.client.bitswarm.BitSwarmClient - ## BlueBox Error: Connection refused"
and then just keeps spamming
"WARN sfs2x.client.bitswarm.bbox.BBClient - BB sending error: can't send data, BlueBox connection is not active" on my pings
with no event fired after stopping the server.

This looks like an entirely different issue.
The "Connection refused" error appears when your client is not able to reach the server. As regards the subsequent "spam" I suppose it has to do with how the client app works. If it continues to try and send messages when no connection exists, those errors will keep popping up.

Hope it help

Thank you for the reply!

Yeah sorry the error messages were just to demonstrate that there is no CONNECTION_LOST even after the sending fails. The Spam is my 5s ping and I just put it in here to show that this triggers several times without the event thrown. There is no issue with that. It was just to demonstrate.

Is there a way to reduce the timeout? 1 Minute is pretty long for out testcases. Else I would workaround with the pinging myself.

If it fails to connect you will get an immediate CONNECTION event with the "success" parameter set to false.
Thus you should not start pinging if such situation occurs.

As regards the case where the server goes down (as per your test)... that seems an unlikely situation, or rather one that should occur very rarely.
Regarding the timeout, it depends on the underlying TCP state so there's not much that can be done. Different devices and OSes will have different behaviors.

Well there are other cases where the connection fails after some time for some reason. I already catch the connection sucess = false, but I had a few BB errors during testing and I made the server stoping case to debug it. I just hoped I can just handle the events and be done with it.

I will add some code for blue box connections. Thank you for your help!