Является ли использование подразумеваемых данных в сообщении для вычисления CRC хорошей стратегией дизайна?

Мы отправляем сообщения UDP с одного устройства на другое. В сообщении есть отметка времени и передается в 16-битовом поле. Приемник отслеживает количество раз, когда поле «перекатывается», так что можно отслеживать промежутки времени, которые требуют более 16 бит. Разработчик протокола решил, что мы должны использовать всю 32-битную метку времени для вычисления CRC для сообщения. Это хорошая идея? Обратите внимание, что мы имеем период сообщения, который намного меньше периода «перевертывания».Является ли использование подразумеваемых данных в сообщении для вычисления CRC хорошей стратегией дизайна?

источник

2016-04-25 Gerry

Не хороший дизайн. Плохо сканируемый уровень передачи данных (целостность полезной нагрузки) с логикой приложения (переполнение таймера). - Что делать, если проверка CRC не удалась? Была ли повреждена полезная нагрузка (-> повторить/проигнорировать) или таймеры дрейфовали друг от друга? Невозможно сказать. - Почему бы явным образом не передать полную метку времени как часть полезной нагрузки? – JimmyB

Поскольку вы, по-видимому, контролируете сообщения, вы должны просто передать 32-битную метку времени в сообщении.

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

Если это 32-разрядный CRC, вы можете снова решить и оставить 16-бит «силы» в обнаружении ошибок, а не 32. Опять же, нужно было бы спросить, почему вы не просто отправьте остальные 16 бит временной метки и поставьте 16-битный CRC в то, что осталось.

Или, если вы можете изменить длину сообщения, просто добавьте отсутствующие 16 бит метки времени, оставив CRC и возможность обнаружения ошибок неповрежденной.

источник

2016-04-25 18:04:44

Это 24-битный CRC. Я думаю, что разработчик протокола думал, что система поймает дополнительный режим отказа, т. Е. Ошибку в вычислении перевертывания. Проблема, которую я вижу, заключается в том, что сообщения становятся парализованными в случае ошибки при перерасчете. Проверка отката с простым сравнением по величине не получается, когда UDP-пакеты выходят из строя, поэтому я считаю, что это недостаток в дизайне. Но я хочу услышать, что думают люди. – Gerry

Является ли использование подразумеваемых данных в сообщении для вычисления CRC хорошей стратегией дизайна?

ответ

Смежные вопросы