Data processing method, cloud storage system and electronic device
By opening the boundary between the application layer and the user-state protocol stack and realizing direct collaboration, the problems of network protocol stack processing delay and CPU scheduling unfriendly in the prior art are solved, and the processing performance of the system is improved.
Patent Information
- Application Number
- PCT/CN2024/104321
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-08-15
- Filing Date
- 2024-07-08
- Publication Date
- 2025-02-20
AI Technical Summary
There are delay problems and unfriendly CPU scheduling during the processing of the existing network protocol stack, resulting in limited system processing performance.
By opening the boundary between the application layer and the user-state protocol stack, the two can collaborate through the direct call relationship, reducing the conversion overhead between data and readable events, and reducing the use of CPU time slices.
The delay in data processing is shortened, the efficiency of CPU scheduling is improved, and thus the processing performance of the system is improved.
Smart Images

Figure CN2024104321_20022025_PF_FP_ABST
Abstract
Description
Data processing method, cloud storage system and electronic device
[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on August 15, 2023, with application number 202311028050.6 and application name “Data processing method, cloud storage system and electronic device”, the entire contents of which are incorporated by reference into this application. Technical Field
[0002] The present application relates to the field of communication technology, and in particular to a data processing method, a cloud storage system, and an electronic device. Background Art
[0003] With the continuous development of network communication technology, the bandwidth and traffic of network communication have increased accordingly, and the processing capacity of the network protocol stack can easily become a bottleneck in system performance.
[0004] Currently, a protocol stack processing process involves multiple time slices of the central processing unit (CPU), which not only causes delay problems but is also not friendly to CPU scheduling, thereby affecting system processing performance.
[0005] Summary of the Invention
[0006] In view of the above problems, the present application is proposed to provide a data processing method, a cloud storage system and an electronic device that solve the above problems or at least partially solve the above problems.
[0007] Therefore, in one embodiment of the present application, a data processing method is provided, which is applied to a first network device; the first network device includes a first application layer, a first user mode protocol stack, and a first network card; the first application layer includes a first application program; the method includes:
[0008] Allocating a first target memory block for the data to be sent of the first application program from a first registered memory space of the first network card using the first application layer;
[0009] Using the first application layer, writing the data to be sent into the first target memory block;
[0010] Using the first application layer to call the first user mode protocol stack to encapsulate the data to be sent in the first target memory block;
[0011] The first network card is used to send the data to be sent after being encapsulated in the first target memory block.
[0012] In another embodiment of the present application, a data processing method is provided, which is applied to a second network device, wherein the second network device includes: a second application layer, a second user mode protocol stack, and a second network card; the second application layer includes a second application program; the method includes:
[0013] Using the second user mode protocol stack to call a query interface provided by the second network card to determine whether the second network card has received network data;
[0014] When it is determined that the second network card receives the network data, decapsulate the network data written by the second network card in a second target memory block using the second user-mode protocol stack; the second target memory block is located in a second registered memory space of the second network card;
[0015] The second application layer is called by the second user mode protocol stack to process the network data after decapsulation in the second target memory block.
[0016] In another embodiment of the present application, a cloud storage system is provided, comprising: a computing node and a storage node; wherein the computing node comprises a first application layer, a first user-mode protocol stack, and a first network card; the first application layer comprises a first application program; the storage node comprises a second application layer, a second user-mode protocol stack, and a second network card; the second application layer comprises a second application program;
[0017] The computing node is configured to: allocate a first target memory block for a read / write request of the first application program from a first registered memory space of the first network card using the first application layer; write the read / write request to the first target memory block using the first application layer; call the first user-mode protocol stack using the first application layer to encapsulate the read / write request in the first target memory block; and send the encapsulated read / write request in the first target memory block to the storage node using the first network card;
[0018] The storage node is configured to: utilize the second user-state protocol stack to call a query interface provided by the second network card to determine whether the second network card has received the read / write request; when it is determined that the second network card has received the read / write request, utilize the second user-state protocol stack to decapsulate the read / write request written by the second network card in a second target memory block; the second target memory block is located in a second registered memory space of the second network card; and utilize the second user-state protocol stack to call the second application layer to process the decapsulated read / write request in the second target memory block.
[0019] In another embodiment of the present application, a first network device is provided, comprising: a memory, a processor, and a first network card, wherein:
[0020] The memory is used to store programs;
[0021] The processor is coupled to the memory and the network card, and is used to execute the program stored in the memory to implement the corresponding data processing method mentioned above.
[0022] In another embodiment of the present application, a second network device is provided, comprising: a memory, a processor, and a second network card, wherein:
[0023] The memory is used to store programs;
[0024] The processor is coupled to the memory and the network card, and is used to execute the program stored in the memory to implement the corresponding data processing method mentioned above.
[0025] In the technical solution provided by the embodiment of the present application, the data to be sent by the application program is located in the registered memory space accessible to the application layer, the user protocol stack, and the network card from the time it is written into the registered memory space of the network card by the application layer until it is sent by the network card, which reduces the number of copies and saves CPU resources. In addition, this solution adopts a user-mode protocol stack and opens up the boundary between the user-mode protocol stack and the application layer, so that the two can collaborate through a direct call relationship. Compared with the solution in the prior art in which the application layer and the user-mode protocol stack need to collaborate through the conversion between data and readable events, this solution not only saves the conversion overhead between data and readable events, but also reduces the CPU time slice involved in the entire processing process. It can be seen that the technical solution provided by the embodiment of the present application can shorten the delay, be friendly to CPU scheduling, and thus improve the system processing performance.
[0026] In the technical solution provided by the embodiment of the present application, after the network data is written into the registered memory space of the network card by the network card and before it is processed by the application, it is always in the registered memory space that can be accessed by the application layer, the user protocol stack and the network card, which reduces the number of copies and saves CPU resources. In addition, this solution adopts a user-mode protocol stack and opens up the boundary between the user-mode protocol stack and the application layer, so that the two can collaborate through a direct call relationship. Compared with the solution in the prior art that the application layer and the user-mode protocol stack need to collaborate through the conversion between data and readable events, it not only saves the conversion overhead between data and readable events, but also reduces the CPU time slice involved in the entire processing process. It can be seen that the technical solution provided by the embodiment of the present application can shorten the delay, be friendly to CPU scheduling, and thus improve the system processing performance. BRIEF DESCRIPTION OF THE DRAWINGS
[0027] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0028] FIG1 is an example diagram of an event triggering model and a data pass-through model provided in an embodiment of the present application;
[0029] FIG2 is a flow chart of a data processing method according to an embodiment of the present application;
[0030] FIG3 is an example diagram of a timing wheel and a linked list provided in an embodiment of the present application;
[0031] FIG4 is a first diagram illustrating an example of communication between a client and a server according to an embodiment of the present application;
[0032] FIG5 is a flow chart of a data processing method according to an embodiment of the present application;
[0033] FIG6 is a schematic diagram of a cloud storage system provided by an embodiment of the present application;
[0034] FIG7 is a second diagram illustrating an example of communication between a client and a server according to an embodiment of the present application;
[0035] FIG8 is a structural block diagram of a first network device provided in an embodiment of the present application;
[0036] FIG9 is a structural block diagram of a second network device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0037] Currently, most protocol stack solutions use an event-triggered model, which has problems such as long delays and being unfriendly to CPU scheduling.
[0038] Taking the kernel-mode protocol stack solution as an example, as shown in Figure 1, in the event-triggered model, when the network card receives network data, it needs to copy the data from the network card to the kernel mode. The kernel-mode protocol stack (the top layer of which is the transport layer) unpacks the data copied from the network card. After the kernel-mode protocol stack completes the unpacking process, it copies the unpacked data to the transport layer in the kernel-mode protocol stack and provides it to the user-mode socket interface. The operating system continuously checks the socket interface for data through an interface. If data is present, a read event is generated (note: this also involves a data copy). When the application detects this read event, it reads the data and copies it to the application's memory. As can be seen from the left side of Figure 1, the entire process involves four copies and three time slices, resulting in high CPU overhead and long latency.
[0039] In order to solve the above technical problems, the present application proposes a new protocol stack processing solution. In the technical solution provided by the embodiment of the present application, the data to be sent by the application program is always in the registered memory space accessible to the application layer, the user protocol stack and the network card after it is written into the registered memory space of the network card by the application layer and before it is sent by the network card, which reduces the number of copies and saves CPU resources; in addition, this solution adopts a user-mode protocol stack and opens up the boundary between the user-mode protocol stack and the application layer, so that the two can collaborate through a direct call relationship. Compared with the solution in the prior art that the application layer and the user-mode protocol stack need to collaborate through the conversion between data and readable events, it not only saves the conversion overhead between data and readable events, but also reduces the CPU time slice involved in the entire processing process. It can be seen that the technical solution provided by the embodiment of the present application can shorten the delay, be friendly to CPU scheduling, and thus improve the system processing performance.
[0040] In order to enable those skilled in the art to better understand the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below based on the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.
[0041] In addition, some of the processes described in the specification, claims and the above-mentioned figures of this application include multiple operations that appear in a specific order. These operations may not be executed in the order in which they appear in this document or may be executed in parallel. The serial numbers of the operations, such as 101, 102, etc., are only used to distinguish between different operations, and the serial numbers themselves do not represent any order of execution. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions of "first", "second", etc. in this document are used to distinguish different messages, devices, modules, etc., and do not represent the order of precedence, nor do they limit "first" and "second" to be different types.
[0042] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.
[0043] Before introducing the data processing method provided in the embodiments of the present application, the network system architecture involved in the data processing method provided in the embodiments of the present application is introduced. The network system includes a first network device and a second network device. The first network device can act as both a sender and a receiver of data. The second network device can act as both a sender and a receiver of data.
[0044] The first network device and the second network device may be connected to each other via the Internet or a mobile network. The mobile network may be of any one of 2G, 2.5G, 3G, 4G, 4G+, and WiMax.
[0045] The first network device can be a terminal, a conventional server, a cloud server, a cloud host, or a virtual center. The second network device can be a terminal, a conventional server, a cloud server, a cloud host, or a virtual center. A server's architecture primarily includes a processor, a hard drive, memory, a system bus, and the like, similar to a general-purpose computer architecture.
[0046] In one example, the first network device includes a first application layer, a first user mode protocol stack, and a first network card; the first application layer includes a first application program; and the first network device may be configured to:
[0047] Allocating a first target memory block for the data to be sent of the first application program from a first registered memory space of the first network card using the first application layer;
[0048] Using the first application layer, writing the data to be sent into the first target memory block;
[0049] Using the first application layer to call the first user mode protocol stack to encapsulate the data to be sent in the first target memory block;
[0050] The first network card is used to send the data to be sent after being encapsulated in the first target memory block.
[0051] In another example, the second network device includes: a second application layer, a second user mode protocol stack, and a second network card; the second application layer includes a second application program; and the second network device can be used to:
[0052] Using the second user mode protocol stack to call a query interface provided by the second network card to determine whether the second network card has received network data;
[0053] When it is determined that the second network card receives the network data, decapsulate the network data written by the second network card in a second target memory block using the second user-mode protocol stack; the second target memory block is located in a second registered memory space of the second network card;
[0054] The second application layer is called by the second user mode protocol stack to process the network data after decapsulation in the second target memory block.
[0055] In a specific example, the network data may be data to be sent by the first network device.
[0056] The specific processing procedures of the first network device and the second network device in the above system will be described in detail in the following embodiments.
[0057] FIG2 is a flow chart of a data processing method provided by an embodiment of the present application. The method is applicable to a first network device; the first network device includes a first application layer, a first user-mode protocol stack, and a first network card; the first application layer includes a first application program. As shown in FIG2 , the method includes:
[0058] 201. Utilize the first application layer to allocate a first target memory block from a first registered memory space of the first network card for data to be sent by the first application program.
[0059] 202. Use the first application layer to write the data to be sent into the first target memory block.
[0060] 203. Use the first application layer to call the first user mode protocol stack to encapsulate the data to be sent in the first target memory block.
[0061] 204. Use the first network card to send the encapsulated data to be sent in the first target memory block.
[0062] In the above step 201, the first application layer includes a first application and a first application layer protocol module. The first application layer protocol module may be a Remote Procedure Call (RPC) protocol module, referred to as the RPC layer. The first application layer protocol module is configured to perform application layer protocol processing on data sent and received by the first application.
[0063] The first registered memory space can be registered with the first network card by the first application layer protocol module. In one example, when the process corresponding to the first application is started, the first application layer protocol module can be used to register the memory with the first network card to obtain the first registered memory space. The memory registered to the network card can be recognized by the network card, that is, the network card has the ability to read and write to this registered memory. In actual applications, the first application layer protocol module can call the interface of the Data Plane Development Kit (DPDK) to register the memory with the network card when the network card is initialized to obtain the registered memory space.
[0064] The first user-mode protocol stack may be a TCP / IP (Transmission Control Protocol / Internet Protocol) protocol stack. The first user-mode protocol stack may include a transport layer, a network layer, and a data link layer. Each layer may support one or more protocols, which is not specifically limited in this embodiment of the present application. In this embodiment of the present application, the topmost protocol layer in the user-mode protocol stack is the transport layer.
[0065] In one example, the step of “using the first application layer to allocate a first target memory block for the data to be sent by the first application from the first registered memory space of the first network card” in step 201 includes:
[0066] 2011. Utilize the first application program to call the first application layer protocol module to allocate a first target memory block for the data to be sent by the first application program from the first registered memory space of the first network card.
[0067] When the first application needs to send data, the first application layer protocol module is called by the first application to allocate a first target memory block for the data to be sent by the first application from the first registered memory space of the first network card.
[0068] In actual applications, the first application layer protocol module may provide a memory block allocation interface to the first application program. When the first application program needs to send data, the first application program invokes the memory block allocation interface provided by the first application layer protocol module to allocate a first target memory block from the first registered memory space of the first network interface card for the data to be sent by the first application program.
[0069] The first application layer protocol module may allocate an idle first target memory block from the first registered memory space based on the memory requirement transmitted by the first application via the memory block allocation interface. The size of the first target memory block is determined based on the memory requirement; the memory requirement is determined by the first application based on the size of data to be sent.
[0070] In actual application, after the first application layer protocol module completes the allocation, the memory address information of the first target memory block can be returned to the first application program, wherein the memory address information may include: the first address of the first target memory block and the length of the first target memory block.
[0071] In the above 202, after the first application receives the memory address information of the first target memory block, the first application is used to write the data to be sent into the first target memory block.
[0072] In addition, before step 203, the method may further include:
[0073] The first application program is used to call the first application layer protocol module to perform application layer encapsulation processing on the data to be sent in the first target memory block.
[0074] That is, an application layer header is added to the data to be sent. The first application layer protocol module can provide an application layer encapsulation processing interface to the first application program. After the first application program writes the data to be sent to the first target memory block, the first application program calls the application layer encapsulation processing interface, so that the first application layer protocol module performs application layer encapsulation processing on the data to be sent in the first target memory block.
[0075] In the above step 203, the first application layer protocol module may be used to call the first user-mode protocol stack to perform encapsulation processing on the data to be sent in the first target memory block. Specifically, after the application layer encapsulation processing is completed, the first application layer protocol module may be used to call the first user-mode protocol stack to perform encapsulation processing on the data to be sent in the first target memory block. Encapsulation processing here refers to further encapsulation processing on the results of the above application layer encapsulation processing.
[0076] The first user-state protocol stack can provide a user-state encapsulation processing interface to the first application layer protocol module; after the application layer encapsulation processing is completed, the first application layer protocol module is used to call the user-state encapsulation processing interface so that the first user-state protocol stack can encapsulate the data to be sent in the first target memory block.
[0077] In actual applications, the first user-mode protocol stack includes a transport layer, a network layer, and a data link layer arranged from top to bottom. These three layers encapsulate the data to be sent in turn to obtain the final encapsulated data.
[0078] In the above 204, in actual applications, the first user mode protocol stack can be used to notify the first network card to send the to-be-sent data after encapsulation in the first target memory block.
[0079] In the technical solution provided by the embodiment of the present application, the data to be sent by the application program is located in the registered memory space accessible to the application layer, the user protocol stack, and the network card from the time it is written into the registered memory space of the network card by the application layer until it is sent by the network card, which reduces the number of copies and saves CPU resources. In addition, this solution adopts a user-mode protocol stack and opens up the boundary between the user-mode protocol stack and the application layer, so that the two can collaborate through a direct call relationship. Compared with the solution in the prior art in which the application layer and the user-mode protocol stack need to collaborate through the conversion between data and readable events, this solution not only saves the conversion overhead between data and readable events, but also reduces the CPU time slice involved in the entire processing process. It can be seen that the technical solution provided by the embodiment of the present application can shorten the delay, be friendly to CPU scheduling, and thus improve the system processing performance.
[0080] It's important to note that breaking the boundary between the application layer and the user-mode protocol stack essentially breaks the boundary between the application layer and the transport layer. The prerequisite for the application layer and the transport layer in the user-mode protocol stack to interact through interface calls is that both are in user mode. In the data pass-through model, shown on the right side of Figure 1, direct calls between the application layer and the transport layer allow the entire protocol stack to complete within a single CPU time slice. Compared to traditional event-driven models, this offers better performance, shorter links, and greater CPU resource savings.
[0081] The traditional cross-language and platform serialized data structure (ProtoBuf) has high development efficiency and strong scalability, but serialization consumes a lot of CPU. However, in some application scenarios (for example, cloud storage scenarios), the fields involved in the application layer protocol are rarely adjusted. Therefore, the above 202 "using the first application layer to write the data to be sent to the first target memory block" may include:
[0082] 2021. Use the first application layer to write the data to be sent into the first target memory block in binary form.
[0083] Specifically, the data to be sent is written into the first target memory block in binary form using the first application.
[0084] In this solution, you can negotiate with the application in advance and request that it directly provide the data to be sent in binary format. The application can then directly convert the data structure to binary format and write it to the target memory block. Subsequently, throughout the entire processing chain, the memory address of the target memory block is simply passed. This saves subsequent serialization operations and effectively reduces CPU overhead.
[0085] In a specific example, the first target memory block is reserved with a first filling position for the data to be sent, a second filling position for the message header corresponding to the application layer, and a third filling position for the message header corresponding to each protocol layer in the first user-mode protocol stack; wherein, the first filling position and the second filling position are filled by the first application layer; and the third filling position is filled by each protocol layer in the first user-mode protocol stack. Specifically, the first filling position is filled by the first application program of the first application layer; and the second filling position is filled by the first application layer protocol module. Specifically, the first target memory block is reserved with, from front to back: the third filling position for the message header corresponding to the data link layer, the third filling position for the message header corresponding to the network layer, the third filling position for the message header corresponding to the transport layer, the third filling position for the message header corresponding to the application layer, the second filling position for the message header corresponding to the first application layer, and the first filling position for the data to be sent.
[0086] Optionally, the first network device includes a network client device; the data to be sent includes a request to be sent; and the method may further include:
[0087] 205. Utilize a run-to-termination thread model to allocate a target thread for the initial to-be-sent request of the application from multiple threads of the process corresponding to the first application.
[0088] 206. Generate a second request identifier for the initial request to be sent according to the first request identifier of the request issued by the target thread.
[0089] The second request identifier is different from the first request identifier of the request issued by the target thread.
[0090] 207. Generate the request to be sent according to the second request identifier and the initial request to be sent.
[0091] 208. Allocate the request to be sent to the target thread, so that the target thread executes the following steps ad.
[0092] a. Utilize the first application layer to allocate the first target memory block for the request to be sent from the first registered memory space of the first network card.
[0093] b. Use the first application layer to write the request to be sent into the first target memory block.
[0094] c. Using the first application layer to call the first user-mode protocol stack to encapsulate the request to be sent in the first target memory block.
[0095] d. Using the first network card, the to-be-sent request in the first target memory block that has been encapsulated is sent to a network service device through a network connection associated with the target thread.
[0096] In which, the response data returned by the network server device for the request to be sent includes the second request identifier; the network server device returns the response data through the network connection associated with the target thread; the connections associated with different threads of the process are different network connections between the network client device and the network server device.
[0097] In one feasible solution, a full mesh mode can be adopted between the network client device and the network server device, that is, each thread of the process on the network client device is connected to all threads on the network server.
[0098] The Run To Complete (RTC) thread model refers to a model in which when an event occurs, the entire thread resource is monopolized until the event processing is completed, and no thread switching occurs in the middle.
[0099] In the above 205, in one example, an idle thread is selected from multiple threads of the process corresponding to the first application using a run-to-termination thread model; and the idle thread is used as a target thread allocated to the initial request to be sent of the application.
[0100] In the above 206 , based on the first request identifier of the request already issued by the target thread, a second request identifier different from the first request identifier of the request already issued by the target thread is generated for the initial request to be sent.
[0101] In one feasible solution, to reduce the cost of request identifier generation, a request identifier auto-increment method can be used to generate request identifiers. Therefore, the first request identifier of the target thread's most recent request can be obtained, and a second request identifier can be generated based on the first request identifier according to a preset auto-increment strategy. For example, a preset value (e.g., 1) can be added to the first request identifier to obtain the second request identifier.
[0102] In the above 207, the request to be sent includes the second request identifier and the initial request to be sent.
[0103] In the above 208 , the request to be sent is assigned to the target thread, and the target thread executes the above steps 201 , 202 , 203 and 204 to send the request to be sent to the network service device through the network connection associated with the target thread.
[0104] After receiving the request to be sent, the network server device unpacks the request to be sent; processes the unpacked request to be sent to obtain response data; encapsulates the response data to obtain encapsulated response data; and returns the encapsulated response data to the network client via its network card. Specifically, the network server returns the response data to the network client via the network connection associated with the target thread.
[0105] The specific processing process of the network server device for the received request to be sent will be described in detail in the following embodiments. The specific processing process of the network server for the response data can refer to the processing process of the network client for the request to be sent.
[0106] In this solution, the request ID of each request only needs to be unique on the thread that issues the request, and does not need to be unique across the entire process. This is because this solution has the following two characteristics:
[0107] First point: In the RTC thread model, the entire life cycle of a request is maintained by a single thread. The entire life cycle of a request includes: request sending, response receiving, timeout handling, etc.
[0108] Second, each thread is associated with a different network connection, meaning multiple threads cannot share the same network connection. Thus, when a network client receives a response through a network connection, the thread associated with that network connection can be determined based on the network connection. The thread associated with that network connection is also the thread that originally issued the request for which the response was received. Once the thread associated with the network connection is determined, the request to which the response refers can be uniquely determined from all requests issued by that thread using the request identifier carried in the response, which is guaranteed to be unique to that thread.
[0109] In actual applications, the client and the server use a multi-request concurrent mode. Therefore, after receiving the above response data, it is necessary to find the context information corresponding to the response data to determine which request the response data is for.
[0110] Therefore, the above method may further include:
[0111] 209 After receiving the response data, determine, according to the second request identifier, the position of the request to which the response data refers in the array of issued requests corresponding to the target thread.
[0112] The position of the issued request of the target thread in the issued request array is determined by the request identifier of the issued request.
[0113] 210 Determine the request to which the response data is directed from the array of issued requests according to the position.
[0114] In this solution, the above-mentioned response data must be received by the above-mentioned target thread through the network connection associated with it. Therefore, after the target thread receives the above-mentioned response data, it can determine the position of the request to which the response data corresponds in the array of issued requests corresponding to this thread based on the second request identifier.
[0115] In the above 209, in this solution, for each thread, an array for recording the requests that have been issued by the thread, that is, the issued request array, is maintained. Moreover, the position of the issued request of the target thread in the issued request array corresponding to the target thread is determined by the request identifier of the issued request. In one instance, a hash calculation can be performed on the request identifier of the issued request to obtain a hash result; and the position of the issued request in the array is determined based on the hash result. For example: the length of the issued request array is 128; the request identifier of the first request issued by the target thread is 1, the request identifier of the second request is 2, the request identifier of the third request is 3, and so on; thus, the request identifier of the nth request issued by the target thread is n; then, the hash calculation formula can be: n%128, and the value of the hash calculation formula is the position of the nth request in the issued request array.
[0116] A preset hash calculation is performed on the second request identifier to obtain the position of the request to which the response data corresponds in the array of issued requests corresponding to the target thread.
[0117] In the above 210 , the request to which the response data is directed is obtained from the position in the array of issued requests.
[0118] Optionally, the network client device is a computing node in a cloud storage system, and the network server device is a storage node in the cloud storage system. Then, the request to be sent may be a read or write request.
[0119] From the above analysis, it can be seen that the embodiment of the present application only needs to ensure that the request identifier is unique on the thread, and does not need to ensure that the request identifier is unique on the process (or globally unique). Compared with the prior art, a global request identifier generation module is required to ensure the global uniqueness of the request identifier. In this solution, the global request identifier generation module has a high maintenance cost, and in multi-threaded scenarios, global locks will be frequently called to ensure multi-threaded security, which is inefficient.
[0120] In actual applications, the client side will generate a scheduled task for the request, which can also be called a timer. Generally, the timer corresponds to a timeout point. Once the response data packet of the request is not received after the timeout point, the request is considered to have timed out, that is, the timer has expired. Once the timer of a request expires, it is necessary to execute a retry mechanism for the request, thereby improving the response rate of the request and reducing the impact on the user experience. In the prior art, all scheduled tasks are usually placed in a queue, and each timed task records the timeout point. Each time a scheduled task is inserted or deleted, the queue needs to be traversed from beginning to end. The time consumption of this traversal method is O(n). In some application scenarios, such as cloud storage scenarios, through research and request feature collection, it is found that more than 90% of requests are completed normally and do not wait until the request timeout timer is triggered, which means that the request timeout accuracy is not necessary to the millisecond level. Therefore, in order to reduce the maintenance consumption of scheduled tasks, the above method may also include:
[0121] 211 determines a timeout point corresponding to the request to be sent according to the current time of the time wheel and the preset delay duration corresponding to the request to be sent.
[0122] 212 , according to the timeout time point corresponding to the request to be sent, a target scale matching the timeout time point is determined from the time wheel.
[0123] 213 adds the timer of the request to be sent to the linked list corresponding to the target scale.
[0124] 214 When the target scale arrives, delete the linked list corresponding to the target scale.
[0125] In the above 211, the current time refers to the position currently pointed to by the pointer of the time wheel.
[0126] The preset delay time corresponding to the request to be sent can be determined by the application, and the preset delay time corresponding to different requests can be different. The sum of the current time and the preset delay time corresponding to the request to be sent can be used as the timeout time point of the request.
[0127] In one example, the target scale can be the mark on the time wheel closest to the timeout point. In another example, it is determined whether there is a mark on the time wheel that coincides with the timeout point. If so, the mark on the time wheel that coincides with the timeout point is used as the target scale. If not, the smallest mark on the time wheel that is later than the timeout point is used as the target scale.
[0128] The duration corresponding to one revolution of the timing wheel can be set based on actual needs and is not specifically limited in this embodiment of the present application. For example, the duration corresponding to one revolution of the timing wheel can be 128 seconds. The timing wheel can be divided into scales according to preset time intervals, wherein the preset time intervals can also be set based on actual needs and is not specifically limited in this embodiment of the present application. For example, a preset time interval of 1 second means that the timer accuracy is at the second level.
[0129] In this way, through calculation, timers for multiple requests with small differences can be placed in a linked list at the same scale, which simplifies the search and maintenance costs of timer insertion. In addition, multiple timers at the same scale are organized through a linked list, and the cost of deleting a node is O(1). The combined design of the time wheel and the linked list can improve the search efficiency to O(1). As shown in Figure 3, 5 business requests were generated at 00:00:00:
[0130] If the request timeout of a is 0.9s, then a is directly put into the linked list of the time wheel 301 with a scale of 1s;
[0131] If the request timeout of b is 1.3s, put b into the linked list with a scale of 2s;
[0132] The timeout for request c is 63.9s, the timeout for request d is 64.0s, and the timeout for request e is 63.3s. All three requests are placed in a linked list with a scale of 64.
[0133] The timer wheel in Figure 3 supports a maximum timer timeout of 128 seconds. For example, in cloud storage scenarios, the timeout is reduced to 20 seconds at most, and there's no need for a longer timeout. Therefore, limiting the duration of one revolution of the timer wheel can simplify timer maintenance.
[0134] In step 213 above, the linked list corresponding to the target scale is found, and the timer for the pending request is added to the linked list corresponding to the target scale. Specifically, the timer for the pending request can be added at any position in the linked list corresponding to the target scale. The arbitrary position can be the end of the linked list, so that the original structure of the linked list is not changed.
[0135] It can be seen that in this scheme, when inserting a timer, the search time consumption is O(1).
[0136] In step 214, when the target scale arrives, it indicates that all timers in the linked list corresponding to the target scale have timed out. Therefore, all timers under the target scale need to be deleted. In practical applications, in addition to deleting all timers under the target scale, it is also necessary to perform corresponding retry operations on these timers. The specific implementation of the retry operation can be found in the prior art and will not be described in detail here.
[0137] To facilitate linked list maintenance, the linked list can be a bidirectional linked list. Furthermore, to save storage space, the linked list can be stored based on the sent request array. Specifically, the sent request array can store, for each sent request stored therein, a direct successor address pointer and a direct predecessor address pointer associated with the sent request; the direct successor address pointer points to the request corresponding to the direct successor timer of the sent request in the corresponding linked list; and the direct predecessor address pointer points to the request corresponding to the direct predecessor timer of the sent request in the corresponding linked list.
[0138] Traditional network frameworks only support one specific transport layer protocol during runtime, such as TCP (Transmission Control Protocol), UDP (User Datagram Protocol) and RDMA (Remote Direct Memory Access), which greatly limits the deployment scalability of the client and server. The framework provided in the embodiment of the present application implements a multi-network platform autonomous negotiation and adaptive solution, supporting the deployment of clients and servers based on different network transport layers. A common usage scenario is: half of the machines in a cluster are configured with Melos network cards, which use RDMA; the other half of the machines are configured with Broadcom network cards, which can use the high-performance RDMA protocol: solar.
[0139] If a client process needs to connect to both machines in the cluster simultaneously for communication, the client must be able to autonomously negotiate with the server to adapt to a multi-network environment. As shown in Figure 4, a handshake mechanism can be implemented between the client and server. Specifically, when an application needs to send data, the client initiates a handshake. After receiving the handshake request, the server sends the client a handshake response containing the transport layer protocols it supports. The client then selects the appropriate transport layer protocol for communication based on the server's support and its own protocol.
[0140] Specifically, the first user-mode protocol stack includes a transport layer; the above method may further include:
[0141] 215. Send a handshake request to the network server device.
[0142] 216. Receive a handshake response returned by the network server device in response to the handshake request.
[0143] The handshake response carries the transport layer protocol supported by the network server device.
[0144] 217. Configure a target transport layer protocol of the transport layer in the first user mode protocol stack according to the transport layer protocol supported by the network server device and the transport layer protocol supported by the network client in the handshake response.
[0145] In the above 216, the handshake response may carry a list of transport layer protocols supported by the network server device.
[0146] In the above 217, one may be selected from the intersection of the transport layer protocols supported by the network server device and the transport layer protocols supported by the network client as the target transport layer protocol of the transport layer in the first user mode protocol stack.
[0147] In this embodiment, the transport layer protocols supported by the client and server only need to overlap, not be completely identical. This improves the scalability of client and server deployments. Based on this solution, users can flexibly choose different transport layer protocols on both the client and server for deployment.
[0148] For example, as shown in Figure 4, Server 1 supports TCP; Server 2 supports TCP and the enhanced RDMA protocol, Luna; and Server 3 supports RDMA and TCP. Clients support TCP, UDP, Luna, Solar, and RDMA. Therefore, after negotiation, Client 1 communicates with Server 1 using TCP; Client 2 communicates with Server 2 using Luna; and Client 3 communicates with Server 3 using RDMA.
[0149] In practical applications, the above method may further include:
[0150] 218. Use the first user mode protocol stack to call the query interface provided by the first network card to determine whether the first network card receives network data.
[0151] 219. When it is determined that the first network card receives the network data, use the first user mode protocol stack to decapsulate the network data written by the first network card in the third target memory block.
[0152] The third target memory block is located in the first registered memory space of the first network card.
[0153] 220. Use the first user-mode protocol stack to call the first application layer to process the decapsulated network data in the first target memory block.
[0154] In the above 218 , in one example, the network data may be response data of the above request to be sent.
[0155] The query interface provided by the first network card may be called once by using the first user mode protocol stack at every preset time interval to determine whether the first network card has received network data.
[0156] After receiving the network data, the first network card writes the network data to a third target memory block within the first registered memory block of the first network card. The third target memory block may be allocated by the first network card for the network data after receiving the network data. The first registered memory space is registered with the first network card by the first application layer. In one embodiment, the first application layer may further include a first application layer protocol module. When a process corresponding to the first application is started, the first application layer protocol module is used to register memory with the first network card to obtain the first registered memory space.
[0157] In one specific example, the first network card can write network data to the third target memory block in the first registered memory block of the first network card through a DMA (Direct Memory Access) operation. DMA technology allows peripheral devices (such as network cards) to directly access memory through a DMA controller while the CPU continues to execute programs without interrupting the CPU.
[0158] In the above 219, after the first user-state protocol stack calls the query interface, if the first network card receives network data, it can return the memory address information of the third target memory block corresponding to the network data to the first user-state protocol stack through the query interface; if the first network card does not receive the network data, it can inform the first user-state protocol stack through the query interface that the data has not been received.
[0159] If the first network card returns memory address information of the third target memory block through the query interface, it can be determined that the first network card has received the network data. When it is determined that the first network card has received the network data, the first user-mode protocol stack is used to decapsulate the network data written by the first network card in the third target memory block based on the memory address information of the third target memory block.
[0160] In the above 220, after the decapsulation process is completed, the first user-mode protocol stack is used to call the first application layer to process the decapsulated network data in the third target memory block. The first application layer protocol module of the first application layer further decapsulates the decapsulated network data. After the first application layer protocol module completes the decapsulation process, the first application layer protocol module is used to call the first application program to process the final decapsulated network data.
[0161] The decapsulation process is to strip the corresponding message header from the network data in the third target memory block. The calling method involved in this solution can be an interface calling method.
[0162] FIG5 is a flow chart of a data processing method provided in an embodiment of the present application. The method is applied to a second network device, the second network device including: a second application layer, a second user-mode protocol stack, and a second network card; the second application layer includes a second application program. As shown in FIG5 , the method includes:
[0163] 501. Use the second user mode protocol stack to call a query interface provided by the second network card to determine whether the second network card receives network data.
[0164] 502. When it is determined that the second network card receives the network data, decapsulate the network data written by the second network card in the second target memory block using the second user mode protocol stack.
[0165] The second target memory block is located in the second registered memory space of the second network card.
[0166] 503. Use the second user-mode protocol stack to call the second application layer to process the decapsulated network data in the second target memory block.
[0167] In the above 501, the query interface provided by the second network card may be called once at every preset time interval using the second user mode protocol stack to determine whether the second network card has received network data.
[0168] After receiving the network data, the second network card writes the network data to a second target memory block in the second registered memory block of the second network card. The second target memory block may be allocated by the second network card for the network data after receiving the network data. The second registered memory space is registered with the second network card by the second application layer. In one embodiment, the second application layer may further include a second application layer protocol module. When the process corresponding to the second application is started, the second application layer protocol module is used to register the memory with the second network card to obtain the second registered memory space.
[0169] In a specific example, the second network card may write the network data into the second target memory block in the second registered memory block of the second network card through a DMA operation.
[0170] In the above 502, after the second user-state protocol stack calls the query interface, if the second network card receives network data, it can return the memory address information of the second target memory block corresponding to the network data to the second user-state protocol stack through the query interface; if the second network card does not receive the network data, it can inform the second user-state protocol stack through the query interface that the data has not been received.
[0171] If the second network card returns memory address information of the second target memory block through the query interface, it can be determined that the second network card has received the network data. When it is determined that the second network card has received the network data, the second user-mode protocol stack is used to decapsulate the network data written by the second network card in the second target memory block based on the memory address information of the second target memory block.
[0172] In 503 above, after the decapsulation process is completed, the second user-mode protocol stack is used to call the second application layer to process the decapsulated network data in the second target memory block. The second application layer protocol module of the second application layer further decapsulates the decapsulated network data. After the second application layer protocol module completes the decapsulation process, the second application layer protocol module is used to call the second application program to process the final decapsulated network data.
[0173] The decapsulation process is to strip the corresponding message header from the network data in the second target memory block. The calling method involved in this solution can be an interface calling method.
[0174] In the technical solution provided by the embodiment of the present application, after the network data is written into the registered memory space of the network card by the network card and before it is processed by the application, it is always in the registered memory space that can be accessed by the application layer, the user protocol stack and the network card, which reduces the number of copies and saves CPU resources. In addition, this solution adopts a user-mode protocol stack and opens up the boundary between the user-mode protocol stack and the application layer, so that the two can collaborate through a direct call relationship. Compared with the solution in the prior art that the application layer and the user-mode protocol stack need to collaborate through the conversion between data and readable events, it not only saves the conversion overhead between data and readable events, but also reduces the CPU time slice involved in the entire processing process. It can be seen that the technical solution provided by the embodiment of the present application can shorten the delay, be friendly to CPU scheduling, and thus improve the system processing performance.
[0175] In the embodiment of the present application, the topmost protocol layer in the second user-mode protocol stack is the transport layer.
[0176] In one example, the network data may be a request to be sent from the first network device.
[0177] Note: The protocol processing process of the second network device is the opposite of the protocol processing process of the first network device in the above embodiments. Therefore, the protocol processing process of the second network device can refer to the corresponding content in the above embodiments and will not be described in detail here.
[0178] It should be noted that for any steps not fully described in detail in the methods provided in the embodiments of the present application, reference may be made to the corresponding contents in the aforementioned embodiments, and no further elaboration is required here. Furthermore, in addition to the aforementioned steps, the methods provided in the embodiments of the present application may also include some or all of the other steps in the aforementioned embodiments, for which reference may be made to the corresponding contents in the aforementioned embodiments, and no further elaboration is required here.
[0179] FIG6 shows a schematic diagram of a cloud storage system provided by an embodiment of the present application. As shown in FIG6 , the cloud storage system includes: a computing node 601 and a storage node 602. The number of storage nodes 602 can be one or more. The computing node includes a first network card, a first user-mode protocol stack, and a first network card; the first application layer includes a first application; the storage node includes a second application layer, a second user-mode protocol stack, and a second network card; the second application layer includes a second application;
[0180] The computing node 601 is configured to: allocate a first target memory block for the read / write request of the first application program from the first registered memory space of the first network card using the first application layer; write the read / write request to the first target memory block using the first application layer; call the first user-mode protocol stack using the first application layer to encapsulate the read / write request in the first target memory block; and send the encapsulated read / write request in the first target memory block to the storage node 602 using the first network card;
[0181] The storage node 602 is used to: use the second user-state protocol stack to call the query interface provided by the second network card to determine whether the second network card has received the read / write request; when it is determined that the second network card has received the read / write request, use the second user-state protocol stack to decapsulate the read / write request written by the second network card in the second target memory block; the second target memory block is located in the second registered memory space of the second network card; and use the second user-state protocol stack to call the second application layer to process the decapsulated read / write request in the second target memory block.
[0182] In actual applications, after the storage node 602 processes the read / write request and obtains the response data corresponding to the request, it may further perform the following steps:
[0183] Utilize the second application layer to allocate a fourth target memory block for the response data from the second registered memory space of the second network card; utilize the second application layer to write the response data into the fourth target memory block; utilize the second application layer to call the second user-mode protocol stack to encapsulate the response data in the fourth target memory block; utilize the second network card to send the encapsulated response data in the fourth target memory block to the computing node 601.
[0184] Specifically, the second application is used to call the second user-state protocol stack to allocate a fourth target memory block for the response data from the second registered memory space of the second network card; the second application is used to write the response data into the fourth target memory block; the second application is used to call the second application layer protocol module to perform application layer protocol processing on the response data in the fourth target memory block; the second application layer protocol module is used to call the second user-state protocol stack to further encapsulate the response data in the fourth target memory block; and the second network card is used to send the encapsulated response data in the fourth target memory block to the computing node 601.
[0185] In addition, the above-mentioned computing node 601 is also used to: use the first user-state protocol stack to call the query interface provided by the first network card to determine whether the first network card has received the response data; when it is determined that the first network card has received the response data, use the first user-state protocol stack to decapsulate the response data written by the first network card in the third target memory block; wherein, the third target memory block is located in the first registered memory space of the first network card; use the first user-state protocol stack to call the first application layer to process the response data after decapsulation in the first target memory block.
[0186] The specific processing procedures of the computing node 601 and the storage node 602 can be found in the corresponding contents of the above embodiments, which will not be repeated here.
[0187] The entire processing flow of the cloud storage system in this solution is shown in Figure 7. The entire processing flow is roughly divided into the following steps:
[0188] Step 1: The client maintains the request context.
[0189] Maintaining the request context includes maintaining the above-mentioned array of sent requests, which involves functions such as request uniqueness guarantee, timeout timing, and request search.
[0190] Step 2: The client performs RPC encoding.
[0191] Step 3: The client encapsulates the request using the first user mode protocol stack.
[0192] Step 4: The server uses the second user-mode protocol stack to decapsulate the request.
[0193] Step 5: The server performs RPC decoding.
[0194] Step 6: Service lookup for request processing.
[0195] The client side is also the computing node; the server side is also the storage node. The specific implementation of each step can be found in the corresponding content of the above embodiments, and will not be repeated here.
[0196] The technical solution proposed in this application works with applications to implement a simple, high-performance request context management strategy, a lightweight timer suitable for applications, a lightweight coding design based on cross-layer binary data transmission, a data pass-through model, and a full-link cross-layer zero-copy feature, allowing data to go directly from the application to the network card, bringing the ultimate performance experience to the application. Experimental data shows that compared to existing technologies, the use of this solution can improve the performance of the entire link by 64%, of which the lightweight timer can bring 8% performance optimization; the lightweight coding design can bring 20% performance optimization; the data pass-through model can bring 22% performance optimization; and the full-link cross-layer zero-copy feature can bring 14% performance optimization.
[0197] Figure 8 shows a schematic structural diagram of a first network device provided in an embodiment of the present application. As shown in Figure 8, the first network device includes a memory 1101, a processor 1102, and a first network card. The memory 1101 can be configured to store various other data to support operations on the electronic device. Examples of such data include instructions for any application or method operating on the electronic device. The memory 1101 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read only memory (EEPROM), erasable programmable read only memory (EPROM), programmable read only memory (PROM), read only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.
[0198] The memory 1101 is used to store programs;
[0199] The processor 1102 is coupled to the memory 1101 and is configured to execute the program stored in the memory 1101 to implement the method or function adapted to the first network device in the above embodiment.
[0200] Furthermore, as shown in Figure 8, the electronic device also includes other components such as a communication component 1103, a display 1104, a power supply component 1105, and an audio component 1106. The communication component 1103 includes a first network card. Figure 8 only schematically illustrates some components, and does not mean that the electronic device only includes the components shown in Figure 8.
[0201] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, which, when executed by a computer, can implement the method or function adapted to the first network device in the above embodiment.
[0202] Figure 9 shows a schematic structural diagram of a second network device provided in an embodiment of the present application. As shown in Figure 9, the first network device includes a memory 1201, a processor 1202, and a second network card. The memory 1201 can be configured to store various other data to support operations on the electronic device. Examples of such data include instructions for any application or method operating on the electronic device. The memory 1201 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read only memory (EEPROM), electrical programmable read only memory (EPROM), programmable read only memory (PROM), read only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.
[0203] The memory 1201 is used to store programs;
[0204] The processor 1202 is coupled to the memory 1201 and is configured to execute the program stored in the memory 1201 to implement the method or function adapted to the second network device in the above embodiment.
[0205] Furthermore, as shown in Figure 9, the electronic device also includes other components such as a communication component 1203, a display 1204, a power supply component 1205, and an audio component 1206. The communication component 1203 includes a second network card. Figure 9 only schematically illustrates some components, and does not mean that the electronic device only includes the components shown in Figure 9.
[0206] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, which, when executed by a computer, can implement the method or function adapted to the second network device in the above embodiment.
[0207] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they may be located in one location or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of the present embodiment. Persons of ordinary skill in the art will be able to understand and implement the present invention without inventive effort.
[0208] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, or of course, by hardware. Based on this understanding, the above technical solution, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product can be stored in a computer-readable storage medium, such as ROM (Read Only Memory) / RAM (Random Access Memory), a disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or certain parts of the embodiments.
[0209] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.
Claims
1. A data processing method, characterized in that: Applied to a first network device; the first network device includes a first application layer, a first user mode protocol stack and a first network card; the first application layer includes a first application program; the method includes: Allocating a first target memory block for the to-be-sent data of the first application program from a first registered memory space of the first network card using the first application layer; Using the first application layer to write the data to be sent into the first target memory block; Using the first application layer to call the first user mode protocol stack, so as to encapsulate the data to be sent in the first target memory block; The first network card is used to send the data to be sent after being encapsulated in the first target memory block.
2. The method according to claim 1, characterized in that The first application layer also includes: a first application layer protocol module; Allocating a first target memory block for the to-be-sent data of the first application program from a first registered memory space of the first network card using the first application layer includes: The first application layer protocol module is called by the first application to allocate a first target memory block for the data to be sent by the first application from the first registered memory space of the first network card.
3. The method according to claim 2, characterized in that Writing the to-be-sent data into the first target memory block using the first application layer includes: Using the first application program to write the data to be sent into the first target memory block; The method, before using the first application layer to call the first user mode protocol stack to encapsulate the data to be sent in the first target memory block, further includes: The first application program is used to call the first application layer protocol module to perform application layer encapsulation processing on the data to be sent in the first target memory block.
4. The method according to claim 3, characterized in that Writing the to-be-sent data into the first target memory block using the first application layer includes: The data to be sent is written into the first target memory block in binary form using the first application.
5. The method according to any one of claims 1 to 4, characterized in that A first filling position for the data to be sent, a second filling position for the message header corresponding to the application layer, and a third filling position for the message header corresponding to each protocol layer in the first user mode protocol stack are reserved in the first target memory block; The first filling position and the second filling position are filled by the first application layer; and the third filling position is filled by the corresponding protocol layers in the first user mode protocol stack.
6. The method according to any one of claims 1 to 4, characterized in that The first network device includes a network client device; the data to be sent includes a request to be sent; the method further includes: Allocating a target thread for an initial request to be sent of the application from a plurality of threads of a process corresponding to the first application using a run-to-termination thread model; Generate a second request identifier for the initial request to be sent according to the first request identifier of the request issued by the target thread; wherein the second request identifier is different from the first request identifier of the request issued by the target thread; generating the request to be sent according to the second request identifier and the initial request to be sent; The request to be sent is assigned to the target thread for execution by the target thread: the first application layer is used to allocate the first target memory block for the request to be sent from the first registered memory space of the first network card; the first application layer is used to write the request to be sent into the first target memory block; the first application layer is used to call the first user state protocol stack to encapsulate the request to be sent in the first target memory block; and the first network card is used to send the encapsulated request to be sent in the first target memory block to the network service end device through the network connection associated with the target thread; Among them, the response data returned by the network server device for the request to be sent includes the second request identifier; the network server device returns the response data through the network connection associated with the target thread; the connections associated with different threads of the process are different from the network connections between the network client device and the network server device.
7. The method according to claim 6, characterized in that The network client device includes a computing node in a cloud storage system; the network service end device includes a storage node in the cloud storage system; and the request to be sent includes a read and write request.
8. The method according to claim 6, characterized in that Also includes: After receiving the response data, determining the position of the request to which the response data refers in the issued request array corresponding to the target thread according to the second request identifier; the position of the issued request of the target thread in the issued request array is determined by the request identifier of the issued request; The request to which the response data is directed is determined from the array of issued requests according to the position.
9. The method according to claim 6, characterized in that The first user mode protocol stack includes a transport layer; Sending a handshake request to the network server device; Receiving a handshake response returned by the network service end device in response to the handshake request; the handshake response carries a transport layer protocol supported by the network service end device; According to the transport layer protocol supported by the network server device and the transport layer protocol supported by the network client in the handshake response, a target transport layer protocol of the transport layer in the first user mode protocol stack is configured.
10. The method according to claim 6, characterized in that Also includes: Determine the timeout time point corresponding to the request to be sent according to the current time of the time wheel and the preset delay time length corresponding to the request to be sent; According to the timeout time point corresponding to the request to be sent, determining a target scale matching the timeout time point from the time wheel; Adding a timer for the request to be sent in the linked list corresponding to the target scale; When the target scale arrives, the linked list corresponding to the target scale is deleted.
11. A data processing method, characterized in that: Applied to a second network device, the second network device includes: a second application layer, a second user mode protocol stack and a second network card; the second application layer includes a second application program; the method includes: Using the second user state protocol stack to call the query interface provided by the second network card to determine whether the second network card has received the network data; When it is determined that the second network card receives the network data, decapsulate the network data written by the second network card in the second target memory block by using the second user state protocol stack; the second target memory block is located in the second registered memory space of the second network card; The second user-mode protocol stack is used to call the second application layer to process the network data after decapsulation in the second target memory block.
12. A cloud storage system, characterized in that: include: A computing node and a storage node; wherein the computing node includes a first application layer, a first user state protocol stack and a first network card; the first application layer includes a first application program; the storage node includes a second application layer, a second user state protocol stack and a second network card; the second application layer includes a second application program; The computing node is used to: use the first application layer to allocate a first target memory block from the first registered memory space of the first network card for the read and write request of the first application; use the first application layer to write the read and write request to the first target memory block; use the first application layer to call the first user state protocol stack to encapsulate the read and write request in the first target memory block; use the first network card to send the encapsulated read and write request in the first target memory block to the storage node; The storage node is used to: use the second user state protocol stack to call the query interface provided by the second network card to determine whether the second network card has received the read and write request; when it is determined that the second network card has received the read and write request, use the second user state protocol stack to decapsulate the read and write request written by the second network card in the second target memory block; the second target memory block is located in the second registered memory space of the second network card; use the second user state protocol stack to call the second application layer to process the read and write request in the second target memory block after decapsulation.
13. A first network device, characterized in that: include: A memory, a processor and a first network card, wherein: The memory is used to store programs; The processor is coupled to the memory and the network card, and is used to execute the program stored in the memory to implement the data processing method according to any one of claims 1 to 10.
14. A second network device, characterized in that: include: A memory, a processor and a second network card, wherein: The memory is used to store programs; The processor is coupled to the memory and the network card, and is used to execute the program stored in the memory to implement the data processing method according to claim 11.
Citation Information
Patent Citations
Glusterfs-based network communication optimization method and device
CN113067849A
Data transmission method and device, network equipment and storage medium
CN113485823A
Efficient TCP / IP datagram processing method and system
CN115103036A
Managing configured application-layer measurements during handover
WO2023027619A1