keepsimple1

From your log, it looks like it was because an address record was received with different `cache_flush = false` (ttl = 60) , which previously cases are `cache_flush = true`...

> With a longer time testing, it seems the problem not completely gone. I will debug it further tomorrow. I debugged a it more. Looks like it was because I...

PR #217 merged. Thank you for testing diligently!

The `ip` in `ServiceInfo::new()` is meant to support one or more unicast IP addresses. I'm actually not aware of use cases where a multicast IP is used for registering a...

> but I'm not actually sure what the "listener" sees as the source address for packets that are sent to it (it might be the multicast address, but I think...

> Providing an A record for a multicast address for which a mDNS responder is the authoritative source for data being sent to a multicast group would fall under the...

Support for section 7.2 (multi-packet) is merged in for the querier side (PR above). We will submit a new PR for the responder side when it's feasible / ready.

Thanks for opening the issue! It seems a valid use case. I've opened a PR to address this based on my understanding. If you got chance, let me know if...

> I am advertising the services: > > * `node._sub._my-service._udp.local.` with the metadata `{ "i": "0" }` > * `another._sub._my-service._udp.local.` with the metadata `{ "i": "1" }` do you advertise...

Let me think a bit about `browse_all()` API. And, it seems to me that there are 2 things in play: 1. One service instance advertising more than 1 sub service...