[zeromq-dev] Is UDP transport needed in ZeroMQ?

[Daniel Krikun]

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" <bruno.rodrigues at litux.org>
wrote:

>
> On Dec 28, 2013, at 17:26, Michael Powell <mwpowellhtx at gmail.com> wrote:
>
> > On Sat, Dec 28, 2013 at 11:05 AM, Daniel Krikun <dkrikun0 at gmail.com>
> 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131228/22e0dbc2/attachment.htm>