這個問題比較常見，在高并發(fā)大數(shù)據(jù)傳輸時數(shù)據(jù)分包接收會亂

在org.jboss.netty.handler.codec.frame包中，有LengthFieldBasedFrameDecoder類用來解析帶有長度屬性的包，只要我們在傳輸協(xié)議中加入包的總長度就行了（也許有更好的方法）

?

具體方法：

1.可在數(shù)據(jù)包前加4個字節(jié)表示包的總長度，例如：

?

/**?
* 傳輸協(xié)議
* |------------------------------------------
* |總長度4byte |pkey長度4byte ? ? ?|
* |------------------------------------------
* | value 4byte|name 4byte|zip ?1 |
* |------------------------------------------
* |skey值 ? ? ?8byte(long型時間，固定) |
* |------------------------------------------------
* | ?包體內(nèi)容 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
* | ? ? ? ? ? ? ? ? ? ?
* |------------------------------------------------

在通過netty傳輸數(shù)據(jù)之前，執(zhí)行

?

2.在接受的ChannelPipeline中加入decoder，加在handler之前，例如：

?

?

[java]?view plaincopy

bootstrap.setPipelineFactory(new?ChannelPipelineFactory()?{??

???????????public?ChannelPipeline?getPipeline()?throws?Exception?{??

????????????ChannelPipeline?pipeline?=?new?DefaultChannelPipeline();??

????????????pipeline.addFirst("decoder",?new?LengthFieldBasedFrameDecoder(100000000,0,4,0,4));??

????????????pipeline.addLast("handler",?new?XXX(config));??

????????????return?pipeline;??

???????????}??

???????});??

?

?

使用LengthFieldBasedFrameDecoder作為decoder實(shí)現(xiàn)，LengthFieldBasedFrameDecoder構(gòu)造函數(shù)，第一個參數(shù)為信息最大長度，超過這個長度回報(bào)異常，第二參數(shù)為長度屬性的起始（偏移）位，我們的協(xié)議中長度是0到第3個字節(jié)，所以這里寫0，第三個參數(shù)為“長度屬性”的長度，我們是4個字節(jié)，所以寫4，第四個參數(shù)為長度調(diào)節(jié)值，在總長被定義為包含包頭長度時，修正信息長度，第五個參數(shù)為跳過的字節(jié)數(shù)，根據(jù)需要我們跳過前4個字節(jié)，以便接收端直接接受到不含“長度屬性”的內(nèi)容。

?

至此，接收端會按照decoder指定的長度接收完整后才會調(diào)用handler繼續(xù)處理信息。

轉(zhuǎn)載于:https://www.cnblogs.com/gehonglin/p/4174459.html

總結(jié)

以上是生活随笔為你收集整理的过长内容分成了多次发送 问题 LengthFieldBasedFrameDecoder使用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。