Websockets with ephemeral ports

Question

I am writing a library which will use Websockets to communicate between different processes (and processes running in different languages, and maybe even on different machines). I want to avoid port conflicts with existing servers that might already be running on a machine. I learned a little bit about ephemeral ports, and I am guessing I could use ephemeral ports with Websockets in order to avoid port conflicts.

However, I am having a lot of trouble finding information about whether this is possible. In order to make this worthwhile, I need a Websocket implementation in Python, Go, Java and Node.js which can handle ephemeral ports. The only Websocket implementation I am familiar with is Socket.io in the JavaScript world.

My questions are:

1. Does anyone know if it is possible to use ephemeral ports with socket.io and websockets in general?
2. Can you provide a code sample or a link as how to accomplish this?

Answer 1

A webSocket connection is based on TCP and thus the way a connection uses a port is just like TCP. As such, you have one side initiating the connection (the client) and one side that is listening for incoming connections (the server). In TCP, a connection is established between two IP address/port pairs. So, you have a IP1/port1 connecting to IP2/port2.

The client can use any port it wants for its own port, but it must connect to a specific port on the server where there is a server process listening for incoming connections. You can pick any port not already in use for the server to listen on (though there are port ranges recommended for such use), but that port must be known in advance to the client so the client can connect on that port.

So, the client connects to the server IP on the known port that the server is listening on. The client will be coming from the client IP on some specific client port. The client port would typically be an ephemeral port that was automatically allocated by the underlying TCP stack. This ephemeral port is communicated to the server in the initial connection and is used for directing network traffic coming back to the client to the appropriate socket on the client.

A server would not typically use an ephemeral port and it can't use a dynamically allocated port because then the client wouldn't know what port to connect on.

So, the usual way this is done is for someone who is setting up the server to understand what processes are running on the server and what ports are being used by what and then pick a port in the range intended for server listening that will not conflict and then communicate that to the client, either via a client config file or by just building that port into the client.

If you really wanted a dynamic listening port, you could use a well-known server process and port (such as a web server on port 80) and then craft an http request whose sole purpose was to ask the server what port is being used for your incoming webSocket communication. But, that still requires a well known port number so it probably isn't really saving anything unless port 80 happens to not be in use on the computer and you don't want to use it for your webSocket. Or, if you really wanted to go nuts with this (generally overkill), you could use one of the resource discovery protocols that would allow devices to discover how to connect to one another.

In practice, most people just pick a four digit port number in the range of 2000-9999 that doesn't conflict with any other servers on the same box.

IANA says that ephemeral ports are in the range of 49152 to 65535, though some Linux kernels use 32768 to 61000.

Ports below 1024 require super-user privileges and are usually avoided for non-standard servers.

There's a long list of types of servers and what port numbers they typically use here, though you are unlikely to find many of these processes running on your own server.