• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            MINA服務端與C++客戶端通訊(1)

            Posted on 2011-07-05 15:27 chugf 閱讀(4002) 評論(2)  編輯 收藏 引用

            最近學習了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);  
            }

            Feedback

            # re: MINA服務端與C++客戶端通訊(1)  回復  更多評論   

            2011-07-07 22:14 by 放屁阿狗
            1.大小數問題這是個跨平臺、網絡編程基礎概念,*nix一般都是大數優先
            2.你說的這個我都沒聽明白,mbcs可以進行任何編碼iconv,傳輸字符串編碼很多方式,utf8比較流行,也可以進行壓縮,你可以參考一些通信軟件框架的消息編碼代碼,定義一個合適的協議格式封裝你所要傳遞的消息,比如rpc的xdr,ice通信協議
            3.c/c++這種允許直接內存地址引用的語言,只有我在剛學會編程的開始會直接&obj的地址作為數據的首地址進行異構網絡的通信,采用#pragma這種方式來實現對其這是個很要命且很呆瓜的辦法,導致了諸多的問題,必須封裝成stream wrapper的方式來serialize數據,比如java的writeUint32,writeString等等
            4.不知在說啥
            5.這個問題很好解決,c端發送完畢調用shutdown(1)實現半關閉,java那里就知道對點退出了,很多軟件都是這么做的,比如 hp-openview的sdk
            6.不知在說啥,網絡通信其實是個比較簡單的過程 ,熟悉posix標準的socket api就可以了,不存在語言差異問題

            # re: MINA服務端與C++客戶端通訊(1)  回復  更多評論   

            2011-07-08 09:26 by chugf
            @放屁阿狗
            非常感謝

            posts - 5, comments - 22, trackbacks - 0, articles - 0

            Copyright © chugf

            亚洲中文字幕无码久久精品1| 国产成人精品久久亚洲高清不卡| 精品人妻久久久久久888| 性做久久久久久久久浪潮| 69国产成人综合久久精品| 久久综合九色综合97_久久久| 国产视频久久| 伊人久久大香线蕉综合影院首页| 久久婷婷国产综合精品| 99热成人精品免费久久| 久久婷婷五月综合成人D啪| 日本精品久久久久中文字幕| 久久婷婷五月综合色99啪ak| 99热热久久这里只有精品68| 综合久久一区二区三区| 国产午夜久久影院| 亚洲狠狠婷婷综合久久蜜芽| 久久99精品国产麻豆蜜芽| 久久国产精品一区| 91精品国产高清久久久久久io| 欧美日韩成人精品久久久免费看| 精品人妻久久久久久888| 亚洲欧美另类日本久久国产真实乱对白| 国内精品伊人久久久久av一坑 | 久久中文精品无码中文字幕| 国产精品一久久香蕉国产线看观看 | 久久精品视频免费| 日日狠狠久久偷偷色综合免费| 久久精品国产2020| 亚洲伊人久久成综合人影院 | 久久精品国产精品亚洲精品| 久久精品视频91| 国产 亚洲 欧美 另类 久久| 久久91精品国产91久久麻豆| 欧洲成人午夜精品无码区久久| 狠狠色婷婷久久一区二区| 久久久精品人妻一区二区三区蜜桃| 久久久久一级精品亚洲国产成人综合AV区| 久久久精品免费国产四虎| 久久久久四虎国产精品| 国产成人无码精品久久久久免费|