Potential memory leak in webrtc packet processing

[renaynay]

Non-critical but noticeable memory leak interestingly coming from context.Done somewhere from webrtc packet processing.

Flame graph from yesterday at ~15:00 UTC+1

https://flamegraph.com/share/c80d4436-fa8b-11ef-8d53-2a7e77e4af82

Flame graph from today at ~10:30 UTC+1

https://flamegraph.com/share/df3ef673-fb37-11ef-8d53-2a7e77e4af82

cc @Wondertan

[sukunrt]

Thanks for reporting this.

I'm curious, are you using / are interested in using webrtc-direct in production?
I have a bunch of improvements I can make to the transport, but I'm unwilling to spend time on it without some interest from users.

[Wondertan]

We do use webrtc-direct in production where we can't use webtransport. What kind of improvements do you mean?

[sukunrt]

1. Having the certhash be persistent across restarts, like webtransport.
2. There's probably potential for performance improvements. I already have a couple of draft PRs that I never pushed over the line in SCTP. Optimize payload queue for write path pion/sctp#320 Add receive chunk tracker for better received chunk handling pion/sctp#319

[Wondertan]

Having the certhash be persistent across restarts, like webtransport.

@sukunrt, this is indeed useful! We could then add them to dnsaddr, so certain browsers can connect over WebRTC directly.
Optimizations are less so, as long as it works. There are bigger bottlenecks on our side for WebRTC ones to be even visible.