[zeromq-dev] Does ZMQ handle tcp-RST?
Michel Pelletier
pelletier.michel at gmail.com
Thu Dec 19 18:22:34 CET 2013
If you and your architects believe there is a better solution to the
problem and that 0mq is doing it wrong, then by all means, don't use it.
Create your own solution and do it right. I encourage you to open source
your solution and build a community around it. You could fork 0mq and go
from there.
However, simplifying the statement of the problem until it "goes away" is
not the same thing as solving it. As many people on this thread have told
you, the only way to know that your message got to your destination is to
receive an acknowledgement. We did not make this up in order to make 0mq.
It is the nature of reality.
-Michel
On Dec 19, 2013 4: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/44e549b0/attachment.htm>
More information about the zeromq-dev
mailing list