You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like libmdns does not probe on startup according to the mdns specification
When a service is registrered, the 'send_unsollicited' function is triggered but this sends out a Query Response out to the multicast group
Shouldn't we first send a few rounds of DNS Queries questioning whether anyone has records for the service we wish to occupy and then after some time and nobody answered we announce the service?
Currently libmdns is only a responder and cannot perform queries. I'm still maintaining this lib but very much just to merge Pull Requests. Querying support would be very welcome (#5 ) but I'm personally unlikely to add anything substantial to this lib any time soon.
The first startup step is that, for all those resource records that a
Multicast DNS responder desires to be unique on the local link, it
MUST send a Multicast DNS query asking for those resource records, to
see if any of them are already in use.
I think probing is only required when a service is expected to be unique. You're right that this would be a good thing to add. But again, really it's blocked on #5 being completed
willstott101
changed the title
Probing and announcing not implemented?
Probing before announcing not implemented?
Nov 7, 2022
willstott101
changed the title
Probing before announcing not implemented?
Probing before announcing is not implemented
Nov 7, 2022
It seems like libmdns does not probe on startup according to the mdns specification
When a service is registrered, the 'send_unsollicited' function is triggered but this sends out a Query Response out to the multicast group
Shouldn't we first send a few rounds of DNS Queries questioning whether anyone has records for the service we wish to occupy and then after some time and nobody answered we announce the service?
https://www.rfc-editor.org/rfc/rfc6762#section-8
The text was updated successfully, but these errors were encountered: