I may be missing something here, so I am looking for someone with architectural/design knowledge of those component to indicate how a good fit or not they are and what "showstopper" issue I may encounter.
I am not looking for an existing solution (unless one exists), but mostly trying to validate a plan I have from expert in this field already. 2013/6/7 Yannick Koehler <[email protected]>: > Ok, so let's say I have a bridge, so I have internally multiple TCP > connections going towards my bridge which then has to multiplex all > those zeroMQ TCP connection into the websockets protocol. The > websockets protocol doesn't have sub-channel, I will then have to > build a multiplexing/demultiplexing protocols. > > My understanding is that ZMTP 3.0 is such a thing, and therfefore if I > go create a web socket connection like this: > > GET /broker HTTP/1.1 > Host: server.example.com > Upgrade: websocket > Connection: Upgrade > Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== > Sec-WebSocket-Protocol: zmtp-3.0 > Sec-WebSocket-Version: 13 > Origin: http://example.com > > Then I will have to encapsulate messages/commands of ZeroMQ within > WebSockets messages/frames. > > My assumption here is that I will be losing batch performance because > I am going through a bridge not build using the batch philosophy, and > that I will be using 2 framing mechanism one on top of the other for > the exact same purpose, which looks to me like a waste. > > I could certainly try that at first, but then investing in that will > not give an optimal solution, so why should I not invest in the > optimal solution which appears to be making the zeromq > message/command/fragment system works on top of websocket > message/fragment system and use ZMTP 3.0 as the multiplexing solution. > > Then my bridge will still exists but at least it talks zeroMQ on all > it's underlying nodes that it bridge together. > > Does that make sense? > > > 2013/6/7 Pieter Hintjens <[email protected]>: >> If you want to talk to web servers, you really should use an existing >> websocket proxy or bridge IMO. >> >> On Fri, Jun 7, 2013 at 4:04 PM, Yannick Koehler <[email protected]> wrote: >>> Stepping back was my actual next step, before investing I needed to make >>> sure that the requirement that I have were met or would be met in a >>> relatively close future. I need a persistent (yet recoverable since >>> connection still could be dropped) TCP connection to a web server (re-using >>> existing port ala websocket) that offer message based bi-directional and >>> allow multiplexing subchannels that offers a messaging API on top of it, and >>> ideally a PUSH/PULL method supporting REST on top. >>> >>> If ZeroMQ can't offer that in the next year, it would be a waste of my time >>> to step back and use ZeroMQ as its currently offered, knowing that next year >>> I still won't have what I need. >>> >>> So right now, in order for me to progress on my project with ZeroMQ, I need >>> to understand if my needs can be somewhat met, by actual code or by >>> implementing it in the time frame that I have, so basically, I need to know >>> how "utopic" that would be. >>> >>> I totally understand that not having this requirement above, I could achieve >>> the same with multiple simultaneous and short lived connections and learn >>> the ZeroMQ way/API but that requirement so far is not something I can drop >>> that easily. >>> >>> >>> 2013/6/7 Pieter Hintjens <[email protected]> >>>> >>>> On Fri, Jun 7, 2013 at 2:39 PM, Yannick Koehler <[email protected]> >>>> wrote: >>>> >>>> > I have a need where for firewall penetration and simplicity to have a >>>> > single TCP connection between my clients and servers. My understanding >>>> > is >>>> > that ZMTP 3.0 is offering this. It is also my understanding that right >>>> > now >>>> > this is not yet stable or usable in a production environment, is this >>>> > assertion true? >>>> >>>> It's specified in ZMTP 3.0 but not implemented in libzmq yet. >>>> >>>> > I will download libzmq and try to find out on my own, but would really >>>> > appreciate some pointer as to the state of this kind of usage and best >>>> > practices... >>>> >>>> My advice is to step back from what you want to make, and instead >>>> spend a few days learning the 0MQ patterns and semantics by working >>>> through the Guide. When it "clicks" for you, go back to your problem >>>> and make a simple minimal design. Then develop that little by little. >>>> If you try to make the real architecture directly, it will usually not >>>> work due to the many wrong assumptions you have about how 0MQ works, >>>> and you'll be disappointed with 0MQ. >>>> >>>> -Pieter >>>> _______________________________________________ >>>> zeromq-dev mailing list >>>> [email protected] >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >>> >>> >>> >>> -- >>> Yannick Koehler >>> Courriel: [email protected] >>> Blog: http://corbeillepensees.blogspot.com >>> >>> _______________________________________________ >>> 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 > > > > -- > Yannick Koehler > Courriel: [email protected] > Blog: http://corbeillepensees.blogspot.com -- Yannick Koehler Courriel: [email protected] Blog: http://corbeillepensees.blogspot.com _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
