.NET 2.0: WSEWOULDBLOCK socket error when sending data using synchronous sockets ?

[Navin Mishra]

Hi,

In load test of our .NET 2.0 socket application on Win2003 server, we are
seeing sometimes
WSEWOULDBLOCK error when sending data to clients. We are using synchronoous
scokets with SendTimout of 2 secs. Is it normal ?

Thanks in advance and regards

Navin

 

[Arkady Frenkel]

WSEWOULDBLOCK really isn't error but warning only
Arkady

 

[Ben Voigt]

WSEWOULDBLOCK really isn't error but warning only

For a synchronous socket, it's an error. It means that the kernel refused
to buffer the data, the request was denied. The application can perform its
own buffering and hide the problem, but that's probably not a good idea,
because kernel buffer reaching capacity usually indicates poor network
connectivity, and the app could just end up allocating all available memory
for additional buffers.

 

[Arkady Frenkel]

As I see , the socket used as async, because TO of 2 sec is much less than
default for the case ( 21 sec = 3+6+12)
Arkady

 

[Navin Mishra]

That's interesting. Doesn't SendTimeout property apply to synchronous
sockets only ? And how 21 sec = 3+6+12 was calculated ?

Thanks!

 

[Arkady Frenkel]

Hi!

That's interesting. Doesn't SendTimeout property apply to synchronous
sockets only ?

Yes, but that's the point , operation failed on the first time ( or during
first time ) , because of short TO maybe treated as async ( instead of TO
return code you receive WSEWOULDBLOCK ). But that is my proposition only

And how 21 sec = 3+6+12 was calculated ?

There is two registry keys used :
TcpInitialRtt ( 3s by default ) and really that much more because
TcpMaxConnectRetransmissions is 2 ( forW2K/ XP/Vista machines, before was 3,
so connection time is equal to 21 sec for W2K/XP/Vista and 45 for NT),
TcpMaxDataRetransmissions equal to 5 , so real value for send is
3+6+12+24+48+96 = 3min15 sec

Arkady