最近學習了Apache MINA通訊，在使用過程中碰到了一些問題，記錄下一些心得。
在服務端和客戶端都使用MINA提供的庫時，通訊一切正常，當我把客戶端改為C++代碼時，發現客戶端發送給服務端的二進制流中的整形數據，位置被倒置了。
C++客戶端16進制 ：0x00000013
MINA服務端16進制：0x13000000
查詢了網上資料後才知道Java在所有平台上都默認是big-endian，而C++在不同的平台上有不同的字節序, X86上是little-endian, solaris上是big-endian。
注意問題：
1、字節序
C++在不同的平台上有不同的字節序, X86上是little-endian, solaris上是big-endian; 而java在所有平台上都默認是big-endian, 所以在傳輸諸如short,int,long數據時要在C++轉換成網絡序(big-endian)
2、字符編碼
C++上最普遍的是采用mbcs, 而java上是用unicode(並且和標准的unicode還有些區別,可以參考java文檔), 所以除非必須否則不要傳字符串, 可以傳文本文件代替, 一定要傳的話只能自己轉換了
3、 內存對齊, 在C/C++的網絡通信程序中經常采用讀寫結構體的方式方便地交換數據, 但是不注意的話結構體內很可能有空隙, 比如struct A{ int a; char c }; struct B{ char a; int b }; 這兩個結構體內都有空隙, 而如果不說明空隙的存在java程序是不會知道的, 就會導致雙方解析時出錯. 要消除空隙應該小心地安排結構體的成員, 不推薦使用#pragma pach(1), 因為沒有通用性
4、 位域
除非小心安排, 否則位域導致的結構體大小與平台相關, int a:4所占用的字節隨平台和編譯器變化(char a:4相對穩定占1字節)
5、 (可能平台相關)傳送與接收速度不同當C++向java傳送一個大一些的數據時, 可能C++一邊已經傳完退出了, 而java那邊還沒收完, 導致最後的一部分數據丟失. 所以項目中采用了簡單的確認機制, 任何一方接收完數據就回送1字節的確認, 以防止C++過早退出
6、(可能平台相關)java在同C++建立連接後以及在C++向java傳送完一段數據後, java若向C++傳送一段數據則第一次傳送的數據C++只能收到一個字節, 第一次過後恢復正常
C++整形轉換代碼如下：
void swap_4(unsigned long &x)
{
x = (x << 24) |
((x << 8) & 0x00ff0000u) |
((x >> 8) & 0x0000ff00u) |
(x >> 24);
}
int _tmain(int argc, _TCHAR* argv[])
{
unsigned long len = 19;
swap_4(len);
}
