A data access method and related apparatus

Abstract

The application discloses a data access method applied to an intermediate device in a network file system (NFS) architecture. In the method, the intermediate device is arranged between a client device and a remote server, and the intermediate device is responsible for caching part of data on the remote server. In this way, when the intermediate device obtains a data access request from each client device, the intermediate device can quickly return corresponding data to the client device based on the cached data, thereby improving data access efficiency. Moreover, the data is uniformly cached based on one intermediate device, without introducing a complex delegation authorization mechanism, thereby reducing data processing overhead and network burden.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data access method and related apparatus. Background Technology

[0002] Network File System (NFS) is a network protocol for accessing remote file systems. Based on NFS, directories of a file system on a remote server can be mounted onto directories of a file system on a client device, allowing the client device to access files on the remote server as if they were local files, thus enabling file sharing across different devices.

[0003] Since remote servers typically serve multiple client devices simultaneously, they need to continuously process data processing requests from these devices, resulting in significant data processing pressure on the remote server and consequently impacting the data access efficiency of the client devices.

[0004] To improve data access efficiency on client devices, related technologies cache a portion of data from the remote server on each client device, such as frequently accessed data. When a client device needs to access data, it first searches for the required data in the cached data, and only retrieves the corresponding data from the remote server if the data is not found on the client device.

[0005] In related technologies, because multiple client devices cache copies of data from the server in their respective cache spaces, when one client device modifies a data copy in its local cache space, the data copies stored in the cache spaces of other client devices also need to be modified accordingly. To ensure data consistency on client devices, the server manages file data on client devices through a series of complex cache management processes, including authorization, delegation, and eviction. Because these technologies introduce complex delegation and authorization mechanisms, file authorization and the eviction of file permissions require additional interactions, increasing data processing overhead and network burden. Summary of the Invention

[0006] This application provides a data access method that establishes an intermediate device between a client device and a remote server, with the intermediate device responsible for caching a portion of the data on the remote server. This allows the intermediate device to quickly return the corresponding data to the client devices based on the cached data when it receives data access requests from various client devices, improving data access efficiency. Furthermore, by using a single intermediate device to uniformly cache data, it is no longer necessary to reserve storage resources on each client device for caching, thus eliminating the need for complex delegation and authorization mechanisms and reducing data processing overhead and network burden.

[0007] The first aspect of this application provides a data access method applied to an intermediate device in an NFS architecture, the NFS architecture including a plurality of first electronic devices, the intermediate device, and a second electronic device.

[0008] The data access method specifically includes: an intermediate device receiving a first request message from a target electronic device, the first request message being used to request access to first data on a second electronic device, the target electronic device being any one of the plurality of first electronic devices. Then, the intermediate device determines second data cached in the intermediate device based on the first request message, wherein the second data is identical to the first data, and the intermediate device caches partial data from the second electronic device. For example, the intermediate device may cache metadata of file data, small-sized file data, or frequently accessed file data by the first electronic device. After determining the second data corresponding to the first request message, the intermediate device sends a first response message to the target electronic device, the first response message including the second data.

[0009] In this solution, an intermediate device is set up between the first and second electronic devices to cache a portion of the data on the second electronic device. This allows the intermediate device to quickly return the corresponding data to the first electronic devices based on the cached data when it receives data access requests from various first electronic devices, reducing the data processing load on the second electronic devices and improving data access efficiency. Furthermore, by using a single intermediate device to centrally cache data, it is no longer necessary to reserve storage resources on each first electronic device for data caching, thus eliminating the need for complex delegation and authorization mechanisms and reducing data processing overhead and network burden.

[0010] In one possible implementation, before the intermediate device receives the first request message sent by the target electronic device, the method further includes: the intermediate device receiving a second request message sent by the target electronic device, the second request message being used to request access to the first data on the second electronic device. When the intermediate device receives the second request message, the intermediate device has not yet cached the first data requested by the second request message.

[0011] Therefore, in response to the absence of the data requested by the second request message in the intermediate device, the intermediate device forwards the second request message to the second electronic device. Then, after the second electronic device processes the second request message, the intermediate device receives a second response message sent by the second electronic device, the second response message including the first data. Finally, the intermediate device forwards the second response message to the target electronic device.

[0012] In this solution, when the intermediate device does not cache the data requested by the target electronic device, the intermediate device is responsible for forwarding the interaction messages between the target electronic device and the second electronic device, so that the target electronic device can access the data on the second electronic device and ensure the normal operation of the data access service.

[0013] In one possible implementation, after receiving a second response message returned by a second electronic device, the intermediate device caches the data carried in the second response message to obtain the second data.

[0014] In other words, when the intermediate device obtains the data returned by the second electronic device to the target electronic device, the intermediate device can cache the obtained data in its local cache space. This ensures that when the target electronic device accesses the data again or when other electronic devices access the data, the intermediate device can quickly return the data to the target electronic device or other electronic devices without having to obtain the data from the second electronic device again.

[0015] In one possible implementation, after the intermediate device sends a first response message to the target electronic device, the method further includes: the intermediate device receiving a third request message sent by the target electronic device, the third request message being used to request access to data on the second electronic device, the third request message being a Transmission Control Protocol (TCP) message.

[0016] In response to the absence of the data requested by the third request message in the intermediate device, the intermediate device updates the sequence number (seq) and acknowledgment number (ack) in the third request message according to the first request message and the first response message to obtain the updated third request message, and forwards the updated third request message to the second electronic device.

[0017] Then, the intermediate device receives a third response message sent by the second electronic device, the third response message including the data requested by the third request message. The intermediate device updates the seq and ack in the third response message according to the first request message and the first response message to obtain an updated third response message, and sends the updated third response message to the target electronic device.

[0018] In this scheme, since the intermediate device will process part of the TCP messages from the target electronic device on behalf of the second electronic device, that is, part of the TCP connection information will be truncated on the intermediate device, the intermediate device can subsequently correct part of the content in the request and response messages between the target electronic device and the second electronic device to ensure that the TCP connection between the target electronic device and the second electronic device maintains normal interaction.

[0019] In one possible implementation, the sequence number (seq) of the updated third request message is the difference between the seq of the third request message and the length of the valid data in the first request message; the ack of the updated third request message is the difference between the ack of the third request message and the length of the valid data in the first response message; the sequence number (seq) of the updated third response message is the sum of the seq of the third response message and the length of the valid data in the first response message; and the ack of the updated third response message is the sum of the ack of the third response message and the length of the valid data in the first request message.

[0020] In one possible implementation, before the intermediate device receives the first request message sent by the target electronic device, the method further includes: the intermediate device receiving a fourth request message, the fourth request message being used to instruct the intermediate device to store third data, the third data being a portion of data on the second electronic device, the third data including the second data; the intermediate device caching the third data according to the fourth request message.

[0021] In one possible implementation, the intermediate device determines the second data cached in the intermediate device based on the first request message, including: the intermediate device parses the first request message to obtain the type of the first request message and a target field in the first request message, wherein the first request message is used to request access to the first data related to the target data, the type of the first request message is used to indicate the type of the first data, and the target field is used to indicate the identifier of the target data. The intermediate device, based on the type of the first request message and the content of the target field, looks up a mapping table to obtain the second data, the mapping table being used to record the mapping relationship between message type, data identifier, and data.

[0022] In this solution, a mapping table is established on the intermediate device. This mapping table establishes a mapping relationship between the key information in the request message used to request data access and the data itself. This enables the intermediate device to obtain the corresponding data content by querying the mapping table after parsing the request message, thereby enabling the provision of data access services on the intermediate device.

[0023] In one possible implementation, the first data associated with the target data includes one or more of the content of the target data, attribute information of the target data, and permission information of the target data.

[0024] In one possible implementation, the method further includes: the intermediate device receiving a fifth request message sent by the target electronic device, the fifth request message being used to request an update of the first data; the intermediate device updating the second data according to the fifth request message, and sending the fifth request message to the second electronic device.

[0025] In one possible implementation, the method further includes: the intermediate device receiving a sixth request message, wherein the sixth request message is for requesting access to data on the second electronic device, the type of the sixth request message is a target type, and different types of request messages are for requesting access to different types of data; in response to the intermediate device not supporting the processing of messages belonging to the target type, the intermediate device forwards the sixth request message to the second electronic device.

[0026] In this solution, when the processing capacity or caching resources of the intermediate device are limited, the intermediate device can cache only certain types of data and process only messages related to these data types, thereby replacing the second electronic device in processing certain types of messages. This approach, while taking into account the capabilities of the intermediate device, reduces the processing load on the second electronic device, improves the access efficiency of certain data types, and enhances the applicability of this solution.

[0027] In one possible implementation, the intermediate device may include one or more of a network processor (NP), a programmable chip, a field-programmable gate array (FPGA), and a data processing unit (DPU).

[0028] A second aspect of this application provides a data access device applied to an intermediate device in an NFS architecture, the NFS architecture including a plurality of first electronic devices, the intermediate device, and a second electronic device. The device includes: a receiving module for receiving a first request message sent by a target electronic device, the first request message being used to request access to first data on the second electronic device, the target electronic device being any one of the plurality of first electronic devices; a processing module for determining, based on the first request message, second data cached in the intermediate device, wherein the second data is the same as the first data, and the intermediate device caches a portion of the data on the second electronic device; and a sending module for sending a first response message to the target electronic device, the first response message including the second data.

[0029] In one possible implementation, the receiving module is further configured to receive a second request message sent by the target electronic device, the second request message being used to request access to the first data on the second electronic device; the sending module is further configured to forward the second request message to the second electronic device in response to the absence of the data requested by the second request message in the intermediate device; the receiving module is further configured to receive a second response message sent by the second electronic device, the second response message including the first data; the sending module is further configured to forward the second response message to the target electronic device.

[0030] In one possible implementation, the processing module is further configured to cache the data carried in the second response message in order to obtain the second data.

