Comments 28
UFO just landed and posted this here
по поводу обновления с версии до версии, такой вариант — с поочередным накатываение всех патчей — адекватно оптимален с точки зрения разработки vs удобства применения. Да, в лоб, но зато меньше вероятности где-нибудь накосячить, плюс нет необходимости хранить (n * n -1)/2 патчей.
ИМХО проще хранить на сервере копию последней версии + список общих хешей для файла + список хешей по чанкам.
При обновлении соответственно:
* получаем список хешей с сервера
* строим список хешей локального клиента
* если хеши не совпали — качаем хеши чанков, дальше через range запрос получаем конкретный кусок
Ещё вариант не делать велосипед и прикрутить ко всему этому торрент — получаем сразу чанки по всему клиенту + частичное снижение нагрузки на сервер, соответственно:
* новая версия — делаем торрент для неё, выкладываем на свой сервер по http
* апдейтер забирает торрент, качает всё что изменилось
P.S. мы в своё время через торренты бэкапы так рассылали по нескольким серверам
При обновлении соответственно:
* получаем список хешей с сервера
* строим список хешей локального клиента
* если хеши не совпали — качаем хеши чанков, дальше через range запрос получаем конкретный кусок
Ещё вариант не делать велосипед и прикрутить ко всему этому торрент — получаем сразу чанки по всему клиенту + частичное снижение нагрузки на сервер, соответственно:
* новая версия — делаем торрент для неё, выкладываем на свой сервер по http
* апдейтер забирает торрент, качает всё что изменилось
P.S. мы в своё время через торренты бэкапы так рассылали по нескольким серверам
«Чтобы меньше накосячить» — нужно вначале отладить «внутреннюю» инфраструктуру;
«Нет необходимости хранить гору патчей» — а нынче это не сложно, зато пользователю становится в n-раз удобнее / проще. И, да, с оценкой сложности вы ошиблись, как мне кажется, ибо достаточно иметь патч от каждой выпущенной версии до последней, да и в продакшен такая схема вписывается проще.
У меня иногда интересуются, может грохнем наши апдейт-файлы с того года? Они уже весят почти столько же, сколько оригинальный дистриб. Но нет, стою на своем, «все равно меньше» и так удобнее будет пользователям.
«Нет необходимости хранить гору патчей» — а нынче это не сложно, зато пользователю становится в n-раз удобнее / проще. И, да, с оценкой сложности вы ошиблись, как мне кажется, ибо достаточно иметь патч от каждой выпущенной версии до последней, да и в продакшен такая схема вписывается проще.
У меня иногда интересуются, может грохнем наши апдейт-файлы с того года? Они уже весят почти столько же, сколько оригинальный дистриб. Но нет, стою на своем, «все равно меньше» и так удобнее будет пользователям.
1. На самом деле так оно и происходит
2. Если принудительно пропишете свежую сборку, то ничего страшного не произойдет, патчер просто не обновит вам клиент. Для нас это не принципиально, т.к. клиент игры дополнительно сверяет с сервером версию протокола, и если клиент устарел, то его не пустит в игру.
3. У всех вариантов есть минусы. Мы выбрали этот, чтобы не увеличивать нагрузку на сервер. Учитывая малый размер патчей не вижу проблемы.
2. Если принудительно пропишете свежую сборку, то ничего страшного не произойдет, патчер просто не обновит вам клиент. Для нас это не принципиально, т.к. клиент игры дополнительно сверяет с сервером версию протокола, и если клиент устарел, то его не пустит в игру.
3. У всех вариантов есть минусы. Мы выбрали этот, чтобы не увеличивать нагрузку на сервер. Учитывая малый размер патчей не вижу проблемы.
Честно говоря не только Blizzard так работают — EA/DICE также через Origin.
Ваш процесс загрузки и установки патчей:
for (int i = current_version; i < last_version; i++)
{
DownloadPatch(URL + string.Format("{0}_{1}", i, i+1));
ApplyDownloadedPatch();
}
То есть загрузка патчей и их установка происходит синхронно. Почему бы не качать следующий патч (если он есть) в то время, когда устанавливается текущий?!
PS в исходники не смотрел, код взят из поста.
for (int i = current_version; i < last_version; i++)
{
DownloadPatch(URL + string.Format("{0}_{1}", i, i+1));
ApplyDownloadedPatch();
}
То есть загрузка патчей и их установка происходит синхронно. Почему бы не качать следующий патч (если он есть) в то время, когда устанавливается текущий?!
PS в исходники не смотрел, код взят из поста.
Вполне годная идея: мы делали что-то подобное для одного из наших проектов. Только у нас основной exe'шник запускался только по команде патчера, т.е. пользователь сперва в любом случае запускал патчер, которые проверял обновления. Причём мы принудительно качали архив с XML со списком файлов и их md5 и проверяли по нему md5 всех локальных ресурсов. Если не находили нужный файл или находили несовпадение md5 — то перекачивали этот файл заново с сервера.
Достойных кандидатов оказалось два.
Чем VCDIFF не подошёл?
В Windows есть готовый API для разностного сжатия, который используется, например, в процедуре установки хотфиксов Windows Update. Правда на больших файлах я его использовать не пробовал…
разве это не только для PE?
т.е. для данных нужно тогда их оборачивать в вид DLL RESOURCE.
т.е. для данных нужно тогда их оборачивать в вид DLL RESOURCE.
API без проблем обрабатывает файлы любого типа, ничего оборачивать не нужно (когда-то успешно экспериментировал на bmp скриншотах при помощи утилит mpatch и apatch под Windows XP). Просто, как я понимаю, технология сжатия оптимизирована под PE файлы с учётом особенностей этого формата.
Я пробовал. У меня они так и не заработали. Окно просто закрывалось и ничего не происходило
Эти утилиты — консольные, их необходимо запускать из комадной строки и передавать 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 в которой только функции применения патчей.
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 в которой только функции применения патчей.
Меня, вот, всегда такой вопрос мучал: а что если изменится небольшой участок близко к началу файла и размер изменившегося куска не будет кратен размеру чанка? Патч в результате будет размером на весь файл?
Нет патч, будет небольшим. Если вас детально интересует алгоритм посмотрите тут: citforum.ru/nets/articles/rsync/
Sign up to leave a comment.
Разработка патчера к игре