应用层协议解耦合的通用网络处理系统.pdf

《应用层协议解耦合的通用网络处理系统.pdf》由会员分享，可在线阅读，更多相关《应用层协议解耦合的通用网络处理系统.pdf（18页完成版）》请在专利查询网上搜索。

1、(19)中华人民共和国国家知识产权局 (12)发明专利申请 (10)申请公布号 (43)申请公布日 (21)申请号 202010608948.0 (22)申请日 2020.06.29 (71)申请人 上海金融期货信息技术有限公司 地址 200122 上海市浦东新区世纪大道 1600号17楼 (72)发明人 张海荣李思昌张勇鲁继东 (74)专利代理机构 上海专利商标事务所有限公 司 31100 代理人 施浩 (51)Int.Cl. H04L 29/08(2006.01) (54)发明名称 一种应用层协议解耦合的通用网络处理系 统 (57)摘要 本发明公开了一种应用层协议解耦合的通 用网络处理系统。

2、， 实现跨进程间基于主题的多种 应用层协议解耦合的通讯组件， 通过提供极简化 的调用接口来实现不同应用场景下的业务通讯 需求， 降低了使用成本。 其技术方案为： 系统中的 协议解耦合可根据场景随意组合， 同一个主题可 以提供多种通讯方式并根据特定的场景进行随 意组合， 且可以基于该组件简单方便的开发各种 上层业务应用。 此外， 本发明的系统实现统一封 装， 服务器端和客户端可以初始化若干个主题， 每个主题之间相互独立， 接口仅需指明主题号， 由系统完成接口匹配。 权利要求书2页 说明书8页 附图7页 CN 112134915 A 2020.12.25 CN 112134915 A 1.一种应用。

3、层协议解耦合的通用网络处理系统， 其特征在于， 系统包括服务器端配置 的组件和客户端配置的组件， 服务器端配置的组件包括主题初始化接口单元、 发布流初始 化接口单元、 发布接口单元、 应答接口单元、 消息透传接口单元、 链路建立回调处理单元、 请 求回调处理单元、 消息透传接收处理单元， 客户端配置的组件包括主题初始化接口单元、 订 阅接口单元、 请求接口单元、 消息透传接口单元、 链路建立回调处理单元、 应答回调处理单 元、 订阅回调处理单元、 消息透传接收处理单元， 其中： 服务器端配置的组件中， 主题初始化接口单元， 通过指明主题号和网络端口地址进行初始化处理， 其中主题号 用于使能服务。

4、器端对应的主题； 发布流初始化接口单元， 用于对主题在服务器端的发布流的初始化处理； 发布接口单元， 将发布数据传送至主题的发布流中， 根据订阅信息列表将发布数据传 递至客户端； 应答接口单元， 与客户端提供的请求相对应， 服务器端的应答接口单元根据客户端发 送的请求报文中的包头信息进行处理， 将请求应答数据回复至对应的客户端主题； 消息透传接口单元， 用于客户端和服务器端之间的全双工消息转发； 链路建立回调处理单元， 用于在与客户端建立链接后通知应用链路创建信息； 请求回调处理单元， 用于监听对应主题下来自客户端的请求； 消息透传接收处理单元， 用于监听对应主题下来自客户端的透传消息； 以及。

5、 客户端配置的组件中， 主题初始化接口单元， 用于通过指明主题号和网络端口地址完成主题初始化的处理， 其中主题号用于使能客户端对应的主题； 订阅接口单元， 用于订阅服务器端对应主题发布的数据； 请求接口单元， 用于往服务器端的对应主题发送请求报文； 消息透传接口单元， 用于客户端和服务器端之间的全双工消息转发； 链路建立回调处理单元， 用于与服务器端建立链接后通知应用链路创建信息； 应答回调处理单元， 用于监听并处理请求至服务器端的请求报文对应的应答数据； 订阅回调处理单元， 用于接收服务器端基于对应主题的发布数据； 消息透传接收处理单元， 用于监听对应主题下来自服务器端的透传消息。 2.根据。

6、权利要求1所述的应用层协议解耦合的通用网络处理系统， 其特征在于， 不同的 主题配置为发布/订阅、 请求/应答、 消息透传的三种通讯方式的任意组合， 服务器端配置的 组件配置为应用层协议解耦合的主题发布、 请求应答、 消息透传， 应用层协议的解耦合的处 理配置为将应用层协议封装至通讯报文体内， 透传至对端， 数据通讯提供应用层协议解耦 合的接口， 只负责协议报文的传输而不限定上层应用的协议报文类型。 3.根据权利要求2所述的应用层协议解耦合的通用网络处理系统， 其特征在于， 请求/ 应答的通讯方式配置为： 请求者请求和对端建立链接后， 在链路上发送自定义的协议的请 求报文至对端的应答者， 其中。

