集合通信系统中控制报文处理方法、装置、设备及系统

本申请要求于2020年06月08日提交中国国家知识产权局、申请号为202010514291.1、申请名称为“集合通讯的在网计算控制的方法和设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本申请涉及信息技术领域，尤其涉及一种集合通信系统中控制报文处理方法、装置、设备、系统以及计算机可读存储介质。

背景技术

随着高性能计算(high performance computing，HPC)以及(artificialintelligence，AI)技术的不断发展，许多新的应用应运而生。用户对各类应用场景的执行效率及性能也越来越追求极致。其中，集合通信是各类应用场景的主流通信方式，也是未来的发展趋势。通过集合通信中的集合操作替代大量点对点操作，可以提升应用的运行性能。

在集合通信系统中，计算节点执行集合操作时往往占用较多的计算资源，如占用较多中央处理器(central processor unit，CPU)资源。基于此，业界提出了一种在网计算(In-network Computing，INC)方案。在网计算具体是利用交换机等在网计算设备的极限转发能力及强计算能力对集合操作进行卸载，从而极大的提升集合操作性能，降低计算节点的CPU负载。

目前，业界典型的在网计算方案是在管理节点部署独立的管理进程，该管理进程包括子网管理进程(subnet manager)和汇聚管理进程(aggregation manager)，然后通过上述管理进程获得通信域内的组网拓扑及在网计算能力，基于该组网拓扑、在网计算能力对后续的业务报文进行INC卸载。

然而，管理进程的部署过程非常复杂，而且维护难度较高。在大规模组网中，部署复杂度和维护难度更加显著。基于此，业界亟需提供一种更加简洁、高效的在网计算方案，以优化集合通信系统的性能。

发明内容

本申请提供了一种集合通信系统中控制报文处理方法。该方法通过复用集合通信系统的上下文直接进行查询报文、通知报文等控制报文的收发，基于控制报文查询在网计算能力，以便后续业务报文基于在网计算能力进行INC卸载，避免了相关资源的重复创建及获取，解耦了对控制面管理进程和计算节点守护进程的依赖。通过该方法实现的在网计算方案更具备维护性、灵活性以及通用性。本申请还提供了上述方法对应的装置、设备、系统、计算机可读存储介质以及计算机程序产品。

第一方面，本申请提供了一种集合通信系统中控制报文处理方法。集合通信系统包括交换机网络(也称作交换矩阵，switch fabric)和多个计算节点。其中，交换机网络是指至少一个交换机形成的网络。该交换机网络可以包括一个交换机，也可以包括多个交换机。交换机网络还可以根据网络架构分为单层交换机网络和多层交换机网络。

单层交换机网络包括单层交换机，也即接入层交换机。单层交换机包括一个或多个交换机。单层交换交换机中的每个交换机可以直连计算节点，从而将计算节点接入网络。

多层交换机网络包括上层交换机和下层交换机。其中，上层交换机是指与交换机连接的交换机，上层交换机通常不直连计算节点。下层交换机是指能够直连计算节点的交换机，因此也称作接入层交换机。例如，多层交换机网络可以是叶脊(1eaf spine)架构。上层交换机为spine交换机，下层交换机为leaf交换机。spine交换机不再是三层架构中的大型机箱式交换机，而是高端口密度的交换机。而leaf交换机作为接入层，可以提供网络连接给终端、服务器等计算节点，同时上联spine交换机。

交换机网络包括第一交换机，该第一交换机可以是上述单层交换机网络中的交换机，也可以是多层交换机网络中的交换机，如leaf交换机或者spine交换机等等。支持集合通信的应用可以复用集合通信系统的上下文发起控制报文流程，以查询交换机网络的在网计算能力等信息，以为在网计算(计算卸载)提供帮助。

具体地，源节点可以根据集合通信系统的上下文生成查询报文，该查询报文用于请求查询所述交换机网络的在网计算能力，第一交换机可以转发由源节点传输至目的节点的查询报文。源节点和目的节点具体是集合通信系统中的不同计算节点。目的节点可以生成通知报文，通知报文携带所述交换机的在网计算能力。第一交换机可以转发由目的节点传输至源节点的通知报文，以向源节点通知交换机网络的在网计算能力。

其中，交换机网络的在网计算能力包括查询报文经过的一个或多个交换机的在网计算能力。集合通信系统的一个或多个计算节点可以作为源节点，向目的节点发送查询报文。当这些查询报文经过交换机网络的所有交换机时，则目的节点通过通知报文返回的交换机网络的在网计算能力是指该交换机网络的所有交换机的在网计算能力。当这些查询报文经过交换机网络的部分交换机时，则目的节点通过通知报文返回的交换机网络的在网计算能力具体是指上述部分交换机的在网计算能力。

该方法复用集合通信系统的上下文直接进行查询报文、通知报文等控制报文的收发，基于控制报文查询在网计算能力，以便后续业务报文基于在网计算能力进行1NC卸载，避免了相关资源的重复创建及获取，解耦了对控制面管理进程和计算节点守护进程的依赖。基于此，本申请实施例提供的在网计算方案更具备易维护性、灵活性以及通用性。

进一步地，该方法支持复用已有的网络协议通道，如以太网的通道，对通信标准没有依赖，无需采用远程直接数据存取(remote direct memory access，RDMA)网络通信标准(infiniband，IB)，也无需额外配置IB交换机，因而能够极大地降低在网计算方案的成本。

而且，该方法也无需在计算节点运行守护进程，只需提供INC动态库(INC lib)，在集合操作通信域内调用INC lib中的指定应用程序编程接口(application programminginterface，API)实现控制报文业务逻辑即可。

在一些可能的实现方式中，查询报文经过第一交换机时，第一交换机可以在查询报文中添加该第一交换机的在网计算能力，例如在查询报文的query字段添加该交换机的在网计算能力。然后，第一交换机向目的节点转发添加有第一交换机的在网计算能力的查询报文。对应地，目的节点根据添加有第一交换机的在网计算能力的查询报文，对第一交换机的在网计算能力进行汇总，得到交换机网络的在网计算能力，然后在通知报文中携带上述交换机网络的在网计算能力。

如此，通过简单且高效的方法实现了查询交换机网络的在网计算能力，为集合通信的在网计算方案提供帮助。

在一些可能的实现方式中，第一交换机的在网计算能力包括该第一交换机支持的集合操作类型和/或第一交换机支持的数据类型。第一交换机在查询报文中添加第一交换机支持的集合操作类型和/或第一交换机支持的数据类型，以便于计算节点根据交换机支持的集合操作类型、数据类型决定是否在该第一交换机进行计算卸载，从而实现在网计算。

其中，集合操作类型可以包括一个成员到组内所有成员的广播、一个成员从所有组成员收集数据、一个成员向组内所有成员分散数据、组内所有成员到所有成员间的分散/收集数据操作、全局归约(global reduction)操作、组合归约(combined reduction)和分散操作、组内所有成员上的搜索操作中的任意一种或多种。其中，成员是指进程组中的一个进程。

数据类型可以包括字节(byte)、16位整型(short)、32位整型(int)、64位整型(long)、浮点型(float)、双精度浮点型(double)、布尔型(boolean)和字符型(char)等中的任意一种或多种。

如此，计算节点可以根据第一交换机支持的集合操作类型和/或第一交换机支持的数据类型，确定在网计算策略。具体地，计算节点可以比较本次集合通信的集合操作类型与第一交换机支持的集合操作类型，以及比较本次集合通信的数据类型与第一交换机支持的数据类型。当第一交换机支持的集合操作类型包括本次集合通信的集合操作类型，第一交换机支持的数据类型包括本次集合通信的数据类型时，计算节点可以将计算卸载至该第一交换机，否则，计算节点不将计算卸载至该第一交换机。由此可以避免计算节点在第一交换机不支持本次集合通信的集合操作类型或数据类型时进行额外的作业，提高计算节点的效率。

在一些可能的实现方式中，第一交换机的在网计算能力包括第一交换机的在网计算剩余可用资源的大小。其中，第一交换机的在网计算剩余可用资源的大小可以通过第一交换机并发主机数的最大值，也即本地组规模(local group size)进行表征。

其中，第一交换机的在网计算能力可以包括第一交换机支持的集合操作类型、第一交换机支持的数据类型以及第一交换机的在网计算剩余可用资源的大小中的任意一种或多种。当第一交换机默认支持各种集合操作类型时，第一交换机的在网计算能力可以不包括第一交换机支持的集合操作类型。当第一交换机默认支持各种数据类型时，第一交换机的的在网计算能力可以不包括第一交换机支持的数据类型。

第一交换机在查询报文中添加该第一交换机的在网计算剩余可用资源的大小，以便于计算节点根据该在网计算剩余可用资源的大小，确定在网计算策略。例如，将计算全部卸载至该第一交换机，或者将计算部分卸载至该第一交换机等等，从而实现充分利用第一交换机的在网计算资源。

在一些可能的实现方式中，第一交换机还可以根据所述查询报文的跳数建立表项，该表项用于所述交换机对业务报文进行计算卸载。具体地，在业务报文流程中，第一交换机可以识别业务报文是否为在网计算报文，若是，则将在网计算报文与控制报文流程中建立的表项进行匹配，若匹配成功，则对该业务报文进行计算卸载。由此可以实现实时分配在网计算资源。进一步地，在集合通信完成后，还可以清除上述表项，释放在网计算资源。如此可以优化资源利用率。

在一些可能的实现方式中，第一交换机直连所述源节点和所述目的节点。对应地，所述第一交换机可以接收所述源节点发送的查询报文，转发所述查询报文至所述目的节点，然后所述第一交换机接收所述目的节点发送的通知报文，转发所述通知报文至所述源节点。由于交换机网络的拓扑相对简单，经过一次转发即可实现查询报文、通知报文的收发，提高了获取在网计算能力的效率。

在一些可能的实现方式中，交换机网络还包括第二交换机和/或第三交换机。其中，第二交换机用于连接所述第一交换机和所述源节点，第三交换机用于连接所述第一交换机和所述目的节点。该第二交换机可以是一个交换机，也可以是多个交换机。类似地，第三交换机也可以是一个交换机或者是多个交换机。

