[zeromq-dev] What exact networking problems ZMQ does solve?

[Lindley French]

Keep in mind that RST does not always mean the server is unreachable,
merely that something went wrong with that particular connection. It can
happen in congested environments, and usually just re-connecting works
fine. The hard part in this case is knowing which messages sent on the
previous connection got through, and which need resending.

The simplest possible example of a case where a server can become
unreachable silently: if a smartphone leaves the coverage area, and loses
its connection to the data network. In general, the only way to "detect"
this is to set a timeout, and assume that if you haven't gotten a response
to your message within that time, you aren't going to get one at all. This
is not a perfect assumption but it's usually good enough. (Heartbeats are a
variation on this theme.)


On Thu, Dec 12, 2013 at 11:46 AM, artemv zmq <artemv.zmq at gmail.com> wrote:

> hi Justin Karneges.
>
> I finally got your point (and point from Justin Cook, he had expressed
> earlier)  !! Thanks a lot.
>
> You guys are talking about situation(s) when server side __is not
> capable__ to send FIN or RST. I reproduced situation of "broken connection
> and blind client"  very easily with "iptables" command.  Before that I was
> using "ifdown" -- and experienced "grievous mental confusion"  because
> couldn't understand __how__ client socket knows that server abruptly
> exited. Until I found that there's such thing as RST ... :)   So,  during
> "ifdown"  or "/etc/init.d/network stop" or abruptly killed server process
>  --  kernel sends RST to client socket(s), making  them  aware that server
> gone offline.  It appears that "iptables"  is very silent "connection
> killer" !
>
> Now my question is going more to networking field. I want that kind of
> situations when I can lose connection __but__ nor FIN, neither RST will be
> generated . In other words I want to lose connection veyr silently (from
> client perspective). Will be much appreciated for all that possible
> scenarios.  Thanks in advance.
>
>
> BR
> -artemv
>
>
> 2013/12/11 Justin Karneges <justin at affinix.com>
>
>> On 12/11/2013 11:07 AM, artemv zmq wrote:
>> >  >> If the server goes down, and their is an established session, there
>> > is no way to know that without further communication, or no response
>> > where response is expected.
>> >>>If there is, I would love to know about it.
>> >
>> > I found a solution. There's  a lib in java called "netty".  So they do
>> > next:   in separate thread they poll existing channels  on read
>> > operation (among others)   and during this poll __they can__ detect
>> > that "socket was focibly closed by remote peer". Ok?  So they just poll
>> > for read  and when things are connected polling on read returns an info
>> > akin to "0 bytes was read", so essentially, appl. treat this like
>> > "nothing was read but channel is alive!".   And that's it.   What it
>> > gives?  Before write operation we may know the status of channel.  "0
>> > bytes read" is an indicator that it's alive.  If got exception --
>> > channel is closed, and all future operations on channel are cancelled.
>> >
>> > I'm wondering why ZMQ  can't do something similar or even better? o_O
>>
>> If you establish a TCP connection to a remote system with netty, and
>> then do "ifdown" on the remote system, you will not receive any
>> indication of this and any messages you send to the remote system will
>> be lost. If the connection stays down long enough, maybe around 20
>> minutes, then the local TCP stack will timeout the connection and netty
>> will finally report an error to your application.
>>
>> TCP, and therefore any framework based upon it, does not instantly
>> report delivery failure, and in general it is hard to figure out what
>> was not delivered when you finally do receive an error. About the best
>> you can do is use ioctl() with SIOCOUTQ to investigate your TCP queue.
>>
>> Your goal of knowing "instantly" if a message was not delivered is not
>> possible without a very fast heartbeat system.
>>
>> One thing you can do is consider delivery to have failed if you don't
>> have a TCP connection active (or if an attempt to establish a connection
>> resulted in a "connection refused" error), but just be aware that this
>> won't cover a case of the network dropping out, as in the case of
>> "ifdown", or if someone accidentally unplugs a network cable.
>>
>> The short answer is that 0MQ does not solve your exact problem. It does
>> solve a bunch of other problems though.
>>
>> Justin
>>
>> _______________________________________________
>> 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/20131212/4b6fe9fd/attachment.htm>