SO_SNDTIMEO and SO_RCVTIMEO

nospam@example.com (Daniel Fischer) — Tue, 24 Mar 2009 13:30:29 +0100

Implementations of the BSD socket interface support various socket options. Two of them are SO_SNDTIMEO and SO_RCVTIMEO. They allow the user to specify a timeout for otherwise blocking send() and recv() calls. They're often described as the two socket options that have the most different implementations and are therefore among the most unportable ones at all.

It's not quite as bad, but among the major UNIX and Unix-like operating systems, there are at least three different beaviours for stream sockets, ignoring that the behaviour for datagram sockets may yet be different.

Most of the operating systems I tested this on actually support these timeouts. Mac OS X, Linux, FreeBSD and AIX were all among the platforms where I was able to use these timeouts in a simple test, using reasonably recent versions of these operating systems. This means that the OSes accepted setting the option and the timeout that was configured did actually work. The BSD socket implementation that is used in Microsoft Windows also falls into this category, the timeouts work reliably there.

One notable exception was Solaris, which reported that the protocol did not support this option. This means that the setsockopt() call failed. Since this is detectable, it's not a problem; there are other ways to implement timeouts without support from the socket layer.

The other notable exception was HP-UX (tested with 11iv3 and 11iv1). On HP-UX, you can get the same behaviour as on Solaris if you use the UNIX03 socket library, meaning setsockopt() fails with ENOPROTOOPT. However, if you're using the BSD socket library that is also provided with HP-UX, then you are allowed to set the timeouts, but they are silently ignored.

Even worse, the system will remember the timout you set, and querying it with getsockopt() will return it. This means you can't verify that the timeout is available by querying it after setting it and comparing it to the value you set it to. Setting it is allowed and querying it will yield the timeout that was previously set, but the timeout setting will be silently ignored by HP-UX.

In summary, you can actually expect these timeouts to either work or cause an error when you try to set them on most UNIX and Unix-like operating systems, and also on Windows, but if you are really concerned about portability, you need a backup plan, and either a whitelist of platforms where the backup plan is not necessary, or a very short blacklist that mostly consists of HP-UX.

Portability Blog (Entries tagged as bsd)

SO_SNDTIMEO and SO_RCVTIMEO