× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: socket in use
  • From: Scott Klement <klemscot@xxxxxxxxxxxx>
  • Date: Thu, 26 Jul 2001 10:46:54 -0500 (CDT)



On Thu, 26 Jul 2001, Steve Richter wrote:
> 
> Mr Mayor and other socket people,
> 
> I saw that item when I was reading my sockets manual. It struck me as rather
> odd. Any idea as to its origin?
> 
> Steve Richter
> A mere socket rookie.
> 

This is somewhat difficult to explain, but I'll do my best...

The TCP protocol is a 'reliable' protocol.  IT ensures that all packets
are received on both sides of the connection.

When a connection is closed, each side of the connection sends a 'FIN' 
(finished) packet to notify it's peer that the connection is to be closed.
Being a reliable protocol, it has to ensure that this 'FIN' packet was
received, so the side that receives the 'FIN' packet will send back a 
'ACK' (acknowledgement) packet.

Okay, that's well and good -- but how does it know that the 'ACK' packet
got received?   

The answer is...   it doesn't.   If the ACK is never received, the side
that is expecting it will re-send it's packet after a timeout period. 
But if the ACK is received, it gets no response at all.

Therefore, there is a period of time after that final ACK where the socket
is waiting for a potential 're-send' of the FIN packet, just in case the
ACK got lost.

Forcing the socket to close before this timeout value has elapsed would
violate the TCP protocol, and is generally not a good idea :)

The 'timeout' value that determines when a packet is to be re-sent is 
called the MSL (Maximum Segment Lifetime) and it defines the length of
time that a segment (a packet containing a piece of a TCP stream) can
bounce around the network before being considered 'lost'.

When waiting for a 're-send' because that final ack was lost, RFC 793
states that you should wait for (2 x MSL) before giving up.   This way,
you've taken into account both the MSL time, as well as the extra time
that a slow network connection might add to it.

So back to the question....  why can't you bind() to a port within a
period of time after that port has been closed?   

The system doesn't allow two different programs/processes/etc to bind use
the same port at the same time unless the 'SO_REUSEADDR' socket option
has been set.

Since that port is still in use (due to the wait for the 2 x MSL timeout)
it does not let you re-bind to it until that timeout period has elapsed.

I hope that makes sense...   It's a little difficult to put into words...



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.