当交换机网络包括第二交换机，且不包括第三交换机时，第一交换机接收所述第二交换机转发的查询报文，转发所述查询报文至所述目的节点，然后第一交换机接收所述目的节点发送的通知报文，将所述通知报文转发至所述第二交换机。

当交换机网络包括第三交换机，且不包括第二交换机时，第一交换机接收所述源节点发送的查询报文，转发所述查询报文至所述第三交换机，然后第一交换机接收所述第三交换机转发的通知报文，将所述通知报文转发至所述源节点。

当交换机网络既包括第二交换机，又包括第三交换机时，第一交换机接收所述第二交换机转发的查询报文，转发所述查询报文至所述第三交换机，然后第一交换机接收所述第三交换机转发的通知报文，将所述通知报文转发至所述第二交换机。

第一交换机通过转发报文至其他交换机，再通过其他交换机进行报文转发，可以实现以间接方式将查询报文由源节点传输至目的节点，将通知报文由目的节点传输至源节点，进而实现通过收发控制报文获得交换机网络的在网计算能力。

其中，第一交换机和第二交换机可以垂直连接，即第一交换机和第二交换机为不同层级的交换机。第一交换机和第二交换机也可以水平连接，即第一交换机和第二交换机可以为同一层级的交换机，例如可以为接入层的交换机。类似地，第一交换机和第三交换机也可以垂直连接，或者水平连接。

在一些可能的实现方式中，所述交换机网络包括单层交换机，如柜顶交换机(topof rack，ToR)。因此，第一交换机为上述单层交换机。由此可以实现服务器等计算节点和第一交换机在机柜内的互联。所述第一交换机通知报文时，直接向源节点转发所述通知报文，具有较高的通信性能。

在一些可能的实现方式中，所述交换机网络包括上层交换机和下层交换机。例如，交换机网络可以是叶脊(leaf spine)架构，包括位于上层的上层交换机即spine交换机，以及位于下层的下层交换机即leaf交换机。第一交换机可以是下层交换机中的一个交换机，例如可以是leaf交换机。

具体地，第一交换机可以根据所述上层交换机的在网计算剩余可用资源的大小从所述上层交换机中确定目标交换机，然后在通知报文中添加所述目标交换机的在网计算剩余可用资源的大小，接着第一交换机向所述源节点转发添加有所述目标交换机的在网计算剩余可用资源的大小的通知报文。如此，在后续的业务报文流程中，计算节点还可以基于目标交换机的在网计算剩余可用资源的大小，确定在网计算策略，具体是在目标交换机进行计算卸载的策略。

在一些可能的实现方式中，第一交换机可以根据所述上层交换机的在网计算剩余可用资源的大小，利用负载均衡策略从所述上层交换机中确定目标交换机。如此可以避免上层交换机出现过载，影响集合通信性能。

在一些可能的实现方式中，第一交换机为下层交换机时，还可以向所述上层交换机发送交换机查询报文，该交换机查询报文用于查询上层交换机的在网计算剩余可用资源的大小，然后接收所述上层交换机发送的交换机通知报文，该交换机通知报文用于通知所述上层交换机的在网计算剩余可用资源的大小。如此可以为下层交换机确定目标交换机提供参考。

在一些可能的实现方式中，第一交换机为上层交换机时，还可以接收所述下层交换机发送的交换机查询报文，所述交换机查询报文用于查询第一交换机在网计算剩余可用资源的大小，然后向所述下层交换机发送交换机通知报文，所述交换机通知报文用于通知所述第一交换机的在网计算剩余可用资源的大小。如此，通过交换机查询报文、交换机通知报文的收发获得上层交换机的在网计算剩余可用资源的大小，为下层交换机确定目标交换机提供参考。

在一些可能的实现方式中，所述集合通信系统的上下文包括应用的上下文或者通信域的上下文。通过复用这些上下文可以避免相关资源的重复创建及获取，解耦了对控制面管理进程和计算节点守护进程的依赖。

在一些可能的实现方式中，所述多个计算节点包括主节点和至少一个子节点。其中，所述源节点可以为所述子节点，对应地，所述目的节点为所述主节点。在一些实施例中，所述源节点也可以主节点，所述目的节点也可以为子节点。

第二方面，本申请提供了一种集合通信系统中控制报文处理方法。所述集合通信系统包括交换机网络和多个计算节点，所述交换机网络包括至少一个交换机，所述多个计算节点包括第一计算节点和第二计算节点。

具体地，第一计算节点接收所述交换机网络中的一个或多个交换机转发的查询报文，所述查询报文用于请求查询所述交换机网络的在网计算能力，所述查询报文由所述第二计算节点根据所述集合通信系统的上下文生成。然后，所述第一计算节点根据所述查询报文生成通知报文，所述通知报文携带所述交换机网络的在网计算能力。接着，所述第一计算节点向所述第二计算节点发送所述通知报文。

该方法复用集合通信系统的上下文直接进行查询报文、通知报文等控制报文的收发，基于控制报文查询在网计算能力，以便后续业务报文基于在网计算能力进行INC卸载，避免了相关资源的重复创建及获取，解耦了对控制面管理进程和计算节点守护进程的依赖。基于此，本申请实施例提供的在网计算方案更具备易维护性、灵活性以及通用性。

在一些可能的实现方式中，所述通知报文携带的所述交换机网络的在网计算能力具体是从所述一个或多个交换机转发的查询报文中获取。查询报文每经过一个交换机，该交换机即在查询报文中添加该交换机的在网计算能力，如此，计算节点可以通过发送查询报文，接收通知报文的方式获得交换机网络的在网计算能力，避免了相关资源的重复创建及获取，解耦了对控制面管理进程和计算节点守护进程的依赖。

在一些可能的实现方式中，所述交换机转发的查询报文包括所述交换机添加的、所述交换机的在网计算能力，所述第一计算节点可以根据一个或多个交换机转发的查询报文中所述一个或多个交换机的在网计算能力，获得所述交换机网络的在网计算能力。由此实现了通过简单的控制报文收发以及处理，即可获得交换机网络的在网计算能力。

在一些可能的实现方式中，所述第一计算节点为主节点或子节点。其中，第一计算节点为主节点时，第二计算节点可以为子节点。第一计算节点为子节点时，第二计算节点可以为主节点。

第三方面，本申请提供了一种集合通信系统中控制报文处理方法。所述集合通信系统包括交换机网络和多个计算节点，所述交换机网络包括至少一个交换机，所述多个计算节点包括第一计算节点和第二计算节点。

具体地，所述第二计算节点根据所述集合通信系统的上下文生成查询报文，所述查询报文用于请求查询所述交换机网络的在网计算能力。然后，所述第二计算节点通过交换机网络中的一个或多个交换机向所述第一计算节点发送所述查询报文。接着，所述第二计算节点接收所述第一计算节点通过所述一个或多个交换机转发的、由所述第一计算节点根据所述查询报文生成的通知报文，所述通知报文携带所述交换机网络的在网计算能力。

该方法复用集合通信系统的上下文直接进行查询报文、通知报文等控制报文的收发，基于控制报文查询在网计算能力，以便后续业务报文基于在网计算能力进行INC卸载，避免了相关资源的重复创建及获取，解耦了对控制面管理进程和计算节点守护进程的依赖。基于此，本申请实施例提供的在网计算方案更具备易维护性、灵活性以及通用性。

在一些可能的实现方式中，所述交换机网络的在网计算能力由所述第一计算节点根据所述一个或多个交换机转发的所述查询报文中所述一个或多个交换机的在网计算能力得到。如此，可以为计算节点通过收发控制报文获得交换机网络的在网计算能力提供帮助。

在一些可能的实现方式中，所述第二计算节点为主节点或子节点。其中，第二计算节点为主节点时，第一计算节点可以为子节点。第二计算节点为子节点时，第一计算节点可以为主节点。

第四方面，本申请提供了一种集合通信系统中控制报文处理装置。所述集合通信系统包括交换机网络和多个计算节点，所述交换机网络包括第一交换机，所述装置包括：

通信模块，用于转发由源节点传输至目的节点的查询报文，所述查询报文用于请求查询所述交换机网络的在网计算能力，所述查询报文由所述源节点根据所述集合通信系统的上下文生成，所述源节点和所述目的节点为所述多个计算节点中的不同节点；

所述通信模块，还用于转发由所述目的节点传输至所述源节点的通知报文，所述通知报文携带所述交换机网络的在网计算能力。

在一些可能的实现方式中，所述装置还包括：

处理模块，用于接收到查询报文时，在所述查询报文中添加所述第一交换机的在网计算能力；

所述通信模块具体用于：

向目的节点转发添加有所述第一交换机的在网计算能力的查询报文。

在一些可能的实现方式中，所述第一交换机的在网计算能力包括所述第一交换机支持的集合操作类型和/或数据类型。

在一些可能的实现方式中，所述第一交换机的在网计算能力包括所述第一交换机的在网计算剩余可用资源的大小。

在一些可能的实现方式中，所述装置还包括：

处理模块，用于根据所述查询报文的跳数建立表项，所述表项用于所述第一交换机对业务报文进行计算卸载。

在一些可能的实现方式中，所述第一交换机直连所述源节点和所述目的节点；

所述通信模块具体用于：

接收所述源节点发送的查询报文，转发所述查询报文至所述目的节点；

接收所述目的节点发送的通知报文，转发所述通知报文至所述源节点。

在一些可能的实现方式中，所述交换机网络还包括第二交换机和/或第三交换机，所述第二交换机用于连接所述第一交换机和所述源节点，所述第三交换机用于连接所述第一交换机和所述目的节点；

所述通信模块具体用于：

接收所述源节点发送的查询报文，转发所述查询报文至所述第三交换机；

接收所述第三交换机转发的通知报文，将所述通知报文转发至所述源节点；或者，

接收所述第二交换机转发的查询报文，转发所述查询报文至所述目的节点；

接收所述目的节点发送的通知报文，将所述通知报文转发至所述第二交换机；或者，

接收所述第二交换机转发的查询报文，转发所述查询报文至所述第三交换机；

接收所述第三交换机转发的通知报文，将所述通知报文转发至所述第二交换机。

在一些可能的实现方式中，所述交换机网络包括单层交换机，所述第一交换机为所述单层交换机；

所述通信模块具体用于：

向所述源节点转发所述通知报文。

在一些可能的实现方式中，所述交换机网络包括上层交换机和下层交换机，所述第一交换机为所述下层交换机；

