Multiple websocket connections

Question

Is there any advantages of having two distinct websocket connections to the same server from the same client? To me this seems a bad design choice, but is there any reason why/where it should work out better?

Fill

Are the REQUEST_URI also same? – Inversely

@Shiplu Hmm. One shouldn't convey info via uri since it is done only once. In this case, let's say yes. – Fill

Can the close-voter please explain why? Why exactly is my question not constructive? – Fill

Answer 1

There are several reasons why you might want to do that but they probably aren't too common (at least not yet):

• You have both encrypted and unencrypted data that you are sending/receiving (e.g. some of the data is bulky but not sensitive).
• You have both streaming data and latency sensitive data: imagine an interactive game that occasionally has streamed video inside the game. You don't want large media streams to delay receipt of latency sensitive normal game messages.
• You have both textual (e.g. JSON control messages) and binary data (typed arrays or blobs) and don't want to bother with adding your own protocol layer to distinguish since WebSockets already does this for you.
• You have multiple WebSocket sub-protocols (the optional setting after the URI) that you support and the page wants to access more than one (each WebSocket connection is limited to a single sub-protocol).
• You have several different WebSocket services sitting behind the same web server and port. The way the client chooses per connection might depend on URI path, URI scheme (ws or wss), sub-protocol, or perhaps even the first message from client to server.

I'm sure there are other reasons but that's all I can think of off the top of my head.

Firebox

Answer 2

I found that it can make client logic much simpler when you are only subscribing to updates of certain objects being managed by the server. Instead of devising a custom subscription protocol for a single channel, you can just open a socket for each element.

Let's say you obtained a collection of elements via a REST API at

http://myserver/api/some-elements

You could subscribe to updates of a single element using a socket url like this:

ws://myserver/api/some-elements/42/updates

Of course one can argue that this doesn't scale for complex pages. However, for small and simple appications it might make your life a lot easier.

Wellborn

Answer 3

In addition to what kanaka said, there may be another problem. For example, your APP configured this way: every 30 seconds there is a ping-pong of the WebSocket network, based on which the server determines if there is a response from the client. You start uploading a large amount of data over WebSocket, e.g 1Gb, which can take several minutes depending on the internet connection speed. The server sends a ping, the client receives it and sends a pong, but the WebSocket channel is already busy transmitting data. The server does not receive a pong and resets the connection. Data transmission is interrupted.

Therefore, it makes sense to separate WebSocket channels based on their functionality. One should be used for client signaling and system data, for example - how much has already been uploaded to the server, and another one specifically for transmitting large data.

Sharie

Answer 4

You can bundle the web socket connection with some kind of context. Imagine a chat client with two simultaneous chats. The context is the recipient. If you have only one web socket, every message needs to include the recipient. If you have two web sockets you can bundle each web socket with a recipient.

Tampere