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?
Advertisement
Answer
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.