[0031] In one possible implementation, the receiving module is further configured to receive a third request message sent by the target electronic device, the third request message being for requesting access to data on the second electronic device, the third request message being a Transmission Control Protocol (TCP) message; the processing module is further configured to, in response to the absence of the data requested by the third request message in the intermediate device, update the sequence number (seq) and acknowledgment number (ack) in the third request message according to the first request message and the first response message to obtain an updated third request message, and forward the updated third request message to the second electronic device; the receiving module is further configured to receive a third response message sent by the second electronic device, the third response message including the data requested by the third request message; the processing module is further configured to, update the seq and ack in the third response message according to the first request message and the first response message to obtain an updated third response message, and send the updated third response message to the target electronic device.

[0032] In one possible implementation, the sequence number (seq) of the updated third request message is the difference between the seq of the third request message and the length of the valid data in the first request message; the ack of the updated third request message is the difference between the ack of the third request message and the length of the valid data in the first response message; the sequence number (seq) of the updated third response message is the sum of the seq of the third response message and the length of the valid data in the first response message; and the ack of the updated third response message is the sum of the ack of the third response message and the length of the valid data in the first request message.

[0033] In one possible implementation, the receiving module is further configured to receive a fourth request message, the fourth request message being used to instruct the intermediate device to store third data, the third data being a portion of the data on the second electronic device, the third data including the second data; the processing module is further configured to cache the third data according to the fourth request message.

[0034] In one possible implementation, the processing module is further configured to parse the first request message to obtain the type of the first request message and the target field in the first request message, wherein the first request message is used to request access to the first data related to the target data, the type of the first request message is used to indicate the type of the first data, and the target field is used to indicate the identifier of the target data; the processing module is further configured to look up a mapping table according to the type of the first request message and the content of the target field to obtain the second data, wherein the mapping table is used to record the mapping relationship between message type and data identifier and data.

[0035] In one possible implementation, the first data associated with the target data includes one or more of the content of the target data, attribute information of the target data, and permission information of the target data.

[0036] In one possible implementation, the receiving module is further configured to receive a fifth request message sent by the target electronic device, the fifth request message being used to request an update of the first data; the processing module is further configured to update the second data according to the fifth request message, and send the fifth request message to the second electronic device.

[0037] In one possible implementation, the receiving module is further configured to receive a sixth request message, wherein the sixth request message is used to request access to data on the second electronic device, the type of the sixth request message is a target type, and different types of request messages are used to request access to different types of data; the sending module is further configured to forward the sixth request message to the second electronic device in response to the intermediate device not supporting the processing of messages belonging to the target type.

[0038] In one possible implementation, the intermediate device may contain one or more of an NP, a programmable chip, an FPGA, and a DPU.

[0039] A third aspect of this application provides a data access apparatus, which may include a memory and a processor, the processor and the memory being coupled. The memory stores data, and the processor is used to execute the method described in the first aspect based on the data in the memory. For details regarding the steps of various possible implementations of the first aspect executed by the processor, please refer to the first aspect; further details will not be repeated here.

[0040] A fourth aspect of this application provides a chip system including a processor for supporting a data access device or network device in implementing the functions involved in the first aspect above, such as transmitting or processing data and / or information involved in the methods described above. In one possible design, the chip system further includes a memory for storing necessary program instructions and data in the network device. This chip system may be composed of chips or may include chips and other discrete devices. Attached Figure Description

[0041] Figure 1 This is a schematic diagram of an NFS architecture related to the technology.

[0042] Figure 2 This is a flowchart illustrating the cache management strategy in related technologies.

[0043] Figure 3A schematic diagram of an NFS architecture provided in an embodiment of this application;

[0044] Figure 4 A flowchart illustrating a data access method provided in an embodiment of this application;

[0045] Figure 5 A flowchart illustrating a data access method provided in an embodiment of this application;

[0046] Figure 6 A schematic diagram illustrating a TCP proxy method provided in an embodiment of this application;

[0047] Figure 7 A schematic diagram illustrating another TCP proxy method provided in an embodiment of this application;

[0048] Figure 8 A schematic diagram of a TCP message format provided in an embodiment of this application;

[0049] Figure 9 This is a schematic diagram illustrating message interaction between a target electronic device, an intermediate device, and a second electronic device, as provided in an embodiment of this application.

[0050] Figure 10 A schematic diagram of the structure of an intermediate device provided in an embodiment of this application;

[0051] Figure 11 A flowchart illustrating the data access method executed by various modules in an intermediate device according to an embodiment of this application;

[0052] Figure 12 This is a schematic diagram of the structure of a data access device provided in an embodiment of this application;

[0053] Figure 13 This is a schematic diagram of the structure of a network device provided in an embodiment of this application. Detailed Implementation

[0054] The embodiments of this application are described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. As those skilled in the art will recognize, with the development of technology and the emergence of new scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0055] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein.

[0056] Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or modules is not necessarily limited to those steps or modules explicitly listed, but may include other steps or modules not explicitly listed or inherent to those processes, methods, products, or apparatuses. The naming or numbering of steps appearing in this application does not imply that the steps in the method flow must be performed in the chronological / logical order indicated by the naming or numbering. The execution order of named or numbered process steps can be changed according to the desired technical purpose, as long as the same or similar technical effect can be achieved.

[0057] For ease of understanding, the technical terms involved in the embodiments of this application will be introduced below.

[0058] (1) Network File System (NFS)

[0059] NFS is a network file system transfer protocol. Based on NFS, directories of a file system on a remote server can be mounted onto directories of a file system on a client device, allowing the client device to access files on the remote server as if they were local files, thus enabling file sharing across different devices. NFS uses the Transmission Control Protocol (TCP) to implement the interaction between the client device and the server; that is, NFS carries file transfer interactions over TCP.

[0060] (2) TCP

[0061] TCP is a connection-oriented, reliable, byte-stream-based transport layer communication protocol.

[0062] (3) Metadata

[0063] Metadata, often referred to as relay data, is a type of data used to describe data. Specifically, metadata refers to structured data extracted from information resources to describe their characteristics and content. In this embodiment, metadata may refer to key information used to locate data requested by a client device.

[0064] (4) File handle

[0065] A file handle is used to uniquely describe the file or directory operated on by a specific file operation. A file handle typically contains three important parts: a volume identifier, an inode number, and a generation number. These three parts together constitute a unique identifier for the file or directory that the client wishes to access.

[0066] Specifically, the volume identifier indicates which file system the data access request is directed to; the inode number indicates which file within that partition the data access request is accessing. Furthermore, a generation number is necessary when an inode number is to be reused; the generation number is incremented when an inode number is to be reused, thus ensuring that the client cannot access a newly created file using an old file handle.

[0067] Please see Figure 1 , Figure 1 This is a schematic diagram of an NFS architecture for related technologies. For example... Figure 1 As shown, the NFS architecture includes a server and multiple client devices (i.e., client device 1 to client device 3). Each client device has reserved cache space to cache a portion of the data on the server. When a client device needs to access data, it chooses whether to retrieve the data from its local cache or pull it from the remote server based on a strategy. Since a single server typically serves multiple client devices, the NFS architecture in related technologies requires setting up cache spaces on multiple client devices to cache data, resulting in significant waste of storage resources on the client devices.

[0068] Furthermore, because each client device uses a cache space to cache data, data consistency issues also exist in the NFS architecture of related technologies. Simply put, multiple client devices cache copies of the data on the server in their respective cache spaces. When one client device modifies its local cache copy, the data copies stored in the cache spaces of other client devices also need to be modified accordingly.

[0069] To address the data consistency problem, relevant technologies have been proposed to address... Figure 1 The diagram illustrates the caching management strategy of the NFS architecture. Specifically, the server caches infrequently accessed or read-only file data on client devices through delegation. Then, the server manages the file data on client devices by executing a series of caching management strategies, including delegation, authorization, and eviction.

[0070] Please see Figure 2 , Figure 2 This is a flowchart illustrating the cache management strategy in related technologies. For example... Figure 2 As shown, the process of the server executing the cache management strategy includes the following steps 1-6.

[0071] Step 1: Client device 1 requests file delegation authorization from the server.

[0072] When client device 1 needs to use a file in the local cache space, client device 1 requests a delegated authorization for that file from the server.

[0073] Step 2: The server issues file authorization to client device 1.

[0074] If the server checks and finds that no delegation authorization for the file has been issued to other client devices, then the server issues delegation authorization for the file to client device 1, so that client device 1 can use the file in the local cache space.

[0075] Step 3: Client device 2 requests authorization from the server for the same file.

[0076] Since both client device 1 and client device 2 have cached the same file in their local cache space, when client device 1 uses a file in its local cache space, client device 2 may request delegation authorization for the same file from the server.

[0077] Step 4: The server reclaims file authorization from client device 1.

[0078] When the server checks and finds that it has already issued a file authorization to client device 1, the server will revoke the file authorization from client device 1.

[0079] Step 5: Client device 1 submits the modifications made during the file authorization period to the server.

[0080] When client device 1 receives a file license revocation instruction from the server, client device 1 submits to the server the modifications made to the file during the file license period in order to release the file license permissions.

[0081] Step 6: The server issues file authorization to client device 2.

[0082] The server receives the modifications submitted by client device 1, modifies the file, and obtains a new file. Then, the server issues a delegation authorization for the new file to client device 2 and sends the new file to client device 2, so that client device 2 can use the new file in its local cache space.

[0083] Depend on Figure 2 As can be seen from the interaction flow shown, the NFS caching mechanism in related technologies is relatively complex, including the following drawbacks.

[0084] 1. In order to solve the problem of cached data consistency, a complex delegation and authorization mechanism is introduced, which requires additional interaction for file authorization and file permission revocation, increasing additional data processing overhead and network burden.

[0085] 2. There are security risks. For example, if the server needs to revoke file permissions on a client device, and the client device does not respond to the server's revoke permission message, the client device's file permissions cannot be revoked, thus preventing other client devices from accessing the file.

[0086] 3. When multiple client devices request authorization simultaneously, the authorization requests from the client devices need to be arbitrated. Furthermore, when the server revokes file authorization permissions for a client device, it also needs to synchronize data with other client devices.

