Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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
    Julien Enoch
    @JEnoch
    By « peers » you mean « routers » right ? You’re only starting 2 zenohd processes, or also zenoh applications (i.e. using a zenoh API) ?
    I mean theeclipse/zenoh container you run is a zenoh router: internally it runs the zenohd process.
    Luigi Rodorigo
    @lrodorigo
    Of course, sorry for the misleading term.
    Yes I would mean router, it is running zenohd process.
    Each host is running the same ecplise/zenoh container with the mentioned docker run command.
    Julien Enoch
    @JEnoch
    OK, thanks for clarification. Actually I saw that both routers_autoconnect_multicast and routers_autoconnect_gossip options have been introduced after the 0.5.0-beta.8 release. Thus, they are not yet supported in eclipse/zenoh:latest image.
    I kicked a build of the master branch that support those options. You should be able to run an eclipse/zenoh:master container soon. I’ll let you know as soon as available.
    Luigi Rodorigo
    @lrodorigo
    Ok, now I remembered that in the previous test I was using a build made from the master branch
    but it was not loading the REST plugin (because I didn't copy the .so files on the other host), so I started to use the Docker container...
    Luigi Rodorigo
    @lrodorigo

    These two options, are actually needed in order to enable the multicast discovery?

    routers_autoconnect_multicast=true
    routers_autoconnect_gossip=true

    Seems that they are quite undocumented (I found them only on this chat)

    Julien Enoch
    @JEnoch
    If all your routers are using routers_autoconnect_multicast=true and multicast is working for all, you don’t need routers_autoconnect_gossip=true.
    Julien Enoch
    @JEnoch
    @lrodorigo : the eclipse/zenoh:master image is now ready.
    Unfortunately, after few tests, I discovered that using routers_autoconnect_multicast=true causes a side effect that prevents the REST plugin to correctly start…
    We will investigate this and come back to you soon.
    Waiting for a fix, can’t you do your tests with a fixed IP (i.e. starting a router with -e tcp/<ip_of_other_router>:7447) ?
    Luigi Rodorigo
    @lrodorigo

    Ok, I will test it later.
    So, I deduce that the multicast discovery of the routers is still an 'experimental feature'.

    Just an observation:
    this is not so-clear from the Getting Started section of the zenoh.io website...
    it would be better to clearly report that, otherwise it seems that the "hello world" example between two routers, even in the simplest network configuration, is not working at all.

    OlivierHecart
    @OlivierHecart

    Hi @lrodorigo,
    You can connect multiple routers with each other manually using the -e option. For example for 2 routers :

    host1> zenohd
    host2> zenohd -e tcp/host1:7447

    routers discovery is deactivated by default so that users keep full control on the routers network topology.

    Luigi Rodorigo
    @lrodorigo
    Thanks Olivier, now it is clear to me.
    I was only reporting that it should be more clear on the Getting Started guide [ here: https://zenoh.io/docs/getting-started/quick-test/ ]
    OlivierHecart
    @OlivierHecart
    Yep we need to improve that. Thanks for the advice.
    Luigi Rodorigo
    @lrodorigo
    Another question:
    in order to persist all data on each router, the storage must be recreated on each router, after the zenohd process has started. Is it correct?
    OlivierHecart
    @OlivierHecart
    That's correct.