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

[Justin Karneges]

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