报文处理方法、装置、设备及计算机可读存储介质与流程

本申请涉及通信技术领域，特别涉及一种报文处理方法、装置、设备及计算机可读存储介质。

背景技术：

随着计算机网络和通讯技术的不断发展，电力系统调度运行的信息传输要求不断提高，信息传输方式已逐步走向数字化和网络化。为此，国际电工委员会电力系统控制及其通信技术委员会(iectc57)根据形式发展的要求制定了调度自动化系统和变电站自动化系统的数据通信标准，以适应和引导电力系统调度自动化技术的发展，规范调度自动化及远动设备的技术性能。电力市场迫使远动系统降低费用，避免多种不兼容的标准和互相竞争的标准出现；同时，在整个电力系统制定统一协调的体系结构，既有利于用户，也有利于制造商。

为了实现104规约多用户连接的功能，在现有技术方案中，可以通过套接字(socket)创建104服务器的文件描述符(filedescriptor，简称fd)，并绑定对应的2404端口，等待104客户端的连接，在104客户端连接后，通过新建一个线程的方法来维护对应的104客户端，当104客户端没有连接时，处于一个阻塞状态，要等到104客户端连接后程序才会往下走。

可见，当104客户端连接服务器的时候，需要给该104客户端分配一个线程，利用该线程维护对应的104客户端，但是，当存在多个104客户端时，需要为每个104客户端分配一个线程，这种多线程分配方式会耗费大量的内存资源。

技术实现要素：

有鉴于此，本申请提供了一种报文处理方法、装置、设备及计算机可读存储介质，在实现104规约多用户连接的功能时，有效节省了内存资源。

具体地，本申请是通过如下技术方案实现的：

一种报文处理方法，所述方法应用于服务器；

其中，所述服务器利用一个发送线程发送报文，包括：

当客户端队列中的客户端连接数大于0时，依次遍历所述客户端队列中的每一客户端对应的客户端信息；若根据当前遍历到的客户端信息确定当前客户端用户为有效用户，则对当前客户端的报文队列中的待发送报文进行发送处理；

其中，所述服务器利用一个接收线程接收报文，包括：

获取所述服务器的文件描述符，并获取所述客户端队列中的每一客户端的文件描述符；根据所述服务器的文件描述符，对所述客户端队列进行更新；对于所述客户端队列中的每一客户端，根据该客户端的文件描述符，确定该客户端与所述服务器的交互报文，并接收所述交互报文。

一种报文处理装置，所述装置应用于服务器，所述装置包括报文发送单元和报文接收单元；

其中，所述报文发送单元，用于利用一个发送线程发送报文；具体用于：

当客户端队列中的客户端连接数大于0时，依次遍历所述客户端队列中的每一客户端对应的客户端信息；若根据当前遍历到的客户端信息确定当前客户端用户为有效用户，则对当前客户端的报文队列中的待发送报文进行发送处理；

其中，所述报文接收单元，用于利用一个接收线程接收报文；具体用于：

获取所述服务器的文件描述符，并获取所述客户端队列中的每一客户端的文件描述符；根据所述服务器的文件描述符，对所述客户端队列进行更新；对于所述客户端队列中的每一客户端，根据该客户端的文件描述符，确定该客户端与所述服务器的交互报文，并接收所述交互报文。

一种电子设备，包括：处理器、存储器；

所述存储器，用于存储计算机程序；

所述处理器，用于通过调用所述计算机程序，执行上述报文处理方法。

一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述报文处理方法。

在以上本申请提供的技术方案中，服务器利用一个发送线程来发送报文，并利用一个接收线程来接收报文。在此过程中，创建和维护了一个客户端队列，利用该客户端队列来实现报文的收发处理，这样，对客户端队列中的每个客户端不用另起一个线程来维护，通过极少的线程实现了104规约多用户连接的功能，大幅节省了内存资源，提高了处理效率，具有更高的可靠性。

附图说明

图1为本申请示出的一种报文处理方法的流程示意图；

图2为本申请示出的发送线程处理流程示意图；

图3为本申请示出的接收线程处理流程示意图；

图4为本申请示出的一种报文处理装置的组成示意图；

图5为本申请示出的一种电子设备的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

在介绍本申请实施例之前，首先对本申请实施例涉及的技术术语进行介绍。

