

Websockets zeromq proxying - hogu
https://github.com/hhuuggoo/ZmqWebBridge

======
Loic
If you really want to easily bridge websocket in the front-end with a backend
using ZeroMQ, please take a look at Mongrel2. You get that plus a wonderful
webserver.

Mongrel2: <http://www.mongrel2.org>

~~~
ominous_prime
Mongrel2 has some great ideas behind it, but it just doesn't seem to be able
to generate any momentum in uptake or community "buzz".

I think it may be solving problems which just aren't big enough for most
people to warrant the switch in their technology stack. HTTP proxying and text
config files work "good enough". Maybe everyone else is like me, and waiting
for feedback from some big deployments in order to see how it all works in
practice.

~~~
mvzink
Ironically, your comment just inspired me to try out Mongrel2. Even during its
initial buzz, I never looked into Mongrel2 at all because I simply had no need
for a new web server. Well, after finally looking at it... it looks fricking
sweet and I can't wait to play around with it.

------
a-priori
Interesting idea, but a huge security nightmare. Essentially you're opening
the door for anyone to send and receive arbitrary ZeroMQ messages to any
address via your server, bypassing any outward-facing firewall that might be
in place.

One way to make this a bit less of a nightmare is to give the addresses via a
server name, and have the proxy map that to an address. That way, the
Javascript code can only access specific services known by the proxy.

~~~
hogu
yes, agreed, I provide 2 functions, one which you override to determine
whether a given websocket can connect, and one where you determine whether a
given fake zmq socket can connect. you should definitely override both and set
them to something sane a list of allowed connection sockets, etc... I might
end up making a list of allowed sockets required in the future, or go with
your approach of requiring some mapping of strings -> sockets, so chatservice
-> tcp://127.0.0.1:9001 for example and then teh client must reference
chatservice, rather than tcp://127.0.0.1:9001

------
jrussbowman
Interesting idea. Are you planning on opening up other zeromq protocols like
pub/sub?

The web server could validate the subscription before establishing the
connection. That would be a little easier for setting up control over who has
access to what resources. I suppose you could do this with REQ/REP but PUB/SUB
would simplify the server side implementation.

For my current project I'm using PUSH/PULL with filtering at the server
because it was fewer connections to deal with between the web server and
zeromq router. PUB/SUB directly between the router and end user client could
potentially cut down on bandwidth for a large implementation.

~~~
hogu
I also wanted to mention, that on the REQ REP side, in the bridge I actually
implement the REQ as an XREQ socket, that way I only need one XREQ socket for
all js side REQ sockets. I simply tag the message with the identity of the js
REQ socket. I had thought it would be nice originally to create a one to one
mapping between javscript side REQ sockets and server side REQ sockets,
however creating one zmq socket per js client may present scaling problems,
running out of file descriptors, etc..

