- Run a zenoh router on the server
- run another dzd instance on the laptop once again on client mode
Thank you @kydos
But this would be the setup I tried first, router on server, and default was client mode.
If my pc also has a locator set up, shouldn't be a problem, or?
FYI: On the robot and my pc, zenoh runs in a self build container with net=host.
The container was build from a ros image, so cyclone libs, etc. should also be available
https://ci.eclipse.org/zenoh/job/zenoh-plugin-dds/
In about 15min you should be able to pull/update the latest version of
eclipse/zenoh-bridge-dds image from Docker hub.
Hi all,
Eclipse zenoh 0.5.0-beta.8 is out!
- See it's changelog here
- The "
zenohd" router binary is available for Linux, MacOS and Windows (all x86-64) here - But also as a Docker image (x86-64 arch only)
- But you can also install it via homebrew (MacOS) or apt (Linux Debian x86-64)
- The Rust API is available via crates.io
- The Python API is available via pypi.org
- The C API is pre-built for main platforms here, but can also be installed via homebrew (MacOS) or apt (Linux) as the
libzenohc-devpackage. - The zenoh-pico C API is pre-built for various platforms as .deb and .rpm packages here
- Also you can get the latest versions of plugins and backends libraries:
- Finally, the "
dzd" zenoh/DDS bridge is available as a Docker image (x86-64 arch only). Notice that as it requires the--net hostoption for UDP multicast, it can be used only on Linux.
I just pushed to master a fix that should allow support for multicast scouting on multi-homed hosts.
Note that the fix will not work on windows platform.
There will be more improvements coming but this fix should be ok for most cases.
Let me know if you have any issues !
Hi @OlivierHecart . I tried your fix and it works, the clients can now detect the router in both subnets. Thank you very much! The only problem that remains is that while the client (in debug log level) prints the locators of the router, the client in one subnet still can not connect to the router. I guess this happens because the client tries to connect to the locator of the other subnet, which fails of course. Then the client panics.
See the debug log of the client:
-- LOG/pub: [2021-04-07T09:26:04Z DEBUG zenoh::net] Zenoh Rust API v0.5.0-beta.8-13-g655641f
-- LOG/pub: [2021-04-07T09:26:04Z DEBUG zenoh::net] Config: mode=client
-- LOG/pub: [2021-04-07T09:26:04Z INFO zenoh::net::runtime] Using PID: 219FB1FD6E2C4D878E0A76B5841E9F94
-- LOG/pub: [2021-04-07T09:26:04Z INFO zenoh::net::runtime::orchestrator] Scouting for router ...
-- LOG/pub: [2021-04-07T09:26:04Z DEBUG zenoh::net::runtime::orchestrator] UDP port bound to 10.0.0.190:36689
-- LOG/pub: [2021-04-07T09:26:04Z INFO zenoh::net::runtime::orchestrator] Found Hello { pid: Some(1A68243413B741F6B37BB9966082E998), whatami: None, locators: Some([Tcp(SocketAddr(11.0.0.22:7447)), Tcp(SocketAddr(10.0.0.201:7447))]) }
-- LOG/pub: thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ZError { kind: Timeout, file: "zenoh/src/net/runtime/orchestrator.rs", line: 628, source: None }', zenoh/examples/zenoh/z_put.rs:26:49As you can see, the client now correctly finds the locators of the router, but then I suspect it tries to connect to the address in the 11.x.x.x subnet instead of the 10.x.x.x subnet which it would be able to reach. When starting the client with -e 10.0.0.201:7447, it connects perfectly fine. I used the z_put example as client.
TLDR: your multicast fix seems to work and multicast scouting works on all interfaces. But the logic for the client to choose which locator to use doesn't work correctly I suppose. Either it should select the most suitable locator (e.g. the one on the same subnet) or should try all locators instead of failing after the first one.
What is supposed to happen is that the router answers to scouting with an Hello message containing both it's locators. Then the client is supposed to try the returned locators one by one until one works. But apparently this last part is not working properly. I'll have a look ASAP.
@OliLay what seems to happen is the following :
- At transport level, for each connection attempt, there is a number of retries (default 3) and a timeout for each retry (10secs).
- At upper level, in client mode there is a global timeout (default 3secs) after which the client considers it failed to connect a router.
So the global timeout triggers before the orchestrator had a chance to try the second locator.
We need to improve the default behavior changing those default timeouts and maybe more cleverly order the locators before attempting to connect them.
Anyway until then, you can change those defaults at compile time. Probably the ones to change are the lower level ones so that the attempts do not take ages. You can do it like this :
export SESSION_OPEN_TIMEOUT=1000
export SESSION_OPEN_RETRIES=0
cargo build --release --all-targets
`depends = "zenoh (=0.5.0-dev)"` `depends = "zenoh (=0.5.0~dev)"`Thanks for reporting this! I’ll fix asap.
Actually I don’t really well understand the behaviour of
cargo-deb when generating the package name:- with zenoh 0.5.0-beta.8 it generated a package named
zenoh_0.5.0~beta.8_amd64.deb(i.e. replacing the-with a~) - now, setting the version to 0.5.0-dev in our master branch, it generates a package named
zenohd_0.5.0-dev_amd64.deb(i.e. keeping the-)
I guess we probably misuse the debian package versionning to keep this-beta.xsuffix and need to better understand it...