Какова правильная логика обновления клиента игры?

Question

[IPv4]

Всем привет. Появилась необходимость в создании приложения, являющегося своего родом "лаунчером" (запускатором) для одной игры.
Единственная загвоздка, с которой я столкнулся - правильное обновление файлов игры.
Видов обновления может быть два:

• Полное обновление
  
• Частичное обновление
  

Если с первым пунктом все более-менее понятно (архив со всеми файлами загружаем и распаковываем), то со вторым пунктом не особо. Нет, конечно, можно при запуске приложения проверять версию программы и сравнивать с последней, той, что на сервере. Если локального файла версии нет, то качать полное обновление и прописывать версию из архива с этим обновлением, после чего снова сравнивать версию и если различается, то качать патч для этой версии и накатывать обновление сверху.

Вопрос первый: Насколько эффективно и эстетично обновление посредством загрузки патчей? То есть, версия будет иметь формат: 3.2.11.25. При запуске приложения/проверки наличия обновлений и загрузки обновлений будет проверяться версия. Если версия не соответствует, будет осуществляться проверка на то, какая из блоков цифр в версии отличается. То есть, если у пользователя версия 3.2.11.10, а на сервере 3.2.11.25, то качаться будут версии с *.*.*.10 по *.*.*.25 по очереди и накатывать патчи каждой из этих версий. А на сервере будет храниться какой нибудь файл с версиями, где они все будут перечисляться.

Вопрос второй: Как по-вашему мнению реализовано это у Steam? Загрузка по частям заголовками? Трафик во-время загрузки файлов идет через 80 порт с серверов Valve и content-type там application/octet-stream. Значит я прав? Но ведь не один большой файл таким образом качается, а много мелких, значит это просто отдача файлов таким образом у них осуществляется.
Как у них осуществляется проверка наличия даже самого ненужного файла? Удалил файл из каталога, а он берет и докачивает его. Проверяет перед запуском все каталоги на время изменения и сравнивает с серверными?

Вопрос третий: Насколько эффективно будет сравнивать время изменения каталогов у пользователя и сравнивать с серверными? Ведь если даже в самой глубокой директории был изменен/удален/создан файл, то самый верхний по иерархии каталог будет иметь дату изменения ту, когда был затронут файл. Соответственно, таким образом можно избежать большого количества рекурсивных проверок.
И, соответственно, обновиться будет проще. Удаляем измененный каталог и закачиваем заново.

Какое ваше мнение? Можете что то подсказать по-этому поводу?

Comments

[IPv4]

Остановился на следующем варианте:
При запуске клиента проверяется наличие файла с версией. Если такового нет, то происходит операция полного обновления (Загружается список всех файлов и сверяются их хеши с теми, что присутствуют в клиенте. Совпадения удаляются на этапе проверки. Недостающие загружаются.).
Если файл есть и версия совпадает, то загружается легкий файл со списком всех каталогов. Если все каталоги на месте, то разрешаем запустить игру. Если какой то отсутствует, то происходит операция полного обновления.
Если файл есть и версия не совпадает, но версия клиента присутствует в истории версий на сервере, то загружается список версий от версии клиента до текущей и накатываются патчи, после чего загружается легкий файл со списком всех каталогов. Если все каталоги на месте, то разрешаем запустить игру.

Причина, по которой я сделал так - равнение на крупные игровые проекты, типа Steam, 4Game, Origin. Касательно Steam в шапке я ошибался - отсутствие даже важных файлов для игры не является поводом для обновления.

Всем большое спасибо за участие. Методы, которые были описаны вами, но мной не использованы, я взял на вооружение.

Answer 1

[Дмитрий Энтелис]

Из личного опыта: imho самое правильное это иметь неразрывную цепочку обновлений с первой версии до текущей, т.е 1>2, 2>3, 3>4 итд.
Периодически для чистой установки выпускать мажорные версии, - но при этом все равно иметь неразрывную цепочку обновлений.

Делать патчи вида 1>4, 2>4 итд - по моему опыту архи неправильно, т.к создает огромные риски неявных багов + затраты на сборку таких патчей.

По факту для пользователя нет проблемы установить много обновлений.

Будет осуществляться проверка на то, какая из блоков цифр в версии отличается.

Это Вы какие то мелкие частности обсуждаете.

Как у них осуществляется проверка наличия даже самого ненужного файла? Удалил файл из каталога, а он берет и докачивает его. Проверяет перед запуском все каталоги на время изменения и сравнивает с серверными?

Вопрос третий: Насколько эффективно будет сравнивать время изменения каталогов у пользователя и сравнивать с серверными? Ведь если даже в самой глубокой директории был изменен/удален/создан файл, то самый верхний по иерархии каталог будет иметь дату изменения ту, когда был затронут файл. Соответственно, таким образом можно избежать большого количества рекурсивных проверок.
И, соответственно, обновиться будет проще. Удаляем измененный каталог и закачиваем заново.

Привязываться к дате изменений - не лучшая идея. Проверка обходит каталоги рекурсивно, сравнивает не только список файлов но и их хеши. Почитайте как работает dropbox/яндекс.диск, да тот же торрент наконец

Comments

[IPv4]

Про хеши файлов я подумал в первую очередь. Но не определился с способом проверки этих хешей. Либо рекурсивно бежать по каталогам и хэш каждого файла отправлять на сервер и там сверять (банально класть рядом с файлами на сервере файл с таким же названием, но расширением .sum, где будет прописан хэш этого файла) либо загружать на период проверки файл со всеми путями и хешами и проверять локально. В первом случае будет много запросов на сервер. Во втором же слишком уж тяжелый файл придется держать в памяти. Файлов то очень много.

Пока склоняюсь именно к промежуточным патчам (1>2,2>3,3>4). Самый оптимальный вариант.

з.ы. эдакая у Вас подпись, спасибо, что счет не выписали)

[AtomKrieg]

Зачем хэш целого файла считать? Версию в заголовок влепить.

[IPv4]

AtomKrieg: не совсем понял что Вы имели ввиду.

[Дмитрий Энтелис]

IPv4: очевидно что "загружать на период проверки файл со всеми путями и хешами и проверять локально."
Я вас умоляю, ну какие тяжелые файлы. У меня вся папка Steam со всеми играми - 16,5k файлов.
Хеш md5 16 байт, еще байт 200-300 на путь и имя файла. (хотя путь и имя файла тоже можно хешировать).
Получается весь файл 30-40 мегабайт. Нынче 1 вкладка хрома больше жрет в разы

Answer 2

[xmoonlight]

Есть версия и есть хеш-сумма текущей версии всех данных приложения (файлы + БД).
При запуске - проверяются оба значения.
При несоответствии - выполняется операция синхронизации:
1. Выявление различий
2. Подготовка списка изменений относительно текущей версии у пользователя
3. Резервирование текущей версии пользователя
4. Загрузка всех необходимых файлов на устройство пользователя. (с возможностью докачки при разрыве соединения)
5. Выполнение изменений.
6. Проверка сделанных изменений (п.1)
7. Удаление резервной копии (созданную в п.3)
При прерывании любого из пунктов (сел аккумулятор у ПК или смартфона и прочее) - всегда должна быть возможность продолжить обновление с прерванного шага.

Answer 3

[Alexander Movchan]

Честно говоря, я с этим не сталкивался, но я бы попробовал сделать так:
Допустим, мы выпускаем новую версию - 2.46. При этом на сервер мы заливаем полную версию для чистой установки или для обновления с очень старых версий, и делаем n-ное количество патчей 2.45to2.46, 2.44to2.46, 2.43to2.46... Так, если пользователь отстаёт на несколько версий, он просто загрузит минимально необходимую разницу между его версией и актуальной, если же у пользователя очень старая версия, он скачивает заново весь клиент.
Таким образом минимизируется количество загрузок для пользователя, а следовательно уменьшится нагрузка и на сервер.

Comments

[IPv4]

Да, в этом есть смысл, этот способ хорошо дополняет идею с патчами. И мне такой способ нравится, за исключением одного - после каждого обновления клиента игры на сервере придется заново создавать все патчи для обновления до последней версии.

[Alexander Movchan]

IPv4: это можно без проблем автоматизировать, зато гораздо удобнее для пользователя.

Answer 4

[Neonoviiwolf]

Сервак сообщает актуальную версию программы, если нет совпадения, то сбрасывает хеш всех файлов новой версии программы, дальше программа на стороне клиента обходит рекурсивно каждый файл и сравнивает хеш, если не совпадает/не находит, качает с сервера. После полной загрузки обновления, изменяет версию ПО.
Тут вам и лишний ничего не скачает без необходимости, решит проблему обрывов соединения и решит проблему в случаи утраты/удаления/подмены файлов

Comments

[IPv4]

Тем не менее, проверка всех файлов осуществляться будет, а не той части, что необходима. Этот момент тоже интересует отчасти.
Предположим, есть следующая иерархия:

• dir1
  • dir1_1
    
  • dir1_2
    
  • dir1_3
    
  
  
• dir2
  • dir2_1
    
  • dir2_2
    
  • dir2_3 (файл в этом каталоге был изменен/удален)
    
  
  
• dir3
  • dir3_1
    
  • dir3_2
    
  • dir3_3
    
  
  

Соответственно, время изменения содержимого каталога dir2_3 будет отличаться от серверного. А если там есть вложенные подкаталоги, то и время тех директорий, в которых в конце концов изменялся/удалялся файл.
А значит быстрее будет пробежаться поверхностно по датам изменения каталогов и сравнить их с серверными значениями и если есть несоответствия, уже шерстить по этому каталогу.
В приведенном примере проверятся даты каталогов dir1,dir2,dir3 и дальше будут проверяться даты только каталогов в директории dir2. Остальные проигнорируются.
Или я ошибаюсь и могу натолкнуться на какие то подводные камни?

[Neonoviiwolf]

IPv4: обрыв соединения при обновлении/случайное удаление файлов пользователем/другими программами и т.п. Так же полностью решает проблему обновления любой версии ПО до актуальной. Если вы не намерены каждый день делать новые релизы, то 30 сек или 60 сек работы не кажется, лично мне, трагедией, но решать в итоге вам

Answer 5

[Владимир Грабко]

Сервер отдаёт файл в котором указана дата последнего изменения отнсительно часового пояса юзера.

Юзер проверяет дату изменения файлов. И пишет их в массив
Юзер шлёт массив "не совпавших дат" и сервер в ответ отдаёт json с хешами для файлов

Потом проверяем хеши для этих файлов (в друг с часовым поясом намутили)
И если изменился загружаем (или даём серверу их список и он генерит в ответ архив с изменёнными файлами)

Answer 6

[Михаил]

Патчи
- Не эффективно
- Слишком сложно, чревато ошибками
- Усложнится поддержка и скорость выпуска патча, его тестирование

Как можно сделать (упрощённая схема)
1. Получаем с сервера список файлов и их хешей (всех)
2. Проверяем есть ли у пользователя все эти файлы (если хеш не корректен, считаем что файла нет)
3. Закачиваем по 1 запакованному файлу с сервера (не архив со всеми файлами, а именно по одному)
4. Распаковываем файлы, с заменой
5. Наслаждаемся обновлённой версией

Можно не считать хеш постоянно, а сохранять значение хеша локально и если дата файла изменилась, тогда считать хеш снова.
Данная схема очень проста, нет никаких патчей, качаются только те файлы, которые нужны, не нужно даже хранить номер версии, т.к. проверка по файлам.

Comments

[IPv4]

У 4Game, например, сделано иначе:
Вышло обновление - загружаем обновление.
И после обновления файлы не загрузятся те, которые были удалены до начала последнего обновления, если они в этот апдейт не входили.
Уже остановился на конкретном варианте, напишу в комментарии под шапкой.

Answer 7

[dponyatov]

Поднимите свой git-сервер для бинарных релизов и открытых скриптов, раз уж Microsoft за 20 лет не разродился apt update. В особо извращенных случаях можно даже отдавать часть исходников, и собирать stand-alone gcc на клиенте с оптимизацией -arch=host.

Comments

[dponyatov]

Из фич можно отметить встроенную авторизацию по SSH-ключу, уникальному для каждого клиента, и все встроенные механизмы гита, включая откаты и локальные ветки для скриптов пользователя.

[Mingun]

Вот еще бы иметь легкую библиотеку для встраивания этого в свои приложения. Посмотреть, сколько git места на винде занимает к примеру -- ужаснуться можно.