Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <009301c3039f$e1aef990$7999883e@pomello>
From: "Max Bowsher" <maxb AT ukf DOT net>
To: "Brian White" <bcwhite AT precidia DOT com>
Cc: <cygwin AT cygwin DOT com>
References: <3E9C374E DOT 4256358D AT precidia DOT com> <004001c30372$9b95d9b0$235e893e AT pomello> <3E9C42AF DOT F8A6AEA1 AT precidia DOT com> <008701c30386$64cc56c0$5c51893e AT pomello> <3E9C73FB DOT F74E775A AT precidia DOT com>
Subject: Re: tcp RST instead of FIN if child exits after parent closes path
Date: Tue, 15 Apr 2003 23:39:29 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Brian White wrote:
>>>> 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?

I believe it is not which process does the final close that matters. Rather,
I think that it is write-then-immediately-close that causes the RST. (At
least with some socket options).

For detail, see MSDN. Look up the closesocket() function, and read that
page, and also "Graceful Shutdown, Linger Options, and Socket Closure"
linked to from that page.

Max.


--
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/