[0087] In view of this, to address the problem that NFS-based data access methods in related technologies lead to significant waste of storage resources on client devices and complex interaction processes, this application proposes a data access method. By using an intermediate device to uniformly cache data, it is no longer necessary to reserve storage resources on each client device for data caching, thereby saving storage resources on client devices. Furthermore, since data is no longer cached on each client device, complex delegation and authorization mechanisms are eliminated, reducing the complex interaction processes between client devices and the server.

[0088] Please refer to Figure 3 , Figure 3 This is a schematic diagram of an NFS architecture provided in an embodiment of this application. (As shown...) Figure 3 As shown in the illustration, the NFS architecture provided in this application includes multiple first electronic devices, an intermediate device, and second electronic devices. The intermediate device is deployed between the multiple first electronic devices and the second electronic devices, and each of the multiple first electronic devices is connected to the intermediate device, which is also connected to the second electronic devices. In other words, the multiple first electronic devices can communicate with the second electronic devices through the intermediate device.

[0089] exist Figure 3 In the NFS architecture shown, the intermediate device is responsible for forwarding communication messages between multiple first electronic devices and second electronic devices. Furthermore, the intermediate device caches some data from the second electronic devices, enabling it to process data access requests. When multiple first electronic devices request to access data on a second electronic device, and the intermediate device has the requested data cached, the intermediate device processes the data access requests from the multiple first electronic devices and returns the corresponding data to them, without needing to send the data access requests back to the second electronic devices.

[0090] In this embodiment, the intermediate device can be a network device added to the existing NFS architecture. Alternatively, the intermediate device can be a modified version of an existing NFS network device, that is, adding data caching and data processing functions to the original network device.

[0091] For example, the intermediate device may include one or more of a network processor (NP), a programmable chip, a field-programmable gate array (FPGA), and a data processing unit (DPU). The programmable chip may be, for example, a BAREFOOT programmable network switching chip. The intermediate device may be a network forwarding device such as a switch, gateway, or router, or it may be a server.

[0092] Multiple first electronic devices may correspond to the client devices described above. These multiple first electronic devices may include, for example, servers, smartphones, personal computers, laptops, tablets, wireless electronic devices in industrial control, wireless electronic devices in smart grids, or wireless electronic devices in smart cities.

[0093] The second electronic device can correspond to the server described above. For example, the second electronic device can be a server, a server cluster consisting of multiple servers, or a virtual machine (VM) deployed on a server.

[0094] Please refer to Figure 4 , Figure 4 This is a flowchart illustrating a data access method provided in an embodiment of this application. Wherein, Figure 4 The data access method shown can be applied to Figure 3 The intermediate device in the NFS architecture shown. For example... Figure 4 As shown, the data access method includes the following steps 401-403.

[0095] Step 401: The intermediate device receives a first request message sent by the target electronic device. The first request message is used to request access to first data on the second electronic device. The target electronic device is any one of the plurality of first electronic devices.

[0096] In this embodiment, since the intermediate device is deployed between multiple first electronic devices and second electronic devices, messages sent by a target electronic device to a second electronic device from the multiple first electronic devices will pass through the intermediate device. When a target electronic device needs to access first data on a second electronic device, the target electronic device can send a first request message with the destination address of the second electronic device. In this way, the intermediate device located between the target electronic device and the second electronic device can receive the first request message before the second electronic device.

[0097] Step 402: The intermediate device determines the second data cached in the intermediate device according to the first request message, wherein the second data is the same as the first data, and the intermediate device caches part of the data on the second electronic device.

[0098] Upon receiving the first request message, the intermediate device parses the message to determine that it requests access to first data on the second electronic device. Then, the intermediate device checks its local cache to see if it has cached data identical to the first data on the second electronic device.

[0099] If the intermediate device has cached second data that is identical to the first data, the intermediate device can determine and obtain the second data cached in its local cache space based on the first request message.

[0100] Optionally, if the second electronic device stores a large amount of file data, the intermediate device may store some of the data from the second electronic device. For example, the intermediate device may store metadata of the file data, file data that occupies a small amount of space, or file data that is frequently accessed by the first electronic device.

[0101] Optionally, the intermediate device may store a portion of the data from the second electronic device using a high-speed storage medium. For example, the intermediate device may use Random Access Memory (RAM) to store a portion of the data from the second electronic device. RAM has a fast read / write speed, and the intermediate device can perform read / write operations on RAM at any time. Therefore, using RAM as the data storage medium can ensure the efficiency of data read / write operations by the intermediate device, thereby ensuring data access efficiency.

[0102] Step 403: The intermediate device sends a first response message to the target electronic device, the first response message including the second data.

[0103] Since the intermediate device has cached the same second data as the first data requested by the target electronic device, the intermediate device can generate a first response message based on the found second data and return the first response message carrying the second data to the target electronic device, without needing to forward the first request message to the second electronic device.

[0104] In this way, the intermediate device can replace the second electronic device in handling data access requests from the target electronic device, thereby reducing the data processing pressure on the second electronic device and effectively improving data access efficiency.

[0105] Understandably, since the intermediate device caches a portion of the data on the second electronic device, it is more efficient than the second electronic device in querying matching data in the cache space based on data access requests (i.e., the first request message mentioned above), thus improving data access efficiency. Furthermore, when the second electronic device handles a large number of data access requests, the disk storing the data on it is prone to frequent full load, leading to low data processing efficiency. Using the intermediate device to handle a portion of the data access requests on behalf of the second electronic device effectively reduces the disk read pressure on the second electronic device, improving data access efficiency.

[0106] Furthermore, when the second electronic device is a server, it typically uses a central processing unit (CPU) to process data access requests by executing software programs. This includes parsing data access requests, querying the corresponding data, and generating response messages. In contrast to a CPU with limited processing power, an intermediate device can be a network device that uses specialized hardware (such as an NP, FPGA, or DPU) to process data access requests. Therefore, the efficiency of the intermediate device in processing data access requests is significantly higher than that of the second electronic device, further improving data access efficiency.

[0107] For example, an NP device typically includes multiple microcode processors and multiple hardware coprocessors. These microcode processors can run in parallel within the NP, controlling its processing flow through pre-programmed microcode. Building upon these microcode processors, the NP employs hardware coprocessors to perform complex data lookups, packet assembly, and forwarding operations, thereby providing high-performance data processing.

[0108] In this embodiment, an intermediate device is set up between the client device and the remote server, which is responsible for caching a portion of the data on the remote server. This allows the intermediate device to quickly return response data to the client based on the cached data when it receives data access requests from various client devices, improving data access efficiency. Furthermore, by using a single intermediate device to centrally cache data, it is no longer necessary to reserve storage resources on each client device, thus saving storage resources on the client devices.

[0109] Furthermore, using an intermediate device to centrally cache data avoids caching data on various client devices, thus eliminating the need for complex delegation and authorization mechanisms, reducing the complex interaction process between client devices and the server, and improving data processing efficiency.

[0110] The above describes the process by which an intermediate device, storing the corresponding data, directly returns the requested data to the target electronic device, replacing the second electronic device. Since the intermediate device only stores a portion of the data from the second electronic device, some data access requests received by the intermediate device may request data not cached on the intermediate device. In such cases, if the intermediate device cannot find matching data based on the data access request, it forwards the data access request to the second electronic device for processing.

[0111] For example, in the above Figure 4 In a corresponding embodiment, before the intermediate device receives the first request message sent by the target electronic device, the data access method further includes the following steps.

[0112] Step 1: The intermediate device receives a second request message sent by the target electronic device. The second request message is used to request access to the first data on the second electronic device.

[0113] Specifically, the intermediate device receives the second request message earlier than it receives the first request message. Furthermore, when the intermediate device receives the second request message, it has not yet cached the first data requested by the second request message.

[0114] Step two: In response to the absence of the data requested by the second request message in the intermediate device, the intermediate device forwards the second request message to the second electronic device.

[0115] Since the data requested by the second request message does not exist on the intermediate device, the intermediate device cannot process the second request message. Instead, the intermediate device forwards the second request message to the second electronic device for processing.

[0116] Optionally, the intermediate device can determine in various ways that it does not cache the data requested by the second request message.

[0117] For example, the intermediate device can check in its local cache whether the data requested in the second request message exists; if the intermediate device cannot find the data requested in the second request message in its local cache, it is determined that the intermediate device does not cache the data requested in the second request message.

[0118] For example, if an intermediate device caches certain types of data from a second electronic device, and by parsing the second request message, the intermediate device discovers that the type of data requested by the second request message is not cached by the intermediate device, then it determines that the data requested by the second request message is not cached in the intermediate device. For instance, assuming the intermediate device caches attribute data of file data on the second electronic device, if the data requested by the second request message is the file data itself, the intermediate device can determine that the data requested by the second request message is not cached in its local cache.

[0119] Step 3: The intermediate device receives a second response message sent by the second electronic device, the second response message including the first data.

[0120] After the intermediate device forwards the second request message to the second electronic device, the second electronic device processes the second request message and carries the first data requested by the target electronic device in the second response message returned to the target electronic device. The second electronic device sends the second response message to the target electronic device through the intermediate device, thus enabling the intermediate device to receive the second response message sent by the second electronic device.

[0121] Step four: The intermediate device forwards the second response message to the target electronic device.

[0122] Understandably, when the intermediate device does not cache the data requested by the target electronic device, the intermediate device is responsible for forwarding the interaction messages between the target electronic device and the second electronic device, so that the target electronic device can access the data on the second electronic device.

[0123] Optionally, after receiving the second response message from the second electronic device, the intermediate device caches the data carried in the second response message to obtain the second data. That is, when the intermediate device obtains the data returned by the second electronic device to the target electronic device, the intermediate device can cache the obtained data in its local cache space. This ensures that when the target electronic device accesses the data again or when other electronic devices access the data, the intermediate device can quickly return the data to the target electronic device or other electronic devices without needing to obtain the data from the second electronic device again.

