My company is attempting to set up a pub/sub connection using RabbitMQ and sockjs, on Windows servers. I have two questions:

  1. My supervisor is calling this setup a comet solution, I was wondering if that is the right terminology?

  2. 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)?

  • Hello and welcome! Please don't post the same question in multiple sites, we can move questions between sites automatically. I've asked an SE employee to delete the Stack Overflow version of the question. – yannis Aug 2 '12 at 23:59
  • As for your question, it's a bit broad, generally speaking we prefer one question per question. I've removed the third part, about having multiple RabbitMQ servers running concurrently, as I felt it was the least relevant of the three distinct questions. You can ask it as a separate question if you want, although it reads like a documentation question, and you should do some research on it on your own before asking. You can review my edits in the question's revision history, and rollback if you disagree with them. – yannis Aug 3 '12 at 0:13
  • The changes are fine. I've read through most of the rabbitMQ documentation and I still don't know the answer. I don't really know what the requirements for having concurrent servers is. I guess that's what my question should of been about, so that I could of seen what I'd missed. – AlexLordThorsen Aug 3 '12 at 4:48
  • If you did do the research, feel free to ask a separate question about having multiple RabbitMQ servers running concurrently. The one question per question mantra helps keeping answers focused and to the point. – yannis Aug 3 '12 at 8:56
  1. 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.

  2. 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.

  • We do have to worry about IE7, about 10% of our base still uses it. Thank you for the clarification. – AlexLordThorsen Aug 3 '12 at 17:00

'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
  • I believe we're going to take the comet approach. The number of open connections shouldn't be an issue. The dropped and timeout issues will be a problem. – AlexLordThorsen Aug 3 '12 at 17:04
  • Just keep in mind that with an off-the-shelf web server such as apache or nginx, the number of simultaneous connections is a significant performance factor; apache for example uses one worker thread per request, so 1000 waiting requests means 1000 sleeping threads. – tdammers Aug 4 '12 at 12:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.