Re: haproxy and orbited (COMET server)

> Well, what an awful concept! Had it appeared at the beginning of the web,
> maybe it could have been the subject of an HTTP evolution to 1.2 for instance.
> But now... With all those proxies, anti-virii, firewalls, load balancers...
> does it have any chance to ever work for at least a small bunch of users ?

=> I guess some people hope so. As a web developer I see it as a technology to aid in making your web-application more real-time instead of polling the server in regular intervals. Most implementations have fallbacks to your standard polling model if the client connection will not support the streaming of data.

=> I believe COMET should serve as an optional communication model with your client, which when supported provides a great user-experience, however the application must not rely on it being available.

=> If streaming does not work, there is still some value to have connections held on the server for a minute or two before they time out as it allows the application to trigger an update event which the client can receive even if the connection is ended after each event. Basically a polling model with a long server timeout.

> To be honnest, I would really wish such a concept to succeed, because it would
> help getting rid of all the crappy heavy technologies people are using to build
> slow web sites. You know, the ones which work on their PC when they are alone,
> which enter production without any modification, and which saturate a server
> when the second user connects...

=> Lol. Sounds like you have had some frustrations with this in the past :) I totally agree. Its amazing what passes as "professionally developed" software especially in the PHP language.

> The problem you'll have with haproxy is not to scale to tens of thousands
> of concurrent connections, but to perform content switching on keep-alive
> connections. Haproxy does not support keep-alive (yet, I'm working on trying
> to get basic things working). So anything after the first request is considered
> data and will not be analyzed. That means that even if you push the timeouts
> very far, a client connecting to a server would always remain on that server
> until the connection closes. This will change when keep-alive gets supported,
> but it will not be before a few months from now it seems.

=> What challenges do you foresee with employing a polling model where the server holds the connection until an event occurs or a reasonable timeout (1 or 2 minutes). The client would re-connect after each event thus requiring no keep-alive. Will haproxy drop the connection to the COMET server if it looses the client connection? This would be important to ensure that the COMET server always as an accurate list of connected clients and can notify the application if a triggering event cannot be delivered because a client is not connected.

> Maybe nginx would be able to do that (I don't know all of its features). But
> it's known to scale at least. On the contrary, pound uses threads and will
> exhibit the well-described problems of this model after a few thousands
> connections.
> Depending on the site you're doing that for, maybe you'd want to turn to
> commercial solutions such as Zeus ZXTM which should scale and support
> keep-alive ?

=> At this point I am looking into the practicality of COMET and the possible benefits and challenges. I think I would opt to run the COMET server on a different port for now if I am unable to proxy it. The client could always try and connect on the dedicated port and if it fails it can fall-back to the long-timeout polling or worst case standard polling.

=> I don't necessarily require COMET for streaming data, but rather for near-realtime event notification from server to client.

> I hope this helps at least a little bit, but I'm sorry I'm not very positive
> about the future of such a technology :-/

=> I appreciate the constructive feedback. If I was wanting to be convinced I would talk to a sales rep of a commercial solution :)

Christoph Received on 2008/01/31 23:38