On Aug 27, 5:27 am, ngocdaothanh <
ngocdaoth...@gmail.com> wrote:
> As I understand Comet and normal HTTP requests/responses are the same.
> The only different is that for normal requests the app should respond
> as quick as possible and for Comet requests the app can delay.
Not really. Let me illustrate this with an example:
Imagine you need to create a real-time chat application between two
people over HTTP. This is a more complex problem than it might seem.
Your first problem is that RFC 2616 says that clients should maintain
only 2 simultaneous connections to HTTP servers. This probably isn't
enough, especially if a user opens up your application in more than
one browser tab. To get around this, you'll need to have a DNS entry
for wildcard subdomains, and then add some Javascript to ensure you
connect to "<random-string>.
yoursite.com". Browsers will treat each
subdomain as a separate server.
Your next problem is maintaining a reliable stream of data. Say you
use a long-polling XHR; each time you receive data, or each time the
XHR times out, you need to disconnect, then reconnect. You need to
ensure that you're not missing any data that is sent during the times
you are not connected, so you need to mark each message with a
incremental sequence number. When the client connects to the server,
it passes the sequence number of the last message it received as a
parameter. The server then passes back any message with a greater
sequence number. This means you'll need a message stack for your
server.
Next, you need to handle disconnections. There isn't any reliable
cross-browser way to inform a server of a closing browser, so you'll
need to create a timeout of how long you'll wait for clients to send a
request before they're considered "disconnected".
Okay, so now you've got a fairly reliable message stream set up. This
requires a fair bit of Javascript and server-side code. But we're not
done yet! Most web servers open up a thread per request, and this will
limit the number of simultaneous users you can support to a few
thousand per server. To improve this, you'll need to use something
like java.nio to make use of low-level OS networking constructs like
selectors.
So my point is that a library designed to serve web pages and
resources, like Compojure, is an entirely different beast to a
streaming network library that happens to use HTTP as a carrier. In
Compojure, you might write something like this:
(defroutes documents
(GET "/document/:id"
(render-document
(headers "accept")
(params :id)))
But in a comet library, you're probably going to be writing something
like this:
(add-listener "/users/connect"
(fn [client message]
(if-let [channel (get-channel (message :channel))]
(if-let [user (get-user client)]
(send-to channel {:type :announce,
:mesg (str (user :login) " joined")})))))
In essense, a good web framework is about resource defining. A good
comet framework is about event handling. Two entirely different
paradigms that really need two separate libraries.
- James