How to Query Number of Queued TCP Connections?

Hello!

I've been poking around trying to find this, but so far no luck. Does
anyone know if there is a getsockopt() or similar call I can use to
determine the number of pending completed TCP connections queued (but
not yet accept()'ed) on a listening socket? I guess it would be
interesting to know the number of incomplete ones, too, if possible.

Thanks!

Tim

In comp.os.linux.networking Hokousha <(E-Mail Removed)> wrote:
> Hello!
>
> I've been poking around trying to find this, but so far no luck. Does
> anyone know if there is a getsockopt() or similar call I can use to
> determine the number of pending completed TCP connections queued (but
> not yet accept()'ed) on a listening socket? I guess it would be
> interesting to know the number of incomplete ones, too, if possible.

There is no capability for this request in the standard Berkeley sockets
API, AFAIK. Nor is there any program I can think of (netstat or lsof
would be the likely candidates) that can display this information).

I imagine it wouldn't be too difficult to write a kernel patch to put
this information into /proc/ somewhere, as the data must surely be held
in the kernel somewhere.

--
Cameron Kerr
(E-Mail Removed) : http://nzgeeks.org/cameron/
Empowered by Perl!

I don't know about linux but windows have no way , I'm appreciting that you
need it to choose backlog param ?
Arkady

"Hokousha" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> Hello!
>
> I've been poking around trying to find this, but so far no luck. Does
> anyone know if there is a getsockopt() or similar call I can use to
> determine the number of pending completed TCP connections queued (but
> not yet accept()'ed) on a listening socket? I guess it would be
> interesting to know the number of incomplete ones, too, if possible.
>
> Thanks!
>
> Tim

In comp.protocols.tcp-ip Hokousha <(E-Mail Removed)> wrote:
> I've been poking around trying to find this, but so far no
> luck. Does anyone know if there is a getsockopt() or similar call I
> can use to determine the number of pending completed TCP connections
> queued (but not yet accept()'ed) on a listening socket? I guess it
> would be interesting to know the number of incomplete ones, too, if
> possible.

Out of curiousity, what would you do with the information?

rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...

On 24 Feb 2004 20:32:56 -0800, (E-Mail Removed) (Hokousha)
wrote:

>I've been poking around trying to find this, but so far no luck. Does
>anyone know if there is a getsockopt() or similar call I can use to
>determine the number of pending completed TCP connections queued (but
>not yet accept()'ed) on a listening socket? I guess it would be
>interesting to know the number of incomplete ones, too, if possible.

Have you tried setting the SO_DEBUG (?) socket option and then using
the trpt (?) program?

I don't recall whether you could get the info you're needing by means
of that socket option, and don't know whether Linux support that
socket option, though.

--
Fernando Gont
e-mail: (E-Mail Removed)

[To send a personal reply, please remove the ANTISPAM tag]

Cameron Kerr <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> There is no capability for this request in the standard Berkeley sockets
> API, AFAIK. Nor is there any program I can think of (netstat or lsof
> would be the likely candidates) that can display this information).
>
> I imagine it wouldn't be too difficult to write a kernel patch to put
> this information into /proc/ somewhere, as the data must surely be held
> in the kernel somewhere.

Hmmmm... an interesting idea for the future, perhaps!

Thanks!

Tim

Rick Jones <(E-Mail Removed)> wrote in message news:<q46%b.1093$%(E-Mail Removed)>...
> In comp.protocols.tcp-ip Hokousha <(E-Mail Removed)> wrote:
> > I've been poking around trying to find this, but so far no
> > luck. Does anyone know if there is a getsockopt() or similar call I
> > can use to determine the number of pending completed TCP connections
> > queued (but not yet accept()'ed) on a listening socket? I guess it
> > would be interesting to know the number of incomplete ones, too, if
> > possible.
>
> Out of curiousity, what would you do with the information?

There are really two things I'm looking at. The original purpose was
to provide a way for an FTP server to determine whether multiple
clients were attempting to connect() to a passive open port in real
time, on the theory that multiple attempts would be indicative of an
active attack. The second application is what Arkady suggested: to
fine-tune the backlog parameter. Stevens presents a table of queued
connections for a busy HTTP server in Unix Network Programming, but
doesn't explain how he did it, so I thought there might be a poorly
documented feature.

Tim

In article <(E-Mail Removed) >,
(E-Mail Removed) (Hokousha) wrote:

> There are really two things I'm looking at. The original purpose was
> to provide a way for an FTP server to determine whether multiple
> clients were attempting to connect() to a passive open port in real
> time, on the theory that multiple attempts would be indicative of an
> active attack.

For this one you don't really need to know the size of the queue, just
whether it's more than one. Call accept() a second time in non-blocking
mode. If it returns another FD, you know there were multiple "clients"
trying to connect at the same time, indicating an attack.

--
Barry Margolin, (E-Mail Removed)
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

In comp.protocols.tcp-ip Hokousha <(E-Mail Removed)> wrote:
> Rick Jones <(E-Mail Removed)> wrote in message news:<q46%b.1093$%(E-Mail Removed)>...
>> Out of curiousity, what would you do with the information?

> The second application is what Arkady suggested: to fine-tune the
> backlog parameter.

I tend to think of a backlog parameter as being a rather binary thing
- it is either large-enough, or it is not. I don't tend to think of a
backlog parameter as being "too large" (at least in the context of
general as opposed to embedded systems) as my understanding is that it
is a limit, not a pre-allocation of some sort. So I tend to just go
with "make the thing huge" (1024 or 2048 or 4096) and be done with it.
If one starts to overflow a queue that large, likely as not other
things are hitting their limits that would need to be addressed first
anyway.

Otherwise, you need to start grubbing around in the stack
datastructures.

rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...

On Fri, 27 Feb 2004 22:35:48 GMT, Rick Jones <(E-Mail Removed)>
wrote:

>> The second application is what Arkady suggested: to fine-tune the
>> backlog parameter.
>I tend to think of a backlog parameter as being a rather binary thing
>- it is either large-enough, or it is not. I don't tend to think of a
>backlog parameter as being "too large" (at least in the context of
>general as opposed to embedded systems) as my understanding is that it
>is a limit, not a pre-allocation of some sort. So I tend to just go
>with "make the thing huge" (1024 or 2048 or 4096) and be done with it.

Perhaps it *would* make sense to not-make-it-too-large to impose a
limit on the number of system resources a given app can take (a limit
on the number of established connections not yet accept()ed).

However, it could only make sense to do this on systems that drop
incoming connection requests when the listening queue is full. Thus,
the client's SYN would be retransmitted some time later, when the
listening queue is hopefully not full anymore. As, it would be the
sending TCP that would retry the connection establishment, it would be
transparent to both the client app and the user.

IIRC, Windows responds with an RST when the listening queue is full
some many clients would probably give up rather than trying to
establish the connection some time later.

--
Fernando Gont
e-mail: (E-Mail Removed)

[To send a personal reply, please remove the ANTISPAM tag]