Server socket: how to limit the number of connections? - Unix

This is a discussion on Server socket: how to limit the number of connections? - Unix ; Alan McKenney writes: > On Apr 16, 6:56 pm, David Schwartz wrote: [...] >> 1) You may be unable to re-open the port unless you set the address re- >> usable. Even if you do, another process might grab the ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 24 of 24

Thread: Server socket: how to limit the number of connections?

  1. Re: Server socket: how to limit the number of connections?

    Alan McKenney writes:
    > On Apr 16, 6:56 pm, David Schwartz wrote:


    [...]

    >> 1) You may be unable to re-open the port unless you set the address re-
    >> usable. Even if you do, another process might grab the port.
    >> (Especially if it's inside the range of dynamic ports.) This is
    >> especially bad for servers that choose a random port on startup and
    >> 'advertise' that port.

    >
    > a. Thanks for the reminder about "reusable." I don't fully
    > understand what it does, but I'm re-engineering existing code which has
    > it all over the place, so I'm putting it in the new code.


    After a TCP connection has been closed, the connection state in the
    kernel goes to TIME_WAIT and stays there for two times the 'maximum
    segment lifetime', to ensure that segments still in the network
    (so-called 'wandering duplicates') have either been received while a
    record of the (old) connection still exists or (should) have been
    dropped by whatever router was holding them when their lifetime was
    over. Because of this, the port associated with this connection is
    still considered to be in use and attempts to again bind to it before
    the TIME_WAIT time has passed will result in an error, except if
    SO_REUSEADDR is used.

    The simple rule is that a server process which always listens on the
    same port should always use this option.

  2. Re: Server socket: how to limit the number of connections?

    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

  3. When to use SO_REUSEADDR (Was: Server socket: how to limit the numberof connections?)

    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?


  4. Re: When to use SO_REUSEADDR

    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.

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2