Detect client EOF properly. Handle EWOULDBLOCK.

[mutability]

Client disconnection appears as a read of 0 bytes.
Without a test for this, dump1090 continues to poll that client forever.

Also, read() may return EWOULDBLOCK as well as EAGAIN
for "no data right now", so handle that.

I don't know if there is an equivalent Win32 bug here as the Win32
interfaces seem subtly different to vanilla POSIX.

The following test/break can probably be removed if Win32 needs
the same fix.

[MalcolmRobb]

Are you sure about including the "nread == 0" condition in at line 854? Surely that will cause dump1090 to modesFreeClient() the connection in the case where no data is read. This may not be an error condition - in the middle of the night it may be common for no data frames to have been received.

AFAIK WIN32 always returns a negative value for errors and disconnections. You then call WSAGetLastError() to get more information on the failure. 0 is a valid return for a stream IO since there may not currently be any more data to read, but there could be some more data aat a later time.

[mutability]

In the POSIX world a return value of 0 from read has exactly one meaning: the remote client closed the connection. This is how client EOF is reported.

If there are no bytes currently available and the socket is nonblocking, you will get a return value < 0 and errno = EAGAIN or EWOULDBLOCK

[MalcolmRobb]

Ok - I'll merge this pull.

[mutability]

For background, client EOF is not an error condition and in fact the socket may still be alive! The standard example of this is a HTTP client that sends a request without Content-Length and performs a half-close, shutting down just the send direction of the socket once it has finished writing the request body. The HTTP server discovers the end of the request body by looking for client EOF. The socket is still alive and in fact the full HTTP response can be written to it after client EOF.

I assume that Win32 has some way of telling you about this half-shutdown case too..