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

artemv zmq artemv.zmq at gmail.com
Thu Dec 19 13:13:29 CET 2013 

hi Lindley,

Thank you for pointing to this.

I devoted so much writing to RST  because this is what usually happens to
our client-server applications  when they being stoped abruptly.   ITOps
 usually just "kill"s  process and that's it.  So OS always tells other
side of a connection that peer gone.   And this gives a perseption that
"you can know upfront whether the server is down or not".  Ok?   So,
architects  get what they want.     And that's why, it's so hard to
convince them, that  in-mem queues and hwm   of ZMQ  just rock.   Because
they say "look, Artem. why we have to deal with all those hwm and in-mem
queues,  if we can know upfront  that we can or cannot send a message?!"  .
 Ok?
So, the  process "kill"  and RST  "make their day",  they just happy  and
don't want to use zmq  as a peer-to-peer solution, because they find it
"not suitable for peer-to-peer  because of  in-mem queues and hwm" .  This
sounds pretty stupid, because ZMQ positions itself as a peer-to-peer
 library :)  . But I can't tell  architects that they are bunch of idiots.
Ok? I just don't have arguments against  their    "we can know upfront
 that we can or cannot send a message"  ... 8(





2013/12/17 Lindley French <lindleyf at gmail.com>

> 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
>>
>>
>
> _______________________________________________
> 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/20131219/dfa785c4/attachment.htm>

More information about the zeromq-dev mailing list