所述装置还包括：

处理模块，用于根据所述上层交换机的在网计算剩余可用资源的大小从所述上层交换机中确定目标交换机，在通知报文中添加所述目标交换机的在网计算剩余可用资源的大小；

所述通信模块具体用于：

向所述源节点转发添加有所述目标交换机的在网计算剩余可用资源的大小的通知报文。

在一些可能的实现方式中，所述处理模块具体用于：

根据所述在网计算剩余可用资源的大小，利用负载均衡策略从所述上层交换机中确定目标交换机。

在一些可能的实现方式中，所述通信模块还用于：

向所述上层交换机发送交换机查询报文，所述交换机查询报文用于查询所述上层交换机的在网计算剩余可用资源的大小；

接收所述上层交换机发送的交换机通知报文，所述交换机通知报文用于通知所述上层交换机的在网计算剩余可用资源的大小。

在一些可能的实现方式中，所述交换机网络包括上层交换机和下层交换机，所述第一交换机为所述上层交换机；

所述通信模块还用于：

接收所述下层交换机发送的交换机查询报文，所述交换机查询报文用于查询所述第一交换机的在网计算剩余可用资源的大小；

向所述下层交换机发送交换机通知报文，所述交换机通知报文用于向所述下层交换机通知所述第一交换机的在网计算剩余可用资源的大小。

在一些可能的实现方式中，所述集合通信系统的上下文包括应用的上下文或者通信域的上下文。

在一些可能的实现方式中，所述多个计算节点包括主节点和至少一个子节点；

所述源节点为所述子节点，所述目的节点为所述主节点；或者，

所述源节点为所述主节点，所述目的节点为所述子节点。

第五方面，本申请提供了一种集合通信系统中控制报文处理装置。所述集合通信系统包括交换机网络和多个计算节点，所述交换机网络包括至少一个交换机，所述多个计算节点包括第一计算节点和第二计算节点，所述装置包括：

通信模块，用于接收所述交换机网络中的一个或多个交换机转发的查询报文，所述查询报文用于请求查询所述交换机网络的在网计算能力，所述查询报文由所述第二计算节点根据所述集合通信系统的上下文生成；

生成模块，用于根据所述查询报文生成通知报文，所述通知报文携带所述交换机网络的在网计算能力；

所述通信模块，还用于向所述第二计算节点发送所述通知报文。

在一些可能的实现方式中，所述交换机转发的查询报文包括所述交换机添加的、所述交换机的在网计算能力；

所述生成模块具体用于：

根据所述一个或多个交换机转发的查询报文中所述一个或多个交换机的在网计算能力，获得所述交换机网络的在网计算能力；

根据所述交换机网络的在网计算能力生成通知报文。

在一些可能的实现方式中，所述装置部署于所述第一计算节点，所述第一计算节点为主节点或子节点。

第六方面，本申请提供了一种集合通信系统中控制报文处理装置。所述集合通信系统包括交换机网络和多个计算节点，所述交换机网络包括至少一个交换机，所述多个计算节点包括第一计算节点和第二计算节点，所述装置包括：

生成模块，用于根据所述集合通信系统的上下文生成查询报文，所述查询报文用于请求查询所述交换机网络的在网计算能力；

通信模块，用于通过所述交换机网络中的一个或多个交换机向所述第一计算节点发送所述查询报文；

所述通信模块，还用于接收所述第一计算节点通过所述一个或多个交换机转发的通知报文，所述通知报文携带所述交换机网络的在网计算能力，所述通知报文由所述第一计算节点根据所述查询报文生成。

在一些可能的实现方式中，所述装置部署于所述第二计算节点，所述第二计算节点为主节点或子节点。

第七方面，本申请提供了一种交换机。所述交换机包括处理器和存储器。

所述处理器用于执行所述存储器中存储的指令，以使得所述交换机执行如本申请第一方面或者第一方面的任一种实现方式所述的方法。

第八方面，本申请提供了一种计算节点。所述计算节点包括处理器和存储器；

所述处理器用于执行所述存储器中存储的指令，以使得所述计算节点执行如本申请第二方面或者第二方面的任一种实现方式所述的方法。

第九方面，本申请提供了一种计算节点。所述计算节点包括处理器和存储器；

所述处理器用于执行所述存储器中存储的指令，以使得所述计算节点执行如本申请第三方面或者第三方面的任一种实现方式所述的方法。

第十方面，本申请提供了一种集合通信系统。所述集合通信系统包括交换机网络和多个计算节点，所述交换机网络包括第一交换机，所述多个计算节点包括第一计算节点和第二计算节点。

所述第二计算节点，用于根据所述集合通信系统的上下文生成查询报文，所述查询报文用于请求查询所述交换机网络的在网计算能力；

所述第一交换机，用于转发由所述第二计算节点传输至所述第一计算节点的所述查询报文；

所述第一计算节点，用于根据所述查询报文生成通知报文，所述通知报文携带所述交换机网络的在网计算能力；

所述第一交换机，还用于转发由所述第一计算节点传输至所述第二计算节点的所述通知报文。

第十一方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，所述指令指示设备执行上述第一方面、第二方面或第三方面的任一种实现方式所述的集合通信系统中控制报文处理方法。

第十二方面，本申请提供了一种包含指令的计算机程序产品，当其在设备上运行时，使得设备执行上述第一方面或第一方面、第二方面或第三方面的任一种实现方式所述的集合通信系统中控制报文处理方法。

本申请在上述各方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。

附图说明

为了更清楚地说明本申请实施例的技术方法，下面将对实施例中所需使用的附图作以简单地介绍。

图1为本申请实施例提供的一种集合通信系统的架构图；

图2为本申请实施例提供的一种集合通信系统中在网计算的原理图；

图3为本申请实施例提供的一种集合通信系统中交换机的结构示意图；

图4为本申请实施例提供的一种集合通信系统中计算节点的结构示意图；

图5为本申请实施例提供的一种集合通信系统中控制报文处理方法的流程图；

图6为本申请实施例提供的一种集合通信系统中查询报文的结构示意图；

图7为本申请实施例提供的一种集合通信系统中通知报文的结构示意图；

图8为本申请实施例提供的一种集合通信系统中控制报文处理方法的交互流程图；

图9为本申请实施例提供的一种集合通信系统中控制报文处理方法的交互流程图；

图10为本申请实施例提供的一种集合通信系统中控制报文处理装置的结构示意图；

图11为本申请实施例提供的一种集合通信系统中控制报文处理装置的结构示意图；

图12为本申请实施例提供的一种集合通信系统中控制报文处理装置的结构示意图；

图13为本申请实施例提供的一种集合通信系统的结构示意图。

具体实施方式

本申请实施例中的术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。

首先对本申请实施例中所涉及到的一些技术术语进行介绍。

高性能计算(high performance computing，HPC)是指利用大量处理单元的聚合计算能力进行计算，从而用于解决复杂问题，如天气预测、石油勘探、核爆模拟等问题。其中，大量处理单元的聚合计算能力可以是单个机器中多个处理器的聚合计算能力，也可以是集群中的多个计算机的聚合计算能力。

人工智能(artificial intelligence，AI)是指通过运行在计算机上的计算机程序，使得计算机具有如同人类智能的效果，从而可以辅助人类或代替人类解决问题。例如，人工智能可以用于实现自动化地图像检测、图像识别、音频检测、视频监控等。

人工智能一般包括两种实现方式。一种实现方式为工程学方式(engineeringapproach)，即采用传统的编程技术，使得计算机呈现智能的效果，而不考虑是否与人或动物机体所用的方法相同。一种实现方式是模拟学方式(modeling approach)，具体为采用和人类或生物机体所用的方法相同或相类似方式，使得计算机呈现智能的效果。

在一些示例中，模拟学方式可以包括基于遗传算法(generic algorithm，GA)模拟人类或生物的遗传-进化机制，也可以包括基于人工神经网络(artificial neuralnetwork，ANN)模拟人类或生物大脑中神经细胞的活动方式。

随着HPC以及AI的不断发展，一些新的应用应运而生。用户对于这些应用的执行效率和性能越来越追求极致。基于此，业界引入了集合通信，通过集合通信中的集合操作代替大量点对点操作，从而提升应用的性能。

集合通信是指组织一个通信域(communicator)为一组通信的进程服务，在进程之间完成特定的通信操作。其中，一组通信的进程(process)形成一个进程组(group)，通信域(也可以称作通信子)则综合描述了通信的进程之间的关系。通信域具体包括：进程组、上下文(context)和拓扑(topology)等。其中，上下文是指进程执行时的环境。拓扑是指执行进程的计算节点的分布。

进程执行时的环境具体是指进程执行时所依赖的各个变量和数据，包括寄存器变量、进程打开的文件以及内存信息等。上下文实质上是环境的一个快照，该快照是一个用于保存状态的对象。在程序中编写的函数大都不是单独完整的，在使用一个函数完成相应功能时，很可能需要其他外部环境变量的支持。上下文即是对外部环境的变量赋值，使函数能正确运行。

每个进程是客观上唯一的，通常具有唯一的进程标识(process id，pid)。同一个进程可以仅属于一个进程组，也可以属于多个进程组(进程在不同进程组中具有各自的编号，即rank号)。当同一个进程属于多个进程组时，考虑到进程组和通信域之间的一一对应关系，该进程也可以属于不同的通信域。

集合通信系统中进程间特定的操作(也即集合操作)主要是针对数据的分发和同步化操作。在信息传递接口(message passing interface，MPI)基础上的集合通信一般包括两种通信模式，一种为一对多的通信模式，另一种为多对多的通信模式。

其中，一对多模式下的通信操作可以包括一个成员到组内所有成员的广播(broadcast)、一个成员从所有组成员收集(gather)数据、一个成员向组内所有成员分散(scatter)数据等等。多对多模式下的通信操作可以包括组内所有成员到所有成员间的分散/收集数据操作、全局归约(global reduction)操作、组合归约(combined reduction)和分散操作、组内所有成员上的搜索操作等等。其中，归约是指通过一个函数将一批数据分成较小的一批数据，例如将一个数组的元素通过加法函数归约为一个数字。

