Five Pitfalls of Linux Sockets Programming (developerWorks) [LWN.net]

developerWorks covers some common mistakes in socket programming. "First introduced into the 4.2 BSD UNIX® operating system, the Sockets API is now a standard feature of any operating system. In fact, it's hard to find a modern language that doesn't support the Sockets API. The API is a relatively simple one, but new developers can still run into a few common pitfalls. This article identifies those pitfalls and shows you how to avoid them."

to post comments

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 21, 2005 1:13 UTC (Wed) by Zarathustra (guest, #26443) [Link] (12 responses)

"Sockets are the X-Windows of IO interfaces." -- Rob Pike

And for an example see pages 8, 9 and 10 of his great presentation The Good, the Bad, and the Ugly: The Unix Legacy.

Pike's presentation

Posted Sep 21, 2005 10:19 UTC (Wed) by man_ls (guest, #15091) [Link]

Very interesting presentation. I wonder why it is so often like this: the first solution to a problem wins, even if better ones emerge over time.

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 21, 2005 11:21 UTC (Wed) by hppnq (guest, #14462) [Link] (10 responses)

Those examples aren't very convincing, are they? I'll admit upfront that I have always been a big W. Richard Stevens fan, and I adore shared libraries.

I must say I found this presentation very enlightening. I have tried diff'ing two PowerPoint files, and indeed, it produces utter rubbish! It also fails miserably at driving my coffeemachine and I daresay I'll be able to find more flaws in this miserable good-for-nothing tool, given time and inspiration.

So it'll be Plan 9 for me from now on. I'll be so relieved when I can finally use regexps in Netscape. And in diff as well, I presume.

Tool approach

Posted Sep 21, 2005 15:46 UTC (Wed) by man_ls (guest, #15091) [Link] (9 responses)

I think you have missed the point, probably because you did not want to see it. Pike says:

The tool approach teaches lessons other communities can learn from. Try to diff two PowerPoint docs.

It is obviously not meant as a shortcoming of diff, but of PowerPoint: binary formats break diff, so they might provide a similar tool. Then you say:

I'll be so relieved when I can finally use regexps in Netscape.

I think the author is not requesting regexp search in Netscape because it is useful; he is pointing out that it is not possible to use regular expressions at all. With command line tools, you can usually pipe the output to egrep; graphical programs break this paradigm and some others in the process, and often do not replace it with alternatives. The result is a less powerful environment.

Tool approach

Posted Sep 21, 2005 17:32 UTC (Wed) by hppnq (guest, #14462) [Link] (8 responses)

Are you kidding me?! Your quote is preceded by this ominous remark:

"What Unix does well isn't what people want"

So pray tell me, what is the lesson to be learned from not being able to diff two PowerPoint files?!

As for the Netscape example: that's without a doubt one of the most hilarious paragraphs I have ever read in a Unix related paper. I'll quote it here in full, just for your amusement:

Then think about regular expressions:
One of Unix's greatest contributions; unused outside.
Almost no visibility beyond the Unix community!
Does your web browser's Find command use regexps? Why not?
Netscape was written on Unix, is still used on Unix, but doesn't accept even that one key idea!

This, in fact, reaches a level of stupidity that makes it hard to believe Rob Pike wrote this.

Tool approach

Posted Sep 21, 2005 19:34 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

What's stupid about it? Monolithic GUI tools are profoundly non-Unixlike, and this is just one of many reasons why.

I think Pike has a pretty good idea of what the Unix philosophy is like, and what doesn't follow it. :)

Tool approach

Posted Sep 21, 2005 20:41 UTC (Wed) by hppnq (guest, #14462) [Link]

Yup, but that's not the point. Read the presentation!

Tool approach

Posted Sep 22, 2005 0:39 UTC (Thu) by man_ls (guest, #15091) [Link] (4 responses)

Your quote is preceded by this ominous remark: "What Unix does well isn't what people want" So pray tell me, what is the lesson to be learned from not being able to diff two PowerPoint files?!

People actually use PowerPoint files, and maybe they would like at some point to find the difference between two such files. I know I have felt similar needs with. So Unix cannot find the difference between some binary files, which is what people want. So maybe the publisher of PowerPoint should provide a "diff" tool, or change the format (which is IMHO what Pike hints at); or we should not use such abominations. Then if you use e.g. SVG you can diff two files; but you have to know the format well to understand the diff, and people do not want to learn complex formats.

As for the Netscape example: [...] This, in fact, reaches a level of stupidity that makes it hard to believe Rob Pike wrote this.

Keep in mind that Pike is writing about "the good, the bad and the ugly". Regular expressions have good, bad and ugly points.

Tool approach

Posted Sep 22, 2005 5:06 UTC (Thu) by hppnq (guest, #14462) [Link] (3 responses)

So Unix cannot find the difference between some binary files, which is what people want.

That pretty much sums it up, don't you see? First, "Unix" has nothing to do with it, "Unix" couldn't find anything if its life depended on it. In any case "Unix" was not conceived so it could find the differences between PowerPoint files (which is more or less what Pike is saying of course), but then why would one expect such functionality? Because diff is part of the Unix heritage?!

Sure, people use and depend upon graphical interfaces more than they did in 1970. And of course traditional Unixisms like pipes tend not to interface well with GUIs. Anyone who is of the opinion, that, because of this, there is something wrong with Unix, must be quite short-sighted.

Personally, I find it amazing that the same system that started out as a platform for grep and diff is now effortlessly running OpenOffice on PowerPoint files. And it seems to me that the Internet is living proof of the immense success of the sockets implementation on Unix systems, for that matter. Unix is exactly what I want. ;-)

Tool approach

Posted Sep 22, 2005 6:18 UTC (Thu) by man_ls (guest, #15091) [Link] (2 responses)

Yes, I think I see the same thing: the original ideas that were fit for a stream of characters (cat, diff, grep) are not that good for a world of graphical interfaces, complex hierarchical objects and roaming networking. Of course there is nothing wrong with the Unix heritage!

But we do not agree on what follows from there: you say that Unix is exactly what you want. Pike seems to say that Unix might (even should) be extended to encompass this new world of ours. And why not?

Tool approach

Posted Sep 22, 2005 7:54 UTC (Thu) by hppnq (guest, #14462) [Link] (1 responses)

I think it eventually boils down to what development model one believes in. I happen to think that evolution is the way to go. Which almost inevitably leads to compromises when trying to make subsystems play together nicely, especially if they have no common heritage.

The funny thing is, of course, that one of the more sensible remarks in the presentation is the observation that interfaces only work at some level and in some context. So I wouldn't draw the conclusion that there is something wrong with the Unix model, because dammit, I can't "cat homepage.html | netscape | sort". I happily accept this, because netscape's interfaces to me and to the world are optimized for the purpose of browsing, which is what I usually want when firing up a browser.

By the way, there are plenty of examples where both networking and GUIs are interfaced with the more traditional Unix way of working, or one wouldn't be able to implement a webserver in Korn shell or use scripting languages like Tcl/Tk.

Tool approach

Posted Sep 22, 2005 8:15 UTC (Thu) by man_ls (guest, #15091) [Link]

I think it eventually boils down to what development model one believes in. I happen to think that evolution is the way to go.

The world is clearly on your side, since we are all using Linux and very few people use Plan 9; I'm not planning to use Plan 9! But the inertia still amazes me.

Tool approach

Posted Sep 22, 2005 7:53 UTC (Thu) by rqosa (subscriber, #24136) [Link]

> Does your web browser's Find command use regexps?

Yes, it does. (I'm using Konqueror.)

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 21, 2005 12:20 UTC (Wed) by RobSeace (subscriber, #4435) [Link] (7 responses)

> Three classes of return values are possible from the send API function:
>
> * If the data has been successfully queued for transmission, a zero is returned.

Um, no... This is completely wrong... send()/write() will always return
the number of bytes queued for transmission, except in the case of errors
(including transient 'soft'-errors, like EINTR, EAGAIN, etc.) where it
returns -1... It should never return zero, unless maybe you pass in zero
as the length arg...

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 21, 2005 14:30 UTC (Wed) by hppnq (guest, #14462) [Link] (6 responses)

The eh, Six Pitfalls of Linux Sockets Programming eh? ;-)

Minor nitpick: if you pass in a length of 0, send(2) and friends will surely return either 0 or -1, but the opposite is not necessarily true: a return value of 0 means "0 bytes sent", which may be either because length == 0 or just because you have no data to send. ;-)

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 21, 2005 14:38 UTC (Wed) by RobSeace (subscriber, #4435) [Link] (5 responses)

There is no other possible scenario where a return value of 0 could
occur (other than a passed-in length of 0), that I'm aware of... If
the socket is blocking, and there is no room in the queue for any more
data at all, then send()/write() will block... If the socket is
non-blocking, and there is no room in the queue for any more data at all,
then send()/write() will return -1 with errno set to EAGAIN... In all
other cases, there is room for at least 1 byte of data in the send queue,
and hence the return value will be at least 1... I can conceive of no
situation, short of passing in a length of 0, where send()/write() could
ever possibly return 0...

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 21, 2005 14:51 UTC (Wed) by hppnq (guest, #14462) [Link] (4 responses)

I meant that there is a distinction between the actual length of the data, and the value you pass on to send(2) as the requested number of bytes to send, e.g., send(fd, NULL, 1024, 0).

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 21, 2005 15:09 UTC (Wed) by RobSeace (subscriber, #4435) [Link] (3 responses)

That example I would expect to return -1 with an errno of EFAULT, since
the NULL pointer is invalid... Alternatively, it might simply crash the
app with SIGSEGV... But, I certainly would never expect it to return 0...
Really, there is no other notion of "actual length of the data" than the
length you pass in to send()/write()... It has no other way of knowing
any other length than what you tell it... (Short of running off the end of
your valid address space, causing either EFAULT or SIGSEGV...)

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 21, 2005 15:29 UTC (Wed) by hppnq (guest, #14462) [Link] (2 responses)

EFAULT seems appropriate, yes; SIGSEGV would be disappointing.

Though, looking up a few send(2) manpages I cannot really conclude that NULL would be an invalid address (I consulted a Solaris manpage before my first comment * bangs head on table * and apparently Solaris doesn't care about EFAULT at all ;-).

But it's trivial to find out of course what Linux does in this case, I'll let you know unless you beat me to it. ;-)

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 21, 2005 16:24 UTC (Wed) by RobSeace (subscriber, #4435) [Link] (1 responses)

It does indeed fail with EFAULT on both Linux (2.4.x, at least) and QNX4.2x
(the only other system I have access to, at the moment)... On any system
where it didn't fail so, I'd expect the seg-fault... It's the only other
rational choice...

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 21, 2005 17:12 UTC (Wed) by hppnq (guest, #14462) [Link]

Alright, common sense rules. ;-) Cheers Rob!

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 21, 2005 15:04 UTC (Wed) by ratz (guest, #32588) [Link] (7 responses)

Generally:
These are very basic things one has to know when doing network
programming in general. Doing system programming and not handling every
return invariant is simply an assured way of giving you long debugging
nights. Read the man pages on how to handle errors or use a library if
you're not too seasoned a programmer. This is actually what I would
recommend to junior network programmers: use a library if you are serious
about writing a networking application.

Unless you are writing applications for fun there is the very important
aspect of performance which contains its own spectre of subtle pitfalls.
I mean not being able to solve an EADDRINUSE clearly shows that the
programmer did not even know of socket(7) and should thus maybe try to
write his application using one of the "dozens" of networking libraries
floating the network. Then of course there is the "pitfall" of not
knowing the appropriate system calls when it comes to performance:
facilities like epoll(4), sendfile(2) or others.

Documentation:
It's almost imperative to have the full Stevens' series books ready when
doing any serious socket programming. At least TCP Illustrated, Vol I and
III. A series of books not often referred to but in my opinion pretty
good are the "Internetworking with TCP/IP series by Douglas E. Comer &
David L. Stevens" Then of course it's very important to know the
appropriate man pages because (unfortunately) socket programming under
Linux can heavily diverge from other OS' socket programming and the
article's focus was Linux sockets programming. socket(7), ip(7) and the
reference man pages in those pages should be consulted.

Debugging:
Regarding tools for debugging your session, _please_ for heaven's sake do
not use the much depreciated (granted, only in the Linux world) tools
like: ifconfig, route and netstat. Please acquaint yourself with the
iproute2 architecture and its tools meanwhile provided by almost every
Linux distribution, such as:

1. ip (as a superset of ifconfig and route)
2. ss (as the socket information tool)

The other tools are not working correctly (race conditions because of
reading proc-fs instead of using netlink) and do not display the correct
information (ifconfig still tells its users that a secondary IP is an
interface for example).

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 21, 2005 15:21 UTC (Wed) by RobSeace (subscriber, #4435) [Link] (5 responses)

> It's almost imperative to have the full Stevens' series books ready when
> doing any serious socket programming. At least TCP Illustrated, Vol I and
> III.

The "TCP/IP Illustrated" books are wonderful, but they are more useful for
understanding the guts of how TCP/IP works at a low level... For actual
sockets coding, I think the most useful Stevens' book (in fact, the most
useful book, period) is "Unix Network Programming"... (Now, actually, a
2-volume set, with the modern second edition... The version I learnt from
in college was a single volume... With the modern one, really only the
first volume is necessary for sockets coding...)

> Then of course it's very important to know the appropriate man pages
> because (unfortunately) socket programming under Linux can heavily
> diverge from other OS' socket programming

Nah, not really... Certainly not any more than any other Unix-like OS
does, anyway... They all have their own little quirks and system-specific
additions and tweaks... But, the core stuff is pretty portable to them
all... (Oh, and I wouldn't trust man pages too much, either... I've been
lied to by them more than once... ;-) But, they're certainly worth
consulting... Just don't blindly believe everything you read there... ;-))

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 22, 2005 0:33 UTC (Thu) by ratz (guest, #32588) [Link] (4 responses)

>The "TCP/IP Illustrated" books are wonderful, but they are more useful for
>understanding the guts of how TCP/IP works at a low level... For actual
>sockets coding, I think the most useful Stevens' book (in fact, the most
>useful book, period) is "Unix Network Programming"... (Now, actually, a
>2-volume set, with the modern second edition...

Yes, I forgot to add this one while editing the text. This certainly is
an excellent reference. This reminds me that I should re-organise my
bookshelf and group all Stevens books back together.

>The version I learnt from
>in college was a single volume... With the modern one, really only the
>first volume is necessary for sockets coding...)

[...]

>Nah, not really... Certainly not any more than any other Unix-like OS
>does, anyway...

For basic stuff agreed (after all the socket interface in Linux is
claimed to be POSIX compatible), but there are things that require you
to read either sys/socket.h and the other headers from there or the kernel
code. I don't have many examples ready, but consider a simple thing like
the backlog queue size (settable in the listen() call for example) and
mechansim. The implementation differs on a lot of Unices and its derivates.

> They all have their own little quirks and system-specific
>additions and tweaks... But, the core stuff is pretty portable to them
>all... (Oh, and I wouldn't trust man pages too much, either... I've been
>lied to by them more than once... ;-) But, they're certainly worth
>consulting... Just don't blindly believe everything you read there... ;-))

I know :). Had a couple of beers with the author(s) already but this
didn't help much. Every once in a while someone shows up on netdev ml
and proposes to address the man page issues, and then they vanish forever.

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 22, 2005 10:45 UTC (Thu) by RobSeace (subscriber, #4435) [Link] (3 responses)

> I don't have many examples ready, but consider a simple thing like
> the backlog queue size (settable in the listen() call for example) and
> mechansim. The implementation differs on a lot of Unices and its derivates.

Yes, and that's sort of what I was saying: Linux is no more different in this area than any other Unix-like system is... There is no "standard" interpretation of what the listen() backlog truly means, and so every Unix-like system does things a little bit different... But, this is to be expected, and no one should really assume one behavior or another, since it's a well-known sockets portability issue... (In fact, there's rarely any use for passing anything other than SOMAXCONN as the listen() backlog, and letting the system give you however much it can in whatever way it wants to... Though, I'm an admin over at The Unix Socket FAQ Forum, and it seems every so often, someone will stop by complaining that a listen() backlog of 1 isn't working like they thought it should, and is allowing more than 1 client to queue up... I have no idea why people try to do such a strange thing in the first place, but it seems a fairly common desire, I guess... But, it's their expectations that are wrong, not any particular behavior of listen()... Though, this is another area where man pages don't exactly help the situation much, since they generally all say something like "The backlog parameter defines the maximum length the queue of pending connections may grow to.", without mentioning any of the controversy over just WTF that actually means... ;-) Is it the completed but unaccepted queue, or the incomplete connection queue, or the sum of both of them? Is the given backlog taken literally as the max, or is it bounded by some internal limits, or is it modified by some internal calculation to increase its value above what you actually specified? Who knows! ;-))

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 22, 2005 16:48 UTC (Thu) by ratz (guest, #32588) [Link] (2 responses)

>Yes, and that's sort of what I was saying: Linux is no more
> different in this area than any other Unix-like system
> is... There is no "standard" interpretation of what the
> listen() backlog truly means, and so every Unix-like system
> does things a little bit different...

Yes, I think we have an accord ;).

>But, this is to be expected, and no one should really assume
> one behavior or another, since it's a well-known sockets
> portability issue... (In fact, there's rarely any use for
> passing anything other than SOMAXCONN as the listen() backlog,
> and letting the system give you however much it can in whatever
> way it wants to...

Clearly, but SOMAXCONN is (was at least in the 90s) different on
each system. BSD even used to set it to 5, HP/UX to 20.

>Though, I'm an admin over at The Unix Socket
>FAQ Forum, and it seems every so often, someone will stop by
> complaining that a listen() backlog of 1 isn't working like
> they thought it should, and is allowing more than 1 client to
> queue up... I have no idea why people try to do such a strange
> thing in the first place, but it seems a fairly common desire,
> I guess... But, it's their expectations that are wrong, not any
>particular behavior of listen()...

Exactly and as you've mentioned above, people come over to your Forum
and ask "silly" questions like this. And I bet you most of them haven't
even ported it yet to another OS. If you check out the source code of
the sockets implementation of portable languages (provided you get access
to), like java for example you'll notice some couple of hundreds of lines
extra just to make a POSIX standard API platform independant.

> Though, this is another
> area where man pages don't exactly help the situation much, since
> they generally all say something like "The backlog parameter
> defines the maximum length the queue of pending connections may
> grow to.", without mentioning any of the controversy over just WTF
> that actually means... ;-)

This is just the tip of the iceberg, as not always and not in all
incarnations of Unix derivates did this backlog parameter really mean
pending connections; or people didn't define pending connections clearly
from the kernel point of view. For a fun read I suggest following list
documents which kind of point out the mess that is/was actually present:

http://www.opengroup.org/onlinepubs/009695399/functions/l...
http://docs.hp.com/en/B2355-90130/listen.2.html
http://snafu.freedom.org/linux2.2/netman/listen.2.txt
http://lists.gnu.org/archive/html/hurd-devel/2001-06/msg0...
a current listen(2) page on a recent Linux distribution

- return values not being the same
- SOMAXCONN being on different values
- backlog queue of 0 has different semantics
- backlog queue generally has slightely different semantics
- pre BSD4.4 aera structures being really incompatible
- internal representation of struct types not equal (minor, but still)

Granted, not for all socket types; but still ...

>Is it the completed but unaccepted queue, or the incomplete connection
> queue, or the sum of both of them? Is the given backlog taken literally
> as the max, or is it bounded by some internal limits, or is it modified
> by some internal calculation to increase its value above what you
> actually specified? Who knows! ;-))

The kernel does and to make things worse, under Linux for example the
semantics and pragmatics also depend on other sysctrl variables, such as
the lovely^Wdeadly syn cookie feature. Check out the following piece of gem
(excerpt from ../net/ipv4/tcp_ipv4.c:tcp_v4_conn_request):

http://lxr.linux.no/source/net/ipv4/tcp_ipv4.c#L1426

... down to line 1524.

The exercise of explaining the semantics of the backlog queue
implementation with all invariants under the Linux 2.6.x kernel is left
to the reader. Hint: There are sockets and mini sockets in the kernel,
otherwise: Good luck! ;).

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 22, 2005 18:27 UTC (Thu) by RobSeace (subscriber, #4435) [Link] (1 responses)

> Clearly, but SOMAXCONN is (was at least in the 90s) different on
> each system. BSD even used to set it to 5, HP/UX to 20.

Yes, but what I'm saying is that, in general, you probably really just
shouldn't CARE what the value is... Simply use SOMAXCONN, and let the
system give you the largest listen queue it can, and simply don't concern
yourself with HOW large that is exactly... I can think of very few
reasons one would want to use a smaller listen queue than the maximum
one supported by the system... (And, if you WANT to, well you're pretty
much out of luck anyway, given all of the differences among the systems,
which means you can't really reliably pin the queue(s) to any specific
desired size, short of hacking your kernel code... So, you might as well
not even try for anything less than the max... ;-))

> If you check out the source code of the sockets implementation of
> portable languages (provided you get access to), like java for example
> you'll notice some couple of hundreds of lines extra just to make a
> POSIX standard API platform independant.

Yep... But, that's usually mostly because they want to support some
system-specific features, which aren't standardized... (And, sockets were
only fairly recently standardized, anyway... They've been defacto standard
for many, many years, of course, but POSIX didn't weigh in on them until a
few years or so ago, I think... And, you know, I almost wish they HADN'T
weighed in, because some of the nonsense they came up with (like "socklen_t")
we were better off without... ;-))

This phenomenon is hardly limited to sockets, either... Look at nearly
any reasonably-sized piece of code which has been ported to more than one
system, and it's almost guaranteed to be littered with tons of #ifdef'd
system-specific code... I mean, why do you think things like autoconf
have to exist at all? Because, while Unices are all "sort of alike", they
all also have tons of pesky little differences, which makes portability a
real pain sometimes... ;-)

Oh, and I love the properly ambiguous language in that Open Group listen()
man page you link to... I wish all man pages incorporated that same level
of ambiguity about the backlog, and then maybe people wouldn't be surprised
by any unexpected behavior... ;-)

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 22, 2005 19:29 UTC (Thu) by ratz (guest, #32588) [Link]

>Yes, but what I'm saying is that, in general, you probably really just
>shouldn't CARE what the value is... Simply use SOMAXCONN, and let the
>system give you the largest listen queue it can, and simply don't concern
>yourself with HOW large that is exactly... I can think of very few
>reasons one would want to use a smaller listen queue than the maximum
>one supported by the system... (And, if you WANT to, well you're pretty
>much out of luck anyway, given all of the differences among the systems,
>which means you can't really reliably pin the queue(s) to any specific
>desired size, short of hacking your kernel code... So, you might as well
>not even try for anything less than the max... ;-))

Boy, am I glad we have this backlog queue, otherwise it would be so
boring and we could use the time to develop really useful things :).
BTW, I agree completely with all you say. I stand corrected and accept
that socket programming under Linux does not heavily diverge from other
OS' socket programming as I mistakenly stated. To me it always was really
messy and none of the original author's pitfalls really bit me, whereas
stuff like we're discussing now certainly did.

>This phenomenon is hardly limited to sockets, either... Look at nearly
>any reasonably-sized piece of code which has been ported to more than one
>system, and it's almost guaranteed to be littered with tons of #ifdef'd
>system-specific code... I mean, why do you think things like autoconf
>have to exist at all? Because, while Unices are all "sort of alike", they
>all also have tons of pesky little differences, which makes portability a
>real pain sometimes... ;-)

;) there's no support for Plan9 though; and depite what Mr. Pike wants
to make us believe, Plan9 also does make use of #ifdef's.

The listen prototype is as follows (from Plan9 Programmer's Manual, 3rd
edition):

int listen(char *dir, char *ldir)

"listen returns an open file descriptor for the ctl file and fills ldir
with the path of the protocol directory for the received connection. It is
passed dir from the announcement." See, no backlog queue :).

>Oh, and I love the properly ambiguous language in that Open Group listen()
>man page you link to... I wish all man pages incorporated that same level
>of ambiguity about the backlog, and then maybe people wouldn't be
>surprised by any unexpected behavior... ;-)

Hey, it's says under RATIONALE: None. So don't complain :).

And the result of such ambiguity is presented in the fuits of different
implementations and following, the different man pages.

Five Pitfalls of Linux Sockets Programming (developerWorks)

Posted Sep 21, 2005 19:38 UTC (Wed) by nix (subscriber, #2304) [Link]

I second the use of ip and ss. There are so many things you simply <i>cannot</i> do if you stick to using ifconfig and route to set up interfaces; often people think as a result that these things are not doable.
They're wrong.

Cure worse than disease?

Posted Feb 17, 2007 6:42 UTC (Sat) by ldo (guest, #40946) [Link]

I'm not so sure that SO_REUSEADDR is a good idea. That TIME_WAIT state is there for a reason, and overriding it can lead to exactly the sort of situation it was designed to prevent.

My preferred solution, when I get an EADDRINUSE error when one of my server processes starts up, is to keep running anyway, and simply retry the bind every 60 seconds until it succeeds.