• binding to ephemeral ports?

    From herrmannsfeldt@gmail.com@21:1/5 to All on Thu Apr 13 07:04:04 2017
    What is supposed to happen if a server wants to bind() to a port
    which happens to already be in use by a TCP session?

    Since the TCP session is identified by the quad source address,
    source port, destination address, destination port, that should not
    limit the ability to bind() to that port. But is that what
    really happens on real systems?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robert Wessel@21:1/5 to All on Thu Apr 13 19:24:31 2017
    On Thu, 13 Apr 2017 07:04:04 -0700 (PDT), herrmannsfeldt@gmail.com
    wrote:

    What is supposed to happen if a server wants to bind() to a port
    which happens to already be in use by a TCP session?

    Since the TCP session is identified by the quad source address,
    source port, destination address, destination port, that should not
    limit the ability to bind() to that port. But is that what
    really happens on real systems?


    On most systems, you will only be able to successfully bind to a port
    not otherwise being used. There may be ways to override a bit (SO_REUSEADDRESS/PORT), but those often don't do what you want.

    In general ephemeral ports should be coming out of a different range
    than statically allocated ports, and so should not conflict, OTOH,
    OS's have not been consistent which ranges get assigned to what - old
    Windows, for example, used to use 1025-5000 for ephemeral port, but
    now uses 49152+, as do most *nix).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From herrmannsfeldt@gmail.com@21:1/5 to robert...@yahoo.com on Fri Apr 14 00:16:01 2017
    On Thursday, April 13, 2017 at 5:24:34 PM UTC-7, robert...@yahoo.com wrote:

    (snip, I wrote)
    What is supposed to happen if a server wants to bind() to a port
    which happens to already be in use by a TCP session?

    Since the TCP session is identified by the quad source address,
    source port, destination address, destination port, that should not
    limit the ability to bind() to that port. But is that what
    really happens on real systems?

    On most systems, you will only be able to successfully bind to a port
    not otherwise being used. There may be ways to override a bit (SO_REUSEADDRESS/PORT), but those often don't do what you want.

    Interesting. I was suspecting that it wouldn't cause a conflict,
    but didn't know. It turns out that the question came from someone misunderstanding how their program worked.

    In general ephemeral ports should be coming out of a different range
    than statically allocated ports, and so should not conflict, OTOH,
    OS's have not been consistent which ranges get assigned to what - old Windows, for example, used to use 1025-5000 for ephemeral port, but
    now uses 49152+, as do most *nix).

    Presumably that works unless one host wants many thousands of connections
    to one port on a server. Rare, but not impossible.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrew Gabriel@21:1/5 to herrmannsfeldt@gmail.com on Fri Apr 14 16:55:15 2017
    In article <8118c585-8773-4f9f-8b7e-83ada9a1fdeb@googlegroups.com>,
    herrmannsfeldt@gmail.com writes:
    On Thursday, April 13, 2017 at 5:24:34 PM UTC-7, robert...@yahoo.com wrote:

    (snip, I wrote)
    What is supposed to happen if a server wants to bind() to a port
    which happens to already be in use by a TCP session?

    Since the TCP session is identified by the quad source address,
    source port, destination address, destination port, that should not
    limit the ability to bind() to that port. But is that what
    really happens on real systems?

    On most systems, you will only be able to successfully bind to a port
    not otherwise being used. There may be ways to override a bit
    (SO_REUSEADDRESS/PORT), but those often don't do what you want.

    Interesting. I was suspecting that it wouldn't cause a conflict,
    but didn't know. It turns out that the question came from someone misunderstanding how their program worked.

    In general ephemeral ports should be coming out of a different range
    than statically allocated ports, and so should not conflict, OTOH,
    OS's have not been consistent which ranges get assigned to what - old
    Windows, for example, used to use 1025-5000 for ephemeral port, but
    now uses 49152+, as do most *nix).

    Presumably that works unless one host wants many thousands of connections
    to one port on a server. Rare, but not impossible.

    It comes up when trying to simulate a large connection load from
    the Internet by using just one test system. I've seen several people
    fall over this over the years.

    It was even more of an issue with a r-protocols (rlogin, rsh, rcp)
    where the client's local port number had to be less than 1024, but
    those have gone away nowadays due to poor security.

    --
    Andrew Gabriel
    [email address is not usable -- followup in the newsgroup]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)