CN112134915A - 一种应用层协议解耦合的通用网络处理系统 - Google Patents

Abstract

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

Description

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

技术领域

本发明涉及网络技术领域，具体涉及一种应用层协议解耦合的通用网络处理，可应用于金融交易软件领域。

背景技术

如图1所示，金融交易系统一般设计成多模块，一个模块对应一个进程，如定价模块、交易模块、策略模块等。各个模块的底层通讯都是常规的TCP/UDP协议，应用层根据不同的应用场景，会存在发布/订阅、请求/应答、消息透传等。不同的场景中，应用层协议存在差异，但都基于相同的底层通讯。每个模块根据业务流程会划分成不同的主题，每个主题可通过发布/订阅和请求/应答等通讯方式完成数据交互。

定价模块通过网络端口地址对外发布行情数据，并接受行情快照请求，称该网络端口地址为主题A；策略模块通过网络端口地址对外发布策略交易指令，标记为主题B；交易模块通过网络端口地址对外发布交易结果数据，标记为主题C。策略模块需订阅主题A发布的行情数据，并且在策略模块启动完成时，向主题A发送行情快照请求，来完成行情数据初始化，同时策略模块需要订阅主题C发布的交易结果。交易模块需订阅主题B发布的策略交易指令，然后将该指令发送出去。

综上，每个主题均可提供多种通讯方式，且每种方式相互隔离和独立，这样会造成应用接口复杂多样，增加了使用成本，无法适应多种应用场景下的业务通讯需求。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明的目的在于解决上述问题，提供了一种应用层协议解耦合的通用网络处理系统，实现跨进程间基于主题的多种应用层协议解耦合的通讯组件，通过提供极简化的调用接口来实现不同应用场景下的业务通讯需求，降低了使用成本。

本发明的技术方案为：本发明揭示了一种应用层协议解耦合的通用网络处理系统，系统包括服务器端配置的组件和客户端配置的组件，服务器端配置的组件包括主题初始化接口单元、发布流初始化接口单元、发布接口单元、应答接口单元、消息透传接口单元、链路建立回调处理单元、请求回调处理单元、消息透传接收处理单元，客户端配置的组件包括主题初始化接口单元、订阅接口单元、请求接口单元、消息透传接口单元、链路建立回调处理单元、应答回调处理单元、订阅回调处理单元、消息透传接收处理单元，其中：

服务器端配置的组件中，

主题初始化接口单元，通过指明主题号和网络端口地址进行初始化处理，其中主题号用于使能服务器端对应的主题；

发布流初始化接口单元，用于对主题在服务器端的发布流的初始化处理；

发布接口单元，将发布数据传送至主题的发布流中，根据订阅信息列表将发布数据传递至客户端；

应答接口单元，与客户端提供的请求相对应，服务器端的应答接口单元根据客户端发送的请求报文中的包头信息进行处理，将请求应答数据回复至对应的客户端主题；

消息透传接口单元，用于客户端和服务器端之间的全双工消息转发；

链路建立回调处理单元，用于在与客户端建立链接后通知应用链路创建信息；

请求回调处理单元，用于监听对应主题下来自客户端的请求；

消息透传接收处理单元，用于监听对应主题下来自客户端的透传消息；以及

客户端配置的组件中，

主题初始化接口单元，用于通过指明主题号和网络端口地址完成主题初始化的处理，其中主题号用于使能客户端对应的主题；

订阅接口单元，用于订阅服务器端对应主题发布的数据；

请求接口单元，用于往服务器端的对应主题发送请求报文；

消息透传接口单元，用于客户端和服务器端之间的全双工消息转发；

链路建立回调处理单元，用于与服务器端建立链接后通知应用链路创建信息；

应答回调处理单元，用于监听并处理请求至服务器端的请求报文对应的应答数据；

订阅回调处理单元，用于接收服务器端基于对应主题的发布数据；

消息透传接收处理单元，用于监听对应主题下来自服务器端的透传消息。

