Multiple interface address case

[anti-social]

I have a service with 2 addresses on an interface (192.168.1.148/24 and 10.238.0.51/24) and a discoverer with only one address (192.168.1.2/24). With this configuration the discoverer does not always discover the service. In wireshark I can see that sometimes the service chooses 10.238.0.51 ip address to communicate (as addresses are stored in a HashSet it depends on its seed). Thus the discoverer does not see these packets as it does not have such an address.

I think it would be worth sending dedicated announcements for every address on an interface and responses only for matched addresses with a source one. I have a quick patch which implements this behavior although it is a little hacky.

[keepsimple1]

That's indeed a problem. I've created a PR #460 to fix that, could you please give a try? Please feel free to comment on the PR.

[anti-social]

What do you think about an option to filter out resolved addresses to return only ones that are matched to the interface networks? Something like:

service_daemon.same_subnet_only(true);

Why it would be nice to have this option. To do the same thing in the application we will have to add additional dependencies to scan network interfaces to be able to filter out unsolicited addresses.

Either we could add some flag to the ScopedIpV4 and ScopedIpV6 structs.

[keepsimple1]

Instead of a daemon-wide flag like service_daemon.same_subnet_only, maybe we can support an option to filter per-browse? Something like:

pub fn browse_with(&self, service_type: &str, options: BrowseOptions)
    -> Result<Receiver<ServiceEvent>>;

pub struct BrowseOptions {
    pub same_subnet_only: bool,
    // pub cache_only: bool,  (then we can deprecate browse_cache)
    // room to grow
}

The rationale is that different queriers might want different policies for whatever reason (say, a particular service type).

It would need some plumbing to filter out unwanted addresses when sending back ServiceResolved event, but I think it's doable. And if addresses were all filtered out, the event will not be sent.

And I think such API could be further extended to support other features in the future. What do you think?

[anti-social]

Yep, I like it. Then I'll try to make a PR