smartfoxserver.com

I am running the Tris example on android. It works well until I want to test the CONNECTION_LOST event handling. After logined the server, I disabled wifi from android setting, so the connection should be broken. I was expecting a CONNECTION_LOST event but nothing happened. I also tried this in TrisGame activity, still nothing happened, and the game stucked there.

I modified the code to listen SOCKET_ERROR event but still not work.

When I checked the log, I did find error log like this:
09-27 10:36:27.680: WARN/System.err(5386): 45426 [New I/O client worker #1-1] ERROR sfs2x.client.core.sockets.TCPSocketLayer - TCPSocketLayer: Socket error: Connection timed out
09-27 10:36:27.680: WARN/System.err(5386): 45426 [New I/O client worker #1-1] INFO sfs2x.client.core.EventDispatcher - Dispatching event OnError to 1 listeners
09-27 10:36:27.680: WARN/System.err(5386): 45426 [New I/O client worker #1-1] INFO sfs2x.client.core.EventDispatcher - Dispatching event ioError to 1 listeners
09-27 10:36:27.680: WARN/System.err(5386): 45427 [New I/O client worker #1-1] INFO sfs2x.client.core.EventDispatcher - Dispatching event OnDisconnect to 1 listeners

It seems the EventDispatcher did dispatch the socket error but I can't find out to catch it in code.

It seems a build configuration issue. I built the apk with libs downloads from android API package here http://www.smartfoxserver.com/download/sfs2x#p=updates . After I override the libs with the files in the example pack it works well.

I am still confused. Since the change log of android client API 1.0.1 says "[FIX] Problem with CONNECTION_LOST events being swallowed." but it seems not.

If the API version causing the issue is the one contained in the example package, this is normal because we don't recompile and update the packages each time a new version of the API is released. In fact in the tutorials we clearly recommend to get the latest API available.

Bax wrote:If the API version causing the issue is the one contained in the example package, this is normal because we don't recompile and update the packages each time a new version of the API is released. In fact in the tutorials we clearly recommend to get the latest API available.

I think both libs in example package and libs in released version API has problem.

1) If I use the libs in the example package:
GOOD: If I disable wifi after the client connected to the server, I would get a CONNECTION_LOST event. It means I will get an error if the connection is broken.
BAD: If I try to connect to a wrong IP (No such host) the client would be stucked. The UI shows the client kept trying to connect to the server.

2) If I use the libs in the released version:
GOOD: If I try to connect to a wrong IP (No such host), I would get a CONNECTION_LOST event since no route to host.
BAD: If I disable wifi after connected to the server. I got nothing. No event, no exception.

The Java API are going under some maintenance work in these days, so we will take your report into account. Thank you.

Hi,

I have a very related issue that i reported: viewtopic.php?f=18&t=15062#p63476

After upgrading the client api version to 1.0.1 and it seems firing only idle CONNECTION_LOST event. But when i shutdown the server, client won't fire anything. Here is the log on the client side:

3053 [New I/O client worker #1-1] ERROR sfs2x.client.core.sockets.TCPSocketLayer - TCPSocketLayer: Socket error: An existing connection was forcibly closed by the remote host
3053 [New I/O client worker #1-1] INFO sfs2x.client.core.EventDispatcher - Dispatching event OnError to 1 listeners
3053 [New I/O client worker #1-1] INFO sfs2x.client.core.EventDispatcher - Dispatching event ioError to 1 listeners
3053 [New I/O client worker #1-1] INFO sfs2x.client.core.EventDispatcher - Dispatching event OnDisconnect to 1 listeners

If we could listen OnDisconnect event. It would be cool, even better than CONNECTION_LOST event. But I haven't found a way to listen that event.

For now, I think write a heart beat thread is still the best way to resolve this. Since even the client can catch the disconnect event, the server can't notice the user disconnected.