On Apr 17, 9:35 am, Alan McKenney wrote:

> This is code we (will) use all over the place.
> At the level I'm working with, the protocol is TCP/IP.
>
> Depending on where it's used, the higher level protocol could
> be anything (mostly protocols we have no control over),
> but the most common is simply a one-way stream of data bytes.
>
> Hence, my preference for "connection refused."

I think that's a huge mistake. The TCP protocol doesn't specify any
way to handle server load and doesn't specify any one right way to
handle it. This should not be handled at the TCP level but at the
level of the protocol layered above TCP.

You should not be trying to "teach" the TCP layer what higher-level
protocols want. Higher-level protocols should implement what they
want, and they should do so *above* the TCP layer.

DS

On Apr 17, 12:46 pm, Rainer Weikusat wrote:
....
> The simple rule is that a server process which always listens on the
> same port should always use this option [SO_REUSEADDR]

The code I'm re-engineering also uses it for stream clients; is it
just a no-op
in this case?

Also, how about the socket you get from "accept()" -- is it good /
bad / useless
to set SO_REUSEADDR on this socket?

Finally, from your description, it sounds like it would be a no-op (or
an error)
to use it for datagram sockets. Am I correct?

Alan McKenney writes:
> On Apr 17, 12:46 pm, Rainer Weikusat wrote:
> ...
>> The simple rule is that a server process which always listens on the
>> same port should always use this option [SO_REUSEADDR]
>
> The code I'm re-engineering also uses it for stream clients; is it
> just a no-op in this case?

It a no-op whenever the socket isn't explicitly bound to some address
by the code. Eg, a FTP client could sensibly use this for an
active mode data connection. For the 'general case' of just creating
the socket and then calling connect on it, it (sh|w)ould be useless.

> Also, how about the socket you get from "accept()" -- is it good /
> bad / useless to set SO_REUSEADDR on this socket?

Completely pointless: The socket returned from accept is already
associated with a fully-specified TCP connection (local ip, local
port, remote ip, remote port).

> Finally, from your description, it sounds like it would be a no-op
> (or an error) to use it for datagram sockets. Am I correct?

This would depend on the protocol. In theory, the answer is 'yes'. In
practice, I happen to know an application (running on the appliances of
my employer) binding a socket to a specific UDP port on Linux 2.4,
which occasionally failed to restart immediatly after it terminated
for some reason with EADDRINUSE. Using SO_REUSEADDR fixed this.