

Nginx 0mq transport layer for communicating with upstream servers - wlll
https://github.com/FRiCKLE/ngx_zeromq

======
alberth
How is this different than Mongrel2?

Wasn't Mongrel2 created solely because NGINX didn't support ZeroMQ.

@ZedShaw, thoughts - comments?

~~~
alexgartrell
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.

~~~
piotrSikora
> it's very feature poor as compared to Mongrel2. One could not simply swap in
> nginx with this module for an existing Mongrel2 installation.

That's because this is _transport_module_ and what Zed did with Mongrel2 is
build a level 7 protocol on top of ZeroMQ messages.

Even if this would support PUSH/PULL + PUB/SUB sockets right now, you would
still need an _upstream_module_ that understands Mongrel2's level 7 protocol.

~~~
piotrSikora
Head's up, I've started working on both:

\- PUSH/PULL + PUB/SUB support for ngx_zeromq (transport module),

\- ngx_mongrel2 (upstream module).

Should be ready sometime next week.

------
andrewvc
Cool stuff, but I'm wondering why they went with REP/REQ instead of
ROUTER/DEALER. That would dramatically reduce the number of file descriptors
needed (indeed, a single socket could handle any number of backends /
requests).

Also, the fact that ZMQ is message, not stream, oriented makes it non-ideal
here. You get the whole response in one big chunk. Across an internal network,
this may not be a _huge_ deal, but it's not a desirable property.

It's conceivable that a variant that broke responses up into discrete messages
might be better, but this would have more complication in implementation, and
I wonder how much it'd have to offer over straight HTTP.

Also, I wonder if the true ideal protocol for this is SPDY without SSL. It
just seems like a no-brainer.

~~~
JoshTriplett
> Also, I wonder if the true ideal protocol for this is SPDY without SSL.

SPDY does not exist without SSL, nor will it.

Also, SSL does not add anywhere near enough overhead to matter for this kind
of application, especially when you just leave the connection established.
SPDY would work quite well as a protocol for this purpose.

~~~
re
> SPDY does not exist without SSL, nor will it.

Can you elaborate on this, or provide a link with more context? Almost all
TLS/NPN references are missing from the current SPDY draft spec. (I've found
webpages that repeat the SSL requirement assertion, but none that source it or
explain why.)

~~~
JoshTriplett
The SPDY draft spec doesn't seem to include any of the encryption bits; I
don't know why. I've read documents explaining the details before (as well as
expressing very strong opinions about the (lack of) merit of a modern protocol
supporting a non-encrypted mode), but I can't seem to find them at the moment.

As far as I know, SPDY's protocol always builds on an SSL session, not a raw
socket connection. Opportunistic SPDY connections to HTTP servers rely
entirely on SSL "next protocol negotiation" (NPN); a SPDY server will indicate
that it supports SPDY to an HTTPS client via NPN. SPDY also uses SSL to avoid
interference from proxies that would otherwise break attempts to use SPDY on
what started out looking like an HTTP connection.

------
splitrocket
I've used frickle's ngx_cache_purge in production for over a year: it is rock
solid. I'm looking forward to finding a use for this plugin!

thanks!

------
njharman
Why? Is it faster, more robust, something, anything????

~~~
piotrSikora
Proof-of-concept, nothing else at this point.

