

DotCloud open-sources its websocket proxy - shykes
http://blog.dotcloud.com/announcing-hipache-dotclouds-open-source-webs

======
wensheng
Haproxy supports websocket. What are the advantages of using Hipache instead
of Haproxy?

~~~
amirmansour
I second this question.

~~~
shykes
To quote the github page [1], Hipache is "a distributed proxy designed to
route high volumes of http and websocket traffic to unusually large numbers of
virtual hosts, in a highly dynamic topology where backends are added and
removed several times per second. It is particularly well-suited for PaaS
(platform-as-a-service) and other environments that are both business-critical
and multi-tenant".

Before building Hipache, dotCloud's network routing layer consisted of a large
number of boxes running nginx, wrapped in a custom instrumentation and
management layer which, among other things, generated configuration files of
mind-boggling size several times per minute and propagated them across a
fairly complex distributed system. If we had used haproxy, we would have had
to adapt that ad-hoc instrumentation layer to haproxy - not a particularly
pleasant prospect. Since dotCloud had reached a scale which mandated a
redesign of the routing layer anyway, we killed two birds with one stone.

<http://github.com/dotcloud/hipache>

------
shykes
Here's the github link: <http://github.com/dotcloud/hipache>

------
beck5
load balancing websockets has been a pain of mine on sharelatex.com and I will
have a good play with this.

However one thing that jumps out at me is the low number of tests. There only
appear to be a few Acceptance tests. For a serious bit of software like a load
balancer I would expect to see a fair few unit tests.

~~~
shykes
Hipache is built on top of node-http-proxy [1], a nodejs library which
implements a lot of the actual websocket logic. Most of the tests you have in
mind are in that library. Hipache implements a management and automation layer
on top of it, and although more tests are always good, in my experience full-
stack integration tests are more important in that context. I am not the
author, but I work at dotCloud and can tell you that Hipache was submitted to
_massive_ amounts of integration testing and load testing before even touching
its first production deployment. Obviously there's a long way to go before
being as battle-tested as squid or nginx, but we're not talking about a week-
end hack project either.

[1] <http://github.com/nodejitsu/node-http-proxy>

~~~
beck5
Thanks for answering. I would still personally prefer to see some unit tests
checking each function behaves as expected, this is not so much to prove that
the thing works now but make sure it can be changed safely over the next few
years so I can pull down the latest version with confidence.

e.g. getBackendFromHostHeader inside worker.js does a lot of things, if I were
the author I would have it wrapped up in unit tests.