应用可以在多个不同的通信域进行集合通信。例如，应用分布式地部署在计算节点1至N中，计算节点1至计算节点K上的进程组可以形成一个通信域，计算节点K+1至N上的进程组可以形成另一个通信域，N为大于3的正整数，K为大于或等于2的正整数。这两个通信域具有各自的上下文。类似地，应用本身也具有上下文。应用的上下文指应用执行时的环境。应用的上下文可以视为全局的上下文，通信域的上下文可以视为在该通信域内的局部的上下文。

在网计算(in-network computing，INC)是业界提出的一种针对集合通信的关键优化技术。具体地，在网计算是指利用交换机的极限转发能力及强计算能力对集合操作进行卸载，从而极大地提升集合操作性能，降低计算节点的负载。

针对在网计算，业界提出了一种基于可扩展分层聚合协议(ScalableHierarchical Aggregation Protocol，SHARP)的实现方案。具体地，管理节点上部署有独立运行的管理进程，该管理进程具体包括子网管理进程(subnet manager，SM)和汇聚管理进程(aggregation manager，AM)。

SM获取汇聚节点(aggregation node，AN)的拓扑信息，然后SM将该拓扑信息告知AM，接着AM获取AN的在网计算能力，AM根据AN拓扑信息和AN的在网计算能力计算SHARP树结构，AM分配并配置AN到AN的可靠连接(reliable connected)队列对(queue pair)，接着根据QP配置所有AN的SHARP树信息。

接着，作业调度器启动作业，分配计算资源。各分配的主机(host)执行作业初始化脚本，启动SHARP守护进程(SHARP Deamon，SD)。编号为0(rank 0)的SD(也可以称作SD-0)将作业信息发送给AM，AM为作业分配SHARP资源。AM在AN上为该作业进行配额，将资源分配描述发送给SD-0，SD-0将信息转发该其他SD。需要说明，其他SD可以并行启动作业，如将作业信息发送给AM，由AM为作业分配资源，并在对应的AN上进行配额等等。

如此，MPI进程可以访问SD获取SHARP资源信息，根据该SHARP资源信息建立连接，然后创建进程组(group)，接着MPI进程向SHARP树发送聚合请求，从而实现在网计算。

上述方法需要管理节点部署SM、AM等管理进程，基于SM、AM获得网络拓扑以及INC资源信息，由此实现在网计算。其中，管理进程的部署过程复杂，而且难以维护。在大规模组网时，管理进程的部署和维护难度更加显著。

有鉴于此，本申请实施例提供了一种集合通信系统中控制报文处理方法。该集合通信系统中包括交换机网络和多个计算节点。其中，交换机网络包括至少一个交换机。集合通信系统的上下文允许对通信空间进行划分，每一个上下文可以提供一个相对独立的通信空间，不同的报文可以在不同的上下文(具体为不同的通信空间)中传输，在一个上下文中传输的报文不会被传输至另一个上下文。集合通信系统的计算节点可以利用上下文的上述特性发起控制报文流程，具体是根据该集合通信系统已有的上下文，例如应用的上下文或者通信域的上下文生成控制报文，向集合通信系统的其他计算节点发送该控制报文，通过该控制报文查询该控制报文经过的交换机网络的组网拓扑及在网计算能力，供后续业务报文进行INC卸载操作。

该方法复用集合通信系统的上下文直接进行查询报文、通知报文等控制报文的收发，基于控制报文查询在网计算能力，以便后续业务报文基于在网计算能力进行INC卸载，避免了相关资源的重复创建及获取，解耦了对控制面管理进程和计算节点守护进程的依赖。基于此，本申请实施例提供的在网计算方案更具备易维护性、灵活性以及通用性。

进一步地，该方法支持复用已有的网络协议通道，如以太网的通道，对通信标准没有依赖，无需采用远程直接数据存取(remote direct memory access，RDMA)网络通信标准(infiniband，IB)，也无需额外配置IB交换机，因而能够极大地降低在网计算方案的成本。

而且，该方法也无需在计算节点运行守护进程，只需提供INC动态库(INC lib)，在集合操作通信域内调用INC lib中的指定API实现控制报文业务逻辑即可。

为了使得本申请的技术方案更加清楚、易于理解，下面结合系统架构图对本申请实施例的技术方案进行介绍。

参见图1所示的集合通信系统的架构图，集合通信系统100包括交换机网络102和多个计算节点104。多个计算节点104中包括一个主节点(master node)和至少一个子节点(child node)。其中，主节点为集合通信系统中根(root)进程(有序进程系列中进程序号为0的进程)所在的计算节点，子节点为集合通信系统中除主节点以外的计算节点。子节点上可以包括一个子根(sub-root)进程。

交换机网络102包括至少一层交换机1020。具体地，交换机网络102可以是单层交换机架构，例如包括一层接入层交换机，该接入层交换机具体可以是柜顶(top ofrack，ToR)交换机，由此可以实现服务器等计算节点和交换机1020在机柜内的互联。需要说明，ToR交换机实际也可以部署在机柜内的其他位置，如机柜中部，只要能够实现服务器和交换机在机柜内互联即可。

交换机网络102也可以是多层交换机架构。例如，如图1所示，交换机网络102可以是叶脊(leafspine)架构。leafspine架构的交换机网络102包括位于上层的上层交换机即spine交换机，以及位于下层的下层交换机即leaf交换机。其中，spine交换机不再是三层架构中的大型机箱式交换机，而是高端口密度的交换机。而leaf交换机可以作为接入层，leaf交换机提供网络连接给终端、服务器，同时上联给spine交换机。需要说明，每层交换机1020的数量可以是一个，也可以是多个，本申请实施例对此不作限定。

计算节点104是具有数据处理能力的设备，具体可以为服务器，或者个式机、笔记本电脑、智能手机等终端设备。多个计算节点104可以是同构设备，例如多个计算节点可以同为Intel复杂指令集(X86)架构的服务器，或者同为高级精简指令集(advanced RISCmachine，ARM)架构的服务器。多个计算节点104也可以是异构设备，例如部分计算节点104为X86架构的服务器，部分计算节点为ARM架构的服务器。

交换机网络102和多个计算节点104形成HPC集群。该集群中的任意一个或多个计算节点104可以作为集群的存储节点。在一些实现方式中，集群也可以增加独立的节点作为集群的存储节点。

交换机网络102与各个计算节点104连接，作为在网计算节点。当主节点的root进程触发集合操作时，如归约求和的操作时，如图2所示，交换机网络102中的交换机1020如leaf交换机或者spine交换机接收到集合通信报文时，具体是集合通信系统的业务报文时，可以对该业务报文进行聚合，并将计算卸载到该交换机的在网计算引擎(INC engine)，由INC engine对聚合的业务报文进行在网计算。接着，交换机1020将计算结果转发至计算节点104，如此可以减少计算节点104的负载。其中，计算在交换机网络102和计算节点104侧共同完成，减少了计算节点104的收发次数，缩短了通信时间，提升了集合通信的性能。

需要说明的是，交换机网络102将计算卸载到交换机的INC engine，由INC engine对聚合的报文进行在网计算，需要计算节点104预先知晓在网计算的组网信息(包括组网拓扑)以及在网计算能力，根据组网信息、在网计算能力请求相应的资源。而组网信息、在网计算能力可以通过控制报文获得。

具体地，支持集合通信的应用可以分布式地部署在集合通信系统的计算节点104上。应用初始化时，可以在计算节点104侧发起控制报文流程。具体地，以集合通信系统中的一个计算节点104为目的节点，剩余的计算节点104中至少一个计算节点104为源节点，源节点根据集合通信系统的上下文生成查询报文，并向目的节点传输上述查询报文。

其中，查询报文经过交换机网络102中的交换机1020时，交换机1020可以在控制报文中添加该交换机1020的在网计算能力，然后再向目的节点转发上述查询报文。目的节点可以根据添加有交换机1020的在网计算能力的查询报文，生成通知报文，向源节点返回上述通知报文，从而向源节点通知交换机网络102的在网计算能力。如此可以实现通过控制报文获取在网计算能力。

在一些实现方式中，计算节点104中的网卡也具有一定的计算能力，基于此，计算节点104还可以将计算卸载至网卡，从而实现节点内卸载。具体地，集合通信涉及节点内通信和节点间通信时，可以将节点内计算卸载至网卡，将节点间计算卸载至交换机1020，如此可以进一步优化大规模集群中集合通信的性能。

以位于8个计算节点104上的32个进程间的集合通信为例，每个计算节点104上包括4个进程，可以在计算节点104中的网卡上对4个进程进行聚合，将这4个进程的计算卸载至网卡，网卡将4个进程的计算结果转发至交换机1020，交换机1020对不同计算节点104的计算结果进行进一步聚合，将计算卸载至交换机1020。由此可以实现基于网卡和交换机1020的在网计算方案。

集合通信系统中的多个计算节点可以是一个主节点和至少一个子节点。在一些可能的实现方式中，源节点可以是上述子节点，目的节点可以是上述主节点，即子节点向主节点发送查询报文，以查询交换机网络102的在网计算能力。在另一些可能的实现方式中，源节点也可以是主节点，目的节点也可以是子节点，即主节点向子节点发送查询报文，以查询交换机网络102的在网计算能力。

以上对集合通信系统架构进行了介绍，接下来，将从硬件实体化角度对集合通信系统中的设备如交换机1020、计算节点104进行介绍。

图3示出了交换机1020的结构示意图。应理解，图3仅仅示出了上述交换机1020中的部分硬件结构和部分软件模块，具体实现时，交换机1020还可以包括更多的硬件结构，如指示灯等等，以及更多的软件模块，如各种应用程序等。

如图3所示，交换机1020包括总线1021、处理器1022、通信接口1023和存储器1024。处理器1022、存储器1024和通信接口1023之间通过总线1021通信。

总线1021可以是外设部件互连标准(peripheral component interconnect，PCI)总线、快捷外设部件互连标准(peripheral component interconnect express，PCIe)或扩展工业标准结构(extended industry standard architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图3中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

处理器1022可以为中央处理器(central processing unit，CPU)、图形处理器(graphics processing unit，GPU)、微处理器(micro processor，MP)或者数字信号处理器(digital signal processor，DSP)等处理器中的任意一种或多种。

通信接口1023用于与外部通信，例如接收子节点发送的查询报文，向子节点发送由主节点生成的通知报文等等。

存储器1024可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，RAM)。存储器1024还可以包括非易失性存储器(non-volatilememory)，例如只读存储器(read-only memory，ROM)，快闪存储器，硬盘驱动器(hard diskdrive，HDD)或固态硬盘驱动器(solid state drive，SSD)。

