search

libp2p / go-libp2p

libp2p implementation in Go
MIT License
6.02k stars 1.06k forks source link

WebRTC: Tracking Issue #2656

Open sukunrt opened 10 months ago

sukunrt commented 10 months ago 
### Tasks
- [x] Implement FIN_ACK spec: https://github.com/libp2p/specs/pull/582
- [ ] https://github.com/libp2p/go-libp2p/issues/2614
- [ ] https://github.com/libp2p/go-libp2p/issues/1917
- [x] Remove Experimental tag: https://github.com/libp2p/go-libp2p/issues/2657
- [ ] Share the same UDP socket with QUIC #2446, https://github.com/ipfs/kubo/pull/10228
- [ ] WebRTC Private to Private: #2009
- [ ] Allow clients to provide their certificates for server
- [ ] Integrate WebRTC with Perf test
SgtPooki commented 7 months ago

@sukunrt any update here?

sukunrt commented 7 months ago

We are on track for a release in v0.34(roughly end of the month) that's good enough to be non experimental. We will still keep it experimental in v0.34 and see if any issues arise. After than v0.35 should have it non experimental.

The current master is pretty good performance wise. When run with the pion/webrtc branch here: https://github.com/pion/webrtc/pull/2696 I see decent memory usage. I'll share the exact numbers soon but for 10 connections each doing 1000 streams and a ping pong of 1MB we see a memory usage of roughly 30MB after the streams are closed and all the connections are open.

On the CPU usage, the performance doesn't look great. Again I'll share more understandable numbers soon, but the CPU usage is roughly 1.5 - 2x of what quic has under similar load. This seems okay to me. quic-go is highly optimised. Single connection throughput is also only 50MB/s but that's also good enough for clients on the web who most likely will be on wifi networks. It's not ideal but we can do perf improvements much better once we see some adoption. On the bright side, the CPU usage is proportional to the total data being transferred on the connection so that's a nice property.