Skip to content

[core] Gate publisher sends by active connection layer - #2680

Open
KerstinKeller wants to merge 2 commits into
masterfrom
hotfix/dont-transmit-data-without-subscriber
Open

[core] Gate publisher sends by active connection layer#2680
KerstinKeller wants to merge 2 commits into
masterfrom
hotfix/dont-transmit-data-without-subscriber

Conversation

@KerstinKeller

Copy link
Copy Markdown
Contributor

Track the selected transport layer per subscriber connection and derive per-layer send_enabled state so stale writer objects no longer emit data after their last matching subscriber disconnects.

Description

Related issues

Track the selected transport layer per subscriber connection and derive
per-layer send_enabled state so stale writer objects no longer emit data
after their last matching subscriber disconnects.
@KerstinKeller KerstinKeller added cherry-pick-to-support/v6.0 Cherry pick these changes to support/v6.0 cherry-pick-to-support/v6.1 Cherry pick these changes to support/v6.1 labels Jul 9, 2026
mutable std::mutex m_connection_map_mutex;
SSubscriptionMapT m_connection_map;
std::atomic<size_t> m_connection_count{ 0 };
std::atomic<bool> m_udp_send_enabled{ false };

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of an std::atomic we should use connection counters, as we can increase / decrease them upon registration / unregistration which eliminates the need to iterate over the map every time.

@KerstinKeller

Copy link
Copy Markdown
Contributor Author

This is already better than what we had previously. However we still have a problem.
In theory we have a state machine for a connection: PENDING -> ESTABLISHED -> CLOSED. After the first regisration refresh a connection is pending, after the second refresh it's currently counted as establed. This is a very bad heuristic.

With this PR, we currently won't send out data for pending connections, which is a different behavior than previously.
We should consider modeling pending conditions as well, and already send data even if the connection has not yet been confirmed.

Anyways the logic is brittle, and what we need is a true handshake, as we get e.g. in TCP, instead of a heuristic via the monitoring.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cherry-pick-to-support/v6.0 Cherry pick these changes to support/v6.0 cherry-pick-to-support/v6.1 Cherry pick these changes to support/v6.1

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants