apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Win32 apr_sockets; Random notes from the 'oh, duh' department
Date Thu, 24 Apr 2003 02:20:40 GMT
At 08:11 PM 4/23/2003, Bill Stoddard wrote:

>>>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?

Well now my brain is twisted...

Here, it's documented as 'supported';


Here is a terrific grid;


But here is something completely different, documented as 'unsupported';


  "BSD options not supported for setsockopt are shown in the following table. "

Now what does that mean?  Supported on win32, unsupported on BSD?
Or options from BSD not supported on Win32?

Even worse;

    "When using the <http://msdn.microsoft.com/library/en-us/winsock/winsock/recv_2.asp>recv
function, if no data arrives during the period specified in SO_RCVTIMEO, 
    the recv function completes. In Windows versions prior to Windows 2000, any data received

    subsequently fails with WSAETIMEDOUT. In Windows 2000 and later, if no data arrives within

    the period specified in SO_RCVTIMEO the recv function returns WSAETIMEDOUT, and if data

    is received, recv returns SUCCESS."

    "If a send or receive operation times out on a socket, the socket state is indeterminate,

    and should not be used; TCP sockets in this state have a potential for data loss, since

    the operation could be canceled at the same moment the operation was to be completed."

Take your pick.  What scares the bejezus out of me is that if the
docs contradict, what will your average TCP/IP Filter author do?

>>>>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
>>>>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 must be up to APR - we can't expect application authors to make low-level
decisions when all of the low-level implementations differ ;-)

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

I concur - patch on it's way tomorrow.


View raw message