|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 31 Oct 2002 11:48:06
To : Ramazan Ja-Far
Subject : Re: ~Hадежный FTP~
--------------------------------------------------------------------------------
>>> Ramazan Ja-Far wrote:
VN>>>>в поле CRC пакета инвертированно - как делается в V.42) CRC-16 или CRC-32
VN>>>> - слишком сложно.
RJF>>> А доказательство этого факта имеется :-)?
VN>>Тут приводили расчеты.
RJF> Ты хочешь сказать, что нужно применять более сложную схему
RJF> контроля целостности?
Возможно.
RJF> При случайном нарушении данных тебе не помогут ухищрения
RJF> вроде CRC или кодов Хэмминга. Вероятность принять пакет
RJF> с нераспознанной ошибкой == 1/2^N, где N - количество бит
RJF> контрольной сигнатуры, будь то MD5, CRC или простая
RJF> контрольная сумма. Т.е. для 16-битной сигнатуры эта
RJF> вероятность == 1/65536, для 32-битной == 1/2^32
Дело в том, что ошибки часто не "случайные".
Для многих видов аппаратуры и каналов типичны, например, систематические
искажения только одного бита в октете.
CRC тем и хороши, что "размазывают" один бит на все, после чего действительно
оказывается такая картина, как ты говоришь. С простыми контрольными суммами -
вероятность неотслеживания таких ошибок катастрофически растет.
RJF> И всякие _правильности_ уложения в пакет, типа "с
RJF> начальным значением кольцевого счетчика из всех единиц"
RJF> в данном случае ничем не помогут. Такие вещи рассчитаны
RJF> на обнаружение/исправление специфических сбоев, типа
RJF> "все нули" или порча ограниченного количества бит.
Да. А если точнее - они устраняют окончательно описанные проблемы простых
контрольных сумм из свойств применяемых CRC.
RJF> Ты сказал, что контрольная сумма TCP считается убого.
RJF> Я тебе поясняю, что ты не прав.
Я знаю, как она считается.
RJF> P.S. Почитай RFC 1071, в особенности IEN 45,
RJF> прилагающийся к нему.
Прими этот совет себе. Тот же RFC1071. Одна только коммутативность этой суммы
чего стоит - взаимные перестановки пар октетов ею не опознаются совершенно...
/netch
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
