On Mon, Apr 17, 2000 at 06:59:22PM +0200, Hirokazu Takahashi wrote:
> Hi.
>
> >> > I think sendig FIN is required when closing SYN_RECV connections
> >> > even if they are on a backlog-queue(sk->tp_pinfo.af_tcp.syn_wait_queue),
> >> > but Linux releases SYN_RECV connections without anything.
> >> > Or it would not be bad idea to send reset (RST) to the peer
> >> > than doing nothing.
> >>
> >> RST is not good when the SYN-RECV ACK has not been received yet -- you
> >> risk killing innocent connections because only after the three way handshake
> >> you're fully synchronized. FIN is not good neither. For Established sockets
> >> we already do the right thing.
> >>
> >> -Andi
>
> No risk there.
> It is easy to specify the peer to send RST/FIN and it doesn't matter
> that the peer is SYN-SENT or ESTABLISHED.
There are situations when you can get a SYN with the other end already gone
(e.g. consider a dynamic IP dialin address hat changes owners while there
is still an old SYN in the network). To catch that we have the 3 way handshake.
Only after it you can be sure that there is really someone at the other end.
Sending a RST earlier is evil.
> The information of the peer -- inetaddress,port,seq ... -- is contained
> in the open_request.
> If a SYN-SENT socket receives RST, status of the socket turns into CLOSE
> and make an ECONNREFUSED error.
> If a ESTABLISHED socket receives RST, status of the socket turns into CLOSE
> and make an ECONNRESET error.
>
> RFC916 says:
>
> RFC916> 5.2.3. SYN-RECEIVED
> RFC916>
> RFC916> Arrived at from the LISTEN and SYN-SENT states in response to
> RFC916> an arriving SYN packet.
> RFC916>
> RFC916> Departures
> RFC916>
> RFC916> - A CLOSE request is made by the user. Create a packet with
> RFC916> FIN set. Send it and go to the FIN-WAIT state.
BSD is the more relevant real-world reference here, and it does like
I describe.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