[0124] In practical applications, intermediate devices can update the data in their cache by caching the data carried in the response messages returned by the second electronic device in real time. Since the intermediate device only sends a request message to the second electronic device when it cannot retrieve the requested data from its local cache, the response message received from the second electronic device will include data not cached in the intermediate device's local cache. In this case, the intermediate device can cache newly accessed data from the first electronic device in its local cache in real time, thus ensuring the real-time performance of the data cached in its local cache. Furthermore, when the intermediate device's local cache is full, it can prioritize deleting the least recently accessed data in its local cache, thereby maximizing the real-time performance of the data cached in its local cache.

[0125] The above describes the process by which an intermediate device retrieves data from a second electronic device by caching the data carried in the response message returned by the second electronic device. In some cases, the intermediate device may also retrieve data from the second electronic device using other methods.

[0126] For example, the second electronic device may send some of its data to the intermediate device as needed, so that the intermediate device can cache the received data in its local cache space. For instance, the second electronic device may send metadata corresponding to locally stored file data, small-sized file data, or frequently accessed file data to the intermediate device, so that the intermediate device can process some data access requests on behalf of the second electronic device based on this data.

[0127] Specifically, the intermediate device can receive a fourth request message, which instructs the intermediate device to store third data, which is a portion of the data on the second electronic device and includes the second data. The intermediate device then caches the third data according to the fourth request message. In this way, when the intermediate device receives the aforementioned first request message, it can find the second data matching the first request message and return a first response message carrying the second data to the target electronic device.

[0128] In addition, the intermediate device can also be connected to a controller that can manage the data on the second electronic device and send some of the data from the second electronic device to the intermediate device as needed.

[0129] Optionally, during the period when the intermediate device provides data access services to the target electronic device, the target electronic device may request an update to the data on the second electronic device, while the intermediate device also caches the data requested for update by the target electronic device. In this case, the intermediate device may update the cached data based on the data update request from the target electronic device and forward the data update request to the second electronic device, so that the second electronic device can also update its data synchronously.

[0130] For example, the intermediate device can receive a fifth request message sent by the target electronic device, the fifth request message being used to request the update of first data on the server. Since the intermediate device caches second data identical to the first data, it updates the second data according to the fifth request message and sends the fifth request message to the second electronic device. In this way, the intermediate device and the second electronic device can synchronously update the same data, thereby ensuring data consistency between the intermediate device and the second electronic device.

[0131] Alternatively, the intermediate device can directly forward the fifth request message requesting updated data to the second electronic device without updating the second data based on the fifth request message. Then, the second electronic device updates the first data based on the fifth request message and sends the updated first data back to the intermediate device, thereby ensuring data consistency between the intermediate device and the second electronic device.

[0132] Please refer to Figure 5 , Figure 5 This is a flowchart illustrating a data access method provided in an embodiment of this application. Figure 5 As shown, the data access method includes the following steps 501-507.

[0133] Step 501: The intermediate device receives a request message 1 from the client device, which requests access to data 1 on the server.

[0134] In this embodiment, the client device corresponds to Figure 4 The target electronic device described in the embodiment, the server corresponds to Figure 4 The second electronic device described in the embodiment. The destination address of the request message 1 received by the intermediate device is the server.

[0135] Step 502: The intermediate device forwards request message 1 to the server.

[0136] Since the intermediate device does not have the data 1 indicated in request message 1 cached, it cannot process request message 1 and therefore forwards request message 1 to the server.

[0137] Step 503: The intermediate device receives response message 1 from the server, which carries data 1.

[0138] After processing request message 1, the server returns response message 1 to the intermediate device. The destination address of response message 1 is the client device. Furthermore, response message 1 carries the data 1 requested in request message 1.

[0139] Step 504: The intermediate device caches data 1 in response message 1.

[0140] Step 505: The intermediate device forwards response message 1 to the client device.

[0141] It should be noted that this embodiment does not limit the execution order of steps 504 and 505. The intermediate device may execute step 505 first and then step 504; or the intermediate device may execute steps 504 and 505 simultaneously.

[0142] Step 506: The intermediate device receives request message 2 from the client device, which requests access to data 1 on the server.

[0143] In this embodiment, request message 1 and request message 2 may come from the same client device or from different client devices. This embodiment does not make any specific limitations on this.

[0144] Step 507: The intermediate device sends a response message 2 to the client device, which carries data 1.

[0145] Since data 1 is already cached in the intermediate device, when the intermediate device receives a request message 2 requesting access to data 1, it can locate data 1 in its local cache based on the request message 2. Then, the intermediate device generates a response message 2 based on data 1 and returns the response message 2 carrying data 1 to the client device.

[0146] The above describes the process of data caching and updating by intermediate devices. The following will describe the process of intermediate devices forwarding messages to client devices and servers.

[0147] Since NFS is carried over TCP, the request messages sent by the client device to the server and the response messages returned by the server to the client device are actually TCP messages. Furthermore, when a TCP connection is established between the client device and the server, the intermediate device processes some of the TCP messages from the client device on behalf of the server, which can cause some TCP connection information to be truncated on the intermediate device. Therefore, in this embodiment, the intermediate device can act as a TCP proxy, ensuring that the TCP connection between the client device and the server maintains normal interaction.

[0148] The following will introduce two TCP proxy methods provided in the embodiments of this application.

[0149] TCP proxy method 1: TCP termination proxy.

[0150] In this context, TCP-terminated proxy refers to an intermediate device terminating the TCP connection between the client device and the server, while simultaneously establishing separate TCP connections with both the client device and the server. In other words, the client device does not establish a direct TCP connection with the server; instead, it establishes a TCP connection with the intermediate device, which in turn establishes a TCP connection with the server.

[0151] For example, see Figure 6 , Figure 6 This is a schematic diagram illustrating a TCP proxy method provided in an embodiment of this application. For example... Figure 6 As shown, the client device establishes a TCP connection with the intermediate device, and the intermediate device establishes another TCP connection with the server.

[0152] In TCP proxy mode 1, since the intermediate device establishes separate TCP connections with both the client and server, the destination address of request messages sent by the client device is actually the intermediate device, and the destination address of response messages sent by the server is also actually the intermediate device. When the intermediate device determines that it cannot process a request message sent by the client device, it cannot directly forward the request message to the server because the destination address of the request message sent by the client device is the intermediate device. The intermediate device typically needs to generate a new request message based on the TCP connection between the intermediate device and the server, and then send the new request message to the appropriate server. Similarly, after the server returns a response message to the intermediate device, the intermediate device also needs to generate a new response message based on the TCP connection between the intermediate device and the client device, and then send the new response message to the appropriate server.

[0153] As described above, in TCP proxy mode one, the intermediate device establishes TCP connections with both the client device and the server. The intermediate device needs to parse and process request and response messages and generate new request and response messages. Therefore, a complete TCP protocol stack needs to be established on the intermediate device, placing high demands on its hardware performance. Furthermore, after establishing the TCP connection, the intermediate device needs to maintain the TCP connection. For example, connection establishment information, connection termination information, and heartbeat maintenance information all need to be uploaded to the intermediate device's processor for processing, which to some extent affects the processing performance of the intermediate device.

[0154] In certain special cases, such as when multiple client devices connect to an intermediate device, and the intermediate device also connects to multiple servers storing file data, the intermediate device also needs to perform distribution management between multiple client devices and multiple servers, thus increasing the management complexity of the intermediate device. For example, after receiving a request message from a client device, the intermediate device needs to determine which server the data requested in the current request message is located on; or, for example, after receiving a response message from a server, the intermediate device needs to determine which client device the current response message should be returned to.

[0155] TCP proxy method 2: TCP non-terminal proxy.

[0156] Please refer to Figure 7 , Figure 7 This is a schematic diagram illustrating another TCP proxy method provided in an embodiment of this application. For example... Figure 7 As shown, a TCP non-terminal proxy means that the intermediate device does not terminate the TCP connection between the client device and the server, and the client device and the server communicate based on the TCP connection between them.

[0157] In TCP proxy mode 2, the intermediate device is mainly responsible for forwarding request and response messages. It does not need to regenerate new request and response messages. Therefore, there are no additional performance requirements for the processor of the intermediate device. The intermediate device can forward request and response messages based on hardware entries, thus ensuring the performance of the intermediate device.

[0158] Furthermore, in scenarios where multiple client devices connect to an intermediate device and the intermediate device also connects to multiple servers, since the client devices and servers establish independent TCP connections, the destination address and port number in the request messages from the client devices and the response messages from the servers do not need to be converted. Therefore, the intermediate device can easily forward messages based on the destination address in the request and response messages without having to perform distribution management between multiple client devices and multiple servers.

[0159] However, since the intermediate device handles some TCP messages from the client device on behalf of the server, meaning that part of the TCP connection information is truncated on the intermediate device, the intermediate device needs to subsequently correct some of the content in the request and response messages to ensure that the TCP connection between the client device and the server maintains normal interaction.

[0160] To make it easier to understand, the mechanism of TCP messages will be briefly introduced below.

[0161] Please refer to Figure 8 , Figure 8 This is a schematic diagram illustrating the format of a TCP message provided in an embodiment of this application. For example... Figure 8 As shown, a TCP message includes several fields: source port, destination port, sequence number (seq), acknowledgment number (ack), header length, reservations, control flags, window, checksum, urgent pointer, options, padding, and valid data. Among these, intermediate devices need to modify the seq and ack fields in request and response messages. The roles of seq and ack in TCP messages will be explained below.

[0162] During the transmission of TCP messages, each TCP message has its own unique seq and ack to identify the TCP message.

[0163] The semantics of seq are related to the values ​​of control flags in the TCP message. Depending on whether the SYN flag is 1, seq expresses different meanings.

[0164] (1) When SYN=1, it indicates that the current stage is the connection establishment phase. The seq in the TCP message is the Initial Sequence Number (ISN), which is randomly generated by an algorithm.

[0165] (2) When SYN=0, it indicates that data transmission has officially begun. The seq of the first TCP message is ISN+1; the seq of subsequent TCP messages is specifically: the seq of the previous TCP message + the length of the valid data in bytes of the previous TCP message. For example, if the seq of a TCP message sent by the client device is 5, and the length of the valid data in that TCP message is 12 bytes, then when the client device sends the next TCP message, it should set the seq of the next TCP message to be sent to 5+12=17.

