[zeromq-dev] state of publishers and subscribers via ZMQ_PUB and ZMQ_SUB

[Doron Somech]

It is part of ZMTP v3.1 but it is not yet implemented, I think.
On Oct 24, 2015 11:10 AM, "Justin Karneges" <justin at affinix.com> wrote:

> Ah, yes I didn't think about non-graceful disconnects. Enabling TCP keep
> alives is probably the best answer in terms of keeping ZeroMQ usage pure,
> though I know there are some concerns about this as a general solution.
>
> Keep alives in the ZMTP protocol would be ideal. Is this being considered?
>
> On Fri, Oct 23, 2015, at 10:49 PM, Doron Somech wrote:
>
> Just to clarify, zeromq doesn't recognize disconnection (yet), operating
> system is, however it cannot recognize disconnection when it is not
> graceful. This why we need the heart beat. The reason the publisher need to
> be the client, the one doing connect is responsible to do reconnections and
> only send operation can recognize disconnection when it is ungraceful (recv
> will block forever or until send operation happen on the same socket).
> Because in pub/sub only publisher is doing send operation publisher need to
> be the client for reconnection to happen automatically.
> On Oct 24, 2015 6:54 AM, "Justin Karneges" <justin at affinix.com> wrote:
>
>
> Sockets automatically reconnect. You don't have to think about
> connections, just messages.
>
>
> On Fri, Oct 23, 2015, at 08:01 PM, Aravind Sethuraman wrote:
>
> sorry i guess the answer to my question is in Zoron's email ...subscribe
> to ping heartbeat....ok i will give this a shot...
>
> thanks everyone
>
> On Fri, Oct 23, 2015 at 10:47 PM, Aravind Sethuraman <arvinj1 at gmail.com>
> wrote:
>
> interesting point...so if sockets do not connect or are in midst of
> connecting or were connected and a system comes down, upon restart, do
> systems implicitly reconnect?
>
> On Fri, Oct 23, 2015 at 9:54 PM, Justin Karneges <justin at affinix.com>
> wrote:
>
>
> With ZeroMQ, any socket type can bind or connect. Who binds and who
> connects is matter of which entities should have stable or dynamic
> existence, not who is acting as a "server" in some kind of traditional
> sense. So yeah, you can have a PUB socket connect to a SUB socket and vice
> versa. Similarly you can have a REP socket connect to a REQ socket.
> Realizing that these combinations are possible is one of those "ah-hah"
> moments of enjoying ZeroMQ. :)
>
> As for knowing when subscribers are connecting/reconnecting, in general
> you should not need to care about this.
>
> On Fri, Oct 23, 2015, at 06:21 PM, Aravind Sethuraman wrote:
>
> hello doron,
> i am actually interested in making the publisher a client and subscriber a
> server. Correct me if i am wrong but is it not a departure from the usual
> understanding of publisher being a server and subscriber clients? is it
> even possible to do that (i am guessing since you mentioned it; it must be
> ) . also how do i know which subscribers are connected and are reconnecting
> etc?
>
> On Fri, Oct 23, 2015 at 5:55 PM, Justin Karneges <justin at affinix.com>
> wrote:
>
>
> If you make the subscriber the client, reconnections should still work. I
> tested this myself again just now to be sure.
>
> On Fri, Oct 23, 2015, at 02:07 PM, Doron Somech wrote:
>
> make the publisher the client (connect) and the subscriber the server
> (bind), this is important, it will not work the other way, send heartbeat
> from publisher every X seconds (don't forget to make sure subscriber
> subscribe to the heartbeat). If you do it that way reconnection will happen
> automatically. Alternatively you can just enable TCP keep alive.
> On Oct 23, 2015 11:53 PM, "Aravind Sethuraman" <arvinj1 at gmail.com> wrote:
>
> I am building a full mesh of publishers and subscribers (no brokers) and
> as i would like to implement re-connecting when there is a reboot of a
> node. How can i get a list of current state of subscribers to a publisher
> node?
>
> thanks
> aRavind
>
>
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> 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/20151024/2ee2026e/attachment.htm>