网络客户端ISocketClient和网络会话ISocketSession都继承了ISocketRemoteISocketRemote表示远程通信,核心就是收发数据。
下面是ISocketRemote接口的主要实现
/// <summary>远程通信Socket,仅具有收发功能</summary> public interface ISocketRemote : ISocket { #region 属性 /// <summary>远程地址</summary> NetUri Remote { get; set; } /// <summary>通信开始时间</summary> DateTime StartTime { get; } /// <summary>最后一次通信时间,主要表示会话活跃时间,包括收发</summary> DateTime LastTime { get; } /// <summary>缓冲区大小</summary> Int32 BufferSize { get; set; } #endregion #region 发送 /// <summary>发送数据</summary> /// <remarks> /// 目标地址由<seealso cref="Remote"/>决定 /// </remarks> /// <param name="pk">数据包</param> /// <returns>是否成功</returns> Boolean Send(Packet pk); #endregion #region 接收 /// <summary>接收数据。阻塞当前线程等待返回</summary> /// <returns></returns> Packet Receive(); /// <summary>数据到达事件</summary> event EventHandler<ReceivedEventArgs> Received; /// <summary>消息到达事件</summary> event EventHandler<MessageEventArgs> MessageReceived; #endregion #region 数据包处理 /// <summary>粘包处理接口</summary> IPacket Packet { get; set; } /// <summary>异步发送数据并等待响应</summary> /// <param name="pk"></param> /// <returns></returns> Task<Packet> SendAsync(Packet pk); /// <summary>发送消息并等待响应</summary> /// <param name="msg"></param> /// <returns></returns> Task<IMessage> SendAsync(IMessage msg); #endregion }
一、同步收发
一般小型网络应用,或者个人学习程序,都会使用同步收发。
Send(xxx);
var buf = Receive();
这样向对服务端发一个数据包,然后同步阻塞等待接收一个响应数据。
同步收发最大的优点就是简单,容易理解;
最大的缺点是性能极其底下,并且很大的几率会失败抛出异常,特别是离开本机或者局域网以后。
除非网络很干净,客户端服务端只进行很简单的通信,否则出错崩溃就是家常便饭!
并且,这个阶段的工程师,一般认为只能客户端向服务端发数据,而不知道服务端可以主动向客户端发数据。
因此,15年经验表明,同步收发根本不适合做产品级应用!
二、事件驱动
中大型网络应用,一般采用事件驱动,特别是多并发服务端。
不管是APM还是SAEA,绝大多数网络框架都会包装成为事件,或者路由分发架构。
正如前文接口图黄色箭头所示,事件驱动一般用法:
client.Received += OnReceive;
client.Send(xxx);
先建立接收事件,然后发送数据,如果对方有响应,就会触发OnReceive函数,对响应结果进行处理。
事件驱动(包括路由分发)是当下网络框架主流,占比超过70%
几乎所有框架都会在此之外再包装一层,Send一个业务对象,内部序列化为数据后发出,OnReceive后反序列化得到业务对象,返回给上层。
事件驱动跟同步业务需求是相背而行的。
如果业务需要向服务端发送一个请求,然后等待响应结果,那么事件驱动甚至还不如同步操作好用!
一般做法是Send里面做堵塞等待,然后OnReceive里面做拦截。
这也是事件驱动无法进一步扩大比例的根本原因。
事件驱动很好很强大,只是特别不适应业务上的同步操作需求!
三、异步请求响应
近20年的软件发展史,无一例外等同于Web发展史。
除了技术的发展,Web思维影响了几乎所有软件工程师。哪怕初学者,也很清楚HTTP是请求响应模型。在Web开发里面,所有的业务都要基于请求与响应。
于是我们网络库有了第三种选择。(前文接口图紫色箭头)
Task<Packet> SendAsync(Packet pk);
Task<IMessage> SendAsync(IMessage msg);
event EventHandler<MessageEventArgs> MessageReceived;
异步发送SendAsync,可以像事件模型那样在MessageReceived里面处理,也可以 var rs = await SendAsync(pk); 把异步转为同步操作,满足同步业务需求。
更为重要的是,SendAsync支持单连接通道并行多异步请求!
也就是说,在一个网络连接上,第一个请求的响应还没有收到之前,业务逻辑可以连续发出更多的请求,不管这些请求的响应包先后顺序以后,网络库都能够准确配对,让await SendAsync得到正确的结果。
这就解决了一个极为常见的问题,一个业务应用里面,可能多个线程需要向服务端请求数据,而传统做法只能是加锁,在第一个请求响应完成之前,阻塞其它请求。
实际上,HTTP 1.0/1.1正是传统做法,前一个请求完成之前,不能发起新的请求,导致浏览器不得不建立多个Tcp连接。
因此,异步请求响应的架构设计,让请求响应准确配对,支持并行请求,并且解决一切粘包问题!
应用级消息收发伪代码:
var str = "{action:Open,args:{index:3},remark:打开3号灯}"; var client = new NetUri("tcp://127.0.0.1:1234").CreateRemote(); client.Packet = new DefaultPacket(); var rs = await client.SendAsync(str.GetBytes()); // rs = "{result:true,data:3号灯已打开}"
上面的DefaultPacket正是 新生命团队标准网络封包协议
请求响应包的头部,都会增加4字节,Json字符串作为负载数据。
正是增加的这4字节,确保了请求响应的准确配对(序列号匹配),解决了粘包问题(头部长度)
即使没有默认封包DefualtPacket,上面代码也是可以工作的,只是这样就失去了准确配对和粘包拆分,要求业务层不能频繁收发。
End.
原文:http://www.cnblogs.com/nnhy/p/7455792.html