7、请求报文中标记请求者所在的进程的编号、 业务标识、 以及一 个用于请求者/应答者之间基于通讯接口的自定义消息透传的可选项， 其中应用层协议封 装在请求报文体内， 来完成通讯方式和应用层协议的解耦合； 应答者监听链路上是否有请 求报文送达， 根据请求报文的业务标识做相应应答处理， 并将应答内容和应用层协议封装 权利要求书 1/2 页 2 CN 112134915 A 2 至应答报文体中应答返回。 4.根据权利要求3所述的应用层协议解耦合的通用网络处理系统， 其特征在于， 请求/ 应答的通讯方式还配置为： 请求者和应答者之间存在链接已经建立和未建立两种情况， 对于链接已经建立的情 况， 请求者将报。

8、文通过链路会话发往对端， 并以当前时间为标记加入内部应答超时队列， 在 规定时间内若未收到应答者的应答则将该请求报文标记为超时通过初始化设置好的应答 回调反馈至应用层， 同时将该报文从超时检查队列中移除， 在规定时间内若收到应答者的 应答， 则检查应答报文协议中的请求号， 检查在超时检查队列中是否存在该应答对应的请 求报文， 如果存在则发送至应用层并将请求报文从超时检查队列中删除， 如果不存在则不 再处理； 对于链接未建立的情况， 请求者将请求报文加入等待队列中， 若链接建立成功则将等 待队列中的请求报文发往应答者， 若链接建立失败或者超时则清除等待队列中的请求报 文， 并通过回调通知应用层。。

9、 5.根据权利要求2所述的应用层协议解耦合的通用网络处理系统， 其特征在于， 发布/ 订阅的通讯方式配置为： 发布者负责一个指定主题流的发布任务， 订阅者负责接收该主题流下的消息， 发布和 订阅是应用层协议解耦合的， 在基于发布订阅的通讯方式上， 应用层协议封装至消息体内， 应用层收到消息后进行协议解码应用。 6.根据权利要求5所述的应用层协议解耦合的通用网络处理系统， 其特征在于， 发布/ 订阅的通讯方式还配置为： 发布者内部维护一个发布会话列表， 发布会话负责监听通道上的消息， 同时将主题流 消息发布到该通道上， 发布会话读取发布主题流中的消息发送至对应的通道； 订阅者内部维护一个订阅会话。

10、， 订阅会话对应于一个通信通道， 订阅会话负责处理该 通道上的数据， 订阅会话接收通道上的消息并将确认接收的消息写入订阅主题流中； 订阅者启动后根据配置的通道地址通过通道向发布者发送主题订阅请求， 请求中带有 订阅者节点号标识， 其中发布者的发布会话内维护一个订阅者节点列表， 该订阅者节点列 表由一系列订阅者节点组成， 如果订阅者在该通道上发起了主题订阅请求， 发布者在该通 道上的发布会话监听到该请求后， 将根据请求中的订阅者节点号和订阅起始位置新建一个 订阅者节点， 将其加入到订阅者节点列表中； 发布者注册发布通道， 发布者的发布标识列表内有对应于订阅者所订阅主题的发布标 识对象， 发布会话。

11、列表中包含多个对应不同订阅者的节点信息； 发布者内部维护一个发布主题流， 在主题流中每个消息都有一个唯一的消息编号， 当 应用层产生新消息后， 发布者给该新消息分配一个新的消息编号并将该新消息放入主题流 中。 7.根据权利要求2所述的应用层协议解耦合的通用网络处理系统， 其特征在于， 消息透 传的通讯方式配置为： 在链路建立成功后获取到对端的网络节点信息后， 指定特定的会话号， 并将发送内容 装载至网络报文中进行端到端的发送， 对端注册消息回调接口完成数据接收， 如果链路未 建立则对端注册消息回调接口直接报错返回至应用层。 权利要求书 2/2 页 3 CN 112134915 A 3 一种应用。

12、层协议解耦合的通用网络处理系统 技术领域 0001 本发明涉及网络技术领域， 具体涉及一种应用层协议解耦合的通用网络处理， 可 应用于金融交易软件领域。 背景技术 0002 如图1所示， 金融交易系统一般设计成多模块， 一个模块对应一个进程， 如定价模 块、 交易模块、 策略模块等。 各个模块的底层通讯都是常规的TCP/UDP协议， 应用层根据不同 的应用场景， 会存在发布/订阅、 请求/应答、 消息透传等。 不同的场景中， 应用层协议存在差 异， 但都基于相同的底层通讯。 每个模块根据业务流程会划分成不同的主题， 每个主题可通 过发布/订阅和请求/应答等通讯方式完成数据交互。 0003 定价。

