httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jlwpc1" <>
Subject Re: Is it possible to "unbind" a socket?
Date Sat, 13 May 2000 18:15:06 GMT

> >> Specifically a Winsock2 socket?
> >> Now my question...
> >> I'd like to recycle the socket explicitly with system calls rather than relying
> >> TransmitFile to do it for me.  I can use shutdown on the socket,  but how can
> "unbind"
> >> it?
> > Shutdown(socket, how) and then closesocket(socket)?
> shutdown(socket,how) works fine. I don't want to close the socket. I want to put the
> socket back into the same state as a socket created with the socket() call. 

Shutdown() does not release the socket's hold on the socket's internal info list. Only  closesocket()
releases all the sockets "hold" on internal info. So it is shutdown() -> (is everything
ready - if so) -> closesocket() (release all internal info) -> (start over) -> socket()
(store internal info). I believe once you call shutdown(), you start the loop but if data
is queued or sent during shutdown() you fall out of this loop and the connection is reset.

> has  magic to do this. It has a couple of flags that cause the socket to be disconnected
> then unbound, but -not- closed.

Are you sure TransmitFile() does not close and re use?  Maybe it's fast and/or sends a get
out of shutdown() data back :) ??? TransmitFile() is all a kernal mode action and I fully
"understand" your magic idea.  WSASend() involves user mode to kernal mode actions.

>You can then pass this exact same socket back to AcceptEx
> and it works.  

That is why MS wants you to use their extras (see below). Most of the time they make them
to work with other MS stuff.  

>I would like to be able to replicate this function in cases where
> TransmitFile is not used.

Have you tried these socket options (SO_CONNECT_TIME - used for AcceptEx seconds connect time
count, SO_REUSEADDR - useful with ports in TIME_WAIT state, SO_UPDATE_ACCEPT_CONTEXT - used
by  AcceptEx taking the listening socket and the socket handle that becomes the accept client,

But it would supposely be slower without using the MS magic - I assume that is why MS added
these functions and other Winsock venders may have or may have not. 

AcceptEx and TransmitFile (NT sp4(?) and up) are _only_ MS extension functions that will be
there if and only if you are using the mswsock.lib and thru the MS SPI (Service Provider Interface).
 There are other vender versions (SPI) of Winsock out there. Some Winsock functions are completely
in ws2_32.dll and/or call WIN32 system calls.  Others are in a lower layer (SPI).  


gethostname, htonl,WSAGetLastError, etc. are in ws2_32.dll.

WSAEventXXX, etc. are sent to WIN32 system calls.

WSAAccept is really SPI WSPAccept
closesocket                SPI WSPCloseSocket

Now applications "must use the Winsock 2 APIs" and are not SPI clients.  

App -> ws2_32.dll -> SPI -> TSP/NSP

Info on SPI (layers) used to be in PSDK under winsock2/ and use ws2spi.h.

Now SPIs are suppose to write functions the same way but you know how true that would be.
 I might write one and you might write one and we still call all the functions but they would
not _always_ do the same thing in the same way. So do you really want to look at SPIs?  

Anyway AcceptEx and TransmitFile call a special SPI function in mswsock.lib called WSPIoctl().
  Which has the socket, buffers, overlap info, completion routine, threadID, error and an
IoControlCode. They use a GUID (globally unique ID). But what really happens - I'll leave
to you (in other words - I don't know - I only know what I read and sometimes that is even
wrong <g>).  You can trace winsock API and SPI calls made from the ws2_32.dll.  You
need the winsock checked build and dt_dll samples. Supposely you can trace just the call you
want. Good luck.

> I bet there is a undocumented MS call to do this and I've tried to find it w/o success.

Undocumented? MS says there is no such thing :)  - let us know when you find it! 


View raw message