Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    halfbit
    @halfbit:matrix.org
    [m]
    with zenoh storage and get, is there any thinking on a get + subscribe mechanism? like if I have an some structured data where many attributes remain the same and some are changing relatively often, and I want those updates after the initial get
    Luca Cominardi
    @Mallets
    Hi @shantanoo-desai , regarding building zenoh-pico for Arduino there was an initial attempt from @cguimaraes here. The PR is still marked as work in progress but I believe it could serve as a starting point.
    kydos
    @kydos
    Hello @halfbit:matrix.org that’s coming early next week. We call it Quering Subscriber. @JEnoch should merge the feature monday or tuesday. We’ll post a message once done.
    Julien Enoch
    @JEnoch
    Hi @halfbit:matrix.org ,
    Actually I merged last Thursday (eclipse-zenoh/zenoh@59fd21b). It’s in a new side crate named zenoh-ext that extends the zenoh::net::Session with a declare_querying_subscriber() function. You can see an example of usage here.
    By default the QueryingSubscriber starts with a query on the same resource it subscribes to (but it could be configured to query on another resource). The results of the query are merged/sorted/deduplicated with the live publications that may occur in parallel, before to be delivered to the QueryingSubscriberuser. At any time, the user can re-issue a query and the same behaviour will re-occur.
    Shan Desai
    @shantanoo-desai
    @JEnoch just a weird update regarding musl cross compilation for aarch64 apparently the cdylib was causing problems when compiling for aarch64-unknown-linux-musl but on my local x84_64 based machine I replaced the crates that had cdylib to staticlib and it seems to cross-compile.
    This produces *.a files as opposed to *.so files.
    Not sure if this is good or not but I am trying to spin it up in an apline container and see if this works.
    14 replies
    gardenest
    @gardenest
    Hello, I have a question that the description of Zenoh-python say it does not support peer-to-peer communication, but I can use it to pub and sub without Zenoh router. Doesn't pub and sub means peer to peer communication? If not, what is the definition of 'peer ' at Zenoh?
    Julien Enoch
    @JEnoch
    Hi @gardenest ,
    That’s an oversight from a previous version. I confirm that current versions of zenoh-python now well supports peer-to-peer communications (i.e. without router).
    Thanks for pointing this mistake, I’ll fix the README now.
    gardenest
    @gardenest
    @JEnoch Thanks.
    Iñaki Ucar
    @Enchufa2

    Hi, everyone! I just tried the example in "your first zenoh app". First, I launch the dockerized router:

    $ podman run --init -p 7447:7447/tcp -p 7447:7447/udp -p 8000:8000/tcp eclipse/zenoh --mem-storage='/myhome/**'

    Then, I launch the Python script that produces temperature readings, and I see:

    Traceback (most recent call last):
    File "/***/zenoh-server.py", line 18, in <module>
    z = Zenoh({})
    zenoh.ZError: IO error (Unable to bind udp port 224.0.0.224:7447) at /root/.cargo/registry/src/github.com-1ecc6299db9ec823/zenoh-0.5.0-beta.8/src/net/runtime/orchestrator.rs:350. - Caused by Address already in use (os error 98)

    Everything locally. Am I doing something wrong? Shouldn't the peer find the router?

    Iñaki Ucar
    @Enchufa2
    (podman is not the issue; I tried with docker too, same result)
    Adding "multicast_address": "224.0.0.224:7448" to the config works! Thanks, @Mallets
    Iñaki Ucar
    @Enchufa2
    So it seems that docker and multicast do not play well together: moby/moby#23659
    And it's needed to specify the peer too. As a suggestion, it would be great to add these details to the documentation. :)
    1 reply
    Alexandre Santos
    @AlexandreVSantos_gitlab
    Hi guys looking at the code available I found several definitions that I am not sure if I know what they mean. If someone could clarify the difference between Locator and Broker I would be very pleased. And for example if I am a zenoh router then how should I fill the flags on a Hello message.
    kydos
    @kydos
    Hello @AlexandreVSantos_gitlab a locator is, in a way, an address at which to find a zenoh endpoint and the lower level protocol to use to communicate with it. Over IP networks a zenoh locator may look like udp/131.176.207.40:7447 or tcp/131.176.207.40:7447. A broker is just en entity mediating communications between two clients.
    @Enchufa2 indeed that should be a bit more clear from the docs. @JEnoch, can you look into this or make sure that the right info is more easily accessible?
    gardenest
    @gardenest
    Hi everyone, according to the key concept docs communicate with other peers could be peer to peer and mesh topology. I'm wondering can I and how to choose the topology. Is it configurable? or it will choose automatically?
    OlivierHecart
    @OlivierHecart

    Hi @gardenest , you can define the topology by manually interconnecting the different peers with each other. To do so, you need to configure each zenoh session with the following :

    • a tcp listener with a specific tcp port to listen on (so that other peers can easily connect to it)
    • one or more peers to connect to
    • deactivate multicast and gossip discovery so that peers do not connect automatically to each other.

    Here is an example in python :

    from zenoh import Zenoh
    z = Zenoh({"listener": "tcp/0.0.0.0:7447",
               "peer": "tcp/127.0.0.1:7448,tcp/127.0.0.1:7449",
               "multicast_scouting": "false",
               "peers_autoconnect": "false"})
    gardenest
    @gardenest
    @OlivierHecart Thanks for your reply, I will try on it.
    I have another question is about the memory usage of peer. I'm trying to testing it via the example zn_pub.py and zn_sub.py and testing scenario is one subscriber with many publishers. The situation is when new publisher application start, the memory usage of the existed publisher will become larger each time. How can I prevent this kind of situation?
    OlivierHecart
    @OlivierHecart
    @gardenest I see 2 solutions for this :
    • use a zenoh router and configure all pubs and sub as clients.
    • configure a "mesh" of peers where each zn_pub is only connected to the zn_sub.
      For this second solution, using zn_pub.py and zn_sub.py examples you need to write a config file to deactivate multicast and gossip discovery :
      $ cat config
      multicast_scouting=false
      peers_autoconnect=false
      Then you can run zn_sub.py and zn_pub.py like this :
      python3 examples/zenoh-net/zn_sub.py -c config -l tcp/0.0.0.0:7447
      python3 examples/zenoh-net/zn_pub.py -c config -e tcp/127.0.0.1:7447
      python3 examples/zenoh-net/zn_pub.py -c config -e tcp/127.0.0.1:7447
    gardenest
    @gardenest
    @OlivierHecart Thanks a lot for the detailed reply. I will try to evaluate these solution.
    Alexandre Santos
    @AlexandreVSantos_gitlab
    @kydos thanks for the explanation
    I have another question about session establishment. Looking at some captures taken with wireshark, I can see that the zenoh client when trying to establish a session with a router, sends along with an init header, an attachment header with some payload. Is that for authentication? how should the router handle that information and how should be the response?
    Luca Cominardi
    @Mallets

    hi @AlexandreVSantos_gitlab , the attachment is used for exchanging additional information. At the moment is used only for these 2 cases:
    1) user-password authentication
    2) shared-memory probing to see if the client/router can operate over a shm segment

    By default user-password authentication is disabled and SHM is enabled. So, what you see is problably SHM probing. In that case, the router will simply ignore the attachment in case does not support SHM. In the contrary, it will answer to the query.

    The authenticators for user-password and SHM are here
    Luca Cominardi
    @Mallets
    Hello zenohers! Since in the past week there was a discussion on this very channel about zenoh minimal overhead, we have decided to write a blog post about it: https://zenoh.io/blog/2021-07-05-zenoh-overhead/. Enjoy the reading and thanks again to the curiosity of everyone that initially triggered the discussion on this aspect of zenoh!
    expploitt
    @expploitt
    Great! Thanks @Mallets !
    Charles Cross
    @spiderkeys_gitlab
    @kydos what is the current state of Zenoh for microcontrollers/the XRCE use-cases? There are a number of different projects/repos (zenoh, zhe, zenoh-pico) and I'm trying to find out what the latest approach to deploying on something like an arduino might be. I'm working with another company on the development of a set of standards and a framework for communication between marine sensors and devices and I wanted to review any potential solutions that Zenoh might be able to provide.
    Luca Cominardi
    @Mallets
    Hi @spiderkeys_gitlab , the repository to use is zenoh-pico. It’s a pure-C implementation of a zenoh client. Regarding building zenoh-pico for Arduino there was an initial attempt from @cguimaraes here: eclipse-zenoh/zenoh-pico#12. You might want to have a look at it as a starting point.
    Charles Cross
    @spiderkeys_gitlab
    Thanks @Mallets , I'll have a look
    Lieven
    @vortex314
    As XRCE also supports a serial interface, is there a way to run the zenoh protocol across a serial ( USB ) line ? If it's not existing yet, what would be the best way to implement this ?
    Luca Cominardi
    @Mallets
    zenoh is multi-protocol by design, that means that it can potentially work on various types of transport. As of today it can run on top of TCP, UDP, QUIC, TLS, and Unix sockets
    Making it work on top of a serial is possible in principle, the only requirements is to have a Rust library that implements AsyncRead and AsyncWrite Rust traits. So, if such library exists it would quite easy to integrate it within zenoh.
    To be honest I have never looked into such libraries, do you have any hint on where to look for serial?
    To give you some examples, the implementations of the various “drivers” for the transport protocols can be found here.
    kydos
    @kydos
    @spiderkeys_gitlab as @Mallets you should look into zenoh-pico and more in general for zenoh what we actively develop and maintain is on the Eclipse-zenoh repository . ZHE is implements the very first version of the zenoh protocol and its evolution is zenoh-pico.
    Lieven
    @vortex314
    @Mallets for the serial interface would it make sense just to have a serial-to-udp gateway ? As I'm not skilled in Rust. I could generate the UDP packets at micro-controller level , encapsulate them on serial and through the serial-2-udp get it to the zenoh daemon ?
    Luca Cominardi
    @Mallets
    I believe it could work since zenoh would only see an UDP interface and magic would be done hidden
    Lieven
    @vortex314
    @Mallets something completely different , I saw zenoh claims low latency. I saw benchmarks on throughput not on latency. Are there some figures on the round-trip times ?
    @Mallets I will give a try on the serial2zenoh interface.
    Luca Cominardi
    @Mallets
    @vortex314 looking forward to zenoh on serial!
    regarding the latency, we haven’t published yet some data on the blog but that will arrive soon. In the meanwhile you can get some recent data on latency in this video and slides
    Lieven
    @vortex314
    @Mallets very impressive latency figures ! Thanks for the info.
    Luca Cominardi
    @Mallets
    You are welcome!
    gardenest
    @gardenest
    Is there a way to configure Zenoh router to make it auto connect to another scouted Zenoh router?
    OlivierHecart
    @OlivierHecart

    Hi @gardenest, yes there is.
    You need to point the router to a config file at startup :

    zenohd -c config

    In this config file you may set the following options :

    routers_autoconnect_multicast = true
    routers_autoconnect_gossip = true

    When routers_autoconnect_multicast is set to true, routers connect to other routers they discovered through multicast.
    When routers_autoconnect_gossip is set to true, routers connect to other routers they discovered by the intermediate of already connected routers.

    gardenest
    @gardenest
    Thanks @OlivierHecart , I will try it.
    Luigi Rodorigo
    @lrodorigo

    Hi all,
    I am trying Zenoh for the first time.
    I need to share a single key between two Zenoh routers, in the same ethernet LAN (using latest docker container in net=host mode). I need to use the multicast discovery between the routers.

    Without adding the following options to the config file, the discovery is not working at all.

    routers_autoconnect_multicast = true
    routers_autoconnect_gossip = true

    After adding the options found in the previous messages, the log reports that a peer is discovered.

    The final reported configuration is :
    Config: peers_autoconnect=true;multicast_scouting=true;listener=tcp/0.0.0.0:7447;mode=router;peer;add_timestamp=true

    At this point I am registering the data storage via curl (on the two peers):

     curl -X PUT -H 'content-type:application/properties' -d 'path_expr=/demo/example/**' http://localhost:8000/@/router/local/plugin/storages/backend/memory/storage/my-storage

    and then, on the host1:
    curl -X PUT -d 'Hello World!' http://localhost:8000/demo/example/test

    curl http://localhost:8000/demo/example/test
    response is (correctly):

    [
    { "key": "/demo/example/test", "value": "Hello World!", "encoding": "application/x-www-form-urlencoded", "time": "2021-07-07T07:35:25.674262035Z/C896D2A77D1341C88D1EB9DDF4886B7B" }
    ]

    but on the host2 the command
    curl http://localhost:8000/demo/example/test
    returns an empty array

    [ 
    
    ]
    Julien Enoch
    @JEnoch
    Hi @lrodorigo ,
    What returns the command curl http://localhost:8000/@/** on host2 ?
    Luigi Rodorigo
    @lrodorigo

    Unfortunately now seems that the discovery of the peer has stopped working...
    docker run --init --rm --name=zenoh -e RUST_LOG=debug -v /home/user/zenoconfig/config:/zenoconfig --net=host eclipse/zenoh:latest -c /zenoconfig

    the content of /zenoconfig seen inside the zenoh container is:

    multicast_scouting=true
    peers_autoconnect=true
    routers_autoconnect_multicast=true
    routers_autoconnect_gossip=true
    the two peers are not able to discover each other