13、模块通过网络端口地址对外发布行情数据， 并接受行情快照请求， 称该网络 端口地址为主题A； 策略模块通过网络端口地址对外发布策略交易指令， 标记为主题B； 交易 模块通过网络端口地址对外发布交易结果数据， 标记为主题C。 策略模块需订阅主题A发布 的行情数据， 并且在策略模块启动完成时， 向主题A发送行情快照请求， 来完成行情数据初 始化， 同时策略模块需要订阅主题C发布的交易结果。 交易模块需订阅主题B发布的策略交 易指令， 然后将该指令发送出去。 0004 综上， 每个主题均可提供多种通讯方式， 且每种方式相互隔离和独立， 这样会造成 应用接口复杂多样， 增加了使用成本， 无法适应多种应用。

14、场景下的业务通讯需求。 发明内容 0005 以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。 此概述不是 所有构想到的方面的详尽综览， 并且既非旨在指认出所有方面的关键性或决定性要素亦非 试图界定任何或所有方面的范围。 其唯一的目的是要以简化形式给出一个或多个方面的一 些概念以为稍后给出的更加详细的描述之序。 0006 本发明的目的在于解决上述问题， 提供了一种应用层协议解耦合的通用网络处理 系统， 实现跨进程间基于主题的多种应用层协议解耦合的通讯组件， 通过提供极简化的调 用接口来实现不同应用场景下的业务通讯需求， 降低了使用成本。 0007 本发明的技术方案为： 本发明揭示了一。

15、种应用层协议解耦合的通用网络处理系 统， 系统包括服务器端配置的组件和客户端配置的组件， 服务器端配置的组件包括主题初 始化接口单元、 发布流初始化接口单元、 发布接口单元、 应答接口单元、 消息透传接口单元、 链路建立回调处理单元、 请求回调处理单元、 消息透传接收处理单元， 客户端配置的组件包 括主题初始化接口单元、 订阅接口单元、 请求接口单元、 消息透传接口单元、 链路建立回调 处理单元、 应答回调处理单元、 订阅回调处理单元、 消息透传接收处理单元， 其中： 0008 服务器端配置的组件中， 0009 主题初始化接口单元， 通过指明主题号和网络端口地址进行初始化处理， 其中主 题号用。

16、于使能服务器端对应的主题； 说明书 1/8 页 4 CN 112134915 A 4 0010 发布流初始化接口单元， 用于对主题在服务器端的发布流的初始化处理； 0011 发布接口单元， 将发布数据传送至主题的发布流中， 根据订阅信息列表将发布数 据传递至客户端； 0012 应答接口单元， 与客户端提供的请求相对应， 服务器端的应答接口单元根据客户 端发送的请求报文中的包头信息进行处理， 将请求应答数据回复至对应的客户端主题； 0013 消息透传接口单元， 用于客户端和服务器端之间的全双工消息转发； 0014 链路建立回调处理单元， 用于在与客户端建立链接后通知应用链路创建信息； 0015 。

17、请求回调处理单元， 用于监听对应主题下来自客户端的请求； 0016 消息透传接收处理单元， 用于监听对应主题下来自客户端的透传消息； 以及 0017 客户端配置的组件中， 0018 主题初始化接口单元， 用于通过指明主题号和网络端口地址完成主题初始化的处 理， 其中主题号用于使能客户端对应的主题； 0019 订阅接口单元， 用于订阅服务器端对应主题发布的数据； 0020 请求接口单元， 用于往服务器端的对应主题发送请求报文； 0021 消息透传接口单元， 用于客户端和服务器端之间的全双工消息转发； 0022 链路建立回调处理单元， 用于与服务器端建立链接后通知应用链路创建信息； 0023 应答。

18、回调处理单元， 用于监听并处理请求至服务器端的请求报文对应的应答数 据； 0024 订阅回调处理单元， 用于接收服务器端基于对应主题的发布数据； 0025 消息透传接收处理单元， 用于监听对应主题下来自服务器端的透传消息。 0026 根据本发明的应用层协议解耦合的通用网络处理系统的一实施例， 不同的主题配 置为发布/订阅、 请求/应答、 消息透传的三种通讯方式的任意组合， 服务器端配置的组件配 置为应用层协议解耦合的主题发布、 请求应答、 消息透传， 应用层协议的解耦合的处理配置 为将应用层协议封装至通讯报文体内， 透传至对端， 数据通讯提供应用层协议解耦合的接 口， 只负责协议报文的传输而不。

19、限定上层应用的协议报文类型。 0027 根据本发明的应用层协议解耦合的通用网络处理系统的一实施例， 请求/应答的 通讯方式配置为： 请求者请求和对端建立链接后， 在链路上发送自定义的协议的请求报文 至对端的应答者， 其中请求报文中标记请求者所在的进程的编号、 业务标识、 以及一个用于 请求者/应答者之间基于通讯接口的自定义消息透传的可选项， 其中应用层协议封装在请 求报文体内， 来完成通讯方式和应用层协议的解耦合； 应答者监听链路上是否有请求报文 送达， 根据请求报文的业务标识做相应应答处理， 并将应答内容和应用层协议封装至应答 报文体中应答返回。 0028 根据本发明的应用层协议解耦合的通用。

20、网络处理系统的一实施例， 请求/应答的 通讯方式还配置为： 0029 请求者和应答者之间存在链接已经建立和未建立两种情况， 对于链接已经建立的 情况， 请求者将报文通过链路会话发往对端， 并以当前时间为标记加入内部应答超时队列， 在规定时间内若未收到应答者的应答则将该请求报文标记为超时通过初始化设置好的应 答回调反馈至应用层， 同时将该报文从超时检查队列中移除， 在规定时间内若收到应答者 的应答， 则检查应答报文协议中的请求号， 检查在超时检查队列中是否存在该应答对应的 说明书 2/8 页 5 CN 112134915 A 5 请求报文， 如果存在则发送至应用层并将请求报文从超时检查队列中删除。

21、， 如果不存在则 不再处理； 0030 对于链接未建立的情况， 请求者将请求报文加入等待队列中， 若链接建立成功则 将等待队列中的请求报文发往应答者， 若链接建立失败或者超时则清除等待队列中的请求 报文， 并通过回调通知应用层。 0031 根据本发明的应用层协议解耦合的通用网络处理系统的一实施例， 发布/订阅的 通讯方式配置为： 0032 发布者负责一个指定主题流的发布任务， 订阅者负责接收该主题流下的消息， 发 布和订阅是应用层协议解耦合的， 在基于发布订阅的通讯方式上， 应用层协议封装至消息 体内， 应用层收到消息后进行协议解码应用。 0033 根据本发明的应用层协议解耦合的通用网络处理系。

22、统的一实施例， 根据本发明的 应用层协议解耦合的通用网络处理系统的一实施例， 发布/订阅的通讯方式还配置为： 0034 发布者内部维护一个发布会话列表， 发布会话负责监听通道上的消息， 同时将主 题流消息发布到该通道上， 发布会话读取发布主题流中的消息发送至对应的通道； 0035 订阅者内部维护一个订阅会话， 订阅会话对应于一个通信通道， 订阅会话负责处 理该通道上的数据， 订阅会话接收通道上的消息并将确认接收的消息写入订阅主题流中； 0036 订阅者启动后根据配置的通道地址通过通道向发布者发送主题订阅请求， 请求中 带有订阅者节点号标识， 其中发布者的发布会话内维护一个订阅者节点列表， 该订。

23、阅者节 点列表由一系列订阅者节点组成， 如果订阅者在该通道上发起了主题订阅请求， 发布者在 该通道上的发布会话监听到该请求后， 将根据请求中的订阅者节点号和订阅起始位置新建 一个订阅者节点， 将其加入到订阅者节点列表中； 0037 发布者注册发布通道， 发布者的发布标识列表内有对应于订阅者所订阅主题的发 布标识对象， 发布会话列表中包含多个对应不同订阅者的节点信息； 0038 发布者内部维护一个发布主题流， 在主题流中每个消息都有一个唯一的消息编 号， 当应用层产生新消息后， 发布者给该新消息分配一个新的消息编号并将该新消息放入 主题流中。 0039 根据本发明的应用层协议解耦合的通用网络处理。

24、系统的一实施例， 消息透传的通 讯方式配置为： 0040 在链路建立成功后获取到对端的网络节点信息后， 指定特定的会话号， 并将发送 内容装载至网络报文中进行端到端的发送， 对端注册消息回调接口完成数据接收， 如果链 路未建立则对端注册消息回调接口直接报错返回至应用层。 0041 本发明对比现有技术有如下的有益效果： 本发明系统中的协议解耦合可根据场景 随意组合， 同一个主题可以提供多种通讯方式并根据特定的场景进行随意组合， 且可以基 于该组件简单方便的开发各种上层业务应用。 此外， 本发明的系统实现统一封装， 服务器端 和客户端可以初始化若干个主题， 每个主题之间相互独立， 接口仅需指明主题。

