Design / Architecture: One Socket and Multiple Connections Web Socket

Question

During the design of the client / server architecture, is there any advantage for multiplexing several WEBSOCKET connections from the same process to the server (i.e. sharing the same connection) versus opening one WEBSKETET connection per thread / session in the client (as is usually performed when connected to memcached servers or database servers.)

I am aware of the overhead associated with each connection (e.g. RAM ...). But expect that on each side of the client there will be less than 1K-10K.

---

Specific use case: Suppose I have a remote server with several sessions on one side, and on the other hand I have several clients, each client will connect to another session through a web server server. There are two ways to implement it on the remote server: (1) each session creates its own connection to the web connection (2), all sessions will use the same connection to the websites.

In terms of connectivity, I like the sharing solution (one connection to a web connection to all sessions), because the websocket server is limited to # available connections (server storage / scaling).

But in terms of speed / performance, traffic / performance, if the sessions will send many small packets through the connection, then if we use one joint connection, we will not be able to use the bandwidth (payload .... / collect several small packets into one or split a large packet into small packets), because we may have to send different packets to different clients from different sessions, in this case we will not be able to collect several packets (small packets) since they have different destinations and from different sources !!, unless we create a "virtual link", which manages information of each session to maximize the speed, but it would hamper the implementation !!!

Any other opinions?

Thanks, JB.

Answer 1

I think you should consider using a pool of limited connections, as in the database connection architecture.

Another solution that I would consider is a Pub / Sub database broker such as Redis. This allows you to use existing solutions, and also simplifies scaling.

As far as I understand, both having a single connection and using many connections have their own problems.

For example, one connection can send only one message at a time. A large enough message can block the connection ... are you moving big data?

Many connections can cause overhead, which can be very expensive, and also increase the likelihood of errors. Consider the following:

• Creating new connections is very expensive, uses bandwidth, suffers from longer network latencies and requires local resources, and this is exactly what allows websites to avoid.

• You will encounter scalability issues. For example, Heroku limits websocket connections to 600 per server, or at least they didn’t do it for long (and I think this is reasonable) ... How do you connect all the servers together to the same data store?

• Remember that each OS has a restriction on open files and that web windows use the I / O architecture (each of them is an “open file”, therefore web sites are a limited resource).

Regarding the speed / performance of traffic / data, this is a server architecture issue ... but I believe that you will see a slight increase in speed with a single connection (or a small connection pool). It is important to remember that there is no need to multitask when you need to send TCP / IP packets.

In addition, with a limited number of connections (even with one connection), you can use the connection function with the OS package, which will allow you to send several websocket frames over one TCP / IP packet (unless you constantly clean the TCP / IP connector). You actually spend more bandwidth on more connections — without even considering the bandwidth used to open every new connection.

Only my 5 cents, we will all think differently, I'm sure.

Good luck