基于NIO的消息路由的实现(三)服务端与客户端结构

一、服务器端结构:

如图所示:

  • 指令类和报文类:对下行的指令和上行的报文进行了类的封装,分别实现IOrder和IPacket接口,继承Order,Packet基类;
  • 服务主线程:接受客户端连接,将客户端发送的报文投递到通讯队列中,发送指令给客户端;保存连接对象(GVConnection)
  • 通讯队列CQ:存储客户端发送过来的报文,此报文由通讯主线程放入;
  • 通讯队列消费者:对通讯队列中的报文进行处理,该做什么做什么,如果是短消息,则放入消息队列MQ中单独处理;
  • 消息队列消费者:对MQ中的短消息进行处理;如果转发的目标客户端没有通道(channel),那么就存入redis。(此部分目前尚未实现)
  • 通道清理线程,针对超时的通道,已关闭的通道进行定期清理;此部分应该有更好地实现方式,请大家帮忙想想吧。

二、客户端结构:

  • 指令和报文类同上;
  • 链路维护线程:每隔一定的时间发送给服务端K报文,用于链路检测,如果超过服务端的连续回应次数超过一定的限制(比如,连续三次没有回应),那么,视为已经掉线;
  • 短线重连线程:两种情况会引发重连:1、服务端主动切断通道;这来是可捕获的;2、异常中断(依靠链路维护);
时间: 2024-11-05 23:24:48

基于NIO的消息路由的实现(三)服务端与客户端结构的相关文章

基于NIO的消息路由的实现(四) 服务端通讯主线程(2)断包和粘包的处理

本来我打算单独开一章,专门说明粘包和断包,但是觉得这个事儿我在做的时候挺头疼的,但是对于别人或许不那么重要,于是就在这里写吧. 那么何谓粘包.何谓断包呢? 粘包:我们知道客户端在写入报文给服务端的时候,首先要将需要写入的内容写入Buffer,以ByteBuffer为例,如果你Buffer定义的足够大,并且你发送的报文足够快,此时就会产生粘包现象,举例来说 你发送一个 报文" M|A",然后你有发送了一个"M|B",如果产生粘包,服务端从缓冲区里面读出的就是"

基于NIO的消息路由的实现(四) 服务端通讯主线程(1)

一.简单介绍: 服务端通讯主线程是消息路由服务的启动类,其主要作用如下: 1.初始化相关配置: 2.根据配置的ip和port创建tcp服务: 3.接收客户端连接,并给客户端分配令牌: 4.接收客户端的登录请求,并将客户端相关信息(令牌.客户端登录标识.最后访问时间.当前token所使用的通道,保存到缓冲区) 5.接收客户端的报文请求,并添加到通讯队列,等待处理: 6.接收来自各处的指令发送请求,并发送至相关通道: 二.详细介绍: 1.启动方法:首先加载配置信息:然后启动主线程.通讯报文消费线程(

基于NIO的消息路由的实现(七)客户端的一些实现,维持链路,断线重连

一.客户端代码存在的必要性以及我认为需要解决的问题 就NIO通讯本身而言完全没必要分开,其实客户端代码和服务端代码可以放到一起.但是在业务上是分开的.我在做nio的时候思考了许多我自己认为应该解决的问题:主要的如下: 1.链路维护(心跳): 定期的向服务端发送维持链路报文,获得服务端的响应,以证明其仍然在存活状态:同时服务端会记录客户端每次维持链路的时间,用于服务端对通道的超时 判断: 2.断线重连: 一种情况是正常断线,目前我利用对channel的read返回来进行判断: 另一种是非正常短线,

基于NIO的消息路由的实现(六)报文队列的处理

一.报文队列的处理: 如果将多路复用器获取到的所有事件,阻塞式的同步处理,那恐怕会严重影响selector的性能,所以我把从客户端接收到的大部分消息,都放入了队列中,然后另外启动队列的消费线程对消息进行异步的处理:具体如下: 1.通讯报文队列消费者:在selector对read事件的处理过程中,我在最后都把客户端发送的报文放入了一个叫CQUEUE的队列中,具体定义如下,CQUEUE是所有客户端发送报文的队列,在CQUEUE队列中的消费者线程中,我又对M类报文进行了对垒处理,放入了另一个队列MQU

基于SignalR的服务端和客户端通讯处理

SignalR是一个.NET Core/.NET Framework的实时通讯的框架,一般应用在ASP.NET上,当然也可以应用在Winform上实现服务端和客户端的消息通讯,本篇随笔主要基于SignalR的构建一个基于Winform的服务端和客户端的通讯处理案例,介绍其中的处理过程. 1.SignalR基础知识 SignalR是一个.NET Core/.NET Framework的开源实时框架. SignalR的可使用Web Socket, Server Sent Events 和 Long

WebSocket 实现服务端给客户端推送消息

目录 代码发布 应用场景 ajax 操作 队列 递归 如何实现服务端主动给客户端推送消息的效果 长轮询(兼容性好) websocker(主流浏览器都支持) 代码验证(了解) 代码发布 服务端主动给客户端推送消息 截至目前为止,我们所写的 web 项目基本都是基于 HTTP 协议的 HTTP 协议有四大特性:无链接 基于 HTTP 协议实现服务端主动给客户端推送消息好像有点麻烦--- 我们都经历过,浏览器打开一个网站不动,网站过一会儿自动弹出消息 再比如网页版本的微信和 qq,我们所有人创建一个群

WebSocket安卓客户端实现详解(三)–服务端主动通知

WebSocket安卓客户端实现详解(三)–服务端主动通知 本篇依旧是接着上一篇继续扩展,还没看过之前博客的小伙伴,这里附上前几篇地址 WebSocket安卓客户端实现详解(一)–连接建立与重连 WebSocket安卓客户端实现详解(二)–客户端发送请求 终于是最后一篇啦,有点激动\ ( ≧▽≦ ) /啦啦啦, 服务端主动通知 热身完毕,我们先回顾下第一篇中讲到的服务端主动通知的流程 根据notify中事件类型找到对应的处理类,处理对应逻辑. 然后用eventbus通知对应的ui界面更新. 如果

IOS 推送消息 php做推送服务端

IOS推送消息是许多IOS应用都具备的功能,最近也在研究这个功能,参考了很多资料终于搞定了,下面就把步骤拿出来分享下: iOS消息推送的工作机制可以简单的用下图来概括: Provider是指某个iPhone软件的Push服务器,APNS是Apple Push Notification Service的缩写,是苹果的服务器. 上图可以分为三个阶段: 第一阶段:应用程序把要发送的消息.目的iPhone的标识打包,发给APNS. 第二阶段:APNS在自身的已注册Push服务的iPhone列表中,查找有

使用极光推送(www.jpush.cn)向安卓手机推送消息【服务端向客户端主送推送】C#语言

链接网址:http://www.cnblogs.com/yangwujun/p/5973120.html 在VisualStudio2010中新建网站JPushAndroid.添加引用json帮助类库Newtonsoft.Json.dll. 在web.config增加appkey和mastersecret,可以在极光官网www.jpush.cn申请.web.config源码: <?xml version="1.0"?> <!-- 有关如何配置 ASP.NET 应用程序