Написал updater к программе. Процесс происходит следующим образом:

• updater вытягивает из интернета файл version.xml;
  
• содержимое этого файла сравнивается с таким же файлом у приложения;
  
• файлы с отличающимися версиями качаются и переписываются;
  
• запускается основное приложение;

Все работает, но мне не нравится... некрасиво это как-то, не гармонично... Поэтому решил спросить здесь. Кто как обеспечивает обновление своих программ? И второй вопрос: если мне необходимо изменить сам updater — как это сделать? Скачать я его конечно же могу, но не могу переписать поверх запущенного.
Спасибо.

I>Все работает, но мне не нравится... некрасиво это как-то, не гармонично...

Можешь почетче сформулировать, что именно тебе не нравится? Для простого приложения вроде — самое то, ничего больше и не нужно.

I>И второй вопрос: если мне необходимо изменить сам updater — как это сделать? Скачать я его конечно же могу, но не могу переписать поверх запущенного.

Отчего же? Просто перед заменой исполняемого файла самого updater'а переименуй его и перекинь куда-нибудь в %TEMP%. При следующем запуске удалишь.

Ну или запускай другой процесс, который дождется завершения updater'а и произведет подмену.

Здравствуйте, ingvarwolf, Вы писали:

Если работаете с .NET можете посмотреть в сторону Updater Application Block из Microsoft Enterprise Library.

Здравствуйте, ingvarwolf, Вы писали:

I>Написал updater к программе. Процесс происходит следующим образом:
I>

updater вытягивает из интернета файл version.xml;
I>

содержимое этого файла сравнивается с таким же файлом у приложения;
Может быть надо сравнивать с версиями самих файлов.

I>

файлы с отличающимися версиями качаются и переписываются;
Стоит добавить проверку целостности скачанных файлов.

I>

запускается основное приложение;

Здравствуйте, ingvarwolf, Вы писали:

I>Все работает, но мне не нравится... некрасиво это как-то, не гармонично... Поэтому решил спросить здесь. Кто как обеспечивает обновление своих программ?

http://msdn.microsoft.com/msdnmag/issues/03/02/bits/

?

I>>

файлы с отличающимися версиями качаются и переписываются;
W>Стоит добавить проверку целостности скачанных файлов.
А разве TCP протокол уже перестал быть надежным?

Или вы имеете ввиду возможную атаку? мне кажется этот вариант низковероятным.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, savaDAN, Вы писали:

I>>>

файлы с отличающимися версиями качаются и переписываются;
W>>Стоит добавить проверку целостности скачанных файлов.
DAN>А разве TCP протокол уже перестал быть надежным?
А вы никогда не скачивали битых файлов?

DAN>Или вы имеете ввиду возможную атаку? мне кажется этот вариант низковероятным.
Нет, это отдельный вопрос.

I>>>>

файлы с отличающимися версиями качаются и переписываются;
W>>>Стоит добавить проверку целостности скачанных файлов.
DAN>>А разве TCP протокол уже перестал быть надежным?
W>А вы никогда не скачивали битых файлов?
За 10 лет работы с инетом только один раз — когда дебагировали самописный сетевой драйвер на работе...
Очень любопытно было кстати глядеть на реакцию приложений

Я ж вам говорю — TCP сети гарантируют доставку. Т.е. пакеты и так проверяются на целостность на нижних уровнях и городить для TCP подобную проверку если не стоит проблема атаки бессмысленно.

PS: расскажите мне где в HTTP есть проверка целостности?

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, savaDAN, Вы писали:

I>>>>>

файлы с отличающимися версиями качаются и переписываются;
W>>>>Стоит добавить проверку целостности скачанных файлов.
DAN>>>А разве TCP протокол уже перестал быть надежным?
W>>А вы никогда не скачивали битых файлов?
DAN>За 10 лет работы с инетом только один раз — когда дебагировали самописный сетевой драйвер на работе...
DAN>Очень любопытно было кстати глядеть на реакцию приложений

DAN>Я ж вам говорю — TCP сети гарантируют доставку. Т.е. пакеты и так проверяются на целостность на нижних уровнях и городить для TCP подобную проверку если не стоит проблема атаки бессмысленно.

DAN>PS: расскажите мне где в HTTP есть проверка целостности?

