[zeromq-dev] identity bug

[Serge Aleynikov]

On 5/25/2010 1:56 AM, Martin Sustrik wrote:
>> 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.

Since there are very limited details on what XREQ/XREP are supposed to 
achieve, could you tell if in the example above when using XREQ/XREP 
there would be any resource leaks (due to pending transaction) or any 
other types of blocking?  Does XREQ preserve ordering semantics (i.e. if 
requests are sent in order 1 and 2, is it possible to receive and 
process replies in order 2 and 1 without blocking if reply to request 1 
is lost forever)?

Serge