[zeromq-dev] New Projects: NetMQ.WebSockets and JSMQ

Michael Haberler mail17 at mah.priv.at
Tue Jun 24 08:20:24 CEST 2014


Hi Doron,


Am 23.06.2014 um 14:30 schrieb Doron Somech <somdoron at gmail.com>:

> Hi Michael,
> 
> You are right, every message start with ascii code of 1 or 0 to indicate if more to come, regarding the RFC, I think it will be great.
> 
> We should think about more stuff like port sharing (multiple sockets on same port each with different URI) and sub protocols validation (for PubSub, Request Reply).

Assuming we write up a recommendation/method to map zeromq onto websockets as an RFC-style document, I see several aspects to the task:

- define a mapping how multiframe messages are en/decoded, assuming the current ws connection handles a single connection (say a dealer/router or xsub/xpub pair); that would essentially cover non-mutilation of the frame structure, but not aspects like multiple destinations handled in one socket
- do the whole ZMTP/multiple destination URI's dance on the JS side.
- multiplexing several sockets over a single ws connection
- define if the ws connect URI (which can be viewed as pre-connect, out of band information) is used to carry extra setup, like carry socket type, identity, make the proxy connect to several target URI's etc

The first step IMO is essential; curious - does your scheme proxy zero-length frames properly? I'm not fully up to speed on ws specs if zero-length frames are passed properly.
In my application scenario I dont have any upside for (2) and (3), and I'm a bit concerned about feature creep
I think (4) would cover much of (2)
(2) and (3) would probably require more complex framing than just (1) and (4), which would be my preferred goal

I think the decision to take is 'full ZMTP JS-side' and more complex framing, versus one ws connection mapped onto a socket (which may connect to several URI's at the proxy), and simpler framing. I fear the framing methods would be incompatible if one started with the second goal and tried to achieve to the first thereafter, for what I see limited upside.

What I propose is we formulate the framing procedure for the single-socket connection case for a start, and go from there.

- Michael



> 
> Regards,
> 
> Doron
> 
> 
> 
> On Mon, Jun 23, 2014 at 2:53 PM, Michael Haberler <mail17 at mah.priv.at> wrote:
> Hi Doron,
> 
> Am 23.06.2014 um 10:25 schrieb Doron Somech <somdoron at gmail.com>:
> 
> > Hi All,
> >
> > I'd like to introduce two new projects I'm working on:
> >
> > https://github.com/somdoron/JSMQ - ZeroMQ/NetMQ javascript client over WebSockets
> > https://github.com/somdoron/NetMQ.WebSockets - WebSockets extension to NetMQ, uses stream socket type and provide a new socket object that has very similar interface to NetMQ socket object.
> >
> > Both available on nuget (include prerelease) and at a beta stage.
> >
> > You can read more about the projects at my blog:
> > http://somdoron.com/2014/06/introducing-netmq-websockets-jsmq/
> 
> very interesting since I'm on a related venture - relaying zmq router/dealer and xsub/xpub to JS via libwebsockets (C++)
> 
> I'm a complete JS retard, but if I understand your JSMQ layer right it essential wraps multipart frames (with leading 0/1 per frame == MORE flag) over ws frames so they can be assembled/sent from normal zmq multipart frames in the proxy, and message structure retained?
> 
> if this is so I'll adopt your scheme for the zmq/ws proxy I'm working on, because preservation of multiframe messages on the ws side is an open issue for me, and with your approach it would be more 'end-to-end', the zmq/ws proxy being a zeromq proxy proper in terms of socket identity
> 
> maybe this kind of ws framing warrants a bit of an RFC? happy to co-author - could help interoperability downstream
> 
> - Michael
> 
> ps: where I am : http://goo.gl/4TfWBh
> 
> nonobvious aspects are:
> - a key feature is automatic JSON <-> protobuf conversion since we use protobuf-over-zmq internally, see: http://goo.gl/9OEcHY and http://goo.gl/sY6sEI respectively
> - I use URI arguments to drive proxy behavior: http://goo.gl/FVddoJ - rather flexible to tack on this or that option, uses liburiparser
>   a client-side URI to connect to the proxy could look like so:
> 
> 
> 
> 
> 
> >
> > Regards,
> >
> > Doron
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




More information about the zeromq-dev mailing list