Re: [Linux-decnet-user] Patch to 2.4.15-pre5 to fix local port alloc bug

[Steven W. <st...@gw...>]

Hi,

I wondered about the TIME_WAIT state.... in fact the Linux DECnet code has such
a thing (rather crude but works I think) as I added it to avoid those problems.

After we spoke about the hashing at the storage management conference last year
I started writing a new set of hashing code based upon what you'd said to me
there. It started looking rather ugly, so I made the decision to use much
simpler code to fix the bugs in 2.4 and then to look again at the more
complex, but less limiting code in 2.5.

The idea of adding some bits as a counter to avoid TIME_WAIT seems interesting
but I wonder if we could come up with a better one... for example if we timed
how long it takes for the local port counter (in dn_alloc_port()) to wrap
around ? We could insert an extra delay in the case that it was rotating too
fast. Easy to do since we only ever allocate local ports from user context.

For a more advanced version, that could be done on a per remote-node basis.
Perhaps we need a peer cache, like the ipv4 code .... ? The entries would
contain the local port counter for that remote node and they would only
need to stay around for the TIME_WAIT period.

At least then we'd only need to keep the small cache entry around and not
a bunch of sockets,

Steve.

> 
> Excerpt of message (sent 18 November 2001) by Steven Whitehouse:
> > ...
> > Also, please note that this code 
> > limits the maximum number of DECnet sockets (system wide) to 0xffff - 1. There 
> > isn't really any need for this limit because if you take the local and remote 
> > DECnet addresses into account during socket demultiplexing then you should be 
> > able to have 0xffff - 1 connections to each remote node.
> 
> The global limit is typical of DECnet implementations.  The connection
> identifying approach used in NSP (two identifiers, each picked by one
> endpoint) was chosen specifically so each end could simply use that
> identifier as an index into a vector of connection pointers.  (More
> commonly, some of the bits are index and the rest are a serial number,
> to distinguish old connections from new ones -- so NSP doesn't need
> the TIME_WAIT state as TCP does.)  The result is (a) very easy
> connection lookup for inbound traffic, (b) a global limit on
> connections rather than a per remote host limit.  For the era when
> DECnet (phase 2, actually) was designed, that was a fine tradeoff, and
> it wasn't revisited either for phase 3 or phase 4.
> 
>      paul
>