25、号， 由系统完 成接口匹配。 本发明系统的应用接口单一且极为简化， 使用成本极小。 附图说明 0042 在结合以下附图阅读本公开的实施例的详细描述之后， 能够更好地理解本发明的 说明书 3/8 页 6 CN 112134915 A 6 上述特征和优点。 在附图中， 各组件不一定是按比例绘制， 并且具有类似的相关特性或特征 的组件可能具有相同或相近的附图标记。 0043 图1示出了现有的金融交易系统的实现原理的示意图。 0044 图2示出了应用层三种通讯场景之一的请求/应答通讯方式的原理示意图。 0045 图3示出了应用层三种通讯场景之一的请求/应答通讯方式的任务流程图。 0046 图4示出了应。

26、用层三种通讯场景之一的发布/订阅通讯方式的原理示意图。 0047 图5示出了应用层三种通讯场景之一的发布/订阅通讯方式的任务流程图。 0048 图6示出了应用层三种通讯场景之一的消息透传方式的任务流程图 0049 图7和图8示出了本发明的金融交易系统的一实施例的原理图。 具体实施方式 0050 以下结合附图和具体实施例对本发明作详细描述。 注意， 以下结合附图和具体实 施例描述的诸方面仅是示例性的， 而不应被理解为对本发明的保护范围进行任何限制。 0051 在介绍本发明的实施例的实现方案之前， 首先对应用层协议通讯的基本概念进行 说明。 跨进程的网络传输中， 根据不同的业务场景， 衍生出不同的。

27、通讯方式， 诸如发布/订 阅、 请求/应答、 消息透传等通讯方式。 0052 (1)主题(topic_id) 0053 网络通讯的进程， 根据其业务结构需要从其他模块请求数据或者往其他模块发送 数据， 也会从其他模块订阅数据或者向其他模块发布数据。 把网络主体中发布/订阅和请 求/应答归为主题(主题是根据业务数据类型做归类的， 跟具体通讯方式没有直接关系。 根 据业务数据类型将数据划分为多个主题， 每个主题上可以使用三种通讯方式， 每个主题有 用一个网络地址)， 如发布数据者通过该主题发布数据， 订阅数据者通过该主题订阅数据。 0054 (2)主题流(flow) 0055 主题流(flow)描。

28、述了消息的组织形式。 在传输通讯组件中， 每一个被传输的消息 都必须有一个所属的主题， 同一个主题下的各个消息形成了一个消息主题流。 主题流内的 消息是有序的， 可以理解为是一类消息形成的队列。 0056 (3)回调(callback) 0057 回调函数就是一个通过函数指针调用的函数。 把函数的指针(地址)作为参数传递 给另一个函数， 当这个指针被用例调用其所指向的函数时， 称之为回调函数。 一般通讯主体 向应用层传递数据， 会通过回调函数完成， 如订阅对方发布的数据， 可以传入一个订阅的回 调函数， 当对方发布数据后， 本方的订阅回调函数会被执行， 应用层获取并解析数据， 完成 相应的业务。

29、处理。 0058 (4)节点信息(message_node) 0059 网络链路建立后， 会话号(session_id)、 节点号(每个节点即一个Linux应用进 程)、 请求消息号msg_id(应用层业务标识号)和网络地址等等， 这些信息封装成message_ node。 0060 图7示出了本发明的金融交易系统的一实施例的原理， 本实施例的系统包括服务 器端配置的组件和客户端配置的组件。 0061 服务器端配置的组件配置为协议解耦合的主题发布、 请求应答、 消息透传， 其中发 说明书 4/8 页 7 CN 112134915 A 7 布是指提供基于主题的发布， 请求应答是提供基于主题的应答。

