[zeromq-dev] RPC design pattern

Joe Holloway jholloway7 at gmail.com
Sun Apr 18 09:28:04 CEST 2010

Let's speculate that I'm developing a RPC over TCP application and I
need to invoke a named service, say "helloworld".  I have a service
discovery subsystem capable of resolving the "helloworld" service and
telling my client which nodes provide this service and on which port
to connect, etc.  It's possible that my service discovery subsystem is
stale and responds with a node that has been taken down.  If my RPC
client detects a faulty node, it should failover to other nodes until
it finds one that is reachable.

I guess this is an age old problem of fault tolerant service
discovery.   The service registry can't know whether or not a service
is reachable until a client has tried to connect.

In a traditional RPC system, the client would be able to detect socket
connection errors immediately and failover to another service
provider.  The documentation for 0MQ says that zmq_connect is lazy and
that zmq_send operations are asynchronous.  In my mental model, this
means the client agent can't rely on either of those operations
reporting connection failures.

This leaves zmq_recv as the last hope.  Is there an unambiguous way to
detect connection errors from zmq_recv?  Am I misunderstanding the 0MQ
RPC model and instead should be looking at something like P2P?


More information about the zeromq-dev mailing list