[zeromq-dev] Disable resend of Publisher after reconnection

[Jonathan Reams]

You could use ZMTP heartbeats for this (although it's only in master right
now). You set ZMQ_HEARTBEAT_IVL and ZMQ_HEARTBEAT_TIMEOUT to the minimum
time a tcp connection should be allowed to be idle, and it will reset the
sockets if there's a disconnection for longer than that period.

I think you'll also need to do some kind of time-stamping on each message
though if it's really important that you only receive messages sent after
you've been "connected." What length of time should trigger a disconnection?

On Thu, Aug 27, 2015 at 9:32 AM, Doron Somech <somdoron at gmail.com> wrote:

> For how long are you disconnecting the network?
>
> Just for the experiment try to set SNDBUF of the publisher to zero, along
> with immediate to 1 and send highwatermark to 1. I think it should work.
> However I dont think it is a good configuration. My suggestion is to have a
> time field on each message, save the diff on first message and check it on
> every message. If it too high drop the connection.
> On Aug 27, 2015 4:13 PM, "KIU Shueng Chuan" <nixchuan at gmail.com> wrote:
>
>> You could use the tcp keepalive socket options to make the tcp connection
>> drop faster once you have unplugged your cable. That should cause the
>> queued packets to be dropped.
>>
>> Or your subscriber could drain the socket of messages by reading it until
>> it would block and only process the last one.
>> On Aug 27, 2015 20:42, "Bachmair Florian - flexSolution GmbH" <
>> florian.bachmair at flexsolution.eu> wrote:
>>
>>> ok, thank you!
>>>
>>> I have to think about that, because I want to use curve as well, and
>>> therefore I would need tcp...
>>>
>>> Am 27.08.2015 um 14:12 schrieb Sergey Zinov:
>>>
>>> Seems like that should be the case. TCP is a reliable protocol, it
>>> buffers all data till it acknowledged by receiver and resend when needed.
>>> Switch to the UDP if don't need that reliability.
>>>
>>> On 27.08.2015 14:07, Bachmair Florian - flexSolution GmbH wrote:
>>>
>>> This does not work either :/
>>>
>>> I'm unsing PUB/SUB via tcp.
>>>
>>> I have captured the tcp connection with tcpdump and I saw that after I
>>> unplug the cable I get tcp retransmission packets.
>>>
>>> May this be more a behaviour of tcp itself than of zmq?
>>>
>>>
>>> Am 27.08.2015 um 13:39 schrieb Sergey Zinov:
>>>
>>> Hi,
>>>
>>> Try to set ZMQ_SNDHWM to 1. By the way which transport are you using?
>>>
>>> On 27.08.2015 11:52, Bachmair Florian - flexSolution GmbH wrote:
>>>
>>> I tried it, but it does not work!
>>>
>>> Don't know If I get that right, but even If I set ZMQ_RECONNECT_IV to
>>> "-1" my PUB and SUB Sockets are reconnecting to each other after I replug
>>> the cable
>>>
>>> Am 27.08.2015 um 10:59 schrieb Doron Somech:
>>>
>>> I'm not sure, but try to set  ZMQ_IMMEDIATE option.
>>> On Aug 27, 2015 11:38 AM, "Bachmair Florian - flexSolution GmbH" <
>>> florian.bachmair at flexsolution.eu> wrote:
>>>
>>>> Hello!
>>>>
>>>> Is there a opportunity to tell the publisher not to resend messages?
>>>>
>>>> I have two stations A and B
>>>>
>>>> A publishes all the time
>>>> B receives it
>>>>
>>>> A-PUB 10
>>>> B-SUB 10
>>>> A-PUB 20
>>>> B-SUB 20
>>>> A-PUB 30
>>>> B-SUB 30
>>>> A-PUB 40
>>>> B-SUB 40
>>>> ---unplug cable
>>>> A-PUB 50
>>>> A-PUB 60
>>>> A-PUB 70
>>>> ---plug cable again
>>>> B-SUB 50
>>>> B-SUB 60
>>>> B-SUB 70
>>>> ....
>>>>
>>>>
>>>> B does some routines after it gets those values. But I'm not interested
>>>> in 50 and 60 any more, I just want the 70 after reconnection.
>>>> I do Heartbeating so I detect connection lost on my own and I can
>>>> request the last value as well. So is this possible to disable the
>>>> resend mechanism?
>>>>
>>>> Thx
>>>> Florian
>>>> _______________________________________________
>>>> zeromq-dev mailing list
>>>> zeromq-dev at lists.zeromq.org
>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> zeromq-dev mailing listzeromq-dev at lists.zeromq.orghttp://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> zeromq-dev mailing listzeromq-dev at lists.zeromq.orghttp://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>>>
>>> --
>>> Sergey Zinov
>>>
>>> Wissenschaftlicher Mitarbeiter
>>> Fachbereich Elektrotechnik, Maschinenbau und Wirtschaftsingenieurwesen
>>> Hochschule Anhalt
>>> /
>>> Research Assistant
>>> Department of Electrical, Mechanical and Industrial Engineering
>>> Anhalt University of Applied Sciences
>>>
>>> Phone: +4915738145172
>>>
>>>
>>>
>>> _______________________________________________
>>> zeromq-dev mailing listzeromq-dev at lists.zeromq.orghttp://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> zeromq-dev mailing listzeromq-dev at lists.zeromq.orghttp://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>>>
>>> --
>>> Sergey Zinov
>>>
>>> Wissenschaftlicher Mitarbeiter
>>> Fachbereich Elektrotechnik, Maschinenbau und Wirtschaftsingenieurwesen
>>> Hochschule Anhalt
>>> /
>>> Research Assistant
>>> Department of Electrical, Mechanical and Industrial Engineering
>>> Anhalt University of Applied Sciences
>>>
>>> Phone: +4915738145172
>>>
>>>
>>>
>>> _______________________________________________
>>> zeromq-dev mailing listzeromq-dev at lists.zeromq.orghttp://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/20150827/ffb77a87/attachment.htm>