存储器1024中存储有程序或指令，例如实现本申请实施例提供的集合通信系统中控制报文处理方法所需的程序或指令。处理器1022执行该程序或指令以执行前述集合通信系统中控制报文处理方法。

需要说明的是，图3中仅示出了交换机网络102中的一个交换机1020。在一些实现方式中，交换机网络102可以包括多个交换机1020。考虑到交换机1020之间的传输性能，这多个交换机1020也可以集成在一个背板上，或者放置在同一机架上。

图4示出了计算节点104的结构示意图。应理解，图4仅仅示出了上述计算节点104中的部分硬件结构和部分软件模块，具体实现时，计算节点104还可以包括更多的硬件结构，如麦克风、扬声器等等，以及更多的软件模块，如各种应用程序等。

如图4所示，计算节点104包括总线1041、处理器1042、通信接口1043和存储器1044。处理器1042、存储器1044和通信接口1043之间通过总线1041通信。

总线1041可以是PCI总线、PCIe或EISA总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。处理器1042可以为CPU、GPU、MP或者DSP等处理器中的任意一种或多种。通信接口1043用于与外部通信，例如通过交换机网络102传输查询报文，通过交换机网络102传输通知报文等等。

存储器1044可以包括易失性存储器，例如随机存取存储器。存储器1044还可以包括非易失性存储器，例如只读存储器，快闪存储器，硬盘驱动器或固态硬盘驱动器。存储器1044中存储有程序或指令，例如实现本申请实施例提供的集合通信系统中控制报文处理方法所需的程序或指令。处理器1042执行该程序或指令以执行前述集合通信系统中控制报文处理方法。

为了使得本申请的技术方案更加清楚、易于理解，下面结合附图对本申请实施例提供的集合通信系统中控制报文处理方法进行详细介绍。

参见图5所示的集合通信系统中控制报文处理方法，该方法包括：

S502：交换机1020转发由源节点传输至目的节点的查询报文。

为了简化集合通信系统中业务报文的通信流程，优化集合通信的性能，计算节点104可以先传输控制报文，基于控制面的控制报文交互获得在网计算能力等信息，以为业务报文传输奠定基础。

在一些可能的实现方式中，计算节点104中的子节点可以作为源节点发起控制报文流程。具体地，子节点(具体为子节点的sub-root进程)可以根据集合通信系统的上下文，如应用的上下文或者通信域的上下文生成查询报文。该查询报文属于控制报文中的一种，用于查询交换机网络102的在网计算能力。在网计算能力也可以称作在计算卸载能力，用于表征交换机网络102能够承担计算任务的能力。其中，在网计算能力可以通过以下指标的至少一种进行表征：支持的集合操作类型、数据类型。

其中，交换机网络102支持的集合操作类型可以包括一个成员到组内所有成员的广播、一个成员从所有组成员收集数据、一个成员向组内所有成员分散数据、组内所有成员到所有成员间的分散/收集数据操作、全局归约(global reduction)操作、组合归约(combined reduction)和分散操作、组内所有成员上的搜索操作中的任意一种或多种。其中，成员是指进程组中的一个进程。

交换机网络102支持的数据类型可以包括字节(byte)、16位整型(short)、32位整型(int)、64位整型(long)、浮点型(float)、双精度浮点型(double)、布尔型(boolean)和字符型(char)等中的任意一种或多种。

查询报文由子节点传输至主节点是通过交换机网络102实现的。具体地，查询报文是根据集合通信系统的上下文，如通信域的上下文生成，查询报文中可以携带有通信域标识，例如在INC报文头中携带有通信域标识，交换机1020基于该通信域标识向通信域内的目的节点转发上述查询报文。子节点可以根据上述查询报文对应的通知报文获得交换机网络102的在网计算能力，无需通过管理节点上的SM进程获取交换机网络102的组网信息(具体为交换机网络102的拓扑信息)，并将拓扑信息告知AM，由AM获取交换机网络102的在网计算能力。

在一些实现方式中，所述交换机网络102中接收到所述查询报文的交换机1020(也可以称之为第一交换机)，可以在所述查询报文中添加所述交换机1020的在网计算能力，然后向主节点(具体为主节点的root进程)转发添加有上述交换机1020的在网计算能力的查询报文。

具体地，查询报文包括INC报文头。INC报文头用于标识该报文为INC报文，包括INC控制报文或者INC数据报文(也称INC业务报文)。交换机1020接收到报文时，可以根据是否包括INC报文头识别报文是否为INC报文，进而决定是否执行查询在网计算能力的操作。

为了查询在网计算能力，查询报文中可以预留查询(query)字段。交换机1020在query字段中添加该交换机1020的在网计算能力。交换机1020的在网计算能力包括该交换机1020支持的操作类型、数据类型等在网计算特性，这些在网计算特性可以形成在网计算特性清单(INC feature list)。交换机1020可以在query字段中添加INC feature list。

为了便于理解，本申请实施例还提供了查询报文的一个示例。查询报文包括INC报文头和INC报文的有效载荷。如图6所示，INC报文头为MPI+字段，INC报文的有效载荷为query字段。在一些实现方式中，查询报文的头部还包括MPI报文头、IB报文头、用户数据报协议(user datagram protocol，UDP)报文头、网际协议(Internet protocol，IP)报文头、以太(Ether)报文头等等，用于在传输层、以太网中传输。当然，查询报文的尾部还可以包括校验字段，如循环冗余校验(cyclic redundancy check，CRC)。

其中，INC报文头具体可以包括在网计算标记(1NC Tag)和通信域标识(communicator ID，commID)。其中，在网计算标记包括INC tag low。在一些示例中，INCtag low取值为0x44332211时，标识该报文为INC报文。在网计算标记还可以包括INC taghigh，INC tag high可以和INC tag low共同用于标识报文为INC报文，由此可以提高识别INC报文的准确率。通信域标识具体标识本次集合通信复用的通信域。在一些可能的实现方式中，INC报文头还包括本次集合通信的操作类型(operation code，opt code)、数据类型(data type)。

INC报文头还可以包括源进程序号(source rank，src rank)，即生成该报文的进程的rank号。INC报文头还可以包括消息请求标识(request ID，req ID)、消息分片个数(request packet number，ReqPkt Num)、报文的数据个数(PktPara Num)中的一个或多个。在一些实施例中，INC报文头还可以包括保留字段，如保留标识(reserve ID，rsvd)，该保留标识的不同保留值可以用于区分计算节点发送的控制报文和交换机发送的控制报文。

query字段包括交换机支持的操作类型(supported data operation)、支持的数据类型(supported data type)。在一些实现方式中，query字段还可以包括支持的MPI类型(supported MPI type)，支持的集合类型(supported coll type)、最大数据量(max datasize)、全局组规模(global group size)、本地组规模(local group size)、通信域标识(comm ID)、可用组规模(avalible group number)。其中，query字段还可以包括querynotify hop，query notify hop可以占用一个字节，该字节的前4位取值为0x0时，表征该报文为查询报文。

查询报文经过一个交换机1020，该交换机1020即在该查询报文(具体可以是查询报文的query字段)中填写该交换机的在网计算能力。当查询报文经过多个交换机1020时，每个交换机1020在查询报文中添加该交换机1020的在网计算能力，具体是添加该交换机1020支持的操作类型和/或数据类型。

进一步地，交换机1020的在网计算能力还还可以包括交换机1020的在网计算剩余可用资源的大小。其中，交换机1020的在网计算剩余可用资源的大小可以通过交换机1020并发主机数的最大值，也称作本地组规模进行表征。基于此，交换机1020还可以在查询报文中添加本地组规模。在一些实施例中，交换机1020还可以添加支持的MPI类型、支持的集合类型、最大数据量、全局组规模、通信域标识等中的任意一种或多种。

主节点(具体是主节点上的root进程)可以对这些交换机1020的在网计算能力进行汇总获得交换机网络102的在网计算能力，基于交换机网络102的在网计算能力生成通知报文，用于向子节点的sub-root进程通知交换机网络102的在网计算能力。

在一些实现方式中，交换机1020还可以在query字段中填写报文跳数(hop)。参见图6，交换机1020可以在query notify hop的后4位中添加报文跳数。对应地，交换机1020还可以根据报文跳数创建表项。

具体地，报文跳数为0时，表明源节点与该交换机1020直接连接，该交换机1020在交换机内创建表项。如此，在业务报文流程中，交换机1020接收到业务报文，可以根据上述表项对业务报文进行计算卸载。

在一些实施例中，表项中至少包括源节点(具体是源节点上的进程)的标识，例如source rank。交换机1020先根据报文头识别业务报文为INC报文，然后比较报文中的srcrank和表项中的src rank，当src rank一致时，交换机1020分配INC资源，进行计算卸载。进一步地，当集合通信完成时，交换机1020还可以删除上述表项，释放INC资源。由此实现实时分配及释放INC资源，优化资源利用率。

S504：所述交换机1020转发由所述目的节点传输至所述源节点的通知报文。

所述通知报文用于向所述源节点通知所述交换机网络102的在网计算能力。通知报文由所述目的节点根据所述查询报文生成。与查询报文类似，通知报文中携带集合通信系统的上下文，如通信域标识。此外，通知报文中还携带了交换机网络102的在网计算能力。其中，上下文使得通知报文能够被准确地传输至相应节点(具体是节点的进程，如子节点的sub root进程)。如此，子节点等源节点无需通过在管理节点启动SM进程和AM进程，即可获得交换机网络102的在网计算能力。

为了便于理解，图7还提供了通知报文的一个具体示例。如图7所示，通知报文的格式与查询报文的格式相同，通知报文的query字段中填充有交换机网络102的在网计算能力，包括supported data operation、supported data type等等。其中，query字段还可以包括query notify hop，query notify hop可以占用一个字节，该字节的前4位取值为0x1时，表征该报文为通知报文。

当交换机网络102包括单层交换机1020，具体为接入层交换机时，该单层交换机可以在接收到通知报文时，向子节点转发通知报文，从而实现向所述子节点传输由所述主节点生成的通知报文。

