zenohd
binary). And you can deploy those routers wherever you want, as soon as they are interconnected.@gardenest
@kydos Thanks for your reply. This feature is important for device discovery and identification. I'm looking forward for this feature release.
Absolutely, this is one of the reasons why we wanted all messages in our protocol to support user attachments. We are about to finalise the features list for June and July — we’ll try to squeeze this in June. BTW, once the API will expose this feature you’ll be able to attach properties to scout/hello, open as well as to data messages. We keep the working-feature-list on the [github wiki] (https://github.com/eclipse-zenoh/zenoh/wiki/2021). I’ll let you know once that is updated.
GetRequest::reply()
as many time as you want.Hi @gardenest ,
Yes, in your Eval function, you can callGetRequest::reply()
as many time as you want.
Just notice that if you send several replies with a same Path, the consolidation mode configured by default in the zenoh API will make that your requester will only receive 1 value per Path (the one with the mre recent timestamp). But I guess you probably want to send replies with different Paths, right ?
@JEnoch Actually I need one Path with multiple replies and client need to receive all replies, is that possible?
Yes, it is possible: currently the way for the requester to specify that he wants several replies for a same Path is to set the starttime
and/or the stoptime
as properties in the Selector.
That’s for instance used to query the InfluxDB backend. See example of use here:
https://github.com/eclipse-zenoh/zenoh-backend-influxdb#behaviour-on-get
Just know that the values of starttime
and stoptime
properties are not interpreted by the zenoh infrastructure itself, but by the receiver of the GetRequest. I.e. the InfluxDB backend, or your Eval function in your case.
The InfluxDB backend, for instance, uses the values of starttime
and stoptime
in the DB query it does to retrieve the time-serie to reply.
Your Eval function could interpret those starttime
and stoptime
values in the way you want (or just ignore them). The only missing part we currently have is that in zenoh API, there is no way yet to specify a timestamp with the Value you replies. The timestamp is automatically generated by zenoh when replying, and it could therefore not match the time interval specified in the Selector.
But that might not be an issue for your use case if you don’t care about timestamps.
mininet
and zenoh-python
(the repo is https://github.com/luca-della-vedova/robocom-benchmarks, with the relevant functions being testZenoh and the zenoh subfolder). I keep getting errors in connection when TLS is enabled and wireshark shows no packets going through, I wonder if you had any input? I'm using the deb version of zenoh and I built zenoh-python from source, specifically the error is:[2021-06-07T08:17:06Z ERROR zenoh::net::runtime::orchestrator] Unable to connect to any of [Tls(SocketAddr(10.0.0.1:7447))]!
.zenohd
zenoh-process.py
to use tcp/<your_hostname>:7447
as peer
musl
or gcc
?
arm64/x86
platforms without having to maintain distinct Dockerfiles for each platforms.zenohd
and *.so
you built this way, which maximal GLIBC version they require (check with ldd -v zenohd *.so | grep GLIBC
) ? I manage to cross-build binaries for armv7l
using a specific Dockerfile, but unfortunately the resulting libzplugin_storages.so
requires GLIBC 2.29 which is greater than the default one on Raspberry Pi OS (2.28)Hello @gardenest, this is indeed strange. You should see all reachable routers and peers with zn_scout.
There is a difference between zn_info and zn_scout that could explain this behavior :
So maybe part of your peers are not reachable through multicast but are discovered by zn_info and other peers by gossip discovery (through the router probably).
use zenoh::net::*;
let mut config = config::peer();
config.insert(config::ZN_MULTICAST_ADDRESS_KEY, "224.0.0.224:7448".to_string());
let session = open(config).await.unwrap();
aarch64
for a Pi4 (2GB) and I started the router ./zenohd
and followed the steps in the documentation of setting up a local memory storage and tried putting hello world
on the API. Upon querying the data I get [ ]
although the paths are the same.
--mem-storage /demo/example/**
parameter for zenohd
RUST_LOG=debug ./target/release/zenoh-bridge-dds -m peer
ros2 run examples_rclcpp_minimal_publisher publisher_member_function
<?xml version="1.0" encoding="UTF-8"?>
<CycloneDDS xmlns="https://cdds.io/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://cdds.io/config https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/master/etc/cyclonedds.xsd">
<Domain id="any">
<Discovery>
<ParticipantIndex>
auto
</ParticipantIndex>
<MaxAutoParticipantIndex>
30
</MaxAutoParticipantIndex>
</Discovery>
</Domain>
</CycloneDDS>
zenoh
for arm64
and if someone has a Raspberry Pi 4 with docker lying around please give docker run --init -p 7447:7447/tcp -p 7447:7447/udp -p 8000:8000/tcp shantanoodesai/zenoh
a spin