Zenoh hop-to-hop reliability is today completely delegated to the underlying transport protocol, e.g. TCP, TLS, QUIC.
No hop-to-hop reliability is provided by Zenoh in case of using a non-reliable transport protocols, e.g. UDP, Serial.
Intended outcome
Zenoh will be able to retransmit lost messages, e.g. due to network/host congestion, network TX errors, etc.
This mechanisms is intended to work for Reliable messages only and to be limited to hop-to-hop communication.
It is not by any means intended to be fully end-to-end.
It is worth highlighting that in a stable system, end-to-end reliability can be achieved by chaining multiple hop-to-hop reliable communication.
However, in case of a node failure (e.g. a router going down), end-to-end reliability can not be ensured by the hop-to-hop reliability mechanism.
How will it work?
Reliable messages are acknowledged and retransmitted in case they have not been received.
No changes are expected to the API.
Summary
Zenoh hop-to-hop reliability is today completely delegated to the underlying transport protocol, e.g. TCP, TLS, QUIC. No hop-to-hop reliability is provided by Zenoh in case of using a non-reliable transport protocols, e.g. UDP, Serial.
Intended outcome
Zenoh will be able to retransmit lost messages, e.g. due to network/host congestion, network TX errors, etc. This mechanisms is intended to work for
Reliablemessages only and to be limited to hop-to-hop communication. It is not by any means intended to be fully end-to-end. It is worth highlighting that in a stable system, end-to-end reliability can be achieved by chaining multiple hop-to-hop reliable communication. However, in case of a node failure (e.g. a router going down), end-to-end reliability can not be ensured by the hop-to-hop reliability mechanism.How will it work?
Reliablemessages are acknowledged and retransmitted in case they have not been received. No changes are expected to the API.