The 'dial' method in WebRTCTransport creates an RTCPeerConnection as it's first step. However, there are several dependencies to actually being able to negotiate the WebRTC connection, including being able to connect to the Circuit Relay. If the Circuit Relay is not reachable for any reason, a stream cannot be opened, or other possible issues, the dial fails and the RTCPeerConnection is wasted.
This seems like a nit, but it creates a significant issue because:
1) Dialing is often done automatically on a periodic basis
2) Chrome has a hard limit of 500 RTCPeerConnections instantiated in the lifetime of a Chrome process (browser tab).
https://issues.chromium.org/issues/41378764
For long-running libp2p instances, this can easily present an issue. Once the issue occurs, the only recourse is the close the tab, even refreshing will not work.
Steps to reproduce the error:
Attempt to dial a WebRTC peer address 510 times via an unreachable Circuit Relay address
Observe the dial attempts will fail forever after the 500th attempt on the RTCPeerConnection instantiation
Observe that even if the Circuit Relay becomes available after 500 failures, a WebRTC connection will never be established again
This would allow the address parsing, relay connection and stream establishment to occur before the RTCPeerConnection construction. That way, if any of the pre-requisite steps fail, the RTCPeerConnection is not 'wasted'.
Granted, this is only an issue because of bad behavior in Chrome. However, this has been a known issue for several years and no progress has been made in fixing it. The affects all Chrome derivatives (Edge, Brave, etc), which taken together represent the vast majority of the browser market.
Version: libp2p: 1.2.4 @libp2p/webrtc: 4.0.22
Platform:
Linux master 6.8.6-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 13 Apr 2024 14:42:24 +0000 x86_64 GNU/LinuxSubsystem: WebRTCTransport dial
Severity:
Medium
Description:
The 'dial' method in WebRTCTransport creates an RTCPeerConnection as it's first step. However, there are several dependencies to actually being able to negotiate the WebRTC connection, including being able to connect to the Circuit Relay. If the Circuit Relay is not reachable for any reason, a stream cannot be opened, or other possible issues, the dial fails and the RTCPeerConnection is wasted.
This seems like a nit, but it creates a significant issue because: 1) Dialing is often done automatically on a periodic basis 2) Chrome has a hard limit of 500 RTCPeerConnections instantiated in the lifetime of a Chrome process (browser tab). https://issues.chromium.org/issues/41378764
For long-running libp2p instances, this can easily present an issue. Once the issue occurs, the only recourse is the close the tab, even refreshing will not work.
Steps to reproduce the error:
Perhaps the RTCPeerConnection construction could be moved inside of 'initiateConnection' and returned from that function? https://github.com/libp2p/js-libp2p/blob/main/packages/transport-webrtc/src/private-to-private/initiate-connection.ts#L29
This would allow the address parsing, relay connection and stream establishment to occur before the RTCPeerConnection construction. That way, if any of the pre-requisite steps fail, the RTCPeerConnection is not 'wasted'.
Granted, this is only an issue because of bad behavior in Chrome. However, this has been a known issue for several years and no progress has been made in fixing it. The affects all Chrome derivatives (Edge, Brave, etc), which taken together represent the vast majority of the browser market.