Client side technique for a comet

Question

I am trying to come up with a practical client-side implementation (JavaScript) for Comet. http://en.wikipedia.org/wiki/Comet_(programming )) talks about this theory, but it's hard for me to find an attempt to find an implementation that works. I understand that there are also good requirements for the server, but I'm only interested in its client part.

In particular, the questions I'm trying to answer are

• How to determine in JavaScript that a connection has been successfully created. E.g. if I used the script tag a long polling method and the browser can never reach the server, how do I know?
• With a long poll, if there is no response from the server, the browser ultimately falls into the "requested timeout" state. How did I find this in Javascript and restore a lengthy poll?
• How to ensure that my technique works in browsers? Basically I want to know the right combination of methods (script tag, xhr, etc.) that most browsers cover.

I tried looking for the Comet infrastructure, but every infrastructure I found (CometD, Atmosphere), etc. come with server-side implementation and make the client transaction transparent to the user. However, I am trying to figure out how they reach the client approach. I have my own server implementation and protocol.

Thanks.

Answer 1

Below is information on how my company solves these problems:

1) if you can establish a connection without immediately receiving an error, you must assume that the connection is established. If you did not receive the answer immediately (badly or otherwise), you just need to assume that it works ... does some tough client-side households, so it is important to use sequence identifiers wisely.

2) Just try again right away. Typically, the server shuts down before the client executes and sends an error code informing you that this has happened. Just make sure you use something as reasonable as 20 seconds for your server side polling time.

3) You must switch to a different domain name than other requests to the same office computer and use jsonp. For example, if your page is hosted on example.com, the chat.example.com subdomain usually exists, since most browsers only allow 3 or 4 open connections at the same time with the same domain name. Jsonp is needed due to the same origin policy. In addition to this: test, test, test.

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

Good luck

Answer 2

• If transport is a kind of long survey, you may not know this. I had the same problem when I developed a long polling transport in the JQuery Socket, because the socket object fires an open event when a connection is established. Therefore, I added the rule that the server should respond immediately when the server receives the first request for a lengthy poll to inform the client that the server accepts this request and establishes a connection. For your information, if the first long polling request is not completed at the specified timeout, the socket object fires a close event.

• I agree with @Hersheezy's answer. Try again.

• The test is the answer. The combination of transports is based on the environment of your browser application and server application. For example, if you support IE6 but don’t support cross-domain connections and mobile devices, you don’t need to use a long polling transport. This is enough to use WebSocket, Server-Sent Events and HTTP Streaming events, and if you cannot prepare the WebSocket server, then the events and streams sent by the server will be the correct vehicles.

I am creating a jQuery Socket , which is an agonistic JavaScript library for JavaScript and provides a socket for browser-based applications. Perhaps this would be useful for you. This is currently a preview alpha, and I'm writing a server-side processing document.

Thanks.