TokioMdns takes a long time to discover peers

[Kelo007]

I'm trying to build a tokio version mdns. The code is almost the same as examples/mdns-passive-discovery.rs.

It takes a long time to discover peers from start (about 10 secs).

Is this normal or is there something wrong?

// Copyright 2018 Parity Technologies (UK) Ltd.
//
// Permission is hereby granted, free of charge, to any person obtaining a
// copy of this software and associated documentation files (the "Software"),
// to deal in the Software without restriction, including without limitation
// the rights to use, copy, modify, merge, publish, distribute, sublicense,
// and/or sell copies of the Software, and to permit persons to whom the
// Software is furnished to do so, subject to the following conditions:
//
// The above copyright notice and this permission notice shall be included in
// all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
// OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
// FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
// DEALINGS IN THE SOFTWARE.

use futures::StreamExt;
use libp2p::{
    identity,
    mdns::{MdnsConfig, MdnsEvent, TokioMdns},
    swarm::{Swarm, SwarmEvent},
    PeerId,
};
use log::debug;
use std::error::Error;

#[tokio::main]
async fn main() -> Result<(), Box<dyn Error>> {
    env_logger::init();

    // Create a random PeerId.
    let id_keys = identity::Keypair::generate_ed25519();
    let peer_id = PeerId::from(id_keys.public());
    println!("Local peer id: {:?}", peer_id);

    // Create a transport.
    let transport = libp2p::tokio_development_transport(id_keys)?;

    // Create an MDNS network behaviour.
    let behaviour = TokioMdns::new(MdnsConfig::default()).await?;

    // Create a Swarm that establishes connections through the given transport.
    // Note that the MDNS behaviour itself will not actually inititiate any connections,
    // as it only uses UDP.
    let mut swarm = Swarm::new(transport, behaviour, peer_id);
    swarm.listen_on("/ip4/0.0.0.0/tcp/0".parse()?)?;

    loop {
        match swarm.select_next_some().await {
            SwarmEvent::Behaviour(MdnsEvent::Discovered(peers)) => {
                for (peer, addr) in peers {
                    debug!("discovered {} {}", peer, addr);
                }
            }
            SwarmEvent::Behaviour(MdnsEvent::Expired(expired)) => {
                for (peer, addr) in expired {
                    debug!("expired {} {}", peer, addr);
                }
            }
            _ => {}
        }
    }
}

[thomaseizinger]

Thanks for posting! I had a play around with this locally and can confirm that it sometimes takes longer. After running the example repeatedly though, the discovery is basically instant.

I am not sure where that waiting is happening here to be honest.

[dariusc93]

Honestly thought it was me noticing this. Its rare though but at times do take about 5 to 10 seconds for it to discover but many times its instant. Could maybe test libp2p before commit 89f898c to see if it occurs there with tokio.

[Kelo007]

Actually in my local environment, it's not sometimes but always.

@dariusc93 I did a test. The discovery is instant before commit 89f898c.

[gallegogt]

Hi everyone, I'm going to review to see how it can be improved.

[gallegogt]

Hi @thomaseizinger, @Kelo007 I found something:

The timeout check in the Iface poll (This lines https://github.com/libp2p/rust-libp2p/blob/master/protocols/mdns/src/behaviour/iface.rs#L242-L245), maybe can be moved to this line (https://github.com/libp2p/rust-libp2p/blob/master/protocols/mdns/src/behaviour/iface.rs#L223).

with this we make sure that the query is always sent instantly once the timeout has expired; otherwise you would have to wait for the poll to run again.

[thomaseizinger]

Thanks! That might explain things!

The implementation doesn't quite agree with our coding guidelines. I'll prepare a patch.

[thomaseizinger]

@Kelo007 Can you try your example with #2939 included and check if that fixes it for you?

[Kelo007]

Yes, it is fixed! Thank you very much!