fd：文件描述符。内核(kernel)利用文件描述符(filedescriptor)来访问文件。文件描述符是非负整数。打开现存文件或新建文件时，内核会返回一个文件描述符。读写文件也需要使用文件描述符来指定待读写的文件。

在本申请实施例中，在创建104服务器的fd之前，会初始化一个客户端队列，该客户端队列的队列信息，可以包括头节点信息和尾节点信息、以及当前连接的客户端数目，其中，头结点对应客户端队列中的第一个客户端，尾节点对应客户端队列中的最后一个客户端，这里，通过头节点信息可以找到客户端队列中第一个客户端节点的客户端信息，当获取到第一个客户端的客户端信息后，可以根据该客户端信息获取客户端队列中第二个客户端的客户端信息，依次类推，可以逐一获取客户端队列中每一客户端的客户端信息。

对于客户端队列中的每一客户端，为了便于区分，这里将每一客户端定义为当前客户端，该当前客户端节点的客户端信息(即客户端节点结构体)可以包括下一个客户端节点的地址，以及当前客户端的标识ip、当前客户端的socket(套接字)文件描述符、当前客户端的状态信息、当前客户端的报文收发序列号、以及当前客户端的待发送报文队列信息等中的至少一项。

其中，当前客户端的状态信息，可以是当前客户端与服务器处于断开状态、或当前客户端与服务器处于已连接状态、或当前客户端与服务器处于连接中状态；当前客户端的待发送报文队列信息，可以包括报文头指针、报文尾指针和当前待发送报文的数量，这里，报文指针指向的地址中可以包括报文的长度、报文的数据、以及下一个报文的地址等。

在完成上述客户端信息初始化后，104服务器会创建自己的fd，并绑定2404端口，之后，104服务器会开启两个线程，一个用于接收报文，一个用于发送报文。

下面对本申请实施例提供的报文处理方法进行具体介绍，该方法应用于一种服务器，该服务器可以是104服务器，客户端队列中的客户端则为104客户端，当然，该服务器也可以是适用于本申请实施例的其它服务器。

参见图1，为本申请实施例提供的报文处理方法的流程示意图，该方法中的服务器利用一个发送线程发送报文、利用一个接收线程接收报文。可见，当该服务器是104服务器时，可以通过极少的线程实现了104规约多用户连接的功能，不但大幅节省了内存资源，还提高了运行效率，具有更高的可靠性。

需要说明的是，为了便于理解发送线程的处理流量，本申请实施例将结合图2所示的发送线程处理流程示意图，对图1中关于发送线程的各个步骤进行具体介绍；同理，为了便于理解接收线程的处理流量，本申请实施例将结合图3所示的接收线程处理流程示意图，对图1中关于接收线程的各个步骤进行具体介绍。

在图1中，当服务器利用一个发送线程发送报文时，可以包括以下步骤s101-s102：

s101：当客户端队列中的客户端连接数大于0时，依次遍历客户端队列中的每一客户端对应的客户端信息。

参见图2所示的步骤s201-s204，在发送线程被开启后，会持续读取当前客户端队列中的客户端连接数，如果客户端连接数大于0，则先对客户端队列进行加锁，以防止在读取客户端队列的过程中数据被修改，即，防止接收线程操作客户端队列的相关公共资源时导致资源访问冲突；然后，按照客户端队列的节点顺序，依次遍历客户端队列中的每一客户端对应的客户端信息，当每遍历到一个客户端的客户端信息时，便将该客户端作为当前客户端，并基于当前客户端的客户端信息执行后续步骤。

可见，在本申请实施例中，在依次遍历客户端队列中的每一客户端对应的客户端信息之前，还可以包括：对客户端队列进行加锁。这样，可以防止接收线程的操作，对公共资源造成的访问冲突。

s102：若根据当前遍历到的客户端信息确定当前客户端用户为有效用户，则对当前客户端的报文队列中的待发送报文进行发送处理。

参见图2所示的步骤s204-s205，先读取客户端队列中第一个客户端的客户端信息，如前述内容所述，该第一个客户端的客户端信息，可以包括第二个客户端节点的地址，以及第一个客户端的标识ip、第一个客户端的socket(套接字)文件描述符、第一个客户端的状态信息、第一个客户端的报文收发序列号、以及第一个客户端的待发送报文队列信息等中的至少一项。基于此，可以从中获取第一个客户端的状态信息，从该状态信息中可以获知第一个客户端与服务器处于何种连接状态，具体的，若第一个客户端与服务器处于已连接状态或连接中状态，则认为第一个客户端用户为有效用户，若第一个客户端与服务器处于断开状态，则认为第一个客户端用户为无效用户。

