Re: socket in use

On Thu, 26 Jul 2001, Steve Richter wrote:
> 
> Is using the SO_REUSEADDR option bad practice?  

I hope not.. I do it all the time :)   But, I guess it depends on what
you're trying to do...

For example:

Some protocols require the client to use a port in a specific range.   RSH
is one such protocol, it requires the server's port to be 514, and the
client's port to be in the range of 512 - 1023.

Therefore when you implement an RSH client, you start by trying to bind
your socket to port 512.  Failing in that, you try 513, etc, until you
get an available port.

Therefore, using SO_REUSEADDR would be bad -- you wouldn't be able to
detect when a port was already in use.

The opposite example:

A telnet server, http server, ftp server, heck even an RSH server (as 
opposed to an RSH client) needs to bind to a specific port number, always.
And then, it also will listen() to that port number.    Although setting
SO_REUSEADDR allows more than one socket to bind to the same port, it
does NOT allow more than one socket to LISTEN to the same port...

So, in the case of these various servers it makes sense to use
SO_REUSEADDR so that you don't have to try to deal with the 2 minute
delay before re-binding...

> Should a server pgm wait and
> retry when its port is reported as in use?  Esp if the circumstances allow?

Whatever's best for your situation... with a server, it's probably better
to set SO_REUSEADDR... see above...

> 
> is there an instance nbr assigned to each socket to socket conversation and
> is it transmitted along with the ip addr and port nbr in each packet of data
> sent between sockets ?
> 

I don't think so...  the "instance" is kept track of by looking at the
source address, source port, destination address and destination port.  

Generally a client app will have a different port for every instance, 
and a server app will use the same port for every instace.   Since the
client port differs, it can keep them separated.

> 
> Would this "conv instance nbr" enable the ack from the end of a closed conv
> not to be mixed up with packets from a new conv?

If for some reason the client app re-uses the same port number and the 
server app also uses the same port number, this COULD be a concern, but
it should be handled by the ISN (Initial Sequence number) selection 
mechanism of TCP.

To explain that, I'm going to give you a quote from RFC 793:


 Initial Sequence Number Selection

  The protocol places no restriction on a particular connection being
  used over and over again.  A connection is defined by a pair of
  sockets.  New instances of a connection will be referred to as
  incarnations of the connection.  The problem that arises from this is
  -- "how does the TCP identify duplicate segments from previous
  incarnations of the connection?"  This problem becomes apparent if the
  connection is being opened and closed in quick succession, or if the
  connection breaks with loss of memory and is then reestablished.

  To avoid confusion we must prevent segments from one incarnation of a
  connection from being used while the same sequence numbers may still
  be present in the network from an earlier incarnation.  We want to
  assure this, even if a TCP crashes and loses all knowledge of the
  sequence numbers it has been using.  When new connections are created,
  an initial sequence number (ISN) generator is employed which selects a
  new 32 bit ISN.  The generator is bound to a (possibly fictitious) 32
  bit clock whose low order bit is incremented roughly every 4
  microseconds.  Thus, the ISN cycles approximately every 4.55 hours.
  Since we assume that segments will stay in the network no more than
  the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55
  hours we can reasonably assume that ISN's will be unique.


So... there ya have it. :)  Now I have to figure out exactly how much
of this info I want to integrate into the tutorial on sockets that I'm
writing for my web page... :)



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