Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.protocols.tcp-ip    |    TCP and IP network protocols.    |    14,669 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 14,293 of 14,669    |
|    Andrew Gabriel to herrmannsfeldt@gmail.com    |
|    Re: binding to ephemeral ports?    |
|    14 Apr 17 16:55:15    |
      From: andrew@cucumber.demon.co.uk              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: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca