Mail Archives: cygwin-developers/2002/07/29/13:56:58
Conrad Scott wrote:
>
> *) On win98 (and possibly other non-NT systems) sockets don't seem
> to be released properly so with a long-running server you get
> WSAENOBUFS errors (sooner or later) and no clients can attach
> until the server is restarted. This is what I'm trying to
> understand right now (w/ no success as yet) --- an "equivalent"
> server using winsock2 directly doesn't suffer from this problem.
>
> *) There are a couple of reported bugs I've come across in the
> MSDN archives that need to be worked around but aren't currently
> (AFAICT). For example, see "BUG: Closesocket() on a Duplicated
> Socket Fails to Clean Up"
> (http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q198663&)
> and "INFO: WSA_FLAG_OVERLAPPED Is Needed for Non-Blocking Sockets"
> (http://support.microsoft.com/default.aspx?scid=kb;[LN];Q179942).
Those two are the same, AFAIK.
The problem occurs when the primary socket is closed before the
duplicated socket (in another process). Does your "equivalent"
server do that?
A typical MS server only duplicates sockets as needed.
Often it is thus enough to close a primary socket after
the corresponding child terminates.
Cygwin has an extra problem because it duplicates all sockets
on every fork. This leads to the more complicated bookkeeping
proposed by Corinna.
Note that Q198663 says:
"The workaround would require the child application to create a dummy
TCP socket (just call socket (AF_INET,,,,)) and close it at its own leisure.
The other possibility is to close the socket that is being duplicated in the
parent process only after child is done with it."
The solution I implemented in some test code (and which runs fine,
but uses a non-unix "close on fork" fcntl) is the second one,
i.e. "The other possibility...".
I have scratched my head about the "dummy tcp socket" and tried
various things, without success. Have you experimented with that?
> One idea I've had is to extend the semphore work I put into the
> UNIX domain socket patch to allow the DLL to detect the last close
> of a socket if it's been duplicated by whatever means. This would
> allow the DLL to close the socket "properly" (e.g. non-blocking +
> shutdown(2) + linger as appropriate).
I am not sure this does it (perhaps I don't understand what you mean).
As I recall, calling shutdown makes the socket to not appear
CLOSE_WAIT in netstat -a, but you still get the WSAENOBUFS after
a while. Again, the key is to delay closing the primary socket.
>
> Comments warmly welcomed, particularly if they are of the form:
> "here's a way to get around all these problems w/o having to do
> any work" :-)
Sorry!
Pierre
- Raw text -