[zeromq-dev] adaptable net

Pieter Hintjens ph at imatix.com
Sun Apr 10 20:07:38 CEST 2016

On Sun, Apr 10, 2016 at 7:42 PM, Matjaž Ostroveršnik
<matjaz.ostroversnik at gmail.com> wrote:

> What were conceptual reasons to make tracker as string? What is wrong with
> some integer value (e.g. uint32/64)?

Easier to generate guaranteed unique values, and messages that need
this kind of reliability tend not to worry about efficiency. You can
always store trackers as fixed size strings depending how you
implement them (thus no allocation).

> Any conceptual objection to extend the confirm message with a (possibly zero
> length) blob?

Sure, if you can tell me what problem you're solving (as usual). Just
adding fields because they *may* be useful tends to make messy

> That is possible, but what about simple zsock_attach with several connect
> addresses? Just simple change from connect to attach. ;-)

I think zsock_attach already allows this:

//  Attach a socket to zero or more endpoints. If endpoints is not null,
//  parses as list of ZeroMQ endpoints, separated by commas, and prefixed by
//  '@' (to bind the socket) or '>' (to connect the socket). Returns 0 if all
//  endpoints were valid, or -1 if there was a syntax error. If the endpoint
//  does not start with '@' or '>', the serverish argument defines whether
//  it is used to bind (serverish = true) or connect (serverish = false).

> Each new thread is potential can of worms. I prefer not to use them unless
> absolutely necessary. ;-)

Actors are safe and easy to use.

> Is there a way to influence the selection of next server/router on DEALER?
> As far I know it is round robin fashion only.
> Perhaps some callback function on zsock_t which returns id of the next
> socket to use?

Use two or more dealer sockets, connect each one to a single router,
and select the one you send to, explicitly.


More information about the zeromq-dev mailing list