NewLife.Net——管道处理器解决粘包
Tcp网络编程,必须要解决的一个问题就是粘包,尽管解决办法有很多,这里讲一个比较简单的方法。
老规矩,先上代码:https://github.com/NewLifeX/NewLife.Net
一、管道处理器
新建管道处理器项目HandlerTest,源码复制自第一节课的EchoTest项目,增加一个管道处理器类
class EchoHandler : Handler
{
public override Object Read(IHandlerContext context, Object message)
{
var session = context.Session; var pk = message as Packet;
session.WriteLog("收到:{0}", pk.ToStr()); // 把收到的数据发回去
session.Send(pk); return null;
}
}
EchoHandler继承自处理器基类Handler,重载Read方法,当网络层收到数据包时,会调用该方法。
这里我们实现了Echo功能,并打印日志。返回null告知不再执行管道上的后续处理器。
既然有了处理器,第一节课中的MyNetServer就用不上啦,在TestServer中改回来标准的NetServer
// 实例化服务端,指定端口,同时在Tcp/Udp/IPv4/IPv6上监听
var svr = new NetServer
{
Port = ,
Log = XTrace.Log
};
svr.Add<EchoHandler>();
svr.Start();
这里的svr.Add<EchoHandler>()把上面的处理器给注册进去,大意就是由这个处理器来负责处理收到的网络数据包。
跑起来服务端和客户端看看效果:
可以看到,收发正常!
二、粘包的产生
真实应用场景中,不可能允许我们间隔1秒才发出一个网络包,直接就不该有等待。连续发送多个数据包,就很容易产生粘包。
static void TestClient()
{
var uri = new NetUri("tcp://127.0.0.1:1234");
//var uri = new NetUri("tcp://net.newlifex.com:1234");
var client = uri.CreateRemote();
client.Log = XTrace.Log;
client.Received += (s, e) =>
{
XTrace.WriteLine("收到:{0}", e.Packet.ToStr());
};
client.Open(); // 定时显示性能数据
_timer = new TimerX(ShowStat, client, , ); // 循环发送数据
for (var i = ; i < ; i++)
{
//Thread.Sleep(1000); var str = "你好" + (i + );
client.Send(str);
} //client.Dispose();
}
这里注释了睡眠语句,让它紧密发出5个数据包。注释后面的Dispose,让其有机会收到响应包。
跑起来看到,粘包了!!!
客户端发送5次,服务端作为一个包给接收了,整体处理,然后返回给客户端。
粘包的解决办法很多,一般是加头部长度或者分隔符,也有取巧的办法直接设置NoDelay。
从使用上来讲,相对可靠的做法是加头部长度。因为除了多个包粘在一起,还可能出现一个包被拆成两半,分别在前后两个包里面。
三、普通粘包解法
我们加上头部长度来解决解包问题。
修改一下服务端,增加一个处理器
static void TestServer()
{
// 实例化服务端,指定端口,同时在Tcp/Udp/IPv4/IPv6上监听
var svr = new NetServer
{
Port = ,
Log = XTrace.Log
};
//svr.Add(new LengthFieldCodec { Size = 4 });
svr.Add<StandardCodec>();
svr.Add<EchoHandler>(); // 打开原始数据日志
var ns = svr.Server;
ns.LogSend = true;
ns.LogReceive = true; svr.Start(); _server = svr; // 定时显示性能数据
_timer = new TimerX(ShowStat, svr, , );
}
StandardCodec处理器是新生命团队标准封包。https://github.com/NewLifeX/X/tree/master/NewLife.Core/Net
其固定4字节作为头部,其中后面两个字节标识负载长度。
也可以使用LengthFieldCodec编码器(如上注释部分),并制定头部加4字节作为长度。
编码器顺序非常重要,网络层收到数据包以后,会从前向后走过每一个处理器;SendAsync/SendMessage发送消息时,会从后向前走过每一个过滤器,逆序。
客户端也要增加相应过滤器
static void TestClient()
{
var uri = new NetUri("tcp://127.0.0.1:1234");
//var uri = new NetUri("tcp://net.newlifex.com:1234");
var client = uri.CreateRemote();
client.Log = XTrace.Log;
client.Received += (s, e) =>
{
var pk = e.Message as Packet;
XTrace.WriteLine("收到:{0}", pk.ToStr());
};
//client.Add(new LengthFieldCodec { Size = 4 });
client.Add<StandardCodec>(); // 打开原始数据日志
var ns = client;
ns.LogSend = true;
ns.LogReceive = true; client.Open(); // 定时显示性能数据
_timer = new TimerX(ShowStat, client, , ); // 循环发送数据
for (var i = ; i < ; i++)
{
var str = "你好" + (i + );
var pk = new Packet(str.GetBytes());
client.SendAsync(pk);
}
}
发送函数改为SendAsync,原来的Send(Packet pk)会绕过管道处理器。
客户端接收时,e.Message表示经过处理器处理得到的消息,e.Packet表示原始数据包。
同时,通过LogSend/LogReceive打开收发数据日志。
上图效果,客户端发出第5个包,头部多了4个字节,其中07-00表示后续负载数据长度为7字节(NewLife)。
服务端先收到第一个包11字节,然后收到44字节,这是4个包粘在一起。
然后StandardCodec编码器成功将其拆分成为4个,并依次通过EchoHandler。
到了客户端这边,也是后面4个粘在一起,并且也得到了正确拆分。
如果一个大包被拆分为几个,StandardCodec也能缓冲合并,半包超过500~5000ms仍未能组合完整时将抛弃。
四、总结
借助管道处理器架构,我们轻易解决了粘包问题!
显然,管道架构并非单纯为了粘包问题而设计,它有着非常重要的意义,加解密、压缩、各种协议处理,等等。
管道架构的设计,参考了Netty,因此大部分Netty的编解码器都可以在此使用。
最新文章
- Quartz
- jcFeather For Maya 2012免费版
- VHDL的参数写在一个vhd文件里
- 使用oh-my-zsh后导致的卡顿问题
- [Reship]如何回复审稿人意见
- 编译rnnlib
- JavaScript parser
- python_way ,day23 API
- OpenGL ES为缓存提供数据的7个步骤
- SSL handshake failed: SSL 错误:在证书中检测到违规的密钥用法。
- UVA 11488-Hyper Prefix Sets(Trie)
- 导航软件 CH Round #57 - Story of the OI Class
- Visual Studio 当前不会命中断点的问题
- 常用Windows DOS命令项目部署经常用到
- cshtml razor
- [UE4]重构Grab和Drop
- javascript模块化编程-立即执行函数(IIFE)
- cmd打开E盘文件
- LeetCode--404--左叶子之和
- mySQL InnoDB 的性能问题讨论