Hi Doron,
Am 23.06.2014 um 14:30 schrieb Doron Somech <[email protected]>: > 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 <[email protected]> wrote: > Hi Doron, > > Am 23.06.2014 um 10:25 schrieb Doron Somech <[email protected]>: > > > 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 > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
