Subject: Re: time of queued connections if not reaped...

From: [email-masked] (Jerry Toporek)
Date: Fri, 2 Feb 2001 13:20:24 -0800

> 
> If you really want those connections to go away without more direct
> intervention, you might want to use an interface that inserts the
> application between the receipt of the SYN and the sending of the
> SYN|ACK. I _think_ XTI is or can be such an interface. In that case, you
> would simply stop taking the request notificatoins and the clients would
> timeout on their connects.
> 

Rick:

I don't know of any TCP implementation that withholds the SYN-ACK until the
application accepts the connection.  I do know that if you experiment with
such a strategy, you will find that BSD-based implementations of FTP will
be unable to successfully establish a data connection.  It's been a long time
since I stumbled into this, so the details are fuzzy, but basically you get
into a deadlock where the client doesn't try to accept the data connection
until it receives a message on the control connection, but the server doesn't
send that message on the control connection until the data connection is
established.  This works only if the SYN-ACK for the data connection is sent
without waiting for the accept.

It may be the case that XTI (or would that really be TPI?) intended for the
application to control whether or not an inbound connection ever gets to
established state.  This sounds like a pretty good idea, but having FTP break
is not acceptable.  FTP implementations that work this way could, of course,
be "fixed", but that isn't going to happen.

jt

---

From: Rick Jones <[email-masked]>
Date: Fri, 02 Feb 2001 15:02:17 -0800

> application to control whether or not an inbound connection ever gets to

Certainly, that is what I infered from the manpages for t_listen and
t_accept :)

rick
-- 
ftp://ftp.cup.hp.com/dist/networking/misc/rachel/
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, OR post, but please do NOT do BOTH...
my email address is raj in the cup.hp.com domain...

---

From: "ravi reddy" <[email-masked]>
Date: Mon, 5 Feb 2001 18:49:01 -0000

Hi all,

  We have clients and servers in our product. When the server runs out of
FDs, we usually remove the listener FD from the select set and register it
back when any FD is freed. Are there any drawbacks with this solution?.
Currently we have connection timeouts and so the clients will timeout fast
enough without waiting for server to accept the connections or until the
keepalive probes kickin. But infinite connection timeouts are not also ruled
out in the implemenation.

  What are the drawbacks of closing the listener socket and binding it again
to the same port?. The only drawback I can think of right now is that the
port could be reused by the OS and the server which has closed its listener
socket will not be able to bind to it.

  Any help greatly appreciated.

  regards,
  Ravi.

---

From: Mahmoud Chilali <[email-masked]>
Date: Wed, 14 Feb 2001 19:32:45 +0100

When you close the fd, the socket is not immediately freed at the TCP
level. so the port will be "already in use" even if no application is using
it. This may be either annoying or not a problem depending on your
requirements.

I personally prefer setting a max-connections threeshold (this should be
less than the number of fds per process), and if the threshold is reached,
accept the connection and close it immediately. The time this takes is
short enough compared to what you need as timeouts.

regards
Mahmoud

---

From: "ravi reddy" <[email-masked]>
Date: Wed, 14 Feb 2001 18:53:21 -0000

We do have a threshold. When the threshold is reached, we remove the
listener FD from the select FD set and issue a listen() call of 0. When the
FD count goes down, we put back the listener FD and reset the listen queue
length. The only issue with this is that clients will wait for 75 seconds
before timing out (listen() call of 0 is ignored by BSD implementations
which allow one connection to go through to the complete connection queue
and this client will indefinitely wait). Other than using client-level
timeouts, we have no way to make these clients timeout before 75 seconds. If
there is a way, please let me know.

> short enough compared to what you need as timeouts.

  What this does is it makes the listener thread unnecessarily spin (by
accepting and closing)
without doing any meaningful work.

  Thanks,
  ravi.

---

From: Alan Cox <[email-masked]>
Date: Wed, 14 Feb 2001 19:48:04 +0000 (GMT)

> there is a way, please let me know.

Listen counts are also ignored by hosts using syncookies.

---

From: Mahmoud Chilali <[email-masked]>
Date: Thu, 15 Feb 2001 19:57:47 +0100

At 18:53 14/02/01 +0000, ravi reddy wrote:

>listener FD from the select FD set and issue a listen() call of 0.

note that the backlog argument to listen is interepreted in a system
dependent manner.

>When the

the close after accept is probably faster (I don't have the state diag at 
hands).

>without doing any meaningful work.

probably, but replacing a "accept+close" with a "listen+listen" or with a
"close+socket+bind+listen" doesn't add any meaningful stuff here.
(Also, note that a program generally spends its time doing things that are not
meaningful:)

The problem with your approach is that you add design constraints just to cope
with a situation that should be exceptional. The accept/close approach is 
trivial
and won't "happen" under normal circumstances (by normal circumstances, I mean
that you configure your system and software to have the correct threshold, and
if the clients are yours, configure them to be "friendly"....)

regards,
Mahmoud