libdatachannel: PeerConnection sometimes fails to establish local connection
Hi Paul-Louis,
I hope you are well 😃
I’m using libdatachannel to facilitate networking in a realtime multiplayer game. When a player hosts a game they run both the client & server code within the same process & thread i.e. the architecture is client-server, the host just happens to be running both the client & server code. In this hosting instance two rtc::PeerConnections are created, one for the “server side” code & one for the “client side” code. I then connect these two local PeerConnections to eachother. Remotely connecting clients only create a single rtc::PeerConnection that is connected to the host’s server side rtc::PeerConnection.
Now I’m occasionally having trouble establishing a connection between the host’s two local rtc::PeerConnection’s in the same process. I’d say connection establishment fails 5% of the time. As a side note I have a WebAssembly build of the game and I don’t experience the same issue.
I’ve attached game.log captured during a session that experienced the problem. It’s sprinkled with a few of my own log items for my own context so I can help but I can remove these if you like. I’ve also attached my stun_server.log although it’s likely of little use other than for my own context.
Interestingly in the captured logs the client side rtc::PeerConnection finds both host & srflx ice candidates, but the server side only finds a host candidate. Seems a little strange to me. My STUN server also sees much more activity in these 5% failure cases vs the 95% happy path cases. After 10 seconds (at the end of the logs) the game aborts the connection attempt.
Let me know how I can help?
Kind regards,
Deon
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 15 (6 by maintainers)
Hold fire on investing any more time in this right now as I’m now struggling to reproduce it under my Windows setup. I’m going to get things setup there so that I can use it for my daily development and monitor things over the next few days.
Excellent, Wireshark would allow to confirm the response from the STUN server actually arrives.
Everything is received by libjuice here: https://github.com/paullouisageneau/libjuice/blob/64db5b3be66d48af5c6c75eb9ad74f7b30cf8a39/src/agent.c#L650
However, there seems to be no trace of a single datagram received server-side in the log.