30、， 消息透传模块是提供基于 主题的消息透传。 由于基于主题的三种通讯方式(发布/订阅、 请求/应答、 消息透传)均可实 现端到端(服务器端和客户端之间)的数据传送， 是根据不同的应用场景选取合适的通讯方 式来完成业务实现。 不管是哪种通讯方式， 系统的应用层协议需要解耦合， 通讯方式不考虑 应用层协议的具体实现， 通讯方式仅仅是一个传输通道。 因此， 本发明的系统将应用层协议 封装至通讯报文体内， 透传至对端， 数据通讯提供应用层协议解耦合的接口， 不关乎协议的 具体实现， 只负责协议报文的传输， 不管上层应用哪种协议报文。 0062 服务器端管理提供数据的主题集， 主题集包含多个主题(图示为。

31、3个主题)， 每一个 主题可包含一种到三种通讯方式， 其中每种通讯方式的使用是独立的， 且相互之间不存在 依赖关系。 0063 举例来说， 主题1被设计成可对外发布数据和处理请求， 所以在主题1上包含前面 接收的发布/订阅和请求/应答这2种通讯方式， 主题2则同时包含发布/订阅、 请求/应答和 消息透传三种通讯方式， 主题3仅包含对外消息透传这一种通讯方式。 0064 应用层的上述三种通讯场景(发布/订阅、 请求/应答和消息透传)的实现方式详述 如下。 0065 请求/应答的实现原理如图2所示， 任务流程如图3所示， 请同时参见图2和图3， 请 求/应答(requester/responser。

32、)通讯场景是一种一对一的同步通讯方式， 请求者 (requester)请求和对端建立链接后， 在该链路上发送自定义的协议的请求报文至对端， 即 应答者(responser)。 请求报文中的node_id标记请求者所在的进程的编号， msg_id用于业 务标识， context是一个可选项， 用于请求者/应答者之间基于通讯接口的自定义消息透传。 应用层协议封装在请求报文体内， 来完成通讯方式和应用层协议的解耦合。 应答者 (responser)监听链路上是否有请求报文送达， 根据请求报文的msg_id做相应应答处理， 并 将应答内容和应用层协议封装至应答报文体中应答返回。 0066 reques。

33、ter和responser之间存在链接已经建立和未建立两种情况。 对于链接已经 建立的情况， requester将报文通过链路会话发往对端， 并以当前时间为标记加入内部应答 超时队列， 在规定时间内若未收到responser的应答则将该请求报文标记为超时通过初始 化设置好的应答回调反馈至应用层， 同时将该报文从超时检查队列中移除。 在规定时间内 若收到responser的应答， 则检查应答报文协议中的请求号， 检查在超时检查队列中是否存 在该应答对应的请求报文， 如果存在则通过应答回调函数发送至应用层， 并将请求报文从 超时检查队列中删除。 如果不存在， 则说明已经超时或者是重复的应答， 都不。

34、再处理。 0067 对于链接未建立的情况， requester将请求报文加入等待队列中， 若链接建立成功 则将等待队列中的请求报文发往responser， 若链接建立失败或者超时则清除等待队列中 的请求报文， 并通过回调通知应用层。 一般这种情况， 应用层可以通过链路建立回调函数来 确定， 链接已经建立， 再发请求。 0068 发布/订阅的实现原理如图4所示， 任务流程如图5所示， 发布/订阅(publisher/ subscriber)通讯场景是一种一对多的异步通讯方式， 发布者负责一个指定主题流的发布 任务， 订阅者负责接收该主题流下的消息。 发布和订阅也是应用层协议解耦合的， 在基于发 。

35、布订阅的通讯方式上， 应用层协议封装至消息体内， 应用层收到消息后进行协议解码应用。 0069 发布者内部维护了一个发布会话(PubSession)列表， 发布会话负责监听通道上的 说明书 5/8 页 8 CN 112134915 A 8 消息， 同时将主题流消息发布到该通道上。 发布会话读取发布主题流中的消息发送至对应 的通道。 0070 subscriber内部维护了一个订阅会话(SubSession)， 订阅会话对应于一个通信通 道， 订阅会话负责处理该通道上的数据。 订阅会话接收通道上的消息， 并将确认接收的消息 写入订阅主题流中。 0071 subscriber启动后， 根据配置的通。

36、道地址， 通过通道向发布者发送主题订阅请求， 请求中带有订阅者节点号标识。 发布者的发布会话内维护一个订阅者节点列表， 该列表由 一系列订阅者节点(Node)组成。 如果订阅者在该通道上发起了主题订阅请求， 发布者在该 通道上的发布会话监听到该请求后， 将根据请求中的订阅者节点号和订阅起始位置新建一 个订阅者节点， 将其加入到订阅者节点列表中。 此外， 发布者还维护一份发布标识列表， 该 列表由一系列的发布标识(PubFlag)组成， 每个发布标识对象对应于一个订阅者， 用于实时 记录针对该订阅者的数据发布情况。 0072 在图4的示例中， 发布者注册了发布通道。 有两个订阅者订阅该主题流， 。

37、因此发布 者的发布标识列表内有两个PubFlag对象。 PubSession中包含两个节点信息， 即订阅者1和 订阅者2。 0073 发布者内部维护了一个发布主题流， 主题流是一个线程安全的消息队列。 在主题 流中， 每个消息都有一个唯一的消息编号Seqno， Seqno从0开始递增编号。 当应用层产生新 消息后， 发布者给这个消息分配一个新的Seqno， 并将该消息放入主题流中。 0074 消息透传的任务流程如图6所示， 消息透传模式和请求/应答模式都是一对一的通 讯模式， 较请求/应答模式最大的区别在于， 消息透传模式， 不需要应答， 且通讯双方相互之 间在链接建立后都可以进行消息透传， 。