基于上述内容，s102中的“根据当前遍历到的客户端信息确定当前客户端用户为有效用户”，包括：若根据当前遍历到的客户端信息，确定当前客户端与服务器处于未断开状态，则确定当前客户端用户为有效用户。

当第一个客户端用户为无效用户时，则继续遍历客户端队列中的第二个客户端的客户端信息。当第一个客户端用户为有效用户时，参见图2所示的步骤s206-s208，需要检查第一个客户端的报文队列中是否存在待发送的报文，如果存在，则将这些报文进行发送，并从报文队列中删除已发送的报文，然后，继续遍历客户端队列中的第二个客户端的客户端信息。

按照上述方式，逐一遍历客户端队列中的所有客户端，直至遍历到的节点地址为无效地址(地址为空)时，则结束遍历(对应图2所示的s209)，并将客户端队列进行解锁(对应图2所示的s210)。可见，在本申请实施例，当遍历客户端队列之前，对客户端队列进行了加锁时，则在遍历完客户端队列后，还需要对客户端队列进行解锁。

需要说明的是，本申请实施例可以重复执行s101-s102，以利用发送线程来发送报文，可以每执行一次后间隔预设时长后再次执行，也可以每执行一次便重新执行，从而保证报文的及时发送。

在图1中，当服务器利用一个接收线程接收报文时，可以包括以下步骤s103-s105：

s103：获取服务器的文件描述符，并获取客户端队列中的每一客户端的文件描述符。

参见图3所示的s301-s302，当开启接收线程后，可以先创建一个文件描述集，该文件描述集用于存放客户端和服务器的文件描述符fd，在完成对文件描述集的初始化后，先将服务器的文件描述符fd加入到文件描述集中。

然后，再将客户端队列中的各个客户端的文件描述符fd加入到文件描述集中，为此，需要获取客户端队列中的每一客户端的文件描述符。

在本申请实施例的一种实现方式中，s103中的“获取客户端队列中的每一客户端的文件描述符”，可以包括：当客户端队列中的客户端连接数大于0时，依次遍历所述客户端队列中的每一客户端对应的客户端信息；若根据当前遍历到的客户端信息确定当前客户端用户为有效用户，则加载当前客户端的文件描述符；若根据当前遍历到的客户端信息确定当前客户端用户为无效用户，则将当前客户端从客户端队列中剔除。

具体来讲，在本实现方式中，需要判断客户端队列中是否存在客户端用户，如果是，则先对客户端队列进行加锁，再依次遍历各个客户端的客户端信息，用于判断当前客户端用户是否为有效用户，具体实现可以参见图3所示的步骤s303-s307(这些步骤与图2所示的s201-s205相同，请参见s201-s205的相关介绍，此处不再赘述)。

参见与3所示的s307-s310，对于当前遍历到的客户端，若当前客户端用户为有效用户，则将当前客户端的文件描述符fd加入文件描述集中，但若当前客户端用户为无效用户，则将该当前客户端从客户端队列中踢出，然后，继续遍历客户端队列中的下一个客户端，并将该客户端作为当前客户端，重复执行上述流程，按照上述方式，逐一遍历客户端队列中的所有客户端，直至遍历到的节点地址为无效地址(地址为空)时，则结束遍历，并将客户端队列进行解锁。

基于上述内容可知，在s103中的上述具体实现方式中，在依次遍历客户端队列中的每一客户端对应的客户端信息之前，还可以包括：对客户端队列进行加锁；并且，当遍历完客户端队列后，对客户端队列进行解锁。此外，在s103中的上述具体实现方式中，其中的“根据当前遍历到的客户端信息确定当前客户端用户为有效用户”，具体可以包括：若根据当前遍历到的客户端信息，确定当前客户端与服务器处于未断开状态，则确定当前客户端用户为有效用户。

