It does not have to be that something wrong happened to B, maybe B is a busy server and it took too long to reply to A (from A point of view). I would still like to use REQ/REP because of REP outgoing policy. On Dec 28, 2013 9:06 PM, "Bruno D. Rodrigues" <[email protected]> wrote:
> > On Dec 28, 2013, at 17:26, Michael Powell <[email protected]> wrote: > > > On Sat, Dec 28, 2013 at 11:05 AM, Daniel Krikun <[email protected]> > wrote: > >> What I wanted to say is that while patterns do simplify development, > they > >> have there peculiarities, in the example above, i'm doing non-blocking > >> receive with REQ/REP which looks benign, but in fact it isn't because > if the > >> message is not obtained, i cannot send(). > > > > I don't know your code, but it sounds like a bug worst case, possibly > > a feature request best case. You would likely need to report it, > > probably clarify what you mean by "if the 'message' is not obtained", > > what it is you mean by "I cannot send". > > This is a quite clear case and well documented on the book and patterns. > Peer A sends a message. Something wrong happens with peer B that doesn’t > receive the message, or doesn’t reply, or replies but the message never > gets back to A. Peer A is dead locked. Peer A needs to disconnect and > reconnect. Now if peer A was for whatever reason doing a bind, it would > need to fully kill the socket and create a new one. > > I think simple answer is to never use REP/REQ but instead use > DEALER/ROUTER combinations ;) (/me ducks) > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
