The zenoh project was started to address the short comings of existing technologies in addressing hetherogeneity, scale and integration between data at rest and data in motion. In other terms we wanted to have a protocol with the following characteristics:
Extremely wire efficient: to be used effectively on low power networks
Low static and dynamic footprint: to be able to run on anything ranging from a server to a micro-controller
Scalable to Internet-scale applications
Unified abstraction for data at rest and data in motion: a minimal set of abstractions to dealing with data in motion as well as at rest
Hello @carelphillipkruger , in the current rust implementation of zenoh, routers do not try to automatically connect to each other. The main reason of that is that we want the user to keep strong control on the routing network topology (we can discuss that further if needed). So you need to explicitly connect routers with each other and set up the exact topology you want.
The -p option is indeed gone and has been replaced by the -e option. So to interconnect two routers running on a same host :
zenohd -l tcp/0.0.0.0:7447
zenohd -l tcp/0.0.0.0:7448 -e tcp/127.0.0.1:7447Current rust routers can only route if interconnected in a "clique" (all routers directly connected to each other). Full routing capacities is one of our next items in the roadmap. It should added in the next weeks/months.
@methylDragon , about this :
Would it be feasible to implement a way to obtain the resource ID that a message was obtained from within a
ZNSubscriber's callback function (from the ffi)?e.g.
If Izn_write_wrid()to a resource ID (say, 1), could I obtain that number somehow from a ZNSubscriber's callback function (perhaps exposed in thezn_sampleobject that gets passed?)
We decided not to expose this information. The main reason for that is that the resource name to resource id mapping is purely local. So, in routed communications, the received id from the network is probably different from the one that has been used by the publisher. The only case in which you would be able to get the same id as used by the publisher would be in peer2peer communications.
May I ask why you would like to get this information so that we could reconsider our choice or provide another way to address the use case?
@OlivierHecart thanks for answering my query! I originally wanted it to debug the issue I posted above, I think that's not necessary now, so it's all good (:
Although, I'd like to ask if there are any suggestions on getting messages timestamped in the FFI (that is, the time the messages are sent out and received.) Would there be plans to expose that information in Zenoh, or is it preferable that I manually attach it to the message bytes I send instead?
I hope you all doing well. So while I was researching on the pub/sub architecture and message queueing algorithms, I had the following questions that concern on the implementation of zenoh for this architecture :
- What happens to the sending message if it fails or the receiving subscriber is temporarily unavailable?
- How long are messages kept in the storage/queue?
- What happens if the subscriber is overloaded with messages?
So, I wonder how zenoh can handle these situations.
Thanks in advance, and have a great day.
Hello @Harmouch101 , what we currently have is what I would call hop-to-hop no dropping reliability implementation. Meaning that a reliable protocol (relying on TCP reliability for now) is run between each hop in the routing path. I'm not sure about the size of the internal queue but @Mallets can answer that in details. Nothing is dropped until the receiver finally acknowledges the message or is declared dead. So to answer points 1 and 3, back pressure is propagated back from all subscribers down to the publisher that may eventually been slowed down.
We plan to add a dropping strategy to avoid slow subscribers to slow down the full system (basically older messages would be dropped when the queue is full).
This would grant full reliability while the routing network topology is stable but there may be losses on topology changes (router crash, etc ...). So we also plan to add an end-to-end reliability mechanism by tagging each message with a writerId + writerSN which would allow subscribers to detect missed samples and ask for resends (samples would be retained by storages disseminated in the network for some period of time). This strategy provides a greater reliability but brings scalability issues.
void zn_init_logger(void);
Seafloor asked about using it for autonomous boat swarms via LoRa https://www.seafloorsystems.com
Cool, happy to learn more about their use case.
Hello zenoh team! I have a couple of questions regarding using zenoh on MCUs . Your website http://zenoh.io/ has section that reads:
Constrained Devices
zenoh implementations can be extremely resource constrained. Our smallest implementation takes as little as 300 bytes footprint on an Atmel 8-bit microcontroller.
However, in project's rodmap microcontroller support is listed as new feature planned for September.
I'd like to test out zenoh on STM32 mcu that is connected using UART/serial to RPi4 running Cyclone DDS instance and I wonder if zenoh provides similar functionalities to this project. I would be grateful if you could provide me with some resources on how to use zenoh wih microcontrollers.
