什么可能导致我的数据包的字节顺序被部分加扰？答案

【问题标题】：What could cause my packet's byte order to become partially scrambled?什么可能导致我的数据包的字节顺序被部分加扰？
【发布时间】：2013-04-28 13:50:07
【问题描述】：

我在 Linux Centos 4 机器和运行带有 Gentoo 的 Interix 的 Windows XP 机器之间通过 TCP 套接字发送数据包。当 Interix 接收到数据包时，大约 10% 的字符始终以与数据包开头完全相同的偏移量进行加扰。在发送 Linux 端，数据包具有以下正确内容：

但在 Interix 上，数据包内容有些混乱（但大部分是正确的）：

我已经指出了与上面^ 字符的区别。 y 周围可能还有更多字符，因为重复的 / 会隐藏在该部分中移动的其他字符。

此代码在多个平台对之间运行良好：

Linux 和 Linux
Linux 和 BSD
Linux 和 Cygwin

这可能是 Interix 和 Gentoo 代码中的错误吗？我在 Windows XP、Interix v3.5 上运行。我注意到所有正确的字符都出现了，但是它们的顺序一直被打乱，部分被颠倒了，其他的被剪切并重新插入到不同的地方。数据包正在接收端读取，TCP 套接字文件描述符上带有::read()。这里有很多代码，所以我不确定哪些部分最相关，但如果提出特定请求，我会尝试添加更多代码。

const int fd; // Passed in by caller.
char *buf;    // Passed in by caller.

size_t want = count; // This value is 625 for the packet in question.
// As ::read() is called, got is adjusted, until the whole packet is read.
size_t got = 0;

while (got < want) {
  // We call ::select() to ensure bytes are available before calling ::read().
  ssize_t result = ::read(fd, buf, want - got);

  if (result < 0) {
    // Handle error (not getting called, so omitted).
  } else {
    if (result != 0) {
      // We are coming in here in one try and got is set to 625, the amount we want...
      // Not an error, increment the byte counter 'got' & the read pointer,
      // buf.
      got += result;
      buf += result;
    } else { // EOF because zero result from read.
      eof = true; // Connection reset by peer.
      break;
    }
  }
}

我可以进行哪些实验来帮助确定错误的来源？

【问题讨论】：

看起来没问题如果你没有溢出buf。（顺便说一句，编辑 cmets 不会重新发送通知。）
您可以使用数据包嗅探器来确定问题出在发送端还是接收端。
@Mat Buf 的长度约为 1,500 字节，因此此处读取的 625 远低于 buf 的大小。
@brianbeuning 您建议在 Windows XP 上运行什么数据包嗅探器？
@WilliamKF 我们对wireshark有很好的体验wireshark.org

标签： c++ sockets tcp corruption endianness

【解决方案1】：

我会说你在“buf”上有一个并发错误，或者可能是重复的 free() 或在 free() 之后重复使用。

【讨论】：

【解决方案2】：

谜团解开了！问题是off_t 在 Windows XP 机器上是 32 位宽，而在 Centos 机器上是 64 位宽。发送数据包时，包含一些off_t 对象的内存布局从主机放入网络字节顺序（小端到大端），然后在 Windows 机器上，当它收到数据包时，它从网络返回到主机。因为内存布局不同，我得到了上面看到的加扰。

我通过在 64 位宽的任何地方使用我自己的 soff_t 解决了这个问题。

但是，然后我遇到了另一个问题，编译器在两台机器上没有以相同的方式打包结构，在 Windows 上它插入了 4 个字节以使 long long 8 字节对齐，而在 Centos 上它没有这样做：

typedef struct Option
{
  char[56]    _otherStuff;
  int         _cpuFreq;   
  int         _bufSize;
  soff_t      _fileSize;    // Original bug fixed by forcing these 8 bytes wide.
  soff_t      _seekTo;      // Original bug fixed by forcing these 8 bytes wide.
  int         _optionBits;
  int         _padding;     // To fix next bug, I added this 4 bytes
  long long   _mtime;
  long long   _mode;
} __attribute__ ((aligned(1), packed)) Option;

我曾使用__attribute__ ((aligned(1), packed)) 来强制包装保持一致和密集，但在 Windows XP 上，这没有或无法兑现。我通过添加_padding 来解决这个问题，以强制下一个 8 字节成员在 Centos 上对齐 8 字节，因此与 Windows XP 一致。

【讨论】：