上文已經提到過,如果一個框架要為我們的應用做更多的事情,那么這個框架必須建立更多的標準,必須對框架自己要處理的消息有更多的了解,所以,每個消息都要是自描述的,也就是說每個消息要包含它自己的“元數據”。那么,“元數據”位于消息的何處了?你一定想到了,對,是消息頭( MessagHeader )。
在
ESFramework
中,消息
NetMessage
由“消息頭
+
主體”構成,并且消息頭和主體都必須實現上文講到的
IContract
接口。消息頭既是本條
NetMessage
的元數據,其中包含了諸如消息長度、消息類型等描述信息。
ESFramework
為了能識別每個消息的元數據,必須再建立一個“標準”,這個標準便是
IMessageHeader
接口。為了簡化后面的計算和應用,
ESFramework
要求所有的消息頭的長度是固定的,比如都是
64
字節。注意,固定消息頭的長度不是必須的,但是這會降低框架的復雜度。
我們來看看
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 ;} // 發出請求的用戶編號
11 bool P2PAck{ get ; set ;} // 僅僅對P2P消息有效,1表示為服務器轉發P2P消息的Ack,Result反映了轉發成功還是失敗。Ack消息主體為null
12 bool ZipMe{ get ; set ;} // 控制對于本條消息是否啟用壓縮/解壓縮,如果有些消息比較短小,則將IMessageHeader.ZipMe設為false
13 }
IMessageHeader 現在已經包含了比較多的內容了,其實剛開始時, IMessageHeader 僅僅需要 32 個字節就足夠,隨著 ESFramework 的演化成長,越來越多的信息慢慢加了進來,現在 IMessageHeader 的長度基本上需要 96 字節。加進來的內容對很多應用是必須的。
比如, DestUserID 表明了本條消息不是交給服務器處理的,而是要服務器轉發給 ID 為 DestUserID 的用戶,這為框架引入了處理“ P2P 消息”的能力;有時,用戶可能需要發送一系列按順序的 P2P 消息,如果是基于 UDP ,則必須要等到對方確認收到上一個消息后,才可以發送下一個消息,于是就有了 P2PAck 字段。基于對網絡上傳輸的消息進行壓縮是常見的要求,而有些比較短小的消息又不必進行壓縮的情況,就出現了 ZipMe 字段,表明消息是否被壓縮 / 解壓過。
而在你的具體應用中,消息頭應該包括哪些內容,由你的應用的需求來決定,比如,你的應用可能從來不需要處理 P2P 消息,那么在實現 IMessageHeader 接口時,就不需要關注 DestUserID 字段和 P2PAck 字段,并且在你的實際的消息頭的字節流中也不需要為它們提供“位置”;而且在使用 ESFramework 裝配你的應用的時候,也不用“接插”“ P2PMessage 處理器”。這是非常靈活的。
剛才看到的是消息頭的結構,那么消息主體是什么了?在框架這一層,由于框架對所有的具體消息的主體內容一無所知,即使框架知道消息主體可以被解析為一個
IContract
“對象”,但是在這一層,并沒有足夠的信息給框架去將主體解析為
IContract
。所以,框架中的消息主體仍然用字節流
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
可以存放發送本條消息的客戶的
IPEndPoint
,而這個信息可能會被后面的消息處理器用到。
RoundedMessage包含了比NetMessage更豐富的信息,從網絡進口接收到的實際上是RoundedMessage,有時消息分配器或處理器可能需要用到類似ConnectID這樣的信息。
在客戶端和應用這一層,
NetMessage
可以向下轉換,因為此時,我們已經知道了消息主體的結構,這個消息主體已經可以被解析為
IContract
了,所以
NetMessage
可以轉換為
Message
:

可以看到,
NetMessage 已經是一個完全的面向對象的消息了。而至于主體到底含有什么具體的內容,還需要對主體 IContract 向下轉換到具體的協議上才行。這通常是消息處理器的工作。關于消息處理器和處理器工廠的介紹,請留意下篇文章。
ESFramework
介紹之(
3
)
――
消息處理器和處理器工廠
上一篇: ESFramework介紹之(1)――網絡通信消息協議接口IContract
轉到: ESFramework 可復用的通信框架(序)
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
