Separating websocket apps for different website features, any benefits? - websocket

Question

So i have been making a live chat room with my websockets app, using socket.io.
But i also have a secondary feature that requires real time that is unrelated to my live chat feature. So I wanted to know should i run a separate app on a different port ?
Does this provide any technical benefit on performance and scalability ? Or should a website use one app which handles all web socket data.
I'm no expert on servers so i was wondering if there is a correct approach for this on a technical aspect.
Please note: I'm not looking for opinions only factual truths of pros and cons of separating over centralising.
Assuming there is any pros and cons at all. The lack of documentation on alot of websocket frameworks don't really go into much detail on this particular aspect.

Answer 1

WebSocket Apps and Ports
Q: So I wanted to know should i run a separate app on a different port ?
The short answer is yes because unrelated services may expect different growth patterns, so you want to separate the functionality as much as you can so you can deploy one or more services on the same box on different ports.
The longer answer is that you should do this to separate things internally, but it sure would be great if you could let your clients access all your services over ports 80 or 443 - with WebSockets you can use the WebSocket URL to distinguish services and share the same port.
To achieve this, you can introduce a WebSocket gateway application that supports port-sharing. Then your clients can hit port 80 for every WebSocket service, but you utilize different ports for your separate apps.
If your WebSocket gateway application supports port-sharing for WebSockets it means your server accept on the same port with different paths... e.g.
ws://example.com:80/chat_service
ws://example.com:80/unrelated_service
In general to get traffic over the Internet at large it's better to use ports 80 and 443, port-shared if you can, to pierce through any number of intermediary proxies/firewalls along the way.
Q: Does this provide any technical benefit on performance and scalability ? Or should a website use one app which handles all web socket data?
Just like an application server, there is no reason why one WebSocket server should not serve multiple different web applications. If you expect the applications will experience different growth rates, you should separate them into separate web apps, sharing libraries.
For performance, if your applications push a larger amount of data over the WebSocket to the clients, you might want to consider the total network interface traffic of all services to make sure you are not maxing out the bandwidth of the network card. This is independent of your separate port question.
For scalability, if the functionality is unrelated it will be more scalable to keep things separate and share libraries if necessary. This is because you may experience different growth levels for the unrelated services.
Summary
I'd suggest the combination of keeping things simple for clients and scalable for the servers is as the following:
Use a WebSocket gateway that can port-share. All clients can use 80 or 443 with separate paths.
Configure the WebSocket gateway to proxy through to separate apps on separate ports to allow for the servers to scale independently.
+----------+
+------| App:Chat |
+--------+ +---------+ | +----------+
| Client |-----internet------| gateway |------+ (port 8081)
+--------+ +---------+ |
(port80) | +----------+
+------| App:App2 |
+----------+
(port 8082)
Gateway solutions like the Kaazing WebSocket gateway offer this type of functionality and are free for development use up to 50 connections at a time.
(Disclaimer: I used to work for Kaazing as a server engineer).

Answer 2

I don't have a definitive answer for you but two things that may be helpful
1) There is a great book from O'Reilly on browser networking which you can actually read online for free to learn how the series of tubes that we know as the internet actually works. Here is the chapter on WebSockets (which is in the latter portion of the book) http://chimera.labs.oreilly.com/books/1230000000545/ch17.html. I just skimmed this and found a paragraph on multiplexing which seems relevant to your research.
2) One reason that springs to mind for why you may want to have the separate connections is that they act as FIFO queues so if one your 2nd usecase involves large payloads, the chat session would essentially hang while that payload transfers. Surely there are other reasons to go one way or the other though and hopefully someone else can give you a more complete answer.