[jcxz 184]

Про TCP я читал очень давно, как там дополнительно контролируется содержимое внутри уже проверенного внешним CRC32 пакета, но CRC32 вполне себе очень доверятельная вещь !

Ещё раз внимательно читаем по слогам: в TCP-кадрах нет CRC32-контроля.

Вот расчёт контрольной суммы для TCP-кадра из рабочего TCP-стека:

static s32 CalcCsum(void const *start, int cnt, s32 sum)
{
 u16 const *p = (u16 const *)start;
 while ((cnt -= 2) >= 0) sum += *p++;  //sum words
 if (!(cnt + 1)) sum += *(u8 *)p;   //add left-over byte, if any
 while ((u32)(sum = (sum & 0xFFFF) + ((u32)sum >> 16)) >> 16); //fold 32-bit sum to 16 bits
 return ~sum;
}

Покажите мне - где здесь CRC32????

[kolobok0 0]

...где здесь CRC32????

 

Вам шашечки или ехать?

От противного =>

Вы утверждаете, что контрольая сумма даёт сбои при конкретной реализации и посему TCP не надёжен в плане сетевой передачи?

 

Если нет - тогда не понятен изначальный посыл. Если да, то собственно это немного противоречит мировой практики, несколько тонн кода и

фиг знает сколько часов работы...

 

[Golikov 0]

На самом деле я что-то тоже в какой-то момент начал думать что в ТСР CRC32, но для себя эту проблему решил прочитав еще раз формат пакета, там обычная 16 битная сумма.

 

Такая контрольная сумма весьма не дурна, но не гениальна. Она не замечает перестановку слов, и двойную ошибку одного бита. Учитывая сетевой протокол, избыточное кодирование и прочее она годиться для ТСР (вот теперь сижу вспоминаю а есть ли там избыточное кодирование:)), и дает единицы ошибок в год, но CRC32 в разы надежнее...

 

Принимать из интернета битые файлы - это нормальная практика, не скажу чтобы так каждый день, но при передачи файлов по сети такое несколько раз случалось, так что проблема не мифическая.

 

Единственное я бы не стал встраивать контрольную сумму в FTP, все таки это вне протокола, то есть я бы принял файл, а потом проверил и выставил бы какой-то признак файлу, так было бы идеологически правильнее, чем передавать сигнал прием завершен или нет в зависимости от целостности, но это на усмотрение автора...

[Сергей Борщ 119]

Хорошо, в TCP простая сумма. Но этот TCP идет поверх Ethernet, в котором как раз таки CRC-32.

Википедия:

Самый популярный и рекомендуемый IEEE полином для CRC-32 используется в Ethernet,

[Golikov 0]

Вот оно откуда воспоминание о CRC32, ведь помнил что был какой-то гемор в железной его реализации%)))

 

Неужели тогда не хватает CRC32, ведь реально по сети есть шансы скачать битый файл...

[jcxz 184]

Вы утверждаете, что контрольая сумма даёт сбои при конкретной реализации и посему TCP не надёжен в плане сетевой передачи?

Пропускают ошибки любые методы контроля. Вопрос в вероятности. А по этому критерию CRC32 несравнимо лучше обычной суммы.

И если поддаться паранойе, то можно не ограничиваться 32 разрядами. Есть полиномы и на большие разрядности.

 

Хорошо, в TCP простая сумма. Но этот TCP идет поверх Ethernet, в котором как раз таки CRC-32.

А где ТС пишет, что клиент и сервер находятся в одной Ethernet-сети?

Он вроде про Интернет пишет. А значит - на пути следования пакета могут быть различные физические+канальные среды передачи.

Плюс - переход пакета из одного сегмента сети в другой, через кучу маршрутизаторов.

Не здесь-ли и возникают сбои, приводящие к ошибкам в принятых по FTP файлах?

 

А ещё - как я понимаю для Ethernet обязательно только формирование кадров с CRC, но не обязателен контроль этой CRC на приёмной стороне.

 

Такая контрольная сумма весьма не дурна, но не гениальна. Она не замечает перестановку слов, и двойную ошибку одного бита. Учитывая сетевой протокол, избыточное кодирование и прочее она годиться для ТСР (вот теперь сижу вспоминаю а есть ли там избыточное кодирование:)), и дает единицы ошибок в год, но CRC32 в разы надежнее...

Я бы сказал - не в разы, а на порядки. Учитывая кол-во разрядов в контрольной сумме TCP и в CRC32. Уж не говоря о том что даже CRC16 будет надёжнее обычной суммы.

Кодирование - это функция вроде канального или физического уровня протокола (в частности - Ethernet-уровня или какой там канальный/физический уровень в данном сегменте). А TCP - это более высокий уровень OSI.