CN109347851A - 一种请求响应方法及装置 - Google Patents

Abstract

本申请提供了一种请求响应方法及装置，应用于电子设备，所述电子设备中配置有至少两台虚拟逻辑设备，所述方法包括：确定所述虚拟逻辑设备接收到请求方发送的处理请求并当所述处理请求符合预定义的协议属性信息时，将所述处理请求发送至公共协议进程进行处理。通过本申请的技术方案，极大程度减少了对协议进程的重复配置，减少了物理内存空间占用，提高了内存空间利用率。

Description

一种请求响应方法及装置

技术领域

本申请涉及网络技术领域，具体涉及一种请求响应方法及装置。

背景技术

随着网络规模的日益扩大，组网日益复杂，传统的网络部署模型由于存在组网复杂、维护成本高、多个部门间业务隔离手段单一等诸多缺陷问题，已难以满足日益多样化的需求和严格的安全要求。OVC(OS-Level Virtual Context，操作***级虚拟环境)技术通过将一个物理设备虚拟成多个逻辑设备，使得业务的快速部署和调整不再受限于物理设备本身，有效解决了多业务安全隔离和资源按需分配的问题。

但在现有技术中，每个OVC运行独立的协议进程，为实现各个OVC之间不同的通信功能，同一物理设备中需要提供更多的物理空间以在各个OVC中均配置满足需要的协议进程，占据较大的内存空间且在协议进程运行过程中产生较大的物理内存消耗。

发明内容

有鉴于此，本申请提供一种请求响应方法及装置，使得OVC在保证支持相应协议功能的基础上，减少物理内存的消耗。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种请求响应方法，包括：

确定所述虚拟逻辑设备接收到请求方发送的处理请求；

当所述处理请求符合预定义的协议属性信息时，将所述处理请求发送至公共协议进程进行处理。

根据本申请第二方面，提出了一种请求响应装置，包括：

接收单元，确定所述虚拟逻辑设备接收到请求方发送的处理请求；

处理单元，当所述处理请求符合预定义的协议属性信息时，将所述处理请求发送至公共协议进程进行处理。

由以上技术方案可见，本申请通过将OVC收到的处理请求发送至公共协议进程中进行处理，使得各个OVC虚拟环境中无需分别配置完整的功能协议进程，极大程度减少了对协议进程的重复配置，减少了物理内存空间占用，提高了内存空间利用率。

附图说明

图1是现有技术中配置有n个OVC的电子设备的示意图；

图2是根据本申请一示例性实施例中的一种请求响应方法流程图；

图3是根据本申请一示例性实施例中的一种请求响应交互过程的结构示意图；

图4是根据本申请一示例性实施例中的一种请求响应的交互示意图；

图5是根据本申请一示例性实施例中的一种电子设备的示意结构图；

图6是根据本申请一示例性实施例中的一种请求响应装置的框图。

具体实施方式

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

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

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

图1为现有技术中配置有n个OVC的电子设备的示意图。如图1所示，电子设备中配置有OVC1、OVC2……OVCn，各个OVC之间彼此隔离、相互独立，使得各个OVC需要分别创建独立的协议进程，以针对接收到的协议报文进行处理。例如，OVC1中创建有SNMP进程1、OVC2中创建有SNMP进程2，当OVC1接收到SNMP协议报文时，只能交由SNMP进程1进行处理，类似地当OVC2接收到SNMP协议报文时，只能交由SNMP进程2进行处理；其他协议报文的处理情况类似，此处不再一一赘述。

可见，由于OVC之间相互独立的特性，使得协议进程在各个OVC之间无法实现共享，需要在各个OVC中分别重复创建同样的协议进程，造成了对电子设备中的物理内存的大量占用，甚至可能影响电子设备的处理性能和运行效率。

有鉴于此，本申请提供一种请求响应方法及装置，由公共协议进程集中处理同一网络设备中各个OVC接收到的请求信息，使得各个OVC仍支持原有协议功能的情况下，减少物理内存的占用，提高资源使用效率。

下面结合附图，对本申请的具体实施方案进行详细阐述。

请参见图2，图2是根据本申请一示例性实施例中的一种请求响应方法流程图，该方法应用于电子设备，所述电子设备中配置有至少两台虚拟逻辑设备，该方法可以包括以下步骤：

步骤201，确定虚拟逻辑设备接收到请求方发送的处理请求。

步骤202，当所述处理请求符合预定义的协议属性信息时，将所述处理请求发送至公共协议进程进行处理。

在一实施例中，公共协议进程运行在区别于OVC虚拟环境之外的电子设备中，所述公共协议进程可以为对网络连通无影响的协议进程，例如SNMP协议进程、NTP协议进程等，相对于与网络连通相关的协议进程，例如路由相关进程(BGP协议进程、ISIS协议进程、OSPF协议进程、RTM协议进程)等，该类协议进程不参与OVC与外部网络通信过程。

