[zeromq-dev] Alternative efficiency design of lbbroker

Kenneth Adam Miller kennethadammiller at gmail.com
Mon Jan 12 07:31:30 CET 2015

Instead of routing all information through the broker and requiring an
intermediary hop, I'd like to consider an approach where the address
information that the req socket parses out on the side that first sends
ready is used in order to manage a simple mutual connection facilitator in

Just like with load balancing broker from the manual, I have two parties
that mutually require one another. But I want to do simply a request to the
broker and receive the information I need in order to send directly to the
other entity.

With router sockets, I get the address in a empty delimited set of message
sending convention. What I don't know is if I add a router socket to each
mutually requiring party, and -even if party A is not connected even to
party B- use the address information attained from the broker to send on
party A's router socket to party B and vice versa. Is this the best way to
do this? I don't want to manage a set of connected sockets.

I realize that party A may have individual 1 and party B an individual 2
where 1 & 2 repeatedly make connection over broker-I want to keep using
broker anyway, because broker allows each party to know when an individual
is ready in each. So the 1& 2 scenario is coincidental.

But what I don't think is a good design idea is having a socket that makes
connect/close calls between each iteration to the broker or the idea of
having each endpoint know it's hostname or something (possibly I have
premature misgivings).

In any case, does what I am thinking about work? Reading the target address
information gained from a router object and feeding it to a completely
different router object (where individual 1 may not have ever had his
router connected to individual 2 before)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150112/8ece8eb0/attachment.htm>

More information about the zeromq-dev mailing list