[zeromq-dev] expose dead/slow zyre peer to application layer

[Johan Philips]

On 2015-09-02 15:50, Pieter Hintjens wrote:
> Sounds good, why not make a pull request. You can add this to zyre_event too.

Pull request sent!

>
> On Wed, Sep 2, 2015 at 12:42 PM, Johan Philips
> <johan.philips at kuleuven.be> wrote:
>>
>>
>> On 2015-09-02 12:09, Johan Philips wrote:
>>>
>>>
>>> On 2015-09-02 09:32, Pieter Hintjens wrote:
>>>> This could be done, with a new event.
>>
>> I've added an EVASIVE event, which works fine for our use case at the
>> moment. Thanks for making your software so easy to read and adapt! :-)
>>
>> Here's the minimal change, I had to make:
>>
>> diff --git a/src/zyre_node.c b/src/zyre_node.c
>> index c98eec3..a8a6ccc 100644
>> --- a/src/zyre_node.c
>> +++ b/src/zyre_node.c
>> @@ -848,6 +848,10 @@ zyre_node_ping_peer (const char *key, void *item,
>> void *argument)
>>                    self->name, zyre_peer_name (peer), zyre_peer_endpoint
>> (peer));
>>            zre_msg_t *msg = zre_msg_new (ZRE_MSG_PING);
>>            zyre_peer_send (peer, &msg);
>> +        // Inform the calling application this peer is being evasive
>> +       zstr_sendm (self->outbox, "EVASIVE");
>> +       zstr_sendm (self->outbox, zyre_peer_identity (peer));
>> +       zstr_send (self->outbox, zyre_peer_name (peer));
>>        }
>>        return 0;
>>    }
>>
>>
>>>> The problem is that on WiFi, the
>>>> rate of lost pings is high, so you will get lots of these events and
>>>> not be able to do much with them.
>>>>
>>>> Can you explain what you would do with "peer is being evasive" events?
>>>
>>> Our use case is search & rescue robotics and we want to be able to
>>> determine the quality of service of the communication channel. If WiFI
>>> gets bad, we might want to temporarily switch to DRM for critical messages.
>>>
>>> Maybe we should rely on QoS measurements done lower in the communication
>>> stack, but since in Zyre you are sending pings around we thought we
>>> could benefit from this info :)
>>>
>>> Johan
>>>
>>>>
>>>> On Tue, Sep 1, 2015 at 11:23 PM, Johan Philips
>>>> <Johan.Philips at kuleuven.be> wrote:
>>>>>
>>>>>> On 01 Sep 2015, at 16:56, Pieter Hintjens <ph at imatix.com> wrote:
>>>>>>
>>>>>> If a peer becomes unreachable and removed, there's a LEAVE event. Is
>>>>>> this not what you need?
>>>>>
>>>>> We would like to detect pings that fail, i.e. the evasive not only the expired.
>>>>>
>>>>>>
>>>>>> On Tue, Sep 1, 2015 at 4:39 PM, Johan Philips <johan.philips at kuleuven.be> wrote:
>>>>>>> Dear all
>>>>>>>
>>>>>>> We are using Zyre/Pyre in our application and it would be great if we
>>>>>>> could expose the pings sent between peers to our application layer,
>>>>>>> especially if one of the peers becomes unreachable.
>>>>>>>
>>>>>>> In the current Zyre implementation, in zyre_node.c it is only logged
>>>>>>> with zsys, if in verbose mode. In zyre_node_ping_peerm you have:
>>>>>>>
>>>>>>> if (zclock_time () >= zyre_peer_evasive_at (peer)) {
>>>>>>>            //  If peer is being evasive, force a TCP ping.
>>>>>>>            //  TODO: do this only once for a peer in this state;
>>>>>>>            //  it would be nicer to use a proper state machine
>>>>>>>            //  for peer management.
>>>>>>>            if (self->verbose)
>>>>>>>                zsys_info ("(%s) peer seems dead/slow name=%s endpoint=%s",
>>>>>>>                    self->name, zyre_peer_name (peer), zyre_peer_endpoint
>>>>>>> (peer));
>>>>>>>            zre_msg_t *msg = zre_msg_new (ZRE_MSG_PING);
>>>>>>>            zyre_peer_send (peer, &msg);
>>>>>>>
>>>>>>>
>>>>>>> How could we benefit from this peer management to either send an event
>>>>>>> to our application (using zyre.c) or do we need to do the timing ourselves?
>>>>>>>
>>>>>>> Johan
>>>>>>> _______________________________________________
>>>>>>> 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
>