go-libp2p
go-libp2p copied to clipboard
libp2p
mDNS's new implementation doesn't perform as well
Sorry, no hard number to provide other than "upgrading to the new implementation makes my test fails all over the place, randomly.
I have a series of go test for my project that simulate locally the interactions of a series of services. Those test rely on mDNS for local discovery.
Until now I had a simple time.Sleep() to give this discovery some time to connect, everything was fine. While updating to a more recent go-libp2p, I changed my code to use the new mDNS implementation, resulting in broken tests. I changed my time.Sleep() by something smarter that wait until the discovery worked, up to a minute, but that doesn't seems to be enough.
It seems to me that often the discovery is slower, and sometimes never succeed in a 1 minute period.
Is that something to expect? Is this a bug?
That's not expected, and might very well be a bug.
Are you still using the old mDNS in parallel? We might have another issue with one of the two implementations that might or might not be related: https://github.com/ipfs/go-ipfs/issues/8695.
In general, mDNS discovery should be fast. Nodes that join the network will query their peers, so they should receive a response very quickly. Have you tried running WireShark to see what's going on on the wire?
Are you still using the old mDNS in parallel?
Not in parallel but when I replaced it with mdns_legacy everything worked again.
Have you tried running WireShark to see what's going on on the wire?
No. I can give it a try but I'm familiar at all with what mDNS should looks like.
I tried to wireshard a bit. While with the legacy implementation it does show up in wireshark on localhost, the new implementation traffic either doesn't show up or is not recognized properly.
2022-04-27 conversation: wireshark-level view is needed here. We're not sure why the new mdns is not showing up for @MichaelMure . This is likely ~.5 day of work to debug. We've downgraded to P2 as there are other peer discovery mechanisms we rely on.
@MichaelMure Could you share your tests or any small reproduction of your issue, please?