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'; http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/socket_options_for_windows_nt_and_windows_95_98_me_2.asp Here is a terrific grid; http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/socket_options.asp But here is something completely different, documented as 'unsupported'; http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/setsockopt_2.asp "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; "SO_RCVTIMEO and SO_SNDTIMEO" "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 >>>>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 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 thing. I concur - patch on it's way tomorrow. Bill
