You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Dialing is often done automatically on a periodic basis
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.
The text was updated successfully, but these errors were encountered:
Chrome limits how many RTCPeerConnections a given tab can instantiated
during it's lifetime - https://issues.chromium.org/issues/41378764
To delay hitting this limit, only create the dial-end RTCPeerConnection
once a relayed connection has successfully been opened to the dial
target, this prevents needlessly creating RTCPeerConnections when the
dial fails before they are actually used.
Fixes#2591
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/Linux
Subsystem:
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:
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.
The text was updated successfully, but these errors were encountered: