views:

26

answers:

2

We have an app with a long polling scheme over HTTP (although this question could apply to any TCP-based protocol). Our timeout is fairly high, 30 minutes or so.

What we see sometimes is mobile devices hop from IP to IP fairly often, every minute or so, and this causes dozens of long-lived sockets to pile up on the server. Can't help but think this is causing more load than neccessary.

So I am guessing that some IP gateways are better than others at closing connections when a device hops off. The strategies I can think of to deal with this are:

  • Decrease the timeout (increasing battery life on the device)
  • Close the last active connection when a user reconnects (requires cookie or user ID tracking)

Any others?

A: 

If you can, turn on TCP keepalive on the sockets, and give them a fairly low timer (e.g. every 1-5 minute). As long as you're reading from the socket, you'll detect an unreachable peer faster - and with less resources utiilization on the phone than decreasing your 30 minute application timeout.

nos
Won't the keepalive reduce battery consumption on the device just as if we sent data over the socket?
sehugg
Yes, but not as much as handling it in the application.
nos
A: 

I would look into closing the last active connection using a cookie or some sort of ID in you're server. Yes it's more work, but as soon as the user hops addresses, you can find the old socket and clean up the resources right of way. It should be fairly easy to tie to a username or something like that.

The other problem you may run into even if the user equipment isn't hopping addresses, some mobile networks and maybe you're own network may have a statefull firewall that will clean up unused sockets, which will cause connectivity problems since a new connection will require the syn/syn-ack again. Just something to keep in mind if you're noticing connectivity problems.

If you do decide to play with keep alives, please don't be too aggressive, chatty applications are the plague of Mobile networks, and ones that hammer the network when it lose connection to the server can cause all sorts of problems for the network (and you if the carrier catches on). Atleast have a sort of backoff mechanism to retrying connectivity, and maybe even try to find out why the device is switching IP addresses every minute. If it's functioning properly that shouldn't occur.

***I work for a mobile operator in Canada, however, my comments do not reflect the position of my employer.

Kevin Nisbet
I am kind of worried about keepalives since any data activity wakes the radio -- that's why I have it set to 30 mins. Not sure what do to about firewall timeouts either, won't notice it on the server as easily :(
sehugg
@sehugg On the network you are on, does the device get a public IP address? If so, one method I've seen with success is when the device get's an IP address, it registers with the server, and then just listens for incomming connections, and the server connects out to the device when someone has something for it. However, carriers aren't very supportive of this and may lock it down. The other way is to send the device an SMS, and have you're device intercept the SMS to wake up the application to do something.
Kevin Nisbet
@Kevin I haven't had luck with connecting to the device - tried this once with UDP. Now I understand the value of services like Apple's APNS and Google's C2DM :)
sehugg
@sehugg Those are definitely valuable, but I've never looked at them to see how they work, so they may suffer from some similar problems. The only one I know how it works and is absolutely reliable is the Rim Relay network, where they get a private connection into the wireless carriers network, and can send data to the device with no firewalls and no interference. The Apple / Google systems may use very similar long poll which I don't think is ideal, but I've never gone and taken a capture off any of these devices to see.
Kevin Nisbet