Re: socket in use

excellent. thanks again scott.

If you want any more questions for your tutorial, just say so :)

Steve


---------- Original Message ----------------------------------
From: Scott Klement <klemscot@klements.com>
Reply-To: MIDRANGE-L@midrange.com
Date: Thu, 26 Jul 2001 15:46:20 -0500 (CDT)

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