38、链路上传递的消息一般可以是本端的状态更新或者 无需相应的通知等等。 基于消息透传方式， 应用层可以自定义各种协议， 通过该方式来完成 业务逻辑。 如A和B两个通讯主体需要相互发心跳， 那么可以自定义心跳协议通过消息传送 方式进行交互， 收到报文后， 根据心跳协议进行解码， 并做相应处理。 0075 在实现上， 消息透传模式仅在链路建立成功后， 获取到对端的网络节点信息后， 指 定特定的会话号(session_id)， 并将发送内容装载至网络报文中进行端到端的发送， 对端 注册消息回调接口即可完成数据接收。 如果链路未建立， 则对端注册消息回调接口直接报 错返回至应用层。 0076 如图8所示，。

39、 服务器端配置的组件包括多个接口单元和多个回调处理单元， 其中， 多个接口单元包括主题初始化接口单元、 发布流初始化接口单元、 发布接口单元、 应答接口 单元、 消息透传接口单元。 0077 多个回调处理单元包括链路建立回调处理单元、 请求回调处理单元、 消息透传接 收处理单元。 0078 主题初始化接口单元通过指明主题号和网络端口地址进行初始化处理， 其中主题 号用于使能服务器端对应的主题。 0079 发布流初始化接口单元完成对主题在服务器端的发布流的初始化处理。 0080 链路建立回调处理单元在与客户端建立链接后， 通过用户设置的回调函数通知应 用链路创建信息， 比如可收集客户端的mess。

40、age_node信息等。 0081 请求回调处理单元是通过在应用层设置回调函数监听对应主题下来自客户端的 说明书 6/8 页 9 CN 112134915 A 9 请求。 解析请求的message_node可确定客户端的session_id和msg_id， 并根据msg_id进行 相关处理， 将结果发送至session_id对应的客户端。 0082 消息透传接收回调处理单元是通过在应用层设置回调函数来监听对应主题下来 自客户端的透传消息。 0083 发布接口单元是将发布数据传送至主题的发布流中， 根据订阅信息列表将发布数 据传递至客户端。 0084 应答接口单元与客户端提供的请求相对应， 服务。

41、器端的应答接口单元根据客户端 发送的请求报文中的包头信息进行处理， 将请求应答数据回复至对应的客户端主题。 0085 消息透传接口单元， 用于客户端和服务器端之间的全双工消息转发。 0086 客户端配置的组件成为对各主题数据的获取方， 通过订阅、 请求方式获取服务器 端数据， 或者往服务器端透传数据。 0087 客户端配置的组件进一步包括多个接口单元和多个回调处理单元。 其中多个接口 单元包括主题初始化接口单元、 请求接口单元、 订阅接口单元、 消息透传接口单元， 多个回 调处理单元包括链路建立回调处理单元、 应答回调处理单元、 订阅回调处理单元、 消息透传 接收处理单元。 0088 主题初始。

42、化接口单元用于通过指明主题号和网络端口地址完成主题初始化的处 理， 其中主题号用于使能客户端对应的主题。 0089 请求接口单元用于往服务器端的对应主题发送请求报文， 例如配置函数request (topicid,msg_id,void*context)， 其中msg_id为业务标识， context是应用层自定义数据， 会通过服务器端的应答接口单元原样返回。 0090 订阅接口单元用于订阅服务器端对应主题发布的数据， 例如配置函数subscribe (topicid)， 其中topicid为主题号。 0091 消息透传接口单元， 用于客户端和服务器端之间的全双工消息转发。 0092 链路建立。

43、回调处理单元用于与服务器端建立链接后， 通过用户设置的回调函数通 知应用链路创建信息， 比如可收集服务器端的message_node信息。 0093 应答回调处理单元用于通过设置的回调函数， 监听并处理请求至服务器端的请求 报文对应的应答数据。 0094 订阅回调处理单元用于通过在应用层设置的回调函数接收服务器端基于对应主 题的发布数据。 0095 消息透传接收回调处理单元用于在应用层设置的回调函数监听对应主题下来自 服务器端的透传消息。 0096 尽管为使解释简单化将上述方法图示并描述为一系列动作， 但是应理解并领会， 这些方法不受动作的次序所限， 因为根据一个或多个实施例， 一些动作可按不。

