Getting the local address for a discovered service?

[hgomersall]

I'm trying to use mdns-sd on a system that has multiple interfaces. Each interface has a link-local IP address. On the networks those interfaces are connected to are various servers all of which have link-local IP addresses, and all of which advertise themselves with mdns-sd.

My understanding is that this is an acceptable design, and that I can specify a connection by binding a socket to the relevant IP address (which defines the interface). The problem I have is that I can't determine the IP address of the interface that a service was discovered on. I guess I could also know what interface, but it's not clear how I can do that either.

Am I missing something here? It seems like a use-case that should be supported. I'm happy to do the leg-work to make this happen, but I need a bit of a steer on whether the info is available already, and failing that, how I should best implement the changes.

For context, I'm seeing an issue on (at least) Windows where connection to a server takes a long time after a quick mdns-sd discovery. Presumably because the machine does not know which interface to use for the connection so has to try the various interfaces until it finds one that works. I suspect it will break horribly if two machines on different physical networks have the same IP address.

[keepsimple1]

If I understand it, the issue is that when a ServiceResolved event happens, it contains ResolvedService that does not directly say on which interface the event was triggered.

At the high level, this is due to an early decision I made (without realizing the subtle implications): combine address info (resolved) for the same service instance into one resolved struct. In other words, the resolved service is not per interface, i.e. not interface-scoped. In other words, this lib automatically deduplicates the same service found on multiple interfaces.

Now I found that Apple's Bonjour and Avahi on Linux are not doing that, and are reporting services per interface. I think we could change this lib to match that, but it's probably a quite big change that needs some careful design.

I guess I could also know what interface, but it's not clear how I can do that either.

Today you could find out what interface is if it's IPv6: ScopedIpV6 tells which interface reported the address:

mdns-sd/src/dns_parser.rs

Lines 69 to 72 in e3f4e89

	pub struct ScopedIpV6 {
	addr: Ipv6Addr,
	scope_id: InterfaceId,
	}

But you would have to find out the IP address of this interface via other methods. My search shows that it's possible to bind a socket to interface by using interface index, but I haven't done that before.

For IPv4, currently we don't report the interface index that resolved the address. We can add it for ScopedIpV4 so it's at least available for use. Btw, for IPv4, you can generally bind the socket to 0.0.0.0 and let the OS to select the correct interface, because IPv4 link-local address should be unique between interfaces. (That's not true for IPv6).

What's in your use case? IPv4 or IPv6? Does the interface index in ScopedIpV6 help in your case?

[hgomersall]

My system is currently ipv4. I don't think I can currently move to Ipv6 sadly.

It feels one workaround is to run the discovery step separately for each interface, though I haven't tried that. Is there a reason that would not work?

It does seem that services discovered on separate interfaces should not be combined. Conceptually should they not be considered as entirely separate networks? I guess one could design a routing that meant the same service is discovered on multiple interfaces, but that must be relatively uncommon. It feels to me a service should be identified by both its service name and the interface on which it was discovered (and ideally the local IP address of that interface should be available for convenience).

[keepsimple1]

My system is currently ipv4. I don't think I can currently move to Ipv6 sadly.

I've created a PR #439 to add interface_id() support for IPv4. As a short term fix, would you be able to get the local IP address for the returned interface and help the use case at hand?

It feels one workaround is to run the discovery step separately for each interface, though I haven't tried that. Is there a reason that would not work?

If use disable_interface(IfKind::All) paired with enable_interface(an_interface), it is possible but might be too tedious? I would suggest to try out the new interface_id() for ScopedIpV4 in the PR first.

Conceptually should they not be considered as entirely separate networks?

It depends. If a computer has both WiFi and Ethernet connected to the same network, then they will see the same service on both interfaces. And that could happen quite easily on a home network. (That said, I'm thinking about possible change for the longer term)

[hgomersall]

It depends. If a computer has both WiFi and Ethernet connected to the same network, then they will see the same service on both interfaces. And that could happen quite easily on a home network. (That said, I'm thinking about possible change for the longer term)

Maybe the simplest solution would be set this as an option method on ServiceDaemon. Something like prune_duplicate_services(bool).

[hgomersall]

It depends. If a computer has both WiFi and Ethernet connected to the same network, then they will see the same service on both interfaces. And that could happen quite easily on a home network. (That said, I'm thinking about possible change for the longer term)

Thinking about this some more, in general mdns-sd has no way of knowing whether a service is a duplicate or unique based only on its service-name/IP and interface. It would also need some info about routing to make that inference. What do other libraries do here?

It also, presumably, leaves ambiguity as to which interface will be used when connecting to a given service. In the example of wifi or ethernet, should one of those be preferred, or left to the downstream code, or what? There are clearly non-trivial policy implications of making a decision inside mdns-sd.