1

I've been using cocoaasyncsocket as a client to a Windows .net server using asyncsocket. I am encoding messages using ProtocolBuffers. Together, these make a great set of tools.

However recently I have noticed that if I leave the client connected to the server for a long time - many hours - when I try to make a request for data, the message appears to get sent but never arrives at the server. I'm calling this a "silent" disconnection because I'm not receiving the usual disconnection that I would if there were a network problem.

I am handling the following methods in my effort to debug, but none of them get called:

- (NSTimeInterval)onSocket:(AsyncSocket *)sock
  shouldTimeoutReadWithTag:(long)tag
                   elapsed:(NSTimeInterval)elapsed
                 bytesDone:(CFIndex)length {

- (void)onSocket:(AsyncSocket *)sock willDisconnectWithError:(NSError *)err

- (void)onSocketDidDisconnect:(AsyncSocket *)sock

Without any notification, I'm finding this tricky to debug. The server similarly does not show any disconnections.

Would anyone be able to point me in a direction to how to further analyze this?

Many thanks.

hocker
  • 688
  • 6
  • 18

1 Answers1

3

If you want to know that your clients and servers are connected, you must have a heartbeat or "keepalive", i.e. an application level message which is exchanged basically saying "Are you there"/"yes".

This is particularly true nowadays as many routers will silently drop idle TCP connections. That's not what TCP was designed for, but it is a fact of life.

TCP has an option to send connection-layer heartbeat or keepalive with SO_KEEPALIVE, but historically there was an argument over whether this was appropriate. The designers felt that dropping a socket because of a temporary intermediate network problem was wrong. If no data was actually sent during that period, there was no reason to drop the connection. Others felt that knowing whether the connection was good was important in and of itself. What if you were expecting data but it hadn't arrived? Woudln't you want to know?

Ultimately it depends on the application. If "no new information" is an assertion of fact which is important to your application, (for example news feeds, sales orders, market data price changes) you need to check that the "no new information" is a real "no new information" not a "connection silently dropped". That means an explicit message.

So how often should you send it?

That depends on a balance of things. 1a) how often do you normally get updates? 1b) What latency is acceptable/normal (e.g. if this is part of a process, other steps take typically hours, then 5-10 minutes might be acceptable). 2a) battery and 2b) data usage due to heartbeat. I suspect the effect on battery/power will be crucial, but all these need to be looked at carefully, and balanced.

You could lose coverage at any time after all (tunnels etc). I would run the heartbeat only if you have had no updates after something between 0.5 and 5 times the average update interval. So if you expect 2 updates per minute, run heartbeats if idle for 15 seconds to 3 minutes - judge what is best. Provided the user is in the app "live" and "turns it off" when done, the battery life is not such an issue since they are using it anyway. Battery life is really an issue if you are waking the device to process the updates.

Ben
  • 34,935
  • 6
  • 74
  • 113
  • I was hoping that wouldn't be the answer. This is a mobile application and it just seems wasteful to send periodic 'ping' messages. Should I would implement SO_KEEPALIVE or build my own protocol? – hocker Mar 17 '11 at 12:57
  • If you have other information you could usefully exchange during a heartbeat, then go with an application-level one. Otherwise SO_KEEPALIVE is fine, BUT you will have to set the desired keepalive interval with SIO_KEEPALIVE_VALS, as the default is 2 hours which I suspect will be too long. – Ben Mar 17 '11 at 14:46
  • We implemented a very simple application-level one because asyncsockets makes it so easy. Now the question is timing. For an application that will be in use on a mobile device, what's a good interval to use? – hocker Mar 18 '11 at 13:01
  • That depends on a balance of things. 1a) how often do you normally get updates? 1b) What latency is acceptable/normal (e.g. if this is part of a process, other steps take typically hours, then 5-10 minutes might be acceptable). 2a) battery and 2b) data usage due to heartbeat. **I suspect the effect on battery/power will be crucial**, but all these need to be looked at carefully, and balanced. – Ben Mar 18 '11 at 17:25
  • It's a stock trading application so latency is quite important. The app doesn't have any other functions that run periodically, just this keepalive process. I guess the way I need to frame the question is, "what's the longest I can wait and know that I won't have been disconnected, before sending this keepalive?" – hocker Mar 18 '11 at 18:45
  • @hocker, there is no such period with a mobile app. You could lose coverage at any time after all (tunnels etc). I would run the heartbeat only if you have had no updates after something between 0.5 and 5 times the average update interval. So if you expect 2 updates per minute, run heartbeats if idle for 15 seconds to 3 minutes - judge what is best. Provided the user is in the app "live" and "turns it off" when done, the battery life is not such an issue since they are using it anyway. Battery life is really an issue if you are waking the device to process the updates (like an email app), . – Ben Mar 18 '11 at 20:28