Открыть список
Как стать автором
Обновить

Комментарии 28

НЛО прилетело и опубликовало эту надпись здесь
по поводу обновления с версии до версии, такой вариант — с поочередным накатываение всех патчей — адекватно оптимален с точки зрения разработки vs удобства применения. Да, в лоб, но зато меньше вероятности где-нибудь накосячить, плюс нет необходимости хранить (n * n -1)/2 патчей.
ИМХО проще хранить на сервере копию последней версии + список общих хешей для файла + список хешей по чанкам.
При обновлении соответственно:
* получаем список хешей с сервера
* строим список хешей локального клиента
* если хеши не совпали — качаем хеши чанков, дальше через range запрос получаем конкретный кусок

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

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

У меня иногда интересуются, может грохнем наши апдейт-файлы с того года? Они уже весят почти столько же, сколько оригинальный дистриб. Но нет, стою на своем, «все равно меньше» и так удобнее будет пользователям.
1. На самом деле так оно и происходит
2. Если принудительно пропишете свежую сборку, то ничего страшного не произойдет, патчер просто не обновит вам клиент. Для нас это не принципиально, т.к. клиент игры дополнительно сверяет с сервером версию протокола, и если клиент устарел, то его не пустит в игру.
3. У всех вариантов есть минусы. Мы выбрали этот, чтобы не увеличивать нагрузку на сервер. Учитывая малый размер патчей не вижу проблемы.
Честно говоря не только Blizzard так работают — EA/DICE также через Origin.
НЛО прилетело и опубликовало эту надпись здесь
Для BF3 например — ОЧЕНЬ много дополнений идут, а если у Вас Premium Edition или Premium — то еще и все платные дополнения. Однако вот последний патч (исправление сингла) был небольшим — 36MB. (diff)
НЛО прилетело и опубликовало эту надпись здесь
у них просто все ресурсы сделаны в виде фрагментов ФС — поэтому им нужно пересылать все блоки из-за этого, хотя могли бы и разностное сжатие использовать. По поводу Steam к сожалению не смотрел на эту тему — ничего не могу сказать.
Ваш процесс загрузки и установки патчей:
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 — то перекачивали этот файл заново с сервера.
все преимущества courgette проявляются только при работе с PE файлами
а еще он основан на bsdiff
Достойных кандидатов оказалось два.

Чем VCDIFF не подошёл?
Я смотрел в его сторону, но по нему меньше документации и готовых реализаций.
Есть Xdelta3, OpenVCDIFF.
Наложение патча реализуется за пол часа посматривая одним глазом в RFC 3284.
Да и есть на C# реализация наложения патча готовая
Значит подходящая реализация RSync была выше в выдаче
разве это не только для PE?
т.е. для данных нужно тогда их оборачивать в вид 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 в которой только функции применения патчей.
Я все сделал как в документации. Поставил Windows SDK и запускал именно так.
P.S. Я не особо разбирался почему не заработало. Забил и пошел гуглить дальше.
Меня, вот, всегда такой вопрос мучал: а что если изменится небольшой участок близко к началу файла и размер изменившегося куска не будет кратен размеру чанка? Патч в результате будет размером на весь файл?
Нет патч, будет небольшим. Если вас детально интересует алгоритм посмотрите тут: citforum.ru/nets/articles/rsync/
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.