根据本发明的应用层协议解耦合的通用网络处理系统的一实施例，不同的主题配置为发布/订阅、请求/应答、消息透传的三种通讯方式的任意组合，服务器端配置的组件配置为应用层协议解耦合的主题发布、请求应答、消息透传，应用层协议的解耦合的处理配置为将应用层协议封装至通讯报文体内，透传至对端，数据通讯提供应用层协议解耦合的接口，只负责协议报文的传输而不限定上层应用的协议报文类型。

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

根据本发明的应用层协议解耦合的通用网络处理系统的一实施例，请求/应答的通讯方式还配置为：

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

对于链接未建立的情况，请求者将请求报文加入等待队列中，若链接建立成功则将等待队列中的请求报文发往应答者，若链接建立失败或者超时则清除等待队列中的请求报文，并通过回调通知应用层。

根据本发明的应用层协议解耦合的通用网络处理系统的一实施例，发布/订阅的通讯方式配置为：

发布者负责一个指定主题流的发布任务，订阅者负责接收该主题流下的消息，发布和订阅是应用层协议解耦合的，在基于发布订阅的通讯方式上，应用层协议封装至消息体内，应用层收到消息后进行协议解码应用。

根据本发明的应用层协议解耦合的通用网络处理系统的一实施例，根据本发明的应用层协议解耦合的通用网络处理系统的一实施例，发布/订阅的通讯方式还配置为：

发布者内部维护一个发布会话列表，发布会话负责监听通道上的消息，同时将主题流消息发布到该通道上，发布会话读取发布主题流中的消息发送至对应的通道；

订阅者内部维护一个订阅会话，订阅会话对应于一个通信通道，订阅会话负责处理该通道上的数据，订阅会话接收通道上的消息并将确认接收的消息写入订阅主题流中；

订阅者启动后根据配置的通道地址通过通道向发布者发送主题订阅请求，请求中带有订阅者节点号标识，其中发布者的发布会话内维护一个订阅者节点列表，该订阅者节点列表由一系列订阅者节点组成，如果订阅者在该通道上发起了主题订阅请求，发布者在该通道上的发布会话监听到该请求后，将根据请求中的订阅者节点号和订阅起始位置新建一个订阅者节点，将其加入到订阅者节点列表中；

发布者注册发布通道，发布者的发布标识列表内有对应于订阅者所订阅主题的发布标识对象，发布会话列表中包含多个对应不同订阅者的节点信息；

发布者内部维护一个发布主题流，在主题流中每个消息都有一个唯一的消息编号，当应用层产生新消息后，发布者给该新消息分配一个新的消息编号并将该新消息放入主题流中。

根据本发明的应用层协议解耦合的通用网络处理系统的一实施例，消息透传的通讯方式配置为：

在链路建立成功后获取到对端的网络节点信息后，指定特定的会话号，并将发送内容装载至网络报文中进行端到端的发送，对端注册消息回调接口完成数据接收，如果链路未建立则对端注册消息回调接口直接报错返回至应用层。

本发明对比现有技术有如下的有益效果：本发明系统中的协议解耦合可根据场景随意组合，同一个主题可以提供多种通讯方式并根据特定的场景进行随意组合，且可以基于该组件简单方便的开发各种上层业务应用。此外，本发明的系统实现统一封装，服务器端和客户端可以初始化若干个主题，每个主题之间相互独立，接口仅需指明主题号，由系统完成接口匹配。本发明系统的应用接口单一且极为简化，使用成本极小。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1示出了现有的金融交易系统的实现原理的示意图。

图2示出了应用层三种通讯场景之一的请求/应答通讯方式的原理示意图。

图3示出了应用层三种通讯场景之一的请求/应答通讯方式的任务流程图。

图4示出了应用层三种通讯场景之一的发布/订阅通讯方式的原理示意图。

图5示出了应用层三种通讯场景之一的发布/订阅通讯方式的任务流程图。

