feat(mdns): adaptive initial interval peer discovery #3975
Conversation
stormshield-pj50
changed the title
| @@ -159,6 +186,25 @@ where | |||
| if Pin::new(&mut self.timeout).poll_next(cx).is_ready() { | |||
| log::trace!("sending query on iface {}", self.addr); | |||
| self.send_buffer.push_back(build_query()); | |||
| log::trace!("tick on {:#?} {:#?}", self.addr, self.probe_state); | |||
|
|
|||
| let continue_probing = self.discovered.is_empty(); | |||
There was a problem hiding this comment.
Do we need this here if we set it on line 268 already?
I think it is easier to understand if we pair the changes to probe_state with the changes to discovered.
There was a problem hiding this comment.
You're right the check on self.discovered when the timer triggers is useless
stormshield-pj50
force-pushed
the
feat_mdns_initial_delay
branch
from
84e72c3 to
1366ea2
Compare
|
Clippy doesn't seem to be happy though. |
On our side we have an automated docker testsuite and the first mDNS query can be lost if the interface is not ready yet. Anyway the current version works, we just did plug our manual libp2p test tool with it and the mdns peer discovery works as expected, both with a successful and an unsuccessful discovery, the probe ticks logs are OK. |
The code looks good to me too. I am fine merging without an automated test. Thanks for confirming! |
mergify
bot
dismissed stale reviews from thomaseizinger and mxinden
Approvals have been dismissed because the PR was updated after the send-it label was applied.
Description
Peer discovery with mDNS can be very slow, particularly if the first mDNS query is lost. This patch resolves it by adjusting the timer with an adaptive initial interval. We start with a very short timer (500 ms). If a peer is discovered before the end of the timer, then the timer is reset to the normal query interval value (300s), otherwise the timer's value is multiplied by 2 until it reaches the normal query interval value.
Related: #3323.
Resolves: #3319.
Change checklist