I run Snapclient on a laptop that sometimes switches between an ethernet and a wifi connection (depending on my mood and location in my house). Unfortunately, this causes Snapserver to treat my laptop as two separate clients depending on how it is connected (since my ethernet and wifi connections have distinct MAC addresses).
This means I have two clients listed in the Snapserver config and responses, which is unnecessary since I am never running multiple instances on my laptop at the same time. Having two listed also causes issues with API consumption, because there isn't a consistent ID to reference my laptop Snapclient with.
Providing --instance doesn't currently do me any good, because the base clientID still depends on the MAC address, which changes depending on how I am connected to the network.
There's a couple different ways I could see this changing:
--instance from a number that gets added to the MAC address to overriding the full clientID.--clientID parameter that overrides the full clientID, and deprecate --instance (or it could be kept, but may be semi-redundant).This might also be useful in situations like #246 (and on iOS, were this ever to be ported there 馃榿 ), where the MAC address is not accessible via SDK.
It seems that there are some good candidates listed here, e.g. gethostid() or /var/lib/dbus/machine-id
For Android getprop ro.serialno seems to be a good solution.
I would like to keep the general approach of having some unique machine identifier and use the instance id to enumerate multiple instances.
The develop branch introduces a getHostId function, that will return the host name as a last resort.
I think I will extend this function to use gethostid() and/or other things, depending on the OS.
I agree that there should be a base default unique machine identifier generated (for people who don't care to mess with it), but could you allow that base unique ID to be overridden via a command-line argument? Without that (or at least have the ability to force it to use hostname, or some other machine-specific characteristic instead of an interface-specific MAC address) anyone connecting with multiple network interfaces will have multiple client entries in Snapserver that refer to the same machine 馃槙 .
Regarding gethostid(), that article says Since the semantics of this ID are not clear and most often is just a value based on the IP address it is almost always the wrong choice to use..
Also, neither /etc/hostid nor /var/lib/dbus/machine-id exist on macOS.
yep, gethostid() seems to be a bad choice :grinning:
I think that Snapcast's getHostId() now creates a more or less reliable host ID for most OSes, using MAC address and host name as fallback.
Because I couldn't find any working solution for FreeBSD and because of the "more or less" reliability, I will add the --clientID command line option to override the automatic ID creation.
This will in fact make --instance semi-redundant, but will not break the existing command line interface.
Fixed in version v0.12.0
Most helpful comment
yep,
gethostid()seems to be a bad choice :grinning:I think that Snapcast's
getHostId()now creates a more or less reliable host ID for most OSes, using MAC address and host name as fallback.Because I couldn't find any working solution for FreeBSD and because of the "more or less" reliability, I will add the
--clientIDcommand line option to override the automatic ID creation.This will in fact make
--instancesemi-redundant, but will not break the existing command line interface.