One Million Concurrent TCP connections

Re:One Million Concurrent TCP connections by asomiv on Friday September 23, 2011 @04:04AM (#3029225)

Yes I would say kqueue, the interface, is superior to epoll. Kqueue allows one to batch modify watcher states and to retrieve watcher states in a single system call. With epoll, you have to call a system call for every modification. Kqueue also allows one to watch for things like filesystem changes and process state changes, epoll is limited to socket/pipe I/O only. It's a shame that Linux doesn't support kqueue.

But as awesome as kqueue is, OS X apparently broke it: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#OS_X_AN...

[ Parent | on HN ]

Re:One Million Concurrent TCP connections by gorset on Friday September 23, 2011 @06:34AM (#3029499)

I fully agree that kqueue is awesome, but what specifically is broken on OSX? I've used in extensively on that platform, and haven't run into any showstoppers.

[ Parent | on HN ]

Re:One Million Concurrent TCP connections by asomiv on Friday September 23, 2011 @08:01AM (#3029679)

You can't poll on TTYs for example. I remember this bug from 2004 and apparently they still haven't fixed it.

[ Parent | on HN ]

Re:One Million Concurrent TCP connections by gorset on Friday September 23, 2011 @08:27AM (#3029735)

Yeah, the lack of support for TTYs can be annoying when writing a terminal application (a workaround for some cases is to use pipes), but it hardly qualifies as a significant problem for writing network applications.

Here's a more interesting bug in OSX: kqueue will sometimes return the wrong number for the listen backlog for a socket under high load.

[ Parent | on HN ]

Re:One Million Concurrent TCP connections by Flow on Friday September 23, 2011 @10:09AM (#3030022)

IIRC, kqueue can be told to read the whole http-request before letting client know there's data to read.

[ Parent | on HN ]

Re:One Million Concurrent TCP connections by rdtsc on Friday September 23, 2011 @12:06PM (#3030480)

How does it work? Do users provide a buffer and the kernel fills the buffer with data and notifies the user when ready?

That is more akin to AIO Linux system, then? Otherwise, epoll/poll/select just notifies users when data is available but the actual copy is done by the user. Surprisingly this can make a huge difference when streaming large amounts of data.

http://blog.lighttpd.net/articles/2006/11/12/lighty-1-5-0-an...

We have argued here before and I have gotten downvoted into oblivion for being pedantic and distinguishing between asynchronous IO and non-blocking IO but it looks like that extra user-space memcpy can make a huge difference.

[ Parent | on HN ]

Re:One Million Concurrent TCP connections by Flow on Friday September 23, 2011 @03:01PM (#3031138)

I can't find anything about this now, just spent a good 20 minutes searching for it. I guess keywords kqueue, buffer request http are too generic in some sense. :-/

Anyway, the idea was to avoid context switches by waiting/parsing in kernel-side till there was enough data for the client to do something else that just another gimme_more_data()-call back to the kernel.

It could even be applied to other methods than kqueue, so perhaps I remember a bit wrong that this was just for kqueues.

[ Parent | on HN ]

Re:One Million Concurrent TCP connections by gorset on Friday September 23, 2011 @03:12PM (#3031176)

That's actually accept_filter(9). The man page for freebsd has a interesting info:

    The accept filter concept was pioneered by David Filo at Yahoo! and
    refined to be a loadable module system by Alfred Perlstein.

The closest you can get by using kqueue is to set a low water mark, so that a read event is only returned when there's enough data ready.

[ Parent | on HN ]

Re:One Million Concurrent TCP connections by Flow on Friday September 23, 2011 @03:48PM (#3031320)

Ah, that's it! Thanks for finding it.

[ Parent | on HN ]