Какова цель CRC для полезной нагрузки, когда полезная нагрузка разбита на несколько пакетов?

Question

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

Так что может случиться:

Pkt 0: S | Pkt Hdr Seq = 0 | Начало полезной нагрузки | Pkt CRC | E

Pkt 1: S | Pkt Hdr Seq = 1 | Полезная нагрузка продолжается | Pkt CRC | E

Pkt 2: S | Pkt Hdr Seq = 2 | Конец полезной нагрузки | Полезная нагрузка CRC | Pkt CRC | E

S - начало упаковки; E - конец пакета; Seq - Последовательность Номер пакета

Почему у протокола есть свой CRC на передаваемой ими полезной нагрузке, когда CRC-пакет уже установлен? Полезная нагрузка уже защищена. Разработчики протокола знали о параметре уровня пакета CRC.

Единственные причины я могу думать о том, являются:

1. слой прохождения полезной нагрузки до нижнего уровня протокола не обязательно знать, если нижний слой уже имеет CRC
2. Слой прохождения полезной нагрузки не знает, имеет ли конфигурация нижнего уровня протокола CRC.
3. Слой, передающий полезную нагрузку, использует усовершенствованную технику проверки ошибок или коррекции на полезной нагрузке.
4. Слой, передающий полезную нагрузку, защищает полезную нагрузку от потенциально плохих/сломанных нижних слоев/оборудования.

1, 2, & 3 не применяются в этой ситуации. Итак, единственная «хорошая» причина, которую я имею.

Answer 1

1, 4, и, возможно, 3.

В протоколе стеки часто бывает важно, что слои должны быть независимы друг от друга. У слоев обычно есть свои основные услуги, которые они предоставляют, и они могут предоставить дополнительные функции. Например: в слое ISO/OSI 7 вы можете написать приложение, которое обменивается данными через сокеты. Если вы добавите контрольную сумму на свой собственный уровень протокола уровня приложения, вам не придется полагаться на проверку протокола TCP или UDP ниже.

Возможно, это правда, что в текущей ситуации вы знаете, что протокол работает по определенному существующему протоколу BUS. Но, возможно, в будущем (скажем через 5 лет), что BUS будет изменен на что-то еще. Какой-то I2C, ODB, кто знает. Теперь, как правило, более новые протоколы, вероятно, обеспечивают лучшую проверку ошибок, но вам не нужно полагаться на неизвестное.

Вы можете наблюдать это в слоях ISO/OSI, у большего количества слоев есть различные проверки ошибок. Кажется, что это избыточно, но технологии слоев меняются.

Answer 2

Пакет может перемещаться по нескольким (нижним) перелетам при переходе от источника к месту назначения. Проверка контрольной суммы в пункте назначения гарантирует, что мы не выполнили никаких битовых ошибок на любом промежуточном переходе. Таким образом, даже если у нас есть пакет, фрагментированный на несколько меньших пакетов, он является источником, который выполняет фрагментацию, и это место назначения, которое собирает фрагментацию. Вот почему, с точки зрения контрольной суммы, он делает senese обрабатывать каждый фрагмент как отдельный пакет. Фактически, именно так и происходит фрагментация и контрольная сумма в IP-сетях. Если отправляемый пакет больше MTU, отправитель разбивает пакет на несколько меньших пакетов и вычисляет контрольную сумму для каждого из них по отдельности. Как только получатель получает эти фрагменты, он проверяет контрольную сумму для каждого из них перед выполнением повторной сборки. Итак, я также поеду с опцией 4!