[c - async sockets] help! (12)

1 Name: #!/usr/bin/anonymous : 2007-10-16 06:46 ID:sxcISE2S

I need some good books/tutorials on asynchronous sockets with C..
Before you ask, yes i have googled and it brough up irrevelant results

2 Name: #!/usr/bin/anonymous : 2007-10-16 09:50 ID:Heaven

> Before you ask, yes i have googled and it brough up irrevelant results

Then read them.

3 Name: #!/usr/bin/anonymous : 2007-10-16 14:36 ID:sxcISE2S

>>2
They are irrelevant; Of not relevance to async sockets in C.

4 Name: #!/usr/bin/anonymous : 2007-10-16 19:18 ID:ChVVLwGD

>>1
That's because nobody says "asynchronous sockets in C". They refer to real problems: overlapped IO, multiplexing IO, edge-triggered event IO, and level-triggered event IO.

See: www.kegel.com/c10k.html

5 Name: #!/usr/bin/anonymous : 2007-10-16 19:57 ID:Heaven

Stupid >>1 is stupid.

6 Name: #!/usr/bin/anonymous : 2007-10-16 21:53 ID:Heaven

We can do without the insults. I think >>4 offered a good link and >>1 can tell us if he has a problem with anything more specifically.

7 Name: #!/usr/bin/anonymous : 2007-10-17 14:40 ID:d4E9JfY3

>>6
I think >>4's link is what i needed, thanks

>>5
?

8 Name: >>5 : 2007-10-18 03:14 ID:Heaven

Very well. What I meant is that in general, the vocabulary used in Microsoft Windows and its various C++-oriented libraries is generally not the one that is used in the more standard, cross-platformish interfaces. As such, it is silly to assume that e.g. google would produce anything pertinent with the search "asynchronous sockets in C", since first, "C" and "C++" map to the same search keyword and second, "asynchronous" is not the correct expression for dealing with sockets in the first place (for various, generally UNIX-specific reasons which are too long to go into here).

To be constructive, I would suggest that >>1 instead google for information on non-blocking sockets, or more generally non-blocking I/O in POSIX. The reason for the latter is that sockets are just a special case of file descriptor, the mechanism by which endpoints of serial communication (among other things) are implemented in UNIX, and as such the techniques used for non-blocking I/O generally apply to sockets just like they do to e.g. named pipes or TTY devices.

9 Name: #!/usr/bin/anonymous : 2007-10-18 12:03 ID:Heaven

>>8

What exact magic are you suggesting >>1 should use to find out through THOUGHTS ALONE that Unix calls "asynchronous" "non-blocking"?

10 Name: #!/usr/bin/anonymous : 2007-10-18 13:53 ID:ChVVLwGD

>>5

Non-blocking I/O is part of it, but it isn't all of it, and worse, many people ask for NBIO when they really want to multiplex multiple connections with a single process. NBIO requires a contortion for portability: http://cr.yp.to/unix/nonblock.html

Poll, /dev/poll, /dev/epoll, epoll, select, Waitformultipleobjectsex and so on, are all multiplexed I/O. This is very easy and doesn't require NBIO, but does require a new kind of event loop.

Modern unixish systems and Windows have overlapped IO whereby you start an I/O operation, and the OS generates a signal (completion) when its done. Many windows manuals use the term "asynchronous IO" for this, as does POSIX (see AIO). Without this kind of AIO, you can use non-blocking writes, but it means you have to handle queueing yourself, and it's best to use a library (like VSTR) to handle this because it is very complicated to get right. See: http://www.and.org/vstr/

Oddly enough, most operating systems offer a big kernel buffer for output, so doing multiplexed reads and blocking writes often gives the best performance so long as you don't have to worry about broken or malicious clients (or reliably small responses; as is the case for writing an SMTP server).

If >>1 wants to learn about "asynchronous IO" from an academic perspective, they should probably see >>4 but if they're interested from a practical matter they should either use a library like VSTR or look for "overlapped IO" libraries on windows (if that's where they're at).

11 Name: #!/usr/bin/anonymous : 2007-10-18 20:00 ID:d4E9JfY3

I'm on unix, i want my code to work on posix-ish unix systems.

> when they really want to multiplex multiple connections with a single process.

Well, yeah, that's what i want.. Actually, i want a very efficient method to handle many file descriptors. Blocking IO or threads (or even worse, fork()) are not efficient as far as i know.

I'm going to read that kegel page because i want to learn about those methods before i proceed in writing code with them, however this seems nice http://monkey.org/~provos/libevent/ (the link is in the kegel page http://www.kegel.com/c10k.html#frameworks)

12 Name: >>5 : 2007-10-19 15:22 ID:Heaven

>>9
Googling for socket programming would work. Most of the texts on the intarbutts are written from a BSD sockets (i.e. not win32) POV, and eventually mention non-blocking operation.

This thread has been closed. You cannot post in this thread any longer.