[zeromq-dev] new libzmq API

[MinRK]

On Thu, Jan 17, 2013 at 3:10 PM, Pieter Hintjens <ph at imatix.com> wrote:

> On Thu, Jan 17, 2013 at 11:50 PM, MinRK <benjaminrk at gmail.com> wrote:
>
> > This is a clone of pyzmq's own MonitoredQueue that does less.  MQ does
> two
> > things that proxy does not:
> >   1. there is a prefix message for messages sent via the side socket, so
> > that receivers can actually tell where they came from
> >   2. MonitoredQueue works with ROUTER:ROUTER configurations, allowing it
> to
> > act as a multiplexer device.
> >
> > I think zmq_proxy would be a better function if it did one or both of
> these,
> > but the first would require changing the zmq_proxy API,
> > which is unfortunately set in stone now that there has been a stable
> > release.
> >
> > The inertia involved in a change to zmq_proxy again raises all the same
> > arguments that led to the attempted removal of zmq_device.
>
> I don't see any inertia. No-one's made a pull request that was refused
> or delayed, and since zmq_proxy was new, and I suspect few people use
> it, I think extending or changing the API would be uncontroversial.
> zmq_proxy was waiting for some suggestions, it's obviously a first
> draft.
>

I only mean that since there is a stable release with zmq_proxy,
a change to the API has to have a different name, think about deprecation,
etc.


>
> I'm not familiar with the MQ functionality, perhaps you can explain more:
>
> * is the prefix configurable, and if so, how do you configure it?
>

In Python, these are just strings passed to the function as arguments, with
defaults 'in' and 'out'.
In libzmq, they could be message or strings, I'm not sure what is best.
The principal is that if you have a ROUTER-DEALER-SUB proxy, you can tell
where messages are coming from:

client DEALER connects to ROUTER, sends 'hello'
ROUTER gets ['IDENTITY', 'hello']
DEALER sends ['IDENTITY', 'hello']
PUB sends ['in', 'IDENTITY', 'hello']

service ROUTER at the bottom gets ['IDENTITY2', 'IDENTITY', 'hello']
replies with ['IDENTITY2', 'IDENTITY', 'I heard you']
DEALER gets ['IDENTITY', 'I heard you']
ROUTER sends ['IDENTITY', 'I heard you']
PUB sends ['out', 'IDENTITY', 'I heard you']

client receives ['I heard you']

using zmq_proxy in its current form, messages in either direction are
indistinguishable - there's no way to tell if 'I heard you' is a request or
a reply.


> * what precisely do you mean with ROUTER-ROUTER configurations?
>

a ROUTER-ROUTER device can be used as a multiplexer,
but you must swap the first two message parts to get the identity routing
right:

client DEALER (identity CLIENT)
service ROUTER sets identity 'SERVICE'

device has two ROUTERs - R1, R2, client connects to R1, service to R2.

client sends ['SERVICE', 'request']
R1 receives ['CLIENT', 'SERVICE', 'request']
device swaps identities
R2 sends ['SERVICE', 'CLIENT', 'request']
service receives ['CLIENT', 'request']

service sends ['CLIENT', 'reply']
R2 receives ['SERVICE', 'CLIENT', 'reply']
R1 sends ['CLIENT', 'SERVICE", 'reply']
client receives ['SERVICE', 'reply']

So now you can connect a collection of services to one of these proxies,
and clients use the proxy as a service multiplexer based on service socket
identities.



>
> > 2. zmq_ctx_set vs zmq_setctxopt
>
> You mean zmq_sock_set vs. zmq_setsockopt, right?
>
> > should we add zmq_sock_set/get, so that libzmq is consistent?
> > It's clear that zeromq does not worry about renaming/deprecating
> functions
> > if devs decide a different name is simply preferable (e.g.
> zmq_ctx_destroy).
>
> Yes, I think we've rolled over from the old inconsistent API to a
> cleaner one without breaking applications. The deprecated names will
> stay there as long as anyone needs them.
>
> I like your suggestion of zmq_sock_set and zmq_sock_get, it makes
> great sense. Consistency is worth striving for.
>
> For a start I'd definitely use this syntax in the binding; it's
> already the style used in CZMQ (zsocket_set_xxx).
>
> > 3. zmq_ctx_destroy
> >...
> > I realize that I missed the window for much of this conversation,
> because I
> > was writing my thesis while these decisions were made,
> > and libzmq was released, but I would appreciate some input.
>
> :-) Yes, these are great criticisms that would have been helpful a
> while back. Better late than never, and I hope your thesis was a hit.
>
> +1 on renaming zmq_ctx_destroy to _term and deprecating _destroy.
>
> Do you want to make these changes or should someone else?
>

I'll get started, I just wanted to check in before writing code.

Thanks!

-MinRK


>
> -Pieter
> _______________________________________________
> 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/20130117/aa06f876/attachment.htm>