什么可能导致我的数据包的字节顺序变得部分扰乱?

时间:2013-04-28 13:50:08

标签: c++ sockets tcp corruption endianness

我在Linux Centos 4计算机和运行Interix与Gentoo的Windows XP计算机之间通过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代码中的错误吗?我正在运行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;
    }
  }
}

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

2 个答案:

答案 0 :(得分:0)

我会说你有'buf'的并发错误,或者可能是重复的free()free()之后的重复使用。

答案 1 :(得分:0)

神秘解决了!问题是off_t在Windows XP机器上是32位宽,在Centos机器上是64位宽。当数据包被发送时,其包含一些off_t对象的内存布局从主机放入网络字节顺序(小端到大端),然后在Windows机器上获取数据包时,它从网络返回到主办。因为内存布局不同,我得到了上面的扰乱。

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

然而,我遇到另一个问题,编译器没有在两台机器上以相同的方式打包结构,在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 XP上,这不是或不能兑现。我通过添加_padding解决了这个问题,迫使下一个8字节成员在Centos上对齐8字节,因此与Windows XP一致。