在一实施例中，对网络连通无影响的协议进程包括对响应的实时性要求不高的协议进程，即便由于转发、处理等操作而造成一定程度的响应延迟，也不会影响网络的正常连通。

在一实施例中，在每个OVC虚拟逻辑环境中预配置中转进程，当该中转进程监听到符合预定义的协议属性信息的协议进程后，通过本地socket转发至公共协议进程中进行处理。

进一步的，协议进程应答报文可以经本地socket发送给中转进程，以由所述中转进程转发至请求方作为请求响应。

在一实施例中，所述中转进程可以包括以下至少之一：协议端口号、协议类型等，本申请并不对此进行限制。

通过图2所示流程，替代现有技术中在各个OVC虚拟环境分别配置完整的功能协议进程，相应地，在本申请中对于OVC虚拟环境中所接收到的符合中转进程中预配置的协议属性信息的请求信息，发送至公共协议进程中处理。因此，与现有技术中随着OVC数量的增多，功能协议进程的配置数量不断增加的情况完全不同的是，在本申请中仅需将完整的功能协议进程在公共协议进程中配置一份，便可支持对各个OVC虚拟环境接收到的请求进行处理，从而在一定程度上减少了电子设备对同一种协议进程重复存储的情况，极大程度上降低了功能协议进程所占用的物理空间，提高了内存空间利用效率。

图3是根据本申请一示例性实施例中的一种请求响应交互过程的结构示意图。如图3所示，电子设备中配置有OVC1、OVC2……OVCn，各个OVC中增加配置了中转进程，并在区别于OVC配置区域之外配置了公共协议进程，用以处理OVC环境中发送的指定的协议请求报文。例如，当电子设备中的OVC1接收到携带有某一协议进程属性信息的请求处理报文后，中转进程将满足预定义的协议属性信息的处理请求转发至公共协议进程集合中对应的公共协议进程进行处理，处理结果以请求响应信息的形式到达中转进程并由中转进程转发至请求方设备。

本申请技术方案区别于现有技术中由OVC独立完成上述请求响应的过程，本申请的实施例极大程度地减少了各个OVC中功能进程的物理内存占用率，扩展了内存空间，提高内存响应效率。

下面以OVC1为例，对上述请求响应的交互过程进行进一步说明，参见图4，图4是根据本申请一示例性实施例中的一种请求响应的交互示意图，如图4所示，该交互过程可以包括以下步骤：

步骤401，接收请求方发送的处理请求。

在一实施例中，以NTP(Network Time Protocol)网络时间协议为例，请求方设备与电子设备通过网络相连，且请求方设备、电子设备均有自己独立的***时钟。当请求方设备需要与电子设备中的OVC1实现各自***时钟的自动同步时，电子设备中的OVC1接收到某一请求方设备A发送的一个NTP报文信息，该报文中带有协议端口号、协议类型、离开请求方设备A时的时间戳，例如协议类型及协议端口号为UDP：123，时间戳为10:00:00am(T1)。

步骤402，中转进程监听到符合预定义的协议属性信息的协议类型、协议端口号的处理请求。

在一实施例中，协议属性信息预先配置在中转进程中，当接收到来自请求方的处理请求后，将满足预先配置的协议属性信息的报文转发至中转进程，中转进程获取所监听的处理请求。例如在协议属性信息中预配置了协议类型及协议端口号为UDP：123的属性信息，则中转进程可接收到该协议类型及协议端口号为UDP：123，时间戳为10:00:00am(T1)的处理请求。

步骤403，通过本地socket将该处理请求发送至公共协议进程进行处理。

在一个实施例中，本地socket实现将OVC1中的应用层数据拷贝到公共协议进程中的相应进程中进行处理。例如在OVC1中建立一个socket，并将所建立的socket绑定在UDP：123端口上，当监听到请求方发送的协议类型及协议端口号为UDP：123，时间戳为10:00:00am(T1)的处理请求时，接收这个链接并同时新建一个socket和公共NTP进程进行通信，将所监听的处理请求发送至公共协议进程集合中的公共协议进程进行处理，在本申请中与处理请求对应的公共协议进程为NTP协议进程，通信完成后关闭socket。

针对所接收到的不同的协议进程的处理请求信息，中转进程将其转发至公共协议进程集合中与其对应的公共协议进程进行处理。在一实施例中，中转进程可根据处理请求中的协议类型和/或协议端口号，将其转发至该协议类型和/或协议端口号所对应的公共协议进程进行处理。

步骤404，公共协议进程对接收到的请求信息进行处理。

在一个实施例中，公共协议进程对接收到的请求信息进行处理，例如当接收到本地socket发送的NTP报文时，公共协议进程加上电子设备当前的时间戳，例如该时间戳此时为11:00:01am(T2)。

步骤405，通过本地socket向中转进程返回请求响应信息。

