atolab/zenoh

a protocol with zero overhead and powerful abstractions

Julien Enoch

@JEnoch

I don’t see the output of the curl command in your snapshot. Could you please share it ?

Julien Enoch

@JEnoch

A simple scenario to test pub/sub with 1 router and 2 clients is the following:

Start: zenohd.exe -v
in another shell in zenoh-python, start: python3 examples/zenoh/z_sub.py
in another shell in zenoh-python, start: python3 examples/zenoh/z_pub.py

Harmouch101

@Harmouch101

i want that the function get_storage works fine

anyway i will try to delete the package and then reinstall it

thanks for your advices

Julien Enoch

@JEnoch

Your curl command is not the correct one. Please use port 8000 instead of 7447 in URL

port 7447 is for the zenoh protocol.
port 8000 is used by the HTTP/REST plugin of zenoh

curl -g http://172.17.0.1:8000/@/**

Harmouch101

@Harmouch101

ah ok

Julien Enoch

@JEnoch

BTW, we also have an online infrastructure of 4 interconnected zenohd routers that you can use for testing:

You can use test your scripts replacing the z.login(None) with:
z.login("tcp/eu-central.yaks.is:7447")

Harmouch101

@Harmouch101

ok great

Julien Enoch

@JEnoch

You can also use this curl command to list the storages:
curl -g http://eu-central.yaks.is:8000/@/**/storage/**

You can put values in stores with such curl command:
curl -X PUT -d "this is a test" http://eu-central.yaks.is:8000/demo/eu/test

And get key/values from storages with:
curl -g http://eu-central.yaks.is:8000/demo/eu/**

Julien Enoch

@JEnoch

I’m leaving for now. I’ll be back tomorrow if you have more questions or need of help.

Harmouch101

@Harmouch101

thanks a lot <3

Angelo Corsaro

@kydos

@/all I wanted to let you know that as zenoh is now an Eclipse Project the development discussion will take place on the zenoh-dev@eclipse.org mailing list. I suggest you subscribe at https://accounts.eclipse.org/mailing-list/zenoh-dev

Angelo Corsaro

@kydos

@/all we have just added support for natively dealing with integer and floating point types. These changes are now in the zenoh master as well as on the zenoh-python API. We are now working to add the support on other programming languages. As a consequence of this extension now it is possible to do w.put("/some/temperature/sensor", 23.2)

To try out check out and install out of the master and let us know if you have any issues!

Morgan Quigley

@morganquigley_gitlab

Greetings. Not sure if this is the ideal place for this question (happy to be directed elsewhere) but how are things looking security-wise? TLS ? Thanks!

Aaron Chong

@aaronchongth

Hello all! thanks for the comments on eclipse-zenoh/zenoh-python#27, any advice for using zenoh our desired application case (mentioned in the issue) is most welcome! Thanks again!

Julien Enoch

@JEnoch

Hi @morganquigley_gitlab , we didn’t address security so far. But indeed TLS is on our todo list (probably using mutual authentication).

Angelo Corsaro

@kydos

@morganquigley_gitlab we will have support for TLS in the rust version

Angelo Corsaro

@kydos

Hello @aaronchongth, I see that your use case is about constrained robots. I also see that you are currently using Cyclone, as a consequence I'd assume that (1) you are running over an IP network and (2) your target HW is likely a Cortex-A (or R) as opposed to Cortex-M. Is that right?

Getting to how to make your system scale better, there are really two dimensions. One which is about exploiting zenoh primitives and the other which is about deploying the zenoh routing nodes so to optimise network flows.

For what concerns zenoh primitives, the main difference when compared to DDS or other pub/sub technologies, is that zenoh supports distributed queries. In other terms, you have the ability to query for data as opposed to have data pushed to you all the time.

Angelo Corsaro

@kydos

Queries can be, kind of simulated, via DDS, but that requires creating a reader for each topic you want to query and waiting for historical data. Then destroying these readers. This generates quite a bit of discovery traffic (your point on scaling the system).

In zenoh queries do not generate any discovery traffic, thus that can make quite some difference.

A good application of queries could be to read robots properties.

Let me know if this makes sense, and if you have any other questions. I'll be more than happy to discuss and provide you with suggestions.

Angelo Corsaro

@kydos

