《自定義應(yīng)用層通信協(xié)議.doc》由會員分享，可在線閱讀，更多相關(guān)《自定義應(yīng)用層通信協(xié)議.doc（5頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1．通信協(xié)議的概念及其要素 在OSI開放互聯(lián)參考模型中，對等實體之間數(shù)據(jù)單元在發(fā)送方逐層封裝，在接收方的逐層解析。發(fā)送方N層實體從N+1層實體得到的數(shù)據(jù)包稱為服務(wù)數(shù)據(jù) 單元（Service Data Unit，SDU）。N層實體只將其視為需要本實體提供服務(wù)的數(shù)據(jù)，將服務(wù)數(shù)據(jù)單元進行封裝，使其成為一個對方能夠理解的數(shù)據(jù)單元（Protocol Data Unit，PDU），封裝過程實際上是為SDU增加對等實體間約定的控制信息（Protocol Control Information，PCI）的過程。 為了保證網(wǎng)絡(luò)的各個功能的相對獨立性，以及便于實現(xiàn)和維護，通常將協(xié)議劃分為多個子協(xié)議，并且讓這些協(xié)議保持一種層次結(jié)構(gòu)，子協(xié)議的集合通常稱為協(xié)議簇。 網(wǎng)絡(luò)協(xié)議的分層有利于將復(fù)雜的問題分解成多個簡單的問題，從而分而治之。各層的協(xié)議由各層的實體實現(xiàn)，通信雙方對等層中完成相同協(xié)議功能的實體稱為 對等實體。對等實體按協(xié)議進行通信，所以協(xié)議反映的是對等層的對等實體之間的一種橫向關(guān)系，嚴格地說，協(xié)議是對等實體共同遵守的規(guī)則和約定的集合。 通信協(xié)議精確地定義了雙方通信控制信息和解釋信息：發(fā)送方能將特定信息（文本、圖片、音頻、視頻）按協(xié)議封裝成指定格式的數(shù)據(jù)包，最終以串行化比特流在網(wǎng)絡(luò)上傳輸；接收方接收到數(shù)據(jù)包后，根據(jù)協(xié)議將比特流解析為本地化數(shù)據(jù)，從而獲取對方發(fā)送過來的原始信息。 通信協(xié)議包括三個要素： （1）語法：規(guī)定了信息的結(jié)構(gòu)和格式； （2）語義：表明信息要表達的內(nèi)容； （3）同步：規(guī)則涉及雙方的交互關(guān)系和事件順序。 整個計算機網(wǎng)絡(luò)的實現(xiàn)體現(xiàn)為協(xié)議的實現(xiàn)，TCP/IP協(xié)議是Internet互聯(lián)網(wǎng)的核心協(xié)議。 2．通信協(xié)議開發(fā)步驟 （1） 協(xié)議的開發(fā)主要包括協(xié)議設(shè)計、協(xié)議形式描述、協(xié)議實現(xiàn)和協(xié)議一致性測試。協(xié)議的開發(fā)過程與步驟如圖1所示。 圖1 協(xié)議開發(fā)過程與步驟 （2） 協(xié)議設(shè)計過程中的分組發(fā)送接收模型如圖2所示。 圖2協(xié)議設(shè)計過程中的分組發(fā)送接收模型 （3）協(xié)議的一致性測試 協(xié)議的一致性測試是指測試協(xié)議能否按照預(yù)想的控制策略實現(xiàn)正確的通信，主要體現(xiàn)在數(shù)據(jù)包通過信道從信源傳送到信宿后，信宿能夠根據(jù)協(xié)議正確的解析出原始信息。 協(xié)議的一致性測試如圖3所示。 圖3 協(xié)議一致性測試環(huán)境 根據(jù)測試環(huán)境的可以分為局部測試和分布式測試，如圖4所示。 圖4局部測試法、分布式測試法 3．數(shù)據(jù)包和數(shù)據(jù)報 為方便描述自定義協(xié)議，還是借用數(shù)據(jù)包和數(shù)據(jù)報來描述封裝數(shù)據(jù)單元和傳輸數(shù)據(jù)單元，但這里的數(shù)據(jù)包和數(shù)據(jù)報完全不同于TCP/IP架構(gòu)中的Packet和Datagram概念。 下文所述的數(shù)據(jù)包指封裝的基本單位，以TLV（Type-Length-Value）格式封裝基本消息單位；數(shù)據(jù)報Package是傳輸?shù)幕締挝?，頭部包含序列號和命令信息。接收端根據(jù)命令信息分辨事件類型，做出不同的解析。報文實體是多個TLV數(shù)據(jù)包組成的鏈表。 4.數(shù)據(jù)包TLV的設(shè)計 從應(yīng)用層HTTP協(xié)議，到超文本置標語言HTML（HyperText Mark-up Language），再到可擴展置標語言XML（Extensible Markup Language），它們提供了數(shù)據(jù)的格式化存儲、傳輸和格式化顯示的規(guī)范，是網(wǎng)絡(luò)通信的基石。然而HTTP協(xié)議以及HTML/XML置標語言的本質(zhì)就是 定義一堆標簽（Tag）對數(shù)據(jù)進行串行化序列化，然后接收方再根據(jù)標簽解析、還原數(shù)據(jù)。 自定義通信協(xié)議的關(guān)鍵是對數(shù)據(jù)包的合理構(gòu)造（construct）和正確解析（parse），即制定編解碼規(guī)則。 抽象語法標記ASN（Abstract Syntax Notation） BER的長度確定的編碼方式，由3部分組成Identifier octets、Length octets和Contents octets，實際上這就是一中TLV（Type-Length-Value）模型：類型字段（Type或Tag）是關(guān)于標簽和編碼格式的信息；長度字段 （Length）定義數(shù)值的長度； 內(nèi)容字段（Value）表示實際的數(shù)值。 因此，一個編碼值又稱TLV三元組。編碼可以是基本型或結(jié)構(gòu)型，如果它表示一個簡單類型的、完整的顯式值，那么編碼就是基本型（primitive）；如果它表示的值具有嵌套結(jié)構(gòu)，那么編碼就是結(jié)構(gòu)型 （constructed）。 TLV編碼就是指對Type（Tag）、Length和Value進行編碼，形成比特流數(shù)據(jù)包；解碼是編碼的逆過程，是從比特流緩沖區(qū)中解析還原出原始數(shù)據(jù)。 采用C++編程語言設(shè)計TLV協(xié)議類，其類視圖如圖5所示。 圖5 CTLV類視圖 目前只提供設(shè)置整形值（int型）的setValue_Int和設(shè)置字符串值（C_String型）的SetValue_Cstring兩個接口。 TLV將數(shù)據(jù)封裝成包的格式如表1所示。 表1 TLV包格式 TLV包 頭部 包實體 m_dwTag m_nLen m_pValue TLV的接口說明： （1）值類型標簽m_vtTag是內(nèi)部輔助枚舉變量，它根據(jù)構(gòu)造TLV時傳遞的服務(wù)類型標簽m_dwTag來確定。 （2）TLV::m_nLen在為TLV設(shè)置具體值時確定。 （3）TLV包的封裝： 1）使用Tag參數(shù)創(chuàng)建一個TLV對象后，調(diào)用TLV::setValue_*方法為TLV填充具體值； 2）調(diào)用TLV::toBuffer方法打包到緩沖區(qū)streamBuffer。 （4）TLV包的解析：創(chuàng)建一個TLV對象后，調(diào)用TLV::fromBuffer方法從緩沖區(qū)streamBuffer解析出TLV。 （5）封裝和解析涉及到本機字節(jié)順序和網(wǎng)絡(luò)字節(jié)順序的轉(zhuǎn)換問題。 （6）調(diào)用TLV::setValue_*方法填充TLV時，統(tǒng)一字節(jié)邊界數(shù)為4。 5.數(shù)據(jù)報Package的設(shè)計 不同于底層的數(shù)據(jù)包/數(shù)據(jù)報只是對數(shù)據(jù)層次的封裝解析，實際應(yīng)用程序是以事件驅(qū)動的，因此必須注冊不同的信令（事件類型標簽），然后填充到數(shù)據(jù)報中。接收端根據(jù)信令做出相應(yīng)的事件處理。 例如在C/S通信系統(tǒng)中，客戶端往往要先登錄，通過服務(wù)器端的校驗才能進行后續(xù)通信。因此客戶端運行后，需要構(gòu)造并向服 務(wù)器端發(fā)送含有LOGIN信令的包含用戶名字符串strUserName和密碼字符串strPassWord的數(shù)據(jù)報；服務(wù)器端解析LOGIN信令后做校 驗處理，然后發(fā)送含有LOGIN_RESPONSE信令和校驗結(jié)果的回執(zhí)數(shù)據(jù)報給客戶端。 采用C++編程語言設(shè)計Package類，其類視圖如圖6所示。 圖6 CPackage類視圖 Package類將TLV封裝成包的格式如表2所示。 表2 Package包格式 Package包 頭部 序列號 包實體 m_nCmdLen m_dwCmdID m_dwCmdState m_nSeqNo Count*Tlv Package的接口說明： （1）Package::m_nCmdLen是整個Package包的長度，將其作為首個字段的好處在于當傳送大數(shù)據(jù)包時，接收方可以根據(jù)數(shù)據(jù)長度來控制讀狀態(tài)，從而將一個大數(shù)據(jù)包分批接收。 （2）Package::m_nCmdLen在構(gòu)造函數(shù)中初始化為16，在調(diào)用Package::addTLV方法填充包實體時增長。 （3）Package包的封裝： 1）創(chuàng)建Package對象后，調(diào)用Package::setHeader方法填充頭部信令； 2）創(chuàng)建TLV對象并填充數(shù)據(jù)，再調(diào)用Package::addTLV方法填充包實體； 3）調(diào)用Package::toBuffer方法將Package打包到緩沖區(qū)streamBuffer。 （4）Package包的解析： 1）先創(chuàng)建一個Package對象，調(diào)用Package::fromBuffer方法從緩沖區(qū)streamBuffer先解析出Package的頭部和序列號，再從剩余緩沖區(qū)中解析出TLV并將其串行化到鏈表。 2）調(diào)用Package::getTLV方法根據(jù)Tag從鏈表中查找具體TLV包，再調(diào)用TLV::getValue方法取得具體值。 （5）Package::toBuffer方法和Package::fromBuffer方法主要遍歷Package::m_TLV_List列表，然后調(diào)用TLV::toBuffer方法和TLV::fromBuffer方法解析出TLV數(shù)據(jù)單元。 TLV數(shù)據(jù)包的功能測試（主要是本地測試） 鑒于實際通信數(shù)據(jù)最后都要轉(zhuǎn)換成比特流，故只測試發(fā)送字符串類型的變量，僅測試協(xié)議能否正確打包、解析。其他類型的普通數(shù)據(jù)都可以轉(zhuǎn)換成字符串傳輸，最后，接收方根據(jù)m_dwTag確定值類型m_vtTag，解析出具體值。 對TLV::setValue_C_String方法填充TLV的測試，需要考慮字節(jié)對齊問題。對于長度為4字節(jié)倍數(shù)的C狀態(tài)字符串，打包時省去末尾的‘/0’結(jié)束標志符。需要測試長度非4倍數(shù)的字符串和長度為4倍數(shù)的字符串。 經(jīng)本地測試，調(diào)用TLV::setValue_Int方法和TLV::setValue_C_String方法構(gòu)造整形和字符串時，能夠正確封裝、正確解析。 Package數(shù)據(jù)報的功能測試，主要是將TLV組合成包，然后添加信令，完成特定的通信。對登陸LOGIN和發(fā)送消息SUBMIT_SM的測試表明Package協(xié)議能正確封裝、正確解析。 在實際項目中使用Package通信協(xié)議，對于稍大一點的數(shù)據(jù)塊需要控制好讀的步驟，以便能接收整包完整的信息。