What is the correct logic for updating the game client?

Question

Programming

Hello. There was a need to create an application that is a kind of "launcher" (launcher) for one game.
The only hitch I've run into is updating the game files properly.
There are two types of updates:

• Complete update
  
• Partial update
  

If everything is more or less clear with the first point (we download and unpack the archive with all the files), then with the second point it’s not very clear. No, of course, when you start the application, you can check the version of the program and compare it with the latest one on the server. If there is no local version file, then download the full update and prescribe the version from the archive with this update, then compare the version again and if it differs, then download the patch for this version and roll the update from above.
Question one: How efficient and aesthetically pleasing is it to update by downloading patches? That is, the version will have the format: 3.2.11.25. When running the application/checking for updates and downloading updates, the version will be checked. If the version does not match, a check will be made to see which of the blocks of numbers in the version is different. That is, if the user has version 3.2.11. 10 , and on the server 3.2.11. 25 , then versions from *.*.*.10 to *.*.*.25 will be downloaded in turn and patches of each of these versions will be rolled. And on the server some file with versions will be stored, where they will all be listed.
Question two: How do you think Steam implemented this? Loading in parts by titles? Traffic during file download goes through port 80 from Valve servers and content-type is application/octet-stream there. So am I right? But after all, not one large file is downloaded in this way, but many small ones, which means that this is just the return of files in this way.
How do they check for the presence of even the most unnecessary file? Deleted the file from the directory, and he takes and downloads it. Checks before start all directories on the time of change and compares with server?
Question three: How effective will it be to compare the change time of directories for the user and compare with server ones? After all, even if a file was changed/deleted/created in the deepest directory, then the directory at the top in the hierarchy will have the date of the change when the file was affected. Accordingly, a large number of recursive checks can be avoided in this way.
And, accordingly, it will be easier to upgrade. Delete the changed directory and upload again.
What is your opinion? Can you suggest something about this?

Answer 1

From personal experience: imho the most correct thing is to have an unbreakable chain of updates from the first version to the current one, i.e. 1>2, 2>3, 3>4, etc.
Periodically release major versions for a clean installation, but still have an unbroken chain of updates.
Making patches like 1>4, 2>4, etc. - in my experience, archi is wrong, because it creates huge risks of implicit bugs + the cost of assembling such patches.
In fact, there is no problem for the user to install many updates.

A check will be made to see which of the blocks of numbers in the version is different.

You are discussing some small details.

How do they check for the presence of even the most unnecessary file? Deleted the file from the directory, and he takes and downloads it. Checks before start all directories on the time of change and compares with server?
Question three: How effective will it be to compare the change time of directories for the user and compare with server ones? After all, even if a file was changed/deleted/created in the deepest directory, then the directory at the top in the hierarchy will have the date of the change when the file was affected. Accordingly, a large number of recursive checks can be avoided in this way.
And, accordingly, it will be easier to upgrade. Delete the changed directory and upload again.

Attaching to the date of the changes is not a good idea. The check goes through the directories recursively, compares not only the list of files but also their hashes. Read how dropbox / Yandex.disk works, and finally the same torrent

Answer 2

There is a version and there is a hash sum of the current version of all application data (files + database).
At startup, both values ​​are checked.
If there is a discrepancy, a synchronization operation is performed:
1. Detection of differences
2. Preparation of a list of changes relative to the current version of the user
3. Backup of the current version of the user
4. Downloading all necessary files to the user's device. (with the possibility of resuming when the connection is broken)
5. Making changes.
6. Checking the changes made (p. 1)
7. Deleting the backup copy (created in p. 3)
If any of the points is interrupted (the battery of the PC or smartphone has run out, etc.), it should always be possible to continue the update from the interrupted step.

Answer 3

Honestly, I have not come across this, but I would try to do this:
Let's say we release a new version - 2.46 . At the same time, we upload the full version to the server for a clean installation or for updating from very old versions, and make the nth number of patches 2.45to2.46 , 2.44to2.46 , 2.43to2.46 ... So, if the user is behind by several versions, it will simply download the minimum necessary difference between its version and the current one, but if the user has a very old version, he will download the entire client again.
Thus, the number of downloads for the user is minimized, and therefore the load on the server will also decrease.

Answer 4

The server reports the current version of the program, if there is no match, it resets the hash of all files of the new version of the program, then the client-side program bypasses each file recursively and compares the hash, if it does not match / does not find it, it downloads from the server. After the update is fully downloaded, it changes the software version.
Here you will not download anything extra unnecessarily, solve the problem of disconnected connections and solve the problem in cases of loss / deletion / substitution of files

Answer 5

The server sends a file that contains the date of the last change relative to the user's time zone.
The user checks the modification date of the files. And writes them to an array The
user sends an array of "mismatched dates" and the server responds with json with hashes for files
Then we check the hashes for these files (we messed with the time zone in a friend)
And if it has changed, we load (or give the server a list of them and it generates in response archive with modified files)

Answer 6

Patches
- Not effective
- Too complicated, fraught with errors
- Support and speed of patch release and testing will become more difficult
How to do it (simplified scheme) 1. Get a
list of files and their hashes (all) from the server
(if the hash is not correct, we consider that the file does not exist)
3. Upload 1 packed file from the server (not an archive with all files, but one at a time)
4. Unpack the files, with replacement
5. Enjoy the updated version
You can not count the hash all the time, but store the hash value locally and if the date of the file has changed, then calculate the hash again.
This scheme is very simple, there are no patches, only those files that are needed are downloaded, you don’t even need to store the version number, because. file checking.

Answer 7

Get your git server up and running for binary releases and open source scripts since Microsoft hasn't spawned apt update in 20 years. In especially perverted cases, you can even give away part of the sources, and build stand-alone gcc on the client with the -arch=host optimization.