Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lieven
    @vortex314
    @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.
    Luigi Rodorigo
    @lrodorigo
    Sorrry for another question:
    What is the Zenoh behaviour wrt the leading slash of the path?
    Are /demo/first and demo/first both allowed? If yes, are both seen as the same path?
    Julien Enoch
    @JEnoch
    Both are allowed. Using the zenoh API demo/first is a relative Path to the Workspace prefix. If not specified, the default prefix of a Workspace is /.
    Luigi Rodorigo
    @lrodorigo
    Quite clear, many thanks.
    Julien Enoch
    @JEnoch
    @lrodorigo : Olivier just pushed a fix for the « routers_autoconnect_multicast + REST plugin » issue. You can pull and build master now, or wait ~1h that a new eclipse/zenoh:master image is built and pushed to Docker hub.
    @gardenest : if you use routers_autoconnect_multicast=true too, you should also pull the master branch for this fix.
    Luigi Rodorigo
    @lrodorigo

    Sorry for annoying you with really noob questions, but I am also having problems with z_put.py/z_get.py/z_sub.py examples (from https://github.com/eclipse-zenoh/zenoh-python/blob/master/examples/zenoh/).

    In particular the following happens:
    1) I start the z_sub.py script
    2) I run z_put.py script (without additional parameters)
    3) z_sub.py correctly invokes the callback
    4) if I run z_get.py, no data are received at all.

    Openning session...
    New workspace...
    Get Data from '/demo/example/**'...
    
    Process finished with exit code 0

    More over (while the zenohd process with a [working] REST plugin is running):
    0) I start z_sub.py -e tcp/localhost:7447
    1) I run z_put.py -e tcp/localhost:7447
    2) I run curl -X PUT -d 'Hello Data!' http://localhost:8000/demo/example/test2
    3) The z_sub.py invokes the callback ONLY for the data sent from the z_put.py script (and not for the data sent by the REST API)
    4) The key put from z_put.py is retreived on the API at http://localhost:8000/demo/** but the content is blank (while the content received from z_sub.py is (correctly) 'Put from Python!'

    Am I missing something?

    Julien Enoch
    @JEnoch
    For your first use case, you need to have a running zenoh router with an appropriate storage configured to store the publication and reply to the get (e.g. start the router with an memory storage: zenohd —mem-storage ‘/demo/**').
    Is that your case ?
    Luigi Rodorigo
    @lrodorigo
    Ok, just tried with a running zenohd router (and a mem storage created by 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), but unfortunately the result is the same
    Also tried to add -e tcp/localhost:7447 to z_pub and z_get (in this case the multicast discovery should work?)
    Julien Enoch
    @JEnoch
    If you installed zenoh-python via pip install eclipse-zenoh you might have compatibility issue with the router built from master branch. (sorry, we’re large phase of changes since the last 0.5.0-beta.8 release, including in the protocol and APIs…)
    Can you please try to re-install it with:
    pip install https://github.com/eclipse-zenoh/zenoh-python/zipball/master
    Julien Enoch
    @JEnoch
    I just tried a similar scenario using router and zenoh-python from master branch, and it worked for me:
    1. zenohd --mem-storage '/demo/**’
    2. python3 ./z_sub.py
    3. python3 ./z_put.py => z_sub receives the publication
    4. curl -X PUT -d 'Hello Data!' http://localhost:8000/demo/example/test2=> z_sub receives the publication
    5. curl http://localhost:8000/demo/** => result is:
      [
      { "key": "/demo/example/zenoh-python-put", "value": "Put from Python!", "encoding": "text/plain", "time": "2021-07-07T13:48:04.130432996Z/D2D25874C4884368A11E63673229BA46" },
      { "key": "/demo/example/test2", "value": "Hello Data!", "encoding": "application/x-www-form-urlencoded", "time": "2021-07-07T13:48:08.151674997Z/D2D25874C4884368A11E63673229BA46" }
      ]
    Can you try the same ?
    To answer your question: -e tcp/localhost:7447 is not necessary for z_put and z_get since they are configured in peer mode by default and will do multicast discovery and discover the router.
    Luigi Rodorigo
    @lrodorigo
    After installing the python library from the master branch things are going better
    Julien Enoch
    @JEnoch
    Glad to read that ! :smiley:
    Luigi Rodorigo
    @lrodorigo
    If run zenohd with zenohd --mem-storage '/demo/** everything is working, if I run the zenohd docker container, and then I create the storage using 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, the GET request does not see the data sent from z_put.py (but it sees the data sent from PUT HTTP requests)
    kydos
    @kydos
    @lrodorigo it would be good if you could look at the admin information in both cases. In other terms, look at what is the difference when you do a get on the URI: http://localhost:8000/@/router/local/plugin/storages/backend/memory/storage/**
    BTW, alsos notice that in the first case the storage path is /demo/** in the sencond you are creating a storage on /demo/example/**.
    Thus depending on what you’re trying to put it may not be surprising that it does not get stored. What is the key you are putting?
    Julien Enoch
    @JEnoch
    @lrodorigo the issue with docker container might still be related to the « routers_autoconnect_multicast + REST plugin » issue mentionned above that prevents the storages plugin to works properly. The new eclipse/zenoh:master image including Olivier’s fix for this issue is now ready. Please try to pull it and re-do your test.
    Luigi Rodorigo
    @lrodorigo

    Yes I noticed that, and actually the reported metadata of the two datastores are correct:

    /@/router/FB96238589C74C1AAADBB8359A9A24A8/plugin/storages/backend/memory/storage/my-storage
    {"path_expr":"/demo/example/**"}

    and

    /@/router/1FE3B25A0F674180A0424BEFC8F46314/plugin/storages/backend/memory/storage/mem-storage-1
    {"path_expr":"/demo/**"}

    Anyway I am using z_put.py with the default --path parameter (/demo/example/zenoh-python-put), and I am publishing with curl on /demo/example/zenoh-python-put