图6示出了应用层三种通讯场景之一的消息透传方式的任务流程图

图7和图8示出了本发明的金融交易系统的一实施例的原理图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

在介绍本发明的实施例的实现方案之前，首先对应用层协议通讯的基本概念进行说明。跨进程的网络传输中，根据不同的业务场景，衍生出不同的通讯方式，诸如发布/订阅、请求/应答、消息透传等通讯方式。

(1)主题(topic_id)

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

(2)主题流(flow)

主题流(flow)描述了消息的组织形式。在传输通讯组件中，每一个被传输的消息都必须有一个所属的主题，同一个主题下的各个消息形成了一个消息主题流。主题流内的消息是有序的，可以理解为是一类消息形成的队列。

(3)回调(callback)

回调函数就是一个通过函数指针调用的函数。把函数的指针(地址)作为参数传递给另一个函数，当这个指针被用例调用其所指向的函数时，称之为回调函数。一般通讯主体向应用层传递数据，会通过回调函数完成，如订阅对方发布的数据，可以传入一个订阅的回调函数，当对方发布数据后，本方的订阅回调函数会被执行，应用层获取并解析数据，完成相应的业务处理。

(4)节点信息(message_node)

网络链路建立后，会话号(session_id)、节点号(每个节点即一个Linux应用进程)、请求消息号msg_id(应用层业务标识号)和网络地址等等，这些信息封装成message_node。

图7示出了本发明的金融交易系统的一实施例的原理，本实施例的系统包括服务器端配置的组件和客户端配置的组件。

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

服务器端管理提供数据的主题集，主题集包含多个主题(图示为3个主题)，每一个主题可包含一种到三种通讯方式，其中每种通讯方式的使用是独立的，且相互之间不存在依赖关系。

举例来说，主题1被设计成可对外发布数据和处理请求，所以在主题1上包含前面接收的发布/订阅和请求/应答这2种通讯方式，主题2则同时包含发布/订阅、请求/应答和消息透传三种通讯方式，主题3仅包含对外消息透传这一种通讯方式。

应用层的上述三种通讯场景(发布/订阅、请求/应答和消息透传)的实现方式详述如下。

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

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

对于链接未建立的情况，requester将请求报文加入等待队列中，若链接建立成功则将等待队列中的请求报文发往responser，若链接建立失败或者超时则清除等待队列中的请求报文，并通过回调通知应用层。一般这种情况，应用层可以通过链路建立回调函数来确定，链接已经建立，再发请求。

发布/订阅的实现原理如图4所示，任务流程如图5所示，发布/订阅(publisher/subscriber)通讯场景是一种一对多的异步通讯方式，发布者负责一个指定主题流的发布任务，订阅者负责接收该主题流下的消息。发布和订阅也是应用层协议解耦合的，在基于发布订阅的通讯方式上，应用层协议封装至消息体内，应用层收到消息后进行协议解码应用。

发布者内部维护了一个发布会话(PubSession)列表，发布会话负责监听通道上的消息，同时将主题流消息发布到该通道上。发布会话读取发布主题流中的消息发送至对应的通道。

subscriber内部维护了一个订阅会话(SubSession)，订阅会话对应于一个通信通道，订阅会话负责处理该通道上的数据。订阅会话接收通道上的消息，并将确认接收的消息写入订阅主题流中。

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

在图4的示例中，发布者注册了发布通道。有两个订阅者订阅该主题流，因此发布者的发布标识列表内有两个PubFlag对象。PubSession中包含两个节点信息，即订阅者1和订阅者2。

发布者内部维护了一个发布主题流，主题流是一个线程安全的消息队列。在主题流中，每个消息都有一个唯一的消息编号Seqno，Seqno从0开始递增编号。当应用层产生新消息后，发布者给这个消息分配一个新的Seqno，并将该消息放入主题流中。

