編織訊息框架 設計協議 解決粘包半包 中

上節介紹問題出現跟處理方式，寫資料部份已經實現

這節介紹如何讀處理

處理流程分三部分

1.校驗包是否合法

2.讀取包內容

3.切割包

由於切割包用的是netty處理，所以只需集中精力解決前兩個問題即可

bytetomessagehandler.class

1

@override
2public qpacket decode(channelhandlercontext ctx, bytebuf in) throws
exception 
7if (bytebuf.readablebytes() 10final
short headflag =bytebuf.readshort(); //讀取頭部開始資訊 2byte
11final
int packetlen =bytebuf.readint(); //讀取內容長度
12final
int endlen = 1; //尾部結束標誌 1byte
13 　　//比較頭部資訊是否合法
14if (headflag !=qmconfig.getinstance().getpacketheadflag(packetlen)) 
1718
// 緩衝可讀長度是否少於包長度
netty 處理過了
19//
if (bytebuf.readablebytes() - endlen < packetlen) 
2223
final
int mark =bytebuf.readerindex(); //標記已讀座標，目的先讀最後結束資訊做比較
24bytebuf.skipbytes(packetlen); //跳到最後結束標記
25final
byte endflag =bytebuf.readbyte(); //讀取結束標記1byte
26if (endflag !=qmconfig.getinstance().getpacketendflag(packetlen)) 
29bytebuf.readerindex(mark);//還原座標，開始處理qpacket
30 qpacket ret =qpacket.of(bytebuf, packetlen); //構造qpacket
31bytebuf.skipbytes(endlen); //跳結束標記
32return
ret;
33 }

qpacket

1

public
static qpacket of(bytebuf bytebuf, int
packetlen)

1

public
static qpacket of(byte
bytes)

為什麼沒有直接用第二種方式去構造qpacket?

如果多乙個臨時物件array byte 會有損耗，無必要佔建立時間，多乙份記憶體開銷

之前寫入訊息也採取相同處理方式，直接把資料傳給netty bytebuf 底層

1

public
void
writetobytebuf(bytebuf bytebuf) 89
@override
10public
byte
tobytes()

編織訊息框架 設計協議 位運算

上節介紹bit基礎，這節課介紹bit常用基本運算 為什麼要使用 這幾種常見的運算？如果你理解需求是非常簡單的 需求1 有八種狀態可以疊加 那麼每個狀態佔乙個byte位 每個狀態可用 疊加起來 需求2 要知道已使用那個狀態 用 執行清位資料 得出的結果必然跟狀態相等 需求3 要清除所有狀態用 組合 需...

編織訊息框架 訊息處理模式 管道模式

proxy server 提供外部公開訪問服務 client向proxy server訪問時，proxy server分發n個任務呼叫工作服 而client無需要關心proxy server 如何工作，如服務排程非同步還是同步 等侍合併結果 資料過濾去髒等 常用於 公開訪問服務，如資料分析任務分發 ...

編織訊息框架 訊息處理模式 發布訂閱模式

上面時序流程能解決外部請求，適合c s,b s架構 如果是s s可以簡化流程處理 這是經典的消費 生產模式，簡化了大量的處理邏輯，並消去通訊同併發產生的問題，服務與服務之間形成獨立解偶。一切以記錄為主，只要寫進就認為是處理成功 發布訂閱模式能支援多個消費同多個生產 而發布訂閱模式難點在於資料發生變更...