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
I was only able to replicate this issue on Windows. I wasn’t able to reproduce this behavior on WSL (Ubuntu 22.04.4 LTS on Windows 10 x86_64).
The issue seems to be timing-related. I wasn’t able to replicate this issue with verbose logging and had to close about 100 connections at a time for this to occur.
Replication steps:
Create 100 PeerConnection objects (connected to some other peers).
Within a few seconds, all the other peers will start failing.
No more PeerConnection connections will be created; it is stuck in a stable state. The application has to be restarted before any new connections can be made.
Expected behavior:
To not prevent all future PeerConnections from being able to establish a connection.
I don’t know if this is a timing issue from libdatachannel or if this should be addressed in libjuice. Please advise.
The text was updated successfully, but these errors were encountered:
I was indeed on an old version of libdatachannel.
Updated to 0.21.2, still seeing the same behavior.
I did the following:
Removed all cached files (including all files related to vcpkg)
Cleaned the project in Microsoft Visual Studio
Reinstalled vcpkg
Added version constraint for >= 0.21.2 in the vcpkg.json file
Adding 100 clients, then deleting them again causes above behavior after closing & removing the first 5 clients of the 100 created.
I am also logging the version (RTC_VERSION) on startup.
Notes:
Replication steps:
Result:
[rtc::impl::IceTransport::LogCallback@363] juice: conn_poll.c:311: poll failed, errno=10038
Expected behavior:
To not prevent all future PeerConnections from being able to establish a connection.
I don’t know if this is a timing issue from libdatachannel or if this should be addressed in libjuice. Please advise.
The text was updated successfully, but these errors were encountered: