January 15, 2007

Контрольная сумма и ширина канала - things that matter

Вводная:

Скачал я тут себе недавно Fedora Core 6. Хотел посмотреть чего там новенького. Надо сказать, что занятие это на моём домашнем 64кбитном канале не очень быстрое, так что я ждал момента окончания закачки как ничего другого. И вот... Случилось! Докачалось! Ура. Заливаю образ на ДВД и давай ставить.

У RedHat'ов (а может ещё у кого есть, но запомнилось только у них) есть замечательная опция: при установке можно проверить диск на ошибки. Никогда, если честно, этим не занимался, видимо потому, что ставил FC5 с 5 CD дисков и уж больно не хотелось их туда-сюда вставлять-вынимать. А тут целый один DVD - можно и проверить, хуже не будет. Проверяем-проверяем... 10%... 25%... 68%... БАЦ! Corrupted. Я было погрешил на диск, он у меня был немного потёртый. А потом думаю: "а ну-ка вместо того чтобы диски резать один за другим проверю контрольную сумму ISO". Проверил. Взгрустнулось. Сумма не совпала.

Сразу вспомнился эпизод, как в один прекрасный момент посреди процесса закачки выключился свет. Видимо в этот самый миг какой-то байтик был принят неправильно и все 3.6Гб оказались бесполезными.

А теперь идея, которая пришла ко мне после этого инцидента.

Контрольная сумма всегда одна на файл. (По крайней мере иного расклада я не встречал ещё ни разу.) Существует 2 возможных выхода. Первый: разбить файл на несколько частей и посчитать контрольную сумму для каждой, чтобы в процессе скачивания видеть что такая-то часть скачалась с ошибкой, и не терять весь файл целиком. Зато в этом случае не совсем понятно как быть с возможностью докачки, точнее таким её использованием, как скачивание в несколько потоков. Вариант второй предполагает возможность в любой момент времени попросить у сервера посчитать сумму для любой части файла, сделать то же на клиентской стороне и сравнить полученные результаты. В случае ошибки переспросить кусочек файла. Большими минусами в этом случае можно назвать увеличение вычислительной нагрузки на сервер (особенно если всякие неблагонадёжные типы будут постоянно спрашивать пересчитать сумму для огромных файлов, это будет настоящий DoS) и необходимость изменения существующих протоколов. Но для таких как я, людей с "ограниченными возможностями" в плане ширины канала это будет что ни на есть решение.

Ах да. Где-то прочитал что всякие P2P сети (а ля eDonkey и BitTorrent) имеют достаточно мощные средства по обеспечению правильности файла при скачивании.


# posted by Maxim Moiseev : 10:19
Comments:
Предпочтительным и "официальным" способом загрузки Fedora Core как-раз и является torrent
воспользовавшись которым вы бы и скачали наверняка быстрее и с проблемой "контрольная сумма одна на файл" справились бы :)
ссылка на торрент - на официальной странице http://www.redhat.com/fedora/

# posted by Anonymous Anonymous : 15/1/07 12:18
 


Из нескольких скачаных мной дистрибутивов, *ни один* не прошел проверки на сумму. Поэтому, таки да, стоит предпочесть torrent.

# posted by Anonymous Anonymous : 15/1/07 12:51
 


2Андрей: Да я видел, что рекомендуется торентом пользоваться, но старый способ он как-то привычнее. Да и в тот момент, когда я поставил на закачку федору мне было совсем некогда разбираться, что там надо настроить в моём АДСЛ модеме, чтобы заработал форвард портов, так что я немного поискал нужный образ на зеркалах и решил скачать именно его.

# posted by Blogger Maxim Moiseev : 15/1/07 13:53
 


2Аноним: А я вот первый раз наткнулся на кривость скачивания. Незадолго до ФЕдоры скачал openSUSE почти такого же размера и ничего. А ещё всяких ubuntu/kubuntu качал. И всё нормально было, а тут... Одно расстройство. Обязательно теперь буду торрентить.

# posted by Blogger Maxim Moiseev : 15/1/07 13:57
 


Вообще-то в unix-мире давно существует такая штука, как rsync (http://rsync.samba.org/, http://en.wikipedia.org/wiki/Rsync).
Инструмент для синхронизации бинарных файлов. Используется часто и как download'ер (или для поддержки mirror'ов). Качает только изменившиеся (или испорченные) части файлов. Работает как по своему протоколу, так и через ssh/rsh.
У fedora есть масса rsync-mirror'ов: http://fedora.redhat.com/download/mirrors.html
Каких-то специальных пробросов портов не нужно, нужен только клиент (есть и под windows).

# posted by Anonymous Anonymous : 15/1/07 16:55
 


2vg: Собственно, я и не сомневался, что что-то подобное уже есть. Так всегда бывает с хорошими идеями, их кто-то уже придумал :-) Более того, я почему-то всё чаще убеждаюсь что в мире *nix уже придумали всё :-) Дальнейшее существование бессмысленно. Спасибо за наводку. Теперь вот чувствую себя немного идиотом, потому как битый ИСОшник федоры я удалил :-)

# posted by Blogger Maxim Moiseev : 15/1/07 17:09
 


В догонку, если битый ISO еще не удалили, можно и его исправить rsync'ом. Скачать rsync-клиент (если по винду, то например cwRsync отсюда http://itefix.no/cwrsync/, под unix'ами обычно в дистрибутиве/портах есть).
Дальше нарипмер так (в директории с испорченным ISO):
(путь к rsync)\rsync -v rsync://mirror.linux.duke.edu/fedora-linux-core/6/i386/iso/README-BURNING-ISOS-en_US.txt .

P.S. Тулза commandline, надеюсь это не будет проблемой.

# posted by Anonymous Anonymous : 15/1/07 17:12
 


Ой, комманда конечно же
(путь к rsync)\rsync -v rsync://mirror.linux.duke.edu/fedora-linux-core/6/i386/iso/FC-6-i386-DVD.iso .
это я просто на txt тестил :-)

P.S. Жаль, что удалили :-(

# posted by Anonymous Anonymous : 15/1/07 17:15
 


Кстати, насчет "контрольная сумма всегда одна на файл" тоже не верно, бывает и поблочная md5. Пример: ftp://ftp.asplinux.ru/pub/i386/10/
файлы *md5sums.
Хотя согласен, это действительно бывает редко: тот же ASP перестал так делать для последних дистрибутивов.

# posted by Anonymous Anonymous : 15/1/07 17:21
 


Мда. Сейчас всё заточено под жирнющие каналы. И никто не заботится о частичных суммах :-)

# posted by Blogger Maxim Moiseev : 15/1/07 17:24
 


Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?