keepsimple1
Feature request: a simple way to automatically uniquify the service name when other hosts already have the desired name.
This might be desired behaviour following from my understanding of the correct way mDNS-SD should function. I might also be misusing the library.
I have a service running and advertising on a Linux machine. If I run the same executable on a different (Windows) machine, when I run my discover code I see the first machine advertised from the Windows machine as well as from the original Linux machine. I know this is the case as the TXT record contains a UUID generated from each server. I then receive two records advertising the Linux machine, each with a different UUID.
This is not a huge problem, as I can filter on repeated IP addresses, but it seems a little odd to re-advertise a service not explicitly registered.
Ok, I think I understand what is going on here. The resolver is finding other machines in the network with the same name but different IP address. It's not clearly what, if anything, one should do about this.
I suppose the point here really is to have a way to automate the RFC 6763 Appendix D policy of updating the name to something unique. This would be a useful feature.
Perhaps a function on ServiceDaemon that takes a name and returns a unique version of it based on a standard policy.
It's surely a useful feature! (It even feels overdue now you mentioned it)
Perhaps a function on ServiceDaemon that takes a name and returns a unique version of it based on a standard policy.
yeah, this could be defined as a new event that can received by a daemon handle. I will take a look at the scope. (It seems like a substantial feature as we need to support Probing and Conflict Resolution. It'll a lot of fun implementing it ;-) )
Yeah, I was thinking about this and it's not entirely trivial to work around potential races. It's not hard to envisage two servers fighting in tandem to get a unique name! (though I might be missing something about how it works).
Edit: this is clearly addressed in rfc 6762 as you linked to!
Yes please!
Something I'd like to request is either a user supplied function/closure for the conflict resolution algorithm, or at least some kind of hook or callback with the newly resolved name.
If I remember correctly, this was either hard or impossible with Avahi. Bonjour did have some of interface for this (again, if my memory serves).
The new conflict-resolved name should be saved in some kind of non-vol storage to be used on the next system start. Having some kind of callback would allow custom implementations, like for embedded systems.
Something I'd like to request is either a user supplied function/closure for the conflict resolution algorithm, or at least some kind of hook or callback with the newly resolved name.
As the first / current phase, I'm looking into generating an event with the newly resolved name (as the RFC seems to mandate automatically generated name). Will keep the option of user supplied conflict resolution open / possible.
@hgomersall I've opened a PR #265 that implements the basic conflict resolution (and required probing). When you have time, could you please take a look and give it a try?
I also updated the example register.rs to support input of hostname and --disable-ipv6 option to help testing conflict resolution easily (using same names on two different machines):
Usage:
cargo run --example register <service_type> <instance_name> <hostname> [options]
Options:
--unregister: automatically unregister after 2 seconds
--disable-ipv6: not to use IPv6 interfaces.
Not sure where I saw it in the RFC's, or maybe it was in some Apple docs? Service names get uniqueified like " (N)", but host names should be like "-N". Don't want to have spaces in host name. (Parens are probably out too).
Not sure where I saw it in the RFC's, or maybe it was in some Apple docs? Service names get uniqueified like " (N)", but host names should be like "-N". Don't want to have spaces in host name. (Parens are probably out too).
Thanks! This makes sense. I've updated my PR to reflect this.
PR merged. Please let me know if any problems. We can iterate / fix things before the next release.
A new release 0.12.0 is published and includes this feature. Any comments / feedbacks are very appreciated, and will be helpful for adding the support of custom function of name conflict resolution.
I'm debating with myself whether we should / are ready to add support of custom function of name conflict resolution.
My view of adding such support:
- Pros: give the library user more flexibility.
- Cons: quite more complex code.
My take: only add the custom function if there is a strong desire for it in real use cases.
Any comments are appreciated.
What do you think this would look like? A method on the ServiceDaemon to add a callback, like this?
That feels like quite a clean way to add functionality without complicating additional stuff. Getting the right signature of the callback would be important and also there is additional complexity around making sure a valid and unique name is returned.
What do you think this would look like? A method on the
ServiceDaemonto add a callback, like this?
Yes this is similar with what I've imagined. (we probably need the callback to return a String)
That feels like quite a clean way to add functionality without complicating additional stuff. Getting the right signature of the callback would be important and also there is additional complexity around making sure a valid and unique name is returned.
Yes we would need to validate the name. The uniqueness can be checked as part of probing.
My only concern is that if this feature (custom function) is really needed. Is our current name change logic sufficient / working well?
My only concern is that if this feature (custom function) is really needed. Is our current name change logic sufficient / working well?
Indeed. I certainly don't have the need for any more.
Greetings All,
It's been a while (two jobs, 6 years ago) that I was heavily involved with the LXI spec and Test & Measurement, which uses mdns for device discovery. One of the requirements is that the new unique name needs to be saved in non-vol for the next boot. One of the things that really frustrated me about Avahi is that there was no hook for when the host name needs to be changed to make it unique. It is really important that the new name is saved so that, for example, if you have a meter.local and then add another, it becomes meter-2.local. If the meter-2 device starts up first or is currently the only device, you still want to talk to it as meter-2. You don't want the names to keep changing all the time depending on which device starts up first.
So it's important to not only provide a way to make a new name, it's also important to provide a way to allow the application to know when name changes.
Thanks! -Dale
On Thu, May 15, 2025 at 4:34 AM Henry Gomersall @.***> wrote:
hgomersall left a comment (keepsimple1/mdns-sd#264) https://github.com/keepsimple1/mdns-sd/issues/264#issuecomment-2883019824
My only concern is that if this feature (custom function) is really needed. Is our current name change logic https://github.com/keepsimple1/mdns-sd/blob/60888b703486667bcc21738923d47600c3dffe41/src/service_daemon.rs#L3515 sufficient / working well?
Indeed. I certainly don't have the need for any more.
— Reply to this email directly, view it on GitHub https://github.com/keepsimple1/mdns-sd/issues/264#issuecomment-2883019824, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA4AUUMDT7L5INB45RPRFT26RGQXAVCNFSM6AAAAABPYZSN3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOBTGAYTSOBSGQ . You are receiving this because you commented.Message ID: @.***>
If the meter-2 device starts up first or is currently the only device, you still want to talk to it as meter-2. ... So it's important to not only provide a way to make a new name, it's also important to provide a way to allow the application to know when name changes.
Greetings! It's cool to hear about LXI.
To help myself understand, in the case of the meter-2 device reboots, even it's the only device, would the application still register its hostname as meter and expect the mdns lib (say mdns-sd) to automatically change the hostname into meter-2 and send a notification to the application?
If that's correct, when will the application expect the device use its original hostname meter again (if ever) ? Maybe an explicit call to the mdns lib?
On Sat, May 17, 2025 at 10:04 PM keepsimple1 @.***> wrote:
keepsimple1 left a comment (keepsimple1/mdns-sd#264) https://github.com/keepsimple1/mdns-sd/issues/264#issuecomment-2888707342
If the meter-2 device starts up first or is currently the only device, you still want to talk to it as meter-2. ... So it's important to not only provide a way to make a new name, it's also important to provide a way to allow the application to know when name changes.
Greetings! It's cool to hear about LXI.
To help myself understand, in the case of the meter-2 device reboots, even it's the only device, would the application still register its hostname as meter and expect the mdns lib (say mdns-sd) to automatically change the hostname into meter-2 and send a notification to the application?
No, it should attempt to only register meter-2. Basically, when it uniqueifies to meter-2, it should update /etc/hostname or call sethostname (or both?) or whatever way the system would save the hostname configuration across reboots/powercycles.
If that's correct, when will the application expect the device use its
original hostname meter again (if ever) ? Maybe an explicit call to the mdns lib?
For LXI devices, there is a required method ("LCI" Lan Configuration Initialize in LXI speak) to reset to system defaults. Can be a physical reset button or a menu on a display.
https://public.lxistandard.org/specifications/LXI_1.6_Specifications/LXI_Device_Specification_1.6.1_2024-01-18.pdf#%5B%7B%22num%22%3A247%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C87%2C258%2C0%5D
I don't think mdns-sd needs to do all that, just provide an interface (name change callback?) to allow that to happen.
I'm not sure but I think the RFCs specify something like this too. I'll take a look...
-Dale
Message ID: @.***>
On Sun, May 18, 2025 at 10:46 PM Dale Smith @.***> wrote:
I'm not sure but I think the RFCs specify something like this too. I'll take a look...
Yes, in rfc6762 section 9: https://datatracker.ietf.org/doc/html/rfc6762#page-32
3. Once an available unique name has been determined, by probing
without receiving any conflicting response, record this newly
chosen name in persistent storage so that the device will use
the same name the next time it is power-cycled.
-Dale
Message ID: @.***>
I don't think mdns-sd needs to do all that, just provide an interface (name change callback?) to allow that to happen.
Currently mdns-sd implemented a conflict resolution with a callback like this:
- The application calls
ServiceDaemon::monitor(). - When a name change happens,
mdns-sdsends an event to the application viaDaemonEvent::NameChange(DnsNameChange), which provides the following info:
pub struct DnsNameChange {
pub original: String,
pub new_name: String,
pub rr_type: RRType,
pub intf_name: String,
}
Does it work for your use case?
Ah! Looks perfect!Sorry about the noise. I didn’t realize this was available and my pain points with avahi prompted me to comment. -DaleSent from my iPhone...Beware of typos!On May 19, 2025, at 12:49 AM, keepsimple1 @.***> wrote: keepsimple1 left a comment (keepsimple1/mdns-sd#264)
I don't think mdns-sd needs to do all that, just provide an interface (name change callback?) to allow that to happen.
Currently mdns-sd implemented a conflict resolution with a callback like this:
The application calls ServiceDaemon::monitor() . When a name change happens, mdns-sd sends an event to the application via DaemonEvent::NameChange(DnsNameChange), which provides the following info:
pub struct DnsNameChange { pub original: String, pub new_name: String, pub rr_type: RRType, pub intf_name: String, }
Does it work for your use case?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
No problem! I think we should improve the doc for the users to discover this feature more easily.
Update: opened PR #359 .
I think the main feature request of this issue is done. If there is a need to support a custom function plug-in for name changes in future (see early comment), please open a new issue and link to this issue.
Thanks all!