binding to ephemeral ports?

[h***@gmail.com]

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?

[Robert Wessel]

Post by h***@gmail.com
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).

[h***@gmail.com]

On Thursday, April 13, 2017 at 5:24:34 PM UTC-7, ***@yahoo.com wrote:

(snip, I wrote)

Post by Robert Wessel

Post by h***@gmail.com
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.

Post by Robert Wessel
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.

[Andrew Gabriel]

Post by h***@gmail.com
(snip, I wrote)

Post by Robert Wessel

Post by h***@gmail.com
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.

Post by Robert Wessel
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.