[zeromq-dev] libzmq utility functions

shancat shannenlaptop at gmail.com
Thu Oct 31 16:21:09 CET 2013


Peter brought up the other point of what to do in case of errors. Do we
quit if the bind/connect fails? Do we try again 10 times? 15? Do we tell
someone else to handle it?
On Nov 1, 2013 2:10 AM, "Uli Köhler" <ulikoehler.dev at googlemail.com> wrote:

> Thanks for all your feedback! I really like Pieters idea of bind/connect
> by > or < characters. I'll try to put together a pull request for that
> feature.
>
> @Peter Kleiweg:
> In my application, about 80% of the socket creations bind/connect
> immediately.
> About 10% need to set the HWM and/or other sockopts (mainly IPV4ONLY =
> false)
> The remaining 10% need multiple binds (runtime-configured) or connects
> (e.g. TCP and IPC).
>
> I assume most applications will have an even higher percentage of "simple"
> binds/connects.
> Of course, you could still do "classic" binds, but I think especially with
> Pieter's idea, the convenience is worth the one extra API function (call me
> lazy).
>
>
> Best regards,
> Uli
>
>
> 2013/10/29 shancat <shannenlaptop at gmail.com>
>
>> Presumably it's not very often you create a socket without
>> binding/connecting it so these don't really "depend on the application".
>>  On Oct 29, 2013 9:04 PM, "Peter Kleiweg" <pkleiweg at xs4all.nl> wrote:
>>
>>> Pieter Hintjens schreef op de 29e dag van de wijnmaand van het jaar 2013:
>>>
>>> > I think it's a great idea and was playing with it also. It should go
>>> > into the low level API IMO so it's available to all languages.
>>> >
>>> > You could make a single API call, zmq_new_endpoint () which has
>>> > different syntax for the endpoint depending on direction. E.g. by
>>> > default, it's a bind but if you prefix with ">" it's a connect.
>>> >
>>> > It could also be nice to consider endpoint resolution in libzmq using
>>> > an internal protocol as we do for authentication. I.e. bind/connect to
>>> > "$myname" which gets resolved by a plugin into "tcp://hostname:port".
>>>
>>> I think these kind of things are more for applications. There,
>>> you determine what the regular patterns are, and you write
>>> tiny utility functions that wrap these in a single call.
>>>
>>> But what those typical patterns are depends on the application,
>>> so I don't think this belongs in the library. At least not in
>>> the C library.
>>>
>>> Language bindings for languages that work usually on a more
>>> abstract level could provide higher level functionality. For
>>> instance, for my Go binding, there is no setsockoption or
>>> getsockoption. There's a separate function for each option
>>> (which also works well with the godoc system), and there are
>>> even some more higher level functions.
>>>
>>> But what type of higher level functionality is required also
>>> depends on the language. Czmq has things that make no sense in a
>>> Go binding, because Go does things in a different way.
>>>
>>>
>>>
>>> --
>>> Peter Kleiweg
>>> http://pkleiweg.home.xs4all.nl/
>>> _______________________________________________
>>> 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/20131101/c41f364c/attachment.htm>


More information about the zeromq-dev mailing list