I want to setup a comet/web-socket server for a forum sitting in front of a message queue i.e. rabbitmq, that will maintain client connections and update them about relevant events (i.e. new posts, topics, etc.)
The popular way to go about this is to use some async server that does this in one thread and hands off the blocking tasks to other worker threads. My question is, should this async update-server be on the same physical server as the website? In other words, the task of maintaining client connections and updating them as needed should be separated from the task of creating and returning dynamic web-pages right? Should they be on the same server or separated completely?
The criteria for evaluating the decision is performance and ease of scalability.
Also, this question isn’t about what specific platforms to use. I’m asking about the general practice of seperating concerns: Serving dynamic webpages vs updates; when is it best to place them together and when is it best to seperate them? (physically on the server as well as in code base)
8
You could use NodeJS and the node package module Socket.io for this. Separating the tasks of client connections and creating/returning dynamic web pages into node modules could work the way you described. Node describes their modules in their API docs.
The book NodeJS in Action has some projects that perform similar functionality (even the basic ChatApp in Chapter two performs this to some degree.
2
I use https://github.com/centrifugal/centrifuge, it is a standalone application that uses websockets and falls back to long polling if that fails. Unlike centrifuge, I had lots of issues with comet with high volumes, it did not scale well for various reasons.
Centrifuge even has a dockerfile so you could literally spin up the server on a server in a few seconds. Your web front end requires a tiny bit of javascript and server side is also really simple to push messages to
5