Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Always create RELIABLE Writers (fix #23) #26

Merged
merged 1 commit into from
Dec 11, 2023
Merged

Always create RELIABLE Writers (fix #23) #26

merged 1 commit into from
Dec 11, 2023

Conversation

JEnoch
Copy link
Member

@JEnoch JEnoch commented Dec 8, 2023

At Writer creation, just remove Reliability QoS if set to BEST_EFFORT.
If not set, the default Reliability value for Writers is RELIABLE with max_blocking_time=100ms.

Note: Writers for Services and Actions are already set to RELIABLE.

@JEnoch JEnoch requested a review from OlivierHecart December 8, 2023 16:52
@Fellfalla
Copy link

@JEnoch Thank you for working on this! Does this make the DDS writers reliable even though the bridge is configured with udp or the forwarded publisher is BEST_EFFORT?

@JEnoch
Copy link
Member Author

JEnoch commented Dec 9, 2023

Yes, this PR forces RELIABLE QoS for any DDS Writer created by the bridge to send data coming from Zenoh to a DDS Reader.
If this Writer is created because of the forwarded discovery of a remote DDS Writer by another bridge:

  • if the discovered Writer is BEST_EFFORT, the created Writer will have the spec default Reliability QoS which is RELIABLE with max_blocking_time=100ms.
  • if the discovered Writer is RELIABLE, the created Writer will use the same RELIABLE and max_blocking_time values.

This behaviour doesn't depend on the transport configured for the Zenoh protocol.
Therefore, if an un-reliable transport is used (such as UDP), messages can be lost between 2 bridges, even if the DDS Writer are RELIABLE.
This behaviour will remain until a Reliability protocol is implemented for Zenoh (work in progress). In the meantime, TCP or QUIC should be used to ensure end-to-end reliability across bridges.

@OlivierHecart OlivierHecart merged commit 83ba7e4 into main Dec 11, 2023
7 checks passed
@OlivierHecart OlivierHecart deleted the fix_23 branch December 11, 2023 14:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants