net::ERR_HTTP2_PROTOCOL_ERROR 200 for loading large batch of files (60~80 MBs)

Developers
1

Hi,

On the context of a game, with a WebGL build, we are occasionally getting the error “net::ERR_HTTP2_PROTOCOL_ERROR 200” and “Failed to load resource” when loading the Unity build (around 60~80 MBs).

Screenshot 2024-07-26 at 14.57.30

For many times we just ask to refresh and sometimes it works, but a few areas / internet access seem to get it a lot, while others almost never happens.

From what I researched, eventually a timeout is reached on the “batching” process of querying the asset from the canister, can you kindly confirm my suspicion?

And if so, my main question here is if it can be improved? If not, are you aware of any frontend lib that could help mitigate this issue better?

Thanks for your time and help :pray:

1 Like
2

An important context, Unity has it’s “loading” script, you can see it here:

Then that loader calls the “framework.js”:

Then this framework is the one that loads the .data and .wasm file (and these big ones are the ones that are having trouble to load):

3

Hey @tiago89

This is Rüdiger from the boundary node team. I am sorry to hear about the poor user experience. Indeed, loading a big file can be slow and unfortunately sometimes fail.

First, how do the boundary nodes handle such large files: A response coming from a canister on the IC can be at most 2mb. Therefore, when you request a larger file, the boundary node actually requests it chunk by chunk and streams it to the client as one big response. Since the boundary node randomly selects one replica node in the subnet for each request, the latency varies highly (from 10ms to ~300ms).

In order to look into the issue in more detail, it would help us if you could provide us with the request id of the failed requests. You can see the request ID by looking at the response headers from the network pane in the developer tools of your browser.

1 Like
4

Hi Rüdiger,

Thanks for the message and apologies for only getting these request IDs today.

As I was collecting these request IDs, realized a pattern. It’s always the same file and it looks like it’s calling two times the same file (from concurrent threads), example, these were the fetch calls on the network tab:

Two unsuccesful requests:

  • Desktop.wasm (not success 27 MB): Request ID 7cb721f3-d8f5-5f83-d501-2d6324faee88
  • Desktop.wasm (not success 9 MB): Request ID 7cb721f3-d8f5-5f83-d501-2d6324faee88

And one, always succesful, but similar size:

  • Desktop.data (success 78 MB): Request ID eda2e479-5d96-8071-5db0-376af7598130

In my computer the Desktop.wasm is only one and only one fetch call, on the user computer, the framework.js file (specific of Unity) seems to be doing two fetch calls, concurrently to the same file. I don’t know why the request ID is the same or how the Unity file seems to be getting lost and end up doing those 2 calls.

Will try to debug this deeper tomorrow and let you know of my findings.

Thanks :pray:

1 Like
5

Hi Rüdiger,

Want to give an update on this.

Have deep dived, tried to reproduce on my side and struggled, despite different Browsers, OS or networks. Even with VPN could not reproduce.

Meanwhile have solved it by setting up Cloudflare (CDN) and custom domain for the canister that holds the Unity build.

With that it solved the errors on the 2 players affected. So I am left believing the main problem is the network being slow and the Boundary Nodes being too strict on the timeout. It seems Cloudflare is handling things more gracefully, allowing for slower connections to still load the file.

I know that some changes will soon be applied to the Boundary Nodes, so I can test it again when released.

For now, this is solved on my side, so no more work here. Thanks Rüdiger for your attention :pray: