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

[Pieter Hintjens]

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