所有的 CRC 生成器位都相同吗?

问题描述

在 CRC 中,如果发送方必须发送数据,它将用 g(x) 划分数据位,这将给出一些剩余位。这些剩余位附加到数据位。现在,当这个码字被发送到接收器时,接收器将用相同的 g(x) 划分码字,给出一些余数。如果余数为零,则表示数据正确。

现在,如果所有系统都可以相互通信,是否意味着世界上的每个系统都具有相同的 g(x)。因为发送方和接收方必须有共同的 g(x)。

(请仅在有正确知识和一些有效证据的情况下回答)

解决方法

这取决于协议。 CRC 本身可以用于不同的多项式,使用它的协议定义了要使用的 g(x) 多项式。

https://en.wikipedia.org/wiki/Cyclic_redundancy_check#Standards_and_common_use 上有一个示例列表

这不是问题,因为系统显然无法在发送端和接收端使用不同的协议进行通信。潜在地,协议也可以使用可变多项式,在通信开始时以某种方式决定,但我不明白为什么这会有用

,

这是一个很大的问题。此外,除了 g(x) 之外,还有其他几种变体。

如果有人告诉您计算 CRC,您有很多问题要问。你需要问:g(x) 是什么? CRC 的初始值是多少?它是否与最后一个常数异或?比特以什么顺序送入 CRC,最不重要的还是最重要的? CRC 位以什么顺序放入消息中? CRC bytes 以什么顺序放入消息中?

这是一个 catalog of CRCs,(今天)有 107 个条目。它并不是所有使用的 CRC。 CRC 的长度有很多(g(x) 的次数),多项式有很多(g(x)),其中的位序、初始值和最终异或也有很多选择。

告诉您计算 CRC 的人可能甚至不知道! “不是只有一个吗?”他们可能会天真地问(就像你一样)。然后,您必须为您正在使用的协议找到 CRC 的定义,并能够解释它,或者为您的消息找到正确的 CRC 计算示例,并尝试推导出参数。

顺便说一下,在计算附加了 CRC 的消息的 CRC 时,并非所有 CRC 都会给出零。根据初始值和最终异或,您将获得所有正确消息的常量,但该常量不一定为零。即便如此,只有当您以正确的顺序计算来自 CRC 的位时,您才会得到一个常数。实际上,忽略该属性并仅计算接收到的消息的 CRC,然后简单地将其与随消息接收到的 CRC 进行比较实际上更容易、更快捷。

相关问答

错误1:Request method ‘DELETE‘ not supported 错误还原:...
错误1:启动docker镜像时报错:Error response from daemon:...
错误1:private field ‘xxx‘ is never assigned 按Alt...
报错如下,通过源不能下载,最后警告pip需升级版本 Requirem...