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

[Michael Powell]

On Sat, Dec 28, 2013 at 1:39 PM, Bruno D. Rodrigues
<bruno.rodrigues at litux.org> wrote:
> 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.

Don't know it's worth mentioning, having dealt with some TCP and UDP
in my career, on a couple of occasions I found myself tuning the
actual OS network stack. This was in an embedded Linux system, in
order to allow optimum traffic. It wasn't anything that my software
was doing, the actual OS needed adjustment.

> 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 <dkrikun0 at gmail.com> 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" <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
>>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>