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

Wed Feb 10 14:44:21 CET 2016

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160210/1d5f1bba/attachment.htm>