"The TCP protocol provides 16 bits for the port number, and this is interpreted as an unsigned integer; all values are valid, apart from 0, and so the largest port number is (2^16 - 1) or 65,535."

Ah, on the client side not the server, makes sense. I was doing the math as the full IP + port, which would offer 48 bits, but with only one client IP you really only have a client port to play with and you must bind as long as the connection remains open.

but the blog post says different.

> The client side has similar settings but does not need to set up multiple IP addresses, obviously

Also as I know, Linux will only use one IP for outbound connections, unless forcefully bind to another IP address in the code.

The server only uses only one port. 9001 according to the code. https://github.com/uNetworking/uWebSockets.js/blob/875f16e1f...

This blog post does not make any sense.

A connection is identified by the tuple {host IP, host port, client IP, client port}. The server listens on one port, but the client has a separate port for each connection. This means that there can be 65k connections for a single {host IP, client IP} combination.

There's two ways to get more connections: use more client IPs or use more host IPs. In this post the OP has decided to add more host IPs.

That means this benchmark is useless right?

In real world there will be more client IPs and the host will be listening on 1 IPv4 on 1 port.

That would depend on if it matters to the WebSocket server if connections are from one or multiple IPs. In this case I would not think that there's any difference as far as the WS library is concerned. Maybe it has some effect on the OS kernel's networking routines, but I would not expect it to be big.

Port numbers are 2 bytes (16 bits) in the tcp packet header.

so 2 * 16 == 65k

Aren't connections defined by sender_ip+receiver_ip+port?

Usually a connection is defined by what's called a 5-tuple. Source up, source port, dest up, dest port, protocol (e.g. tcp or udp)

Maximum file descriptors