forums.smartfoxserver.com

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

After further investigation I don't see any data passed to the client when the server removes the session. There should be a termination byte sent in so that the iPhone client knows to close it's socket too.

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

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 undersand the SmartReconnect mechanisms does not cover cable unplugged scenarios on the client side. Do 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.

Yep because it's impossible
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.

Do 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.

Not in the near future

Actually on the Mac you get IOStream error even with idle connection. So that can be handled and the sessions reestablished on a new socket. I have done work on a successful socket jumper we called it. If you are interested I can help with that in SmartFoxServer.