Folks, we have a number of real issues with the win32 implementation of sockets which I think I can fix over the next day or so, but I'm just dropping off this note early enough for folks to bitch^H^H^H^H^H comment.
Serious Problem #1: Blocking Socket, apr_sendv() invokes WSASend() with NULL completion arguments... according to WinSock2 this should be a sync, blocking send. Put a huge (4MB), mmap'ed region into that iovec, and it will be sent - BUT IT IS SENT ASYNC! So later we close the socket and the transmission is aborted. Solution? Apparently we just can't trust sync send/recv, and I guess it is time to simply surrender and make them all async with a completion event, irrespective of timeouts. Then wait on that event INFINITE or by the so_timeout value. Question; do we simply use the socket itself as the event handle? Or do we create one event for each socket that we can later use for all sorts of goodness such as a WSAAsyncSelect()-style poll? Two threads won't be looking at the same socket, so I think an event handle in each apr_socket_t would be useful. Serious Problem #2: Win32 doesn't support socket timeouts. We are using raw WSASend/WSARecv, blocking. This just isn't good. Solution? Same as for #1 above. 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. Those are just the random observations of the day. If you have a Win32 sockets patch - now would be the time to toss it back up for consideration since I'm already up to my neck in WinSock2. Bill
