MirrorHub/dendrite
0
0
Fork 0
mirror of https://github.com/matrix-org/dendrite synced 2024-12-13 16:53:10 +01:00
Code Issues Releases Wiki Activity

clarify why we picked js-libp2p rather than go-libp2p

Matthew Hodgson 2020-06-03 17:11:25 +01:00
parent 609c35bc43
commit 19c3c23052
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
How-p2p.riot.im-works.md

@ -58,7 +58,7 @@ Overall, working with service workers has been the hardest part of this entire p
Finally, we use a [rendezvous server](https://github.com/libp2p/js-libp2p-websocket-star-rendezvous) to act as a relay for peer-to-peer traffic. This means all traffic goes via a central server: not quite as peer-to-peer as we'd like. We'd like to use WebRTC data channels in the future, but currently [service workers do not support them](https://github.com/w3c/webrtc-pc/issues/230). This means that if you have two browsers on the same laptop they'll still bounce via the relay server.
We implement a custom `http.RoundTripper` in our Federation client which hits out to the p2p network. We actually use the JS version of libp2p rather than the Go version because it was easier to get things set up that way. This code uses similar communication techniques already decribed and the [code can be found here](https://github.com/matrix-org/go-http-js-libp2p). We've found peer discovery can take a while, and latency when sending data scales badly with load - likely because the rendezvous server gets overloaded (it often maxes out a CPU core).
We implement a custom `http.RoundTripper` in our Federation client which hits out to the p2p network. We actually use the JS version of libp2p rather than the Go version to avoid having to shim all the p2p network activity (e.g. websockets or webrtc) through to JS from Go, and to make it easier to debug the libp2p side in-browser. This code uses similar communication techniques already decribed and the [code can be found here](https://github.com/matrix-org/go-http-js-libp2p). We've found peer discovery can take a while, and latency when sending data scales badly with load - likely because the rendezvous server gets overloaded (it often maxes out a CPU core).
The libp2p JS libraries have some quirks - stylistically they are in the middle of a transition from old to new JS codestyles, and the large number of dependencies means that it can be easy to use incompatible versions of certain libraries together (e.g a newer version of `peer-info` with an older version of `peer-id`) which then fails in obscure ways. We've also hit a few various scenarios whereby requests seemingly black hole, even when specifying sensible timeouts. Overall though, it works okay enough for the purposes of the demo.