[0166] In a TCP message, ack indicates the sequence of bytes the receiver expects to receive. Specifically, the value of ack in a TCP message represents the sequence number (seq) of a TCP message that is ready to be received. It's important to note that the value of ack in a TCP message points to the seq of the TCP message that is ready to be received, which is the seq of the next expected TCP message.

[0167] For example, suppose a client device sends a TCP message 1 to a server. The sequence number (seq) of TCP message 1 is 1, and the length of the valid data in bytes is 1000. After receiving TCP message 1, the server replies to the client device with a response message, namely TCP message 1'. The ack in TCP message 1' is the sum of the seq received by the server from TCP message 1 and the length of the valid data in bytes; that is, the ack in TCP message 1' is 1 + 1000 = 1001. Since the client device continues to send the next TCP message (TCP message 2), the seq in TCP message 2 is also the sum of the seq in TCP message 1 and the length of the valid data in bytes. Therefore, the ack in TCP message 1' actually represents the seq of the next TCP message the server expects to receive.

[0168] In general, for any given device, the sequence number (seq) in a TCP message can represent the sum of the seq in the previous TCP message sent by the device and the length of the valid bytes. The ack in a TCP message sent by the device represents the sum of the seq and the length of the valid bytes in the most recently received TCP message; furthermore, the ack in a TCP message sent by the device can also represent the seq in the next TCP message that the device expects to receive.

[0169] As explained above regarding seq and ack, the value of seq is determined based on the TCP message sent by the previous device, while the value of ack is determined based on the TCP message received by the previous device. When the intermediate device uses the second TCP proxy method described above for TCP proxying, the TCP message exchange between the client device and the server is interrupted when the intermediate device processes request messages on behalf of the server and returns the corresponding response messages. Therefore, the intermediate device needs to modify the seq and ack values ​​in subsequent TCP messages between the client device and the server to ensure that the client device can maintain normal interaction with the server.

[0170] Based on the above Figure 4 In a corresponding embodiment, after the target electronic device sends a first request message to the second electronic device, and the intermediate device returns a first response message to the target electronic device on behalf of the second electronic device, if the target electronic device continues to send request messages to the second electronic device, then since the second electronic device did not receive the first request message previously sent by the target electronic device, the second electronic device will consider the seq and ack in the subsequent request messages to be incorrect. In other words, after the intermediate device processes the request message from the target electronic device on behalf of the second electronic device, when the intermediate device forwards subsequent request messages from the target electronic device to the second electronic device, it needs to modify the seq and ack in the request message to ensure the continuity of interaction.

[0171] For example, in Figure 4 In a corresponding embodiment, during the first interaction between the target electronic device and the second electronic device, the target electronic device sends a second request message to the second electronic device, and the second electronic device returns a second response message to the target electronic device. In subsequent interactions, the first request message sent by the target electronic device to the second electronic device is intercepted midway by an intermediate device, which then returns a first response message to the target electronic device. In other words, the second interaction between the target electronic device and the second electronic device is actually executed by the intermediate device, and the second electronic device is unaware of the interaction between the target electronic device and the intermediate device.

[0172] In this embodiment, after the intermediate device sends a first response message to the target electronic device, the intermediate device receives a third request message sent by the target electronic device. The third request message is used to request access to data on the second electronic device, and the third request message is a TCP message.

[0173] Then, in response to the absence of the data requested by the third request message in the intermediate device, the intermediate device updates the seq and ack in the third request message according to the first request message and the first response message to obtain the updated third request message, and forwards the updated third request message to the second electronic device.

[0174] Wherein, the seq of the updated third request message is the difference between the seq of the third request message and the length of the valid data in the first request message, and the ack of the updated third request message is the difference between the ack of the third request message and the length of the valid data in the first response message.

[0175] Secondly, the intermediate device receives a third response message sent by the second electronic device. This third response message includes the data requested by the third request message. The third response message is generated by the second electronic device based on the updated third request message; therefore, the seq and ack bytes in the third response message also need to be modified.

[0176] Finally, the intermediate device updates the seq and ack in the third response message according to the first request message and the first response message to obtain the updated third response message, and sends the updated third response message to the target electronic device.

[0177] Wherein, the seq of the updated third response message is the sum of the seq of the third response message and the length of the valid data in the first response message, and the ack of the updated third response message is the sum of the ack of the third response message and the length of the valid data in the first request message.

[0178] To facilitate understanding, the following will explain in detail, with specific examples, the process by which intermediate devices modify the seq and ack in request and response messages.

[0179] Please refer to Figure 9 , Figure 9 This is a schematic diagram illustrating message interaction between a target electronic device, an intermediate device, and a second electronic device, as provided in an embodiment of this application.

[0180] like Figure 9 As shown, firstly, the target electronic device sends request message 1 to the second electronic device. In this request message 1, the seq value is 100, the ack value is 500, and the byte length is 106. This request message 1 can be, for example, the one described above. Figure 4 The second request message described in the corresponding embodiment.

[0181] Since the intermediate device does not cache the data requested by request message 1, it does not process request message 1, but instead forwards it to the second electronic device.

[0182] After processing request message 1, the second electronic device returns response message 1 to the target electronic device through an intermediate device. Response message 1 has a seq value of 500, an ack value of 206, and a byte length of 112. Response message 1 can be, for example, as described above. Figure 4 The second response message described in the corresponding embodiment.

[0183] Then, the target electronic device continues to send request message 2 to the second electronic device. Request message 2 has a seq of 206, an ack of 612, and a byte length of 106. Clearly, the seq in request message 2 is the sum of the seq and byte length (100+106) of the previous message (i.e., request message 1) sent by the target electronic device; the ack in request message 2 is the sum of the seq and byte length (500+112) of the previous message (i.e., response message 1) received by the target electronic device. Request message 2 can be, for example, as described above. Figure 4 The first request message described in the corresponding embodiment.

[0184] Since the intermediate device caches the data requested by request message 2, it processes request message 2 on behalf of the second electronic device and returns response message 2 to the target electronic device. Response message 2 has a sequence number (seq) of 612, an ack of 312, and a byte length of 112. Clearly, the seq in response message 2 is the ack from the previous message (request message 2) received by the intermediate device; the ack in response message 2 is the sum of the seq and byte length (206 + 106) from the previous message (request message 2) received by the intermediate device. For example, response message 2 could be as described above. Figure 4 The first response message described in the corresponding embodiment.

[0185] After receiving response message 2, the target electronic device continues to send request message 3 to the second electronic device. Request message 3 has a seq value of 312, an ack value of 724, and a byte length of 100. Clearly, the seq and ack in request message 3 can be obtained based on response message 2. Request message 3 can, for example, be the third request message described in the above embodiments.

[0186] Since the intermediate device does not cache the data requested by request message 3, it needs to forward request message 3 to the second electronic device for processing. Furthermore, because the intermediate device processed request message 2 on behalf of the second electronic device, the message actually received by the second electronic device last time was request message 1. To maintain the TCP connection between the target electronic device and the second electronic device, the intermediate device can modify the seq and ack in request message 3 to obtain request message 3'. In request message 3', the seq is 206, the ack is 612, and the byte length is 100. Specifically, the seq in request message 3' is the difference in byte length between the seq in request message 3 and request message 2 (312-106=206); the ack in request message 3' is the difference in byte length between the ack in request message 3 and response message 2 (724-112=612). Request message 3' can, for example, be the updated third request message described in the above embodiment.

[0187] After processing request message 3', the second electronic device returns response message 3 to the intermediate device. This response message 3 has a seq value of 612, an ack value of 306, and a byte length of 50. This response message 3 can, for example, be the third response message described in the above embodiments.

[0188] After receiving response message 3, the intermediate device also modifies the seq and ack in response message 3 to obtain response message 3'. The seq in response message 3' is 724, the ack is 412, and the byte length is 50. Specifically, the seq in response message 3' is the sum of the seq in response message 3 and the byte length of response message 2 (612 + 112 = 724); the ack in response message 3' is the sum of the ack in response message 3 and the byte length of request message 2 (306 + 106 = 412). Response message 3' can, for example, be the updated third response message described in the above embodiment.

[0189] Understandably, the above describes how the intermediate device modifies the seq and ack in subsequent request messages sent to the second electronic device after processing a request message on behalf of the second electronic device, as well as the seq and ack in the response message returned by the second electronic device.

[0190] In practical applications, an intermediate device may process multiple request messages from the target electronic device on behalf of the second electronic device. In this case, the intermediate device needs to modify the seq and ack in subsequent request messages sent to the second electronic device, as well as the seq and ack in the response messages returned by the second electronic device, based on all the request messages it has processed and all the response messages it has generated.

[0191] As explained above, the seq and ack in any request or response message are actually derived by summing the byte lengths of previous request and response messages. Therefore, by simply recording the sum of the byte lengths of the request and response messages processed by the intermediate device on behalf of the second electronic device, the intermediate device can modify any request or response message.

[0192] For example, when an intermediate device receives a request message from a target electronic device and the intermediate device needs to modify the seq and ack in the request message in order to send it to a second electronic device, the intermediate device modifies the seq and ack in the request message in the following formulas 1 and 2.

[0193] Seq_New1=Seq_Origin1–C2S_Break_Len Formula 1

[0194] Ack_New1=Ack_Origin1–S2C_Break_Len Formula 2

[0195] Wherein, Seq_Origin1 represents the seq in the original request message; Seq_New1 represents the seq in the request message obtained after modification by the intermediate device; C2S_Break_Len represents the cumulative byte length of all request messages processed by the intermediate device on behalf of the second electronic device; Ack_Origin1 represents the ack in the original request message; Ack_New1 represents the ack in the request message obtained after modification by the intermediate device; and S2C_Break_Len represents the cumulative byte length of all response messages fed back by the intermediate device on behalf of the second electronic device to the target electronic device.

