[zeromq-dev] Implementing failover in client side

Iñaki Baz Castillo ibc at aliax.net
Tue Oct 5 01:28:22 CEST 2010


Hi, I'm trying to understand the proper way to implement failover in a
ZMQ requester (not just load balancing). Let me expose the scenario I
want to achieve:


1) An application processes SIP requests (VoIP) in a single process.

2) The application has a ZMQ REQ socket connected to N servers (ZMQ
REP), so there is load balanding.

3) When a SIP request arrives the application sends a message using
ZMQ REQ (so it expects a response) to a server (which runs a ZMQ REP
socket). Let's say it chooses server-1.

4) The client waits (blocking) the reply for some ms (using zmq_poll).

4.1) If it arrives then it does something with it, and continues
processing the SIP request.

4.2) If the response doesn't arrive (perhaps server-1 is down) the
client should try with server-2 (I expect ZMQ provides this failover
capability in someway but couldn't find it).

4.3) In case all the servers are down then the client would know it
because no response was received in the REQ socket. Then it would
terminate the SIP request processing in any other way, or continue
with it and log an error, or whatever.
Then when a new SIP request arrives the client must re-open the ZMQ
REQ socket (if not it can not send a new request because no response
was received). Also, I don't want the previous lost response to be
received now (I don't want the queue feature), this is, if the
response didn't arrive within N ms due to network issues, I don't want
the response to arrive later. The ZMQ response message only makes
sense when processing the SIP request for which the correspnding ZMQ
request was sent. The only way to get it I can imagine is closing and
re-opening the ZMQ REQ socket after detecting error running zm_send().


Unfortunatelly I cannot find in the documentation how to achieve this
scenario, it seems that ZMQ doesn't provide failover in client side at
all (but just load balancing when using REQ-REP). So I've thinking in
how to get this behavior with ZMQ and the resulting code would change
a lot the "expected" use case of ZMQ, becoming very ugly so it seems
I'm not using ZMQ. Or perhaps I miss something :)


Any recommendation about it? Thanks a lot.

-- 
Iñaki Baz Castillo
<ibc at aliax.net>



More information about the zeromq-dev mailing list