• <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>

            網絡服務器軟件開發/中間件開發,關注ACE/ICE/boost

            C++博客 首頁 新隨筆 聯系 聚合 管理
              152 Posts :: 3 Stories :: 172 Comments :: 0 Trackbacks

                一.問題的提出

                這里的編碼,具體是指如何高效地將基本類型序列化,以便在網絡上傳輸,不是指將整個數據包用utf8或base64等編碼,更不是應用層和業務相關的編碼。

                假若有定義如下:

                          #pragma pack(1)

                          typedef struct tagS_HDR

                          {

                                 uint8       nProtocol;//協議類型

                                 uint16     nLength;//消息長度,不包括本消息頭

                                 uint16     nType;//消息類型        

                                 uint8       nExt;//協議擴展標記,比如消息子類型

                          }S_HDR;

                          #pragma pack()

                          typedef struct tagS_FileTxHDR_Req

                          {

                                 S_HDR   hdr_;//消息頭

                                 uint32            nUID_;//接收方用戶唯一ID

                                 string             sFileName_;//要傳送的文件名

                                 uint32            nFileSize_;//文件大小

                                 uint8              nFileID_;//臨時分配的文件ID,最多支持同時傳256個文件

                          }S_FileTxHDR_Req;

                如果你是做服務器開發,對類似這樣的結構體應該非常熟悉,為了簡化問題,在繼續討論之前,我們做幾個假設:

                    (1)消息頭的長度是固定的,且設計足夠高效,不在編碼優化之列。

                    (2)整形里面只關注uint8,uint16.uint32.

                    (3)字符串關注兩類:以\0結尾的string和二進制流的bytes。

                    (4)其它類型暫不關注,不影響問題的討論,后續會慢慢完善。

                   (5)libprotobuf已經很強大,但也有限制,比如必須鏈接一個庫,如果是手機客戶端和服務器通訊,顯然是不能用的。

                場景如下:A(ID為123)要給B(ID為456)發送file.txt文件,文件內容為”Hello World!”,傳統的序列化方式為nUID占用4個字節,nFileSize也占用4個字節,而事實上456用2個字節表示足以,” Hello World!”的長度用一個字節表示足以。明顯是浪費嘛!有沒有什么辦法解決這個問題呢?當然有,答案是:站在巨人的肩上。

                  

                二。Base 128 Varints

                Google Protobuf里面提出了“Base 128 Varints”編碼,這是一種變字節長度的編碼,官方描述為:varints是用一個或多個字節序列化整形的一種方法。我理解要點有三個(1)操作是序列化(2)操作對象是整形(3)變長編碼。重點是最后一點,他是如何編碼的呢?

                   (1)除了最后一個字節,varint中的每個字節的最高位設為1,表示后面還有字節出現

                   (2)每個字節的低7位看成是一個組(group),這個組和他相鄰的下一個7位組共同存儲某個整形的“組合表示”,最低有效組在前面。

                上面的定義可能比較生硬,我沒看具體例子之前,也沒搞明白,我們來看http://code.google.com/intl/zh-CN/apis/protocolbuffers/docs/encoding.html#varints中的例子:

                    (1)一個字節。下面只有一個字節,所以最高位是0,表示十進制1

                        0000 0001

                    (2)兩個字節。

                        1010 1100 0000 0010

                    由于第一個字節后面還有一個字節,所以第一個字節的最高位設置為1,表示后面還有后繼字節,第二個字節的最高位為0。去掉每個字節的最高位,我們對兩個字節進行分組。第一個7位組:0101100,第二個7位組:0000010,組合起來就是:0101100 0000010,由于最低有效組在前面,所以兩個7位組進行調換,結果為:0000010  0101100,中間的空格是為了大家區分,去掉前面的0,也就是:100101100,十進制為1*2^8 + 1*2^5 + 1*2^3 + 1*2^2 = 256 + 32 + 8 + 4 = 300。

                   (3)三個字節。我們換種方式,給定某個整形,要求寫出他的varint表示,這里當然是落在需要3個字節表示的整形。16380可以嗎?不可以!因為16380 < 2^14,所以2個字節足以,我們就以27491為例,27491的二進制表示為:

                                 0110 1011 0110 0011

                    注意這里是高字節之前,低字節在后,和varint的編碼規則相反,首先按照7位一組劃分為:0000001 1010110  1100011然后反轉為:1100011 1010110  0000001,最后將末尾的7位組前面補0組成一個字節,兩個7位組都補1分別組成一個字節:

                                 11100011 11010110  00000001

                   (4)更多字節。聰明的你可能發現,varint編碼中4個字節最大表示的數為2^28,非常正確,同時說明了天下沒有免費的午餐,有得有失。Protobuf引入了fixed32解決這個問題的,如果某個字段經常大于2^28,應當優選fixed32,他是固定長度為32位的。

                 三.String和bytes

                 string和bytes的表示形式一致,都是“長度+值”,其中長度采用varint編碼,值為字符序列或者二進制碼流

                  

                 如有錯誤,請指正,下次會寫到結構體類型的編碼,對應于libprotobuf的Message概念。

             

               


            posted on 2009-09-11 04:12 true 閱讀(2741) 評論(5)  編輯 收藏 引用 所屬分類: 編碼知識通信技術

            Feedback

            # re: 協議設計之一 基本類型的編碼 2009-09-11 04:17 true
            一篇文章竟然寫了一晚,該休息會了:)  回復  更多評論
              

            # re: 協議設計之一 基本類型的編碼 2009-09-11 17:48 sd
            省了微不足道的空間
            卻在序列化上耗費時間
            得不償失  回復  更多評論
              

            # re: 協議設計之一 基本類型的編碼 2009-09-11 17:58 true
            @sd
            我也知道xmpp已經得到了廣泛的使用,這里主要是想,做一個自動描述協議,自動序列化的工具,既然要做到這樣,我選擇了基于libprotobuf的方案,第一次看到它的編碼時,著實讓人開闊思路:)  回復  更多評論
              

            # re: 協議設計之一 基本類型的編碼 2009-09-12 10:28 guest
            mfc系列化中的CString的長度字段采用了類似的變長方案:
            len < 255, 1Byte(byte)
            255<= len <65535, 3Byte( 0xff, ushort)
            len >= 65535, 7byte(0xff, 0xff, 0xff, uint)
            因為大部分的字符串長度小于255(1個字節就夠了), 使用3個字節都時候都很少了,需要使用7個字節的時候微乎其微。所以總體來說節省了空間,而且沒有復雜的解碼過程  回復  更多評論
              

            # re: 協議設計之一 基本類型的編碼 2009-09-25 15:55 那誰
            @sd
            贊同你的觀點.
              回復  更多評論
              

            五月丁香综合激情六月久久| 国产精品免费看久久久香蕉| 老男人久久青草av高清| 日本五月天婷久久网站| 久久久久亚洲AV无码永不| 久久综合久久综合久久| 亚洲国产成人久久一区久久| 色综合久久中文字幕无码| 国产午夜精品久久久久九九电影| 色偷偷88欧美精品久久久| 国内精品久久久久久久97牛牛| 精品国产91久久久久久久a| 精品国产99久久久久久麻豆| 国产精品亚洲综合专区片高清久久久 | 久久亚洲精品成人无码网站| 国产一区二区三区久久精品| 久久精品免费网站网| 久久国产一区二区| 亚洲国产欧洲综合997久久| 久久狠狠一本精品综合网| 久久精品国产亚洲av麻豆小说 | 久久WWW免费人成—看片| 久久综合给合久久国产免费| 久久精品国产黑森林| 国产激情久久久久影院| 久久综合九色综合网站| 久久人人爽人人爽人人片AV麻烦| 国产毛片久久久久久国产毛片| 久久精品中文字幕久久| 久久久久久九九99精品| 亚洲精品无码久久久久去q| 波多野结衣久久| 合区精品久久久中文字幕一区| 久久久久亚洲AV无码专区桃色| 一级做a爰片久久毛片16| 青草影院天堂男人久久| 色综合久久中文色婷婷| a级毛片无码兔费真人久久| 青青草国产精品久久| 久久国产综合精品五月天| 久久精品国产99久久久香蕉 |