lkml.org 
[lkml]   [1999]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject> 15K simultaneous connections EXAMPLE program/OS config needed, was: Re: POSIX aio vs completion ports
Stephen, or anyone else, are you aware of a test program that illustrates the
use of existing (2.2.12+) mechanisms to efficiently handle many sockets?

I have several needs for this, including a communication concentrator server.
I could use a collection of processes each having at most 1024 (or something
similarly small) sockets each working together, but although this appears to
be workable it sounds like there are much more efficient ways.

What will slow down at the OS level with many sockets?

Is there a limit to the number of connections per IP address, assuming many
different client IP's? (In other words, is there any problem with running out
of local sockets? There shouldn't be really since a client program that
doesn't specify a certain local socket doesn't care if it has that same socket
number used with N different remote IP's.)

I really want to handle 100,000 TCP connections simultaneously per system,
eventually.

I can see that there are two ways to optimize: for many descriptors with
little traffic and fewer (but still large) descriptors with a lot of traffic.
Ideally, if there were a significant latency or performance benefit, you
should be able to dynamically tune the handling of a connection.

Thanks
sdw

"Stephen C. Tweedie" wrote:

> Hi,
>
> On Sat, 11 Sep 1999 21:26:47 -0700, John Gardiner Myers
> <jgmyers@netscape.com> said:
>
> > Alan Cox wrote:
> >> POSIX real time signal queues are effectively completion ports.
>
> > You must not have understood the post you were replying to. POSIX real
> > time signal queues are inferior to completion ports in many ways.
>
> > * As far as I know, there is no way to allocate a POSIX real time signal
> > number in a thread safe manner. There is no equivalent to the socket()
> > system call--one must just pick a number and hope that no other thread
> > in the same process just picked the same number.
>
> As far as I know, completion ports still have the demultiplexing done in
> a single place, so in that model you still have to have extra explicit
> application/library cooperation to let libraries share queues.
>
> > * Chuck Lever informs me that the signal queue might overflow, leading
> > to lost completion notifications. There is no reasonable way for an
> > application to recover from such a condition.
>
> There is. The existing kernel supports sending a separate, higher
> priority event to notify the application of overflow, and poll is a
> sufficient recovery mechanism. You don't expect overflow to be a
> common, performance-critical case.
>
> > * POSIX aio lacks a mechanism to request read polls.
>
> Who is talking about POSIX aio? That is a totally different API. For
> the purposes in question --- networking IO --- leave POSIX aio well
> alone, Unix O_NONBLOCK plus completion events is a perfectly adequate
> API. The async IO API is not necessary or desirable.
>
> > * POSIX aio lacks asynchronous versions of writev() and sendfile().
> > (Though the lack of an aio_writev() is made less important by
> > TCP_CORK.)
>
> See the previous point: you'd be crazy to want aio_writev on a socket.
>
> --Stephen
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

--
OptimaLogic - Finding Optimal Solutions Web/Crypto/OO/Unix/Comm/Video/DBMS

sdw@lig.net Stephen D. Williams Senior Consultant/Architect http://sdw.st

43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax 5Jan1999




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.121 / U:0.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site