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 <[email protected]> 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 <[email protected]> > >> 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 <[email protected]> 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 <[email protected]> >>> >>>> 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 <[email protected] (mailto:[email protected])> >>>> > > 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 <[email protected](mailto: >>>> [email protected])> 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 >>>> > > > [email protected] (mailto:[email protected]) >>>> > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>> > > >>>> > > _______________________________________________ >>>> > > zeromq-dev mailing list >>>> > > [email protected] (mailto:[email protected]) >>>> > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>> > >>>> > >>>> > _______________________________________________ >>>> > zeromq-dev mailing list >>>> > [email protected] (mailto:[email protected]) >>>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> zeromq-dev mailing list >>>> [email protected] >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>> >>> >>> >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >>> >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
