Hacker News Reader

Comment by andrewvc | Hacker News Reader

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.

View on HN

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

ZMQ and ngx_zeromq support multipart messages, so this is only true if your backend sends it as one big chunk.

This is just an initial spike. The conversation started here: https://github.com/chaoslawful/lua-nginx-module/issues/35.

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

> 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.)

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.

Speed aside, maintaining certs for all your backend servers would suck.

> Cool stuff, but I'm wondering why they went with REP/REQ instead of ROUTER/DEALER.

Because this is just proof-of-concept hacked over 2 days (+ README file). It probably wouldn't be even released at this point, if I didn't promise it to @igrigorik.

I'll look into adding other socket types sooner or later.

Reply on news.ycombinator.com