zenohour desired application case (mentioned in the issue) is most welcome! Thanks again!
Thanks Julien and Angelo! As you may have guessed, Aaron and I work together :smile: and yes, we are interested in exploring Zenoh precisely for the discovery-scaling reasons you mention. Thanks!
Next question: a common pitfall with mobile robots is that their WiFi connections are often spotty as they drive around. If I understand correctly, Zenoh is built on top of TCP. Do you have a feel for how Zenoh would be able to handle WiFi connections that appear and disappear fairly often?
Thank you. So we've actually been seeing on some "larger" enterprise WiFi networks (say ~10 AP's to start) that multicast (even for discovery) is not particularly reliable, and we've been having better luck by using unicast discovery and messaging. I'm not sure if that's particular to our network situations, or if that's a general statement for "larger" enterprise WiFi networks. In any event, I assume that Zenoh can also discover over unicast to a known endpoint.
Our applications often include mixture of low-bandwidth topics (small messages like "please open door 42" or "here is my XYZ position") and high-bandwidth topics with frequent large messages, like a camera stream. For the high-bandwidth topics, I'm under the impression (please correct me if I'm wrong) that TCP generally will allow higher throughput for large messages, so long as not-too-many packets are dropped, but that TCP may have a less-graceful hiccup recovery from a WiFi outage. Are there things that Zenoh can do to "help" TCP quickly recover from hiccups, or is the general recommendation instead to always use UDP for applications where occasional connection drops are expected? Thank you!