Пакетный CRC вычислительный подход

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

Я также написал класс, где я могу создавать пакеты для отправки. Этот класс имеет метод GenerateCRC (), который позволяет вызывающей стороне вычислять CRC для пакета, который они создали посредством вызовов других методов. Вызов GenerateCRC () предназначен для вызова только после правильной настройки заголовка пакета и данных. В результате этот метод перебирает пакет в цикле for и таким образом вычисляет CRC.

Теперь, когда я пишу код для чтения в пакетах, мне нужно проверить их с помощью вычисления CRC. Я пытаюсь максимально использовать предыдущий класс «builder», учитывая, что, поскольку я читаю в пакете, я хочу сохранить его в памяти, и лучший способ сделать это — использовать класс «builder». Тем не менее, я столкнулся с трудностями при вычислении CRC.

Есть два основных подхода, которые я рассматриваю, и мне трудно взвесить все за и против и принять решение о подходе. Вот мои два варианта:

  1. Вычислите CRC, как я прочитал в байтах. Данные, которые я читаю, помещаются в очередь, поэтому я выкидываю байты по одному. Я бы продолжал выполнять «общий» CRC и закончил бы вычисления, как только будет прочитан последний байт данных.

  2. Вычислить CRC только после того, как я прочитал полный пакет. В этом случае мне не нужно хранить промежуточный итог, но мне придется снова итерировать пакет. Я должен отметить, что это позволило бы мне повторно использовать мой ранее написанный код.

В настоящее время я склоняюсь к варианту 1 и перемещаю любую общую функциональность между «строителем» и «читателем» в отдельный заголовочный файл. Однако я хочу убедиться, что первый вариант на самом деле является лучшим с точки зрения производительности, поскольку он делает мой код немного более перемешанным.

Заранее спасибо за помощь.

0

Решение

Я бы выбрал дверь № 2. Это позволяет упростить проверку кода с использованием идентичного кода на обоих концах, а также позволяет использовать более быстрые алгоритмы CRC, которые обрабатывают четыре или восемь байтов за раз.

0

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector