keepsimple1

I think this PR might be too involved. And since the full diff will introduce some breaking changes, I am wondering if we can split it into two steps: 1)...

> 1. Does the daemon runs in its own process (like mdnsResponder)? Or is it a detached thread? A detached thread. It's mentioned in the doc: https://docs.rs/mdns-sd/0.13.2/mdns_sd/ > 3. Does...

I think this is resolved. If not, please feel free to re-open it or to create a new issue. Thanks!

The reason is in this loop: ```rust while let Ok(event) = receiver.recv_timeout(Duration::from_secs(5)) { println!("{:?}", event); } ``` Every time an event is received, the timeout is reset for another 5...

> But since `receiver` is a re-exported method from `flume`, we have a different [documentation](https://docs.rs/flume/latest/flume/struct.Receiver.html#method.recv_timeout). Is it possible to achieve the same result as in `flume`? Sorry, I didn't get...

> But these two loops > > /// mdns-sd > while let Ok(event) = receiver.recv_timeout(Duration::from_secs(5)) { > println!("{:?}", event); > } > > // flume > while let Ok(msg) =...

> That being said, how can I obtain this condition, the whole loop should always take 5 seconds, through recv_async and an external timer? I'm sure there are many ways....

There is a pending issue with the changes on the Responder side for this feature: Per [RFC 6762 section 7.2](https://datatracker.ietf.org/doc/html/rfc6762#section-7.2): ``` A Multicast DNS responder seeing a Multicast DNS query...

Because of the issue describe in earlier comments, I decided to merge in the support for the querier side first. This will unblock Known-Answer feature, except not supporting the multi-packet...