[zeromq-dev] Reundance/Failover Capabilites?

[Martin Sustrik]

Evan,

>> I assume you are speaking about applications reconnecting after  
>> network/application failure rather than about guaranteed delivery.
>>
>> Currently, when peer disconnects, you are notified about the event via  
>> callback function and you can reestablish the connection if needed.
> 
> The question that I intended to ask is what happens when the machine hosting
> `zmq_server' server process goes down. It wasn't clear to me whether or not you
> were answering this question, or whether you were asking the question about
> nodes connected via this zmq_server process becoming unavailable.
> 
> The specific application that I'm thinking of is this. Many clients on a
> cluster need to log messages. These log messages need to be aggregated onto a
> single machine, in more-or-less real time. The conventional solution for this
> is a syslog service (syslog-ng, rsyslog, etc.) but they don't work well for
> this application (for example, among many issues, they don't deal well with
> binary log formats).
> 
> If the clients are all connected via a single instance of zmq_server than the
> machine hosting the zmq_server process is a single point of failure, which is
> unacceptable in this scenario. What I'm wondering is, is there a way to get
> around this? Clearly I could log to multiple hosts using zmq_server and then
> have some sort of log reconciliation service running after the fact, but I'm
> interested to find out if this capability is built into 0MQ (or whether or not
> it is planned).

Ok, I think you've misunderstood what zmq_server is actually doing. 
Although it looks like standard messaging broker found in other 
messaging products, it is actually only a directory service that keeps 
info about machines, IP addresses and ports of running 0MQ client 
applications. Messages on the other hand are passed directly from one 
app to another, circumventing the broker. It's called broker-less 
architecture. So, in your specific scenario clients would send log 
messages directly to the sys-log service.

Consequently, there will be no single point of failure (unless sys-log 
service fails). Moreover, you'll experience 1/2 of bandwidth usage and 
1/2 latencies (there's single network hop for each message rather than 
two of them).

HTH
Martin