keepsimple1

> * I don't think I can extend the instance name to also include the subservice name because it will probs overflow the DNS record. Right now it would be...

> For 1) I am not exactly sure what you're saying. Could you please clarify? Currently one service instance can only have one subtype (if any), which is stored in...

> Let me think a bit about `browse_all()` API. Just wanted to follow up, sorry being a bit late, I feel that adding such API is too much hack for...

Thanks for stepping up and take the initiative! Here is a list of tasks on my mind: - [ ] sockets for receiving: currently `Zeroconf::intf_socks` only processes multicast packets, these...

> The best example I've found so far is the [multicast socket](https://github.com/bltavares/multicast-socket) crate. So a potential way forward could be to base the implementation on this, although it would require...

> What prevents us from using the `nix` crate though? `winapi` is the windows equivalent to nix in the end ^^; In this crate, we moved away from `nix` to...

> I think looking at the destination address could tell if it's unicast or multicast. The multicast packets be sent to the multicast address, but unicast to the host address....

It's awesome you created the `socket-pktinfo` crate! Nice work! I'd love to use it to solve this issue, but I do have some other thinking going on: Recently after discussing...

> My present understanding (which I should verify) is that you can control selection of multicast network interface by binding the socket to the local IP of the interface, and...

> Might need to use the SO_REUSEPORT socket option? yes we're using this option (when supported, otherwise SO_REUSEADDR).