DNSConn makes excessive UDP Bind calls

[nemosupremo]

I noticed one our services experiencing excessive load after several hours under what should be minimal conditions (on a machine with 2 cpus and 48 cores, the 1 minute load average was as high as 200). After some sleuthing we discovered that that the majority of our program was spending time in a. single function: webrtc_mdns::conn::DnsConn::get_interface_addr_for_ip.

I'm not sure if its a function of our network (we have ~200 devices on the network potentially doing mdns stuff), but what is odd is this occurs without any peerconnections open; I'd expect that after negotiation, or after the peerconnection is dropped, that the DnsConn task would be stopped as well.

Setting set_ice_multicast_dns_mode(MulticastDnsMode::Disabled) seems to solve the problem, but as I understand it this prevents Chrome from negotiating connections on a local network. Attached is a perf flamegraph of what I was seeing.

I'm not sure how to solve this problem, so any pointers on how specifically mdns is used within webrtc could help and the purpose of the DnsConn server.

I took a look at what pion/mdns and noticed one difference: In Pion when we receive a packet we will only call get_interface_addr_for_ip only after a call to p.Question(). I don't know enough about the protocol, but this may provide a form of soft rate limiting so that we are not calling get_interface_addr_for_ip every time we get some data on the port.

If anyone could confirm that this line of reasoning makes sense I can draft a PR.

[metaclips]

Seems we called the get_interface_addr_for_ip function too early, created a PR for a fix, do check it out.

[k0nserv]

Reopening based on the discussion that @nemosupremo raised around caching.

[k0nserv]

We have migrated this crate to the monorepo(webrtc-rs/webrtc) please re-open this issue over there.