44、同次序发生 和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他 动作并发地发生。 0097 本领域技术人员将进一步领会， 结合本文中所公开的实施例来描述的各种解说性 逻辑板块、 模块、 电路、 和算法步骤可实现为电子硬件、 计算机软件、 或这两者的组合。 为清 楚地解说硬件与软件的这一可互换性， 各种解说性组件、 框、 模块、 电路、 和步骤在上面是以 其功能性的形式作一般化描述的。 此类功能性是被实现为硬件还是软件取决于具体应用和 说明书 7/8 页 10 CN 112134915 A 10 施加于整体系统的设计约束。 技术人员对于每种特定应用可用不同的方式来实现。

45、所描述的 功能性， 但这样的实现决策不应被解读成导致脱离了本发明的范围。 0098 结合本文所公开的实施例描述的各种解说性逻辑板块、 模块、 和电路可用通用处 理器、 数字信号处理器(DSP)、 专用集成电路(ASIC)、 现场可编程门阵列(FPGA)或其它可编 程逻辑器件、 分立的门或晶体管逻辑、 分立的硬件组件、 或其设计成执行本文所描述功能的 任何组合来实现或执行。 通用处理器可以是微处理器， 但在替换方案中， 该处理器可以是任 何常规的处理器、 控制器、 微控制器、 或状态机。 处理器还可以被实现为计算设备的组合， 例 如DSP与微处理器的组合、 多个微处理器、 与DSP核心协作的一个。

46、或多个微处理器、 或任何其 他此类配置。 0099 结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、 在由处理器 执行的软件模块中、 或在这两者的组合中体现。 软件模块可驻留在RAM存储器、 闪存、 ROM存 储器、 EPROM存储器、 EEPROM存储器、 寄存器、 硬盘、 可移动盘、 CD-ROM、 或本领域中所知的任 何其他形式的存储介质中。 示例性存储介质耦合到处理器以使得该处理器能从/向该存储 介质读取和写入信息。 在替换方案中， 存储介质可以被整合到处理器。 处理器和存储介质可 驻留在ASIC中。 ASIC可驻留在用户终端中。 在替换方案中， 处理器和存储介质可作为分立。

47、组 件驻留在用户终端中。 0100 在一个或多个示例性实施例中， 所描述的功能可在硬件、 软件、 固件或其任何组合 中实现。 如果在软件中实现为计算机程序产品， 则各功能可以作为一条或更多条指令或代 码存储在计算机可读介质上或藉其进行传送。 计算机可读介质包括计算机存储介质和通信 介质两者， 其包括促成计算机程序从一地向另一地转移的任何介质。 存储介质可以是能被 计算机访问的任何可用介质。 作为示例而非限定， 这样的计算机可读介质可包括RAM、 ROM、 EEPROM、 CD-ROM或其它光盘存储、 磁盘存储或其它磁存储设备、 或能被用来携带或存储指令 或数据结构形式的合意程序代码且能被计算机。

48、访问的任何其它介质。 任何连接也被正当地 称为计算机可读介质。 例如， 如果软件是使用同轴电缆、 光纤电缆、 双绞线、 数字订户线 (DSL)、 或诸如红外、 无线电、 以及微波之类的无线技术从web网站、 服务器、 或其它远程源传 送而来， 则该同轴电缆、 光纤电缆、 双绞线、 DSL、 或诸如红外、 无线电、 以及微波之类的无线 技术就被包括在介质的定义之中。 如本文中所使用的盘(disk)和碟(disc)包括压缩碟 (CD)、 激光碟、 光碟、 数字多用碟(DVD)、 软盘和蓝光碟， 其中盘(disk)往往以磁的方式再现 数据， 而碟(disc)用激光以光学方式再现数据。 上述的组合也应。

49、被包括在计算机可读介质 的范围内。 0101 提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公 开。 对本公开的各种修改对本领域技术人员来说都将是显而易见的， 且本文中所定义的普 适原理可被应用到其他变体而不会脱离本公开的精神或范围。 由此， 本公开并非旨在被限 定于本文中所描述的示例和设计， 而是应被授予与本文中所公开的原理和新颖性特征相一 致的最广范围。 说明书 8/8 页 11 CN 112134915 A 11 图1 图2 说明书附图 1/7 页 12 CN 112134915 A 12 图3 说明书附图 2/7 页 13 CN 112134915 A 13 图4 说明书附图 3/7 页 14 CN 112134915 A 14 图5 说明书附图 4/7 页 15 CN 112134915 A 15 图6 说明书附图 5/7 页 16 CN 112134915 A 16 图7 说明书附图 6/7 页 17 CN 112134915 A 17 图8 说明书附图 7/7 页 18 CN 112134915 A 18 。