使用ACE_CDR类进行网络编解码(5-3)

这次我们来处理边界调整的问题。留意下面的代码片段：

view plain copy to clipboard print ?

1. char  buf[6] = {0};  
2. ACE_OutputCDR ocdr(buf, 6, ACE_CDR::BYTE_ORDER_BIG_ENDIAN);  
3. ACE_CDR::ULong temp1 = 88;  
4. ACE_CDR::UShort temp2 = 66;  
5. ocdr << temp1;  
6. ocdr << temp2;  
7. int  result = peer.sendn(buf, 6);  

char buf[6] = {0};
ACE_OutputCDR ocdr(buf, 6, ACE_CDR::BYTE_ORDER_BIG_ENDIAN);
ACE_CDR::ULong temp1 = 88;
ACE_CDR::UShort temp2 = 66;
ocdr << temp1;
ocdr << temp2;
int result = peer.sendn(buf, 6);

 

上面的代码将两个数据压到buf中。这里面有一个隐藏的BUG。第二行用一个buf来构造ACE_OutputCDR对象 时，ACE_OutputCDRr构造函数会进行一个复杂的操作。它先用这个buf构造一个ACE_Message_Block，然后对这个 ACE_Message_Block调用ACE_CDR::mb_align方法，进行一次边界调整。

如果刚好buf的起点不在4字节的边界上（不能整除4），则会将ACE_Message_Block的起点后移到4字节对齐的边界上。这会造成两个 可能的后果。如果调整的确发生了（假如往后调整了2个字节），那么上述代码最后一行发送的内容，实际上就是错误的，因为错开了2个字节。更为严重的错误是 我们的buf刚好是6个字节，我们也写入了6个字节，但是如果ACE_OutputCDR替我们做了一次调整的话，在写入的时候就会越界，破坏堆栈(覆写 buf数组后面的两个字节)。

解决的方式有两个。如果是像上述的代码一样，用CDR类来对原始的buffer进行处理，那么可以通过在config.h文件中定义下例的宏来屏蔽对齐行为。

view plain copy to clipboard print ?

1. #define ACE_CDR_IGNORE_ALIGNMENT   

#define ACE_CDR_IGNORE_ALIGNMENT

注意要重新编译ACE。

另外一种方法是，如果是ACE在项目中用得比较普及的话，建议不要直接用原始buffer，改用ACE_Message_Block。实际上对齐时 是调整了内部的ACE_Message_Block的base指针。如果总是通过ACE_Message_Block的base方法来得到实际 buffer的起始，就不用担心会发生错位。这里唯一要注意的就是要为可能的调整留出空间，避免上面说的溢出。比如下面的代码：

1. ACE_Message_Block mb(1024 + ACE_CDR::MAX_ALIGNMENT);  

ACE_Message_Block mb(1024 + ACE_CDR::MAX_ALIGNMENT);

我们需要一个1024大小的buffer，但是在实际申请空间时加一个冗余值 ，对齐最大也不可能超过这个冗余，这样就避免了压入数据时引起越界。

ACE进行一次对齐的原因是为了加快内存操作。结合前面“紧缩”部分的描述，我们可以知道，在缺省情况下，ACE在编解码时不但将Buffer的起 始外进行对齐处理，里面的数据类型不论大小也是按4字节对齐的。有兴趣的可以看一下MAX_ALIGNMENT这个冗余量的值是8而不是4，我猜可能是为 了兼容64位机器