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

artemv zmq artemv.zmq at gmail.com
Wed Dec 11 20:07:52 CET 2013


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/4173783e/attachment.htm>


More information about the zeromq-dev mailing list