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

From: "ravi reddy" <[email-masked]>
Date: Fri, 2 Feb 2001 17:44:14 -0000

Hi all,

  In the product that I'm currently working in, we have clients and servers.
The server has a leader-follower pattern of threads which monitor the
connections or data that come as the result of fds that fire from the select
set. (the fd could be listener fd for which a new client connection comes
when it fires or a old fd with some data).

  Now the question is?.

  When the server runs out of FDs, I remove the listener FD from the select
set as I don't want to talk to any client. Coming to the TCP/IP internals, I
believe any new client connections will queue up in the queue with backlog
mentioned by listen() system call until reaped by accept() call. If queue is
full, any new clients will timeout as they cannot contact the server. I
believe the time in this case is 75 seconds which is the establishment
timer. Now what I want to know is if the server never issues an accept()
call to take these connections off the queue (this will happen because we
pulled out the listener FD from the select set and so it won't fire), FOR
HOW LONG will these connections stay in the queue. I presume any client that
sends data to the connection which is in a ESTABLISHED state and queued at
server, it starts a retransmission timer and no response after 5 or 9
minutes (recommended default of 12 retrasmissions) will elicit a RST from
the client side to the  server side. As a result of this, the server TCP/IP
will remove the established connection from the queue.

  So is the time related to retransmission timer?.

  Any help greatly appreciated.

  Have a nice day,
  Ravi.

---

From: Rick Jones <[email-masked]>
Date: Fri, 02 Feb 2001 11:37:53 -0800

>   So is the time related to retransmission timer?.

My guess would be probably not. The client will be able to send data -
the connection is ESTABLISHED, and that data will likely be accepted and
ACKed. My guess would be that those connections in the listen queue will
stay there for quite a long time. Basically until the client gets fed-up
with a lack of response and closes. Or, you explicitly accept and close
them yourself.

I have no guess as to what would happen if you went and did a
listen(s,0) listen(s,1)...

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 jones
-- 
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: Sat, 3 Feb 2001 15:35:19 -0000

> stay there for quite a long time.

  Assuming client sends data for the ESTABLISHED connection which is queued
in the socket receive buffer on the server side and the data fills the
buffer, then I presume the client's TCP will never get any ACKs for the
additional data sent and will eventually timeout which is the retransmission
timeout.

> Basically until the client gets fed-up with a lack of response and closes.

  Any idea of the situations when it would get fed up.

> Or, you explicitly accept and close them yourself.

  In my case server won't accept() or close() the connections as it is out
of FDs and it will do so only if the FD count goes down. The problem here is
that any data sent by client using the ESTABLISHED connection will be put
into socket receive buffer and will probably be ACKed. But if I issue an
accept() call, it will reap a connection from the listen queue and will
overlay the connection onto a FD whose creation will fail as the server is
out of FDs.

> listen(s,0) listen(s,1)...

  You mean to say that I issue an listen(s,0) or listen(s,1) when the server
runs out of FDs. We call listen with a backlog of 5 and then wait for any
FDs to fire from the select set. I haven't investigated this scenario.

> timeout on their connects.

  This is out of question right now with the tight schedules.

  Could you please clarify one more QUESTION?.

  Any clients SYNs will be put into incomplete connection queue waiting for
the three-way handshake to complete. But since the complete connection queue
is full, how would TCP handle this scenario. Though it can complete the
three-way handshake, it can't move this incomplete connection to the
complete connection queue as the queue is full. I guess the server's TCP
will not complete the three-way handshake until the complete connection
queue has space and those SYNs will be ignored and the clients will timeout
after 75 seconds which is the establishment timer.

  If both the queues are full, the client's SYN will be ignored and will
these clients stop trying after the expiry of establishment timer of 75
seconds?.

  Thank you very much for the response.

  regards,
  Ravi.

---

From: Bill Fenner <[email-masked]>
Date: Sat, 3 Feb 2001 10:16:04 -0800

I remember seeing someone talk about an experiment with the BSD API
where it didn't send the SYN/ACK until the first IO operation was
posted to the socket.  This meant that a knowledgable program could
accept() and then close the new socket if it didn't like it, and
normal programs would (should?) be relatively unaffected.

I thought it sounded like a cool idea when I read about it but I never
tried the experiment myself.

  Bill

---

From: Rick Jones <[email-masked]>
Date: Mon, 05 Feb 2001 11:11:13 -0800

> additional data sent and will eventually timeout which is the retransmission

While there are some stacks that "lie" about their window and amount of
data they can store, 99 times out of ten, if the receive socket buffer
is full, the sender has a zero window, and so unless it is broken, will
not be sending and data that will be dropped without an ACK.

>   Any idea of the situations when it would get fed up.

Client-level timeouts, people sitting at keyboards hitting ^C, or "STOP"
buttons. That sort of thing.

> overlay the connection onto a FD whose creation will fail as the server is

Just what is your FD limit? On the "enterprise ready" :) platforms, or
at least two with which I'm slghtly familiar, the per-process FD limit
is either 32768 or 60000 - the kernel being configured apropriately.

>   This is out of question right now with the tight schedules.

As others have pointed-out, which the XTI interface routines and their
descriptions imply what I thought would happen, the actual
implementations may not behave quite that way.

rick

---

From: Craig Partridge <[email-masked]>
Date: Tue, 06 Feb 2001 10:48:33 -0500

In message <[email-masked]>, Bill Fenner writes

>normal programs would (should?) be relatively unaffected.

As I recall this wasn't easy.  The problem is that some sockets
don't do IO -- they do an accept and then hang a select() -- so basically
you have to go through and change a lot of code to make this work.

Craig

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 7 Feb 2001 18:22:00 +0100 (CET)

> 
> In message <[email-masked]>, Bill Fenner
> writes :
> 
> >

The TCP implementation done by Mentat that went into Solaris 2.0
originally had a knob where the SYN/ACK could be deferred until
the application called accept().

Even this caused problems for ftp/ftpd if I recall correctly - the 
establishment of the data connection has some dependencies on the
connect() returning before the other end is told to call accept().

  Erik