消息透传的任务流程如图6所示，消息透传模式和请求/应答模式都是一对一的通讯模式，较请求/应答模式最大的区别在于，消息透传模式，不需要应答，且通讯双方相互之间在链接建立后都可以进行消息透传，链路上传递的消息一般可以是本端的状态更新或者无需相应的通知等等。基于消息透传方式，应用层可以自定义各种协议，通过该方式来完成业务逻辑。如A和B两个通讯主体需要相互发心跳，那么可以自定义心跳协议通过消息传送方式进行交互，收到报文后，根据心跳协议进行解码，并做相应处理。

在实现上，消息透传模式仅在链路建立成功后，获取到对端的网络节点信息后，指定特定的会话号(session_id)，并将发送内容装载至网络报文中进行端到端的发送，对端注册消息回调接口即可完成数据接收。如果链路未建立，则对端注册消息回调接口直接报错返回至应用层。

如图8所示，服务器端配置的组件包括多个接口单元和多个回调处理单元，其中，多个接口单元包括主题初始化接口单元、发布流初始化接口单元、发布接口单元、应答接口单元、消息透传接口单元。

多个回调处理单元包括链路建立回调处理单元、请求回调处理单元、消息透传接收处理单元。

主题初始化接口单元通过指明主题号和网络端口地址进行初始化处理，其中主题号用于使能服务器端对应的主题。

发布流初始化接口单元完成对主题在服务器端的发布流的初始化处理。

链路建立回调处理单元在与客户端建立链接后，通过用户设置的回调函数通知应用链路创建信息，比如可收集客户端的message_node信息等。

请求回调处理单元是通过在应用层设置回调函数监听对应主题下来自客户端的请求。解析请求的message_node可确定客户端的session_id和msg_id，并根据msg_id进行相关处理，将结果发送至session_id对应的客户端。

消息透传接收回调处理单元是通过在应用层设置回调函数来监听对应主题下来自客户端的透传消息。

发布接口单元是将发布数据传送至主题的发布流中，根据订阅信息列表将发布数据传递至客户端。

应答接口单元与客户端提供的请求相对应，服务器端的应答接口单元根据客户端发送的请求报文中的包头信息进行处理，将请求应答数据回复至对应的客户端主题。

消息透传接口单元，用于客户端和服务器端之间的全双工消息转发。

客户端配置的组件成为对各主题数据的获取方，通过订阅、请求方式获取服务器端数据，或者往服务器端透传数据。

客户端配置的组件进一步包括多个接口单元和多个回调处理单元。其中多个接口单元包括主题初始化接口单元、请求接口单元、订阅接口单元、消息透传接口单元，多个回调处理单元包括链路建立回调处理单元、应答回调处理单元、订阅回调处理单元、消息透传接收处理单元。

主题初始化接口单元用于通过指明主题号和网络端口地址完成主题初始化的处理，其中主题号用于使能客户端对应的主题。

请求接口单元用于往服务器端的对应主题发送请求报文，例如配置函数request(topicid,msg_id,void*context)，其中msg_id为业务标识，context是应用层自定义数据，会通过服务器端的应答接口单元原样返回。

订阅接口单元用于订阅服务器端对应主题发布的数据，例如配置函数subscribe(topicid)，其中topicid为主题号。

消息透传接口单元，用于客户端和服务器端之间的全双工消息转发。

链路建立回调处理单元用于与服务器端建立链接后，通过用户设置的回调函数通知应用链路创建信息，比如可收集服务器端的message_node信息。

应答回调处理单元用于通过设置的回调函数，监听并处理请求至服务器端的请求报文对应的应答数据。

订阅回调处理单元用于通过在应用层设置的回调函数接收服务器端基于对应主题的发布数据。

消息透传接收回调处理单元用于在应用层设置的回调函数监听对应主题下来自服务器端的透传消息。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

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

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

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

Claims (7)

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

服务器端配置的组件中，

主题初始化接口单元，通过指明主题号和网络端口地址进行初始化处理，其中主题号用于使能服务器端对应的主题；

