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

Justin Karneges justin at affinix.com
Wed Dec 11 20:53:03 CET 2013


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




More information about the zeromq-dev mailing list