[zeromq-dev] new libzmq API

[MinRK]

One question about zmq_sock_set.

There is one major difference about zmq_sock_set from zmq_ctx|msg_set that
I hadn't considered:

    there are non-integer socket options.

So we have:

int rc = zmq_ctx_set(ctx, opt, val)
int value = zmq_ctx_get(ctx, opt)

where the *return* of zmq_ctx_get is the option value.  But we can't really
do that with socket options,
since there are a few that aren't ints, and we have

int rc = zmq_setsockopt(sock, opt, &val, sizeof(val))
int rc = zmq_getsockopt(sock, opt, &val, &size)

I don't see any really clean solution.  Should we have zmq_sock_set/get, so
the names match, but the signatures don't?
Or do we want zmq_sock_set/get to only work with int socket options and do
something else with the others?

For instance, what would we do if there ever needs to be a context option
that isn't an int?

-MinRK

On Thu, Jan 17, 2013 at 3:32 PM, MinRK <benjaminrk at gmail.com> wrote:

>
>
> 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/5d0d24f7/attachment.htm>