The design is neat. Sadly too much work to implement it in libzmq, and
more profitable areas to work on.
On Mon, Feb 15, 2016 at 12:33 PM, Tom Quarendon
<tom.quaren...@teamwpc.co.uk> wrote:
> The idea with resources would be that when you connected or bound, you just
> added the resource name after the endpoint, as in:
> connect("tcp://localhost:5555/resource")
>
> Has the great advantage that it is completely encapsulated in the endpoint
> string, so any existing code that uses ZeroMQ, any protocol that might be
> implemented can trivially be made to run over a "multiplexed" port, you just
> change the endpoint string.
>
> Adding the information as an extra frame means you start needing to alter
> your protocol logic, and you need to be aware of what framing your protocol
> might use. If your protocol already used multiple frames per message then you
> have the issue of finding the "service routing" frame.
>
> Search for "ZMTP 3.0 "Resources". Implemented?"
>
> -----Original Message-----
> From: zeromq-dev-boun...@lists.zeromq.org
> [mailto:zeromq-dev-boun...@lists.zeromq.org] On Behalf Of Alex Bligh
> Sent: 11 February 2016 12:22
> To: ZeroMQ development list <zeromq-dev@lists.zeromq.org>
> Cc: Alex Bligh <a...@alex.org.uk>
> Subject: Re: [zeromq-dev] Multiplexing a TCP endpoint
>
>
> On 10 Feb 2016, at 19:11, Tom Quarendon <tom.quaren...@teamwpc.co.uk> wrote:
>
>> This is what "resources" in ZMTP 3.1 were designed for. No implementation
>> yet though (see other discussion on his list) :-)
>
> Thanks. That is pretty much exactly what I was looking for (other than the
> 'no implementation yet though' bit).
>
> I've only just subscribed to the list and my google search through the
> archives led only to a post in 2013 hoping this would be in zeromq 4.0. Do
> you have a pointer to the discussion (e.g. the thread title)?
>
> I've read the relevant part of the ZTMP specification. In essence the
> 'resource' seems to be transmitted in the metadata when the connection is set
> up. I'm guessing to use this feature in a compatible way without
> implementation details, then:
>
> 1. On the 'connect' side, I'd merely need to add some metadata
>
> 2. On the 'bind' side, I'd need to run some form of multiplexer and look at
> the metadata property.
>
> I can't however see an API way to set or read from the metadata dictionary
> before any messages are passed.
>
> Am I therefore correct that it isn't possible to implement this without a
> change to zeromq itself?
>
>> You would have to write the proxy loop yourself. So do a select on the
>> external socket and all the internal sockets and know that when you pull a
>> message from the external socket that you peel off the first frame after the
>> delimiter, then use the service name it includes to pick which internal
>> socket to pass the rest of the message to. The services then run
>> independently on their own inproc (or even out of process on ipc or tcp)
>> sockets. It's what I would end up doing to do the same thing.
>
> That's pretty much what I concluded save for the fact that I had thought the
> service ID should probably be the innermost frame (possibly after the empty
> frame delimiter and with it's own zero frame delimiter) so the transport over
> TCP could (if necessary) be routed transparently through RTR sockets.
>
> --
> Alex Bligh
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
