[zeromq-dev] adaptable net

[Matjaž Ostroveršnik]

Within your mail.

On 10.4.2016 20:07, Pieter Hintjens wrote:
> 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).
c strings end with binary zero. Binary trackers can have zeros in the 
middle, therefore on the path from client to worker and backwards some 
intermediate layer can simply strip contents after the zero, since type 
of the field is c string.
Maybe later on I'll ask you for explanation how to transfer strings 
through zmq without allocation/dealocation. ;-)
>
>> 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
> protocols.
I'd like to add blob in order to transfer back a reply to the service 
request. Sometimes it is not enough just simple answer I did it or it 
failed.
Normal communication in service usage is:
client: please do something with the provided data
worker: I did it, and the result of the service is the flowing data. 
(the following data is blob, that I proposed to add)
>
>> 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:
Yes that's exactly wanted I wanted to say. If multi address connect 
could replace spawning 1+ actors and additional pipe, I would rather use 
multi address connect.
>
> ```
> //  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.
I don't doubt in actor plumbing code. I am more affraid of the actor 
implementation code. E.g. not long ago I tried to start zauth actor 
within mlm_server, which was already actor. It crashed. Then I moved 
zauth actor to the main thread and just provided the address of the 
zauth to it, and it worked. I can not exclude my mistake, but simpler 
the code is, simpler it is debuged and maintained.
>
>> 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.
I did it with Majordomo pattern and it worked, but it was all my code. :-)
I just wanted to piggy back on the existing zmq code. There must be 
definitely somewhere in the code a section which defines which next 
connection to use for send or recv. ;-)
>
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev