Differences Between Windows and Unix Non-Blocking Sockets

While working on Twisted's networking, I discovered a series of differences between socket APIs on Windows and Unix/Linux. This article is intended to document them for the benefit of those who are developing their own networking code.

While working on Twisted's networking, I discovered a series of differences between socket APIs on Windows and Unix/Linux. This article is intended to document them for the benefit of those who are developing their own networking code.

The permanent home of this article will be on my homepage, where I will add anything new I discover or I receive from other people. Please add comments to the article if you know of any other differences.

Some caveats:

• This document only discusses non-blocking sockets.
• I am not an expert on either Unix or Windows or networking. On the other hand Twisted has an extensive set of tests and runs numerous real programs on both platforms.
• These results were based on Python's behavior, as is my terminology. Since Python wraps the C APIs in a very light weight way, and I haven't found major contradictions between its behavior and MSDN and Unix documentation, this information is probably valid for C networking as well.

My main sources of information were the relevant MSDN pages, Volume 1 of Unix Network Programming (2nd Edition), and experimentation and results from running systems. I recommend all three for verifying this information.

Without further ado, here are the differences (I may have forgotten some):

WSA errnos

Socket APIs will return WSA errnos, rather than the standard ones (e.g. WSAEWOULDBLOCK, although Windows also has EWOULDBLOCK). Except when they don't. Refer to MSDN.

select(2) doesn't block on empty lists of fds

If you don't pass any socket fds to select(2) on Unix, it will block for the specified timeout. On Windows, it will return immediately with an error. This may be a Python oddity.

Peculiar errnos from select(2)

I've seen errnos 0 and 2 returned on Win32 for no reason I understood, apparently when passing empty read or write list.

Detecting failed connects is done using exception list of select(2)

On Unix, a failed connect will return an error upon reading or writing from the socket, and select() will mark the socket as notified. The exception list in select(2) is used for detecting OOB data. On Windows, not the read or write lists but rather the exception list is used for detecting failed connects.

Failed connects, reads and writes still return WSAEWOULDBLOCK

Reads or writes to the socket will return a WSAEWOULDBLOCK even if connection failed. The errno is available via getsockopt with SO_ERROR.

WSAEINVAL is equivalent to WSAEWOULDBLOCK for connect(2)

You need to treat both as equivalent on Windows.

SO_REUSEADDR is weird

On Windows it lets you bind to the same TCP port multiple times without errors.

UDP blocking on recvfrom returns WSAECONNRESET for connection refused

On Unix you get ECONNREFUSED.