>>151376
65536 per client/server combination.
>why?
Because TCP connections are identified by their 16-bit client port, their 32-bit client IP, their 16-bit server port and their 32-bit server IP. But for one service on one server, obviously the latter two will always be the same.

Obviously, scaling to tens of thousands of connections is not as simple as repeatedly calling connect().

>>151376
>Is it different for UDP?
Yes, because UDP is connectionless and doesn't have server sockets.

>>151379

First of all thanks for your answer.
That's kind of what i thought.
I found this: http://stackoverflow.com/questions/3329641/how-do-multiple-clients-connect-simultaneously-to-one-port-say-80-on-a-server

Basically this is what happens:
1.) On a server, a process is listening on a port. Once it gets a connection, it hands it off to another thread. The communication never hogs the listening port.

2.) Connections are uniquely identified by the OS by the following 5-tuple: (local-IP, local-port, remote-IP, remote-port, protocol). If any element in the tuple is different, then this is a completely independent connection.

3.) When a client connects to a server, it picks a random, unused high-order source port. This way, a single client can have up to ~64k connections to the server for the same destination port.

So a client simply uses another random port instead of 80 and that's why we can have 65536 simultanisously? Is that correct?

But what is the limitation of UDP?
On SO one guy said:
For a stateless protocol (ie UDP), there is no problem because "connections" don't exist - multiple people can send packets to the same port, and their packets will arrive in whatever sequence. Nobody is ever in the "connected" state.

Then another dude says:
There is no relation to state-fullness or statelessness to answer this question

>>151380
>>151380
>So a client simply uses another random port instead of 80 and that's why we can have 65536 simultanisously? Is that correct?
Yup. Maybr 64512, because most OSes won't give user processes ports 1023 and below.

>>151380
>another dude says:
>There is no relation to state-fullness or statelessness to answer this question
This guy's an idiot.

UDP is a stateless protocol, so there's no such thing as a "UDP connection". Most OSes let one process register a UDP "server port" and send all the UDP packets that come in on that port to that process (only), but that's an implementation detail. It's not a real server socket that produces connections like with TCP.

If you're expecting UDP to provide connection or session management for you, you're using it wrong and should be using TCP. Two packets coming from the same host with the same source port can't be assumed to be part of the same connection, because that's not how UDP works.

>>151380
>On a server, a process is listening on a port. Once it gets a connection, it hands it off to another thread. The communication never hogs the listening port.
Thread pools will work for the low-hundreds, but for massive scales, you really want a state machine: one thread keeps track of every single connection, and every time it receives a packet it mutates the appropriate connection. The state machine thread makes no distinction between packets that open new connections, packets that close connections, and packets that send/receive data.

File: 1442062026019.gif (2 MB, 360x265) Image search: [Google]

2 MB, 360x265

>>151384

Alright. Thanks for you help!