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
eclipse/zenoh-bridge-dds
image from Docker hub.
Hi all,
Eclipse zenoh 0.5.0-beta.8 is out!
zenohd
" router binary is available for Linux, MacOS and Windows (all x86-64) herelibzenohc-dev
package.dzd
" zenoh/DDS bridge is available as a Docker image (x86-64 arch only). Notice that as it requires the --net host
option for UDP multicast, it can be used only on Linux.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:49
As 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.
@OliLay what seems to happen is the following :
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)"`
cargo-deb
when generating the package name:zenoh_0.5.0~beta.8_amd64.deb
(i.e. replacing the -
with a ~
)zenohd_0.5.0-dev_amd64.deb
(i.e. keeping the -
)-beta.x
suffix and need to better understand it...