Does anyone have any idea what could cause a 10035 error (EWOULDBLOCK) when reading on a blocking socket with a timeout? This is under Windows XP using the .NET framework version 3.5 socket library. I've never managed to get this myself, but one of my colleagues is getting it all the time. He's sending reasonably large amounts of data to a much slower device and then waiting for a response, which often gives a 10035 error. I'm wondering if there could be issues with TCP buffers filling up, but in that case I would expect the read to wait or timeount. The socket is definitely blocking, not non-blocking.
A:
http://www.lancerobinson.net/archive/2005/07/20/WinsockError10035.aspx
This error happens when the winsock buffer of either the client or server side become full.
David Johnstone
2009-06-18 03:58:32
Thanks David - I had seen that, but I'm not totally convinced it's causing my issues. I've tried swamping the buffers by sending huge amounts of data between two Windows machines, and all that happens is the send blocks or times out, never gives a 10035 error. Also, the error is happening on a TCP read of what should be quite a small amount of data. I think it's time to unleash Wireshark.
2009-06-18 21:42:18
A:
What seems to be happening is that the error occurs when retrying after a timeout on a read. After the timeout (10060) I re-send data and wait for a reply. The timeout seems to set the socket to non-blocking mode, even though the debugger shows Blocking set to true on the .Net socket object, and I immediately get the 10035 error. If I explicitly set Blocking to true on the socket before retrying the 10035 error goes away. This looks like a bug, or possibly a feature, in Winsock or .Net.