lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] RE: [lwip-users] Why the tcp_pcb haven't been free when


From: Kieran Mansley
Subject: Re: [lwip-devel] RE: [lwip-users] Why the tcp_pcb haven't been free when Icalltcp_close()
Date: Fri, 16 Mar 2007 08:46:49 +0000

On Fri, 2007-03-16 at 08:17 +0100, Goldschmidt Simon wrote:

> Does anyone know the answer (or why I saw it like this on the 2 OSes)?

It's all to do with possible retransmissions due to lost FINs or ACKs
(or even I suppose very delayed duplicate packets from the middle of the
stream) after the connection is closed.  The TIME_WAIT state is designed
as a safety mechanism to ensure that all possible packets for this
connection will have left the network (hence the 2 max segment lifetime
timeout value - the max time for a packet to go from client to server
and back again).  If one of the last FINs or ACKs of the last FIN were
lost or duplicated, it is likely that there would be a retransmission.
If we had gone straight to CLOSED, we could (by the time the
retransmission were received) have reused that port, and so then receive
a packet from the old connection in the middle of the new connection.

The reason it's not needed on the "server" side (the side that sends a
FIN second) is nothing special, it's just that you don't need it on both
ends of the connection, and I think the designers decided that it was
better to have connections in TIME_WAIT at the client (which typically
has fewer connections) than the server.  The reason you don't need it on
both ends is that a old packet could only be interpreted as part of a
new connection if both the source and destination IP addresses and ports
match, so as long as one end prevents re-use of its address and port
pair, everything will be OK.

Hope that helps.  I can recommend Steven's books (TCP/IP Illustrated and
Unix Network Programming) for a full explanation of such things.

Kieran 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]