From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: Raghuram <draghuram@rocketmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Question about tcp hash function tcp_hashfn()
Date: Tue, 30 May 2006 23:55:26 -0600 [thread overview]
Message-ID: <20060530235525.A30563@openss7.org> (raw)
In-Reply-To: <20060531042908.10463.qmail@web51410.mail.yahoo.com>; from draghuram@rocketmail.com on Tue, May 30, 2006 at 09:29:08PM -0700
Raghuram,
On Tue, 30 May 2006, Raghuram wrote:
>
> Hi,
>
> I needed a hash function (in my TCP related work) for
> a project and happened to look at the function used by
> TCP implementation in Linux. I searched for some
> information about this function but couldn't find much
> info. I would appreciate it if someone can provide
> details or some pointers in this regard. Specifically,
>
>
> 1) Are there some design considerations/assumptions
> behind the algorithm? In general, how was the
> algorithm arrived at?
If you mean tcp_hashfn() from 2.4 kernel, I don't believe so.
In fact, if you analyze it, it is not even a very good nor
efficient hash function. For example, it goes to great pains
to permute upper order bits in the local address, which for
most connections will be a constant value.
> 2) What happens if there are collisions? I am assuming
> that each entry in the array will point to a linked
> list of structures. Is there any limit on the length
> of this list?
The hash value is used to index a hash bucket that has
established TCP sockets attached in a linked (collision)
list. Because the number of input values is limited, the
number of collisions is bounded. What the actual bound is
can be determined by analysis or using numerical methods.
Because local address has an extremely limited range, local
port number has a limited range (for dynamic assigment) and
the maximum number of connections will be limited by other
factors (e.g. system maximum number of open file descriptors)
the practical bound is much smaller than the theoretical bound
on the length of the collision list. Because it is not a very
good hash function, the bound on collisions for a given range
of input values might be greater than if a better function were
used. Also, TCP allocates rather large connection hash tables
at startup further reducing the size of collision lists.
There are two typcial uses of TCP: well known port numbers
upon which listening servers exist and outgoing client connections.
Outgoing client connections will almost always use a unique port
number. The hash function does not really exploit this fact.
--brian
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
next prev parent reply other threads:[~2006-05-31 5:55 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-31 4:29 Question about tcp hash function tcp_hashfn() Raghuram
2006-05-31 5:55 ` Brian F. G. Bidulock [this message]
2006-05-31 7:10 ` David Miller
2006-05-31 7:45 ` Brian F. G. Bidulock
2006-05-31 7:49 ` David Miller
2006-05-31 8:00 ` Brian F. G. Bidulock
2006-05-31 9:03 ` Evgeniy Polyakov
2006-05-31 9:12 ` David Miller
2006-05-31 9:44 ` Evgeniy Polyakov
2006-05-31 9:51 ` Brian F. G. Bidulock
2006-05-31 10:58 ` Evgeniy Polyakov
2006-05-31 11:04 ` Evgeniy Polyakov
2006-05-31 13:06 ` Evgeniy Polyakov
2006-05-31 18:29 ` Brian F. G. Bidulock
2006-06-01 6:12 ` Evgeniy Polyakov
2006-06-01 6:18 ` David Miller
2006-06-01 6:22 ` Brian F. G. Bidulock
2006-06-01 6:24 ` David Miller
2006-05-31 18:41 ` David Miller
2006-06-01 6:04 ` Evgeniy Polyakov
2006-06-01 6:18 ` Brian F. G. Bidulock
2006-06-01 6:30 ` Evgeniy Polyakov
2006-06-01 6:46 ` Brian F. G. Bidulock
2006-06-01 7:01 ` Evgeniy Polyakov
2006-06-01 7:11 ` Brian F. G. Bidulock
2006-06-01 8:38 ` Evgeniy Polyakov
2006-06-01 10:24 ` Brian F. G. Bidulock
2006-06-01 11:06 ` Evgeniy Polyakov
2006-06-01 18:40 ` Brian F. G. Bidulock
2006-06-01 20:21 ` David Miller
2006-06-02 7:01 ` Evgeniy Polyakov
2006-06-02 5:40 ` Florian Weimer
2006-06-02 7:48 ` Evgeniy Polyakov
2006-06-02 15:10 ` Brian F. G. Bidulock
2006-06-02 17:26 ` Florian Weimer
2006-06-02 17:37 ` Brian F. G. Bidulock
2006-05-31 9:52 ` Brian F. G. Bidulock
2006-05-31 8:49 ` Brian F. G. Bidulock
2006-05-31 9:02 ` David Miller
2006-05-31 9:39 ` Brian F. G. Bidulock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060530235525.A30563@openss7.org \
--to=bidulock@openss7.org \
--cc=draghuram@rocketmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox