[zeromq-dev] identity bug

[Martin Sustrik]

Hi Serge,

>>> 0MQ provides a good level of
>>> abstraction, however, error notifications are an important factor in
>>> building distributed systems.  Say if 0MQ is used for replication of
>>> database content between two master/standby nodes.  It wouldn't be
>>> appropriate for the standby node to just log a master connectivity error
>>> to file instead of performing immediate failover and assuming the
>>> master's role.  Is there another way to handle such use case with 0MQ?
>> For example, you can connect your client to 2 servers. If both are
>> available, client simply load balances the requests among them. If one
>> goes offline, it's queue gets filled (you have to specify the high
>> watermark) and subsequent requests go only to the second server. It's
>> not yet perfect but that's the idea.
> 
> How about this example - a REQ caller sends a message and issues a 
> blocking recv() call.  The REP server dies between receiving a message 
> and sending a reply.  The REP server comes back and client's 0MQ 
> transport successfully reconnects.  However, the client will be blocked 
> in the recv() call forever because the last transaction got lost.

As I said, it's not yet perfect.

The plan for REQ/REP is to have XREQ/XREP as an asynchronous 
infrastructure for requests and replies.

REQ/REP would then be wrappers on top of XREQ/XREP adding synchronicity. 
In addition, REQ would wait a specific timeout and if reply doesn't 
arrive it'll re-emit the request. Also, it would have to drop duplicate 
replies.

You can then liken XREQ/XREP to IP and REQ/REP to TCP.

Martin