Implement client-side support of downloading RP from CDN

[alvin0319]

Introduction

Implement client-side support of downloading Resource Pack from CDN.

Relevant issues

• Alternative way to fix Resource pack sending overloads low-bandwidth connections #3127

Changes

API changes

• Added ResourcePackManager::getPackURLs(): Returns a map of uuid_version => cdn url

Behavioural changes

The server does not send ResourcePackChunkDataPacket since the client downloads the resource pack from CDN.

Backwards compatibility

There are no known BC breaking changes.

Follow-up

Tests

Test CDN server used with this test: https://github.com/alvin-pm-pl/ResourcePackCDN

Test Pack used with this test: https://mcpedl.com/legendary-bedrock-rtx-texture-pack/

2023-09-22.00-02-22.mp4

[ShockedPlot7560]

Looks OK for me

[BrandPVP]

«However, the resource packs still need to be loaded into PocketMine.»

It should automatically download the pack from the url and cache the metadata, shouldn’t it? Like, why do users need to put it manually when PM can automatize the job

[alvin0319]

«However, the resource packs still need to be loaded into PocketMine.»

It should automatically download the pack from the url and cache the metadata, shouldn’t it? Like, why do users need to put it manually when PM can automatize the job

I don't think it should be a PM's job. We should consider a offline environment.

[ShockedPlot7560]

In fact, I'm going back on my opinion because I hadn't realized the problem that has just been raised. Although you need to be in an offline environment, it can be interesting to enable automation.

[alvin0319]

Well, the problem is that:

1. We can't download the resource packs from CDN every time we turn on the server.
2. If we cache the downloaded resource pack, we have no way to detect whether resource pack content changed unless CDN provides a checksum or sha1 hash of the file.

The reason for requiring Resource Packs to be loaded into PM is that the client also expects info of remote resource packs in ResourcePacksInfoPacket. (after that, this isn't necessary since they download from external)

As an alternative way, we could let users write the UUID and version of the resource pack and optionally content key (which is the least information the client expects) in resource_packs.yml so that we don't let users load the resource pack into PM.

[dktapps]

General sentiment in the dev community so far is that this feature is pretty useless for anyone who doesn't have a perfect connection (i.e. anywhere that isn't the US or Europe).

[jasonw4331]

I would like to see added support for URLs without the https:// header also.

[dktapps]

I do think the cleanest way to do this would be to just allow putting URLs in the resource_stack instead of filenames. The way this is currently done seems janky to me.

Well, the problem is that:

1. We can't download the resource packs from CDN every time we turn on the server.
2. If we cache the downloaded resource pack, we have no way to detect whether resource pack content changed unless CDN provides a checksum or sha1 hash of the file.

The reason for requiring Resource Packs to be loaded into PM is that the client also expects info of remote resource packs in ResourcePacksInfoPacket. (after that, this isn't necessary since they download from external)

As an alternative way, we could let users write the UUID and version of the resource pack and optionally content key (which is the least information the client expects) in resource_packs.yml so that we don't let users load the resource pack into PM.

I'm not understanding the logic here. What's stopping PM from downloading packs from CDN whenever the server boots up?

I don't really buy into the point about caching either. If we have users hardcode pack UUIDs into the YML, we're already caching info, just in a way that the server can't control programmatically. Vs if the pack is downloaded, at least the information is guaranteed to be correct for some version of the resource pack. We can also look at Cache-Control headers to see when a resource pack's local cache should expire.

[dktapps]

This also needs to be updated for latest protocol changes

[github-actions]

This PR has been marked as "Waiting on Author", but we haven't seen any activity in 7 days.

If there is no further activity, it will be closed in 28 days.

Note for maintainers: Adding an assignee to the PR will prevent it from being marked as stale.

[github-actions]

As this PR hasn't been updated for a while, unfortunately we'll have to close it.