Здравствуйте, fk0, Вы писали:

N>>Результат удручает — ни одна сумма такой ситуации не ловит. Статистически лучше всего, похоже, просто младший байт суммы всех байт потока, но тоже качество обнаружения отвратительное.
fk0> 16-битная сумма в 256-байтном пакете (и более коротких) гарантированно ловит такие ситуации. Вроде ж очевидно.

Ах, 16-битная при байтах... ну это уже приём за гранью допустимого. До сих пор контекстом были или IP пакеты (тогда и 16-битная не справится, надо 32), или SMBus (тогда шла речь про 8-битные). А если у тебя будут передачи длиннее 256 байт — что делать, до 32 расширять? Боюсь, обидятся на оверхед.

fk0>>> Кстати ещё пример неправильного применения CRC -- контрольный код записи в FLASH-памяти. Догадываешься уже почему? Ровно та же проблема. Массовое FF-чивание отдельных блоков. Контрольная сумма подходящей разрядности (весьма небольшой) опять же справляется гарантировано и это очевидно математически.
N>>Нет. Модифицируй свою программу и проверь: точно так же не справляется.

fk0> Это ж очевидно, что если в последовательности единиц и нулей часть последовательности заменить на единицы или нули, то сумма станет соответственно такой же или большей, или такой же (когда 0 заменяется на 0) или меньшей. Для одного разряда это так (проверь). И для каждого N+1 тоже (доказано). Если в сумме нет переполнений -- поэтому разрядность должна быть больше, чем log2(sum(все единицы)).

И опять-таки у тебя должна быть очень большая контрольная сумма. Например, при записи порциями по 32 бита (чтобы было достаточно эффективно) в ней должно быть 40-48 бит. К тому же добавляется проблема проверки суммированием... боюсь, на сейчас выгоднее другие примеры применить. Например, RC при тех же недостатках с необходимостью последовательной обработки умеет корректировать данные, что явно важнее.

В общем, твой подход показателен как крайний вариант, но слабоприменим на практике — его можно сравнить с шифрованием с помощью шифроблокнота: надёжность абсолютная, но сопроводительного геморроя слишком много.