CN110392017B - 处理rpc报文的方法及相关装置 - Google Patents

处理rpc报文的方法及相关装置 Download PDF

Info

Publication number
CN110392017B
CN110392017B CN201810350094.3A CN201810350094A CN110392017B CN 110392017 B CN110392017 B CN 110392017B CN 201810350094 A CN201810350094 A CN 201810350094A CN 110392017 B CN110392017 B CN 110392017B
Authority
CN
China
Prior art keywords
message
rpc
processing
duration
timeout
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201810350094.3A
Other languages
English (en)
Other versions
CN110392017A (zh
Inventor
雷歆
黄业钦
罗潇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201810350094.3A priority Critical patent/CN110392017B/zh
Publication of CN110392017A publication Critical patent/CN110392017A/zh
Application granted granted Critical
Publication of CN110392017B publication Critical patent/CN110392017B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/133—Protocols for remote procedure calls [RPC]

Abstract

本公开提供了一种处理RPC报文的方法及相关装置，属于网络通信技术领域。该方法包括：接收发送端的指定业务的RPC报文；通过该指定业务的业务模块，处理该RPC报文；在处理该RPC报文的过程中，当确定在该RPC报文对应的超时等待时长内处理不完该RPC报文时，向该发送端发送第一回应报文，该第一回应报文用于指示该发送端增加该超时等待时长。本公开实现了在某个RPC报文对应的超时等待时长不足时，只修改该RPC报文对应的超时等待时长，不需要修改客户端和服务器的核心代码，也不会增加其他业务的RPC报文对应的超时等待时长，从而整体上提高了处理RPC报文的效率。

Description

处理RPC报文的方法及相关装置
技术领域
本公开涉及网络通信技术领域，特别涉及一种处理RPC报文的方法及相关装置。
背景技术
网络配置协议(Network Configuration Protocol，NETCONF)是一种新的网络配置和管理协议，NETCONF采用可扩展标记语言(Extensible Markup Language，XML)作为配置数据和协议消息的编码方式，使用客户端/服务器(Client/Server，C/S)和远程过程调用(Remote Procedure Call，RPC)方式来管理设备中的信息。因此，在使用NETCONF协议的场景下，客户端与服务器之间通过RPC报文来进行信息交互。
当客户端向服务器发送RPC报文后，会进入等待状态，以等待服务器的回应(rpc-reply)报文；客户端接收到回应报文后，根据该回应报文退出等待状态，以进行后续操作。为了防止客户端陷入无限期的等待而耽误其他操作，客户端与服务器之间约定一个固定时长。客户端将所有业务的RPC报文对应的超时等待时长均设置为该固定时长。如果客户端在发送RPC报文之后的该超时等待时长内没有接收到服务器返回的回应报文，则客户端也会退出等待状态。
由于所有业务的RPC报文对应的超时等待时长均为该固定时长，当某个业务的RPC报文的处理时长较长时，需要修改客户端和服务器的核心代码，以增加该固定时长。由此可见，上述方法会增加所有业务的RPC报文对应的超时等待时长，从而导致所有业务的RPC报文的处理效率低。
发明内容
为了解决现有技术的问题，本公开实施例提供了一种处理RPC报文的方法及相关装置。
第一方面，本公开实施例提供了一种处理RPC报文的方法，所述方法包括：
接收发送端的指定业务的远程过程调用RPC报文；
通过所述指定业务的业务模块，处理所述RPC报文；
在处理所述RPC报文的过程中，当确定在所述RPC报文对应的超时等待时长内处理不完所述RPC报文时，向所述发送端发送第一回应报文，所述第一回应报文用于指示所述发送端增加所述超时等待时长。
在本公开实施例中，在处理RPC报文的过程中，当确定在该RPC报文对应的超时等待时长内处理不完该RPC报文时，向发送端发送第一回应报文，以指示发送端增加该RPC报文对应的超时等待时长。从而实现了在某个RPC报文对应的超时等待时长不足时，只修改该RPC报文对应的超时等待时长，不需要修改客户端和服务器的核心代码，也不会增加其他业务的RPC报文对应的超时等待时长，整体提高了处理RPC报文的效率。
在第一方面的第一种可能实现方式中，所述方法还包括：
确定所述RPC报文对应的超时等待时长，以及统计所述RPC报文的处理时长；
当所述超时等待时长与所述处理时长之间的差值小于预设阈值时，确定在所述RPC报文对应的超时等待时长内处理不完所述RPC报文。
在本公开实施例中，由接收端基于该RPC报文对应的超时等待时长和该RPC报文的处理时长进行比较，从而确定出在该RPC报文对应的超时等待时长内是否能够处理完该RPC报文，提高了效率。
在第一方面的第二种可能实现方式中，所述方法还包括：
接收所述业务模块发送的增加超时等待时间的处理请求，根据所述处理请求，确定在所述RPC报文对应的超时等待时长内处理不完所述RPC报文。
在本公开实施例中，由业务模块确定出在该RPC报文对应的超时等待时长内处理不完该RPC报文时，向接收端发送增加超时等待时长的处理请求，从而接收端基于该处理请求，就可以知道在该RPC报文对应的超时等待时长内处理不完该RPC报文，减轻了接收端的负担。
在第一方面的第三种可能实现方式中，所述向所述发送端发送第一回应报文之前，所述方法还包括：
确定所述发送端是否支持超时等待时长的协商能力；
当所述发送端支持所述协商能力时，执行所述向所述发送端发送第一回应报文的步骤。
在本公开实施例中，在向发送端发送第一回应报文之前，先确定该发送端是否支持超时等待时长的协商能力；当该发送端支持该协商能力时，才向发送端发送第一回应报文，从而避免了由于该发送端不支持该协商能力，而发送第一回应报文导致的资源浪费。
在第一方面的第四种可能实现方式中，所述确定所述发送端是否支持超时等待时长的协商能力，包括：
接收所述发送端发送的第一握手报文，所述第一握手报文用于建立连接；
当所述第一握手报文中携带指示支持超时等待时长的协商能力的指定标签时，确定所述发送端支持超时等待时长的协商能力。
在本公开实施例中，在第一握手报文中携带超时等待时长的能力，从而保证在接收端修改该RPC报文对应的超时等待时长时，不需要修改发送端的代码就可以使用新的超时等待时长进行通讯，简化了处理过程，从而提高了效率。
在第一方面的第五种可能实现方式中，所述第一回应报文携带增加时长，所述增加时长为预设时长或者所述RPC报文还需的处理时长。
在本公开实施例中，第一回应报文中可以携带增加时长，从而发送端直接基于该增加时长修改该RPC的超时等待时长，提高了效率。另外，该第一回应报文中还可以不携带增加时长，由发送端自己确定增加时长，提高了灵活性。
在第一方面的第六种可能实现方式中，所述接收发送端的指定业务的RPC报文之前，所述方法还包括：
在与所述发送端建立连接时，向所述发送端发送第二握手报文，所述第二握手报文携带指定处理时长，所述指定处理时长用于所述发送端设置所述超时等待时长。
在本公开实施例中，接收端在与发送端建立连接时，向发送端发送第二握手报文，基于该第二握手报文协商该RPC报文对应的超时等待时长，从而不需要再次发送通过其他消息，以协商该RPC报文对应的超时等待时长，提高了效率。
在第一方面的第七种可能实现方式中，所述向所述发送端发送第一回应报文之后，所述方法还包括：
当处理完所述RPC报文时，向所述发送端发送第二回应报文，所述第二回应报文用于指示所述RPC报文的处理结果。
在本公开实施例中，当处理完该RPC报文时，向发送端发送第二回应报文，以通知发送端该RPC报文的处理结果，从而使得发送端及时获知该RPC报文的处理结果。
第二方面，本公开实施例提供了一种处理RPC报文的方法，所述方法包括：
向接收端发送指定业务的远程过程调用RPC报文，所述RPC报文用于所述接收端通过所述指定业务的业务模块，处理所述RPC报文；
接收所述接收端的第一回应报文，所述第一回应报文用于指示增加所述RPC报文对应的超时等待时长；
根据所述第一回应报文，增加所述超时等待时长。
在本公开实施例中，接收端在处理RPC报文的过程中，当确定在该RPC报文对应的超时等待时长内处理不完该RPC报文时，向发送端发送第一回应报文，以指示发送端增加该RPC报文对应的超时等待时长。发送端接收到该第一回应报文时，增加该超时等待时长。从而实现了在某个RPC报文对应的超时等待时长不足时，只修改该RPC报文对应的超时等待时长，不需要修改客户端和服务器的核心代码，也不会增加其他业务的RPC报文对应的超时等待时长，从而整体提高了处理RPC报文的效率。
在第二方面的第一种可能实现方式中，所述根据所述第一回应报文，增加所述超时等待时长，包括：
所述第一回应报文携带增加时长，从所述第一回应报文中获取所述增加时长；
在所述超时等待时长的基础上增加所述增加时长的等待时长。
在本公开实施例中，第一回应报文中可以携带增加时长，从而发送端直接基于该增加时长修改该RPC的超时等待时长，提高了效率。
在第二方面的第二种可能实现方式中，所述向接收端发送指定业务的RPC报文之前，所述方法还包括：
向所述接收端发送第一握手报文，所述第一握手报文用于建立连接，且所述第一握手报文携带指示支持超时等待时长的协商能力的指定标签。
在本公开实施例中，在第一握手报文中携带超时等待时长的能力，从而保证在接收端修改该RPC报文对应的超时等待时长时，不需要修改发送端的代码就可以使用新的超时等待时长进行通讯，简化了处理过程，从而提高了效率。
在第二方面的第三种可能实现方式中，所述向接收端发送指定业务的RPC报文之前，所述方法还包括：
在与所述接收端建立连接时，接收所述接收端的第二握手报文，所述第二握手报文携带指定处理时长；
根据所述指定处理时长，设置所述超时等待时长。
在本公开实施例中，接收端在与发送端建立连接时，向发送端发送第二握手报文，基于该第二握手报文协商该RPC报文对应的超时等待时长，从而不需要再次发送通过其他消息，以协商该RPC报文对应的超时等待时长，提高了效率。
在第二方面的第四种可能实现方式中，所述根据所述第一回应报文，增加所述超时等待时长之后，所述方法还包括：
接收所述接收端的第二回应报文，所述第二回应报文为所述接收端在处理完所述RPC报文发送的；
根据所述第二回应报文，确定所述RPC报文的处理结果。
在本公开实施例中，当处理完该RPC报文时，向发送端发送第二回应报文，以通知发送端该RPC报文的处理结果，从而使得发送端及时获知该RPC报文的处理结果。
第三方面，本公开实施例提供了一种处理RPC报文的装置，所述装置包括：
接收单元，用于接收发送端的指定业务的远程过程调用RPC报文；
处理单元，用于通过所述指定业务的业务模块，处理所述RPC报文；
发送单元，用于在处理所述RPC报文的过程中，当确定在所述RPC报文对应的超时等待时长内处理不完所述RPC报文时，向所述发送端发送第一回应报文，所述第一回应报文用于指示所述发送端增加所述超时等待时长。
在第三方面的第一种可能实现方式中，所述装置还包括：
第一确定单元，用于确定所述RPC报文对应的超时等待时长；
统计单元，用于统计所述RPC报文的处理时长；
所述第一确定单元，还用于当所述超时等待时长与所述处理时长之间的差值小于预设阈值时，确定在所述RPC报文对应的超时等待时长内处理不完所述RPC报文。
在第三方面的第二种可能实现方式中，所述装置还包括：
所述接收单元，还用于接收所述业务模块发送的增加超时等待时间的处理请求；
第二确定单元，用于根据所述处理请求，确定在所述RPC报文对应的超时等待时长内处理不完所述RPC报文。
在第三方面的第三种可能实现方式中，所述装置还包括：
第三确定单元，用于确定所述发送端是否支持超时等待时长的协商能力；
所述发送单元，还用于当所述发送端支持所述协商能力时，向所述发送端发送第一回应报文。
在第三方面的第四种可能实现方式中，所述接收单元，还用于接收所述发送端发送的第一握手报文，所述第一握手报文用于建立连接；
所述第三确定单元，还用于当所述第一握手报文中携带指示支持超时等待时长的协商能力的指定标签时，确定所述发送端支持超时等待时长的协商能力。
在第三方面的第五种可能实现方式中，所述第一回应报文携带增加时长，所述增加时长为预设时长或者所述RPC报文还需的处理时长。
在第三方面的第六种可能实现方式中，所述发送单元，还用于在与所述发送端建立连接时，向所述发送端发送第二握手报文，所述第二握手报文携带指定处理时长，所述指定处理时长用于所述发送端设置所述超时等待时长。
在第三方面的第七种可能实现方式中，所述发送单元，还用于当处理完所述RPC报文时，向所述发送端发送第二回应报文，所述第二回应报文用于指示所述RPC报文的处理结果。
第四方面，本公开实施例提供了一种处理RPC报文的装置，所述装置包括：
发送单元，用于向接收端发送指定业务的远程过程调用RPC报文，所述RPC报文用于所述接收端通过所述指定业务的业务模块，处理所述RPC报文；
接收单元，用于接收所述接收端的第一回应报文，所述第一回应报文用于指示增加所述RPC报文对应的超时等待时长；
增加单元，用于根据所述第一回应报文，增加所述超时等待时长。
在第四方面的第一种可能实现方式中，所述第一回应报文携带增加时长；
所述增加单元，还用于从所述第一回应报文中获取所述增加时长，在所述超时等待时长的基础上增加所述增加时长的等待时长。
在第四方面的第二种可能实现方式中，所述发送单元，还用于向所述接收端发送第一握手报文，所述第一握手报文用于建立连接，且所述第一握手报文携带指示支持超时等待时长的协商能力的指定标签。
在第四方面的第三种可能实现方式中所述装置还包括：
所述接收单元，还用于在与所述接收端建立连接时，接收所述接收端的第二握手报文，所述第二握手报文携带指定处理时长；
设置单元，用于根据所述指定处理时长，设置所述超时等待时长。
在第四方面的第四种可能实现方式中，所述装置还包括：
所述接收单元，还用于接收所述接收端的第二回应报文，所述第二回应报文为所述接收端在处理完所述RPC报文发送的；
确定单元，用于根据所述第二回应报文，确定所述RPC报文的处理结果。
第五方面，本公开实施例提供了一种设备，所述设备包括：处理器、存储器、通信接口及总线；
其中，所述存储器、所述处理器及所述通信接口通过所述总线连接，所述存储器上存储有可编程指令，所述处理器调用所述存储器上存储的可编程指令用于执行第一方面或者第一方面的任一项可能实现方式所述的方法。
第六方面，本公开实施例提供了一种设备，所述设备包括：处理器、存储器、通信接口及总线；
其中，所述存储器、所述处理器及所述通信接口通过所述总线连接，所述存储器上存储有可编程指令，所述处理器调用所述存储器上存储的可编程指令用于执行第二方面或者第二方面的任一项可能实现方式所述的方法。
第七方面，本公开实施例提供了一种计算机可读存储介质，所述存储介质包括指令，当其在计算机上运行时，使得所述计算机执行第一方面或者第一方面的任一项可能实现方式所述的方法。
第八方面，本公开实施例提供了一种计算机可读存储介质，所述存储介质包括指令，当其在计算机上运行时，使得所述计算机执行第二方面或者第二方面的任一项可能实现方式所述的方法。
第九方面，本公开实施例提供了一种计算机程序产品，所述计算机程序产品包括至少一条指令，所述指令由处理器加载并执行以实现上述第一方面或者第一方面的任一种可能实现方式所述的方法。
第十方面，本公开实施例提供了一种计算机程序产品，所述计算机程序产品包括至少一条指令，所述指令由处理器加载并执行以实现上述第二方面或者第二方面的任一种可能实现方式所述的方法。
附图说明
图1是本公开实施例提供的一种处理RPC报文的系统架构图；
图2是本公开实施例提供的一种NETCONF协议的结构示意图；
图3是本公开实施例提供的一种设备的结构示意图；
图4是本公开实施例提供的一种处理RPC报文的方法流程图；
图5是本公开实施例提供的一种处理RPC报文的装置结构示意图；
图6是本公开实施例提供的另一种处理RPC报文的装置结构示意图；
图7是本公开实施例提供的一种服务器的结构示意图；
图8是本公开实施例提供的一种客户端的结构示意图。
具体实施方式
为使本公开的目的、技术方案和优点更加清楚，下面将结合附图对本公开实施方式作进一步地详细描述。
本公开实施例提供了一种处理RPC报文的系统架构，参见图1，该系统架构中包括发送端101和接收端102。发送端101和接收端102之间通过NETCONF协议通信。参见图2，该NETCONF协议分为四个层次，从下往上分别为传输层、消息层、操作层和内容层。其中，传输层提供安全的NETCONF数据承载通道，该NETCONF数据承载通道可以为安全外壳(SecureShell，SSH)通道、安全传输层(Transport Layer Security，TLS)通道、简单对象访问协议(Simple Object Access Protocol，SOAP)通道、块可扩展交换协议(Blocks ExtensibleExchange Protocol，BEEP)通道。消息层也称RPC层，该消息层定义了RPC报文：<rpc>和RPC报文的回应报文：<rpc-reply>，该消息层还定义了Notification的编码机制，该编码机制可以为可扩展标记语言(Extensible Markup Language，XML)。该操作层定义了一组基本的协议操作，该协议操作可以为查询设备配置数据或者编辑设备配置数据等，并且，该协议操作也以XML作为编码机制。该内容层定义了数据对象，以及负责定义具体业务特性功能的数据，并且，该内容层也以XML作为编码机制。
其中，消息层的基本元素包括<rpc>和<rpc-reply>，<rpc>用来封装发送端101发送给接收端102的请求，并且，<rpc>的任何属性，都在<rpc-reply>中原样返回。其中，<rpc>的标准属性有消息标识(message-id)，message-id用来关联<rpc>和<rpc-reply>，并且<rpc>可以扩展定义私有属性。<rpc-reply>用来封装rpc报文的应答消息，<rpc-reply>的类型包括<ok>、<rpc-error>和<rpc-timeout>。该<ok>表示RPC报文处理成功。<rpc-error>表示RPC报文处理失败，且该<rpc-error>中携带该RPC报文处理失败的错误信息。<rpc-timeout>为本公开新增的类型，表示增加超时等待时长。
操作层的业务包括：
1)<lock>/<unlock>：数据集的加/解锁操作，粒度为startup/candidate/running。其中，running为系统当前生效的配置数据集；startup为系统重启生效的数据集；candidate为可以编辑，但不影响设备的当前配置的数据集，并可以提交到running数据集中。
2)<edit-config>/<get-config>：修改和查询数据集中的配置，修改操作仅限用于candidate和running数据集
3)<copy-config>/<delete-config>：覆盖或清空数据集的配置，清空操作仅限用于startup数据集
4)<get>：查询系统的状态和运行配置(即running数据集中的配置)。
5)<commit>/<discard-changes>：将candidate数据集中的配置提交到running数据集/清空candidate数据集中的配置。
6)<kill-session>/<close-session>：结束当前会话，kill会终止当前所有的操作，close可以做些善后工作。
需要说明的是，发送端101可以为客户端或者服务器，接收端102可以为服务器或者客户端。在本公开实施例中，以发送端101为客户端，接收端102为服务器为例进行说明。并且，本公开实施例提供的处理RPC报文的方法可以在任意具有通用计算机结构的硬件设备上执行(例如，客户端或者服务器)。如图3所示，该硬件设备上包括中央处理器(centralprocessing unit，CPU)、存储设备(硬盘或者flash)、控制器和驱动器；该CPU是执行机构，该存储设备用于在断电状态下存储程序代码，驱动器用于驱动控制器，以使控制器控制CPU在上电时，将存储设备中的程序代码读入内存中，并被CPU读取后执行。在断电时，该内存中的程序代码被清除。
本公开实施例提供了一种处理RPC报文的方法，该方法应用在发送端和接收端之间。在本公开实施例中，以发送端为客户端，接收端为服务器为例进行说明。参见图4，该方法包括：
步骤201：客户端向服务器发送指定业务的RPC报文，进入等待状态。
当客户端指示服务器执行指定业务的NETCONF操作时，客户端向服务器发送RPC报文，该RPC报文携带为该RPC报文分配的message-id。客户端向服务器发送RPC报文后，会等待服务器的回应，因此，客户端向服务器发送该RPC报文后，进入等待状态。为了防止客户端陷入无限期的等待而耽误其他操作，客户端确定该RPC报文对应的超时等待时长，在发送该RPC报文之后的该超时等待时长内没有接收到服务器返回的回应报文时，客户端退出等待状态。其中，指定业务为客户端与服务器之间的任一业务；例如，该指定业务可以为查询数据集中的配置或者下载文件等。
该RPC报文对应的超时时长可以根据指定业务的业务类型进行设置，也可以根据RPC报文的message-id进行设置。并且，本公开中客户端可以通过以下方式确定该RPC报文对应的超时等待时长。
(一)：开发人员在开发该客户端时，会设置一个系统默认的时长。相应的，客户端确定该RPC报文对应的超时等待时长的步骤可以为：客户端将该系统默认的时长作为该RPC报文对应的超时等待时长。其中，该系统默认的时长可以根据需要进行设置并更改，在本公开实施例中，对该系统默认的时长不作具体限定。
(二)：在客户端向服务器发送该RPC报文之前，客户端与服务器之间建立连接，服务器通过该连接向客户端发送指定处理时长。客户端可以将该指定处理时长作为该超时等待时长。该指定处理时长为该RPC报文的通用处理时长，该指定处理时长可以为服务器对多个RPC报文的平均处理时长。相应的，客户端确定该RPC报文对应的超时等待时长的步骤可以为：
客户端接收服务器发送的第二握手(hello)报文，该第二握手报文中携带指定处理时长。客户端将该指定处理时长作为该RPC报文对应的超时等待时长。当该第二握手报文携带指定处理时长时，该第二握手报文的格式如下：
<hello xmlns＝"urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.1
</capability>
<capability>
urn:ietf:params:netconf:capability:startup:1.0
</capability>
<capability>
urn:ietf:params:netconf:capability:timeout:180
</capability>
</capabilities>
<session-id>4</session-id>
</hello>
其中，该hello报文(第二握手报文)中的URL：
urn:ietf:params:netconf:capability:timeout:180
表示服务器端的该RPC报文的处理时长最多需要180秒。客户端根据此URL设置自己的超时等待时长至少为180秒。
在本步骤中，客户端也可以在该指定处理时长的基础上增加第一预设时长作为该RPC报文对应的超时等待时长，从而提高可靠性。客户端还可以在该指定处理时长的基础上减少第二预设时长作为该RPC报文对应的超时等待时长，从而提高后续RPC报文的处理效率。
第一预设时长和第二预设时长可以相等，也可以不相等。并且，第一预设时长和第二预设时长都可以根据需要进行设置并更改，在本公开实施例中，对第一预设时长和第二预设时长都不作具体限定。例如，第一预设时长和第二预设时长相等，均为1s或者2s等。
(三)：客户端获取系统默认的时长以及服务器反馈的指定处理时长，如果服务器反馈的指定处理时长比客户端的系统默认的时长大，客户端取该指定处理时长作为该RPC报文对应的超时等待时长；如果客户端的系统默认的时长比服务器反馈的该指定处理时长大，客户端取该客户端的系统默认的时长作为该RPC报文的处理时长。相应的，客户端确定该RPC报文对应的超时等待时长的步骤可以为：
客户端获取服务器反馈的指定处理时长，将该指定处理时长和系统默认的时长中的较大的时长作为该RPC报文对应的超时等待时长。
(四):客户端可以设置不同业务类型的RPC报文对应不同的超时等待时长。相应的，客户端确定该RPC报文对应的超时等待时长的步骤可以为：
客户端确定该指定业务的业务类型，根据该业务类型，确定该业务类型对应的超时等待时长作为该RPC报文对应的超时等待时长。其中，客户端中存储业务类型和超时等待时长的对应关系，相应的，客户端根据该业务类型，确定该业务对应的超时等待时长的步骤可以为：客户端根据该业务类型，从业务类型和超时等待时长的对应关系中获取该业务类型对应的超时等待时长。
(五)：客户端可以设置不同RPC报文对应不同的超时等待时长，并且客户端中存储RPC报文的message-id和超时等待时长的对应关系。相应的，客户端确定该RPC报文对应的超时等待时长的步骤可以为：
客户端根据该RPC报文的message-id，从message-id和超时等待时长的对应关系中获取该RPC报文对应的超时等待时长。
需要说明的一点是，以上几种确定超时等待时长的方法仅为举例，并不对本发明造成具体限定。并且，客户端确定出该RPC报文对应的超时等待时长之后，将该RPC报文对应的超时等待时长通知给服务器。在本步骤中，客户端可以将该RPC报文对应的超时等待时长承载在任一消息中发送给服务器，例如，客户端与服务器之间建立连接时，客户端向服务器发送第一握手报文，该客户端将该RPC报文对应的超时等待时长承载在第一握手报文中，也即第一握手报文中携带该RPC报文对应的超时等待时长。
需要说明的另一点是，在本公开实施例中，也可以由服务器确定该RPC报文对应的超时等待时长，将该超时等待时长承载在第一握手报文中发送给客户端。当然，也可以由服务器和客户端基于相同的确定规则，确定该RPC报文对应的超时等待时长，以便于客户端和服务器确定出相同的超时等待时长，从而不需要再次同步该超时等待时长。
步骤202：服务器接收发送端的该RPC报文，通过指定业务的业务模块，处理该RPC报文。
服务器中包括多个业务模块，不同的业务模块用于处理不同的RPC报文；并且，服务器中存储业务和业务模块ID的对应关系。相应的，本步骤可以为：服务器根据该指定业务，从业务和业务模块ID的对应关系中获取该指定业务对应的业务模块的ID，根据该业务模块的ID向该业务模块发送处理请求，该处理请求携带该RPC报文，以指示该业务模块处理该RPC报文。
需要说明的是，服务器在获知该RPC报文对应的超时等待时长之后，该服务器将该超时等待时长通知该业务模块。服务器可以将该RPC报文对应的超时等待时长承载在任一消息中发送给业务模块；例如，服务器将该RPC报文对应的超时等待时长承载在该处理请求中，也即该处理请求中不仅携带该RPC报文，还携带该RPC报文对应的超时等待时长。
步骤203：在处理该RPC报文的过程中，当确定在该RPC报文对应的超时等待时长内处理不完该RPC报文时，服务器向客户端发送第一回应报文，第一回应报文用于指示客户端增加超时等待时长。
在该业务模块处理该RPC报文的过程中，服务器实时检测在该RPC报文对应的超时等待时长内是否能够处理完该RPC报文。当确定在该RPC报文对应的超时等待时长内处理不完该RPC报文时，执行步骤203。当确定在该RPC报文对应的超时等待时长内处理完该RPC报文时，等待该RPC报文的处理结果。
该第一回应报文中可以携带增加时长，该增加时长可以为第三预设时长，也可以为该RPC报文还需的处理时长。该RPC报文还需的处理时长可以由服务器统计得到，也可以由业务模块统计通知给服务器。第三预设时长可以根据需要进行设置并更改，在本公开实施例中，对第三预设时长不作具体限定；例如，第三预设时长可以为5s或者6s等。
需要说明的是，该第一回应报文是NETCONF协议中新增的一种报文，该第一回应报文用于增加超时时间，该第一回应报文的格式如下：
Figure BDA0001633164570000101
其中，<rpc-reply message-id＝"101"表示RPC报文的id为101，<timeout>60</timeout>表示增加时间。因此，上述第一回应报文表示服务器希望将message-id为101的RPC报文增加60秒的超时时间。
需要说明的另一点是，该第一回应报文中也可以不携带该增加时长，由客户端基于第一回应报文确定增加时长。
在一个可能的实现方式中，由于可能一些客户端支持超时等待时长的协商能力，有些客户端不支持该协商能力。因此，在服务器向客户端发送第一回应报文之前，服务器确定该客户端是否支持超时等待时长的协商能力；当该客户端支持该协商能力时，服务器才向客户端发送第一回应报文；当该客户端不支持该协商能力时，服务器不向客户端发送第一回应报文。
在客户端与服务器之间建立连接时，客户端会向服务器发送第一握手报文。当客户端支持该协商能力时，该第一握手报文中携带用于指示该客户端支持超时等待时长的协商能力的指定标签；当该客户端不支持该协商能力时，该第一握手报文中不携带该指定标签。因此，服务器确定该客户端是否支持该协商能力的步骤可以为：
服务器接收客户端发送的第一握手报文，第一握手报文用于建立连接。服务器确定该第一握手报文中是否携带该指定标签；当该第一握手报文中携带该指定标签时，服务器确定该客户端支持该协商能力；当该第一握手报文中不携带该指定标签时，服务器确定该客户端不支持该协商能力。第一握手报文的格式如下所示：
<hello xmlns＝"urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.1
</capability>
<capability>
urn:ietf:params:netconf:capability:startup:1.0
</capability>
<capability>
urn:ietf:params:netconf:capability:timeout:1.0
</capability>
</capabilities>
<session-id>4</session-id>
</hello>
该hello报文(第一握手报文)指示该客户端支持超时等待时长的协商能力。
需要说明的一点是，该第一握手报文中除了携带该指定标签以外，该第一握手报文中还可以携带该客户端支持的协商能力的版本号，不同的版本号用于指示不同级别的协商能力。例如，版本号为1，指示该客户端支持协商能力，但不支持自主获取增加时间；版本号为2，指示该客户端不仅支持协商能力，还支持自主获取增加时间。服务器根据该客户端支持的协商能力的版本号，确定该客户端支持的协商能力的级别，根据该级别向客户端发送第一回应报文。
在本步骤中，可以由服务器对该RPC报文的处理时长进行监控，以确定在该RPC报文对应的超时等待时长内是否能够处理完该RPC报文，也可以由业务模块对该RPC报文的处理时长进行监控，以确定在该RPC报文对应的超时等待时长内是否能够处理完该RPC报文。
(一)：服务器对该RPC报文的处理时长进行监控：当该RPC报文对应的超时等待时长即将到达时，服务器仍未收到业务模块的回应消息时，则服务器评估可能是业务模块需要更多的处理时间，向客户端发送增加超时时间的回应报文(rpc-reply)，要求客户端在该RPC报文对应的超时等待时长的基础上继续等待一段时间。相应的，服务器检测在该RPC报文对应的超时等待时长内是否能够处理完该RPC报文的步骤可以为：
服务器确定该RPC报文对应的超时等待时长，以及统计该RPC报文的处理时长；当该超时等待时长与该处理时长之间的差值小于第一预设阈值时，服务器确定该RPC的处理时长即将达到该RPC报文对应的超时等待时长，也即在该RPC报文对应的超时等待时长内处理不完该RPC报文。当该超时等待时长与该处理时长之间的差值不小于第一预设阈值时，服务器确定该RPC的处理时长还没有达到该RPC报文对应的超时等待时长，也即在该RPC报文对应的超时等待时长内能够处理完该RPC报文。
第一预设阈值可以根据需要进行设置并更改，在本公开实施例中，对第一预设阈值不作具体限定；例如，第一预设阈值可以为0.5s或者1s等。
(二)：业务模块对该RPC报文的处理时长进行监控：业务模块确定在该RPC报文对应的超时等待时长内是否能够处理完该RPC报文。当确定出在该RPC报文对应的超时等待时长内处理不完该RPC报文时，该业务模块主动向服务器发出增加超时时间的处理请求。服务器接收到该处理请求时，确定出在该RPC报文对应的超时等待时长内处理不完该RPC报文。
在一个可能的实现方式中，在该业务模块处理该RPC报文的过程中，该业务模块实时对该RPC报文的处理时长进行统计，当统计到该RPC报文对应的超时等待时长与该RPC报文的处理时长之间的差值小于第二预设阈值时，该业务模块确定在该RPC报文对应的超时等待时长内处理不完该RPC报文。第二预设阈值和第一预设阈值可以相等，也可以不相等。并且，第二预设阈值也可以根据需要进行设置并更改，在本公开实施例中，对第二预设阈值不作具体限定；例如，第二预设阈值可以为0.5s或者1s等。
在一个可能的实现方式中，业务模块也可以不在该RPC报文的处理时长即将达到该RPC报文对应的超时等待时长时，向服务器发送增加超时时间的处理请求，业务模块也可以在处理该RPC报文的过程中，统计该RPC报文还需的处理时长以及剩余的超时等待时长；当该RPC报文还需的处理时长小于该剩余的超时等待时长时，该业务模块确定在该RPC报文对应的超时等待时长内处理不完该RPC报文。
步骤204：客户端接收服务器的第一回应报文，根据该第一回应报文，增加该超时等待时长。
第一回应报文中携带增加时长，或者第一回应报文中不携带该增加时长。当该第一回应报文中携带该增加时长时，客户端从该第一回应报文中获取该增加时长，在该超时等待时长的基础上增加该增加时长的等待时长。当该第一回应报文中不携带该增加时长时，客户端确定该增加时长，在该超时等待时长的基础上增加该增加时长的等待时长。
在一个可能的实现方式中，客户端将该第三预设时长作为该增加时长。在另一个可能的实现方式中，客户端也可以基于该指定业务的业务类型确定该增加时长。客户端中存储业务类型和增加时长的对应关系；相应的，客户端基于该指定业务的业务类型，确定该增加时长的步骤可以为：客户端根据该指定业务的业务类型，从业务类型和增加时长的对应关系中获取该增加时长。
需要说明的是，服务器在向客户端发送第一回应报文之后，会重新确定该RPC报文对应的超时等待时长，并继续检测在该重新确定的超时等待时长内是否能够处理完该RPC报文，当处理不完该RPC报文时，再次向客户端发送第一回应报文，直到发送第一回应报文的次数达到预设次数或者在重新确定的超时等待时长内能够处理完该RPC报文。其中，预设次数可以根据需要进行设置并更改，在本公开实施例中，对预设次数不作具体限定；例如，预设次数可以为3或者5等。
步骤205：当处理完该RPC报文时，服务器向客户端发送第二回应报文，第二回应报文用于指示该RPC报文的处理结果。
当该业务模块处理完该RPC报文时，该业务模块向服务器发送处理结果。服务器接收该业务模块发送的该处理结果，向客户端发送第二回应报文。当该处理结果为处理成功时，该第二回应报文可以为<ok>，用于表示该RPC报文处理成功。当该处理结果为处理失败时，该第二回应报文可以为<rpc-error>，用于表示该RPC报文处理失败的错误信息。
步骤206：客户端接收服务器的该第二回应报文，根据该第二回应报文，确定该RPC报文的处理结果。
当该第二回应报文是<ok>时，客户端确定该RPC报文的处理结果为处理成功。当该第二回应报文为<rpc-error>时，客户端确定该RPC报文的处理结果为处理失败，并且，该第二回应报文中携带错误信息，客户端根据该错误信息，确定该RPC报文处理失败的错误原因。并且，客户端接收到第二回应报文后，退出等待状态。
需要说明的是，客户端与服务器之间基于NETCONF进行信息交互之前，先对NETCONF的配置管理用YANG语言进行建模，得到YANG模型，然后将YANG模型转换为XML语言格式的XML模型；客户端和服务器均保存该XML模型。客户端与服务器之间交换数据时，发送端按照模型对RPC报文/RPC回应报文(包括该第一回应报文和该第二回应报文用XML方式编码。接收端接收到该RPC报文/RPC回应报文后，根据XML模型解析该报文/RPC回应报文，从而实现相应的配置管理动作。
在本公开实施例中，在处理RPC报文的过程中，服务器当确定在该RPC报文对应的超时等待时长内处理不完该RPC报文时，向客户端发送第一回应报文，以指示客户端增加该RPC报文对应的超时等待时长。从而实现了在某个RPC报文对应的超时等待时长不足时，只修改该RPC报文对应的超时等待时长，不需要修改客户端和服务器的核心代码，也不会增加其他业务的RPC报文对应的超时等待时长，从而整体上提高了处理RPC报文的效率。
上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。
本公开实施例提供了一种处理RPC报文的装置，该装置应用在接收端中，用于执行上述处理RPC报文中的服务器执行的操作。参见图5，所述装置包括：
接收单元301，用于接收发送端的指定业务的远程过程调用RPC报文；
处理单元302，用于通过所述指定业务的业务模块，处理所述RPC报文；
发送单元303，用于在处理所述RPC报文的过程中，当确定在所述RPC报文对应的超时等待时长内处理不完所述RPC报文时，向所述发送端发送第一回应报文，所述第一回应报文用于指示所述发送端增加所述超时等待时长。
在一个可能的实现方式中，所述装置还包括：
第一确定单元，用于确定所述RPC报文对应的超时等待时长；
统计单元，用于统计所述RPC报文的处理时长；
所述第一确定单元，还用于当所述超时等待时长与所述处理时长之间的差值小于预设阈值时，确定在所述RPC报文对应的超时等待时长内处理不完所述RPC报文。
在另一个可能的实现方式中，所述装置还包括：
所述接收单元301，还用于接收所述业务模块发送的增加超时等待时间的处理请求；
第二确定单元，用于根据所述处理请求，确定在所述RPC报文对应的超时等待时长内处理不完所述RPC报文。
在另一个可能的实现方式中，所述装置还包括：
第三确定单元，用于确定所述发送端是否支持超时等待时长的协商能力；
所述发送单元303，还用于当所述发送端支持所述协商能力时，向所述发送端发送第一回应报文。
在另一个可能的实现方式中，所述接收单元301，还用于接收所述发送端发送的第一握手报文，所述第一握手报文用于建立连接；
所述第三确定单元，还用于当所述第一握手报文中携带指示支持超时等待时长的协商能力的指定标签时，确定所述发送端支持超时等待时长的协商能力。
在另一个可能的实现方式中，所述第一回应报文携带增加时长，所述增加时长为预设时长或者所述RPC报文还需的处理时长。
在另一个可能的实现方式中，所述发送单元303，还用于在与所述发送端建立连接时，向所述发送端发送第二握手报文，所述第二握手报文携带指定处理时长，所述指定处理时长用于所述发送端设置所述超时等待时长。
在另一个可能的实现方式中，所述发送单元303，还用于当处理完所述RPC报文时，向所述发送端发送第二回应报文，所述第二回应报文用于指示所述RPC报文的处理结果。
在本公开实施例中，在处理RPC报文的过程中，当确定在该RPC报文对应的超时等待时长内处理不完该RPC报文时，向发送端发送第一回应报文，以指示发送端增加该RPC报文对应的超时等待时长。从而实现了在某个RPC报文对应的超时等待时长不足时，只修改该RPC报文对应的超时等待时长，不需要修改客户端和服务器的核心代码，也不会增加其他业务的RPC报文对应的超时等待时长，从而整体上提高处理RPC报文的效率。
本公开实施例提供了一种处理RPC报文的装置，该装置应用在发送端中，用于执行上述处理RPC报文中的客户端执行的操作。参见图6，所述装置包括：
发送单元401，用于向接收端发送指定业务的远程过程调用RPC报文，所述RPC报文用于所述接收端通过所述指定业务的业务模块，处理所述RPC报文；
接收单元402，用于接收所述接收端的第一回应报文，所述第一回应报文用于指示增加所述RPC报文对应的超时等待时长；
增加单元403，用于根据所述第一回应报文，增加所述超时等待时长。
在一个可能的实现方式中，所述第一回应报文携带增加时长；
所述增加单元403，还用于从所述第一回应报文中获取所述增加时长，在所述超时等待时长的基础上增加所述增加时长的等待时长。
在另一个可能的实现方式中，所述发送单元401，还用于向所述接收端发送第一握手报文，所述第一握手报文用于建立连接，且所述第一握手报文携带指示支持超时等待时长的协商能力的指定标签。
在另一个可能的实现方式中，所述装置还包括：
所述接收单元402，还用于在与所述接收端建立连接时，接收所述接收端的第二握手报文，所述第二握手报文携带指定处理时长；
设置单元，用于根据所述指定处理时长，设置所述超时等待时长。
在另一个可能的实现方式中，所述装置还包括：
所述接收单元402，还用于接收所述接收端的第二回应报文，所述第二回应报文为所述接收端在处理完所述RPC报文发送的；
确定单元，用于根据所述第二回应报文，确定所述RPC报文的处理结果。
在本公开实施例中，接收端在处理RPC报文的过程中，当确定在该RPC报文对应的超时等待时长内处理不完该RPC报文时，向发送端发送第一回应报文，以指示发送端增加该RPC报文对应的超时等待时长。发送端接收到该第一回应报文时，增加该超时等待时长。从而实现了在某个RPC报文对应的超时等待时长不足时，只修改该RPC报文对应的超时等待时长，不需要修改客户端和服务器的核心代码，也不会增加其他业务的RPC报文对应的超时等待时长，从而整体上提高了处理RPC报文的效率。
需要说明的是：上述实施例提供的处理RPC报文的装置在处理RPC报文时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的处理RPC报文的装置与处理RPC报文的方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
图7是根据一示例性实施例示出的一种处理RPC报文的装置500的框图。例如，装置500可以被提供为一服务器。参照图7，装置500包括处理组件522，其进一步包括一个或多个处理器，以及由存储器532所代表的存储器资源，用于存储可由处理组件522的执行的指令，例如应用程序。存储器532中存储的可以包括一个或多个应用程序，每一个应用程序对应于一组指令。此外，处理组件522被配置为执行指令，以执行上述处理RPC报文的方法。
装置500还可以包括一个电源组件526被配置为装置500的电源管理，一个有线或无线网络接口550被配置为将装置500连接到网络，和一个输入输出(I/O)接口558。装置500可以运行基于存储在存储器532的操作系统，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。
本实施例提供了一种客户端，该客户端可以用于执行上述各个实施例中提供的处理RPC报文的方法。参见图8，该客户端600包括：一个或一个以上处理器601和一个或一个以上的存储器602、通信接口603以及总线604。
其中，存储器602、处理器601及通信接口603通过总线604连接，该存储器602中存储有可编程指令，该可编程指令由该处理器601加载并执行以实现本公开实施例提供的处理RPC报文的方法，通信接口603可以与服务器进行通信。
当然，该客户端600还可以具有有线或无线网络接口、输入输出接口等部件，以便进行输入输出，该客户端600还可以包括其他用于实现设备功能的部件，在此不做赘述。
本公开实施例提供了一种计算机可读存储介质，所述存储介质包括指令，当其在服务器上运行时，使得服务器执行上述处理RPC报文的方法。
本公开实施例提供了一种计算机可读存储介质，所述存储介质包括指令，当其在客户端上运行时，使得客户端执行上述处理RPC报文的方法。
本公开实施例还提供了一种计算机程序产品，该计算机程序产品包括一个或多个指令，在服务器上加载和执行所述指令时，可以实现本公开实施例所述的处理RPC报文方法。该服务器可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该指令可以从一个网站站点、计算机、服务器或数据中心通过有线或无线方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如软盘、硬盘、磁带)、光介质(例如，数字视频光盘(digital video disc，DVD)、或者半导体介质(例如固态硬盘)等。
本公开实施例还提供了一种计算机程序产品，该计算机程序产品包括一个或多个指令，在客户端上加载和执行所述指令时，可以实现本公开实施例所述的处理RPC报文方法。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上所述仅为本公开的可选实施例，并不用以限制本公开，凡在本公开的原则之内，所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (18)

1.一种处理RPC报文的方法，其特征在于，所述方法包括：
接收发送端的指定业务的远程过程调用RPC报文；
通过所述指定业务的业务模块，处理所述RPC报文；
在处理所述RPC报文的过程中，当确定在所述RPC报文对应的超时等待时长内处理不完所述RPC报文时，向所述发送端发送第一回应报文，所述第一回应报文用于指示所述发送端增加所述超时等待时长，所述超时等待时长为所述业务模块发送至所述发送端的指定处理时长、系统默认的时长和所述业务模块反馈的指定处理时长中最大的时长、所述指定业务的业务类型对应的超时等待时长、所述RPC报文的message-id对应的超时等待时长中的任一种。
2.根据权利要求1所述的方法，其特征在于，所述方法还包括：
确定所述RPC报文对应的超时等待时长，以及统计所述RPC报文的处理时长；
当所述超时等待时长与所述处理时长之间的差值小于预设阈值时，确定在所述RPC报文对应的超时等待时长内处理不完所述RPC报文。
3.根据权利要求1所述的方法，其特征在于，所述方法还包括：
接收所述业务模块发送的增加超时等待时间的处理请求，根据所述处理请求，确定在所述RPC报文对应的超时等待时长内处理不完所述RPC报文。
4.根据权利要求1所述的方法，其特征在于，所述向所述发送端发送第一回应报文之前，所述方法还包括：
确定所述发送端是否支持超时等待时长的协商能力；
当所述发送端支持所述协商能力时，执行所述向所述发送端发送第一回应报文的步骤。
5.根据权利要求1所述的方法，其特征在于，所述第一回应报文携带增加时长，所述增加时长为预设时长或者所述RPC报文还需的处理时长。
6.根据权利要求1-5任一所述的方法，其特征在于，所述向所述发送端发送第一回应报文之后，所述方法还包括：
当处理完所述RPC报文时，向所述发送端发送第二回应报文，所述第二回应报文用于指示所述RPC报文的处理结果。
7.一种处理RPC报文的方法，其特征在于，所述方法包括：
向接收端发送指定业务的远程过程调用RPC报文，所述RPC报文用于所述接收端通过所述指定业务的业务模块，处理所述RPC报文；
接收所述接收端的第一回应报文，所述第一回应报文用于指示增加所述RPC报文对应的超时等待时长；
根据所述第一回应报文，增加所述超时等待时长，所述超时等待时长为所述业务模块发送至所述发送端的指定处理时长、系统默认的时长和所述业务模块反馈的指定处理时长中最大的时长、所述指定业务的业务类型对应的超时等待时长、所述RPC报文的message-id对应的超时等待时长中的任一种。
8.根据权利要求7所述的方法，其特征在于，所述根据所述第一回应报文，增加所述超时等待时长，包括：
所述第一回应报文携带增加时长，从所述第一回应报文中获取所述增加时长；
在所述超时等待时长的基础上增加所述增加时长的等待时长。
9.根据权利要求7或8所述的方法，其特征在于，所述根据所述第一回应报文，增加所述超时等待时长之后，所述方法还包括：
接收所述接收端的第二回应报文，所述第二回应报文为所述接收端在处理完所述RPC报文发送的；
根据所述第二回应报文，确定所述RPC报文的处理结果。
10.一种处理RPC报文的装置，其特征在于，所述装置包括：
接收单元，用于接收发送端的指定业务的远程过程调用RPC报文；
处理单元，用于通过所述指定业务的业务模块，处理所述RPC报文；
发送单元，用于在处理所述RPC报文的过程中，当确定在所述RPC报文对应的超时等待时长内处理不完所述RPC报文时，向所述发送端发送第一回应报文，所述第一回应报文用于指示所述发送端增加所述超时等待时长，所述超时等待时长为所述业务模块发送至所述发送端的指定处理时长、系统默认的时长和所述业务模块反馈的指定处理时长中最大的时长、所述指定业务的业务类型对应的超时等待时长、所述RPC报文的message-id对应的超时等待时长中的任一种。
11.根据权利要求10所述的装置，其特征在于，所述装置还包括：
第一确定单元，用于确定所述RPC报文对应的超时等待时长；
统计单元，用于统计所述RPC报文的处理时长；
所述第一确定单元，还用于当所述超时等待时长与所述处理时长之间的差值小于预设阈值时，确定在所述RPC报文对应的超时等待时长内处理不完所述RPC报文。
12.根据权利要求10所述的装置，其特征在于，所述装置还包括：
所述接收单元，还用于接收所述业务模块发送的增加超时等待时间的处理请求；
第二确定单元，用于根据所述处理请求，确定在所述RPC报文对应的超时等待时长内处理不完所述RPC报文。
13.根据权利要求10所述的装置，其特征在于，所述装置还包括：
第三确定单元，用于确定所述发送端是否支持超时等待时长的协商能力；
所述发送单元，还用于当所述发送端支持所述协商能力时，向所述发送端发送第一回应报文。
14.根据权利要求10所述的装置，其特征在于，所述第一回应报文携带增加时长，所述增加时长为预设时长或者所述RPC报文还需的处理时长。
15.根据权利要求10-14任一所述的装置，其特征在于，
所述发送单元，还用于当处理完所述RPC报文时，向所述发送端发送第二回应报文，所述第二回应报文用于指示所述RPC报文的处理结果。
16.一种处理RPC报文的装置，其特征在于，所述装置包括：
发送单元，用于向接收端发送指定业务的远程过程调用RPC报文，所述RPC报文用于所述接收端通过所述指定业务的业务模块，处理所述RPC报文；
接收单元，用于接收所述接收端的第一回应报文，所述第一回应报文用于指示增加所述RPC报文对应的超时等待时长；
增加单元，用于根据所述第一回应报文，增加所述超时等待时长，所述超时等待时长为所述业务模块发送至所述发送端的指定处理时长、系统默认的时长和所述业务模块反馈的指定处理时长中最大的时长、所述指定业务的业务类型对应的超时等待时长、所述RPC报文的message-id对应的超时等待时长中的任一种。
17.根据权利要求16所述的装置，其特征在于，所述第一回应报文携带增加时长；
所述增加单元，还用于从所述第一回应报文中获取所述增加时长，在所述超时等待时长的基础上增加所述增加时长的等待时长。
18.根据权利要求16或17所述的装置，其特征在于，所述装置还包括：
所述接收单元，还用于接收所述接收端的第二回应报文，所述第二回应报文为所述接收端在处理完所述RPC报文发送的；
确定单元，用于根据所述第二回应报文，确定所述RPC报文的处理结果。
CN201810350094.3A 2018-04-18 2018-04-18 处理rpc报文的方法及相关装置 Active CN110392017B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810350094.3A CN110392017B (zh) 2018-04-18 2018-04-18 处理rpc报文的方法及相关装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810350094.3A CN110392017B (zh) 2018-04-18 2018-04-18 处理rpc报文的方法及相关装置

Publications (2)

Publication Number Publication Date
CN110392017A CN110392017A (zh) 2019-10-29
CN110392017B true CN110392017B (zh) 2020-11-06

Family

ID=68283308

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810350094.3A Active CN110392017B (zh) 2018-04-18 2018-04-18 处理rpc报文的方法及相关装置

Country Status (1)

Country Link
CN (1) CN110392017B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112615700B (zh) * 2020-12-03 2022-06-28 瀚云科技有限公司 数据的发送方法、网关、系统、电子设备及可读存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101997858A (zh) * 2009-08-24 2011-03-30 华为终端有限公司 用户驻地设备广域网管理协议cwmp会话交互方法及装置
EP2197154A4 (en) * 2007-10-10 2011-06-08 Huawei Tech Co Ltd METHOD, SYSTEM AND APPROPRIATE DEVICE FOR TRANSMITTING AN REMOTE PROCEDURE CALL COMMAND
CN103116520A (zh) * 2012-11-02 2013-05-22 深圳键桥通讯技术股份有限公司 基于tcp/ udp的远程过程调用rpc的方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2197154A4 (en) * 2007-10-10 2011-06-08 Huawei Tech Co Ltd METHOD, SYSTEM AND APPROPRIATE DEVICE FOR TRANSMITTING AN REMOTE PROCEDURE CALL COMMAND
CN101997858A (zh) * 2009-08-24 2011-03-30 华为终端有限公司 用户驻地设备广域网管理协议cwmp会话交互方法及装置
CN103116520A (zh) * 2012-11-02 2013-05-22 深圳键桥通讯技术股份有限公司 基于tcp/ udp的远程过程调用rpc的方法

Also Published As

Publication number Publication date
CN110392017A (zh) 2019-10-29

Similar Documents

Publication Publication Date Title
EP3748908A1 (en) Method, system, network device, storage medium for creating a network slice
EP2645636B1 (en) Home gateway, cloud server, and method for communication therebetween
US9544365B2 (en) Mobile device workload management for cloud computing using SIP and presence to control workload and method thereof
AU2021266341B2 (en) Session processing method, device, and system
EP4027664A1 (en) Method and apparatus for providing network auxiliary information, electronic device, and computer-readable storage medium
US9565218B2 (en) Resource management for WebRTC
CN109246220B (zh) 一种消息推送系统及方法
WO2014067311A1 (zh) 资源订阅方法及装置
CN104811459A (zh) 用于消息服务的处理方法、装置及系统、消息服务系统
US9092180B2 (en) Printer-server connections
EP3197170B1 (en) Multimedia processing device, multimedia processing server and method therefor
WO2023217187A1 (zh) 服务响应方法、装置、设备及存储介质
JP7246379B2 (ja) 通信ネットワークにおけるサービス層メッセージテンプレート
Xu et al. Design of oneM2M-based fog computing architecture
CN110392017B (zh) 处理rpc报文的方法及相关装置
CN106686635B (zh) 基于无线接入点的控制和配置协议的数据传输方法和装置
US8112766B2 (en) Multi-threaded device and facility manager
WO2016165477A1 (zh) 一种登录的方法、终端、会话建立的方法和服务器
CN114745564B (zh) 服务调度方法及装置
CN114025005B (zh) 一种数据通讯方法、系统、电子设备及存储介质
WO2022110919A1 (zh) 一种信息订阅的方法及装置
WO2022028189A1 (zh) 投屏方法及装置、电子设备和计算机可读存储介质
WO2022042545A1 (zh) Tsn工业应用服务器、客户端、系统、服务方法及储存介质
CN111490997B (zh) 任务处理方法、代理系统、服务系统和电子设备
CN112165529A (zh) 一种低成本跨网络数据交换的方法、装置、设备和介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant