I will create a page at http://rfc.zeromq.org/ and will cover the framing, but I will only get it on the weekend...
On Tue, Jun 24, 2014 at 12:40 PM, Michael Haberler <[email protected]> wrote: > Hi Doron, > > > Am 24.06.2014 um 09:36 schrieb Doron Somech <[email protected]>: > > > what do you mean "ZMTP/multiple destination URI's dance"? > > well, I see the choices being either a pretty complete ZMTP implementation > on the JS side of things - then you can multiplex, connect several socket > destinations in JS and so forth; or one uses URI options, and the proxy's > functionality, and only multipart framing is done over the ws connection; I > prefer the latter because the first option looks like significant effort > for no clear upside > > > > > 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). > > It does make sense at times to have clients legibly identified, eg in > logs; it's not much extra cost, just a URI k/v pair > > > * We can transfer the protocol version on the "Sec-WebSocket-Protocol" > and later support server that can support multiple client versions. > > that is a clever idea, I like it! > > > * should we only support strings (UTF8)? Because the framing for UTF8 > and binary is different > > I dont see any value in that atm, but I might be missing something; again > I had that as a k/v option in the URI > > > * I don't think we should start with multiplexing, I think it very > complicated to do it right. > > nope, KISS wins the day > > > Other than that, lets start :-). > > how do we start on the multipart framing writeup? You sketch it, or I > disassemble your code ;-? > > One issue we need to think through is the handling of identities - eg if > due to zmq proxies several identities are assembled, delimited with a > zero-length frame; the options are either to pass those through via WS > as-is, or maybe handle them at proxy proper if that is to be the last > zeromq endpoint having a visible identity > > > cheers - Michael > > > > > > Doron > > > > > > > > > > > > > > > > > > On Tue, Jun 24, 2014 at 9:20 AM, Michael Haberler <[email protected]> > wrote: > > 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 > > > > _______________________________________________ > > 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
