Performance issues under poor network conditions about webrtc-native HOT 4 OPEN

Thanks for the insight. Your comment made me curious if the built-in browser RTCPeerConnection behaved the same way under the poor conditions, and lo and behold it does. The issue definitely seems to be the SCTP protocol itself rather than Godot, so thanks for the details surrounding that. I will keep my eye on get_buffered_amount and use it once it's generally available.

For reference, I've included the projects I was testing with. One is the Godot code exported to HTML5, and the other is a pure JavaScript implementation of the same thing.
RtcPerformance.zip

from webrtc-native.

After some more testing, I was also able to reproduce the issue by exporting the project to HTML5 (I should have tried this sooner, apologies), so I'm not sure if the issue is in the Godot engine proper or this plugin.

I also tried adjusting the Max Channel In Buffer Kb project setting, but could not notice a difference with a larger buffer.

from webrtc-native.

I haven't ever seen this manifest as a "frame rate" or "performance" problem, but I can say that WebRTC is hyper sensitive to packet loss. In my testing, if you introduce even a little bit of packet loss (like 2%) you'll see messages get really delayed, way more than you'd expect, and certainly more than compared to ENet (which I've also done comparison testing with).

I believe is caused by the flow control that's built into the SCTP protocol (which is what WebRTC uses for data channels). I think it's detecting the packet loss, and then holding back messages, probably because the protocol is assuming the packet loss is caused by network congestion. And if you try to send more messages after it's entered "flow control mode," it'll actually exacerbate the problem, and cause it to hold back the message even longer. I've observed this with both HTML5 and with the native plugin.

Perhaps this just looks like a frame rate or performance problem because your game objects are moving in fits and starts rather than smoothly?

I've had some success by checking WebRTCDataChannel.get_buffered_amount() and having my code avoid sending if there's any data buffered, which appears to get back out of "flow control mode" quicker. However, that function was only just added in this PR:

#43

... so, there isn't a pre-compiled binary that you can download. (Also, this appears to work more effectively with the native plugin than it does in HTML5, at least in my testing.)

Hopefully @Faless will make a new release of the native plugin shortly after Godot 3.4 stable is released. :-)

from webrtc-native.

The description on this PR has some decent references about WebRTC, its flow control and bufferedAmount: godotengine/godot#50658

from webrtc-native.