[zeromq-dev] new libzmq API

[KIU Shueng Chuan]

I think there was some effort from 2.2 to 3.2 to give ZMQ a more similar
interface to regular sockets?
e.g. Changing the send function to return the number bytes sent on success
instead of 0.

So I see zmq_getsockopt/zmq_setsockopt to be mirroring their regular
sockets counterpart.



On Fri, Jan 18, 2013 at 8:16 AM, MinRK <benjaminrk at gmail.com> wrote:

> 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
>>>
>>
>>
>
> _______________________________________________
> 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/20130118/18ce3f4d/attachment.htm>