Client side technique for Comet

Question

I'm trying to come up with a practical client-side (JavaScript) implementation for Comet. http://en.wikipedia.org/wiki/Comet_(programming)) talks about the theory but I'm having a tough time trying to find an implementation that works. I understand there's a good servers-side requirement here too but I'm only interested in the client-side part of it.

Specifically the questions I am trying to answer are -

1. How do I detect in JavaScript that a connection has been successfully established. For eg. if I were to use the script tag long polling method and the browser could never get to the server, how would I know ?
2. When long polling, if there's no response from the server the browser will eventually fall into the "request timed out" state. How do I detect this in Javascript and re-establish the long poll?
3. How do I ensure my technique works across browsers? Basically I want to know the right mix of methods (script tag, xhr etc.) that would cover most browsers.

I tried looking for Comet frameworks but every framework I found (CometD, Atmosphere) etc. comes with a server-side implementation as well and makes the client-side deal transparent to the user. I'm however trying to find out how they achieve the client-side feat. I have my own server implementation and protocol.

Answer 1

1. If the transport is a kind of long polling, you can't know that. I experienced the same problem when I designed the long polling transport in the jQuery Socket because the socket object fires the open event when a connection is established. So I added a rule that the server has to respond immediately when the server receivies a first long poll request to tell the client that the server accepts this request and establishes a connection. For your information, if the first long poll request is not completed in a specified timeout, the socket object fires the close event.

2. I agree with @Hersheezy's answer. Just try again.

3. Test is the answer. The combination of transports is relying on the enviornment of your browser app and server app. For example, if you will support IE6 but won't support cross-domain connections and mobile devices, you don't need to use the long polling transport. It's enough to use the WebSocket, Server-Sent Events and HTTP Streaming transport, and if you don't afford to prepare a WebSocket server, then proper transports will be the Server-Sent Events and Streaming.

I have been making the jQuery Socket which is a server agonastic JavaScript library and provides a socket for browser-based applications. Maybe this would be helpful to you. Currently, it's pre-alpha version and I'm writing a document covering the server-side processing.

Thanks.

Answer 2

The following is how my company addresses those issues:

1) if you can make a connection without immediately receiving an error, you kinda have to assume that the connection was established. If you don't receive a response immediately (bad or otherwise) you just have to assume that is it working... makes for some tough housekeeping client-side so it is important to use sequence ids intelligently.

2) Just try again right away. Usually the server will time out before the client does and send an error code back telling you that happened. Just make sure to use something reasonable like 20 seconds for your poll time on the server side.

3) You have to be going to a different domain name than other requests to the same service's machine and using jsonp. For example if your page is being hosted from example.com, it is common to have a chat.example.com subdomain since most browsers only allow 3 or 4 open connections at a time to the same domain name. Jsonp is necessary because of the same origin policy. Other than that: test, test, test.

Ryan Dahl (creator of node.js) has a very simple chat client / server implemented here: https://github.com/ry/node_chat

Good luck!!