Subject: Any successor to the sockets APIs ???

From: "Ramesh Shankar" <[email-masked]>
Date: Mon, 22 May 2000 17:21:39 -0600

I am curious to know whether there is any work in progress on a successor to the BSD (or for that matter Winsock) sockets API. The following are the reasons for the question:

- The BSD sockets API does not have a really powerful interface for use with event driven programming. select() and poll() are available, but the performance issues associated with it have been known for sometime now. Winsock has some interesting APIs which seem to help somewhat better than BSD sockets APIs.

- I have been reading about the performance issues with persistent HTTP connection, pipelined requests and how the responses have to be sequential as there is no clear way to demarcate invidual TCP sessions etc (Work by Jeff Mogul and Venkata Padmanabhan). Is there a move towards some kind of APIs like that? (I haven't yet finished the Ph.D. thesis though to understand more details on the nature of APIs).

Any pointers would be greatly appreciated.

S.R.

---

From: Andi Kleen <[email-masked]>
Date: Tue, 23 May 2000 10:28:31 +0200

> - The BSD sockets API does not have a really powerful interface for use with event driven programming. select() and poll() are available, but the performance issues associated with it have been kno…

Single Unix defines a replacement: real time signals that carry fd event
notifications. They unfortunately require a non standard extension to set
the SIGIO signal for a fd to be really useful (or another non standard
extension for queued SIGIO). At least in modern Linux it is supported.
poll() is still needed as fallback when signals get lost.
From first tests queued SIGIO with a sigwaitinfo() main loop scales
very nicely for web servers.

-Andi

---

From: Alan Cox <[email-masked]>
Date: Tue, 23 May 2000 13:38:30 +0100 (BST)

> - The BSD sockets API does not have a really powerful interface for use with event driven programming. select() and poll() are available, but the performance issues associated with it have been kno…

Linux supports event based real time signalling (kind of vaguely akin to the
VMS AST setup).  There are plenty of people who find poll/select scale nicely.
Under load your syscalls/task count drops which materially improves your
throughput. Thus as the load goes up degradation is good.

Point a big internet client simulation (not crap like specweb) at a threaded
or multiprocess server like apache and then try it with thttpd. Its not the
simple set of equations some people think.

[Apache btw suffers, thttpd just keeps going. apache is faster for small loads]

Alan