[zeromq-dev] Does ZMQ handle tcp-RST?

[Lindley French]

Something you need to consider is that a TCP RST does *NOT* necessarily
mean the other host is gone. That's one possibility, but it might also mean
a critical packet was lost due to congestion and TCP got confused. That's
all it really means----TCP is confused. In many cases, it's possible to
re-establish a new TCP connection to replace the old one, so you don't
really know if the other host is gone until you try.

Note, any messages buffered on the old connection (either on the TCP layer
or the 0MQ layer) will be lost if this happens.


On Tue, Dec 17, 2013 at 9:56 AM, artemv zmq <artemv.zmq at gmail.com> wrote:

> I'm sorry for make you (and any other in ZMQ commnty) think that I'm not
> polite or disrespectfull.
>
>
> Here's a code: http://pastebin.com/UGzHbXfG
> On the Client  I set HWM=0 on DEALER socket.  Pls. run code with "-ea"
>  jvm flag so assertions could make sense.
> So, what's point I try to prove with this code?  Smply launch a Server,
> then launch a Client.  Pls. take a look at console, you will see some
> chatting. Then kill the Server and go to Client console -- you will not see
> any "assertion failed"  exceptions which I expected at   "assert   send()".
>  So what we have?   DEALER knows that ROUTER died (via tcp-RST)  but still
> returns "true" for .send().
>
>
>
>
> 2013/12/17 Justin Cook <jhcook at gmail.com>
>
>> Artem,
>>
>> Overall, you have been respectful and polite toward the community. We are
>> all busy, and have jobs, kids, and other things to keep us busy. I asked
>> you to provide your code which you initially dismissed. All it takes is one
>> line or an easy off by one error to cause a complete misunderstanding.
>>
>> Pieter did not imply you said “I want”. That is simply a way of saying
>> that your needs and use cases should be well defined along with providing
>> that which is asked for, read the docs and even source code if necessary so
>> you understand what the underlying semantics are of what you are dealing
>> with.
>>
>> I applaud you for doing tcpdumps and examining what is going across the
>> wire so you understand what happens in specific situations.
>>
>> Cheers,
>>
>> --
>> Justin Cook
>>
>>
>> On Tuesday, 17 December 2013 at 14:26, artemv zmq wrote:
>>
>> > > > Agreed, that's what he's saying. So where are the semantics of HWM=0
>> > > > defined? "I want" has never been a valid problem statement in this
>> > > > community.
>> > >
>> >
>> >
>> > Hi Pieter. I never in this thread said "I want".
>> >
>> >
>> > 2013/12/17 Pieter Hintjens <ph at imatix.com (mailto:ph at imatix.com)>
>> > > Agreed, that's what he's saying. So where are the semantics of HWM=0
>> > > defined? "I want" has never been a valid problem statement in this
>> > > community.
>> > >
>> > > On Tue, Dec 17, 2013 at 2:49 PM, Justin Cook <jhcook at gmail.com(mailto:
>> jhcook at gmail.com)> wrote:
>> > > > Pieter,
>> > > >
>> > > > What he is trying to do is set HWM to 0 so it will block when a
>> network disconnect occurs. So far, he is saying that is not happening. I
>> asked him to provide a link to his code and specifically say what is
>> happening and what are his expectations.
>> > > >
>> > > > He is basically saying that when a disconnect occurs and HWM is set
>> to 0, send() still returns true. He doesn’t want that to occur.
>> > > >
>> > > > --
>> > > > Justin Cook
>> > > >
>> > > >
>> > > > On Tuesday, 17 December 2013 at 13:44, Pieter Hintjens wrote:
>> > > >
>> > > > > HWM=0 does not mean there's no buffering. The TCP buffers will
>> accept
>> > > > > messages up to a certain size. If you try with larger messages
>> send()
>> > > > > may behave differently with HWM=0. Also, the queuing strategy
>> depends
>> > > > > on the socket type.
>> > > > >
>> > > > > Can you find a specification somewhere that states what should
>> happen
>> > > > > in this case, and can you make a test case that proves the
>> software is
>> > > > > not conforming to the specification? That is a bug. "I am trying
>> edge
>> > > > > cases and don't understand the results" isn't a bug.
>> > > > >
>> > > > > So read the specs (there are RFCs for socket behavior, and man
>> pages)
>> > > > > carefully and try to make minimal test cases to disprove the code.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > zeromq-dev mailing list
>> > > > zeromq-dev at lists.zeromq.org (mailto:zeromq-dev at lists.zeromq.org)
>> > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> > >
>> > > _______________________________________________
>> > > zeromq-dev mailing list
>> > > zeromq-dev at lists.zeromq.org (mailto:zeromq-dev at lists.zeromq.org)
>> > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> >
>> > _______________________________________________
>> > zeromq-dev mailing list
>> > zeromq-dev at lists.zeromq.org (mailto: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131217/4ae1706d/attachment.htm>