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

[Justin Karneges]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20151024/1b42b06c/attachment.htm>