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

Doron Somech somdoron at gmail.com
Tue Jun 24 09:36:18 CEST 2014


what do you mean "ZMTP/multiple destination URI's dance"?

He can create a page under http://rfc.zeromq.org/, anyway some of my
thoughts:
* Regarding using URI, i think we should use that for resource sharing
(binding multiple sockets on same port with different service name), we can
also use that for socket type (maybe as fragment) I'm not sure we should
support identifies (I'm not sure what the gain for that).
* We can transfer the protocol version on the  "Sec-WebSocket-Protocol" and
later support server that can support multiple client versions.
* should we only support strings (UTF8)? Because the framing for UTF8 and
binary is different
* I don't think we should start with multiplexing, I think it very
complicated to do it right.

Other than that, lets start :-).

Doron








On Tue, Jun 24, 2014 at 9:20 AM, Michael Haberler <mail17 at mah.priv.at>
wrote:

> 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
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140624/35f9558b/attachment.htm>


More information about the zeromq-dev mailing list