Доброе время суток. Недавно наткнулся на одну страницу, где описывали формат передачи какому-то устройству, пакеты данных по 4 байта. Общий вид: [CRC8|CMD|OP1|OP2] CRC8 - сумма CMD, OP1, OP2 CMD - команда OP1 - первый параметр OP2 - второй параметр CRC8 там используется для валидации сохранности переданной информации (если так можно сказать). Далее я так понимаю, устройство заново вычисляет CRC8, и сравнивает старое значение с новым. Если я все правильно понял, то возникает вопрос: Если при передачи три байта испортятся так, что их CRC8 будет равна старому значению, то устройство выполнит неправильную операцию? 1. Возможна ли такая ситуация? 2. Как её можно обойти? 3. Есть ли альтернатива по надежнее? (Только ненадо предлагать CRC16, CRC32, etc...) 4. В каких областях чаще всего применяется алгоритм CRC8? 5. В каких областях чаще всего применяется предложенная альтернатива (если такова имеется)?
1. Возможно, но мало вероятна. 2. Сделать надежный канал связи. Экранированный провод поставить убрать источники помехи. 3. Советую почитать умныии книги напритмер "Лидовский В.В., Теориинформации, 2003" 4. Это у статистов надо спрашивать эта цитатата из книжке что выше. От себя. Используется в сетевых платах. А также в различных устройствах. Хотя в таких устройствах применяют с такойже частотой и простые контрольные суммы.
1. Да 2. Никак 3. Только CRC16 и CRC32. 4. Если честно, первый раз слышу, чтобы где-то применялся CRC8 5. CRC16/CRC32 активно используется в архиваторах WinZIP, WinRAR, сетевых протоколах и вобще практически повсеместно - жалоб ни от кого не поступало Мораль следующая: Проблема коллизии всегда остается. При небольших размерах сообщения (десятки килобайт) подходит CRC16, при больших (мега/гигабайты) - CRC32. Вероятность того, что сообщение и CRC32 будут повреждены так, что CRC32 будет соответствовать поврежденному сообщению примерно равна 0,0000000002328. Для сравнения - вероятность погибнуть от удара молнии в течение дня всего лишь в два раза меньше.
Не вот то устройство именно CRC8 вычисляет. Pavia и drmist спасибо за разъяснения. Попробую найти вышеописанную книгу. И наверно придется использовать CRC16. Я ведь не спроста спрашивал: Мне нужно было убедиться в том, какой из алгоритмов более надежный (конечно тут и так ясно что в байте не разгуляешься, но все же уточнения мне нужны были).