А как насчет докачки файлов?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

DAN>>Я ж вам говорю — TCP сети гарантируют доставку. Т.е. пакеты и так проверяются на целостность на нижних уровнях и городить для TCP подобную проверку если не стоит проблема атаки бессмысленно.

DAN>>PS: расскажите мне где в HTTP есть проверка целостности?

P>А как насчет докачки файлов?
Уточните контекст вопроса.
Если речь идет о докачке в HTTP, то там используется свойство Range, клиент сам определяет какой Range спросить у сервера.
см. RFC 2616

Если речь идет о сервере обновлений — тут уже надо смотреть на каком транспорте осуществляется получение данных.
В любом случае, не пойму как это соотносится с контрольными суммами?

Здравствуйте, savaDAN, Вы писали:

DAN>PS: расскажите мне где в HTTP есть проверка целостности?
Да вроде нет, а что?

iT>Можешь почетче сформулировать, что именно тебе не нравится?
Да в том-то и дело, что четко сформулировать не могу. Просто как-то не так это выглядит. Хотя сегодня на работе пересмотрели этот процесс, он немного изменился, какие-то детали добавились, так что может следующая версия получится более гармоничной...

iT>Отчего же? Просто перед заменой исполняемого файла самого updater'а переименуй его и перекинь куда-нибудь в %TEMP%. При следующем запуске удалишь.
iT>Ну или запускай другой процесс, который дождется завершения updater'а и произведет подмену.
Спасибо за идею.

V>Если работаете с .NET можете посмотреть в сторону Updater Application Block из Microsoft Enterprise Library.
Спасибо, но у меня пока не .NET проект

W>Может быть надо сравнивать с версиями самих файлов.
Я и сравниваю версии файлов, а не сами файлы. Просто может я неточно выразился.

W>Стоит добавить проверку целостности скачанных файлов.
О, спасибо... Наверное сделаю checksum какой-нибудь.

Здравствуйте, savaDAN, Вы писали:
DAN>А разве TCP протокол уже перестал быть надежным?
Совершенно верно. Единственная проблема в TCP — "бесконечность" потока. Битость файлов при скачивании возникает вследствие одной из двух проблем:
1. Косяк при реализации прикладного протокола. Особенно разработчики серверов любят косячить при реализации докачки. Не знаю, как сейчас, а в старые времена IIS глючил при докачке на его FTP. Download работал нормально, а upload стабильно запарывал файлы. Но это не вина TCP. Это проблема приложений, закачивающих не те байты.
2. Обрыв соединения, который не получается отличить от корректного окончания передачи.
При построении прикладного протокола надо закладывать либо передачу размера в заголовке стрима, либо на явный маркер конца стрима. Этого достаточно для корректной передачи информации.

Здравствуйте, ingvarwolf, Вы писали:

W>>Может быть надо сравнивать с версиями самих файлов.
I>Я и сравниваю версии файлов, а не сами файлы. Просто может я неточно выразился.
Возможно это я неточно выразился. Я предлагал сравнивать версию из обновленного XML файла с версией из ресурса VersionInfo имеющегося файла. В то время как сейчас (как я понял) сравнивается версия из обновленного XML файла с версией из имеющегося XML файла.

W>Возможно это я неточно выразился. Я предлагал сравнивать версию из обновленного XML файла с версией из ресурса VersionInfo имеющегося файла. В то время как сейчас (как я понял) сравнивается версия из обновленного XML файла с версией из имеющегося XML файла.
А есть VersionInfo у flash файлов?

S>http://msdn.microsoft.com/msdnmag/issues/03/02/bits/
У меня не .NET

Здравствуйте, ingvarwolf, Вы писали:

I>А есть VersionInfo у flash файлов?
Думаю что нет (хотя не проверял ). Но засунуть в него сигнатуру и версию так или иначе наверное можно.

Здравствуйте, ingvarwolf, Вы писали:

S>>http://msdn.microsoft.com/msdnmag/issues/03/02/bits/
I>У меня не .NET

.NET тут не при чем. BITS API доступен в виде COM интерфейсов. И я, кстати, присоединюсь к рекомендации snake. Все лучше использовать стандартный системный сервис, чем в очередной раз изобретать велосипед.