apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <b...@wstoddard.com>
Subject Re: Win32 apr_sockets; Random notes from the 'oh, duh' department
Date Thu, 24 Apr 2003 01:11:42 GMT
>>This is horribly inefficient on Windows where sys call overhead is high.  
>>Windows uses the builtin setsockopt(SO_RCVTIMEOUT) timeout 
>>mechanisms (which are part of the BSD socket spec but is not 
>>implemented on Unix).  If, as you are reporting, WSA* calls are not 
>>really working as they should, then we should probably just do them 
>>async and wait for the io completion.
> Ok... according to every document on WinSock2 I've read, it appears that
> SO_RCVTIMEOUT isn't supported on Win32.  I could be misreading, or
> just out of my mind, but it appears clearly documented - as unsupported.

I am floored... got any pointers to the doc?

>>> Solution?  Same as for #1 above.
> Of course if we solve the problems above, this one comes free even if
> SO_RCVTIMEOUT isn't implemented.


>>> Serious Problem #3: Using WaitForSingleObject() with our 'socket'
>>>timeout value is rather bogus - it would measure the total elapsed time,
>>>not the interval between packet transmissions.
>>> Solution?  Well, if WinSock2 had some sort of 'progress' indication, bytes
>>>sent or received so far for a completion-based request - then we could just
>>>sample and assure ourselves that something had happened.  As it is we
>>>just can't do that.  Effectively, it looks like any huge send over a slow wire
>>>will be timed out based on any sane setting for a timeout value.
>>That should not be the case. Last time I checked, I though we set the timeout 
>>then sent 64K (?) chunks then reset the timeout for the next 64k chunk. 
>>This is -eaxactly- what 1.3 does on Unix (where signals are used as the 
>>timeout mechanism). This has someone changed that w/o my noticing? 
>>I'll check later...
> No, especially not in the case of mmaps.  The way filters, brigades and
> buckets work, you can end up with a 16MB sendfile or 4MB mmap.  In
> the later case, you may have 4MB * 16 iovecs in a single WSASend.

Yaaaarrrggggg.... right you are!  The assumption all along was the the 
application (httpd in the case) would not send down huge buffers to 
send. I did not realize that mmaps broke this assumption. Ouch...

It should not be too difficult to make the mods to make WSASend and 
WSARecv do the async thing.


View raw message