Connection Closing

[daviddias]

Similar to go-ipfs (Read Connection Closing), js-ipfs is passing through similar hurdles when it comes to managing resources available that are shared amongst the open Connections.

In js-ipfs this is even more noticeable since it has to run in a Browser with an even more constrained envinronment and use a transport that is known as a CPU and memory hog, I'm talking about WebRTC.

If that wasn't enough, Chrome's new policy since version 57 is to aggressively throttle app resources for any tab that is in the background or not in the view of the users (i.e if you switch to another app, Chrome will also throttle the tab even if it remains open). This forces to be extra especially clever of how to maintain things working inside js-ipfs. There is an issue where we discuss this in more detail -- #611.

A quick way to mitigate this is to stick js-ipfs into a Service Worker, however, it has the tradeoff that it won't be able to use WebRTC.

In essence, we do need to solve Connection Closing and Resource Management as part of the protocol and create a model that can be translated between runtimes.

This is one of our top priorities right now.

[daviddias]

Update: @pgte is on it and he is on 🔥! Track the work at:

• Implement statistics to support Connection Management libp2p/js-libp2p#157
• https://github.com/libp2p/js-libp2p-connection-manager/
• observe traffic and expose statistics libp2p/js-libp2p-switch#243

❤️

[daviddias]

@legastero could you take a look at this one? I bet you will have a lot of input to "managing WebRTC connections memory usage" :)

[lgrahl]

Be aware that adding worker support to WebRTC is heavily requested and currently being investigated as part of WebRTC NV (next version).

[whizzzkid]

js-ipfs is being deprecated in favor of Helia. You can #4336 and read the migration guide.

Please feel to reopen with any comments before 2023-06-05. We will do a final pass on reopened issues afterward (see #4336).