Skip to content

Implement outgoing_queues_empty for PeerConnection#91

Closed
cuchaz wants to merge 2 commits into
webrtc-rs:masterfrom
cuchaz:quiescence
Closed

Implement outgoing_queues_empty for PeerConnection#91
cuchaz wants to merge 2 commits into
webrtc-rs:masterfrom
cuchaz:quiescence

Conversation

@cuchaz
Copy link
Copy Markdown
Contributor

@cuchaz cuchaz commented Apr 21, 2026

To provide a signal for when it's safe to tear down the event loop driving the connection after sending messages over a data channel.

This is another attempt at fixing the issue originally behind #63 that works by adding a new WriteQueueQuiescence trait providing a is_write_queue_empty function for all stages in the peer connection pipeline. If all stages report empty, then it should be safe for the caller of the peer connection to tear down the event loop.

This was a bit tricky to implement because the ICE layer generates a ton of STUN messages that generate a lot of false positive signals. Also, hopefully I actually found all the internal queues where messages can hide.

And the interceptor layer needed special attention because it looks like it's based on a proc macro system. These changes affect the external API requirements for custom interceptors as well.

Let me know what you think.

Thanks,
Jeff

cuchaz added 2 commits April 21, 2026 19:31
to provide a signal for when it's safe to tear down an event loop driving the connection after sending messages over a data channel
@codecov
Copy link
Copy Markdown

codecov Bot commented Apr 24, 2026

Codecov Report

❌ Patch coverage is 33.78378% with 49 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.23%. Comparing base (ca0d153) to head (07321da).

Files with missing lines Patch % Lines
rtc/src/peer_connection/handler/datachannel.rs 0.00% 9 Missing ⚠️
rtc/src/peer_connection/handler/mod.rs 0.00% 7 Missing ⚠️
rtc/src/peer_connection/handler/sctp.rs 0.00% 7 Missing ⚠️
rtc/src/peer_connection/handler/interceptor.rs 0.00% 4 Missing ⚠️
rtc-interceptor/src/noop.rs 0.00% 3 Missing ⚠️
rtc/src/peer_connection/handler/demuxer.rs 0.00% 3 Missing ⚠️
rtc/src/peer_connection/handler/dtls.rs 0.00% 3 Missing ⚠️
rtc/src/peer_connection/handler/endpoint.rs 0.00% 3 Missing ⚠️
rtc/src/peer_connection/handler/ice.rs 0.00% 3 Missing ⚠️
rtc/src/peer_connection/handler/srtp.rs 0.00% 3 Missing ⚠️
... and 2 more
Additional details and impacted files
@@           Coverage Diff           @@
##           master      #91   +/-   ##
=======================================
  Coverage   71.23%   71.23%           
=======================================
  Files         442      442           
  Lines       67356    67430   +74     
=======================================
+ Hits        47979    48035   +56     
- Misses      19377    19395   +18     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Copy Markdown
Member

@rainliu rainliu left a comment

Choose a reason for hiding this comment

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

I don't think adding pub fn outgoing_queues_empty in RTCPeerConnection is a good way. It is not WebRTC spec compatible.

Please consider how to implement bufferedAmount API for RTCDataChannel:
https://www.w3.org/TR/webrtc/#dom-datachannel-bufferedamount, which is currently missing and need to be implemented in some way.

@cuchaz
Copy link
Copy Markdown
Contributor Author

cuchaz commented Apr 28, 2026

Ok, thanks for the feedback. Managing buffer amounts is far more complicated than I need right now, and I'm out of time to spend on this. These changes as-is work well for me right now, so I'm just going to maintain them as a patch.

@cuchaz cuchaz closed this Apr 28, 2026
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.

2 participants