[zeromq-dev] multi-connect REQ socket send routing

Carl Jenkins cjenkins5614 at gmail.com
Sat May 30 17:52:36 CEST 2020

Hi. Just to follow up on the question. I think detecting dead server during
REQ is covered in Chapter 4 Reliable Req-Rep Patterns, and the lazy pirate
pattern deals with this case. In my situation, I ended up having another
SUB socket receive heartbeats from servers and reconnect to the healthy
ones when recv() times out.

This is still a bit involved (one more socket on client side, and some
communication between the health checker and main thread) and led me into
testing some simple cases. What I found was that if the binding servers are
REP, and client is REQ, when one server dies, client won’t automatically
choose a different connected server to send the request. However, if the
binding server is REQ, and clients are REP, when one client dies, the
server is able to fall back to other healthy clients.

The code is at


On Mon, May 25, 2020 at 3:23 PM Carl Jenkins <cjenkins5614 at gmail.com> wrote:

> Hello,
> I started using zeromq for a project and have bee reading the guide
> (almost done with chapter 3. There is one occasion where I want to have a
> REQ client talk to multiple servers. I don’t plan to use the routing/load
> balancing pattern, with the intent to avoid single point of failure. If a
> server dies, I’d like the client to switch to a different server to do
> send-recv.
> I have realized recv would block if that very host it’s talking to dies,
> and my solution is to set RCVTIMEO to a finite number (and LINGER to a
> finite number as well when socket terminates). However, for the send part,
> I can see send always seems to go through (I think due to buffering), and
> the subsequent recv would time out. This means send is still doing simple
> round-robin, otherwise recv would have been smooth, given other servers are
> healthy. I’m OK with buffering and send not reporting one server dying, but
> how can I ask zeromq to neglect the dead server from the round robin list?
> This seems to be the documented behavior from
> https://zeromq.org/socket-api/, but my tests above didn’t reproduce it:
> If no services are available, then any send operation on the socket will
> block until at least one service becomes available. The REQ socket will not
> discard any messages.
> Thanks,
> Carl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20200530/4b860ffb/attachment.htm>

More information about the zeromq-dev mailing list