接下来，当遍历完客户端队列后，即，将客户端队列中的每一客户端的文件描述符fd均添加到文件描述集后，则跳过添加用户文件描述符的过程，直接进去select流程，以利用select函数实现对文件描述集的监听，即，在文件描述集中添加完文件描述符后，调用select函数来实现多用户的监听(参见图3所示的s311)。

在本申请实施例的一种实现方式中，当通过s103获取到客户端队列中的每一客户端的文件描述符之后，还可以包括：对于客户端队列中的每一客户端，若该客户端在预设时长内未与服务器进行数据交互，则使该客户端与服务器断开连接。

在本实现方式中，对于每个客户端来讲，通过设置一个预设时长，来防止该客户端很久没有与服务器交互后仍然占用资源的情况，即，若该客户端在预设时长内一直没有与服务器进行数据交互，服务器会主动断开与该客户端的连接，并清空该客户端的相应数据，可见，通过这种超时保护机制，减少了该客户端长时间没有报文交互却占用资源的情况，即，防止了长时间没有通信造成的资源占用。

其中，参见图3所示的s312-s316，为了计算上述“预设时长”，可以设置一个超时时间(比如10秒)，一旦到达该超时时间，便使超时计数加1，当超时计数达到预设数值(比如3000)时，说明该客户端与服务器的未交互时长持续了“预设时长”，此时，清空该客户端的相应数据。一旦客户端队列中的所有客户端的相应数据均被清除，则重新执行图3所示的“初始化文件描述集”的步骤。

需要说明的是，在判断一个客户端是否超时时，应确定该客户端最近一次与服务器进行数据交互的时间点，从该时间点开始监测超时时间，一旦连续未交互时长达到“预设时长”，则将该客户端从客户端队列中删除。

s104：根据服务器的文件描述符，对客户端队列进行更新。

在本申请实施例的一种实现方式中，s104中的“根据服务器的文件描述符，对客户端队列进行更新”，可以包括：根据服务器的文件描述符，确定是否有新的客户端与服务器建立连接；若是，则将该新的客户端加入客户端队列。

在本实现方式中，当服务器与一个新的客户端建立连接后，会在客户端队列中创建一个新的客户端节点，用于存放该连接的用户节点，以将该新的客户端加入了客户端队列，实现了对客户端队列的更新。具体实现时，参见图3所示的s317-s319，服务器需要对预置的超时时间(比如10秒)进行监测，判断是否超时，若否，则检查服务器的文件描述符fd，若基于服务器的文件描述符fd确定有新的连接，则新建客户端端点以将新客户端加入客户端队列。

s105：对于客户端队列中的每一客户端，根据该客户端的文件描述符，确定该客户端与服务器的交互报文，并接收交互报文。

在本申请实施例中，对于客户端队列中的每一客户端，在客户端队列中对应一个队列节点，该队列节点下挂载对应客户端的报文队列。也就是说，每个客户端用户的报文队列，交给该客户端对应的队列节点来维护，即，该客户端的报文队列挂载在该客户端的队列节点下面，这样，避免了统一管理可能造成的信息错传的后果，从而减少了报文误传的概率。

参见图3所示的s320-s322，对于客户端队列中的每一客户端，可以检查该客户端的文件描述符fd，以确定该客户端与服务器是否有报文交互，若有，则服务器对来自该客户端的报文进行报文解析，并将解析报文放入该客户端的报文队列中。其中，当服务器是104服务器时，可以调用104模块进行对应的报文解析。

在以上本申请实施例提供的报文处理方法中，服务器利用一个发送线程来发送报文，并利用一个接收线程来接收报文，在此过程中，创建和维护了一个客户端队列，利用该客户端队列来实现报文的收发处理，这样，对客户端队列中的每个客户端不用另起一个线程来维护，通过极少的线程实现了104规约多用户连接的功能，大幅节省了内存资源，提高了处理效率，具有更高的可靠性。

参见图4，为本申请实施例提供的一种报文处理装置的组成示意图，该装置应用于服务器，该装置包括报文发送单元410和报文接收单元420；

其中，所述报文发送单元410，用于利用一个发送线程发送报文；具体用于：

当客户端队列中的客户端连接数大于0时，依次遍历所述客户端队列中的每一客户端对应的客户端信息；若根据当前遍历到的客户端信息确定当前客户端用户为有效用户，则对当前客户端的报文队列中的待发送报文进行发送处理；

其中，所述报文接收单元420，用于利用一个接收线程接收报文；具体用于：

获取所述服务器的文件描述符，并获取所述客户端队列中的每一客户端的文件描述符；根据所述服务器的文件描述符，对所述客户端队列进行更新；对于所述客户端队列中的每一客户端，根据该客户端的文件描述符，确定该客户端与所述服务器的交互报文，并接收所述交互报文。

在本申请实施例一种实现方式中，所述客户端队列中的每一客户端，在所述客户端队列中对应一个队列节点；所述队列节点下挂载对应客户端的报文队列。

在本申请实施例一种实现方式中，所述报文接收单元420，还用于：

在获取所述客户端队列中的每一客户端的文件描述符之后，对于所述客户端队列中的每一客户端，若该客户端在预设时长内未与所述服务器进行数据交互，则使该客户端与所述服务器断开连接。

在本申请实施例一种实现方式中，所述报文接收单元420在获取所述客户端队列中的每一客户端的文件描述符，具体用于：

当客户端队列中的客户端连接数大于0时，依次遍历所述客户端队列中的每一客户端对应的客户端信息；

若根据当前遍历到的客户端信息确定当前客户端用户为有效用户，则加载当前客户端的文件描述符；若根据当前遍历到的客户端信息确定当前客户端用户为无效用户，则将当前客户端从所述客户端队列中剔除。

在本申请实施例一种实现方式中，所述报文发送单元410和所述报文接收单元420，还用于：

在依次遍历所述客户端队列中的每一客户端对应的客户端信息之前，对所述客户端队列进行加锁；当遍历完所述客户端队列后，对所述客户端队列进行解锁。

在本申请实施例一种实现方式中，所述报文发送单元410和所述报文接收单元420，在根据当前遍历到的客户端信息确定当前客户端用户为有效用户时，具体用于：

若根据当前遍历到的客户端信息，确定当前客户端与所述服务器处于未断开状态，则确定当前客户端用户为有效用户。

在本申请实施例一种实现方式中，所述报文接收单元420在根据所述服务器的文件描述符，对所述客户端队列进行更新时，具体用于：

根据所述服务器的文件描述符，确定是否有新的客户端与所述服务器建立连接；若是，则将该新的客户端加入所述客户端队列。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本申请实施例还提供了一种电子设备，该电子设备的结构示意图如图5所示，该电子设备5000包括至少一个处理器5001、存储器5002和总线5003，至少一个处理器5001均与存储器5002电连接；存储器5002被配置用于存储有至少一个计算机可执行指令，处理器5001被配置用于执行该至少一个计算机可执行指令，从而执行如本申请中任意一个实施例或任意一种可选实施方式提供的任意一种报文处理方法的步骤。

进一步，处理器5001可以是fpga(field－programmablegatearray，现场可编程门阵列)或者其它具有逻辑处理能力的器件，如mcu(microcontrollerunit，微控制单元)、cpu(centralprocessunit，中央处理器)。

应用本申请实施例，服务器利用一个发送线程来发送报文，并利用一个接收线程来接收报文，在此过程中，创建和维护了一个客户端队列，利用该客户端队列来实现报文的收发处理，这样，对客户端队列中的每个客户端不用另起一个线程来维护，通过极少的线程实现了104规约多用户连接的功能，大幅节省了内存资源，提高了处理效率，具有更高的可靠性。

本申请实施例还提供了另一种计算机可读存储介质，存储有计算机程序，该计算机程序用于被处理器执行时实现本申请中任意一个实施例或任意一种可选实施方式提供的任意一种报文处理方法的步骤。

本申请实施例提供的计算机可读存储介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、cd-rom、和磁光盘)、rom(read-onlymemory，只读存储器)、ram(randomaccessmemory，随即存储器)、eprom(erasableprogrammableread-onlymemory，可擦写可编程只读存储器)、eeprom(electricallyerasableprogrammableread-onlymemory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，可读存储介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。

应用本申请实施例，服务器利用一个发送线程来发送报文，并利用一个接收线程来接收报文，在此过程中，创建和维护了一个客户端队列，利用该客户端队列来实现报文的收发处理，这样，对客户端队列中的每个客户端不用另起一个线程来维护，通过极少的线程实现了104规约多用户连接的功能，大幅节省了内存资源，提高了处理效率，具有更高的可靠性。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。