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

artemv zmq artemv.zmq at gmail.com
Wed Dec 11 20:19:13 CET 2013


Here's code reference (for netty-3.6.6)

org.jboss.netty.channel.socket.nio.AbstractNioWorker.process().   Go to
abstract  function read(SelectionKey k)  .  The go to
org.jboss.netty.channel.socket.nio.NioWorker.read()  implementation.  This
block:

...
try {
            while ((ret = ch.read(bb)) > 0) {
                readBytes += ret;
                if (!bb.hasRemaining()) {
                    break;
                }
            }
            failure = false;
        } catch (ClosedChannelException e) {
            // Can happen, and does not need a user attention.
        } catch (Throwable t) {
            fireExceptionCaught(channel, t);
        }
...
So they read and catch ClosedChannelException.   And then further they call
  close(channel, succeededFuture(channel));  which means  that operation on
channel will not pass.





2013/12/11 artemv zmq <artemv.zmq at gmail.com>

> hi Justin,
>
> >>  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
>
>
> BR
> -artemv
>
>
>
> 2013/12/11 artemv zmq <artemv.zmq at gmail.com>
>
>> Cool!  I saw Bruno response.  Justin, thanks for patience and for keep
>> replying,  I much appreciate that.
>>
>>
>> BR
>> -artemv
>>
>>
>>
>> 2013/12/11 Justin Cook <jhcook at gmail.com>
>>
>>> Artem,
>>>
>>> There is no way to know that a node on the network went down without the
>>> lack of receiving acknowledgements that the message was received — either
>>> with TCP ACKs or a messaging pattern in 0MQ such as REQ/REP.
>>>
>>> If the the server is not up yet, and you have not established a session,
>>> then Bruno has given you the option to workaround that. 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.
>>>
>>> --
>>> Justin Cook
>>>
>>>
>>> On Wednesday, 11 December 2013 at 10:42, artemv zmq wrote:
>>>
>>> > hi Justin. Thanks for heads up.
>>> >
>>> > Ok. Clear. Especially about steady stream.
>>> >
>>> > But, again, let me make it very clear.
>>> > I imagine following situations and desired outcomes:
>>> > - Server is not up yet, and client tries to send a message. Desired
>>> outcome: big red alarm -- "fail" w/o waiting for reply.
>>> > - Server is up, client sends a message, gets reply, everything is
>>> smooth. Then the network between client and server is getting down (e.g.
>>> "ifdown eth0" on server). The client tries to send a message... Desired
>>> outcome: big red alarm -- "fail" w/o waiting for reply.
>>> >
>>> > I don't care server is up or down, or in what status an infrastructure
>>> is. I want to know one thing -- did all frames (of my message) been sent or
>>> not ?
>>> >
>>> > Is it posible with ZMQ?
>>> >
>>> >
>>> > BR
>>> > -artemv
>>> >
>>> >
>>> >
>>> > 2013/12/11 Justin Cook <jhcook at gmail.com (mailto:jhcook at gmail.com)>
>>> > > Artem,
>>> > >
>>> > > This is a problem that every network developer faces. Did my message
>>> make it to its destination? If I send a message, is it likely to make it to
>>> the recipient?
>>> > >
>>> > > Fortunately, there are patterns to use to increase reliability, but
>>> even then there is no way to be 100% sure that when a message is sent, it
>>> will flow across the infrastructure and be delivered with 100% certainty
>>> without an acknowledgement.
>>> > >
>>> > > You cannot _instantly_ get an indication a server failed — or the
>>> associated infrastructure — unless you have a steady stream of bytes going
>>> across the wire, and they suddenly stop. If you want to know a node went
>>> down, you will need heartbeat messages. There are a few ways to do this.
>>> > >
>>> > > Please look at the paranoid pirate example and this:
>>> > >
>>> > > http://zguide.zeromq.org/page:all#Heartbeating
>>> > >
>>> > > --
>>> > > Justin Cook
>>> > >
>>> > >
>>> > > On Wednesday, 11 December 2013 at 09:59, artemv zmq wrote:
>>> > >
>>> > > > Okay. Thanks for your thoughts. Again, I read the guide, and I
>>> know on practice what's pub/sub/push/pull/ .. and so on.
>>> > > >
>>> > > > But let me ask one more time very concrete and simple question. I
>>> want to develop a client/server appl. Okay. I pick dealer/router pattern.
>>> Fine. Now my requirement is following:
>>> > > > if server is unaccessible (wrong ip address, server is not online,
>>> server was online and then went offline, etc.) -- in this case I want to
>>> get (_instantly_) some indication that client can't send a message because
>>> server is unaccessible. It's clear? Again, I don't want to await for reply,
>>> I want to know right now that I can't send a message.
>>> > > >
>>> > > > Realistically, this is very classic networking issue :) So, how
>>> can ZMQ help me? Or is it possible/eligible et al to implement
>>> transactional (not batching!) applications on ZMQ?
>>> > > >
>>> > > >
>>> > > > BR
>>> > > > -artemv
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > 2013/12/11 Bruno D. Rodrigues <bruno.rodrigues at litux.org (mailto:
>>> bruno.rodrigues at litux.org) (mailto:bruno.rodrigues at litux.org)>
>>> > > > > zeromq.org (http://zeromq.org) (http://zeromq.org) - learn the
>>> basics - http://zeromq.org/intro:read-the-manual - the guide -
>>> http://zguide.zeromq.org/page:all
>>> > > > >
>>> > > > > I just gave you a short description of how Ømq is solving the
>>> network problems for me.
>>> > > > >
>>> > > > > On Dec 11, 2013, at 6:59, asif saeed <asif.lse2 at gmail.com(mailto:
>>> asif.lse2 at gmail.com) (mailto:asif.lse2 at gmail.com)> wrote:
>>> > > > > > Hi Bruno,
>>> > > > > >
>>> > > > > > On Wed, Dec 11, 2013 at 12:38 AM, Bruno D. Rodrigues <
>>> bruno.rodrigues at litux.org (mailto:bruno.rodrigues at litux.org) (mailto:
>>> bruno.rodrigues at litux.org)> wrote:
>>> > > > > > > Xsub xpub for distribution load balancing
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > > What is Xsub xpub? Could you please explain these terms or
>>> give me a link to an online resource where these terms are explained in
>>> detail?
>>> > > > > >
>>> > > > > > Thanks in advance,
>>> > > > > > -Asif
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > > _______________________________________________
>>> > > > > > zeromq-dev mailing list
>>> > > > > > zeromq-dev at lists.zeromq.org (mailto:
>>> 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)
>>> (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)
>>> (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
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131211/edcb26fa/attachment.htm>


More information about the zeromq-dev mailing list