В сети (в инете ив локалках) пользователи часто обмениваются файлами, упаковывая их в архивы (RAR или ZIP). При этом для архивов RAR часто используется опция добавления информации для восстановления, добавляющая в конец архива 3-10% избыточных данных, с помощью которых можно восстановить архив, если часть других данные испортились. Хотелось бы определиться, имеется ли в этом смысл и какие методы следует использовать, чтобы надёжно обмениваться файлами при минимальных затратах трафика.
Смежные темы:
восстановление битых кусков с помощью других юзеров;
защита с помощью избыточного кода;
То же (с упоминанием про File Doctor).
Опять же (ICEECC, QuickPAR и другие)
Ну и конечно, исходная тема про WinRAR.
Сперва немного про раздачу файлов:
Файло обычно выкладывают на FTP (а) и в web-обменник типа Рапиды (b). Более прогрессивные технологии типа p2p пока не так распространены, да и проблем с битыми файлами там нет, так что про них не будем.
(a) На FTP возможен сбой при закачке, если сервер очень плохо настроен и на нём отключен набор функций для контроля целостности: mode z (также даёт сжатие на лету при передаче данных), проверку CRC и т.п. Если у выкладывающего или у качающих юзеров заведомо плохой канал, то нелишне будет один раз проверить, не испорчен ли FTP, и при необходимости выбрать другой или настроить данный (просто попросить админа, если это локалка) -- это снимет куда больше проблем с юзеров, чем все манипуляции с исходным файлом (которые по-любому ложатся на юзера). Ну и, естественно, в FTP-клиенте выкладывающий и качающие должны включить (не отключать) те же фичи, позволяющие проверять целостность данных.
На более низких уровнях сети также есть такие проверки, но в заведомо плохих условиях они, видимо, криво настроены и не действуют (хотя мне сходу трудно представить, как можно отключить все проверки сессионного-канального-сетевого-транспортного уровней).
(b) С веб-обменниками всё проще: данные обрабатывает серверный скрипт, функционал которого ограничен только фантазией (и бюджетом:) автора, так что там могут быть любые проверки (например, на целостонсть архивов). Надо только выбрать подходящий обменник. Проблемы с сетью в этом случае обычно проявляются в виде обрывов связи, которые легко заметны и решаются функционалом докачки у сервера и клиента (и не решаются информацией для восстановления).
Итак, есть исходный файл, например, AVI на 100Mb, и есть убитая на всех уровнях сеть, в которой файлы при передаче могут портиться. Условимся также, что файлы выкладывается не для одного-двух конкретных юзеров (с которыми проще отдельно договориться о предпочтительном формате обмена), а "для всех", когда требуется создать комфортные условия большинству. (Мне тут кажется очевидным, что при таком подходе выкладывающему следует проверить залитые файлы и перезалить в случае проблем при аплоаде.)
Выкладываем на FTP (вариант выкладывания в веб-обменник не рассматриваю, т.к. там любая информация "для восстановления" абсолютно лишняя):
Вариант 1: Заливаем сам файл без изменений и дополнений.
Тут всё просто: что скачали (100Мб), то и смотрим; если где-то что-то побилось, то либо этот кусок не смотрим, либо весь файл -- тогда остаётся только скачать его заново (+100Мб). (Отдельные умельцы пользуются докачкой, обрезая скаченный файл с побитого места;)
Вариант 2: Разбиваем файл на тома и заливаем.
Это можно сделать ВинРаром или или любым другим способом, доступным юзерам (например, TC). В результате получаем куски (скажем, 10 по 10Мб), проверку целостности при сборке и возможность закачки только нужного куска, если он побился (+10Мб).
Вариант 3: Пакуем ВинРаром с разбиением на тома и добавляем том для восстановления.
Получается 11 файлов по 10Мб, из которых можно использовать любые 10. При нормальной связи качаются первые 10 томов (100Мб), в случае сбоя докачивается 11-й (восстановительный) том (+10Мб). Неуверенные в себе (в своём канале) качают сразу всё (110Мб) и при необходимости восстанавливают битый том.
3а: Дополнительно можно слегка добавить информации для восстановления в каждый том (0.1-1%), если при передаче предполагаются множественные недиагностируемые сбои. Получится 101Мб +10.1Мб резервный том.
3б: Или (чтобы совсем бессмертный архив создать:) можно разбить файл на 100 томов по 1Мб и добавить 10 томов для восстановления. Те же 100Мб + 10Мб, но в более гибком и надёжном виде.
Вариант 4: Пакуем ВинРаром (с разбиением на тома или без) и добавляем информацию для восстановления (скажем, 10%). Все юзеры качают все 110Мб, если скачалось криво -- восстанавливают (кто умеет).
Т.о. если сбев нет, то варианты 1, 2 и 3 позволяют скачать только нужные 100Мб, вариант 4 -- все 110Мб.
Если незначительные сбои есть, то в варианте 1 придётся качать заново (100Мб), в вариантах 2 и 3 нужно скачать дополнительный том (10Мб), а в варианте 4 оно и так скачано.
Если есть множественные сбои в разных местах, то в варианте 1 всё то же, в вариантах 2 и 3 придётся скачать все попортившиеся тома, а в варианте 4 перед этим можно попробовать использовать информацию для восстановления. В вариантах 3а и 3б скорее всего удастся восстановить информацию, ничего не скачивая, либо скачав дополнительны том (тома) для восстановления (в 3б это 1...10Мб в зависимости от объёма повреждений). После этого в любом случае стоит перейти на другой вариант файлообмена: даже при низком качестве каналов современные технологии позволяют полностью автоматизировать проверку и повторную пересылку данных при передаче. Все же в Глобальной сети -- удалённость от Петербурга (или там от Сан-Хосе) не играет значительной роли при выборе технологии.
Добавлено:
Собственно, вопрос возник из того, что наиболее предпочтительными для большинства случаев кажутся варианты 1-3, а большинство выкладывателей почему-то использует вариант 4. Особенно это непонятно в случае веб-обменников -- там-то чему портиться?
Смежные темы:
восстановление битых кусков с помощью других юзеров;
защита с помощью избыточного кода;
То же (с упоминанием про File Doctor).
Опять же (ICEECC, QuickPAR и другие)
Ну и конечно, исходная тема про WinRAR.
Сперва немного про раздачу файлов:
Файло обычно выкладывают на FTP (а) и в web-обменник типа Рапиды (b). Более прогрессивные технологии типа p2p пока не так распространены, да и проблем с битыми файлами там нет, так что про них не будем.
(a) На FTP возможен сбой при закачке, если сервер очень плохо настроен и на нём отключен набор функций для контроля целостности: mode z (также даёт сжатие на лету при передаче данных), проверку CRC и т.п. Если у выкладывающего или у качающих юзеров заведомо плохой канал, то нелишне будет один раз проверить, не испорчен ли FTP, и при необходимости выбрать другой или настроить данный (просто попросить админа, если это локалка) -- это снимет куда больше проблем с юзеров, чем все манипуляции с исходным файлом (которые по-любому ложатся на юзера). Ну и, естественно, в FTP-клиенте выкладывающий и качающие должны включить (не отключать) те же фичи, позволяющие проверять целостность данных.
На более низких уровнях сети также есть такие проверки, но в заведомо плохих условиях они, видимо, криво настроены и не действуют (хотя мне сходу трудно представить, как можно отключить все проверки сессионного-канального-сетевого-транспортного уровней).
(b) С веб-обменниками всё проще: данные обрабатывает серверный скрипт, функционал которого ограничен только фантазией (и бюджетом:) автора, так что там могут быть любые проверки (например, на целостонсть архивов). Надо только выбрать подходящий обменник. Проблемы с сетью в этом случае обычно проявляются в виде обрывов связи, которые легко заметны и решаются функционалом докачки у сервера и клиента (и не решаются информацией для восстановления).
Итак, есть исходный файл, например, AVI на 100Mb, и есть убитая на всех уровнях сеть, в которой файлы при передаче могут портиться. Условимся также, что файлы выкладывается не для одного-двух конкретных юзеров (с которыми проще отдельно договориться о предпочтительном формате обмена), а "для всех", когда требуется создать комфортные условия большинству. (Мне тут кажется очевидным, что при таком подходе выкладывающему следует проверить залитые файлы и перезалить в случае проблем при аплоаде.)
Выкладываем на FTP (вариант выкладывания в веб-обменник не рассматриваю, т.к. там любая информация "для восстановления" абсолютно лишняя):
Вариант 1: Заливаем сам файл без изменений и дополнений.
Тут всё просто: что скачали (100Мб), то и смотрим; если где-то что-то побилось, то либо этот кусок не смотрим, либо весь файл -- тогда остаётся только скачать его заново (+100Мб). (Отдельные умельцы пользуются докачкой, обрезая скаченный файл с побитого места;)
Вариант 2: Разбиваем файл на тома и заливаем.
Это можно сделать ВинРаром или или любым другим способом, доступным юзерам (например, TC). В результате получаем куски (скажем, 10 по 10Мб), проверку целостности при сборке и возможность закачки только нужного куска, если он побился (+10Мб).
Вариант 3: Пакуем ВинРаром с разбиением на тома и добавляем том для восстановления.
Получается 11 файлов по 10Мб, из которых можно использовать любые 10. При нормальной связи качаются первые 10 томов (100Мб), в случае сбоя докачивается 11-й (восстановительный) том (+10Мб). Неуверенные в себе (в своём канале) качают сразу всё (110Мб) и при необходимости восстанавливают битый том.
3а: Дополнительно можно слегка добавить информации для восстановления в каждый том (0.1-1%), если при передаче предполагаются множественные недиагностируемые сбои. Получится 101Мб +10.1Мб резервный том.
3б: Или (чтобы совсем бессмертный архив создать:) можно разбить файл на 100 томов по 1Мб и добавить 10 томов для восстановления. Те же 100Мб + 10Мб, но в более гибком и надёжном виде.
Вариант 4: Пакуем ВинРаром (с разбиением на тома или без) и добавляем информацию для восстановления (скажем, 10%). Все юзеры качают все 110Мб, если скачалось криво -- восстанавливают (кто умеет).
Т.о. если сбев нет, то варианты 1, 2 и 3 позволяют скачать только нужные 100Мб, вариант 4 -- все 110Мб.
Если незначительные сбои есть, то в варианте 1 придётся качать заново (100Мб), в вариантах 2 и 3 нужно скачать дополнительный том (10Мб), а в варианте 4 оно и так скачано.
Если есть множественные сбои в разных местах, то в варианте 1 всё то же, в вариантах 2 и 3 придётся скачать все попортившиеся тома, а в варианте 4 перед этим можно попробовать использовать информацию для восстановления. В вариантах 3а и 3б скорее всего удастся восстановить информацию, ничего не скачивая, либо скачав дополнительны том (тома) для восстановления (в 3б это 1...10Мб в зависимости от объёма повреждений). После этого в любом случае стоит перейти на другой вариант файлообмена: даже при низком качестве каналов современные технологии позволяют полностью автоматизировать проверку и повторную пересылку данных при передаче. Все же в Глобальной сети -- удалённость от Петербурга (или там от Сан-Хосе) не играет значительной роли при выборе технологии.
Добавлено:
Собственно, вопрос возник из того, что наиболее предпочтительными для большинства случаев кажутся варианты 1-3, а большинство выкладывателей почему-то использует вариант 4. Особенно это непонятно в случае веб-обменников -- там-то чему портиться?
А все потому, что по умолчанию эта опция выключена, так же, как и в других архиваторах, где есть такая возможность, а в других ее просто нет. Я вот как-то заикнулся в топике по 7-zip о том, что пора уже разрабатывать возможность добавления информации восстановления, так на меня там набросились, что никому она не нужна и т.д. и т.п.