tcp RST instead of FIN if child exits after parent closes path

Brian White bcwhite@precidia.com
Wed Apr 16 01:02:00 GMT 2003


> >> This is a bug/feature of Windows Sockets. I think it would be possible to
> >> craft a workaround in Cygwin, but it would require some non-trivial IPC.
> >> (IIUC, you would need to maintain a cross-process refcount for the
> socket).
> >
> > Hmmm...  From my work with Amanda, the child process can continue to
> > send data via the socket even after the parent has closed it's handle
> > on that path, so there must be some sort of reference counting already.
> 
> Yes, but the wrong sort.
> 
> To guarantee avoiding the RST, you need to shutdown(SHUT_WR) the socket. And
> that does stop all processes from writing to the socket. So, you would need
> to refcount the socket, and issue a shutdown just before the last close. (I
> think.)

I don't follow.  The path is still open and able to send the data from the
child even though the parent has closed it.  It's only when the child exits
(note: the child just exited; it didn't do an explicit "close") that the
connection was killed, so there the system already knows when the last close
occurs.  What is being done to the socket that is different depending upon
whether the final close comes from the process that originally opened it or
another one?


> For a quick hack, you could try sleeping for a second before exiting. Should
> work most of the time.

For Amanda, I fixed it by moving the close within the main application until
after all the messages from the child had been parsed and the child had
exited.

                                          Brian
                                 ( bcwhite@precidia.com )

-------------------------------------------------------------------------------
"Everything that can be invented already has been."  --U.S. Patent Office, 1899

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list