Hacker News new | comments | show | ask | jobs | submit login

Hey, we (Dotcloud now Docker) have used zeromq a LOT in the past. The entire Dotcloud platform is based on Zerorpc (http://github.com/dotcloud/zerorpc) which is based on ZMQ.

Libchan is the spiritual child of zerorpc, so it is definitely informed by our experience using zeromq. The main experience was: it's awesome but does too much, too low in the stack, and it's too much of a black box to remove the parts we don't need.

Also, the inability to safely expose it on the public internet was a big problem. I know this has been addressed since then, but we don't want to use a separate protocol stack for that: we want to use the existing HTTP (soon HTTP2) and TLS middleware infrastructure. That's why libchan uses spdy/tls as its main network transport.

I think a more detailed writeup on the issues you had, and the rationale behind the choices for libchan, would be fascinating, if you ever have the chance. :-)

I agree. the summary still sounds like a NIH. Details would be awesome. blog post it, HN the blog post, you guys know how to do that I heard ;)


> That's why libchan uses spdy/tls as its main network transport.

Just as forecast by many on HN, HTTP is becoming the network layer.

spdy+tls is not HTTP! They're building blocks on which you can write protocols that expect some interesting properties (auth, session, multiplexing, bidirectionality,...).

You must be referring to HTTP2, which is indeed HTTP1+SPDY+TLS in one single protocol. Actually, if SPDY catches on and is used for other uses (I already know muxado [0] that uses a SPDY-based protocol to multiplex requests/responses between client and servers) so that it lives by itself, it will be funny to see if HTTP2 really embeds it (and therefore duplicating the work).

[0] https://github.com/inconshreveable/muxado/

Apparently Armon built one too a few weeks ago [1]

I think I'd like to move muxado in a direction where it provides the common interface to the various stream multiplexers. That way you could code against a common interface and swap out http2/spdy/muxado/yamux as the implementation to suit your performance needs.

I'd also like to see libchan use this common interface as a layer built on top of this primitive.

[1] https://github.com/hashicorp/yamux

> Also, the inability to safely expose it on the public internet was a big problem.

Deus, why? Why on Earth would parts of your critical internal infrastructure be exposed to the public Internet?!

Who said anything about "internal"? We want every piece of our infrastructure to use a common, unified communication layer. If parts of it should be authenticated, tunneled, throttled or otherwise protected from nefarious outsiders, then we want to add the appropriate off-the-shelf middleware, or possibly write our own middleware. It makes no sense, in my mind, to artificially separate "internal" and "external" by implementing completely different protocol stacks and tools. In the end this hurts security because everything gets more complicated and you lose visibility.

Just my 2c based on our own production experience.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact