CN109347851B

CN109347851B - Request response method and device

Info

Publication number: CN109347851B
Application number: CN201811314120.3A
Authority: CN
Inventors: 肖海波
Original assignee: Hangzhou DPTech Technologies Co Ltd
Current assignee: Hangzhou DPTech Technologies Co Ltd
Priority date: 2018-11-06
Filing date: 2018-11-06
Publication date: 2021-11-02
Anticipated expiration: 2038-11-06
Also published as: CN109347851A

Abstract

The application provides a request response method and a request response device, which are applied to electronic equipment, wherein at least two virtual logic devices are configured in the electronic equipment, and the method comprises the following steps: and determining that the virtual logic equipment receives a processing request sent by a requester and sending the processing request to a common protocol process for processing when the processing request conforms to predefined protocol attribute information. By the technical scheme, repeated configuration of the protocol process is greatly reduced, physical memory space occupation is reduced, and memory space utilization rate is improved.

Description

Request response method and device

Technical Field

The present application relates to the field of network technologies, and in particular, to a request response method and apparatus.

Background

With the increasing expansion of network scale and the increasing complexity of networking, the traditional network deployment model has the defects of complex networking, high maintenance cost, single service isolation means among multiple departments and the like, so that the increasingly diversified requirements and strict safety requirements are difficult to meet. The OVC (OS-Level Virtual Context, operating system Level Virtual environment) technology virtualizes a physical device into a plurality of logical devices, so that rapid deployment and adjustment of services are not limited to the physical device, and the problems of multi-service security isolation and resource allocation as required are effectively solved.

However, in the prior art, each OVC runs an independent protocol process, and in order to implement different communication functions between the OVCs, more physical space needs to be provided in the same physical device to configure the protocol processes meeting the needs in each OVC, which occupies a larger memory space and generates larger physical memory consumption in the running process of the protocol processes.

Disclosure of Invention

In view of this, the present application provides a request response method and apparatus, so that the OVC reduces consumption of a physical memory on the basis of ensuring that a corresponding protocol function is supported.

In order to achieve the above purpose, the present application provides the following technical solutions:

according to a first aspect of the present application, a request response method is provided, including:

determining that the virtual logic device receives a processing request sent by a requester;

and when the processing request conforms to the predefined protocol attribute information, sending the processing request to a public protocol process for processing.

According to a second aspect of the present application, there is provided a request response apparatus, comprising:

the receiving unit is used for determining that the virtual logic equipment receives a processing request sent by a requester;

and the processing unit is used for sending the processing request to a public protocol process for processing when the processing request conforms to the predefined protocol attribute information.

According to the technical scheme, the processing request received by the OVC is sent to the public protocol process for processing, so that the complete functional protocol process does not need to be configured in each OVC virtual environment, repeated configuration of the protocol process is greatly reduced, physical memory space occupation is reduced, and the memory space utilization rate is improved.

Drawings

Fig. 1 is a schematic diagram of a prior art electronic device configured with n OVCs;

FIG. 2 is a flow chart of a request response method in an exemplary embodiment according to the present application;

FIG. 3 is a block diagram of a request response interaction process in an exemplary embodiment according to the present application;

FIG. 4 is an interaction diagram of a request response in an exemplary embodiment according to the present application;

FIG. 5 is a schematic block diagram of an electronic device in an exemplary embodiment in accordance with the subject application;

FIG. 6 is a block diagram of a request response device in an exemplary embodiment according to the present application.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

Fig. 1 is a schematic diagram of an electronic device configured with n OVCs in the prior art. As shown in fig. 1, the electronic device is configured with OVC1 and OVC2 … … OVCn, which are isolated and independent from each other, so that each OVC needs to create an independent protocol process to process a received protocol packet. For example, an SNMP process 1 is created in the OVC1, an SNMP process 2 is created in the OVC2, when the OVC1 receives an SNMP protocol message, the SNMP process 1 can only be handed over for processing, and similarly, when the OVC2 receives an SNMP protocol message, the SNMP process 2 can only be handed over for processing; the processing conditions of other protocol messages are similar, and are not described in detail herein.

It can be seen that due to the independent characteristics of the OVCs, the protocol processes cannot be shared among the OVCs, and the same protocol process needs to be repeatedly created in each OVC, which causes a large amount of physical memory occupation in the electronic device and may even affect the processing performance and operating efficiency of the electronic device.

In view of this, the present application provides a request response method and apparatus, where a common protocol process centrally processes request information received by each OVC in the same network device, so that each OVC still supports an original protocol function, and thus, the physical memory usage is reduced and the resource utilization efficiency is improved.

Specific embodiments of the present application will be described in detail below with reference to the accompanying drawings.

Referring to fig. 2, fig. 2 is a flowchart illustrating a request response method according to an exemplary embodiment of the present application, where the method is applied to an electronic device, where at least two virtual logic devices are configured in the electronic device, and the method may include the following steps:

step 201, determining that the virtual logic device receives a processing request sent by a requester.

Step 202, when the processing request conforms to the predefined protocol attribute information, sending the processing request to a common protocol process for processing.

In one embodiment, the common protocol process runs in the electronic device outside the OVC virtual environment, and the common protocol process may be a protocol process having no influence on network connectivity, such as an SNMP protocol process, an NTP protocol process, and the like, and the protocol process does not participate in communication between the OVC and the external network, relative to a protocol process related to network connectivity, such as a routing-related process (a BGP protocol process, an ISIS protocol process, an OSPF protocol process, an RTM protocol process), and the like.

In an embodiment, the protocol process having no influence on the network connectivity includes a protocol process having low real-time requirement on response, and even if a certain response delay is caused by operations such as forwarding and processing, the normal network connectivity is not influenced.

In an embodiment, a relay process is preconfigured in each OVC virtual logic environment, and when the relay process monitors a protocol process that conforms to predefined protocol attribute information, the relay process forwards the protocol process to a common protocol process through a local socket for processing.

Further, the protocol process response message may be sent to the relay process through the local socket, and the relay process forwards the protocol process response message to the requester as a request response.

In an embodiment, the transit process may include at least one of: protocol port number, protocol type, etc., which are not limited in this application.

Through the flow shown in fig. 2, instead of configuring a complete functional protocol process in each OVC virtual environment in the prior art, correspondingly, in the present application, request information received in the OVC virtual environment and conforming to protocol attribute information preconfigured in the relay process is sent to a common protocol process for processing. Therefore, the situation is completely different from the situation that the configuration quantity of the functional protocol processes is continuously increased along with the increase of the quantity of the OVCs in the prior art, in the application, the requests received by all the OVCs can be processed only by configuring one complete functional protocol process in the public protocol process, so that the situation that the electronic equipment repeatedly stores the same protocol process is reduced to a certain extent, the physical space occupied by the functional protocol processes is greatly reduced, and the utilization efficiency of the memory space is improved.

Fig. 3 is a schematic diagram of a request-response interaction process according to an exemplary embodiment of the present application. As shown in fig. 3, the electronic device is configured with OVC1 and OVC2 … … OVCn, each OVC is configured with a relay process, and is configured with a common protocol process outside an OVC configuration area for processing a specified protocol request message sent in an OVC environment. For example, after receiving a request processing packet carrying certain protocol process attribute information, the OVC1 in the electronic device forwards a processing request meeting predefined protocol attribute information to a corresponding public protocol process in the public protocol process set for processing, and a processing result reaches the relay process in the form of request response information and is forwarded to the requester device by the relay process.

The technical scheme of the application is different from the process that the OVC independently completes the request response in the prior art, and the embodiment of the application greatly reduces the physical memory occupancy rate of the function process in each OVC, expands the memory space and improves the memory response efficiency.

The above interaction process of request and response is further described below by taking OVC1 as an example, referring to fig. 4, fig. 4 is an interaction diagram of request and response in an exemplary embodiment of the present application, and as shown in fig. 4, the interaction process may include the following steps:

step 401, receiving a processing request sent by a requester.

In an embodiment, taking ntp (network Time protocol) network Time protocol as an example, the requesting device and the electronic device are connected through a network, and both the requesting device and the electronic device have their own independent system clocks. When a requesting device needs to implement automatic synchronization of respective system clocks with the OVC1 in the electronic device, the OVC1 in the electronic device receives NTP message information sent by a certain requesting device a, where the message includes a protocol port number, a protocol type, and a timestamp when the requesting device a leaves, and the protocol type and the protocol port number are UDP: 123 with a timestamp of 10:00:00am (T1).

Step 402, the transit process monitors the processing request of the protocol type and the protocol port number which accord with the predefined protocol attribute information.

In an embodiment, the protocol attribute information is pre-configured in the relay process, and after receiving a processing request from a requester, the relay process forwards a packet satisfying the pre-configured protocol attribute information to the relay process, and the relay process obtains the monitored processing request. For example, the protocol attribute information is preconfigured with the protocol type and the protocol port number as UDP: 123, the transit process may receive that the protocol type and the protocol port number are UDP: 123, processing request with timestamp 10:00:00am (T1).

And step 403, sending the processing request to a public protocol process for processing through the local socket.

In one embodiment, the local socket implementation copies the application layer data in OVC1 to a corresponding process in the common protocol process for processing. For example, a socket is established in OVC1, and the established socket is bound in UDP: on the port 123, when the protocol type and the protocol port number sent by the requester are monitored to be UDP: 123, when the processing request with the timestamp of 10:00:00am (T1), receiving the link, establishing a socket and a public NTP process for communication, sending the monitored processing request to a public protocol process in a public protocol process set for processing, wherein the public protocol process corresponding to the processing request is the NTP protocol process, and closing the socket after the communication is completed.

And for the received processing request information of different protocol processes, the transfer process forwards the processing request information to the corresponding public protocol process in the public protocol process set for processing. In an embodiment, the relay process may forward the protocol type and/or the protocol port number to the common protocol process corresponding to the protocol type and/or the protocol port number according to the protocol type and/or the protocol port number in the processing request for processing.

At step 404, the common protocol process processes the received request message.

In one embodiment, the public protocol process processes the received request message, for example, when receiving the NTP message sent by the local socket, the public protocol process adds the current timestamp of the electronic device, for example, the timestamp is 11:00:01am (T2).

And step 405, returning request response information to the relay process through the local socket.

In one embodiment, the public protocol process establishes a socket, returns a request response message to the transit process through the local socket, and adds a time stamp of leaving to the electronic device when the NTP message leaves the public protocol process, for example, the time stamp of the leaving time is 11:00:02am (T3).

Step 406, the relay process forwards the request response message to the requesting party.

In an embodiment, the requesting device receives response information with an NTP protocol process processing result forwarded by the relay process, and when the requesting device receives an NTP message with response information, the requesting device obtains the local time at this time as 10:00:03am (T4), and then obtains, according to the time information from T1 to T4, the round-trip Delay between the requesting device and the electronic device of the NTP message is (T4-T1) - (T3-T2) ═ 2 seconds, so the time difference between the requesting device and the electronic device is ((T2-T1) + (T3-T4))/2 ═ 1 hour, and the requesting device can complete the synchronous update of the time according to the time difference.

Based on the

step

401 and 405 shown in fig. 4, the technical scheme adopted is as follows: the processing request meeting the predefined protocol attribute information is monitored by the transfer process and a corresponding socket connection is established, so that the application layer data is copied to the public protocol process for processing, the transfer process receives the request response information through the local socket and forwards the request response information to the requesting party, and the processing interaction process of the request information is completed.

FIG. 5 is a schematic block diagram of an electronic device in an exemplary embodiment in accordance with the present application. Referring to fig. 5, at the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory, but may also include hardware required for other services. The processor reads the corresponding computer program from the nonvolatile memory into the memory and then runs the computer program to form the request response device on the logic level. Of course, besides the software implementation, the present application does not exclude other implementations, such as logic devices or a combination of software and hardware, and the like, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Referring to fig. 6, in a software implementation, the request responding apparatus may include:

a receiving unit 601, configured to determine that the virtual logic device receives a processing request sent by a requester;

the processing unit 602, when the processing request conforms to the predefined protocol attribute information, sends the processing request to a common protocol process for processing.

Optionally, the common protocol process includes: and (4) a protocol process which has no influence on network connection.

Optionally, the method further includes:

a forwarding unit 603, configured to monitor the processing request by a transit process preconfigured in the virtual logic device and forward the processing request to the common protocol process.

Optionally, the method further includes:

the response forwarding unit 604 returns the processing result generated by the common protocol process to the transit process, so that the transit process forwards the processing result to the requesting party.

Optionally, the processing unit further includes:

the protocol attribute information includes at least one of: protocol port number, protocol type.

The device corresponds to the method, and more details are not repeated.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the application. One of ordinary skill in the art can understand and implement it without inventive effort.

While this application contains many specific implementation details, these should not be construed as limiting the scope of any invention or of what is claimed, but rather as merely describing the features of particular embodiments of particular inventions. Certain features that are described in this application in the context of separate embodiments can also be implemented in combination in a single embodiment. In other instances, features described in connection with one embodiment may be implemented as discrete components or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.

Claims

1. A request response method, applied to an electronic device, where the electronic device is configured with a common protocol process and at least two operating system-level virtual environments, where the common protocol process runs outside the operating system-level virtual environments and is configured with a complete functional protocol process for performing centralized processing on processing requests received by the operating system-level virtual environments in the electronic device, the method comprising:

determining that the operating system level virtual environment receives a processing request sent by a requester;

when the processing request conforms to predefined protocol attribute information, sending the processing request from the operating system level virtual environment to a common protocol process for processing by the full function protocol process.

2. The method of claim 1, wherein the common protocol process comprises: and (4) a protocol process which has no influence on network connection.

3. The method of claim 1, wherein the processing request is intercepted by a transit process preconfigured in the operating system level virtual environment and forwarded to the common protocol process.

4. The method of claim 3, further comprising:

and returning the processing result generated by the common protocol process to the transfer process so as to be forwarded to the requester by the transfer process.

5. The method of claim 1, wherein the protocol attribute information comprises at least one of: protocol port number, protocol type.

6. A request response apparatus, applied to an electronic device, where the electronic device is configured with a common protocol process and at least two operating system-level virtual environments, where the common protocol process runs outside the operating system-level virtual environments, and is configured with a complete functional protocol process, and is used to perform centralized processing on processing requests received by each operating system-level virtual environment in the electronic device, where:

the receiving unit is used for determining that the operating system level virtual environment receives a processing request sent by a requester;

and the processing unit is used for sending the processing request to a common protocol process from the operating system-level virtual environment when the processing request conforms to the predefined protocol attribute information so as to process through the complete functional protocol process.

7. The apparatus of claim 6, wherein the common protocol process comprises: and (4) a protocol process which has no influence on network connection.

8. The apparatus of claim 6, further comprising:

and the processing request is monitored by a transfer process pre-configured in the operating system level virtual environment and is transferred to the common protocol process.

9. The apparatus of claim 8, further comprising:

and the response forwarding unit returns the processing result generated by the common protocol process to the transfer process so as to be forwarded to the requester by the transfer process.

10. The apparatus of claim 6, wherein the protocol attribute information comprises at least one of: protocol port number, protocol type.