套接字编程：消息未通过检查。有人知道原因吗？答案

【问题标题】：Sockets programming: Message failing check. Does anyone know a fanthom of a reason?套接字编程：消息未通过检查。有人知道原因吗？
【发布时间】：2011-07-07 14:57:00
【问题描述】：

现在我有一个由客户端和服务器组成的通信基础设施。

客户端使用标准 TCP 套接字连接到服务器。

我的消息结构如下：

4 bytes -- Message size
n bytes -- Message
4 bytes -- CRC32 checksum

其中一个要求是消息必须通过连接另一端的 CRC32 检查才能有效，无论是客户端还是服务器都以相同的方式处理消息。

如果消息未通过 CRC32 校验，则断开连接并建立新连接。

我的问题是为什么我会随机出现 CRC32 失败？

没有明显的原因，即使客户端和服务器在同一台机器上使用环回地址 (127.0.0.1)。

我认为即使我为恶意第三方或其他什么情况编写了故障保护程序，我也永远不会在测试期间看到断开连接。

【问题讨论】：

我最好的猜测是您的校验和代码中存在错误。你能给我们展示一些最小的示例代码吗？
我假设在读/写中存在错误（例如，假设 recv 总是返回所需的确切数据长度，类似于 send）或代码检查中的错误/创建 CRC。发布一些代码将大大有助于澄清这一点并帮助我们帮助您。

标签： sockets data-transfer

【解决方案1】：

你没有显示任何代码，所以我只能猜测。

您正在从套接字读取字节而不检查读取的大小。 TCP 是一种面向流的协议，因此无法保证您必须执行的读取次数才能发送整个数据。唯一的保证是，在未指定数量的读取之后，使用未指定数量的段，您将按顺序获得所有八位位组
某些输入的校验和函数失败，因为它不正确

第一个可能是正在发生的事情。您正在读取一些数据，并且 recv / read 返回读取的字节数比您预期的要少。

顺便说一句，您确实意识到您正在尝试做的事情对吗？

以太网帧有一个 CRC-32 字段
IPv4 数据包具有 16b 标头校验和
TCP 段有一个 16-b 校验和，涵盖标头、数据和一些内容
您的数据也将包含 CRC-32

你意识到这是多余的，对吧？

【讨论】：

+1 用于冗余观察。我使用的协议包括某种标记消息结束或开始的帧字节。这使您可以确保消息的发件人没有发送损坏的消息（消息与 MessageSize 不匹配）。这可能有助于确认消息有效，而无需求助于 CRC 计算

【解决方案2】：

顺便说一句，在接收方检查校验和的正确方法是在整个消息上计算它和校验和，被联合视为更长的消息。结果应该为零。这样，您就可以在计算中包含校验和本身。错误的做法是计算不包括校验和的消息的校验和，然后与接收到的校验和进行比较。

【讨论】：

您能否详细说明它应该如何工作？因为我从来没有听说过，我很好奇:)
您描述的错误方式有什么特别的问题？在我看来，这两种方法都可以工作（其中“工作”==“如果数据损坏，则生成校验和不匹配错误”），但我可能遗漏了一些细节。
校验和被定义为消息的异或余数，因此在计算中包含它必须产生零。由于我给出的原因，这是一种优越的方法：它不假设校验和本身已正确传输。可以想象以兼容的方式损坏消息和校验和的损坏：这会捕获它们。