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 Win32 apr_sockets; Random notes from the 'oh, duh' department
Date Wed, 23 Apr 2003 20:03:42 GMT
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


Mime
View raw message