上文已經提到過，如果一個框架要為我們的應用做更多的事情，那么這個框架必須建立更多的標準，必須對框架自己要處理的消息有更多的了解，所以，每個消息都要是自描述的，也就是說每個消息要包含它自己的“元數據”。那么，“元數據”位于消息的何處了？你一定想到了，對，是消息頭（ MessagHeader ）。
在
ESFramework
中，消息
NetMessage
由“消息頭
+
主體”構成，并且消息頭和主體都必須實現上文講到的
IContract
接口。消息頭既是本條
NetMessage
的元數據，其中包含了諸如消息長度、消息類型等描述信息。
ESFramework
為了能識別每個消息的元數據，必須再建立一個“標準”，這個標準便是
IMessageHeader
接口。為了簡化后面的計算和應用，
ESFramework
要求所有的消息頭的長度是固定的，比如都是
64
字節(jié)。注意，固定消息頭的長度不是必須的，但是這會降低框架的復雜度。
我們來看看
IMessageHeader
中包含了些什么信息：
2 {
3 int MessageBodyLength{ get ; set ;} // 本消息主體的長度
4 int TypeKey{ get ; set ;} // 請求的服務目錄類型
5 int ServiceKey{ get ; set ;} // 請求類型
6 int ServiceItemIndex{ get ; set ;} // 請求細分索引
7 int RandomNum{ get ; set ;} // 用于將回復與請求一一對應起來
8 int Result{ get ; set ;} // 服務結果，1表示成功。其它值對應ServiceResultType
9 string DestUserID{ get ; set ;} // 接收消息的目標用戶編號
10 string UserID{ get ; set ;} // 發(fā)出請求的用戶編號
11 bool P2PAck{ get ; set ;} // 僅僅對P2P消息有效，1表示為服務器轉發(fā)P2P消息的Ack，Result反映了轉發(fā)成功還是失敗。Ack消息主體為null
12 bool ZipMe{ get ; set ;} // 控制對于本條消息是否啟用壓縮/解壓縮，如果有些消息比較短小，則將IMessageHeader.ZipMe設為false
13 }
IMessageHeader 現在已經包含了比較多的內容了，其實剛開始時， IMessageHeader 僅僅需要 32 個字節(jié)就足夠，隨著 ESFramework 的演化成長，越來越多的信息慢慢加了進來，現在 IMessageHeader 的長度基本上需要 96 字節(jié)。加進來的內容對很多應用是必須的。
比如， DestUserID 表明了本條消息不是交給服務器處理的，而是要服務器轉發(fā)給 ID 為 DestUserID 的用戶，這為框架引入了處理“ P2P 消息”的能力；有時，用戶可能需要發(fā)送一系列按順序的 P2P 消息，如果是基于 UDP ，則必須要等到對方確認收到上一個消息后，才可以發(fā)送下一個消息，于是就有了 P2PAck 字段。基于對網絡上傳輸的消息進行壓縮是常見的要求，而有些比較短小的消息又不必進行壓縮的情況，就出現了 ZipMe 字段，表明消息是否被壓縮 / 解壓過。
而在你的具體應用中，消息頭應該包括哪些內容，由你的應用的需求來決定，比如，你的應用可能從來不需要處理 P2P 消息，那么在實現 IMessageHeader 接口時，就不需要關注 DestUserID 字段和 P2PAck 字段，并且在你的實際的消息頭的字節(jié)流中也不需要為它們提供“位置”；而且在使用 ESFramework 裝配你的應用的時候，也不用“接插”“ P2PMessage 處理器”。這是非常靈活的。
剛才看到的是消息頭的結構，那么消息主體是什么了？在框架這一層，由于框架對所有的具體消息的主體內容一無所知，即使框架知道消息主體可以被解析為一個
IContract
“對象”，但是在這一層，并沒有足夠的信息給框架去將主體解析為
IContract
。所以，框架中的消息主體仍然用字節(jié)流
byte[]
表示，而且框架也根本不關心這個消息主體如何解析、如何處理，這些都是應用的事情。框架已經通過消息的元數據對該消息有足夠的了解了。
消息
NetMessage
的定義如下：
2 public class NetMessage
3 {
4 public IMessageHeaderHeader = null ;
5 public byte []Body = null ; // 可以經過壓縮、變換Hook
6 public object Tag = null ; // 用于在將NetMessage交給IDataDealer時傳遞額外的信息，不影響ToStream，且很少使用
7
8 public NetMessage()
9 {
10 }
11
12 #region Ctor,ToStream
13 public NetMessage(IMessageHeaderheader, byte []body)
14 {
15 //省略實現......
23 }
24
25 public byte []ToStream()
26 {
27 //省略實現......
41 }
42 #endregion
43
44 #region Length
45 public int Length
46 {
47 //省略實現......
57 }
58 #endregion
59
60 }
Tag
字段用于存放可能在后面的消息處理鏈中需要使用到的額外信息，比如，基于
UDP
時，
Tag
可以存放發(fā)送本條消息的客戶的
IPEndPoint
，而這個信息可能會被后面的消息處理器用到。
RoundedMessage包含了比NetMessage更豐富的信息，從網絡進口接收到的實際上是RoundedMessage，有時消息分配器或處理器可能需要用到類似ConnectID這樣的信息。
在客戶端和應用這一層，
NetMessage
可以向下轉換，因為此時，我們已經知道了消息主體的結構，這個消息主體已經可以被解析為
IContract
了，所以
NetMessage
可以轉換為
Message
：
Message
可以看到，
NetMessage 已經是一個完全的面向對象的消息了。而至于主體到底含有什么具體的內容，還需要對主體 IContract 向下轉換到具體的協(xié)議上才行。這通常是消息處理器的工作。關于消息處理器和處理器工廠的介紹，請留意下篇文章。
ESFramework
介紹之（
3
）
――
消息處理器和處理器工廠
上一篇： ESFramework介紹之（1）――網絡通信消息協(xié)議接口IContract
轉到： ESFramework 可復用的通信框架（序）
更多文章、技術交流、商務合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
