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

Lindley French lindleyf at gmail.com
Thu Dec 19 17:33:15 CET 2013 

You can find out at any time whether the remote peer is up by trying to
ping it or doing something equivalent. However, unless you are using a
heartbeat, it's impossible to know in general whether a remote peer is up
without (a) sending something to it, and (b) timing out without a response.

Any library that tries to re-use a single TCP connection for multiple
messages is going to run into this issue sooner or later.


On Thu, Dec 19, 2013 at 7:13 AM, artemv zmq <artemv.zmq at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/813e6632/attachment.htm>

More information about the zeromq-dev mailing list