Stable transports in the browser

[Beanow]

• Version: 0.26.0
• Platform: Firefox Quantum / Chromium
• Subsystem: swarm, pubsub, transports

Type: Bug / Enhancement

Severity: High

Description:

There's a good amount of pitfalls with the js-ipfs transports in the browser today.
Bundled with 0.26.0 are:

• libp2p-websockets
• libp2p-webrtc-star
• libp2p-railing

libp2p-webrtc-star

As in #950, today libp2p-webrtc-star is crashing the browser.

Possible solutions:

• Connection Closing Connection Closing #962
  Would be good to have, but has no implementation yet.
• libp2p-websocket-star Bring libp2p-websocket-star to the Transports family! 🌟 libp2p/js-libp2p#122
  Has seen a fair amount of work, but has open issues before it can be released.
• Not using libp2p-webrtc-star.
  This will mean you lose pubsub capabilities and run exclusively off of the bootstrap servers or manual connections to an IPFS daemon.

[daviddias]

Thank you for opening this issue, @Beanow :)

I believe we can have an interim solution with libp2p-websocket-star libp2p/js-libp2p#122 (comment)

One other note I want to add to this thread is that PubSub itself does relay, so in practice you can have a hosted node that subscribes to the same PubSub channel and that node will relay messages for you.

[alvestrand]

1. How many PeerConnections did you create?
2. Did you get anything useful done with them, or did you just create and park them?
   I'm currently debugging an issue that seems to be number-of-threads related.

[mitra42]

@alvestrand , I'm not sure who the question was addressed to, but we see this without explicitly creating any connections (just creating and starting IPFS), all the decisions on how many connections to open, and how many threads is happening in lower layers.

@diasdavid - could you post HERE, what is needed for the workaround as libp2p/js-libp2p#122 (comment) seems to have just configurations people are reporting problems with. In particular - need to know what interim configuration to use, anything in package.json (e.g. non-default versions). I'll be happy to test our apps against it.

[nils-ohlmeier]

@alvestrand when opening the demo URL from issue #950 I see Firefox opening lots and lots of PeerConnections with DataChannels in them. It also appears to close PCs, but the number of open PCs keep going up. I'm tempted to put in an upper boundary of PeerConnection's per domain to prevent pages from crashing Firefox by exhausting memory and/or threads.

@mitra42 what I don't quite understand is that this is IPFS project, right? But in here and in issue #950 you state that you don't open connections. Which JS library in your stack opens the PeerConnections? Who ever maintains that library needs to understand that PeerConnections are not as cheap to create as for example TCP connections. So who ever manages the PeerConnections needs keep a balance.

[mitra42]

Hi Nils, There are lots of links in #950, so I'm not sure which "demo URL" you refer to. I don't know about Orbit, if that is what you mean, but I'm refering to our demos (on https://dweb.me/examples).

I said we don't EXPLICITLY open connections, we, and I believe the many others reporting bugs like this, are loading IPFS, using the recommended config for using pubsub which is required by Yjs which is required to implement append-only-logs. ipfs.start() and wait ~5-15 mins and it crashes.

The management of connections is done by the underlying IPFS libraries. I understand that @diasdavid thinks he knows how to fix it, and that is happening (I'm currently not sure if that is a fix to WebRTC-star, or the implementation of websockets-start).

{ repo: ..., config: Addresses: { Swarm: [ '/dns4/star-signal.cloud.ipfs.team/wss/p2p-webrtc-star']}, EXPERIMENTAL: { pubsub: true }}

[nils-ohlmeier]

So I just opened https://dweb.me/examples/example_list.html in Firefox 59 and let it sit for several minutes without doing anything. After maybe 15min or so Firefox had opened 407 PeerConnections, of which 109 got closed.

I noticed that quite a few of the not closed PeerConnections never got connected to anything. From Firefox perspective these connections never received an SDP answer for the offers Firefox created. I think that is something which should get optimized in the IPFS stack to more aggressively close PeerConnections which failed to connect to anything.

I also noticed that each of these PeerConnections starts two threads in Firefox, which seems unnecessary. I'll file a bug on the Firefox side for that. Maybe we can optimize this a little bit more.

One other observation from my side: the tab in Firefox never crashed for me. Now I did this test on a MacBook Pro with 16GB of RAM. Quite possible that on a less power full machine the 500+ threads Firefox was running at the time results in actual problems.

[Beanow]

@nils-ohlmeier wow nice findings!
Could you share a quick primer of how you analysed this? To reproduce and test for improvements.

Same as @mitra42 no connections were declared by me. It's part of the peer discovery process and pubsub stack these connections grow.

From what I know there is a dialer machine in the swarm component that tries to connect with every address that comes up in the peer discovery.

[Beanow]

As for crashes I ran on a 32GB RAM machine and don't think any OOM was triggered by the OS. Perhaps they are some sandboxing hard limit? As in FF Quantum and Chromium it's only crashing the tab.

[mitra42]

Great - I see different behavior on Firefox and on Chrome

• on Firefox (and it varies from version to version) the typical behavior was the growth in threads until Firefox itself crashes.
• on Chrome it slows down a bit and then Chrome closes the tab, occasionally Chrome itself needs restarting.

[nils-ohlmeier]

@Beanow well I work on WebRTC in Firefox for a living, so I should know how to do this ;-)

The easiest thing is to open "about:webrtc" in another tab. That will show you all the WebRTC PeerConnections Firefox currently has open, plus old closed ones. I did then save that page and ran you favorite unix command line tools to do the counting of the connections on that page.

As for the threads I created a bug in the Firefox bug tracker with a patch which should improve the thread problem: https://bugzilla.mozilla.org/show_bug.cgi?id=1421819

But the general problem remains that lots of PeerConnections get created, which eventually get the browser into trouble.