[zeromq-dev] ZMTP 3.0 Status: Sharing Single TCP connection (Example code ?)

[Yannick Koehler]

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 <ph at imatix.com>:
> 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 <yannick at koehler.name> 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 <ph at imatix.com>
>>>
>>> On Fri, Jun 7, 2013 at 2:39 PM, Yannick Koehler <yannick at koehler.name>
>>> 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
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>>
>>
>> --
>> Yannick Koehler
>> Courriel: yannick at koehler.name
>> Blog: http://corbeillepensees.blogspot.com
>>
>> _______________________________________________
>> 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



-- 
Yannick Koehler
Courriel: yannick at koehler.name
Blog: http://corbeillepensees.blogspot.com