Sounds good, why not make a pull request. You can add this to zyre_event too.
On Wed, Sep 2, 2015 at 12:42 PM, Johan Philips <[email protected]> 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 >>> <[email protected]> wrote: >>>> >>>>> On 01 Sep 2015, at 16:56, Pieter Hintjens <[email protected]> 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 <[email protected]> >>>>> 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 >>>>>> [email protected] >>>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>>> _______________________________________________ >>>>> zeromq-dev mailing list >>>>> [email protected] >>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>> >>>> _______________________________________________ >>>> zeromq-dev mailing list >>>> [email protected] >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