[0196] Similarly, when an intermediate device receives a response message from a second electronic device and the intermediate device needs to modify the seq and ack in the response message in order to send it to the target electronic device, the intermediate device modifies the seq and ack in the response message in the following formulas 3 and 4.

[0197] Seq_New2=Seq_Origin2+S2C_Break_Len Formula 3

[0198] Ack_New2 = Ack_Origin2 + C2S_Break_Len (Formula 4)

[0199] Wherein, Seq_Origin2 represents the seq in the original response message; Seq_New2 represents the seq in the response message obtained after modification by the intermediate device; C2S_Break_Len represents the cumulative byte length of all request messages processed by the intermediate device on behalf of the second electronic device; Ack_Origin2 represents the ack in the original response message; Ack_New2 represents the ack in the response message obtained after modification by the intermediate device; and S2C_Break_Len represents the cumulative byte length of all response messages fed back by the intermediate device on behalf of the second electronic device to the target electronic device.

[0200] Based on Formulas 1-4 above, as long as the intermediate device records and accumulates the byte length of all request messages it processes on behalf of the second electronic device, and records and accumulates the byte length of all response messages it sends back to the target electronic device on behalf of the second electronic device, it can modify the received request messages and response messages at any subsequent time.

[0201] For example, in practical applications, since a TCP connection between any two electronic devices can be uniquely identified by a set of five-tuples, an intermediate device can uniquely represent the TCP connection between the target electronic device and the second electronic device based on these five-tuples. These five-tuples include the source IP address, source port, destination IP address, destination port, and transport layer protocol. Alternatively, the intermediate device can also uniquely represent the TCP connection between other first and second electronic devices based on other five-tuples. Then, each time the intermediate device processes a request message from the target electronic device on behalf of the second electronic device, it updates the accumulated value of the request message byte length; and each time the intermediate device sends a response message back to the target electronic device on behalf of the second electronic device, it updates the accumulated value of the response message byte length.

[0202] For example, the intermediate device can record the cumulative value of the request message byte length and the cumulative value of the response message byte length based on Table 1 below.

[0203] Table 1

[0204]

[0205] In Table 1, each 5-tuple can include two 5-tuples: one from the request message from the target electronic device to the second electronic device, and the other from the response message from the second electronic device to the target electronic device. For example, in the 5-tuple 1.1 / port1 / 2.2 / port2 / TCP, 1.1 represents the address of the target electronic device (i.e., the source address), port1 represents the port on the target electronic device (i.e., the source port), 2.2 represents the address of the second electronic device (i.e., the destination address), and port2 represents the port on the second electronic device (i.e., the destination port).

[0206] The above describes how an intermediate device uses a TCP proxy to forward messages and process request messages on behalf of a second electronic device. When the intermediate device processes a request message from the target electronic device, it needs to look up the corresponding data in its local cache. The following section details how the intermediate device retrieves the data corresponding to the request message from its local cache.

[0207] Understandably, in an NFS architecture, the second electronic device stores a large amount of file data and related data (such as file attribute information and file permission information). The target electronic device can request access to different types of data on the second electronic device based on different types of request messages.

[0208] For example, a target electronic device can request access to the attribute information of file data on a second electronic device by sending a request message that includes the getattr field; or, for another example, a target electronic device can request access to file data on a second electronic device by sending a request message that includes the read field.

[0209] Therefore, a mapping table can be established on the intermediate device, which establishes the mapping relationship between the key information in the request message used to request data access and the data itself. In this way, after parsing the request message, the intermediate device can obtain the corresponding data content by querying the mapping table.

