Nginx module to turn it into a long-polling message queuing HTTP push server. | Hacker News Reader

Nginx module to turn it into a long-polling message queuing HTTP push server.

github.com

80 pointslabria25 comments

This just creepy. We had a session at the Real-time web summit yesterday where we described needing something like this.

One of the guys from Google named it the "Comet Tornado Reverse HTTP Proxy" because we were talking about adapting Tornado, this look like exactly that.

hey guys, I'm responsible for this frankenstein of a creation. I am 2 bugs away from a release with quite a few essential improvements.

(of course, the bugs in question seem to be concurrency related, so it might take a day or two or more to fix)

Clever suggestions and constructive forks are welcome.

I'm curious how this compares to twisted.web/tornado in terms of use case (friendfeed type sites). Can anyone quickly explain this to me? Thanks!

Tornado is a web framework on its own, it handles the polling and the replies internally. This nginx module is just a helper to the framework behind it. It keeps the connections to the listeners, waiting for the framework to signal it, and then sends the message back to the listeners.

Quick question for any nginx experts: the following config setting:

set $push_channel_id $arg_id; #/?id=239aff3 or somesuch

Means that the ?id= querystring paramater is used as the push channel ID. Any idea if it would be possible to set it up so /channel/12345/ would result in 12345 being set as the push channel ID?

Quite possible - You'd need to use the rewrite module to pass it as an argument. http://wiki.nginx.org/NginxHttpRewriteModule

Maybe something like this...

  location / {
    rewrite  ^/channel/(.+)$ /channel/?id=$1 last;
  }
  
  location /channel/{
    #stuff
    set $push_channel_id $arg_id; #/?id=239aff3 or somesuch
  }

Nice. I hacked something like this into nginx a while back via kestrel but a native module is better by far. Assuming it's up to the high expectations of nginx stability, it's going to further cement nginx as the proxy / lightweight webserver of choice.

Do you work at Twitter? I wasn't aware that anyone was using Kestrel outside of Twitter - Zing!

This is fantastic. EZ-Mode push using a very simple to deploy piece of software.

If I'm reading the docs correctly, you'd have to make a server-side HTTP request from your synchronous app to nginx for each message you want to push to each client. I'm pretty sure that will be prohibitively slow.

It would be much nicer if you could make one server-side request for each event, and have nginx track which clients are interested in that type of event and even queue that event for a while for clients that are yet to connect.

No. You just set the "push_listener_concurrency" setting to "broadcast", and have as many listeners on one channel as you like.

HTTP prohibitively slow? You don't say! :-)

If this does become an issue, it is a tradeoff between speed and memory usage and ease of implementation.

Personally, I prefer Juggernaut (http://juggernaut.rubyforge.org/) for this. Sure, it's Flash, but it just seems like a bit less of a hack than long-polling.

Have you had any problems using this in production? My understanding with using Flash/Java is that all traffic has to be tunneled through port 80 to not interfere with proxy servers. Even then sometimes traffic that doesn't look like HTTP can be blocked. Has this been a problem for you?

http://cometdaily.com/2008/09/30/why-flash-must-adopt-comet/

http://orbited.org/blog/2007/08/juggernaut-is-a-bad-idea/

I'm using it in production since last week, about 50,000 connections / day. For some reason it seems to stop/crash after 24-36hrs without leaving anything in the logs.

I am using it on port 443 (https).

>> "Sure, it's Flash"

.... and there goes half your potential users.

Maybe half of open source linux developers but more like 0.000002% of normal users

iphone? ipod? wii? ds? etc etc?

I'm a systems administrator for a medium sized company. Every single time there is a security hole in flash, computers get infected with a virus. I roll out updates as soon as they're available but with enough people going to enough sites, someone gets hit.

That aside, I also can't run flash on my iphone, or my blackberry.

Javascript on the other hand is supported nativity across the board.

The advantages/disadvantages listed on the juggernaut website seem fishy to me.

  1) it's not hack 

  2) I don't know of js crashing your browser *more* then flash 

  3) Any browser that supports flash supports JS 

  4) You can use http over any port as well

With Comet you get the added benefit (which is small or large depending on your implementation) of http caching and you remove reliance on 3rd party libraries.

Looks like I just rewrote what was previously mentioned in the articles about juggernaut

Nobody asked; Why do you prefer Juggernaut?

Does Google do something like this for their servers for the chat service inside gmail?

I've noticed it can keep http connections open for extremely long times.

http://en.wikipedia.org/wiki/Comet_(programming) is a good ref. Gmail chat does this.

This wiki page covers mostly the frontend part.

The link covers a server side message passing interface.

I just glanced over it (do not use nginx) think it's just a more efficient way for your idle process to know if they need to send anything over the wire or if they can keep idleing.

The nginx module is ideal for heavy frameworks like rails, so that you can handle clients waiting for chat messages (for example) on the web server, and not by the heavy framework dispatchers.

I do use nginx. This uses a "Simplish HTTP Push Relay Protocol". It's a way for your app (via curl or any other http library) to "connect" to your http clients.

It has a few interesting options. "messages" are passed by a "channel id" and you can have any number of long polling listeners on a channel, or you can error out the first or last connections on a channel so there is only one listener at a time. If you have multiple listeners the message becomes a broadcast.

You also have a configurable amount of memory to buffer messages in the event there is no listener on a channel, or the listener is busy (receiving a message I guess). You can also set limits on number of messages per channel and a timeout.

I can see the advantages of this easily. The connections in nginx are much less resource intensive then a rails or php fast-cgi. You'll end up using much less ram. I know python has twisted and there are few others webservers for other languages, but this would allow me to run a php based chat server and take advantage of long polling.

I like it.

Reply on news.ycombinator.com