Client side technique for Comet
Specifically the questions I am trying to answer are –
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 ?
- When long polling, if there’s no response from the server the
browser will eventually fall into the “request timed out” state. How
- 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.
2 Solutions collect form web for “Client side technique for Comet”
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
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
openevent 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
I agree with @Hersheezy’s answer. Just try again.
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.