新生命团队

注册

 

QQ登录

只需一步,快速开始

发新话题 回复该主题

【发布】网络层直接支持粘包处理和超大包收发 [复制链接]

v6.1.2016.1208   网络层直接支持粘包处理和超大包收发,粘包接口IPacket默认实现HeaderLengthPacket支持基于长度的粘包拆分

已发布到Nuget,vs搜索NewLife.Core即可引用。
源代码已同步:
https://github.com/NewLifeX/X
https://git.oschina.net/NewLifeX/X
http://git.wslink.cn/NewLife/X


测试用例位于 HeaderLengthPacket.Test


简单用法:
var svr = new NetServer();
svr.Port = 777;
svr.SessionPacket = new HeaderLengthPacket();
svr.Log = Log.XTrace.Log;
svr.LogReceive = true;
svr.Start();
重点就是实例化一个IPacket接口的具体实现(根据业务协议),赋值给SessionPacket。


内部实现HeaderLengthPacket,约定每个消息包开头就是长度,使用7位压缩编码整数,网络层将会根据该长度识别消息包是否完整,并拆包返回给上层,业务逻辑层拿到的已经是一个个拆分好的消息包。
如果缓冲区残留数据在3秒内没有跟新数据包匹配,则抛弃残留数据,避免连锁错误。
消息体长度不一定在开头,也可能使用定长长度,可以在HeaderLengthPacket属性里面设定,包括抛弃残留数据的时间。


Udp粘包测试,网络层默认凑合8K超大包发出,可以规避Udp小包顺序不确定的问题,这里为了测试,估计把缓冲区减小到1500。
所以,如果数据包接收顺序乱了,粘包处理会失败。

Tcp粘包测试,默认缓冲区8k,测试需要改为1500
因为Tcp确保数据包先后顺序,所以粘包处理百分比成功!


End.

分享 转发
我不相信神话,我只相信汗水!我不相信命运,我只相信双手!
TOP

你现在的处理逻辑应该是(我只说TCP)每个包的包头附加包长度,包会在IP层被拆分成很多帧,逐帧发到Server?。    这样如果我们用以太网那么所有的数据都是我们自己组织的。  如果我们用COM To Gprs  这样我们的数据会通过中间的DTU模块(市面上现成的模块不同的dtu会有不同方式) dtu 会在数据封包(dtu的封包)时附加一些电话号码,编号等(不同DTU不一样有的附加在心跳里)。总之 导致一个结果就是我们的大包的多帧中间其实加了一些 很多数据。
星辰手
TOP
发新话题 回复该主题