You don't understand comet, apparently.

Connection: keep-alive has absolutely zip squat to do with comet. Completely unrelated.

Connection: keep-alive allows you to SEQUENTIALLY multiplex HTTP connections over a single TCP/IP connection versus the HTTP/1.0 common tactic of opening a new TCP/IP connection for each HTTP connection.

Note the sequentially word there: Even with Connection: keep-alive, you can't send another HTTP request over the TCP/IP connection until the previous one is -COMPLETELY DONE-: request has been sent and is completed, and the response is received in full.

COMET on the other hand is something entirely different: COMET is the act of turning the response into an endless bytestream - normally HTTP delivers set chunks of data: e.g. you request for a file: The server already knows what that data (the file content) is beforehand, it just needs to fetch it and toss it down the pipes. Similar stuff happends for e.g. a GWT-RPC query for a db record. That's normal HTTP stuff.

COMET is the twist on this story: Instead of replying, you as a server act like you are overloaded and dead slow, and you don't send any bytes back, you just sit there, waiting. Then you send a little data, not everything, and wait some more. This process is similar to chat rooms - the data you want to send doesn't even exist yet at the time the request was made.

comet is problematic for three reasons:

1. in IE it is extremely hard to check the content-sent-so-far of dynamic connections. For example, the 'responseText' field of an ajax connection (XmlHttpRequest) is empty until the response is done, but comet is all about the response not being done yet.

2. normal web server paradigms are threaded. If you then do the 'waiting for more data' bit as a simple thread freeze, your apache will conk out and overload after serving up only 50 customers, which is piss poor performance, obviously. You really need a non-threaded paradigm, one where your servlet can return from its doGet/doPost method without closing the connection. Jetty with continuations can do it, and a few other web hacks, but e.g. PHP simply cannot do this, period. You must dedicate a whole thread to each comet connection, which doesn't scale at all.

3. Browsers only allow 2 connections per hostname. The nature of a comet connection is to remain open - and an open connection is taking up a full slot. Even with Connection: keep-alive you can't use that connection for other data, as Connection: keep-alive only does stuff once a request is completed, and comet requests take a long time to complete, that's the point of them. This means in practice that an open comet connection + loading some image someplace = no more data for you. a third connection (e.g. an AJAX call) will simply be placed on hold until the image is done loading or the comet connection completes.

4. The web wasn't designed with comet in mind. There is no low-impact 'stream flush' so a web proxy buffering your data somewhere in the middle can mean a comet info packet doesn't arrive on demand, but only when you close down the stream. Lots of intermediary proxies and browsers will simply think you as a server crashed and call timeout, eventhough you didn't crash but were just waiting for e.g. someone in a chat box to say something. The strategies to read out dynamic delayed response connections are generally pretty bad: IE doesn't play ball well, and regardless of that, most solutions involve parsing an ever-growing string, which becomes slower and slower.

The solutions for that last one are legion - one common tactic is to host your images on img.yourserver.com which is considered different. Another tactic is to multiplex all comet traffic on one connection - this is in fact what the name 'comet' really refers to: It's a protocol which multiplexes unrelated 'on-demand/server-push' data streams onto a single data stream. Web server implementations are called 'cometd', and there is one for e.g. Jetty.

cometd is often overkill. However, in your situation, if you really mean delayed response connections for 60 to 80 widgets, it's -exactly- what you need, and nothing else could possibly work, pretty much.

A common tactic that solves a couple of comet problems is to use delayed single packet response connections: The idea is this: Imagine a chatroom. Instead of having a comet connection that keeps sending the text, you as a server only reply with 1 chat line per connection, but you do this in a delayed fashion. For example, let's say I'm the client and I just received the 800th line of the conversation. I now make a server request:

www.webchat.com/someChatRoomName/?idx=801

in other words, I ask for the 801st line.

The web server receives the request and notices that line 801 hasn't been spoken yet; the client is actually up to date. Instead of responding with 'no 801st line', forcing the client to start' polling' you, asking the same request every second, the server does something different: it freezes the connection until someone says something. When someone says something, the server responds with the text, then CLOSES the connection, forcing intermediate proxies to stop buffering and send it on, in the process, and you dodge IE's inability to grant access to data streams in progress. This doesn't solve the 2 connections per host problem though, and it doesn't solve the problem of web servers not designed for this stuff not being capable of handling more than 50ish simultaneous connections.

If you are confused and generally feeling that comet is extremely difficult, YOU ARE RIGHT - it is. Comet is not for the faint of heart. You can do a lot of cool stuff with it though.

On May 7, 6:48 pm, "idan...@gmail.com" <idan...@gmail.com> wrote: