Разработка патчера к игре

[raol]

по поводу обновления с версии до версии, такой вариант — с поочередным накатываение всех патчей — адекватно оптимален с точки зрения разработки vs удобства применения. Да, в лоб, но зато меньше вероятности где-нибудь накосячить, плюс нет необходимости хранить (n * n -1)/2 патчей.

[RaveNoX]

ИМХО проще хранить на сервере копию последней версии + список общих хешей для файла + список хешей по чанкам.
При обновлении соответственно:
* получаем список хешей с сервера
* строим список хешей локального клиента
* если хеши не совпали — качаем хеши чанков, дальше через range запрос получаем конкретный кусок

Ещё вариант не делать велосипед и прикрутить ко всему этому торрент — получаем сразу чанки по всему клиенту + частичное снижение нагрузки на сервер, соответственно:
* новая версия — делаем торрент для неё, выкладываем на свой сервер по http
* апдейтер забирает торрент, качает всё что изменилось

P.S. мы в своё время через торренты бэкапы так рассылали по нескольким серверам

[naum]

«Чтобы меньше накосячить» — нужно вначале отладить «внутреннюю» инфраструктуру;
«Нет необходимости хранить гору патчей» — а нынче это не сложно, зато пользователю становится в n-раз удобнее / проще. И, да, с оценкой сложности вы ошиблись, как мне кажется, ибо достаточно иметь патч от каждой выпущенной версии до последней, да и в продакшен такая схема вписывается проще.

У меня иногда интересуются, может грохнем наши апдейт-файлы с того года? Они уже весят почти столько же, сколько оригинальный дистриб. Но нет, стою на своем, «все равно меньше» и так удобнее будет пользователям.

[agasper]

1. На самом деле так оно и происходит
2. Если принудительно пропишете свежую сборку, то ничего страшного не произойдет, патчер просто не обновит вам клиент. Для нас это не принципиально, т.к. клиент игры дополнительно сверяет с сервером версию протокола, и если клиент устарел, то его не пустит в игру.
3. У всех вариантов есть минусы. Мы выбрали этот, чтобы не увеличивать нагрузку на сервер. Учитывая малый размер патчей не вижу проблемы.

[qxfusion]

Честно говоря не только Blizzard так работают — EA/DICE также через Origin.

[qxfusion]

Для BF3 например — ОЧЕНЬ много дополнений идут, а если у Вас Premium Edition или Premium — то еще и все платные дополнения. Однако вот последний патч (исправление сингла) был небольшим — 36MB. (diff)

[qxfusion]

у них просто все ресурсы сделаны в виде фрагментов ФС — поэтому им нужно пересылать все блоки из-за этого, хотя могли бы и разностное сжатие использовать. По поводу Steam к сожалению не смотрел на эту тему — ничего не могу сказать.

[imbeat]

Ваш процесс загрузки и установки патчей:
for (int i = current_version; i < last_version; i++)
{
DownloadPatch(URL + string.Format("{0}_{1}", i, i+1));
ApplyDownloadedPatch();
}

То есть загрузка патчей и их установка происходит синхронно. Почему бы не качать следующий патч (если он есть) в то время, когда устанавливается текущий?!

PS в исходники не смотрел, код взят из поста.

[agasper]

Да, я думал так сделать. Планирую позже добавить и эту фичу.

[RedOctoberCZ]

Вполне годная идея: мы делали что-то подобное для одного из наших проектов. Только у нас основной exe'шник запускался только по команде патчера, т.е. пользователь сперва в любом случае запускал патчер, которые проверял обновления. Причём мы принудительно качали архив с XML со списком файлов и их md5 и проверяли по нему md5 всех локальных ресурсов. Если не находили нужный файл или находили несовпадение md5 — то перекачивали этот файл заново с сервера.

[Alver]

dev.chromium.org/developers/design-documents/software-updates-courgette

[theli]

все преимущества courgette проявляются только при работе с PE файлами

[ApeCoder]

а еще он основан на bsdiff

[theli]

Достойных кандидатов оказалось два.

Чем VCDIFF не подошёл?

[agasper]

Я смотрел в его сторону, но по нему меньше документации и готовых реализаций.

[theli]

Есть Xdelta3, OpenVCDIFF.
Наложение патча реализуется за пол часа посматривая одним глазом в RFC 3284.
Да и есть на C# реализация наложения патча готовая

[agasper]

Значит подходящая реализация RSync была выше в выдаче

[roman_pro]

В Windows есть готовый API для разностного сжатия, который используется, например, в процедуре установки хотфиксов Windows Update. Правда на больших файлах я его использовать не пробовал…

[qxfusion]

разве это не только для PE?
т.е. для данных нужно тогда их оборачивать в вид DLL RESOURCE.

[roman_pro]

API без проблем обрабатывает файлы любого типа, ничего оборачивать не нужно (когда-то успешно экспериментировал на bmp скриншотах при помощи утилит mpatch и apatch под Windows XP). Просто, как я понимаю, технология сжатия оптимизирована под PE файлы с учётом особенностей этого формата.

[agasper]

Я пробовал. У меня они так и не заработали. Окно просто закрывалось и ничего не происходило

[roman_pro]

Эти утилиты — консольные, их необходимо запускать из комадной строки и передавать 3 параметра — имена файлов:
mpatch.exe «c:\original_file» «c:\new_file» «c:\patch_file»
apatch.exe «c:\patch_file» «c:\old_file» «c:\new_patched_file»

Если так и делали, но ничего не работало, то ещё вопрос — библиотеку mspatchc.dll в папку к утилитам (или в system32) подкладывали? Её по умолчанию нет в системе Windows XP, а в этой библиотеке как раз находятся функции по созданию патчей. По умолчанию в системе есть только mspatcha.dll в которой только функции применения патчей.

[agasper]

Я все сделал как в документации. Поставил Windows SDK и запускал именно так.
P.S. Я не особо разбирался почему не заработало. Забил и пошел гуглить дальше.

[StrangeAttractor]

Меня, вот, всегда такой вопрос мучал: а что если изменится небольшой участок близко к началу файла и размер изменившегося куска не будет кратен размеру чанка? Патч в результате будет размером на весь файл?

[agasper]

Нет патч, будет небольшим. Если вас детально интересует алгоритм посмотрите тут: citforum.ru/nets/articles/rsync/