Hi!
Post by Navin MishraThat'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
Post by Navin MishraThanks!
Post by Arkady FrenkelAs 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
Post by Ben VoigtPost by Arkady FrenkelWSEWOULDBLOCK 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.
Post by Arkady FrenkelArkady
Post by Navin MishraHi,
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