@morganquigley_gitlab I realise I did not give you sufficient context. The new version of zenoh is being rewritten in Rust. We have made already good progress and if you want to give it a try, take a look at eclipse-zenoh/zenoh-python#27

Morgan Quigley

@morganquigley_gitlab

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?

Angelo Corsaro

@kydos

@morganquigley_gitlab zenoh as a protocol does not require TCP/IP, it can run on a generic best effort transport. As a matter of fact it can sit straight on top of a layer 2 as it does its own routing. If you use WiFi in our experience the best combination would be doing discovery by multicast but still communicating over unicast. If the network connectivity is spotty, then UDP unicast would do. This features will be available in our next release (the Rust rewrite). Just to give you some reference, we've built the current version of zenoh to explore the integration of traditional pub/sub like DDS and NDN. Now that we are happy with the protocol mechanism, we are going for a rewrite and will support UDP/IP in the first beta. I hope we can push the first beta of the new protocol implementation sometimes late of June.

The new version also makes it easy for us or anybody else to extend the transport to support BLE, etc. Thus if you have specific needs do not hesitate to let us know.

Morgan Quigley

@morganquigley_gitlab

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!

And yes, we're using "full size" processors (ARMv8 or x86-64) running Linux on IP networks.

Angelo Corsaro

@kydos

Hello @morganquigley_gitlab, indeed we have experienced the pains of multicast at several instances. Once you move away from a wired LAN things start getting messy -- if allowed at all.

Regarding discovery -- scouting in zenoh terminology -- then the short answer is yes. The longer answer is that scouting is seen by zenoh as side-protocol. For instance on BLE we leverage bluetooth discovery, on IP networks we can use a set of locators or try to discover via multicast. If somebody wanted could do an LDAP based scouting. I guess you see where I am going.

Something else to understand is that if you plan to have a zenoh routing infrastructure, then the only thing that needs to be scouted by application is a router. That could be done even using a fixed locator and then leverage some IP load-balancing -- for instance.

Angelo Corsaro

@kydos

In our experience TCP/IP gives indeed better throughput, at least in a relatively stable network. What makes TCP/IP hiccup is usually the flow control and the time it takes to recover a decent throughput after something going sour. In zenoh we have two solutions of this.

Every zenoh channel can be mapped to one or more TCP/IP connections. Using more TCP/IP connections for sending traffic belonging to the same channel helps with mitigating the flow control issues -- as in essence if we use n TCP/IP sockets per channel is as if we had an equivalent TCP/IP socket with a window that is n-times bigger of that of a single socket. Additionally, zenoh reliability is not tied to that of a TCP/IP connection. In other terms, we can retain reliability after dropping and re-establishing a TCP/IP session.

zenoh can do reliable data through unicast UDP/IP. That removes the problems with TCP/IP flow control.

Morgan Quigley

@morganquigley_gitlab

Thanks Angelo for answering all my questions so quickly. One more: although Zenoh seems like it nicely handles "small and lightweight" type environments and messages, are you aware of aspects that would prevent it from nicely handling large/heavy message flows, like image streams or large point clouds? Thanks again.

Angelo Corsaro

@kydos

Hello again @morganquigley_gitlab. We have been debating support for large data for some time. I would assume that in your context a large message is on the order of a few megabytes, right? In this case, something to know is that if you have zenoh routers deployed they cache messages that go through (in this case would be fragments), thus in case of losses most of the time you can repair at one hop distance. For huge data, say 1GByte payload (we have seen that in the past in collaboration with Space Observatories) than, our plan is to have a "file-transfer" over zenoh that deals with these kinds of huge data. We can do some tests on our side. For anything relative to performances I would take as a reference our new Rust implementation. Let me know which sizes you'd like us to look into. We'll keep you posted.

Angelo Corsaro

@kydos

There is also a video recoding of my talk at the Eclipse IoT and Edge Native Workshop https://www.crowdcast.io/e/May28_2020_IotEdgeNativeDay/2

Angelo Corsaro

@kydos

And here are the slides: https://drive.google.com/file/d/1GwGgm0hd2HzFdF-q7aHxg8W2uC--4ZYS/view?usp=sharing

Morgan Quigley

@morganquigley_gitlab

Thanks Angelo! I really appreciate the detailed responses to all my questions, and the link to the latest talk and slides. Cheers!

Where communities thrive

People

Repo info

Activity