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

Re: pps or other unknown upper bound?

On 11/17/05, Jon Hart <[email protected]> wrote:
> On Fri, Nov 18, 2005 at 12:49:48AM +0100, Daniel Hartmeier wrote:
> > This all makes sense. Assuming you're fetching a tiny document from the
> > web server in a fast loop, the client will run out of random source
> > ports. It's probably honouring 2MSL up to the point where it simply has
> > no choice (other than stalling further connect(2) calls), until ports
> > free up.
> The funny thing is, in my tests, despite having ~31000 source ports to
> choose from, the client is unlucky enough most of the time and very
> quickly manages to reuse a port.  It depends on what else the client is
> doing, but I saw a case earlier today that after about 300 connections,
> the source port was reused.
I've sometimes wondered if adding randomization to ephemeral ports was
a cause behind the 'hanging' problem I sometimes see when an OpenBSD
client sources  TCP sessions at a high rate.
Does Debian have random source ports?
My thought is that the classic approach of using ephemeral ports
sequentially is acting as a poor man's "least recently used" algorithm
in choosing the source port for each new session.
Depending on the implementation, source port randomization could cause
a source port to be reused much sooner than with the "classic"
> This has been my approach for much of today -- I know of many ways to
> fix or alleviate this problem on the client, firewall and/or the server,
> but most either have undesireable side affects or unknown consequences.
> In my opinion, the consequences of rethinking the client are pretty
> clear and it seems like the best approach at this point
Given the above issue, I did think of one hack to make the problem
occur at a much lower frequency.  Basically, assign 16 or 32 alias IP
addresses to the web server, and populate a round-robin A record with
all of these addresses.  Then have the client connect to the
destination using a different destination IP address for each session.
This reduces the likelihood of duplicating the same quad by a factor
of 16 or 32.  A hack, but not all hacks are bad