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

Tom Quarendon tom.quarendon at teamwpc.co.uk
Wed Feb 10 16:17:31 CET 2016 

My scenario was that I wanted to expose multiple services from a single port, which I think was the original intention of this. So I was imagining having a broker process binding , say, service1 to tcp://*:5555/service1 and service2 to tcp://*:5555/service2. The actual implementations of service1 and service2 would then run either within the same process or in another process, and the broker just running a select loop to connect the relevant sockets up. 

You could do this at the application level but it would appear to require having a simple channel protocol such that each message that arrives at the broker has the service ID, so that the broker knows the correct destination (and ditto responses). This is essentially what SSH does with its channel mechanism (if you just take the transport layer and the connection layer, this is what you have, a secure multiplexed socket).

The trouble with doing it at the application level though is that you can't then use any of the other protocols (majordomo, lazy pirate, xrap etc) on top, at least not without writing the whole thing manually. The advantage of just being able to bind to "tcp://*:5555/service1" is that then any library that has been written to use zmq sockets, and just takes a connection string as parameter will continue to work.


-----Original Message-----
From: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Pieter Hintjens
Sent: 10 February 2016 14:10
To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
Subject: Re: [zeromq-dev] ZMTP 3.0 "Resources". Implemented?

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
>
_______________________________________________
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list