My company is attempting to set up a pub/sub connection using RabbitMQ and sockjs, on Windows servers. I have two questions:
-
My supervisor is calling this setup a comet solution, I was wondering if that is the right terminology?
-
Is there a better solution stack for having a data server asynchronously ship data to a client without the client requesting data (besides the initial subscription)?
4
-
SockJS is a bit more than “Comet”. “Comet” is mostly about polling (like http long-polling). SockJS will use native streaming WebSockets when available. In other words: SockJS will use “proper” Websockets if possible and “comet” otherwise.
-
No. SockJS is probably as good as it can be if you need to support IE6 and IE7 and weird network configurations. If you can limit your supported browsers to IE10, new FF and Chrome, and don’t care about users behind broken proxies using native WebSockets might be an alternative.
As a side note, please take a look at RabbitMQ-Web-Stomp plugin. It might be a useful to an extent.
1
‘Comet’ is an approach that allows simulating push-style network communication over a stateless request-response protocol, typically HTTP. It is a solution to the problem that an HTTP server cannot actively push messages to a client – the only way for the server to get data to the client is to respond to a request.
The comet approach uses ‘long polling’ to achieve data pushes; it works like this:
- client sends request to server, with a very long timeout
- server keeps connection open, but doesn’t respond immediately
- as soon as the server wants to push something, it responds to the pending request
- client, upon receiving and processing the response, immediately sends the next request
If this is what your solution does, then it’s justified to call it a ‘comet’ solution.
The most prominent problem with comet-style communication is that the server must be prepared to keep a massive amount of requests open simultaneously – if you have 1000 users logged into your site, you will have 1000 pending requests, all the time. Also, timeouts and network issues (dropped connections etc.) can make comet solutions quite unreliable.
As for alternatives:
- you can compromise on heartbeat-style short polling (client sends a heartbeat every x seconds, server responds with any available data)
- you can try WebSockets, although browser support isn’t ideal
- you can decide step off the web platform and build a desktop application instead
- you can find a browser plugin that provides asynchronous server-push communication
2