|
|
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TДобавь еще такую же вероятность из IP (там также сумма считается), в который оборачивается TCP-пакет. Будет 1/2^32 и умнож на вероятность сбоя в канале передачи. В IP сумма только заголовка, без данных. Но выше уже сказали что в канальном уровне есть своя сумма. Я посмотрел, в ethernet вроде вариация CRC-32 - это снимает все вопросы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 20:43 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyЧто например в сетях с высоким уровнем коллизий (сотовые/вайфай) на больших файлах дает ощутимую вероятность повреждения данных."Но есть ньюанс" - транспортный уровень этих сетей обеспечивает собственное обнаружение ошибок, которое адекватно и уровню помех и уровню коллизий. P.S. Если кто забыл, то размер сектора CD - 2532 байта. Именно для того, чтобы оставалось место для кода коррекции ошибок. И уж если диск не читался, то, обычно, узнавали об этом из системной ошибки, а не по контрольным суммам, которые параноики могли записать вместе с данными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 20:52 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TВероятность двухбитовой ошибки = вероятность однобитовой в квадрате, трехбитовой - в кубе и т.д.Грубое заблуждение - для типичного канала/носителя характерны именно групповые ошибки. В радиоэфире это происходит потому, что длительность импульсных помех превышает период квантования, на компакт-дисках царапины далеки от точечных и т.д. и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 20:56 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Насколько я разбираюсь CD позволяет иметь процент ошибок и при этом нормально звучать/читать файлы. Таковы начальные условия. Материал такой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 20:57 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Точно такой же "материал" и Ethernet. Коррекцию ошибок он, конечно, не умеет, то контроль длины и CRC32 пакета - делает. Точно так же у модемов появился сначала MNP2 (символьный, мог эмулироваться программно), затем MNP4 (битовый поток на аппаратном уровне) и, в конечном итоге - стандарт в виде V.32 и более старших. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 21:02 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Попробуем обобщить. TCP и лежащие над ним протоколы с высокой вероятностью передадут файл верно тк имеют встроенные проверки. Однако возможны погрешности 1) из-за разного софта, роутеров, особенностей сетей итд 2) некоторая вероятность ошибки в TCP Т.о. проверять файл все равно надо. Собственно для этого при скачивании openSource часто пишут checksum. Согласны? Остается только одно недоразумение: почему авторы протоколов не добавили в них эту простейшую проверку. То есть почему FTP не проверяет checksum и md5 хэш файла. Логично сделать проверку на самом высоком уровне. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 22:07 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
DymytryТо есть почему FTP не проверяет checksum и md5 хэш файлаFTP появился на 20 лет раньше MD5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 22:37 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
DymytryОднако возможны погрешности 1) из-за разного софта, роутеров, особенностей сетей итд 2) некоторая вероятность ошибки в TCP Т.о. проверять файл все равно надо. Собственно для этого при скачивании openSource часто пишут checksum. Согласны?Нет. То, что меня в любой момент может сбить автомобиль - не повод всегда оставаться дома. Контрольные суммы, безусловно, выкладываются часто, но это далеко не общепринятая практика. Статистики, которая позволила бы учесть фактическое использование контрольных сумм - вообще не существует.Остается только одно недоразумение: почему авторы протоколов не добавили в них эту простейшую проверку.Зачем??? Если BitTorrent или ZFS интенсивно используют различные проверки, это ещё не повод втыкать сложные контрольные суммы в каждую дырку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 23:09 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Точно такой же "материал" и Ethernet. В отличие от Ethernet, CDDA использует технологию "перемежения" битов в группе блоков. Это позволяет "распылять" групповую ошибку на несколько блоков и передавать ее на декодер кодов коррекции ошибок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 00:46 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
DymytryОстается только одно недоразумение: почему авторы протоколов не добавили в них эту простейшую проверку. То есть почему FTP не проверяет checksum и md5 хэш файла. Логично сделать проверку на самом высоком уровне. Первые сетевые протоколы создавались в те времена когда производительность мерялась в несколько мегагерц и объемы передаваемого трафика - в килобайтах. А такие суровые хеш-функции как SHA-2-(512) были уже продуктом лабораторий криптографии. И появились уже в двухтысячных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 00:52 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovЕсли BitTorrent или ZFS интенсивно используют различные проверки, это ещё не повод втыкать сложные контрольные суммы в каждую дырку. В последнее время пошла мода портировать всё и вся от PC на мобилы. Но здравая инженерная мысль бъёт по рукам. Любое bluetooth устройство типа гарнитуры - это в первую очередь экономное устройство. В его спецификацию включены опции снижения энергопотребления. Для миниатюрных устройств даже существует класс криптографии (т.н. эллиптические кривые) специально созданные для снижения "прожорливости" вычислений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 01:00 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TDimitry SibiryakovЗабыл двоичный режим передачи включить?.. хз, передается многотомный rar-архив, 10-20 файлов, битый всегда последний файл (есть копия отправленного), причем валиться так что размер совпадает, а содержимое левое, но структура rar-a соблюдена. Мистика какая-то. Может винда как-то помогает. Иногда нормально доходит. Попробуйте отключить антивирус - однажды столкнулся, но название антивируса не знаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 02:45 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonВ отличие от Ethernet, CDDA использует технологию "перемежения" битов в группе блоковТолько потому, что у привода нет возможности перезапросить исходный блок. Но дело даже не в этом - эзернет считает CRC32, а CD определяет технологию коррекции ошибок исходя из надёжной передачи данных на следующий уровень. Таким образом, в сегодняшних условиях, мы имеем надёжный транспорт над любой доступной средой передачи. Времена, когда в распоряжении протокола мог оказаться канал без контроля ошибок передачи (V.22(bis)) - давно прошли. Вот там - да, ошибки сыпались "тока в путь". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 09:11 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
По протоколам: plain TCP - сразу нафиг. Вы же не планируете придумывать свой, ни с чем не совместимый и трудно-отлаживаемый бинарный протокол ? FTP - устарел, умер и мумифицировался. Этому старичку давно пора на покой - в мир вечно живых rsh, nntp и прочих мамонтов. Оно использует два соединения (из-за чего может плохо проходить через нат), передает открытым текстом не только тело файла, но и команды вместе с логинами/паролями, да ещё и вносит путаницу с двумя режимами работы, что тоже частенько становится причиной ошибок. HTTP - идеален, если не требуется сохраняться приватность данных. Протокол HTTP также не шифрован, шифрование прикручивается дополнительно средствами SSL. SSH - для бэкапов самое оно, особенно в варианте авторизации по ключам. Мой вам добрый совет - сделайте так, чтобы бэкап-сервер сам заходил на сервер БД за бэкапом, а не сам сервер БД лез по ссш на хранилище бэкапов и что-то туда заливал. Что касается проверок - все эти встроенные проверки в протоколы позволяют проверить только лишь корректность процесса передачи. Для бэкапов же может быть актуальна проверка целостности любой ранее сохраненной копии. Так что sha256sum * > Hashes.sha256 на каждом сервере, и копируйте его вместе с отсальными архивами. Вопросы: 1) каким способом передать файл наиболее надежно по критерию целостности файла SSH / HTTP 2) каким способом передать файл наиболее быстро Пофиг 3) нужно ли проверять md5/checksum своим кодом Для бэкапов - обязательно, используйте утилиту sha256sum (есть под все ОС) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 10:03 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Комменты в теме ЖГУТ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 13:41 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
x1ca4064Dima Tпропущено... хз, передается многотомный rar-архив, 10-20 файлов, битый всегда последний файл (есть копия отправленного), причем валиться так что размер совпадает, а содержимое левое, но структура rar-a соблюдена. Мистика какая-то. Может винда как-то помогает. Иногда нормально доходит. Попробуйте отключить антивирус - однажды столкнулся, но название антивируса не знаю. Отключал. Не помогает. У меня MS Essential, не замечал чтобы он гадил. Заменил FTP на SSH, т.е. вместо wget передавал pscp. Всё дошло. Битых файлов нет. Буду наблюдать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 07:02 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dymytry1) каким способом передать файл наиболее надежно по критерию целостности файла 2) каким способом передать файл наиболее быстро HTTP малоудачен и с точки зрения оверхеда, и с точки зрения надёжности. TCP слишком низкого уровня, придётся много делать самому. Практически стоит выбирать между FTP и SFTP. Dymytry3) нужно ли проверять md5/checksum своим кодом Ни один checksum не даёт абсолютной гарантии, поэтому своя проверка не помешает. Также она поможет от ошибок в используемом софте. Dimitry SibiryakovЗабыл двоичный режим передачи включить?.. Да многое может быть. Скажем, в некоторых случаях на ftp обрывается передача, а получатель тут же радостно забирает неготовый файл до того, как отправитель дошлёт остаток. Basil A. SidorovИ как часто кто-либо видел искажание текста хоть на этом сайте, хоть где-то ещё? Регулярно. По ZMODEM-у, например, с 32-битными контрольными суммами, у меня выпадало два-три десятка файлов в год (то есть пришёл файл, контрольные суммы совпадают, а попытка распаковать даёт ошибку архиватора). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 11:30 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerРегулярно. По ZMODEM-у, например, с 32-битными контрольными суммами, у меня выпадало два-три десятка файлов в год (то есть пришёл файл, контрольные суммы совпадают, а попытка распаковать даёт ошибку архиватора).И где сейчас найти zmodem? И даже если кто-то продолжает пользоваться dialup-ом, где гарантия, что файлы бились при передаче, а не при упаковке кривыми руками? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 14:23 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerHTTP малоудачен и с точки зрения оверхеда, и с точки зрения надёжностиМожно поподробнее с этого места? А то мне аж попкорн захотелось достать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 14:29 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovИ где сейчас найти zmodem? А зачем искать? Будете утверждать, что CRC32 в нём какой-то особый и кардинально отличается от других контрольных сумм в других местах? Basil A. Sidorovгде гарантия, что файлы бились при передаче, Эти файлы упаковывались не Вашими руками, а неплохо написанными роботами, и распространялись по снежинке. Когда один файл ко всем приехал нормально, а на одном из получателей оказался побитым, нетрудно догадаться, что он побился при передаче. Хотя, конечно, никто не помешает и дальше придумывать всякие левые версии, лишь бы хватило твёрдости лба не признавать правды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 14:34 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Тут как-то уж сильно ругают FTP. Давайте позащищаем что-ли. Двухсокетность. Неумение работать за Nat (если я верно понял). И открытость передачи паролей. А в целом? Оки доки. И набор команд пошире чем у http. Удалять по крайней мере можно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 14:35 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovsoftwarerHTTP малоудачен и с точки зрения оверхеда, и с точки зрения надёжностиМожно поподробнее с этого места? А то мне аж попкорн захотелось достать. Хорошее желание, лучше жевать, чем говорить. А за этим делом откройте RFC и прочитайте, что в случае http с ненулевой вероятностью вообще не удастся определить, передан ли файл до конца или оборван на середине. Пользователи всяких качалок типа ReGet-а хорошо помнят такие проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 14:40 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonДвухсокетность. Неумение работать за Nat (если я верно понял). Есть пассивный режим, прекрасно пропускается натом, но не файрволами с кучей запретов исходящих соединений по номерам портов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 14:47 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TmaytonДвухсокетность. Неумение работать за Nat (если я верно понял). Есть пассивный режим, прекрасно пропускается натом, но не файрволами с кучей запретов исходящих соединений по номерам портов. Напомню, что топикстартер ищет способ передать файл по сети. Контролируемой, я так понимаю; у него нет или во всяком случае не заявлено задачи работать с произвольными отправителями-получателями за всякими заборами и интернетами. Поэтому не думаю, что подобные ограничения должны существенно влиять на его выбор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 14:57 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerА зачем искать? Будете утверждать, что CRC32 в нём какой-то особый и кардинально отличается от других контрольных сумм в других местах?Я повторю свою позицию: "на сегодняшний день IP-сети работают поверх принципиально надёжного транспорта". Когда вы найдёте в этом утверждении контрольные суммы - можно обсудить надёжность CRC32.softwarerХотя, конечно, никто не помешает и дальше придумывать всякие левые версии, лишь бы хватило твёрдости лба не признавать правды.У меня есть представительная статистика. Система регионального уровня, где не было собственной системы контроля целостности, а данные передавались по HTTP в упакованном в виде (deflate). Ошибки распаковки давали бы вполне конкретную ошибку во вполне конкретном месте сервере приложений. Сетевые ошибки на сайте системы были обычным делом делом - read/write timeout, connection reset by peer и всё такое, а вот на сервере приложений ошибок распаковки не было. За все шесть лет, которые я работал. По этой причине исторические экскурсы не очень интересны: первое, что я сделал подключившись к местной BBS модемом V.22bis/None - скачал MNP-эмулятор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 15:01 |
|
||
|
|

start [/forum/topic.php?fid=16&startmsg=38755233&tid=1341200]: |
0ms |
get settings: |
5ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
149ms |
get topic data: |
7ms |
get forum data: |
1ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 213ms |
| total: | 434ms |

| 0 / 0 |
