是什么导致我的数据包的字节顺序被部分置乱？

Question

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

-----BEGIN PUBLIC KEY----- 
MIIBojCCARcGByqGSM4+AgEwggEKAoGBAP//////////yQ/aoiFowjTExmKLgNwc
                                        ^   ^^^^^^^^^^^^^   
0SkCTgiKZ8x0Agu+pjsTmyJRSgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHC
^^^^^^^^
ReSFtXZiXn7G9ExC6aY37WsL/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZT 
gf//////////AgECAoGAf//////////kh+1RELRhGmJjMUXAbg5olIEnBEUz5joB 
Bd9THYnNkSilBDzHGgJu98qM2eadIY2YFYU2+S+KG6fwmra2qOEi8kLauzEvP2N6 
JiF00xv2tYX/rlt6A1v29xw1/a1Ez9LXT5IIviWP8ySUMyj2cynA//////////8D 
gYQAAoGAKcjWmS+h/a6xY6HfNeVBk+vU4ZQoi4ROBT8NXdiFQUeLwT/WpE/8oAxn 
KCOssVcoF54bF8JlEL0McWjQUzMrqoQedizALRRdH7kTUM/yqZZdxLgRFmiFDUXT 
XxsFFB5hlLpMqy9lqpNMN8+e5m9ISgu8zHMlTBQXsnwds0VkbeU=
-----END PUBLIC KEY-----

但是在Interix上，数据包内容被稍微加扰(但大多数是正确的)：

-----BEGIN PUBLIC KEY-----
MIIBojCCARcGByqGSM4+AgEwggEKAoGBAP//////y////iFowjTExQ/aomKLgNwc
                                        ^   ^^^^^^^^^^^^^ 
KigTCkS0Z8x0Agu+pjsTmyJRSgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHC
^^^^^^^^
ReSFtXZiXn7G9ExC6aY37WsL/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZT 
gf//////////AgECAoGAf//////////kh+1RELRhGmJjMUXAbg5olIEnBEUz5joB 
Bd9THYnNkSilBDzHGgJu98qM2eadIY2YFYU2+S+KG6fwmra2qOEi8kLauzEvP2N6 
JiF00xv2tYX/rlt6A1v29xw1/a1Ez9LXT5IIviWP8ySUMyj2cynA//////////8D 
gYQAAoGAKcjWmS+h/a6xY6HfNeVBk+vU4ZQoi4ROBT8NXdiFQUeLwT/WpE/8oAxn 
KCOssVcoF54bF8JlEL0McWjQUzMrqoQedizALRRdH7kTUM/yqZZdxLgRFmiFDUXT 
XxsFFB5hlLpMqy9lqpNMN8+e5m9ISgu8zHMlTBQXsnwds0VkbeU=
-----END PUBLIC KEY-----

我已经指出了与上述^字符的不同之处。考虑到重复的y将隐藏在该部分中移动的其他字符，那么在该部分周围可能会有更多的字符。

这段代码在几个平台对之间运行得很好：

• Linux与Linux
• Linux和BSD
• Linux和Cygwin

这可能是Interix和Gentoo代码中的一个bug吗？我正在运行Windows，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;
    }
  }
}

我可以做什么实验来帮助找出错误的来源？

Answer 1

谜团解开了！问题是，在windows机器上，off_t是32位宽，在Centos机器上是64位宽。当数据包被发送时，将包含一些off_t对象的内存布局从主机放入网络字节顺序(小端到大端)，然后在windows机器上得到数据包，从网络返回到主机。由于内存布局不同，我在上面看到了扰码。

我通过使用我自己的soff_t ( 64位宽)来解决这个问题。

但是，我遇到了另一个问题，编译器在这两台机器上都没有以相同的方式打包一个结构，并且在windows上插入了4个字节使长的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上，这是不能或不能得到尊重的。我通过添加_padding来解决这个问题，强制下一个8字节的成员在Centos上对齐，从而符合Windows。

Answer 2

我想说，您在'buf‘上有一个并发错误，或者可能是一个重复的free()，或者是free()之后的重用。