search

ipfs / in-web-browsers

Tracking the endeavor towards getting web browsers to natively support IPFS and content-addressing
https://docs.ipfs.tech/how-to/address-ipfs-on-web/
MIT License
345 stars 29 forks source link

Too many pending WebTransport sessions in Chromium #211

Open lidel opened 1 year ago

lidel commented 1 year ago

Ref. https://bugs.chromium.org/p/chromium/issues/detail?id=1473980

What steps will reproduce the problem?

  1. Visit https://helia-identify.on.fleek.co/
  2. Open the console
  3. Wait a minute or two

What is the expected result?

  • No uncatchable WebTransport errors or warnings should appear in the console
  • :point_right: We should be able to detect when we have too many pending WebTransport sessions and close them
  • :point_right: We should be able to recover from this state and begin opening WebTransport sessions again

What happens instead?

A warning appears in the console: WebTransport session establishment failed. Too many pending WebTransport sessions (64)

All subsequent attempts to open a WebTransport session on any server fail with "WebTransportError: Connection lost"

Timeline

cc @achingbrain @SgtPooki

lidel commented 1 year ago

This is negatively impacting use of WebTransport libp2p transport (https://github.com/ipfs/in-web-browsers/issues/190#issuecomment-1692248130) in Chromium browsers.

@javifernandez do you have thoughts on if problems marked with (:point_right: ) are something Chrome team will fix sooner than later, or if this is something that won't happen without an additional push? (not urgent, we can discuss during check-in on 14th Sep, just wanted cc you on this)

SgtPooki commented 1 year ago

@javifernandez Any updates you can provide? pending & failed WebTransport sessions end up completely halting functionality for js-libp2p when enabled, which is unfortunate because WebTransport was supposed to open up a lot of opportunity for p2p in the browser.

Faolain commented 8 months ago

I believe we saw this back in April and @achingbrain gave us a solution for (tested in realtime and worked) which @eloramirez1356 will be sharing

eloramirez1356 commented 8 months ago

The solution I tried and that was given back in April is the following one, and related to filter connections to reduce the number of useless connections:

const heliaNode = await createHelia({
                libp2p: {
                    connectionGater: {
                        filterMultiaddrForPeer: async (peer, multiaddrTest) => {
                            const multiaddrString = multiaddrTest.toString();
                            if (
                                multiaddrString.includes("/ip4/127.0.0.1") ||
                                multiaddrString.includes("/ip6/")
                            ) {
                                return false;
                            }
                            return true;
                        },
                        denyDialMultiaddr: async (multiaddrTest) => {
                            const multiaddrString = multiaddrTest.toString();
                            console.log("multiaddrString", multiaddrString);
                            if (
                                multiaddrString.includes("/ip4/127.0.0.1") ||
                                multiaddrString.includes("/ip6/")
                            ) {
                                return true;
                            }
                            return false;
                        },
                    },
                },
            });

This previous configuration reduces the speed of the increasing in the number of webtransport failed sessions, concretely without that configuration (using default libp2p configuration by "await createHelia()") it shows 500 or 600 failed sessions right after loading the page and with the previous configuration around 200 or 300, but still getting the issue of connection lost.

I will let you know in case I was able to handle this and fix the issue.

In case it was useful too, I am having the following error in case it was related to this warning too:

stream.js:152 Uncaught (in promise) DOMException: The stream was aborted by the remote server

Thanks!

javifernandez commented 6 months ago

@javifernandez Any updates you can provide? pending & failed WebTransport sessions end up completely halting functionality for js-libp2p when enabled, which is unfortunate because WebTransport was supposed to open up a lot of opportunity for p2p in the browser.

Sorry about the delay, but I've been busy with other tasks; this is now in the top of my tasks list and I have started already with the preliminary analysis of the use case, the demos and the discussion in the Chromium bug. I have to say that although the information in the bug is very useful to understand the root cause of the problem and the use case libp2p is trying to address, there are some open questions that we need to clarify before I can figure out the best approach.

Basically, the penalty for failed connections is by design (although I agree it's not part of the Web Transport specification). Google admitted that Chrome could be smart on some cases (eg, lower penalty for failures in different IPs). The Throtting based on the server IP is something already considered in the design doc, although discarded due to it's potential complexity.

If I've understood it correctly, an smarter throttilng is not the ideal solution, although it'd help; since failed handskaeks are being treated as pending for a long period of time (due to the penalty), we would need a way to cancel them so that the app recovers from this state and can open new sessions again.