如何使用网络库实现应用级消息收发

网络客户端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.

posted @ 2017-08-30 22:51 大石头 阅读(...) 评论(...) 编辑 收藏