What could be the maximum number of concurrent Clients (using different port number) that could communicate to a Server on the same port (Single socket) ? What are the factors that could influence this count ? I am looking for this information w.r.t telnet in Linux environment.

- 36,610
- 17
- 75
- 94

- 605
- 4
- 10
- 15
-
The same question, see https://stackoverflow.com/questions/2332741/what-is-the-theoretical-maximum-number-of-open-tcp-connections-that-a-modern-lin – wow qing Oct 29 '18 at 04:23
3 Answers
This depends in part on your operating system.
There is however no limit on a specific port. There is a limit on the number of concurrent connections however, typically limited by the number of file descriptors the kernel supports (eg 2048).
The thing to remember is that a TCP connection is unique and a connection is a pair of end points (local and remote IP address and port) so it doesn't matter if 1000 connections connect to the same port on a server because the connections are all still unique because the other end is different.
The other limit to be aware of is that a machine can only make about 64K outbound connections or the kernel limit on connections, whichever is lower. That's because port is an unsigned 16 bit number (0-65535) and each outbound connection uses one of those ports.
You can extend this by giving a machine additional IP addresses. Each IP address is another address space of 64K addresses.

- 616,129
- 168
- 910
- 942
-
Another thing to mention is the range of ephemeral port for client side. – Nikolai Fetissov Feb 28 '10 at 04:42
-
On continuing my search , i landed up in the below link w.r.t BSD that gives some good points about kern.maxfiles as each open file, socket, or fifo uses one file descriptor and a large-scale production server may easily require many thousands of file descriptors, depending on the kind and number of services running concurrently - http://www.freebsd.org/doc/handbook/configtuning-kernel-limits.html Doesn't the fast link play a role ? I think, that also plays an important role here. – Karthik Balaguru Feb 28 '10 at 13:09
-
So, it seems that file descriptors is one of the major factor that determines the number of concurrent connections on a particular port in a server in Linux. The below link seems to convey the method to increase the maximum number of file descriptors in Linux - http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/ http://www.cs.uwaterloo.ca/~brecht/servers/openfiles.html – Karthik Balaguru Feb 28 '10 at 13:14
-
1TCP/UDP buffer sizes are another factor not to be overlooked, for performance reason. – Robin Hsu Jan 29 '15 at 03:35
More than you care about. Or rather.
- More than your code can actually handle (for other reasons)
- More than your clients will actually make
- More than you can handle on a single box for performance reasons
- More than you need on a single box because your load balancers will distribute them amongst several for availability reasons anyway
I can guarantee that it is more than all of those. There are scalability limitations with large numbers of sockets, which can be worked around (Google for the c10k problem). In practice it is possible to have more than 10,000 sockets usefully used by a single process under Linux. If you have multiple processes per server, you can increase that up again.
It is not necessary to use a single port, as your dedicated load-balancers will be able to round-robin several ports if needed.
If you are running a service for many 10s of 1000s of client processes, it is probably fairly important that it keeps working, therefore you will need several servers for redunancy ANYWAY. Therefore you won't have a problem deploying a few more servers.

- 62,604
- 14
- 116
- 151
-
1Interesting to know that the load-balancers would be doing round-robin of serveral ports ! – Karthik Balaguru Mar 01 '10 at 07:53
-
One can easily use hundreds of thousands (were they available) sockets on a single system (Linux). Definitely all the available ones. You're making assumptions that are incorrect. – lucian303 May 23 '13 at 01:00
I did a testing on Windows, doing multiple loopback connections onto a single socket. Windows refused to allocate anything after 16372 mark.

- 11
-
6Loopback connections have their own limitations. For one, the client's OS will usually only use ephemeral ports in a certain range (and thus, will only create a given number of them). For another, connections to 127.0.0.1 (the loopback address) will generally use the same source address (namely, 127.0.0.1) for all of them. You'd have to explicitly bind the local end to a different address to work around these limitations. – cHao May 07 '11 at 17:51