当交换机网络102包括多层交换机1020，具体为上层交换机和下层交换机时，下层交换机可以根据所述在网计算剩余可用资源的大小从所述上层交换机中确定目标交换机。该目标交换机具体用于在后续的业务报文流程中对业务报文进行聚合，进而实现在网计算。如此，下层交换机可以在通知报文中添加目标交换机的在网计算剩余可用资源的大小。目标交换机的在网计算剩余可用资源的大小可以通过目标交换机并发主机数的最大值，也即可用组规模进行表征。基于此，下层交换机可以在通知报文的query字段中添加可用组规模。

交换机网络102的在网计算能力还可以包括可用组规模，即目标交换机的在网计算剩余可用资源的大小。下层交换机可以向子节点转发添加有目标交换机的在网计算剩余可用资源的大小的通知报文。对应地，子节点可以根据通知报文中交换机网络102的在网计算能力发起业务报文流程，实现在网计算。

其中，下层交换机在确定目标交换机时，具体是根据在网计算剩余可用资源的大小，利用负载均衡策略从所述上层交换机中确定目标交换机。例如，交换机网络102中包括n个交换机，其中，m个交换机为上层交换机，所述n大于m。主节点在向子节点返回通知报文时，通过交换机网络102转发该通知报文。当通知报文到达与子节点接近的下层交换机时，该下层交换机根据上层交换机的在网计算可用资源的大小，通过负载均衡策略，选择m个上层交换机中在网计算可用资源较大、负载较小的交换机作为目标交换机。

在一些实现方式中，下层交换机可以向上层交换机发送交换机查询报文，该交换机查询报文用于查询在网计算剩余可用资源的大小，然后上层交换机可以向下层交换机返回交换机通知报文，该交换机通知报文中携带所述在网计算剩余可用资源的大小。

下层交换机确定目标交换机后，该下层交换机还可以向所述目标交换机发送资源请求报文，所述资源请求报文用于请求分配资源。其中，请求分配的资源的大小不超过目标交换机的剩余可用资源的大小。目标交换机根据该资源请求报文进行资源分配。在分配成功后，目标交换机可以建立表项，以便后续业务报文流程中，通过分配的资源以及相应的表项对后续的业务报文进行聚合，进而实现计算卸载。其中，目标交换机还可以生成资源响应报文，并向上述下层交换机发送资源响应报文，该资源响应报文用于向上述下层交换机通知资源分配成功。

需要说明的是，图5所示实施例是以子节点生成查询报文，向主节点发送查询报文，主节点根据添加有交换机1020的在网计算能力的查询报文生成通知报文，向子节点返回通知报文进行示例说明。在本申请实施例其他可能的实现方式中，也可以是主节点生成查询报文，子节点生成通知报文，或者一个子节点生成查询报文，另一个子节点生成通知报文。本申请实施例对此不作限定。

在图5所示实施例中，当交换机1020直连所述源节点和所述目的节点时，该交换机1020可以直接接收所述源节点发送的查询报文，转发所述查询报文至所述目的节点，然后接收所述目的节点发送的通知报文，转发所述通知报文至所述源节点。如此经过一次转发即可实现查询报文、通知报文的收发，提高了获取在网计算能力的效率。

当交换机1020(也可称之为第一交换机)通过其他交换机(为了便于描述，本申请称之为第二交换机)与源节点连接，或者通过其他交换机(为了便于描述，本申请称之为第三交换机)与目的节点连接，则交换机1020还可以将报文转发至其他交换机，通过其他交换机将报文转发至源节点或目的节点。

具体地，当交换机网络102包括第二交换机，且不包括第三交换机时，交换机1020接收所述第二交换机转发的查询报文，转发所述查询报文至所述目的节点，然后交换机1020接收所述目的节点发送的通知报文，将所述通知报文转发至所述第二交换机。

当交换机网络102包括第三交换机，且不包括第二交换机时，交换机1020接收所述源节点发送的查询报文，转发所述查询报文至所述第三交换机，然后交换机1020接收所述第三交换机转发的通知报文，将所述通知报文转发至所述源节点。

当交换机网络102既包括第二交换机，又包括第三交换机时，交换机1020接收所述第二交换机转发的查询报文，转发所述查询报文至所述第三交换机，然后交换机1020接收所述第三交换机转发的通知报文，将所述通知报文转发至所述第二交换机。

上层交换机、下层交换机可以包括一个以上层级的交换机，即多层交换机可以是2层或2层以上的交换机。为了便于描述，本申请实施例还以交换机网络102包括的多层交换机为叶脊架构交换机，对集合通信系统中控制报文处理方法进行示例说明。

参见图8所示的集合通信系统中控制报文处理方法的流程图，在该示例中，集合通信系统包括一个主节点、至少一个子节点(例如子节点1和子节点2)以及交换机网络102，其中，交换机网络102包括leaf交换机和spine交换机，该示例以包括2个leaf交换机(具体为leaf1和leaf2)，2个spine交换机(具体为spine1和spine2)进行说明。该方法包括：

S802：子节点根据集合通信系统中通信域的上下文生成查询报文，向主节点发送查询报文。

具体地，子节点上的sub-root进程向主节点上的root进程发送查询报文，用于查询交换机网络102的在网计算能力。该查询报文是子节点根据通信域的上下文生成，如此保障该查询报文能够正确传输至主节点。其中，子节点可以是服务器，为了便于与其他查询报文进行区分，子节点发送的查询报文可以称作server query。

其中，集合通信系统包括多个子节点。例如集合通信系统包括子节点1和子节点2时，子节点1发送的查询报文具体为server1 query，子节点2发送的查询报文具体为server2query。

集合通信系统中存在通信域，例如root进程、sub-root进程1、sub-root进程2所形成的进程组对应的通信域，子节点(具体为子节点上的sub-root进程，例如sub-root进程1、sub-root进程2)复用通信域的上下文，向主节点(具体为主节点上的root进程)发送serverquery，而不必部署管理节点，以及在管理节点上启动SM、AM等管理进程。

在图8的示例中，由于server1和server2分别直连不同的交换机，例如server1直连leaf1，server2直连leaf2，而leaf2还直连主节点，leaf1并不直连主节点，因此，server1query需要经过leaf1、spine1和leaf2到达主节点，server2 query经过leaf2到达主节点，二者的路径是不同的。

S804：交换机网络102中的交换机1020接收到查询报文时，在该查询报文中添加该交换机1020的在网计算能力。

server query(如server query1、server query2)中预留有query字段。serverquery经过交换机传输至主节点时，交换机1020在server query的query字段中添加该交换机1020的在网计算能力。其中，server query经过多个交换机1020时，query字段中添加有这多个交换机1020的在网计算能力。

其中，交换机1020的在网计算能力具体包括支持的集合操作类型、数据类型等中的任意一种或多种。进一步地，交换机1020的在网计算能力还包括该交换机1020的在网计算剩余可用资源的大小。

在一些实现方式中，query字段还用于添加报文跳数(hop)。交换机1020还可以根据通信域标识和报文跳数创建表项。具体地，报文跳数为0时，表征该交换机1020与子节点直连，交换机1020可以创建表项。在后续业务报文流程中，交换机1020根据该表项对业务报文进行聚合，进而实现计算卸载。

S806：主节点生成通知报文，并向子节点发送通知报文。

具体地，主节点可以对接收到的server query(具体是添加有交换机1020的在网计算能力的server query)中query字段的字段值进行汇总，从而得到交换机网络102的在网计算能力。另外，主节点还可以基于交换机转发路径获得交换机网络102的组网信息，如拓扑信息等。

主节点可以根据在网计算能力之类的信息生成通知报文，并向对应的子节点返回通知报文。为了便于区分，该通知报文可以称之为server notify。当有多个子节点发送server query时，主节点可以返回对应的通知报文，如serverl notify和server2 notify。在图8的示例中，server1和serve2分别连接不同的交换机，因此，server1 notify和server2 notify的路径不同。

S808：与子节点接近的下层交换机(接入层交换机)接收到通知报文时，向上层交换机发送交换机查询报文。

与子节点1接近的下层交换机为leaf 1，与子节点2节点的下层交换机为leaf2。当leaf 1接收到server1 notify时，leaf 1向上层交换机(具体为spine1和spine2)发送交换机查询报文switch query。当leaf 2接收到server2 notify时，leaf 2向spine1和spine2发送switch query。该switch query用于查询在网计算剩余可用资源的大小。

S810：上层交换机向下层交换机返回交换机通知报文。

为了便于描述，交换机通知报文可以称作switch notify。switch notify用于向下层交换机通知上层交换机的在网计算可用资源的大小。

S812：下层交换机根据在网计算可用资源的大小确定目标交换机，向目标交换机发送资源请求报文。

具体地，下层交换机如leaf 1、leaf 2汇总各上层交换机通过switch notify反馈的资源信息，根据各上层交换机的在网计算剩余可用资源的大小确定目标交换机。在确定目标交换机时，下层交换机可以通过负载均衡策略确定目标交换机。由此可以平衡各交换机的负载，提高集合通信并发数。

在一些实现方式中，下层交换机也可以从剩余可用资源的大小大于或等于请求资源的大小的交换机中随机选择交换机，作为目标交换机。本申请实施例对确定目标交换机的实现方式不作限定。

下层交换机确定目标交换机后，可以向该目标交换机发送资源请求报文，用于请求分配资源。在图8所示实施例中，目标交换机为spine1，leaf 1、leaf 2分别向spine1发送资源请求报文。该资源请求报文是由下层交换机向目标交换机发送的请求报文，为此可以记作switch request，以便区分。

S814：目标交换机向下层交换机发送资源响应报文。

具体地，目标交换机如spine1可以统计本次集合通信的通信域内的switchrequest是否收齐，当switch request收齐后可以分配资源，然后向下层交换机返回资源响应报文。与switch request类似，资源响应报文可以记作switch response。

其中，switch request中包括全局组规模字段和本地组规模字段。其中，全局组规模也称作全局主机数(global host number)，本地组规模也称作本地主机数(local hostnumber)。目标交换机如spine1可以根据本地主机数字段的字段值、全局主机数字段的字段值确定switch request是否收齐。具体地，目标交换机可以汇总switch request，对本地主机数进行求和，然后将本地主机数之和与全局主机数比较，若相等，则表明switch request收齐，若会根据INC报文内的local主机数和global主机数字段，来判断request消息是否收齐。

