This is an excellent question. Verichat is a good case study of the challenges of trying to keep a persistent TCP/IP connection through varying reception.
You must have connection-reestablishment logic.
A persistent TCP/IP connection can drop due to:
- IP address changes (I heard it may happen when you roam between carriers, like when you walk across the border of a country)
- Prolonged loss of reception
- Timeouts (TTL)
- Carrier disconnecting an inactive socket connection
- Radio-off/power-off
Pinging Is Usually Recommended
Use regular pinging to make sure it's alive. Null packets, for example. Idokorro uses null packets on a telnet connection. Verichat pings the Verichat server. Many carriers will terminate an inactive TCP/IP connection after 120 seconds. So the software often pings once every 30 seconds, or 45 seconds, or 60 seconds. So this is a good strategy.
Advantage: Connections are more likely to stay alive longer.
Disadvantage: Bandwidth usage caused by the ping packets. Can kill a connection more quickly during weak reception because a timeout error automatically means a disconnect, because the ping itself can trigger a timeout whenever pinging isn't necessary. (Some connections make pinging unnecessary).
However, if you've got a mechanism to reestablish connection and continue where you left off, then pinging is better than not pinging at all. And when your connection actually dies, re-establish automatically.
When you lose connection:
It's a fact of life. You will lose the TCP/IP connection eventually. You'll simply have to automatically reconnect.
How to Simulate Reception Loss:
Turn off the Radio. It's an excellent way to simulate sudden loss of reception. Make sure you test different lengths such as 5 seconds, 10 seconds, 30 seconds, 60 seconds, 2 minutes, 5 minutes, 15 minutes.
Other torture tests:
Walk around, drive around, or train/bus around in a low reception area, and let your software take the abuse. (Cycle the radio on/off can help too). You can also manually Switch Networks, for another torture test. And you can also poweroff your BlackBerry and then back on. You can poweroff your BlackBerry overnight with your software running, to make sure your software can recover gracefully from such a condition and automatically reconnect.
Recommended Ping Interval:
Interval of less than 2 minutes. Many systems have a 120 second timeout. Common intervals are 30 seconds, 45 seconds, 60 seconds, 90 seconds. (Some software uses 50 seconds, to workaround a 60 second server timeout)
How Long to Wait for a Ping Reply:
And wait for a long period for the ping reply -- even wait for at least 30 or 60 or more seconds, even 120 seconds, before you declare the connection is dead. That's because when you're in an ception area, it may be simply retrying, and your ping reply may take 120 seconds for certain packets instead of 1-2 seconds.
Data usage of pinging:
Ping logic running 24/7 in software can add approximately 100 kilobytes of data use per day per application, assuming you send about 1 ping per minute all day 24/7, and assuming the ping is counted as about 100 bytes when you include all the TCP/IP overhead.
How long can a socket survive on BlackBerry?:
Typically, expect "a few hours", and you must auto-reconnect about a few times per day. I've seen a socket survive on BlackBerry for more than 24 hours sometimes, when connected to an BES/MDS server with timeouts disabled. However, pinging can actually shorten the lifetime of a socket connection on such a link, while avoiding pinging is a problem with BES/MDS server that has timeouts enabled. Catch-22, eh?
Try to use just one persistent socket connection:
If you can have the power to do so, please do not use multiple socket connections when possible; try to multiplex everything over one socket connection. (Verichat uses four socket connections, one for each network, and gobbles more than double the bandwidth of WebMessenger, probably partially because of this) Verichat is vastly superior to WebMessenger, and there are good reasons to have 4 simultaneous connections, but if that can be avoided, then try to.
Note: BlackBerry email does not use keepalive methods -- It uses a different proprietary push method that's similiar to how an incoming SMS message "finds" you. Complex story behind the scenes with the blackberry.net "APN". For socket connections, you will have to simulate persistency using the above persistence methods, pinging, and auto-reconnects.