发布流初始化接口单元，用于对主题在服务器端的发布流的初始化处理；

发布接口单元，将发布数据传送至主题的发布流中，根据订阅信息列表将发布数据传递至客户端；

应答接口单元，与客户端提供的请求相对应，服务器端的应答接口单元根据客户端发送的请求报文中的包头信息进行处理，将请求应答数据回复至对应的客户端主题；

消息透传接口单元，用于客户端和服务器端之间的全双工消息转发；

链路建立回调处理单元，用于在与客户端建立链接后通知应用链路创建信息；

请求回调处理单元，用于监听对应主题下来自客户端的请求；

消息透传接收处理单元，用于监听对应主题下来自客户端的透传消息；以及

客户端配置的组件中，

主题初始化接口单元，用于通过指明主题号和网络端口地址完成主题初始化的处理，其中主题号用于使能客户端对应的主题；

订阅接口单元，用于订阅服务器端对应主题发布的数据；

请求接口单元，用于往服务器端的对应主题发送请求报文；

消息透传接口单元，用于客户端和服务器端之间的全双工消息转发；

链路建立回调处理单元，用于与服务器端建立链接后通知应用链路创建信息；

应答回调处理单元，用于监听并处理请求至服务器端的请求报文对应的应答数据；

订阅回调处理单元，用于接收服务器端基于对应主题的发布数据；

消息透传接收处理单元，用于监听对应主题下来自服务器端的透传消息。

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

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

4.根据权利要求3所述的应用层协议解耦合的通用网络处理系统，其特征在于，请求/应答的通讯方式还配置为：

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

对于链接未建立的情况，请求者将请求报文加入等待队列中，若链接建立成功则将等待队列中的请求报文发往应答者，若链接建立失败或者超时则清除等待队列中的请求报文，并通过回调通知应用层。

5.根据权利要求2所述的应用层协议解耦合的通用网络处理系统，其特征在于，发布/订阅的通讯方式配置为：

发布者负责一个指定主题流的发布任务，订阅者负责接收该主题流下的消息，发布和订阅是应用层协议解耦合的，在基于发布订阅的通讯方式上，应用层协议封装至消息体内，应用层收到消息后进行协议解码应用。

6.根据权利要求5所述的应用层协议解耦合的通用网络处理系统，其特征在于，发布/订阅的通讯方式还配置为：

发布者内部维护一个发布会话列表，发布会话负责监听通道上的消息，同时将主题流消息发布到该通道上，发布会话读取发布主题流中的消息发送至对应的通道；

订阅者内部维护一个订阅会话，订阅会话对应于一个通信通道，订阅会话负责处理该通道上的数据，订阅会话接收通道上的消息并将确认接收的消息写入订阅主题流中；

订阅者启动后根据配置的通道地址通过通道向发布者发送主题订阅请求，请求中带有订阅者节点号标识，其中发布者的发布会话内维护一个订阅者节点列表，该订阅者节点列表由一系列订阅者节点组成，如果订阅者在该通道上发起了主题订阅请求，发布者在该通道上的发布会话监听到该请求后，将根据请求中的订阅者节点号和订阅起始位置新建一个订阅者节点，将其加入到订阅者节点列表中；

发布者注册发布通道，发布者的发布标识列表内有对应于订阅者所订阅主题的发布标识对象，发布会话列表中包含多个对应不同订阅者的节点信息；

发布者内部维护一个发布主题流，在主题流中每个消息都有一个唯一的消息编号，当应用层产生新消息后，发布者给该新消息分配一个新的消息编号并将该新消息放入主题流中。

7.根据权利要求2所述的应用层协议解耦合的通用网络处理系统，其特征在于，消息透传的通讯方式配置为：

在链路建立成功后获取到对端的网络节点信息后，指定特定的会话号，并将发送内容装载至网络报文中进行端到端的发送，对端注册消息回调接口完成数据接收，如果链路未建立则对端注册消息回调接口直接报错返回至应用层。

Images