A content-defined chunking scheme allows for you to build a pretty efficient game patcher where you can update between any version of the game (forwards and backwards) and doesn't require a bunch of server-side shenanigans.

League of Legends blogged about their updater here: https://technology.riotgames.com/news/supercharging-data-del...

I built something strikingly similar at my last job around the same time as well. Our server-side code was remarkably simple, just holding manifests (list of files and their chunk hashes) + a GCS bucket where all the chunks were stored (filename was just the hash of the chunk, making it content addressable.) Patching just involved the client understanding which chunks it already had, and which chunks needed to be downloaded from the server, or moved between files. Uploading a "new version" of the game to the server was also simple, just figure out what chunks were not in seen in the prior N versions of the game by looking at their manifests, and uploading them to the server, along with a new manifest describing the final contents of the game.

Given updating to a new version was just a matter of downloading new chunks, or re-arranging chunks that already existed on disk, going from one manifest to another did not depend on the new version being the successor of the prior version.

The majority of a game patch isn't actually the executable (where content-defined chunking wouldn't work well) instead were game assets like textures, audio files, etc..., which is why this strategy worked really well.

Okay so they reinvented delta packages but added a whole mess of AWS on top of it.

Like it's a legit good idea but they don't even mention the existing prior art in the article. Did the EA devs not see if this has been done before? Fedora/Redhat has been doing delta rpms forever and probably has ironed out a lot of the edges over the years. Like I would have ripped off https://github.com/mendsley/bsdiff the core of drpms.