Evaluate @roamhq/wrtc

[achingbrain]

The old wrtc module has been rebooted as @roamhq/wrtc. We should evaluate it's performance vs node-datachannel.

The @libp2p/webrtc should be updated to use @roamhq/wrtc - if a PR can be opened with all tests passing we can test the throughput using the perf tests in the libp2p/test-plans repo.

[Khwahish29]

Hey I'd like to work on this :)

[achingbrain]

Great, please submit a PR!

[p-shahi]

Assigning to @luu-alex as discussed in https://github.com/libp2p/js-libp2p/discussions/3140

[AkMo3]

I am sorry, I actually didn't track this and tried to solve this in #3145 without prior communication. In any case, I have pointed a few consideration here which are worth taking a look. It would be help if you can run the CI to check the compatibility of the package across different platforms

[luu-alex]

Got the good to go ^ Will continue working on this issue 👍

[luu-alex]

While looking into the issue I realized their current build of webrtc does not support ice-lite as commented from the author and is incompatible as a replacement for node-datachannel atm.

[Rushhaabhhh]

@achingbrain , @p-shahi ~

Developer Note : Addressing WebRTC Performance and @roamhq/wrtc Evaluation

Hello team, I am a contributor from PLDG and as assigned by @seetadev I've analyzed issues #3033  (WebRTC streaming performance) and #3034 (evaluation of @roamhq/wrtc), I want to share a detailed assessment and propose a pragmatic, multi-stage plan to address the performance challenges and architectural limitations.

Summary of Core Challenges

• Issue #3033 : The current node-datachannel-based WebRTC transport exhibits streaming throughput that is an order of magnitude slower than TCP in Node.js environments. The bottleneck lies primarily in the underlying libdatachannel and libjuice components, particularly in SCTP buffer and ICE handling performance.
• Issue #3034 : The revived @roamhq/wrtc package approaches production-level WebRTC capabilities but is presently unstable in Node.js (N-API errors on process exit), lacks essential WebRTC Direct features like ICE-lite STUN listeners, and does not cleanly replace node-datachannel.

---

Proposed Fixes and Solutions

1. Optimize node-datachannel and libdatachannel Configuration

• Tune SCTP Buffering and flow control by adjusting maxBufferedAmount, bufferedAmountLowEventTimeout, and related parameters to reduce memory pressure and latency during streaming. Consider partial reliability modes (timed retransmits, unordered channels) optimized for real-time streaming workloads.
• Consider recompilation with alternative ICE backends like libnice for better ICE performance.
• Introduce or improve bandwidth estimation and congestion control feedback hooks in node-datachannel to allow adaptive bitrate and pacing, as found in Google’s libwebrtc.

These optimizations form the low-risk, incremental improvements that can be quickly tested and benchmarked while preserving the existing transport architecture.

---

2. Evaluate Hybrid Transport Architecture

• Dual Backend Support :

  Implement a conditional transport selection mechanism allowing the system to dynamically choose between node-datachannel and @roamhq/wrtc based on the connection type or workload (e.g., use node-datachannel for WebRTC Direct and low-overhead cases, raomhq/wrtc for high-throughput streaming).

• Key decision criteria include: ICE-lite support (node-datachannel essential for WebRTC Direct), streaming performance requirements (raomhq/wrtc preferred), resource constraints, and platform compatibility.

This hybrid approach mitigates the risk of a full upstream migration and leverages the strength of each implementation while accommodating libp2p’s diverse connectivity scenarios.

---

Conclusion

A direct replacement of node-datachannel with @roamhq/wrtc today is premature due to stability and feature gaps but should remain a key medium-to-long term goal. Immediate improvements can be gained by carefully tuning libdatachannel and SCTP parameters and exploring ICE backend alternatives. Simultaneously, building a hybrid, feature-aware transport fallback with clean API separation can future-proof libp2p’s WebRTC transport.

I look forward to feedback and collaboration on this roadmap. With a focused effort to address both configuration-level optimizations and architectural flexibility, we can significantly enhance libp2p WebRTC transport performance and reliability in Node.js.

[achingbrain]

@Rushhaabhhh this thread is for a specific piece of work, please do not hijack it. If you wish to discuss a potential third way, please open a new issue or start a discussion.

[NiKrause]

@luu-alex @achingbrain I saw this issue today and just gave it a try.

While replacing node-datachannel, I saw the missing ice-light feature mentioned by @luu-alex https://github.com/WonderInventions/node-webrtc/issues/29#issuecomment-2988643381).

Ice-lite was not yet added to wrtc https://github.com/WonderInventions/node-webrtc/pull/31

So the missing IceUdpMuxListener was implemented on our side via a stun package and I implemented regular (full ICE - not ICE lite) RTCPeerConnection.

Remark: After test cleanup, the wrtc crashes, which, as it seems, needs to be fixed on the wrtc side. https://github.com/WonderInventions/node-webrtc/issues/35

I thought I could do a performance test with it and compare it with node_datachannel.

See: https://github.com/libp2p/js-libp2p/pull/3356

Edit: I had a misconception about Ice-Lite was already implemented in roamhq/wrtc - but it is still not implemented. My PR works (at least locally) since I implemented FULL ICE with the stun package. Ice-Lite isn't necessarily needed.