B being busy is what I called “something wrong”. The kind of wrong that at least it can be identified. I’ve lived with hanged tcp connections (too much bad traffic and bad NAT), which is the worse kind of something wrong.
I honestly can’t understand the need for REQ/REP for long lived connections, but see it quite simple for one-shot requests - similar to HTTP. In this case it’s clear that if the reply doesn’t come back, the A will fully disconnect and reconnect and can send again, as stated on the book. For long lived connections - multiple req/rep - I personally rather use an async version. On Dec 28, 2013, at 19:15, Daniel Krikun <[email protected]> wrote: > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
