Subject: TCP timeout mechanism

From: Proneet Biswas <[email-masked]>
Date: Fri, 04 Aug 2000 10:35:13 -0700

Hi,
   I am interested in maintaining the TCP session information on my
device. The number of sessions which I plan to support is around 1
million. For supporting this, I plan to keep a free pool and impement a
hashed cache. However, it is not very clear to me how to implement an
efficient timeout mechanism to remove the Session entries which have the
TCP timeout and add them to the free pool. The simplest method is to
iterate through all the entries , take  the time difference between when
a last packet was received in the session entry and the current time and
see if the difference is greater than the TCP TIMEOUT value, If yes
remove the entry and add it to the free pool. It would be great if
anybody could suggest other better methods.

Thanks.
Proneet.

---

From: Alan Cox <[email-masked]>
Date: Fri, 4 Aug 2000 19:37:24 +0100 (BST)

> anybody could suggest other better methods.

This is incorrect. A TCP session without keepalives has an infinite TCP_TIMEOUT.

You need to take slightly more active approaches to session tracking

---

From: Proneet Biswas <[email-masked]>
Date: Fri, 04 Aug 2000 11:48:34 -0700

Hi,
   I am currently tryng to investigate other approaches and it would be useful to
know what are the existing alternatives ?

Thanks.
Proneet.

---

From: Charles Esson <[email-masked]>
Date: Sat, 05 Aug 2000 04:20:54 +1000

I know of no way of getting a guaranteed response from the other end of a TCP
connection. I would love to hear of it if there is.

Connections can definitely be abandoned, you can definitely be left with the resources
tied up for no reason, and you will definitely not have unlimited resources. And for
most OS work rebooting is not an option, though this doesn't seem to be a general
rule.

If you time-out TCP connections the time-out period has to be long ( I chose 24
hours), but with the option of making it indefinite. Having a low priority task going
through a million connections in that time is no big deal.

You could have the time-out task link inactive connections in inactivity order; and
only kill the connection if you have to have the resources. The kill code using the
linked list as the order to search for a connection to kill, the search would have to
allow for the possibility the inactivity has stopped, but 99% of the time it would
take the first connection in the list fins it is still inactive and claim the
resources for the new connection.

In fact you could use the inactivity list in the same way as your free resources list.
Instead of thinking of the resources as in use or free,  think of them as active or
inactive, and only give up if the inactivity time of the resource your about to use
falls below say an hour. The resource in question will have a flag to give the state
of the connection just set them all to "closed" on start-up.

The low level task just goes through the table linking the list in inactivity order
and sets a global "load" value. The claiming task searches down the "inactivity list"
until it finds one that has a time greater than that represented by the" load". At the
head of the list you will only have two types of records, inactive connections, or
connections that have recently become active and are not yet moved down by the
time-out routine.

I like it, might be a worthwhile change, problem I now have is how many connections am
I going to allow.

Regards

---

From: Alan Cox <[email-masked]>
Date: Sat, 5 Aug 2000 01:41:06 +0100 (BST)

> connection. I would love to hear of it if there is.

Spoof a keepalive ACK a few times.