[zeromq-dev] Bidirectional Async Over TCP Without Multiple Binds

[Patrik Wenger]

Ah right, I guess there will be a ZMQ-assigned identity if you don't set 
one. Wasn't able to find that in the docs right away though. I found it 
in the ZGuide now though. Seems like the ROUTER itself will invent those 
for each connected socket that doesn't announce its own identity.

Happy hacking!

Regards,
Patrik


On 14.02.2018 22:40, Jake wrote:
> Ok, thanks for the explanation and doc reference. My A node spawns the 
> B nodes in the
> first place, so I guess I can either (1) assign the identity 
> out-of-band at spawn time and
> have the B use it, or (2) have B handshake once at start up to allow A 
> to associate the
> zmq-assigned identity.  After that B just receives and sends on 
> DEALER; without other
> sockets connected there is no load balancing on B's end.  Node A uses 
> the identity association
> to send to a particular B and to recognize which B is sending when it 
> receives a message.
>
> -Jake
>
> On Wed, Feb 14, 2018 at 4:25 PM, Patrik Wenger <paddor at gmail.com 
> <mailto:paddor at gmail.com>> wrote:
>
>     Hi Jake
>
>     In fact, most ZMQ socket types do some sort of load balancing when
>     connected with multiple other sockets. See [1], especially the
>     "Outgoing routing strategy" and "Incoming routing strategy" in the
>     table for each socket type. TL;DR if the socket allows receiving
>     messages and is connected to multiple other sockets, it will try
>     to read from all of those sockets "fairly". If the socket allows
>     sending messages and is connected to multiple other sockets, it
>     will usually round-robin when sending.
>
>     Of course PUB (and RADIO) will not round-robin, but "fan out"
>     instead, meaning all connected sockets will receive every message.
>
>     And ROUTER is an exception too: When sending, it uses the first
>     message part (set by the application) to determine the correct
>     receiver. This allows you to send a message to one specific
>     connected socket. When receiving, it prepends a message part that
>     identifies the socket which sent the message. Your application
>     will have to inspect that first part to know who is its sender.
>     These two things will have to happen in your A node. The DEALER
>     sockets in your B nodes will have to set an identity to be
>     distinguishable in A's ROUTER socket.
>
>     Regards,
>     Patrik
>
>     [1] http://api.zeromq.org/4-2:zmq-socket
>     <http://api.zeromq.org/4-2:zmq-socket>
>
>
>     On 14.02.2018 20:17, Jake wrote:
>>     Isn't ROUTER-DEALER load balancing though?  I've used it in a
>>     REQ-ROUTER-DEALER-REP set up
>>     but in that case the REQ -> ROUTER send does not target a
>>     particular handler on the other side, it
>>     just goes to an arbitrary one and the ROUTER makes sure the reply
>>     goes back to the original sender.
>>     How would my sender (an A node) target a particular B node to
>>     receive a message?
>>
>>     -Jake
>>
>>     On Wed, Feb 14, 2018 at 12:34 PM, Justin Azoff
>>     <justin.azoff at gmail.com <mailto:justin.azoff at gmail.com>> wrote:
>>
>>         On Wed, Feb 14, 2018 at 12:28 PM, Patrik VV.
>>         <paddor at gmail.com <mailto:paddor at gmail.com>> wrote:
>>         > Hi
>>         >
>>         > Not sure why Justin suggested using a ROUTER-Socket on each
>>         side.
>>
>>         Ah yes, I misread the original message. For "one-to-many" you
>>         would
>>         use router-dealer.  router+router would be more for
>>         many-to-many where
>>         each node runs the same code and there is no obvious master node.
>>
>>
>>         --
>>         - Justin
>>         _______________________________________________
>>         zeromq-dev mailing list
>>         zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
>>         https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>         <https://lists.zeromq.org/mailman/listinfo/zeromq-dev>
>>
>>
>>
>>
>>     _______________________________________________
>>     zeromq-dev mailing list
>>     zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
>>     https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>     <https://lists.zeromq.org/mailman/listinfo/zeromq-dev>
>
>
>     _______________________________________________
>     zeromq-dev mailing list
>     zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
>     https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>     <https://lists.zeromq.org/mailman/listinfo/zeromq-dev>
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180214/aeaa8dca/attachment.htm>