-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mDNS: update domain lib; fix various issues #186
Conversation
@kedars If that's not clear ^^^ does not yet implement the "query" portion. But it tries to fix the pre-existing "responder" logic to operate well-enough, so that I hopefully finally get rid of the mDNS lookup timeouts I see from time to time in my own setup over here - in the Commissioner... |
9de2e48
to
6fc9713
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What a can of worms I opened...
:-D
I have spent too much time debugging 'device not accessible over time' issues in the field, distill down to mDNS discovery, depending upon how a particular implementation works, and interoperates with other entities on the network.
Are you considering the built-in implementation for just quick-developer use cases or production options too? If you intend to continue to evolve the built-in implementation:
- I wonder if we should spit it out into a separate project since it will get complicated, and also so that it has a wider applicability, and a better chance of surfacing and fixing issues.
- There is a Bonjour Conformance Test (BCT), available for download on Apple's site (require's Apple developer account) https://developer.apple.com/bonjour/. It also has chattiness tests across a few hours to ensure we aren't creating large bursts. I doubt if many of the current implementations even pass this though.
Great question. So if
Also a great question. The implementation in Reason why I'm not actively pushing for inclusion of this library as a dependency in
So for the short to mid-term - as painful as it is for me - I think we should keep our own mDNS implementation in-tree in
Great idea! Let me look into it (but possibly after merging the BTP PR, as it is next on my list). |
BTW one more reason why we need e2e tests - after my changes, the code was supposed to send to the multicast addresses. Yet - due to a single-line bug - it was still sending to the unicast address. Fixed now (and re-tested), but yes I think we do need e2e - it would be not impossible but difficult to catch such type of errors with unit tests. |
I started looking at the mDNS and DNS-SD RFCs recently w.r.t. what it would take to implement the "query" portion of mDNS in our built-in pure-Rust responder. (So that we can initiate brand-new sessions for subscriptions, or update existing sessions to their new peer IP address, in case such a change is detected.)
What a can of worms I opened...
While the mDNS and DNS-SD specs look deceivingly simple (great work by the author BTW as in the specs are super easy to read), and while the
domain
lib does the heavy-lifting of DNS record parsing / creation for us... these specs are actually complex in that there is a lot of complexity hidden in there not in terms of DNS record parsing/creation, but how an mDNS responder/queryer should react in various circumstances (as in - when to accept unicast requests; when to generate delays before broadcasting; what additional data to put in the mDNS record; and the list goes on...)Anyway, to cut the long story short, this PR addresses the following deficiencies we have in our current mDNS impl (in severity order):
Since the PR was ending up large-ish, I also upgraded
domain
to the next version (0.10). This increased our Rust MSRV from 1.77 to 1.78. Upgrading got rid of a potential future large refactoring (domain lib authors renamed the notion of "dname" to just "name" everywhere) and also we could get rid of theheapless 0.7
"appendix" dependency that we no longer need. And from the "octets" crate which is now re-exported by the new "domain" lib.So yes, I think this should go in.
Are we 100% compliant yet after this PR?
Far from it. I also think we might never get fully compliant with mDNS and DNS-SD. But... we just need to be "compliant enough" and not generate too much "network noise".
I have my doubts that other MCU-based mDNS implementations are very compliant either (due to code complexity yet limited flash size).