在一实施例中，公共协议进程建立一个socket，通过本地socket向中转进程返回请求响应信息，当此NTP报文离开公共协议进程时，电子设备再加上离开时的时间戳，例如此时的时间戳为11:00:02am(T3)。

步骤406，中转进程转发请求响应信息至请求方。

在一实施例中，请求方设备接收到中转进程转发的带有NTP协议进程处理结果的响应信息，当请求方设备接收带有响应信息的NTP报文中，请求方设备获取此时的本地时间为10:00:03am(T4)，则根据T1～T4的时间信息可获取NTP报文在请求方设备与电子设备之间的往返时延Delay＝(T4-T1)-(T3-T2)＝2秒，所以，请求方设备与电子设备的时间差为((T2-T1)+(T3-T4))/2＝1小时，由此请求方设备可根据时间差值完成时间的同步更新。

基于图4所示的步骤401-405，采用的技术方案为：对于满足预定义的协议属性信息的处理请求由中转进程进行监听并建立相应的socket连接，使得该应用层数据复制到公共协议进程中进行处理，并由中转进程通过本地socket接收请求响应信息并转发至请求方，完成请求信息的处理交互过程，因而本实施例中通过本地socket连接实现中转进程与公共协议进程的数据交互，传输数据量小、传输时间短，实现了信息的实时交互，此外socket连接形式支持数据加密，确保了数据传输过程中的安全性。

图5是根据本申请一示例性实施例中的一种电子设备的示意结构图。请参考图5，在硬件层面，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成请求响应装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图6，在软件实施方式中，该请求响应装置可以包括：

接收单元601，确定所述虚拟逻辑设备接收到请求方发送的处理请求；

处理单元602，当所述处理请求符合预定义的协议属性信息时，将所述处理请求发送至公共协议进程进行处理。

可选的，所述公共协议进程包括：对网络连通无影响的协议进程。

可选的，还包括：

转发单元603，所述处理请求由所述虚拟逻辑设备中预配置的中转进程进行监听并转发至所述公共协议进程。

可选的，还包括：

响应转发单元604，将所述公共协议进程生成的处理结果返回至所述中转进程，以由所述中转进程转发至所述请求方。

可选的，所述处理单元还包括：

所述协议属性信息包括以下至少之一：协议端口号、协议类型。

所述装置与上述方法相对应，更多相同的细节不再一一赘述。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

虽然本申请包含许多具体实施细节，但是这些不应被解释为限制任何发明的范围或所要求保护的范围，而是主要用于描述特定发明的具体实施例的特征。本申请中的多个实施例中描述的某些特征也可以在单个实施例中被组合实施。另一方面，在单个实施例中描述的各种特征也可以在多个实施例中分开实施或以任何合适的子组合来实施。此外，虽然特征可以如上所述在某些组合中起作用并且甚至最初如此要求保护，但是来自所要求保护的组合中的一个或多个特征在一些情况下可以从该组合中去除，并且所要求保护的组合可以指向子组合或子组合的变型。

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

Claims (10)

1.一种请求响应方法，其特征在于，应用于电子设备，所述电子设备中配置有至少两台虚拟逻辑设备，所述方法包括：

确定所述虚拟逻辑设备接收到请求方发送的处理请求；

当所述处理请求符合预定义的协议属性信息时，将所述处理请求发送至公共协议进程进行处理。

2.根据权利要求1所述方法，其特征在于，所述公共协议进程包括：对网络连通无影响的协议进程。

3.根据权利要求1所述方法，其特征在于，所述处理请求由所述虚拟逻辑设备中预配置的中转进程进行监听并转发至所述公共协议进程。

4.根据权利要求3所述方法，其特征在于，所述方法还包括：

将所述公共协议进程生成的处理结果返回至所述中转进程，以由所述中转进程转发至所述请求方。

5.根据权利要求1所述方法，其特征在于，所述协议属性信息包括以下至少之一：协议端口号、协议类型。

6.一种请求响应装置，其特征在于，应用于电子设备，所述电子设备中配置有至少两台虚拟逻辑设备，其特征在于：

接收单元，确定所述虚拟逻辑设备接收到请求方发送的处理请求；

处理单元，当所述处理请求符合预定义的协议属性信息时，将所述处理请求发送至公共协议进程进行处理。

7.根据权利要求6所述装置，其特征在于，所述公共协议进程包括：对网络连通无影响的协议进程。

8.根据权利要求6所述装置，其特征在于，还包括：

转发单元，所述处理请求由所述虚拟逻辑设备中预配置的中转进程进行监听并转发至所述公共协议进程。

9.根据权利要求8所述装置，其特征在于，还包括：

响应转发单元，将所述公共协议进程生成的处理结果返回至所述中转进程，以由所述中转进程转发至所述请求方。

10.根据权利要求6所述装置，其特征在于，所述协议属性信息包括以下至少之一：协议端口号、协议类型。