rebase onto latest upstream#1
Open
rmburg wants to merge 17 commits into
Open
Conversation
* fix: store enriched endpoint data with participant default locators in discovery_db When a remote DDS implementation (e.g. CycloneDDS) omits per-endpoint locators in SEDP announcements and relies on the participant's default locators from SPDP, update_subscription() and update_publication() would store the raw data with empty locator lists. The enriched copy (with default locators filled in) was only returned for the immediate notification but never stored back. This caused endpoints created after initial SEDP discovery to get reader/writer proxies with empty locator lists, silently dropping all data. Service calls (single request/reply) failed 100% of the time. The fix builds the enriched data first, then stores the enriched version in external_topic_readers/external_topic_writers so that later lookups via readers_on_topic()/writers_on_topic() return usable locator information. * feat: re-export SampleIdentity from crate root SampleIdentity is required to call WriteOptionsBuilder::related_sample_identity() but was not publicly accessible. It lived in structure::rpc which is pub(crate), making the public API method impossible to call from downstream crates. This is needed for ROS 2 service interop with FastDDS, which uses RTPS Inline QoS PID_RELATED_SAMPLE_IDENTITY for service request/reply correlation.
…tostek#401) The DomainParticipantStatusEvent channel had a capacity of 16 and silently dropped events when full, causing downstream consumers to miss endpoint discoveries entirely with no indication of data loss. A single participant can expose many endpoints (e.g. ~16 in a typical ROS 2 node), so even two participants overwhelm a 16-slot channel during the initial SEDP burst. Changes: - Increase status channel capacity from 16 to 2048 - Upgrade log level from trace! to warn! on channel overflow
Extract PID_USER_DATA from discovered reader and writer parameter lists and expose it on EndpointDescription. This allows applications to access DDS user data set by remote participants, such as ROS 2 type hashes.
RustDDS used OS-default UDP receive buffers (~786 KB on macOS, ~208 KB on Linux), which caused silent packet loss when receiving large fragmented DDS messages (e.g., 1080p images at ~6 MB). The buffer overflowed during fragment bursts, and with BestEffort QoS, lost fragments are never retransmitted. Set SO_RCVBUF to 8 MB by default (configurable via DomainParticipantBuilder::socket_receive_buffer_size). On Linux, users may need to raise net.core.rmem_max for larger payloads. This matches the approach used by CycloneDDS and FastDDS.
Validate readerSNState.base against last_change_sequence_number + 1 so a crafted ACKNACK cannot permanently corrupt all_acked_before (issue Atostek#405). Includes unit tests. Made-with: Cursor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Might fix HULKs/hulk#2404