Thanks for mdns-sd — it's the discovery backend for matter-rust, and this is the first real trouble we've had with it.
Up front: I have not been able to reproduce this on my own network. It comes from a user's environment, with traces, and I'd value your read on whether it's expected behaviour before I go further.
Symptom
On a network with ~18 instances of one service type, ServiceFound fires for every instance almost immediately, but ServiceResolved arrives for only a handful — roughly one instance per query cycle, following the retransmission backoff. Instances that don't get resolved early are effectively unreachable for minutes.
This was captured with the query example on _matter._tcp, unmodified:
At 322.513µs: SearchStarted("_matter._tcp.local. on 2 interfaces [wlp170s0 (3), lo (1)]")
At 46.647774ms: SearchStarted(...)
At 317.055798ms: ServiceFound(..., "2C755BDFDBFDF8A2-00000000AAB08AA7._matter._tcp.local.")
... 18 ServiceFound events, all within ~1 ms of each other ...
At 317.174405ms: ServiceFound(..., "F52AC107C954E38E-0000000000000002._matter._tcp.local.")
At 317.181164ms: ServiceFound(..., "F52AC107C954E38E-0000000000000003._matter._tcp.local.")
At 317.187235ms: ServiceFound(..., "F52AC107C954E38E-0000000000000004._matter._tcp.local.")
At 522.524688ms: ServiceFound(..., "2C755BDFDBFDF8A2-00000000DFCB37CC._matter._tcp.local.")
At 523.018225ms: Resolved a new service: 2C755BDFDBFDF8A2-00000000DFCB37CC._matter._tcp.local.
At 523.104915ms: ServiceFound(..., "2C755BDFDBFDF8A2-0000000000840C83._matter._tcp.local.")
At 523.402917ms: Resolved a new service: 2C755BDFDBFDF8A2-0000000000840C83._matter._tcp.local.
At 1.046694972s: SearchStarted(...)
At 3.047705459s: SearchStarted(...)
At 3.387661735s: ServiceFound(..., "2C755BDFDBFDF8A2-000000006EC96BF5._matter._tcp.local.")
At 3.387926987s: Resolved a new service: 2C755BDFDBFDF8A2-000000006EC96BF5._matter._tcp.local.
At 7.049050317s: SearchStarted(...)
At 7.285577326s: ServiceFound(..., "2C755BDFDBFDF8A2-00000000F141DDE6._matter._tcp.local.")
At 7.285753229s: Resolved a new service: 2C755BDFDBFDF8A2-00000000F141DDE6._matter._tcp.local.
The three F52AC107C954E38E-* instances are the ones the user actually needed. They are found at 317 ms and never resolved — not within the 30 s his application waits, and not within the visible trace.
The resolutions that do happen land immediately after a SearchStarted, which is what suggests one-per-cycle rather than a general delay.
Why it bites
Our consumer waits up to 30 s to resolve one specific instance by name. On this network that succeeded under ~5% of the time, and the same code against the same devices worked reliably with a different mDNS implementation, and avahi-browse showed everything. So the records are on the wire and being received — resolution just doesn't complete for most of them.
What I checked
- Reproduced on 0.20.x; I read the 0.20.3 and 0.21.0 changelogs and neither looks related.
- On my own network I cannot reproduce it: a browse of the same service type with 16 instances resolves 16/16 in under 500 ms, repeatedly. So there is an environmental factor I haven't isolated — his devices are IPv6-only (Thread, behind a border router) and their SRV targets are separate
.local. hostnames; mine are a mix and mostly dual-stack.
- Narrowing the browse to a DNS-SD subtype (3 instances instead of 18) resolves all three of his targets in ~266 ms on the same machine and network. That's our workaround, and it points at instance count or per-instance follow-up work rather than anything about those specific records.
Question
Is one-instance-per-query-cycle the expected resolution rate for a browse with many instances, or should follow-up SRV/address queries be issued more aggressively when several instances are pending? Happy to gather more data from that environment — the user has offered — or to test a patch.
Trace courtesy of @qwandor, who reported it downstream and did most of the legwork narrowing it.
Thanks for mdns-sd — it's the discovery backend for matter-rust, and this is the first real trouble we've had with it.
Up front: I have not been able to reproduce this on my own network. It comes from a user's environment, with traces, and I'd value your read on whether it's expected behaviour before I go further.
Symptom
On a network with ~18 instances of one service type,
ServiceFoundfires for every instance almost immediately, butServiceResolvedarrives for only a handful — roughly one instance per query cycle, following the retransmission backoff. Instances that don't get resolved early are effectively unreachable for minutes.This was captured with the
queryexample on_matter._tcp, unmodified:The three
F52AC107C954E38E-*instances are the ones the user actually needed. They are found at 317 ms and never resolved — not within the 30 s his application waits, and not within the visible trace.The resolutions that do happen land immediately after a
SearchStarted, which is what suggests one-per-cycle rather than a general delay.Why it bites
Our consumer waits up to 30 s to resolve one specific instance by name. On this network that succeeded under ~5% of the time, and the same code against the same devices worked reliably with a different mDNS implementation, and
avahi-browseshowed everything. So the records are on the wire and being received — resolution just doesn't complete for most of them.What I checked
.local.hostnames; mine are a mix and mostly dual-stack.Question
Is one-instance-per-query-cycle the expected resolution rate for a browse with many instances, or should follow-up SRV/address queries be issued more aggressively when several instances are pending? Happy to gather more data from that environment — the user has offered — or to test a patch.
Trace courtesy of @qwandor, who reported it downstream and did most of the legwork narrowing it.