Mongrel2's ZMQ protocol was designed for lightweight messages against async handlers. Instead of a synchronous ZMQ REQ/REP pair that this nginx module uses, Mongrel2 used a combination PUSH/PULL sockets to send the request, and PUB/SUB to get a response.

Say you want to map /chat to a handler. Mongrel2 opens a PUSH socket, and a SUB socket connecting to one or more chat handlers. The handlers open a PULL and PUB socket. Mongrel2 will spread requests to /chat across the available handlers, and receive all published responses. It's a pretty smart way to handle multiple handlers receiving requests at the same time. It's been a while since I looked at Mongrel2, so it's very possible I have some of the details wrong...

I was one of the first committers on Mongrel2 (actually, second behind Zed) and I still am (though mostly as a historical accident, I haven't contributed anything of substance since SSL).

In my opinion, this is great. I think Mongrel2 is an excellent proof-of-concept, and if it provided the impetus for a much more widely used project like nginx to go down a similar path (though it's just a module right now), then everyone wins.

That said, this certainly isn't in nginx mainline, and it's very feature poor as compared to Mongrel2. One could not simply swap in nginx with this module for an existing Mongrel2 installation.

From what I understand, core Nginx decided that supporting ZeroMQ was a non-starter because of the threading model that ZeroMQ uses. I'm not sure if that's just not true anymore, or if the restrictions that this new module places on it (namely, exclusively REQ/REP pairs) make that not apply.

I'm not sure how well adopted mongrel2 has been. There ain't many commits by Zed these days and I don't see blog posts about using it. I don't know why though.

> How is this different than Mongrel2?

It has nothing in common with Mongrel2 other than the fact that both use ZeroMQ transport instead of TCP.