进一步地，目标交换机接收到来自于下层交换机的switch request时，还可以建立表项，该表项用于为后续的业务报文分配资源，对业务报文进行聚合，进而实现计算卸载。

在一些实施例中，执行本申请实施例的集合通信系统中控制报文处理方法时，也可以不执行上述S812中下层交换机向目标交换机发送资源请求报文，以及S814中目标交换机向下层交换机发送资源响应报文的步骤。下层交换机在确定目标交换机后可以直接执行S816，请求分配资源的过程可以在后续的业务报文流程中执行。

S816：下层交换机在通知报文中添加目标交换机的在网计算剩余可用资源的大小，向子节点转发添加有目标交换机的在网计算剩余可用资源的大小的通知报文。

该通知报文为server notify。交换机网络102包括上层交换机，例如spine1和spine 2，leaf 1和leaf2的业务报文可以在spine 1或spine2进行聚合。当下层交换机确定spine 1为目标交换机，并且请求目标交换机分配资源成功时，还可以在server notify中添加目标交换机spine1的在网计算剩余可用资源大小，即在query字段添加可用组规模。然后下层交换机向子节点发送添加有可用组规模的server notify。该server notify用于向子节点通知交换机网络102的在网计算能力，如交换机1020支持的集合操作类型、数据类型以及目标交换机的在网计算剩余可用资源大小，以为后续业务报文的在网计算奠定基础。其中，leaf 1向子节点1发送server1 notify，leaf 2向子节点2发送server2 notify。

当交换机网络仅包括一个spine时，由于可以直接基于该spine对leaf上报的业务报文进行聚合，无需执行选择操作。因此，在控制报文流程中，与源节点直连的下层交换机接收到通知报文时，也可以不执行上述S808至S816，而是直接在该spine上建立表项，并将通知报文转发至源节点。

图8所示实施例主要是以交换机网络102包括leaf和spine交换机进行示例说明的。在一些实现方式中，交换机网络102包括单层交换机，该单层交换机为接入层交换机，单层交换机可以包括一个或多个交换机，如一个或多个Tor。下面交换机网络102包括Tor1和Tor2进行示例说明。

参见图9所示的集合通信系统中控制报文处理方法的流程图，该方法包括：

S902：子节点根据集合通信系统中通信域的上下文生成查询报文，向主节点发送查询报文。

S904：交换机网络102的交换机1020接收到查询报文时，在该查询报文中添加该交换机1020的在网计算能力。

S902至S904的具体实现可以参见S602至S604相关内容描述，本申请实施例在此不再赘述。

S906：主节点根据添加有交换机1020的在网计算能力的查询报文生成通知报文，并向子节点发送通知报文。

其中，主节点通过交换机网络102向子节点发送通知报文。主节点无需通过交换机网络102中的交换机向上层交换机发送交换机查询报文，以确定上层交换机的在网计算可用剩余资源的大小，以及向上层交换机发送资源请求报文，以便在上层交换机对业务报文进行汇聚，而是直接在Tor1、Tor2对业务报文进行聚合，实现在网计算。

在图6、图7所示实施例中，计算节点104可以采用轮询方式发起控制报文流程，如此，交换机网络102的拓扑发生变化时，计算节点104可以实时获得交换机网络102的在网计算能力。在一些实现方式中，计算节点104也可以周期性地发起控制报文流程，以在交换机网络102的拓扑发生变化时，及时更新交换机网络102的在网计算能力。

图8、图9分别从交换机网络102包括多层交换机和交换机网络102包括单层交换机的角度对本申请实施例提供的集合通信系统中控制报文处理方法进行示例说明。

接下来结合一具体场景如天气预测场景对本申请实施例提供的集合通信系统中控制报文处理方法进行说明。

在天气预测场景中，通过搭建HPC集群，在HPC集群上部署天气研究与预报模型(weather research and forecasting model，WRF)，可以实现精细尺度的天气模拟与预报。

具体地，HPC集群可以包括一个交换机1020和8个计算节点104。其中，交换机1020可以是10吉比特(giga bit，G)以太网交换机。该交换机1020中包括处理器，如中央处理器(central processing unit，中央处理器)、神经网络处理器(neural-network processingunit，NPU)中的一种或多种。交换机1020通过上述CPU、NPU实现在网计算，降低计算节点104的计算压力。计算节点104可以是配置有10G以太网卡的服务器。

用户(例如运维人员)在服务器上部署社区企业操作系统(community enterpriseoperating system，cent OS)。接着在操作系统上部署WRF。在部署WRF时，需要先创建环境变量配置文件，安装WRF的依赖包，如层次性数据格式第五版(hierarchical data formatversion 5，HDF5)、并行网络通用数据格式(parallel network common data form，PnetCDF)以及netCDF中不同语言对应的依赖包如netCDF-C、netCDF-fortran。然后运维人员安装主程序，即安装WRF的源码包。其中，在安装源码包之前，可以先确定环境变量是否有效，以保障WRF能够正常运行。

8个服务器中有一个服务器作为主节点，其余服务器作为子节点。子节点上的进程(具体可以为WRF的进程)根据集合通信系统中通信域的上下文生成查询报文，然后向主节点上的进程发送该查询报文。该查询报文经过交换机1020时，交换机1020在查询报文的query字段中添加该交换机1020的在网计算能力，然后向主节点转发添加有在网计算能力的查询报文。如此，主节点上的进程接收到添加有交换机1020的在网计算能力的查询报文，根据查询报文的query字段获得交换机网络102的在网计算能力，具体是本次集合通信涉及的交换机网络102的在网计算能力。其中，本实施例中的交换机网络102包括一个交换机1020，因此，交换机网络102的在网计算能力即为交换机1020的在网计算能力。

主节点上的进程根据上述在网计算能力生成通知报文，该通知报文用于通知交换机网络102的在网计算能力，然后交换机1020接收到通知报文时，向子节点上的进程转发上述通知报文。

如此，子节点上的进程可以知晓交换机网络102的在网计算能力，子节点上的进程在进行集合通信时，如执行一个成员到组内所有成员的广播操作时，子节点还可以根据在网计算能力将计算卸载到交换机1020。由此实现WRC的在网计算方案，提高了天气预报的效率。

需要说明的是，上述交换机1020在硬件上能够支持INC，在软件上支持对查询报文进行处理，具体是在查询报文中添加该交换机1020的在网计算能力。该交换机1020可以是自行研发的具有上述功能的交换机，也可以是基于本申请实施例提供的上述方法对已有交换机进行改造得到。计算节点104可以是自行研发的服务器，也可以是通用服务器，服务器上部署有对应的MPI。

本申请实施例提供的上述方法还可以应用于云环境。具体地，计算节点104可以是云平个中的云计算设备，例如计算节点104可以是基础设施即服务(Infrastructure as aService，IaaS)平个中的云服务器。交换机网络102中的交换机1020可以是云平个中的交换机，即云交换机。云计算设备复用通信域的上下文传递控制报文，从而获得云交换机的在网计算能力，根据该在网计算能力将负载卸载到云交换机，可以优化集合通信性能，提供更加弹性高效的按需分配业务。

上文结合图1至图9对本申请实施例提供的集合通信系统中控制报文处理方法进行了详细介绍，下面将结合附图对本申请实施例提供的集合通信系统中控制报文装置以及交换机、第一计算节点、第二计算节点等设备等进行介绍。

参见图10所示的集合通信系统中控制报文处理装置的结构示意图。所述集合通信系统包括交换机网络和多个计算节点，所述交换机网络包括个第一交换机，所述装置1000包括：

通信模块1002，用于转发由源节点传输至目的节点的查询报文，所述查询报文用于请求查询所述交换机网络的在网计算能力，所述查询报文由所述源节点根据所述集合通信系统的上下文生成，所述源节点和所述目的节点为所述多个计算节点中的不同节点；

所述通信模1002，还用于转发由所述目的节点传输至所述源节点的通知报文，所述通知报文携带所述交换机网络的在网计算能力。

在一些可能的实现方式中，所述装置1000还包括：

处理模块1004，用于接收到查询报文时，在所述查询报文中添加所述第一交换机的在网计算能力；

所述通信模块1002具体用于：

向目的节点转发添加有所述第一交换机的在网计算能力的查询报文。

在一些可能的实现方式中，所述第一交换机的在网计算能力包括所述第一交换机支持的集合操作类型和/或数据类型。

在一些可能的实现方式中，所述第一交换机的在网计算能力包括所述第一交换机的在网计算剩余可用资源的大小。

在一些可能的实现方式中，所述装置还包括：

处理模块1004，用于根据所述查询报文的跳数建立表项，所述表项用于所述第一交换机对业务报文进行计算卸载。

在一些可能的实现方式中，所述第一交换机直连所述源节点和所述目的节点；

所述通信模块1002具体用于：

接收所述源节点发送的查询报文，转发所述查询报文至所述目的节点；

接收所述目的节点发送的通知报文，转发所述通知报文至所述源节点。

在一些可能的实现方式中，所述交换机网络还包括第二交换机和/或第三交换机，所述第二交换机用于连接所述第一交换机和所述源节点，所述第三交换机用于连接所述第一交换机和所述目的节点；

所述通信模块1002具体用于：

接收所述源节点发送的查询报文，转发所述查询报文至所述第三交换机；

接收所述第三交换机转发的通知报文，将所述通知报文转发至所述源节点；或者，

接收所述第二交换机转发的查询报文，转发所述查询报文至所述目的节点；

接收所述目的节点发送的通知报文，将所述通知报文转发至所述第二交换机；或者，

接收所述第二交换机转发的查询报文，转发所述查询报文至所述第三交换机；

接收所述第三交换机转发的通知报文，将所述通知报文转发至所述第二交换机。

在一些可能的实现方式中，所述交换机网络包括单层交换机，所述第一交换机为所述单层交换机；

所述通信模块1002具体用于：

向所述源节点转发所述通知报文。

在一些可能的实现方式中，所述交换机网络包括上层交换机和下层交换机，所述第一交换机为所述下层交换机；

所述装置1000还包括：

