[zeromq-dev] ZMTP 3.0 "Resources". Implemented?

Wed Feb 10 15:10:19 CET 2016

Actually, taking your idea, we can use a single (thread safe) server
socket in a process that is shared by many threads. This kills the use
case.

On Wed, Feb 10, 2016 at 2:44 PM, Axel Voitier <axel.voitier at gmail.com> wrote:
> The use case is true (although I don't feel it personally so far). But if
> its implementation is too complicated in its current form maybe it could be
> done in another way.
>
> Like a kind of muxing-proxy socket that can connect to any kind of sockets
> on one side (on ipc or inproc most likely are they are the local sockets one
> wants to gather I guess), and to another demuxing-proxy socket on the other
> side. It could actually be only one socket type that can both do muxing and
> demuxing.
> It would have to somehow tag each message coming from one socket on one side
> to be mapped to the right socket on the other side. A bit like we can do
> with a router socket, but that can work with any other socket types.
>
>
> Axel
>
> 2016-02-10 14:14 GMT+01:00 Pieter Hintjens <ph at imatix.com>:
>>
>> There was something nice about writing the resource as a path, yet as
>> no-one has implemented it, in any language, I'm probably going to
>> remove it from the 3.1 RFC.
>>
>> On Wed, Feb 10, 2016 at 8:49 AM, Tom Quarendon
>> <tom.quarendon at teamwpc.co.uk> wrote:
>> > Yes, I see the issue now.
>> > So when you bind it will have to check whether you've already bound to
>> > something on the same endpoint and if so ensure the security configuration
>> > is the same, as it has to evaluate the security before it can uncover the
>> > resource to which the connection it being routed.
>> >
>> > It introduces an ambiguity in the XRAP URI syntax. So at the moment you
>> > have {transport}://{endpoint}/{xrap_resource}. You can write a nice cURL
>> > style command line tool that does generic XRAP operations. Once ZMTP
>> > resources are added, the URI becomes
>> > {transport}://{endpoint}/{zmtp_resource}/{xrap_resource}, and this becomes
>> > impossible to parse as you don't know where the zmtp resource name ends and
>> > the xrap resource name starts.
>> >
>> >
>> > -----Original Message-----
>> > From: zeromq-dev-bounces at lists.zeromq.org
>> > [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Pieter Hintjens
>> > Sent: 09 February 2016 15:30
>> > To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
>> > Subject: Re: [zeromq-dev] ZMTP 3.0 "Resources". Implemented?
>> >
>> > Resources act like an internal proxy with a single front-facing socket
>> > (with security) and multiple back-end sockets. It's not a trivial change to
>> > libzmq, which is why we've not made it yet.
>> >
>> > On Tue, Feb 9, 2016 at 4:20 PM, Tom Quarendon
>> > <tom.quarendon at teamwpc.co.uk> wrote:
>> >> You're right, I hadn't noticed that I was looking at ZMTP 3.1 rather
>> >> than 3.0. I think I'd read the "resources" section ages ago and thought
>> >> recently, yes, you can do that with zmq, that's exactly what I want.
>> >> They don't look trivial to implement, since you presumably have to
>> >> exhibit the same behaviour of connecting to something what hasn't been bound
>> >> to yet. I also didn't understand the section on "Since resource evaluation
>> >> happens after security handshaking, all services that use the same endpoint
>> >> SHALL use the same security credentials".  It's unclear whether the
>> >> intention is that resources are multiplexed over a single TCP connection, or
>> >> whether actually each resource has its own connection. The fact that it says
>> >> that all services using the same endpoint use the same security credentials
>> >> suggests that they are multiplexed over the same connection?
>> >>
>> >> Anyway. Sounds like I need a new design.
>> >>
>> >> -----Original Message-----
>> >> From: zeromq-dev-bounces at lists.zeromq.org
>> >> [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Pieter
>> >> Hintjens
>> >> Sent: 09 February 2016 14:11
>> >> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
>> >> Subject: Re: [zeromq-dev] ZMTP 3.0 "Resources". Implemented?
>> >>
>> >> Resources are not implemented in libzmq master, and are specified in
>> >> the ZMTP 3.1 draft.
>> >>
>> >> So the stable 4.1 release of libzmq supports the stable ZMTP 3.0 RFC.
>> >> Master supports other new pieces of 3.1 like heartbeating. If no-one
>> >> volunteers to implement (or pay for) resources, they will eventually be
>> >> moved to a further draft or dropped.
>> >>
>> >> The only way to tell what a given ZMTP stack supports is to test it
>> >> from the outside and via its API, I think. We don't have such test tools
>> >> yet. I'd like to make them at some point.
>> >>
>> >> -Pieter
>> >>
>> >> On Tue, Feb 9, 2016 at 12:39 PM, Tom Quarendon
>> >> <tom.quarendon at teamwpc.co.uk> wrote:
>> >>> I thought I’d just have an experiment with the “resource” facility in
>> >>> ZMTP 3.0, but as far as I can tell there’s no implementation of it,
>> >>> either on master, or in any of the releases.
>> >>>
>> >>> In general, how do I tell what version of ZMTP a release supports?
>> >>>
>> >>> Is the “resource” facility implemented anywhere? It was a rather
>> >>> integral part of a design I’d been working on L
>> >>>
>> >>>
>> >>>
>> >>> Thanks.
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >> _______________________________________________
>> >> 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
>> > _______________________________________________
>> > 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
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>