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

Doron Somech somdoron at gmail.com
Mon Jun 23 14:30:11 CEST 2014


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).

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140623/2e37a028/attachment.htm>


More information about the zeromq-dev mailing list