处理模块1004，用于根据所述上层交换机的在网计算剩余可用资源的大小从所述上层交换机中确定目标交换机，在通知报文中添加所述目标交换机的在网计算剩余可用资源的大小；

所述通信模块1002具体用于：

向所述源节点转发添加有所述目标交换机的在网计算剩余可用资源的大小的通知报文。

在一些可能的实现方式中，所述处理模块1004具体用于：

根据所述在网计算剩余可用资源的大小，利用负载均衡策略从所述上层交换机中确定目标交换机。

在一些可能的实现方式中，所述通信模块1002还用于：

向所述上层交换机发送交换机查询报文，所述交换机查询报文用于查询所述上层交换机的在网计算剩余可用资源的大小；

接收所述上层交换机发送的交换机通知报文，所述交换机通知报文用于通知所述上层交换机的在网计算剩余可用资源的大小。

在一些可能的实现方式中，所述交换机网络包括上层交换机和下层交换机，所述第一交换机为所述上层交换机；

所述通信模块1002还用于：

接收所述下层交换机发送的交换机查询报文，所述交换机查询报文用于查询所述第一交换机的在网计算剩余可用资源的大小；

向所述下层交换机发送交换机通知报文，所述交换机通知报文用于向所述下层交换机通知所述第一交换机的在网计算剩余可用资源的大小。

在一些可能的实现方式中，所述集合通信系统的上下文包括应用的上下文或者通信域的上下文。

在一些可能的实现方式中，所述多个计算节点包括主节点和至少一个子节点；

所述源节点为所述子节点，所述目的节点为所述主节点；或者，

所述源节点为所述主节点，所述目的节点为所述子节点。

根据本申请实施例的集合通信系统中控制报文处理装置1000可对应于执行本申请实施例中描述的方法，并且集合通信系统中控制报文处理装置1000的各个模块/单元的上述和其它操作和/或功能分别为了实现图5至图9所示实施例中的各个方法的相应流程，为了简洁，在此不再赘述。

图10所示实施例提供的集合通信系统中控制报文处理装置1000具体是与交换机1020对应的装置。本申请实施例还提供了与第一计算节点、第二计算节点分别对应的装置。

参见图11所示的集合通信系统中控制报文处理装置1100的结构示意图。所述集合通信系统包括交换机网络和多个计算节点，所述交换机网络包括至少一个交换机，所述装置1100包括：

通信模块1102，用于接收所述交换机网络中的一个或多个交换机转发的查询报文，所述查询报文用于请求查询所述交换机网络的在网计算能力，所述查询报文由所述第二计算节点根据所述集合通信系统的上下文生成；

生成模块1104，用于根据所述查询报文生成通知报文，所述通知报文携带所述交换机网络的在网计算能力；

所述通信模块1102，还用于向所述第二计算节点发送所述通知报文。

在一些可能的实现方式中，所述交换机转发的查询报文包括所述交换机添加的、所述交换机的在网计算能力；

所述生成模块1104具体用于：

根据所述一个或多个交换机转发的查询报文中所述一个或多个交换机的在网计算能力，获得所述交换机网络的在网计算能力；

根据所述交换机网络的在网计算能力生成通知报文。

在一些可能的实现方式中，所述装置1100部署于所述第一计算节点，所述第一计算节点为主节点或子节点。

根据本申请实施例的集合通信系统中控制报文处理装置1100可对应于执行本申请实施例中描述的方法，并且集合通信系统中控制报文处理装置1100的各个模块/单元的上述和其它操作和/或功能分别为了实现图8或图9所示实施例中的各个方法的相应流程，为了简洁，在此不再赘述。

接下来，参见图12所示的集合通信系统中控制报文处理装置1200的结构示意图。所述集合通信系统包括交换机网络和多个计算节点，所述交换机网络包括至少一个交换机，所述装置1200包括：

生成模块1202，用于根据所述集合通信系统的上下文生成查询报文，所述查询报文用于请求查询所述交换机网络的在网计算能力；

通信模块1204，用于通过所述交换机网络中的一个或多个交换机向所述第一计算节点发送所述查询报文；

所述通信模块，还用于接收所述第一计算节点通过所述一个或多个交换机转发的通知报文，所述通知报文携带所述交换机网络的在网计算能力，所述通知报文由所述第一计算节点根据所述查询报文生成。

在一些可能的实现方式中，所述装置部署于所述第一计算节点，所述第二计算节点为主节点或子节点。

根据本申请实施例的集合通信系统中控制报文处理装置1200可对应于执行本申请实施例中描述的方法，并且集合通信系统中控制报文处理装置1200的各个模块/单元的上述和其它操作和/或功能分别为了实现图8或图9所示实施例中的各个方法的相应流程，为了简洁，在此不再赘述。

基于图10、图11、图12所示的实施例提供的集合通信系统中控制报文处理装置1000、集合通信系统中控制报文处理装置1100以及集合通信系统中控制报文处理装置1200，本申请实施例还提供了一种集合通信系统100。

为了便于描述，本申请实施例将上述集合通信系统中控制报文处理装置1000、集合通信系统中控制报文处理装置1100以及集合通信系统中控制报文处理装置1200分别简称为控制报文处理装置1000、控制报文处理装置1100以及控制报文处理装置1200。

参见图13所示的集合通信系统100的结构示意图，该集合通信系统100包括交换机网络102和多个计算节点104。其中，交换机网络102包括至少一个交换机1020，该交换机1020具体用于实现如图10所示的控制报文处理装置1000的功能。多个计算节点104中包括一个目的节点以及至少一个源节点。目的节点具体用于实现如图11所示的控制报文处理装置1100的功能。源节点具体用于实现如图12所示的控制报文处理装置1200的功能。

具体地，源节点用于根据所述集合通信系统100的上下文生成查询报文，所述查询报文用于请求查询所述交换机网络102的在网计算能力。所述交换机1020用于转发由所述源节点传输至所述目的节点的查询报文。目的节点用于根据所述查询报文生成通知报文，所述通知报文携带所述交换机网络的在网计算能力。所述交换机1020，还用于转发由所述目的节点传输至所述源节点的通知报文。

在一些可能的实现方式中，交换机1020具体用于：

接收到查询报文时，在所述查询报文中添加所述交换机1020的在网计算能力；

向目的节点转发添加有所述交换机1020的在网计算能力的查询报文；

对应地，目的节点具体用于：

根据所述交换机1020转发的查询报文中所述交换机1020的在网计算能力，获得所述交换机网络102的在网计算能力；

根据所述交换机网络102的在网计算能力生成通知报文。

在一些可能的实现方式中，所述交换机1020的在网计算能力包括所述交换机1020支持的集合操作类型和/或数据类型。

在一些可能的实现方式中，所述交换机1020的在网计算能力还包括所述交换机1020的在网计算剩余可用资源的大小。

在一些可能的实现方式中，交换机1020还用于：

根据所述查询报文的跳数建立表项，所述表项用于所述交换机1020对业务报文进行计算卸载。

在一些可能的实现方式中，交换机1020直连源节点和目的节点时，交换机1020具体用于：

接收所述源节点发送的查询报文，转发所述查询报文至所述目的节点；

接收所述目的节点发送的通知报文，转发所述通知报文至所述源节点。

在一些可能的实现方式中，所述交换机网络102还包括第二交换机和/或第三交换机，所述第二交换机用于连接所述交换机1020和所述源节点，所述第三交换机用于连接所述交换机1020和所述目的节点；

所述交换机1020具体用于：

接收所述源节点发送的查询报文，转发所述查询报文至所述第三交换机；

接收所述第三交换机转发的通知报文，将所述通知报文转发至所述源节点；或者，

接收所述第二交换机转发的查询报文，转发所述查询报文至所述目的节点；

接收所述目的节点发送的通知报文，将所述通知报文转发至所述第二交换机；或者，

接收所述第二交换机转发的查询报文，转发所述查询报文至所述第三交换机；

接收所述第三交换机转发的通知报文，将所述通知报文转发至所述第二交换机。

在一些可能的实现方式中，所述交换机网络102包括单层交换机，所述交换机1020为单层交换机，所述交换机1020具体用于：

向所述源节点转发所述通知报文。

在一些可能的实现方式中，所述交换机网络102包括上层交换机和下层交换机，所述交换机1020为所述下层交换机；

所述交换机1020具体用于：

根据所述上层交换机的在网计算剩余可用资源的大小从所述上层交换机中确定目标交换机；

在通知报文中添加所述目标交换机的在网计算剩余可用资源的大小；

向所述源节点转发添加有所述目标交换机的在网计算剩余可用资源的大小的通知报文。

在一些可能的实现方式中，所述交换机1020还用于：

根据所述上层交换机的在网计算剩余可用资源的大小，利用负载均衡策略从所述上层交换机中确定目标交换机。

在一些可能的实现方式中，所述交换机1020还用于：

向所述上层交换机发送交换机查询报文，所述交换机查询报文用于查询所述上层交换机的在网计算剩余可用资源的大小；

接收所述上层交换机发送的交换机通知报文，所述交换机通知报文用于向交换机1020通知所述上层交换机的在网计算剩余可用资源的大小。

在一些可能的实现方式中，所述交换机网络102包括上层交换机和下层交换机，所述交换机1020为所述上层交换机；

所述交换机1020还用于：

接收所述下层交换机发送的交换机查询报文，所述交换机查询报文用于查询所述交换机1020的在网计算剩余可用资源的大小；

向所述下层交换机发送交换机通知报文，所述交换机通知报文用于向所述下层交换机通知所述交换机1020的在网计算剩余可用资源的大小。

在一些可能的实现方式中，所述集合通信系统的上下文包括应用的上下文或者通信域的上下文。

在一些可能的实现方式中，所述多个计算节点包括主节点和至少一个子节点；

所述源节点为所述子节点，所述目的节点为所述主节点；或者，

所述源节点为所述主节点，所述目的节点为所述子节点。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、ROM、RAM、磁碟或者光盘等，包括若干指令用以使得一个计算机设备(可以是个人计算机，训练设备，或者网络设备等)执行本申请各个实施例所述的方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、训练设备或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、训练设备或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的训练设备、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(Solid State Disk，SSD))等。

以上所述，仅为本申请的具体实施方式。熟悉本技术领域的技术人员根据本申请提供的具体实施方式，可想到变化或替换，都应涵盖在本申请的保护范围之内。