[0210] For example, the intermediate device determines the second data cached in the intermediate device based on the first request message, specifically including: the intermediate device parses the first request message to obtain the type of the first request message and the target field in the first request message. The first request message is used to request access to the first data related to the target data. The target field is used to indicate the identifier of the target data, which may be, for example, a filehandle. Optionally, the first data related to the target data may include one or more of the content of the target data, attribute information of the target data, and permission information of the target data. For example, the target data may be file data on a second electronic device; then, the first data related to the target data may include the content of the file data itself, the attribute information of the file data (e.g., the file data's creation time, occupied space size, and last modification time), and the file data's permission information (e.g., the file data's access permission information or modification permission information).

[0211] Furthermore, different types of request messages are used to request access to different types of data. Therefore, the intermediate device can determine the type of the first data requested by the first request message based on the type of the first request message. For example, a request message including the getattr field requests access to attribute data; another example is a request message including the read field requests access to file data.

[0212] Then, the intermediate device looks up the mapping table based on the type of the first request message and the content of the target field to obtain the second data. The mapping table is used to record the mapping relationship between message type, data identifier and data.

[0213] For example, the mapping table established by the intermediate device can be as shown in Table 2 below.

[0214] Table 2

[0215] Type + filehandle(key) Cached data (value) Getattr+filehandle1 Data 1 Getattr+filehandle2 Data 2 Read+filehandle3 Data 3 … … Getattr+filehandlen Data n

[0216] As shown in Table 2, the key information in the mapping table includes the request message type and the filehandle used to represent the file or directory, while the cached data in the mapping table records the specific data that needs to be accessed.

[0217] As described above, the target electronic device can request access to different types of data based on different types of request messages. Optionally, since the intermediate device caches some data from the second electronic device, in some cases, the intermediate device can cache only specific types of data from the second electronic device. For example, the intermediate device may only cache attribute data or permission data from the second electronic device. Thus, when the target electronic device requests access to the attribute data or permission data of a file, the intermediate device can return the corresponding data to the target electronic device on behalf of the second electronic device; while when the target electronic device requests access to other types of data, the intermediate device forwards the request message from the target electronic device to the second electronic device, meaning the intermediate device does not process the request message on behalf of the second electronic device.

[0218] For example, the intermediate device receives a sixth request message, wherein the sixth request message is used to request access to data on the second electronic device, and the type of the sixth request message is a target type, and different types of request messages are used to request access to different types of data. The target type can be a message type requesting access to attribute data, a message type requesting access permission data, or a message type requesting access to the file data itself; no specific limitation is made to the target type here.

[0219] In response to the intermediate device not supporting the processing of messages of the target type, the intermediate device forwards the sixth request message to the second electronic device. That is, the intermediate device only supports processing certain message types; for messages that the intermediate device does not support processing, it directly forwards the message to the second electronic device for processing.

[0220] In this solution, when the processing capacity or caching resources of the intermediate device are limited, the intermediate device can cache only certain types of data and process only messages related to these data types, thereby replacing the second electronic device in processing certain types of messages. This approach, while taking into account the capabilities of the intermediate device, reduces the processing load on the second electronic device, improves the access efficiency of certain data types, and enhances the applicability of this solution.

[0221] To facilitate understanding, the data access method provided in the embodiments of this application will be described in detail below with specific examples.

[0222] First, an intermediate device for executing the data access method provided in the embodiments of this application will be introduced. In the embodiments of this application, the intermediate device is used to implement the following three functions.

[0223] Function 1: Some or all of the functions of the NFS protocol stack.

[0224] In this embodiment, since the intermediate device needs to parse NFS messages and perform corresponding processing operations based on them, it must possess NFS protocol stack capabilities. NFS protocol stack capabilities refer to the ability to parse and process NFS messages, which are the messages exchanged between various devices in the NFS architecture. If the intermediate device only processes a subset of NFS message types, it can perform only partial NFS protocol stack functionality; if it processes all types of NFS messages, it needs to possess complete NFS protocol stack functionality.

[0225] Function 2: NFS access request message query caching and quick response message function.

[0226] To achieve function 2, the intermediate device needs to have a certain amount of cache storage media. Optionally, the cache storage media on the intermediate device can be deployed on the intermediate device's own storage media, or it can be external storage media, such as storage media expanded via Remote Direct Memory Access (RDMA). With cache storage media, the intermediate device needs to query the cache based on the client device's data access request. If the data is found in the cache, a quick response is made; otherwise, the request is sent to the original server for processing.

[0227] Function 3: TCP proxy function.

[0228] Since NFS is carried over TCP, a fast truncation response to NFS will inevitably cause TCP discontinuity. Therefore, intermediate devices need to act as additional proxies for TCP to ensure the continuity and integrity of TCP sequence numbers and protocols.

[0229] Please refer to Figure 10 , Figure 10 This is a schematic diagram of the structure of an intermediate device provided in an embodiment of this application. Figure 10As shown, the intermediate device includes a message parsing module, a data query module, a packet assembly module, and a TCP proxy module, and also deploys a cache mapping table. The message parsing module parses request messages from the client device and passes the parsed key information to the data query module. The data query module queries the cache mapping table based on the key information in the request message to confirm the existence of matching data. The packet assembly module generates a response message and returns it to the client device when the data query module finds matching data. The TCP proxy module modifies the request message sent by the client device and sends the modified request message to the server when the data query module does not find matching data. Furthermore, the TCP proxy module also modifies the server's response message when the server returns a response message and sends the modified response message to the client device.

[0230] Please refer to Figure 11 , Figure 11 This is a flowchart illustrating the data access method executed by various modules in an intermediate device according to an embodiment of this application. Figure 11 As shown, the process of each module in the intermediate device executing the data access method includes the following steps 1101-1108.

[0231] Step 1101: The message parsing module receives a request message from the client device.

[0232] This request message is used to request access to data on the server. For example, this request message can be the first request message, the second request message, or the third request message described above.

[0233] Step 1102: The message parsing module parses the request message and passes the key information in the parsed request message to the data query module.

[0234] In this embodiment, the message parsing module is used to parse request messages based on TCP and NFS. Through parsing by the message parsing module, the type of the request message can be determined. If the request message belongs to a message type that the intermediate device supports processing, the intermediate device executes subsequent steps 1103-1108; for message types that the intermediate device does not support processing, the intermediate device forwards the request message to the server.

[0235] The message parsing module supports parsing both TCP-related and NFS-related portions of the request message. Specifically, by parsing the NFS-related portion, the module can obtain key information indicating the requested data, such as the getattr field and filehandle.

[0236] The message parsing module parses the TCP-related parts, obtaining the 5-tuple information, seq, and ack from the request message. The 5-tuple information, seq, and ack from the request message are used to generate a TCP record table to record the accumulated byte length of the request message and the accumulated byte length of the response message. This facilitates the subsequent TCP proxy module in performing corresponding TCP proxy operations based on the TCP record table.

[0237] Step 1103: The data query module queries the cache mapping table based on the key information in the request message to determine whether there is any matching data in the cache mapping table.

[0238] The cache mapping table can be, for example, as shown in Table 2 above. The cache mapping table records the mapping relationship between key information and data. Therefore, the data query module can query the cache mapping table based on the key information in the request message. When the cache mapping table contains information that matches the key information in the request message, it can be determined that there is a match in the cache mapping table.

[0239] Step 1104: If no matching data is found in the cache mapping table, the TCP proxy module modifies the seq and ack in the request message and sends the modified request message to the server.

[0240] If no matching data is found in the cache mapping table, the data query module notifies the TCP proxy module that no matching data exists in the current cache mapping table. In this way, the TCP proxy module can modify the seq and ack in the request message according to the record table shown in Table 1 above, and send the modified request message to the server.

[0241] Step 1105: The TCP proxy module receives the response message from the server.

[0242] After receiving the modified request message, the server generates a response message based on the data requested in the modified request message and returns the response message to the TCP proxy module of the intermediate device.

[0243] Step 1106: The TCP proxy module modifies the seq and ack in the response message and sends the modified response message to the client device.

[0244] Similarly, after receiving the response message from the server, the TCP proxy module can modify the seq and ack in the response message according to the record table shown in Table 1 above, and send the modified request message to the server.

[0245] Optionally, after the intermediate device receives the response message from the server, the message parsing module in the intermediate device can parse the response message and obtain the data in the response message. In this way, the message parsing module can establish a mapping relationship between the key information in the request message and the data in the response message, and store it in the aforementioned cache mapping table, so that the intermediate device can quickly reply to the client device when the client device continues to access the data.

[0246] Step 1107: When the matched data exists in the cache mapping table, the data query module transmits the matched data to the packet assembly module and the TCP proxy module.

[0247] If the cache mapping table contains the matched data, it means that the intermediate device can handle the request message from the client device on behalf of the server. Therefore, the data query module in the intermediate device passes the matched data to the packet assembly module to generate a response message based on the matched data.

[0248] In addition, since the intermediate device processes request messages from the client device on behalf of the server, the data query module needs to pass the hit data or the number of bytes of the hit data to the TCP proxy module so that the TCP proxy module can record the number of bytes of data returned by the intermediate device on behalf of the server in the record table as shown in Table 1 above.

[0249] Step 1108: The packet assembly module generates a response message based on the hit data and sends the response message to the client device.

[0250] In this embodiment, during the process of generating a response message based on the hit data and the request message, the packet assembly module needs to make corresponding modifications to the Media Access Control Address (MAC) layer, IP layer, TCP layer, Remote Procedure Call (RPC) layer, and NFS layer in the message. The MAC and IP layers can be modified according to the traditional reverse reply message, the RPC layer is modified according to the reply message protocol requirements, and the NFS layer data is the value information retrieved from the cache mapping table. The packets are then assembled into the corresponding positions in the message according to the format requirements.

[0251] Taking a specific NFS message as an example, when the client device sends a getattr request message with filehandle X for the first time, the intermediate device records the getattr attribute and X, and forwards the getattr request message to the server.

[0252] When the intermediate device receives the getattr response message returned by the server, the intermediate device associates the data Y in the getattr response message with the getattr attribute and X and saves it to the cache mapping table.

[0253] If the intermediate device subsequently receives another getattr request message with filehandle X, it can directly retrieve the corresponding data Y from the cache mapping table and reassemble the packet to reply.

[0254] Furthermore, if the intermediate device receives a modification request message related to data Y, such as a request message to delete or change data Y, the intermediate device modifies the data Y in the cache mapping table based on the modification request message and sends the modification request message to the server to achieve synchronous update of data Y.

[0255] Please refer to Figure 12 , Figure 12 This is a schematic diagram of the structure of a data access device provided in an embodiment of this application. Figure 12 As shown in the illustration, this application provides a data access device applied to an intermediate device in an NFS architecture, which includes multiple first electronic devices, the intermediate device, and second electronic devices. The data access device includes a receiving module 1201, a processing module 1202, and a sending module 1203. The receiving module 1201 is used to receive a first request message sent by a target electronic device, the first request message requesting access to first data on the second electronic device, the target electronic device being any one of the multiple first electronic devices; the processing module 1202 is used to determine, based on the first request message, second data cached in the intermediate device, wherein the second data is the same as the first data, and the intermediate device caches some data from the second electronic device; the sending module 1203 is used to send a first response message to the target electronic device, the first response message including the second data.

[0256] In one possible implementation, the receiving module 1201 is further configured to receive a second request message sent by the target electronic device, the second request message being used to request access to the first data on the second electronic device; the sending module 1203 is further configured to forward the second request message to the second electronic device in response to the absence of the data requested by the second request message in the intermediate device; the receiving module 1201 is further configured to receive a second response message sent by the second electronic device, the second response message including the first data; the sending module 1203 is further configured to forward the second response message to the target electronic device.

[0257] In one possible implementation, the processing module 1202 is further configured to cache the data carried in the second response message in order to obtain the second data.

[0258] In one possible implementation, the receiving module 1201 is further configured to receive a third request message sent by the target electronic device, the third request message being for requesting access to data on the second electronic device, the third request message being a Transmission Control Protocol (TCP) message; the processing module 1202 is further configured to, in response to the absence of the data requested by the third request message in the intermediate device, update the sequence number (seq) and acknowledgment number (ack) in the third request message according to the first request message and the first response message to obtain an updated third request message, and forward the updated third request message to the second electronic device; the receiving module 1201 is further configured to receive a third response message sent by the second electronic device, the third response message including the data requested by the third request message; the processing module 1202 is further configured to, update the seq and ack in the third response message according to the first request message and the first response message to obtain an updated third response message, and send the updated third response message to the target electronic device.

[0259] In one possible implementation, the sequence number (seq) of the updated third request message is the difference between the seq of the third request message and the length of the valid data in the first request message; the ack of the updated third request message is the difference between the ack of the third request message and the length of the valid data in the first response message; the sequence number (seq) of the updated third response message is the sum of the seq of the third response message and the length of the valid data in the first response message; and the ack of the updated third response message is the sum of the ack of the third response message and the length of the valid data in the first request message.

[0260] In one possible implementation, the receiving module 1201 is further configured to receive a fourth request message, the fourth request message being used to instruct the intermediate device to store third data, the third data being a portion of the data on the second electronic device, the third data including the second data; the processing module 1202 is further configured to cache the third data according to the fourth request message.

[0261] In one possible implementation, the processing module 1202 is further configured to parse the first request message to obtain the type of the first request message and the target field in the first request message, wherein the first request message is used to request access to the first data related to the target data, the type of the first request message is used to indicate the type of the first data, and the target field is used to indicate the identifier of the target data; the processing module 1202 is further configured to look up a mapping table according to the type of the first request message and the content of the target field to obtain the second data, wherein the mapping table is used to record the mapping relationship between message type and data identifier and data.

[0262] In one possible implementation, the first data associated with the target data includes one or more of the content of the target data, attribute information of the target data, and permission information of the target data.

[0263] In one possible implementation, the receiving module 1201 is further configured to receive a fifth request message sent by the target electronic device, the fifth request message being used to request an update of the first data; the processing module 1202 is further configured to update the second data according to the fifth request message and send the fifth request message to the second electronic device.

[0264] In one possible implementation, the receiving module 1201 is further configured to receive a sixth request message, wherein the sixth request message is used to request access to data on the second electronic device, the type of the sixth request message is a target type, and different types of request messages are used to request access to different types of data; the sending module 1203 is further configured to forward the sixth request message to the second electronic device in response to the intermediate device not supporting the processing of messages belonging to the target type.

[0265] In one possible implementation, the intermediate device may contain one or more of an NP, a programmable chip, an FPGA, and a DPU.

[0266] The following describes a network device provided in an embodiment of this application. Please refer to [link to relevant documentation]. Figure 13 , Figure 13 This is a schematic diagram of a network device provided in an embodiment of this application. Figure 13 The network device 1300 shown can specifically be a server, switch, gateway, or router, etc., and is not limited here. The network device 1300 can be equipped with... Figure 12 The data access device described in the corresponding embodiment is used to implement Figure 4The corresponding embodiment describes the data access function. Specifically, the network device 1300 includes a central processing unit 1301, a network processor 1302, and a high-speed storage medium 1303. The network processor 1302 may be connected to the high-speed storage medium 1303 via a high-speed bus.

[0267] The central processing unit 1301 runs on the control plane and is used to perform system startup and control management in the network device 1300.

[0268] Network processor 1302 operates in the forwarding plane and is used to perform operations such as message forwarding, looking up cache mapping tables, and editing / modifying message content. For example, network processor 1302 is used to perform the above operations. Figure 4 The data access method described in the embodiments.

[0269] Specifically, upon receiving a request message from a client device, network processor 1302 determines whether network device 1300 stores the data requested by the client device by looking up a cache mapping table. If network processor 1302 determines from the cache mapping table that network device 1300 does not store the requested data, it forwards the request message to the server. If network processor 1302 determines from the cache mapping table that network device 1300 does not store the requested data, it generates a response message based on the found data and returns the response message to the client device.

[0270] Furthermore, after the network processor 1302 successfully processes the request message from the client device on behalf of the server (i.e., the network processor 1302 returns the data obtained from looking up the cache mapping table to the client device), when the network processor 1302 forwards the message to the server or client device, it needs to edit and modify the forwarded message content (i.e., the seq and ack in the message) to ensure the continuity of messages exchanged between the server and the client device.

[0271] The high-speed storage medium 1303 is used to store a portion of the data on the server; specifically, it stores data requested for access by the client device. For example, the high-speed storage medium 1303 may store the cache mapping table (i.e., Table 2) described in the above embodiments. The network processor 1302 determines the data that needs to be returned to the client device by looking up the cache mapping table on the high-speed storage medium 1303. The high-speed storage medium 1303 may, for example, be RAM.

[0272] This application embodiment also provides an NFS system, including: multiple first electronic devices, an intermediate device, and a second electronic device, wherein the intermediate device is deployed with such... Figure 12The data access device is described above. The intermediate device may, for example, be... Figure 13 The aforementioned network device.

[0273] This application also provides a computer program product that, when run on a computer, causes the computer to perform the steps performed by the aforementioned network device.

[0274] This application also provides a computer-readable storage medium storing a program for data processing, which, when run on a computer, causes the computer to perform the steps performed by the aforementioned network device.

[0275] The network device provided in this application embodiment may specifically include a chip, which includes a processing unit and a communication unit. The processing unit may be, for example, a processor, and the communication unit may be, for example, an input / output interface, pins, or circuits. The processing unit can execute computer execution instructions stored in a storage unit to cause the chip within the network device to execute the data access method described in the above embodiments. Optionally, the storage unit is a storage unit within the chip, such as a register or cache.

[0276] It should also be noted that 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; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0277] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally speaking, any function performed by a computer program can be easily implemented by the corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits.

[0278] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

Claims

1. A data access method, characterized in that, The method is applied to an intermediate device in a Network File System (NFS) architecture, wherein the NFS architecture includes multiple first electronic devices, the intermediate device, and second electronic devices, and the method includes: The intermediate device receives a first request message sent by the target electronic device, the first request message being used to request access to first data on the second electronic device, the target electronic device being any one of the plurality of first electronic devices; The intermediate device determines the second data cached in the intermediate device according to the first request message, wherein the second data is the same as the first data, and the intermediate device caches some data from the second electronic device. The intermediate device sends a first response message to the target electronic device, the first response message including the second data; The intermediate device receives a third request message sent by the target electronic device. The third request message is used to request access to data on the second electronic device. The third request message is a Transmission Control Protocol (TCP) message. In response to the absence of the data requested by the third request message in the intermediate device, the intermediate device updates the sequence number (seq) and acknowledgment number (ack) in the third request message according to the first request message and the first response message to obtain an updated third request message, and forwards the updated third request message to the second electronic device. The seq of the updated third request message is the difference between the seq of the third request message and the length of the valid data in the first request message, and the ack of the updated third request message is the difference between the ack of the third request message and the length of the valid data in the first response message.

2. The method according to claim 1, characterized in that, Before the intermediate device receives the first request message sent by the target electronic device, the method further includes: The intermediate device receives a second request message sent by the target electronic device, the second request message being used to request access to the first data on the second electronic device; In response that the data requested by the second request message is not present in the intermediate device, the intermediate device forwards the second request message to the second electronic device; The intermediate device receives a second response message sent by the second electronic device, the second response message including the first data; The intermediate device forwards the second response message to the target electronic device.

3. The method according to claim 2, characterized in that, The method further includes: The intermediate device caches the data carried in the second response message to obtain the second data.

4. The method according to any one of claims 1-3, characterized in that, After the intermediate device forwards the updated third request message to the second electronic device, the method further includes: The intermediate device receives a third response message sent by the second electronic device, the third response message including the data requested to be accessed by the third request message; The intermediate device updates the seq and ack in the third response message according to the first request message and the first response message to obtain the updated third response message, and sends the updated third response message to the target electronic device.

5. The method according to claim 4, characterized in that, The sequence number (seq) of the updated third response message is the sum of the sequence number of the third response message and the length of the valid data in the first response message, and the ack of the updated third response message is the sum of the ack of the third response message and the length of the valid data in the first request message.

6. The method according to claim 1 or 2, characterized in that, Before the intermediate device receives the first request message sent by the target electronic device, the method further includes: The intermediate device receives a fourth request message, which instructs the intermediate device to store third data, which is a portion of the data on the second electronic device and includes the second data. The intermediate device caches the third data according to the fourth request message.

7. The method according to any one of claims 1-3, characterized in that, The intermediate device determines the second data cached in the intermediate device according to the first request message, including: The intermediate device parses the first request message to obtain the type of the first request message and the target field in the first request message, wherein the first request message is used to request access to the first data related to the target data, the type of the first request message is used to indicate the type of the first data, and the target field is used to indicate the identifier of the target data; The intermediate device searches a mapping table based on the type of the first request message and the content of the target field to obtain the second data. The mapping table is used to record the mapping relationship between message type, data identifier and data.

8. The method according to claim 7, characterized in that, The first data associated with the target data includes one or more of the following: the content of the target data, the attribute information of the target data, and the permission information of the target data.

9. The method according to any one of claims 1-3, characterized in that, The method further includes: The intermediate device receives a fifth request message sent by the target electronic device, the fifth request message being used to request an update to the first data; The intermediate device updates the second data according to the fifth request message and sends the fifth request message to the second electronic device.

10. The method according to any one of claims 1-3, characterized in that, The method further includes: The intermediate device receives a sixth request message, wherein the sixth request message is used to request access to data on the second electronic device, the type of the sixth request message is target type, and different types of request messages are used to request access to different types of data; In response to the fact that the intermediate device does not support processing messages of the target type, the intermediate device forwards the sixth request message to the second electronic device.

11. The method according to any one of claims 1-3, characterized in that, The intermediate device deploys one or more of the following: a network processor (NP), a programmable chip, a field-programmable gate array (FPGA), and a data processor (DPU).

12. A data access device, characterized in that, The device is used as an intermediate device in an NFS architecture, which includes multiple first electronic devices, the intermediate device, and second electronic devices. The device includes: A receiving module is configured to receive a first request message sent by a target electronic device, the first request message being used to request access to first data on a second electronic device, wherein the target electronic device is any one of the plurality of first electronic devices; The processing module is configured to determine, based on the first request message, second data cached in the intermediate device, wherein the second data is the same as the first data, and the intermediate device caches some data from the second electronic device; The sending module is configured to send a first response message to the target electronic device, wherein the first response message includes the second data; The receiving module is further configured to receive a third request message sent by the target electronic device, the third request message being used to request access to data on the second electronic device, and the third request message being a Transmission Control Protocol (TCP) message; The processing module is further configured to, in response to the absence of the data requested by the third request message in the intermediate device, update the sequence number (seq) and acknowledgment number (ack) in the third request message according to the first request message and the first response message to obtain an updated third request message, and forward the updated third request message to the second electronic device, wherein the seq of the updated third request message is the difference between the seq of the third request message and the length of the valid data in the first request message, and the ack of the updated third request message is the difference between the ack of the third request message and the length of the valid data in the first response message.

13. The apparatus according to claim 12, characterized in that, The receiving module is further configured to receive a second request message sent by the target electronic device, the second request message being used to request access to the first data on the second electronic device; The sending module is further configured to forward the second request message to the second electronic device in response to the absence of the data requested by the second request message in the intermediate device; The receiving module is further configured to receive a second response message sent by the second electronic device, the second response message including the first data; The sending module is also used to forward the second response message to the target electronic device.

14. The apparatus according to claim 13, characterized in that, The processing module is also used to cache the data carried in the second response message in order to obtain the second data.

15. The apparatus according to any one of claims 12-14, characterized in that, The receiving module is further configured to receive a third response message sent by the second electronic device, the third response message including the data requested to be accessed by the third request message; The processing module is further configured to update the seq and ack in the third response message according to the first request message and the first response message, obtain the updated third response message, and send the updated third response message to the target electronic device.

16. The apparatus according to claim 15, characterized in that, The sequence number (seq) of the updated third response message is the sum of the sequence number of the third response message and the length of the valid data in the first response message, and the ack of the updated third response message is the sum of the ack of the third response message and the length of the valid data in the first request message.

17. The apparatus according to claim 12 or 13, characterized in that, The receiving module is further configured to receive a fourth request message, the fourth request message being used to instruct the intermediate device to store third data, the third data being a portion of the data on the second electronic device, the third data including the second data; The processing module is also configured to cache the third data based on the fourth request message.

18. The apparatus according to any one of claims 12-14, characterized in that, The processing module is further configured to parse the first request message to obtain the type of the first request message and the target field in the first request message, wherein the first request message is used to request access to the first data related to the target data, the type of the first request message is used to indicate the type of the first data, and the target field is used to indicate the identifier of the target data; The processing module is further configured to look up a mapping table based on the type of the first request message and the content of the target field to obtain the second data. The mapping table is used to record the mapping relationship between message type, data identifier and data.

19. The apparatus according to claim 18, characterized in that, The first data associated with the target data includes one or more of the following: the content of the target data, the attribute information of the target data, and the permission information of the target data.

20. The apparatus according to any one of claims 12-14, characterized in that, The receiving module is further configured to receive a fifth request message sent by the target electronic device, the fifth request message being used to request the update of the first data; The processing module is further configured to update the second data according to the fifth request message and send the fifth request message to the second electronic device.

21. The apparatus according to any one of claims 12-14, characterized in that, The receiving module is further configured to receive a sixth request message, wherein the sixth request message is used to request access to data on the second electronic device, the type of the sixth request message is a target type, and different types of request messages are used to request access to different types of data; The sending module is further configured to forward the sixth request message to the second electronic device in response to the intermediate device not supporting the processing of messages belonging to the target type.

22. The apparatus according to any one of claims 12-14, characterized in that, The intermediate device deploys one or more of the following: NP, programmable chip, FPGA, and DPU.

23. A data access device, characterized in that, It includes a memory and a processor; the memory stores data, and the processor is used to perform the method as described in any one of claims 1 to 11 based on the data in the memory.

24. The apparatus according to claim 23, characterized in that, The processor includes one or more of an NP, a programmable chip, an FPGA, and a DPU.

25. An NFS system, characterized in that, include: A plurality of first electronic devices, intermediate devices, and second electronic devices, wherein the intermediate devices are equipped with a data access device as described in any one of claims 12 to 22.

Images