Determining a Timeout on That Network Event of Yours? Take Your Time

By Ran Arad

Categories: Development

November 26th, 2008

Last week, Mrs. Code of Contact decided to upgrade our internet connection. She talked to the ISP representative, who informed her of a special deal: she is entitled to a server-side service, either an anti-virus or anti-spam for the mail service, or something called “Safe net”. “Safe net” scans sites for malicious scripts and prevents access to sites that may harm the user’s computer. Since Mrs. Contact knows we have anti-virus and anti-spam, she selected the “safe-net” service. To make a long story short, I cancelled it after a week. If it was just the slower access to any webpage, I might have kept it. However, too many services stopped working due to network delays. For instance:

• The antivirus software (AVG antivirus) refused to update its virus database. After trying to connect for about one second, it would declare that I do not have an internet connection. Sometimes it would corrupt its own databases in the process.
• My iGoogle homepage would start to load, and then the browser would claim that the server reset the connection. At first I thought it was some applet or another, but each applet worked fine separately, only when the whole page was loaded did it reset the connection.

This brings me to the issue of timeout in communication products.

How long should you wait?

Many standards define message timeout. ITU-T’s H.225 standard (part of H.323) recommends 3 to 5 seconds of RAS timeout, with 1 or 2 retries, depending on the message. RAS also implements the Request in Progress (RIP) mechanism to notify the sender that his request was received and will take longer to process. MEGACO also has a similar mechanism. When using TCP, the transport control should be the one notifying of failed communications or dropped connections. Why do implementers decide on low timeout values?

Most of the time, the argument used for lower timeouts is the theoretical user: the user cannot be expected to wait. They quote the 8-second rule, saying that if there’s nothing on the screen for 8 seconds, the user gives up. One wonders how people get through starting up their computer before giving up and going to watch TV (check it out: instant-on). Jokes aside, there is a limit to user patience. Shorter timeouts produce a ‘peppier’ response, feeding the user’s need for instant gratifications: Is it working? Did it fail? Should I reboot? Should I try something else? My antivirus’ update program was so anxious to give me results that it didn’t realize better results might arrive had it waited a few more seconds – and I really wouldn’t have minded.

What I’m saying is that even in today’s fast internet, client developers should set generous timeouts. You never know if security measures, billing systems or cellular networks may impose latencies on connections. The question should not be how long the user will have to wait. The user can decide that for himself by canceling the process. The question should be, what is the alternative. If, like my antivirus, all it can do after the timeout is report the failure, the client should wait longer, or even as long as the user allows it. My media player, for instance, notifies me that it is connecting and counts the seconds until giving up (the timeout is configurable). The user may be expecting to see something within 8 seconds, but it’s not necessarily the final result, sometimes a progress bar is enough.