I run in the following issue:
I connecte the client and a login box is displayed. My authentication time out is 20 seconds. If the user does not login in 20 second I do see the server closing the connection. When SFSClient is check _isConnected=NO and when the BitSwarn is checked it shows connected=YES. Is this how it is supposed to work?
In my app I have SmartFoxClient client object , when I do [client isConnected] I get TRUE when property _isConnected is FALSE. The method isConnected actually returns the BitSwarm connection status rather than the SFSClient's
BitSwarm protocol not detecting Server session disconnection
You can adjust the 20 seconds limit to any other value. Probably a 1-2 minute timeout will solve all the problems.
As regards passing data on disconnection.
This is not needed. The server disconnects the socket which in turn is acknowledged by the client which should reset the flags etc...
We'll take a look at the problem you have reported. If it's related with client wireless connections it might be normal.
If the connection blacks out for a while no TCP disconnection exchange is possible and both parties think they are connected.
This is a common issue and there's not much you can do about it besides waiting the TCP stack timeout.
Anyways we'll take a look and see if there's any problem with the API
As regards passing data on disconnection.
This is not needed. The server disconnects the socket which in turn is acknowledged by the client which should reset the flags etc...
We'll take a look at the problem you have reported. If it's related with client wireless connections it might be normal.
If the connection blacks out for a while no TCP disconnection exchange is possible and both parties think they are connected.
This is a common issue and there's not much you can do about it besides waiting the TCP stack timeout.
Anyways we'll take a look and see if there's any problem with the API
The increase on the interval is not much of a solution as if you keep the client at the login box for two minutes then you run in the same issue. I have found a temp work around for my self but it is not too good.
I connect my client and let it sit connected without login. On the server console I see the server closing the connection , but when I check the state of the client nothing indicates that it's socket was closed while connected.
What I'm talking here is server closing a socket on a perfectly good TCP connection and the client never knows about it. That is a issue I run into the first time I started working with NSStream and Java Socket (on the the serve r side) .
If you have Java to Java socket connection and you do socket.close() on one end of the connection , the other end knows it, provided underlaying TCP is intact. That is not the case with Java to NSStream , when you call socket.close() on the java side no event is fired on the NSStream side. A work around for this is to send connection Termination Byte that can cause NSStream client to take action.
My work around : When Java side closes the socket properly and the NSStream tries to write to it , a NSStreamEventHasBytesAvailable is fired and the read on that event will fail. This is where I figure the connection was dropped by the server side and kick in reconnection and login attempt.
I connect my client and let it sit connected without login. On the server console I see the server closing the connection , but when I check the state of the client nothing indicates that it's socket was closed while connected.
What I'm talking here is server closing a socket on a perfectly good TCP connection and the client never knows about it. That is a issue I run into the first time I started working with NSStream and Java Socket (on the the serve r side) .
If you have Java to Java socket connection and you do socket.close() on one end of the connection , the other end knows it, provided underlaying TCP is intact. That is not the case with Java to NSStream , when you call socket.close() on the java side no event is fired on the NSStream side. A work around for this is to send connection Termination Byte that can cause NSStream client to take action.
My work around : When Java side closes the socket properly and the NSStream tries to write to it , a NSStreamEventHasBytesAvailable is fired and the read on that event will fail. This is where I figure the connection was dropped by the server side and kick in reconnection and login attempt.
Code: Select all
I undersand the SmartReconnect mechanisms does not cover cable unplugged scenarios on the client side.
If you unplug a cable nothing can happen. You can only "pray" that some sort of low-level timeout is in place, but it's totally undeterministic.
Not in the near futureDo you have plans to allow a session to be moved on a different socket, very useful to reconnect iPhone / iPad . Those have the tendency to switch to 3G fro Wifi without apparent reason.