WO2013153694A1

WO2013153694A1 - Communication device, method, and system for relaying communication between client and server

Info

Publication number: WO2013153694A1
Application number: PCT/JP2012/079310
Authority: WO
Inventors: 伊藤　大輔; 隆史磯部
Original assignee: 株式会社日立製作所
Priority date: 2012-04-09
Filing date: 2012-11-12
Publication date: 2013-10-17
Also published as: JP2013218505A

Abstract

Services cannot be equally provided to many users by means of conventional application acceleration methods based on prediction. In order to be able to equally provide services to many users, a restriction is imposed on the partial data amount of files that are pre-read at once. Moreover, the access progress state of the partial data of files that were already pre-read is monitored and the subsequent partial data are pre-read if necessary. Additionally, the TIDs of all CIFS messages are reassigned to prevent inconsistencies.

Description

Communication apparatus, system, and method for relaying communication between client and server

The present invention relates to a communication device, and more particularly to a communication device that controls transfer of file data between a client and a server.

Japanese Patent Application Laid-Open Publication No. 2003-260259 discloses a technology that realizes high-speed WAN by performing bandwidth control with TCP (Transmission Control Protocol) when performing communication between a data center (DC) and a base via a wide area network (Wide Area Network, WAN). 1 is disclosed.

Further, CIFS (Common Internet File System) is available as a protocol for file sharing in the protocol of the application layer, which is the upper layer of TCP. Patent Document 3 discloses a technique related to communication between a file server and a client according to the CIFS protocol.

Patent Document 2 operates as a proxy on a network, predicts a CIFS message from a user (referred to as “prediction” in Patent Document 2), and first sends a message to a network storage (Network Attached Storage, NAS). A technique has been disclosed in which transmission is performed and a response is received to achieve high speed.

WO11 / 033894 US Patent Publication No. 2004/0215746 JP 2004-280283A

However, there is a problem in that file sharing using a file server such as NAS is not sufficiently accelerated even if TCP communication between the DC and the base via the WAN is accelerated. In particular, CIFS (Common Internet File System), which is a major NAS protocol and a standard file sharing protocol of Windows (registered trademark), can be used only about 10% of the contract bandwidth even when combined with the method of Patent Document 1. The reason is that CIFS sends and receives a message of 60 KB at most by reciprocating one by one. For this reason, the effect of the technique of Patent Document 1 cannot be obtained, and it takes RTT (Round Trip Time) for each round trip of the message.

In the method based on the prediction of Patent Document 2, if the predicted series (rule) is long, one client occupies a WAN line for a long time. In addition, one client occupies the buffer in the speed-up device for a long time. Therefore, if a rule such as “read all data triggered by open of a certain file” is defined in order to increase the accuracy of prediction, it is not possible to provide a service to many users equally. On the other hand, the effect of speeding up is low only by “reading a part of data triggered by the open of a file”.

Therefore, in the background art, there is a problem that communication services cannot be provided equally to many clients. Further, in Patent Document 2, if a command from a user is transmitted when the prediction is wrong, a mismatch of processing identification numbers (Transaction Identifier, TID) occurs, and communication is disconnected from the NAS.

In order to solve at least one of the above problems, according to one aspect of the present invention, a communication device between a client and a server places a limit on the amount of data to be read ahead for access from the client. In addition, the progress of access from the client to the pre-read data is monitored, and additional pre-read processing is controlled according to the monitoring result.

Resources (buffers) for holding prefetched data can be used efficiently. Moreover, it is not necessary to occupy a communication band for prefetched data.

Example sequence of Example 1 System configuration of the first embodiment Example sequence of Example 1 System flowchart Device configuration of application acceleration device Processing flow of input processing unit Processing flow of the output processing unit Table managed by the output processing unit Processing flow A of prefetch processing unit Processing flow B of prefetch processing unit Processing flow C of prefetch processing unit Processing flow D of prefetch processing unit Processing flow E of the prefetch processing unit Processing flow F of prefetch processing unit Access pattern and prefetch buffer size System configuration of the second embodiment Example sequence of Example 2 Processing flow of input processing unit Processing flow of the output processing unit Processing flow B of prefetch processing unit Processing flow D of prefetch processing unit Processing flow E of the prefetch processing unit Processing flow G of prefetch processing unit The figure which shows a prefetch request management table. The figure which shows a prefetch data management table. The figure which shows an access pattern management table. Table showing access pattern status transition examples

Hereinafter, examples will be described with reference to the drawings.

FIG. 2 shows an overall configuration of the first embodiment including a client that uses a file and a file server that manages the file. In this embodiment, an efficient use form of storage resources and communication resources for file sharing will be described. It also speeds up the provision of file data to client computers.

Here, the client 101 and the file server 102 are connected via the WAN 201.

The client 101 is connected to the file server 102 via a network and uses a file managed by the file server. The client 101 is, for example, a computer, an information processing terminal, or a portable information processing terminal such as a smartphone, and is an information processing apparatus that uses a file on a server.

The file server 102 is a server or the like having a file input / output control unit 5800 and a storage 5900 for storing a plurality of files, and is an information processing apparatus that provides files via a network.

The file input / output control unit 5800 notifies the client 101 of the identifier of the corresponding file, reads the partial data of the file from the storage 5900, and sends it to the WAN in response to a request via the WAN. To do.

However, the client 101 is connected to the WAN 102 via the application acceleration device 1 (105) and the TCP acceleration device 1 (103), and the file server 102 is connected to the application acceleration device 2 (106) and the TCP acceleration device 2. Connect to the WAN 201 via (104).

The TCP speed-up

devices

103 and 104 provide the speed-up function of the fourth transport layer (L4) using the speed-up technique disclosed in Patent Document 1, for example.

The TCP acceleration device may be a WAN bandwidth control device. For example, transmission control for transmitting a pre-read request by the TCP acceleration device application acceleration device 105 to the WAN communication band is performed. For example, the WAN bandwidth control device 103 sets the bandwidth to be transmitted according to the packet discard status or retransmission occurrence status on the WAN according to the Layer 4 TCP (Transmission Control Protocol) defined in the OSI (Open Systems Interconnection) reference model. The prefetch request is transmitted in the set bandwidth. Further, the WAN bandwidth control device determines whether the set bandwidth is within a predetermined upper limit bandwidth, and if the determination result is within the bandwidth, the WAN bandwidth control device performs a compliance determination to transmit a packet such as a prefetch request. You may go. In addition, data communication is performed between the WAN bandwidth control devices according to TCP. The packet includes a file identifier, file data, a command for controlling file processing to the server, or a command for controlling file processing on the client side.

The application acceleration device is in charge of the 5th to 7th layers specified by OSI. For example, the control for speeding up the CIFS (Common Internet File System) which is the 7th layer application layer (L7) application I do. The application layer is also the fourth layer among the four layers in the TCP / IP reference model. The application layer in the TCP / IP reference model corresponds to the application layer, presentation layer, and session layer of the OSI reference model.

For example, the application acceleration device 105 is a communication device that, when receiving an acquisition request for accessing a file from the client 101, executes prefetching of partial data of the file to the file server via the WAN. The application acceleration device 105 includes a prefetch buffer, holds the partial data of the file obtained by prefetching via the WAN, and holds the partial data of the prefetched file that is held in response to a subsequent request from the client. Return from prefetch buffer. Further, the application acceleration apparatus 105 determines the prefetching amount and the prefetching position according to the access status of the file from the client 101, for example, the read request of the file from the client or the transmission status of the prefetched data to the client, The file server 102 is further prefetched with the partial data of the file, and the prefetched partial data of the file is held in the prefetch buffer.

The application acceleration apparatus 105 may be provided on either the file server 102 side or the client side (described later in the second embodiment) instead of both the client side and the server side. In this case, on the file server 102 side, the application acceleration device 105 is provided between the WAN 201 and the file server 102.

Note that the application acceleration device 105 and the TCP acceleration device 103 may be a single communication system instead of separate devices. For example, the communication system includes a processing unit, a LAN transmission / reception unit, and a WAN transmission / reception unit corresponding to the application acceleration device 105 and the TCP acceleration device 103, which are connected by a signal line such as BUS or an internal switch. The When the LAN transmission / reception unit receives a request or transmits data via the client and the network, the LAN transmission / reception unit sends a prefetch request to the file server 102 to the WAN. Alternatively, the WAN transmission / reception unit receives, from the WAN, a file identifier, file partial data, and a command for controlling processing related to the file on the client side. That is, the communication system is connected to a plurality of clients 101 via a local network (LAN), is connected to a file server 102 via a wide area network (WAN), and relays data communication between the client 101 and the file server 102. Control the data communication bandwidth. Further, the communication system holds the partial data of the prefetched file acquired from the file server in the buffer, performs read control from the buffer according to the read request from the client, and acquires the partial data of the file by the further prefetch request. The communication system may be a LAN gateway device.

According to FIG. 2, the application speed-up device 105 realizes speeding up of the response to the request from the client based on Layer 5-7, and the TCP speed-up device 103 speeds up the WAN bandwidth in Layer 4.

The above is the configuration example of the application acceleration device.

FIG. 1 is an example of a sequence according to the first embodiment. In FIG. 1, the application acceleration apparatuses 1 (105) and 2 (106) are provided on the client 101 side and the file server 102 side. In addition, in order to speed up the communication of the application speed-up device, TCP speed-up devices that control the WAN communication band are provided at a plurality of WAN sites.

First, an open command 111 with TID = 1 from the client 101 reaches the file server 102 via each

device

105, 103, 104, 106. Here, TID is an abbreviation of process identification number (Transaction IDentifier), and it is assumed that a request can be uniquely identified by TID within the same session. However, a session is a series of messages exchanged by a certain client 101 from when a certain user logs in to when the user logs out, and the session ID can easily be identified from which session the command belongs to. Here, the same TID is attached to a response command for a certain request command, and the request and the response can be easily identified from the format. Further, particularly in some file servers that implement CIFS, the TID is not only uniquely identifiable, but is also required to be a serial number that specifies the relationship between the preceding and succeeding requests or responses, and their combinations. Therefore, in order to prevent TID mismatch between the client 101 side and the file server 102 side, the application acceleration apparatuses 1 (105) and 2 (106) reassign TIDs and manage them individually. Specific examples of individual management will be described later.

Also, here, the open command is a command for making the file specified by the argument available. In the case of the open command 111, “/foo/bar.txt” specified by an argument is a usable target. In particular, in CIFS, the “SMB2_CREATE” command is an open command. In some file sharing protocols, an exclusive control request is also made in the argument of the open command. In the case of the open command 111, the exclusive control right is requested with “x (exclusive)” specified by the argument. In particular, in CIFS, a request for exclusive control is performed with an argument “RequestedOplockLevel”.

The file server 102 returns a response 112 to the open command 111. The response of the open command includes a file identifier (File Identifier, FID) specified by an argument of the open command. Thereafter, when a file read command (read command) or write command (write command) specified by an open command argument is issued to the file server 102, the file name “/foo/bar.txt” is not an A but a FID. Is an argument. Also, in some file sharing protocols, an exclusive control right acquisition result is also returned.

Note that the response 112 may include an acquisition result of the exclusive control right of the file stored in the file server. For example, in CIFS, which is one of the file sharing protocols, an exclusive control right acquisition result is returned in an argument “OplockLevel”. The obtained results are “SMB2_OPLOCK_LEVEL_NONE”, “SMB2_OPLOCK_LEVEL_II”, “SMB2_OPLOCK_LEVEL_EXCLUSIVE”, “SMB2_OPLOCK_LEVEL_BATCH”, “SMB2_OPLOCK_LEVEL_NOL”, and “SMB2_OPLOCK_LEVEL_LEV”. The response 112 of the open command first passes to the application acceleration device 2 (106) (113). At this time, the application acceleration device 2 (106) checks the acquisition result of the exclusive control right included in the response 112 of the open command. If the exclusive control right is obtained, communication with the file server 102 such as FID and other authentication information is performed. The necessary information is also read. Thereafter, the open command response 112 reaches the client 101 via the

devices

104, 103, and 105.

On the other hand, the application acceleration device 2 (106) prefetches the partial data of the file using the FID acquired in the response (113). Specifically, the application acceleration device 2 (106) transmits 121 a read command to the file server (102). The read command takes three arguments: FID, reading offset, and reading length. The read command transmitted in the sequence 121 has an FID of A (that is, “/foo/bar.txt”), a reading offset of 0 (that is, reading from the beginning of the file), and a reading length of 1000.

Next, the application acceleration device 2 (106) receives the response (122) of the read command transmitted from the file server 102 in the sequence 121. The response 122 received here includes a partial data entity of the file “/foo/bar.txt”.

Subsequently, the application acceleration device 2 (106) pairs the two so that the relationship between the transmitted command 121 and the received response 122 can be understood, and the application acceleration device 1 (105) via the TCP acceleration devices 104 and 103. ) (123).

Upon receiving this, the application acceleration device 1 (105) divides the application acceleration device 2 (106) into the transmitted command 121 and the received response 122, and the partial data of FID = A offset = 0 to 1000. Store it in a buffer so that you can understand. Thereafter, similarly, the application acceleration device 2 (106) performs prefetch (125) until the prefetch buffer size is reached, and passes the result 126 to the application acceleration device 1 (105). In the example of FIG. 1, the prefetch buffer size is 4000. Details of the prefetch buffer size will be described later.

Apart from prefetching, the client 101 also reads the file whose FID is A after receiving the response 112 to the open command 111. Here, first, a read command (131) having a reading offset of 0 and a reading length of 500 is transmitted to the file server 102. When the application acceleration device 1 (105) on the path to the file server 102 receives the read command (131), it returns the processing result for the command from the prefetch buffer of the file server 102 itself. Subsequently, even if a read command (132) with a read offset of 500 and a read length of 500 is transmitted, the application acceleration device 1 (105) returns the result from the prefetch buffer.

Subsequently, even if a read command with a read offset of 1000 and a read length of 1000 is sent 133, the application acceleration device 1 (105) returns the result from the prefetch buffer, but at this time, half of the prefetch buffer (2000) partial data Has been read, the threshold for prefetch buffer management of the application acceleration device 1 is reached (134). Therefore, the application acceleration apparatus 1 (105) makes an addition prefetch request (135) to the application acceleration apparatus 2 (106), and prefetches partial data of a file having a prefetch buffer size (136). Although the threshold value is 50% (half) here, the threshold value is an arbitrary value defined by the user or system. By the way, the TID on the client 101 side at this point is 4 (133), while the TID on the file server (102) side is 6 (136). This is because the application acceleration apparatuses 1 (105) and 2 (106) reassign TIDs and manage them individually as described above.

In response to the response to the open command (111), the application acceleration device 2 (106) on the file server side 102 divides the read-ahead of partial data of a predetermined amount of the file A among the files A multiple times. The partial data of the file obtained over a plurality of times is transferred to the application acceleration apparatus 1 (105). The application acceleration device holds the partial data of the transferred file in a buffer, and returns the partial data of the file to the read command (131) of the client 101. If the read (131, 132, 133) from the client exceeds the threshold for the partial data of the file held in the buffer, the application acceleration device 1 (105) on the client 101 side further processes the file server. The application acceleration device 2 (106) on the (102) side makes an additional prefetch request (135) to the file server (102).

As described above, according to the present invention, prefetching of partial data of a certain file is performed little by little in accordance with the reading of the end user, so that prefetching for a specific client does not occupy a line. In addition, by prefetching partial data of a certain file little by little in accordance with the partial data acquisition request of the client, it is possible to avoid the case where the client stops acquiring partial data or prefetching extra partial data. By prefetching partial data of a certain file little by little using the bandwidth of the communication line according to the partial data acquisition request of the client, the bandwidth for prefetching the extra partial data is used for other communications. It can be used effectively.

The operation when the application acceleration device 105 receives a read command for the partial data of the file corresponding to an address different from the partial data of the file held in the buffer in FIG. explain. Here, the processing is the same as 112 and 113 in FIG. 1 until the client 101 transmits the open command 301 and the application acceleration apparatus 2 (106) performs prefetching accordingly.

However, here, the read command 303 of TID = 4 on the client 101 side requests partial data of the file in the area that has not been prefetched. Here, although the request of the client 101 is a request for partial data of the files from 6000 to 6499, the application acceleration apparatus 1 (105) only prefetches the partial data of the files from 0 to 3999. . Accordingly, the application acceleration apparatus 1 (105) determines that the prefetch has come off 311 and issues an additional prefetch request 312 from the offset 6000 to the application acceleration apparatus 2 (106). Thereafter, the application acceleration device 2 (106) performs prefetching for the prefetch buffer size. As shown in FIG. 3, even if random access is performed, it is not necessary to prefetch the partial data of the extra file. By using the bandwidth of the communication line little by little to prefetch a file according to the client's partial data acquisition request, the bandwidth for prefetching the partial data of the extra file is valid for other communications. Can be used.

Subsequently, the flow of processing of the first embodiment described with reference to FIGS. 1 and 3 performed by the

application acceleration apparatuses

105 and 106 will be described with reference to FIG. The processing starts from the open command reception 401 of the application acceleration apparatus 1 (105), and thereafter, the open command is transferred to the file server 102 via each of the apparatus

TCP acceleration apparatuses

103 and 104 and the application acceleration apparatus 106. When the response application acceleration device 105 from the file server 102 receives a file identifier (FID) response via the application device 106, it is returned to the client 101 (402).

Subsequently, after receiving the FID, the application acceleration device 2 (106) transmits a read command for the prefetch buffer size (122 in FIG. 1) to the file server 102 and transfers the result to the application acceleration device 1 (105). (403) (124 in FIG. 1).

Next, the application acceleration device 1 (105) waits for a command from the client (101). It is determined whether or not the received command is a close command 404, and if it is not close, it is subsequently determined 405 whether or not it is a read command. If it is not a read command, the application acceleration devices 1 (105) and 2 (106) replace the TID included in the read command from the client (101), transfer it to the file server 102, and return the result to the client. Return to step 406 and step 404.

On the other hand, if the command is a read command in step 405, the application acceleration apparatus 1 (105) determines whether the partial data of the read target file is being read into the prefetch buffer or has been read 407, that is, not (that is, In the case of not being held), an additional prefetch request is made from the application acceleration device 1 (105) to the application acceleration device 2 (106), and prefetch buffer prefetching (408) is performed (additional prefetch request ( 135)).

Thereafter, the application acceleration device 1 (105) replaces the TID and returns the partial data of the file in the prefetch buffer to the client 101 (409). Thereafter, it is determined whether or not there has been an access exceeding the threshold value n% for the data in the prefetch buffer (410). If it is determined that the threshold value has been exceeded, an additional prefetch (311) for the prefetch buffer is performed, and the procedure returns to step 404. The additional prefetch request corresponds to 135 in FIG.

On the other hand, if it is determined in step 404 that the received command is a close command, the application acceleration device 1 (105) releases the prefetch buffer (412), and the open command reception 401 and subsequent files are processed for the same FID. It is then determined whether there is no write command (413). Here, the write command is a command for making some change to the file.

Especially in the case of the CIFS protocol, SMB2_WRITE and SMB2_SETINFO are write commands. If there is no write command, the application acceleration device 1 (105) creates a close response and returns it to the client 101 (414), and then replaces the TID via each

device

103, 104, and 106 and sends the close command to the file server. The process is transferred to 102 (415), and the process is finished 417. By determining that there is no write command, it can be determined that there is no risk of the close command failing, and the close process can be completed.

In step 413, if the application acceleration device 1 (105) determines that there is a write command, the TID is changed via each

device

103, 104, and 106, and the close command is transferred to the file server 102, and the file The result transmitted from the server 102 is returned to the client 101 with the TID changed again, and the process ends. Subsequently, the configuration and operation of the application acceleration devices 1 (105) and 2 (106) that enable the operation described in FIGS. 1 and 3 will be described with reference to FIG.

The same application acceleration device 501 as the application acceleration devices 1 (105) and 2 (106) has a LAN side NIF 502, a WAN side NIF 503, an input processing unit 504, an output processing unit 505, and a prefetch processing unit 506.

The LAN-side NIF 502 is a connection port between the application acceleration apparatus 501 and a LAN (Local Area Network), and is connected to the client 101 in the application acceleration apparatus 1 (105). Further, the LAN side NIF 502 of the application acceleration apparatus 2 (106) is connected to the file server 102.

The LAN side NIF 502 includes a LAN side input buffer 521 that temporarily stores input from the LAN and a LAN side output buffer 522 that temporarily stores output to the LAN.

The WAN-side NIF 503 is a connection port between the application acceleration device 501 and the WAN. The application acceleration device 1 (105) is connected to the TCP acceleration device 1 (103), and the application acceleration device 2 (106) is connected to the TCP high speed. Connected to the control device 2 (104). The WAN-side NIF 503 has a WAN-side input buffer 531 that temporarily accumulates inputs from the WAN and a WAN-side output buffer 532 that temporarily accumulates outputs to the WAN.

The input processing unit 504 monitors the input buffers 521 and 531 of the LAN side NIF 502 and the WAN side NIF 503, receives the message, and performs processing. Details of the processing of the input processing unit 504 will be described later.

The output processing unit 505 includes a latest TID management table 801 and a pre-update TID management table 802. The latest TID management table 801 has a session ID column 811 and a TID column 812 for managing the latest TID for each session ID. . The pre-update TID management table 802 has a session ID column 821, a pre-change TID column 822, and a post-change TID column 823 in order to manage the association between the pre-change TID and the post-change TID for each session ID.

The output processing unit 505 receives the output request from the input processing unit 504 and the prefetch processing unit 506, and transfers the output request to the output buffers 522 and 532 of the LAN side NIF 502 or the WAN side NIF 503. The output processing unit 505 has a LAN-side NIF buffer 551 and a WAN-side NIF buffer 552, transfers a message that has entered the LAN-side NIF buffer 551 to the output buffer 522 of the LAN-side NIF 502, and also transfers to the WAN-side NIF buffer 552. The entered message is transferred to the output buffer 532 of the WAN side NIF 503. Details of the processing of the output processing unit 505 will be described later. The prefetch processing unit 506 includes a prefetch buffer 550, a prefetch request management table 560, a prefetch data management table 570, and an access pattern management table 580.

The prefetch buffer 550 stores partial data of a plurality of files acquired from the file server for each user and each file. The prefetch request management table 560 manages to which part of the file the partial data of the file stored in the prefetch buffer corresponds, and where the partial data of the file is stored in the buffer. The prefetch request management table 570 is a table showing correspondence between prefetch data, files, and storage positions in the prefetch buffer. This table may be further associated with the client 101 that issues access.

The prefetch data management table 570 manages past read requests in order to determine whether they are sequential or random. The prefetch data management table 570 is a table showing the correspondence between the start offset, the end offset, and the start offset of the file stored in the prefetch buffer for each file.

The access pattern management table 580 is a table for managing state transitions of access patterns for files from clients.
The prefetch processing unit 506 controls at least one of the above-described tables according to the access status of the prefetch data from the client and the access pattern of the client.

The prefetch processing unit 506 acquires a file identifier from the file server in accordance with the file open request from the client 101.

The prefetch processing unit 506 notifies the client 101 of a file identifier (FID). The prefetch processing unit 506 receives an acquisition request for a file addressed to the file server transmitted from the client 101 in response to receipt of the file identifier. In addition, after receiving a file open request, the prefetch processing unit 506 starts to sequentially acquire partial data in a predetermined range of the file from the file server.

For example, the prefetch processing unit 506 uses the prefetch request management table 560 and the prefetch data management table 570 to monitor the situation in which the partial data of the file is read from the prefetch buffer 550 from the client, and further, the file server 102 or the WAN Whether to issue a file acquisition request (prefetch) to the application acceleration device 106 on the side via the WAN side NIF is determined. The threshold used at that time is also held in a memory (not shown) of the prefetch processing unit 506. More specifically, a limit is imposed on the amount of data to be prefetched for one file stored in the server, and a predetermined amount of the file is prefetched to the server. The access status from the user to the pre-read partial data is monitored, and when the read request is made by the user for a predetermined amount of the pre-read partial data, a further predetermined amount of pre-read is performed on the server.

Then, when the prefetch processing unit 506 receives the prefetched partial data, the prefetch processing unit 506 sends the corresponding data to the client via the LAN side NIF in response to the partial data acquisition request from the client 101. After sending the corresponding data, the prefetch buffer 550 may be erasable or overwritten. For retransmission to the client 101, the output buffer 522 of the LAN-side NIF 502 may hold it.

Also, the prefetch processing unit 506 receives a prefetch message from the data processed by the input processing unit 504 and transfers the processing result to the output processing unit 505. Details of the processing of the prefetch processing unit 506 will be described later.

Next, details of the processing of the input processing unit 504 will be described with reference to FIG. After the processing start 601, the input processing unit 504 repeatedly executes a series of procedures from determination 602 to determination 607, and performs each processing when hitting each determination. Note that it is the high-speed apparatus 1 (105) on the client 101 side that hits the

procedures

602, 603, and 604, and the high-speed apparatus 2 (106 on the file server 102 side that hits the

procedures

605, 606, and 607. ). Therefore, the acceleration apparatus 1 (105) on the client 101 side may skip

steps

605, 606, and 607 other than

steps

602, 603, and 604. Further, the speed-up device 2 (106) on the file server 102 side may skip the

procedures

602, 603, and 604 other than the

procedures

605, 606, and 607. If the input processing unit 504 determines that the request has entered the input buffer 521 of the LAN-side NIF 502 602, the input processing unit 504 determines whether the request is a close command (621), and if it is a close command, the prefetch processing unit 506 performs the prefetch processing D The process is pulled to (FIG. 12) (622). The prefetch process D is a process corresponding to the procedures 413 to 415 in FIG. The procedure 621 corresponds to the procedure 404 in FIG.
On the other hand, if it is not a close command, the input processing unit 504 determines whether it is a read command (623). If it is a read command, the processing is transferred to prefetch processing B (FIG. 10) of the prefetch processing unit 506 (624). The prefetch process B is a process corresponding to steps 407 to 411, and performs a process of determining whether or not an additional prefetch request should be made. The prefetch process B determines whether the access is random access or sequential access according to the content of the read command, and changes the prefetch destination and the prefetch amount.

On the other hand, if it is not a read command, the input processing unit 504 transfers the message to the WAN side NIF buffer of the output processing unit (625). (Corresponding to a part of the procedure 406 in FIG. 4) When it is determined that a response is received in the WAN side NIF buffer (603), the message is transferred to the LAN side NIF buffer 551 of the output processing unit 505 (631).

If it is determined that a management command response has been received in the WAN-side NIF buffer (604), the processing is transferred to the prefetch processing C641 (FIG. 11) of the prefetch processing unit 506. The prefetch process C performs a process of separating only the data part and holding it in the prefetch buffer in response to the response to the management request command.

The management command is a command for exchanging information between the application acceleration apparatuses 1 (105) and 2 (106). In this embodiment, two management request commands and a management close command are used. . Each request has a request and a response. The request response can be easily determined from the format, and the request and response can be easily identified from the format.

When it is determined that the request has entered the WAN side NIF buffer (605), the message is transferred to the LAN side NIF buffer 551 of the output processing unit 505 (651).

If it is determined that the response has entered the LAN side NIF buffer 606, it is determined whether the response is a close command 661. If the response is a close command, the response processing is transferred to the prefetch processing F (FIG. 14) of the prefetch processing unit 506. 662 to take over processing. If not, it is then determined whether the command is an open command 663, and if so, the processing is transferred to the prefetch processing E of the

prefetch processing unit

506, 664. If not, it is then determined whether the command is a read command 665, and if so, a management response is created 666. Thereafter, the message is transferred 667 to the WAN side NIF buffer 552 of the output processing unit 505.

If it is determined that a management command request has been received in the WAN side NIF buffer 607, the message is transferred to the prefetch processing A 671 of the prefetch processing unit 506.

The above is the processing details of the input processing unit 504. Next, a description will be given of TID management processing that is performed when the TID replacement of 406 and 409 in FIG. FIG. 8 shows tables (A) and (B) held by the output processing unit 505 in order to execute the procedure of FIG. The first table (A) is the latest TID management table 801, which has a session ID column 811 and a TID column 812 for managing the latest TID for each session ID. The second table (B) is a pre-update TID management table 802. In order to manage the association between the pre-change TID and the post-change TID for each session ID, the session ID column 821 and the pre-change TID column 822 It has a TID column 823 after the change.

FIG. 7 shows the processing details of the output processing unit 505. A method for updating the two tables in FIG. 8 will be described in accordance with the details of the procedure in FIG.

After the processing start 701, the output processing unit 505 repeatedly executes a series of procedures from the determination 702 to the determination 705, and performs each processing when hitting each determination processing.

Note that it is the speed-up device 1 (105) on the client 101 side that hits the

procedures

702 and 703, and the speed-up device 2 (106) on the file server 102 side hits the

steps

704 and 705. . The high-speed apparatus 1 (105) on the client 101 side may skip

steps

704 and 705 other than the

steps

702 and 703. Further, the acceleration device 2 (106) on the file server 102 side may skip the

procedures

702 and 703 other than the

procedures

704 and 705.

If it is determined that a request has entered the WAN side NIF buffer 552 (702), the latest TID value (a) is acquired from the latest TID management table 801 using the session ID in the message, and the latest TID management table is obtained. The TID column 812 of 801 is updated to a + 1 (721), a record is inserted into the pre-update TID management table 802 using the session ID in the message, the TID in the message, and a (722), and the output buffer of the WAN side NIF 503 The message is transferred to 532 (723). Procedures 721 to 723 correspond to a more detailed procedure 406 of FIG. The message held in the output buffer 532 of the WAN-side NIF 503 performs transmission bandwidth control according to TCP and is sent to the WAN.

If it is determined that a response has entered the LAN-side NIF buffer 551 (703), the session ID and TID in the message are updated from the pre-update TID management table 802 using the session ID and TID in the message (this is the updated TID). The corresponding record is searched, the pre-update TID (referred to as b) is acquired, and the TID in the message is updated to b. Thereafter, the output processing unit 505 deletes the searched record (731).

Here, in the case of the response output by the prefetch processing unit 506, there may be no record in the pre-update TID management table 802. In step 731, it is determined whether a record is found (732). If no record is found, the latest TID value (c) is acquired from the latest TID management table 801 using the session ID in the message (801). Then, the TID column 812 is updated to c + 1 and the TID in the message is updated to c733. Thereafter, the message with the TID updated to c is transferred to the output buffer 522 of the LAN side NIF 502 (734). The LAN side NIF 502 sequentially transfers messages stored in the output buffer 522 toward the client 101. Steps 731 to 734 are executed for the response transferred to the LAN side NIF by step 631 in FIG. For example, procedures 731 to 734 correspond to 406 in FIG.

If it is determined that a response has been received in the WAN side NIF buffer 552 (704), a record is searched from the pre-update TID management table 802 using the session ID and TID (this is the updated TID) in the message, and the pre-update TID ( (d), and the record is deleted 741 after the TID in the message is updated to d. Thereafter, the message is transferred 742 to the output buffer 532 of the WAN side NIF 503.

If it is determined 705 that a response has entered the LAN side NIF buffer 551, the latest TID value (referred to as e) is obtained from the latest TID management table 801 using the session ID in the message, and then the TID column 812 of 801 is set to e + 1. Update 751, insert a record 752 into the pre-update TID management table 802 using the session ID in the message, the TID and e in the message, and forward 753 the message to the output buffer 522 of the LAN side NIF 502. The above is the process in which the output processing unit 505 manages the TID so as to associate the transaction with the client side with the transaction with the server side.

Subsequently, processing details of the prefetch processing unit 506 will be described with reference to FIGS. 9 to 13 and FIGS. 24 to 26. FIG. 24 is a diagram showing the prefetch request management table 560. The prefetch request management table 560 is a table for managing a prefetch buffer size for each file and a location to be prefetched next time. The primary key of this table is the FID column 2410 (the FID can be the primary key because it is a system unique value). The FID is an identifier that identifies a file object opened by a specific user.

The prefetch offset column 2420 indicates how far the partial data of the file can be prefetched. That is, the acquisition state of the partial data of the file of the application acceleration device is shown. When the next prefetch is performed, the

application acceleration apparatuses

105 and 106 issue a request for reading from the offset position indicated in this column.
The prefetch buffer size column 2430 is a column indicating the size of the prefetch buffer allocated to the file object represented by the FID column 2410. That is, the value of the prefetch buffer size 2430 indicates the upper limit value of the buffer allocated for the specific file to the specific user.

A record is added to this table when an FID is issued when a file is opened (that is, when an open response is received). In this case, the prefetch offset is 0, and the prefetch buffer size is the initial value (here 1MB).
FIG. 25 shows the prefetch data management table 570. The prefetch data management table 570 is a table for managing a prefetched location for each file and a location in the prefetch buffer. The primary key of this table is a combination of the FID column 2510 and the start offset column 2520. (This table has multiple records for the same FID (because it is fragmented in the prefetch buffer).)
The start offset column 2520 and the end offset column 2530 indicate where to where the partial data of the file represented by the FID has been prefetched.
The prefetch buffer offset column 2540 represents the start offset in the prefetch buffer of the partial data of the file stored in the prefetch buffer. The end offset in the prefetch buffer is specified from values of the end offset string 2530 and the prefetch buffer start offset 2540.
FIG. 9 shows the details of the prefetch processing A of the prefetch processing unit 506.

The prefetch processing A is executed when a management command request is held in the WAN NIF buffer in FIG.

Here, after the processing is started (901), it is determined whether or not the received message is a management request command (for example, add prefetch request) (902), and if it is a management request command, a read command (request) for the prefetch buffer is created. (921), the data is transferred 922 to the LAN side NIF buffer 551 of the output processing unit 505, and the processing ends (903). Thereafter, in the processing flow of FIG. 7, the output processing unit 505 processes the message stored in the LAN side NIF buffer. Accordingly, the server-side application apparatus 2 (106) makes a prefetch request by the read command created in the procedure 921, and transmits it to the file server 102 to acquire partial data of the file.

On the other hand, if it is not a management request command (that is, if it is a management close command), the prefetch processing unit 506 creates a close command (931) and passes it to the LAN side NIF buffer 552 of the output processing unit 505 (932). The process ends (903). Thereafter, in the processing flow of FIG. 7, the output processing unit 505 processes the message stored in the LAN side NIF buffer. Accordingly, the server-side application apparatus 2 (106) performs a process of transmitting the close command created in the procedure 931 (corresponding to a part of the procedure 416 in FIG. 4).

FIG. 10 shows the details of the prefetch processing B of the prefetch processing unit 506. The prefetch process B is a process performed when a read command is held in the LAN side NIF buffer of the client side application acceleration apparatus 1 (105). This corresponds to the procedures 407 to 411 in FIG. Here, after the processing is started (1001), the prefetch processing unit 506 refers to the prefetch data management table 570, and whether or not the partial data of the file corresponding to the request range of the received read command has been prefetched, corresponds to the request range. It is determined whether the data to be stored is held in the prefetch buffer 550 (1002). As a result of the determination, if it is held (if prefetched), the prefetch processing unit 506 determines whether the access pattern from the client is sequential based on the request range of the past read command transmitted from the client 101. If it is determined (1021) and the determination result is sequential, the next acquisition prefetch buffer size is increased (1022). On the other hand, when the corresponding partial field data is not held (not pre-read), the prefetch processing unit 506 determines whether the access pattern is random (1003). The size is reduced (1031).

When the buffer size is increased / decreased, the prefetch processing unit 506 determines whether the access is random access or sequential access based on the access history from the client according to

steps

1002, 1021, and 1022, and the prefetch buffer size to be acquired next time Update. Details of the access pattern determination process and the prefetch buffer size will be described later. Thereafter, the prefetch processing unit 506 releases the oldest prefetch buffer (1004).

Further, the prefetch processing unit 506 newly secures a prefetch buffer (1005), creates a management request command (1006). The data is transferred to the WAN side NIF buffer of the output processing unit 505 (552). The processing for the management request command is as described above with reference to FIG.

Thereafter, the prefetch processing unit 506 creates a response to the read command including the file data from the prefetch buffer after the partial data of the file has entered the prefetch buffer (1008), and the LAN side NIF buffer 551 of the output processing unit 505. (1009).

Next, it is determined whether or not there is an access exceeding the threshold value n% for the data in the prefetch buffer (1010). If the threshold value is exceeded, the old prefetch buffer is released 1011 and a new prefetch buffer is secured (1012). A management request command which is an additional prefetch request for acquiring partial data of the next file is created (1013) and passed to the WAN side NIF buffer of the output processing unit 505 (1014). Thereafter, the process is finished 1015. The details of the prefetch process B including the process of updating the amount of data to be prefetched and the process of making an additional prefetch request have been described above. Note that the process of monitoring the access status to the data in the prefetch buffer in the procedure 1010 is not limited to the timing of FIG. 10 and may be performed periodically.

Here, the access pattern and the prefetch buffer related to the determination processing in

steps

1003 and 1021 in FIG. 10 will be described with reference to FIGS. 15, 26, 27, and 28. FIG. In this embodiment, the prefetch processing unit 506 determines whether the access pattern is sequential access, random access, or neutral access from the history of access to a certain file, and changes the prefetch control based on the determination result.

“Sequential access” refers to an access pattern in which it is determined that a continuous address range is specified by comparing address ranges requested by a plurality of read commands from a client. Alternatively, the sequential access is a case where data whose address range specified by a plurality of read commands is n% or more of the prefetch buffer is read. Note that n% is smaller than the threshold value n% of the procedure 1010 in FIG.

Also, random access is a case where partial data of a file of n% or more of the prefetch buffer is not read continuously for a predetermined number of times by continuous read commands from the client.

In addition, the neutral access means a case where neither a sequential access nor a random access, and specifically, a case where a partial data of a file of n% or more of the prefetch buffer is read or not read.

In step 1021 of FIG. If the file is determined to be sequential access, the access speed seen from the client can be further increased by increasing the size of the prefetch buffer (1022).

If a file on the other hand is determined to be random access, the partial data of the file that is not actually accessed by the client can be prevented from flowing to the WAN by reducing the size of the prefetch buffer. Further, when it is determined that sequential access is performed and the size of the prefetch buffer is increased, whether sequential access is performed even in the new size (that is, whether or not the partial data of a file of n% or more of the prefetch buffer of the new size is continuously read). Since it is unknown, it is treated as neutral access once and a new access type is determined. Similarly, when it is determined that sequential access is performed and the size of the prefetch buffer is increased, whether random access is performed even in the new size (that is, the partial data of the file of n% or more of the prefetch buffer of the new size is not read continuously). Since it is not known, it is treated as random access and the access type is newly determined.

An example of a state transition diagram summarizing the above explanation is shown in FIG. A description will be given of a case where the prefetch processing unit 505 determines the sequential access and random access determination criteria performed in

steps

1021 and 1003 of FIG.

Here, the neutral access state is set to 1501, the sequential access state is set to 1502, and the random access state is set to 1503. When n% of the prefetch buffer is read from the neutral state, the process proceeds to state 1521. When n% of the next prefetch buffer is read, the process proceeds to state 1522. Further, when n% of the next prefetch buffer is read, it is determined that sequential access 1502 is made, the next acquisition buffer size is increased, and the state returns to the neutral access state 1501. Similarly, if n% of the prefetch buffer is not read from the neutral state, the process proceeds to state 1531. If n% of the next prefetch buffer is not read, the process proceeds to state 1532. If n% of the next prefetch buffer is not read, sequential access is performed. 1503 is determined, and the next acquisition buffer size is reduced, and the process returns to the neutral access state 1501. If n% of the prefetch buffer is not read in the

state

1521 and 1522 during the transition to the sequential access state, the state 1531 is entered. When n% of the prefetch buffer is read in the

state

1531 and 1532 during the transition to the random access state, the state 1531 is entered.

FIG. 26 shows an access pattern management table.
A state example 2620 indicating the state of the access pattern transitioned in accordance with the access pattern state transition rule of FIG. 15, a continuous reading sequence 2630 indicating whether or not the continuous access from the client has occurred, Is a table in which FID column 2610 is associated. The FID column 2610 is a primary key, and manages an access history including an access pattern state and the number of continuous readings from the client, that is, a file reading request range from the client, for each file object. The state column 2620 represents which state in the state transition diagram of FIG.

Note that, regarding the management of the value of the prefetch buffer size 2430 in FIG. 24, the prefetch processing unit 506 may recognize the maximum value and the minimum value in advance. For example, the prefetch processing unit 506 has a user-defined or system-defined upper limit for the prefetch buffer size because the access speed between the clients 101 is biased if the prefetch buffer is too large. Further, if the prefetch buffer is too small, even the data for one read is not stored in the buffer, so the prefetch buffer size has a user-defined or system-defined lower limit.

As an example, the upper limit of the prefetch buffer size 1541 is 8 MB (1542), the lower limit is 128 KB (1543), and the initial value is 1 MB (1544). When the prefetch buffer size is increased, it is doubled (1545) until the upper limit (1542) is reached, and when the prefetch buffer size is decreased, it is halved (1546) until the lower limit (1543) is reached.

In addition, as for the access from the client indicated by the combination of the start offset and the end offset with respect to the file, after the first access (Read (101, 150)), after the random read twice, the sequential access is performed. FIG. 27 shows a state transition in the case where this is the case and n% of the current prefetch buffer is 2000.
Read (101, 150)
Read (301, 400)
Read (5501, 6500)
Read (6501, 7500)
Read (7501, 8500)
Read (8501, 9500)
Read (9501, 10500)
Read (10501, 11500)
Read (11501, 12500)
Read (12501, 13500)
27, in each row, when an input (access from a client) 2720 occurs from the initial state 2710, the state transitions to the transition destination 2730 according to FIG. 15, and in that case, the state column 2620 of the access pattern management table 580 The value of is the transition destination 2730, the value of the continuous reading column 2630 of the access pattern management table 580 is the value 2740, and further indicates that the next input is shifted in the lower row. . The prefetch processing unit 506 updates the access pattern management table 580 in FIG. 26 to confirm the state after the transition and whether or not the data stored in the prefetch buffer from the client has been continuously read.

The above is the description of the access pattern and the prefetch buffer regarding the determination processing in

steps

1003 and 1021 of FIG.

FIG. 11 shows the details of the prefetch processing C of the prefetch processing unit 506.

The prefetch processing C is performed according to the processing result of the procedure 604 in FIG.

Here, after starting processing 1101, it is determined whether the received message is a response to the management request command (1102). If the response is a management request command (for example, an additional prefetch request request), only the data part is separated and newly secured. The partial data of the file stored in the data portion is saved 1121 in the prefetch buffer thus completed, and the processing is completed (1103).

FIG. 12 shows the processing details of the prefetch processing D of the prefetch processing unit 506. Corresponding to steps 412 to 415 in FIG. 4, this is performed according to the determination result in step 621 in FIG. First, the prefetch processing unit 506 releases the prefetch buffer 1202 and determines whether there is no write command for the same FID file after the open command reception 663 (1203).

If there is no write command (if the result of the determination in step 1203 is Yes), a close response is created and returned to the client (1231), and a management close command is created (1232). The prefetch processing unit 506 records the FID of the closed file in the memory (1233), passes it to the WAN side NIF buffer 552 of the output processing unit 505, and finishes the processing. The FID recorded in the procedure 1233 is used in the prefetch processing unit 506 prefetch processing F.

On the other hand, if there is a write command (No in the determination result of step 1203), the prefetch processing unit 506 directly passes the close request command from the client 101 to the WAN side NIF buffer 552 of the output processing unit 505 (1204). ) Finish the process. The Close request command is transferred to the file server 102 via the WAN. The processing flow performed by the application acceleration device 105 when the close command is received from the client 101 has been described with reference to FIG.

FIG. 13 shows details of the prefetch processing E of the prefetch processing unit 506. The prefetch process E is a process performed in response to the process of transferring the response to the client via the WAN when the application apparatus 2 (106) on the file server side receives the response to the open command from the file server. . This corresponds to the procedure 403 in FIG.

First, the prefetch processing unit 506 creates a read command (prefetch request) for the prefetch buffer (1302), passes it to the LAN side NIF buffer 551 of the output processing unit 505 (1303), and ends the processing 1304.

FIG. 14 shows the processing details of the prefetch processing F of the prefetch processing unit 506. In the prefetch processing F, first after the processing start 1401, it is determined whether or not the FID of the received close response message is recorded, and if it is recorded (that is, recorded in the procedure 1233 of the prefetch processing D), nothing is done. The processing ends (that is, the close response message is discarded here). On the other hand, if it has not been recorded, a close response message is passed to the LAN side NIF buffer of the output processing unit 1403, and the process ends 1404. In the first embodiment, an application acceleration device that implements the above-described method places a limit on the amount of data that is prefetched at a time so that a service can be provided equally to many users in the system configured as shown in FIG. In addition, the progress of access to the partial data of the file that has been pre-read is monitored, and the partial data of the subsequent file is pre-read as necessary. Also, the TIDs of all CIFS messages are changed so that no inconsistency occurs.

In the first embodiment, an example has been described in which an application acceleration device is provided on both the client side and the server side via the WAN, and both devices perform the prefetch processing in cooperation.

In the second embodiment, an example will be described in which the client-side application acceleration device 1605 illustrated in FIG. 16 performs prefetch processing on the fill server without cooperating with other application acceleration devices. According to the present embodiment, the application acceleration apparatus 1605 can be installed on the client side. Hereinafter, the difference from the first embodiment will be described with emphasis. FIG. 17 shows the sequence of the second embodiment. Compared to FIG. 1 of the first embodiment, the application acceleration device 1605 is changed to receive an open command and start 1701 prefetching. Similarly, when prefetching is lost, the application acceleration device 1605 starts prefetching.

In the first embodiment, there is no change in the processing flow described in FIG. 4 in the first embodiment and the configuration in the application acceleration device described in FIG. However, the processing contents of the

processing units

504, 505, and 506 in the application acceleration device are slightly changed, and will be described below.

FIG. 18 shows the processing details of the input processing unit 504. Here, in comparison with the processing details (FIG. 6) of the input processing unit 504 of the first embodiment, the input processing unit determines that a request is input to the input buffer 521 of the LAN side NIF 502 and the input buffer of the WAN side NIF 503. When a response is entered in 531, only 1806 is set. In addition, among the processes in the case where the procedure 1806 is hit, the process in the case where the response is a read command is changed to the transfer 1866 to the prefetch process G of the prefetch processing unit 506.

FIG. 19 shows the processing details of the output processing unit 505. Here, in comparison with the processing details (FIG. 7) of the output processing unit 505 of the first embodiment, the output processing unit determines that a request is entered in the WAN side NIF buffer 552 and a response is received in the LAN side NIF buffer 551. When entering, it becomes only 703. The processing after hitting the

judgments

702 and 703 is not changed.

20 to 23 show details of the processing of the prefetch processing unit 506. The prefetch processing A and the prefetch processing C in the first embodiment are not necessary for the prefetch processing unit 506 in the second embodiment. In addition, a prefetch process F is newly added.

FIG. 20 shows the details of the prefetch processing B of the prefetch processing unit 506. Compared to the case of the first embodiment (FIG. 10), the procedure 1006 and the procedure 1013 for creating the management request command are changed to read

command creation

2006 and 2013 for the prefetch buffer.

FIG. 21 shows the details of the prefetch processing D of the prefetch processing unit 506. Compared to the case of the first embodiment (FIG. 12), the management close command creation 1232 procedure becomes unnecessary.

FIG. 22 shows the details of the prefetch processing E of the prefetch processing unit 506. Compared to the case of the first embodiment (FIG. 13), the read command transfer destination is changed to the WAN side NIF buffer 532 (2203) of the output processing unit 505.

FIG. 23 shows the processing details of the prefetch processing G of the prefetch processing unit 506. Here, first, after the processing start 2301, only the data part is separated and stored in a newly secured prefetch buffer 2302, and the processing ends 2303.

In the second embodiment, the application acceleration device 1605 in which the above-described method is implemented can reduce the partial data amount of a file to be pre-read at a time so that a service can be provided equally to many clients in the system configured as shown in FIG. Set restrictions. Also, the progress of access to the partial data of the file that has already been pre-read is monitored, and the subsequent partial data is pre-read as necessary. In addition, the application acceleration device converts the TID included in the CIFS message from the client, sends a CIFS message including a prefetch request to the server side, and similarly converts the TID for the response from the server, Responds to access requests. Thereby, inconsistency is prevented from occurring. According to the above-described embodiment, it is possible to prevent the occupation of the buffer by one user who uses the file, to perform efficient prefetching processing, and to provide a service equally to many users.ため Since the partial data of the file is read little by little, the bandwidth can be released to other communications. Since it is not read at a time, it is not necessary to use a bandwidth for prefetching partial data that is not used by the user, and the network can be used efficiently.

Although the CIFS protocol has been described as an example, a prefetch control similar to that in the above-described embodiment is performed in a communication apparatus that relays between a client and a server that perform communication according to the NFS (Network File System) protocol or FTP (File Transfer Protocol). May be.

In addition, this invention is not limited to the above-mentioned Example, Various modifications are included. For example, the above-described embodiments have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described. Further, a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. Further, it is possible to add, delete, and replace other configurations for a part of the configuration of each embodiment.

In addition, each of the above-described configurations, functions, processing units, processing means, and the like may be realized by hardware by designing a part or all of them with, for example, an integrated circuit. Each of the above-described configurations, functions, and the like may be realized by software by interpreting and executing a program that realizes each function by the processor. Information such as programs, tables, and files for realizing each function can be stored in a recording device such as a memory, a hard disk, an SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, or a DVD.

Also, the control lines and information lines indicate what is considered necessary for the explanation, and not all the control lines and information lines on the product are necessarily shown. Actually, it may be considered that almost all the components are connected to each other.

105, 106

Application acceleration device

103, 104 TCP acceleration device 102 File server

Claims

A communication device connected to a client via a first network and a server via a second network,
A buffer capable of holding data of a file provided by the server;
A control unit that performs read / write control of data with respect to the buffer,
The control unit determines whether to perform prefetching to the server for a predetermined range in the file based on at least one access from the client to a file provided by the server, and performs the prefetching. The communication device, wherein the communication device stores the partial data of the file received from the server in the buffer.
The communication device according to claim 1, wherein
When the access from the client is a file open request,
The said control part transfers the said open request to the said server, and performs the said prefetch according to receiving a file identifier from the said server, The communication apparatus characterized by the above-mentioned.
The communication device according to claim 2,
The communication apparatus according to claim 1, wherein the prefetching is obtained by dividing a predetermined range in the file into a plurality of read requests including designation of the file and designation of the file, and acquiring partial data of the file.
The communication device according to claim 3,
Each of the read requests includes an identifiable identifier.
The communication device according to claim 2,
The control unit transmits the corresponding data to the client when the data corresponding to the access from the client is in the buffer after transmitting the file identifier to the client. .
6. The communication apparatus according to claim 5, wherein prefetching is performed on the server based on an amount of data held in the buffer transmitted to the client.
The communication device according to any one of claims 1 to 6,
When the access from the client is an acquisition request for partial data of the file, the control unit reads the data corresponding to the acquisition request from the buffer to transmit to the client, and the read amount from the buffer A pre-reading is performed on the server based on the communication device.
The communication device according to claim 7,
When the read amount exceeds a predetermined amount, the control unit prefetches data including a range continuous with a previously prefetched range in the file to the server.
The communication device according to any one of claims 1 to 8,
A prefetch target in the file is determined based on a plurality of access histories from the client.
The communication device according to claim 9, wherein
The plurality of accesses specify a continuous range of the file;
The said control part increases the range made into the said prefetch object, The communication apparatus characterized by the above-mentioned.
The communication device according to claim 1, wherein
The second network is a network according to TCP;
The communication apparatus, wherein the server provides a file to the client according to a file request protocol.
A communication system that relays communication between a client and a server that provides a file to the client,
According to the access to the file from the client, the partial data corresponding to the file is read out of the data stored in the buffer and transmitted to the client, and the prefetching to the file is performed according to the access status from the client. A buffer controller that issues the request;
An acquisition device that acquires partial data of the file from a server based on the prefetch request;
A communication system characterized by comprising:
The communication system according to claim 12, wherein
The buffer control device and the acquisition device are connected via a network,
The file acquisition device acquires partial data of a predetermined range of the file with respect to the file data of the server according to the specification of the file from the client,
Obtaining partial data corresponding to a prefetch target range specified by a plurality of read requests for the file from the client, and transmitting the data to the buffer control device;
The buffer control device stores partial data received from the file acquisition device in the buffer, and reads partial data corresponding to a read request transmitted from the client device after the plurality of read requests from the buffer. A communication system characterized by transmitting to the client.
The communication system according to claim 12, wherein
The buffer control device and the acquisition device are connected via a BUS,
The file acquisition device acquires partial data of a predetermined range of the file with respect to the file data of the server according to the specification of the file from the client,
Obtaining partial data corresponding to a prefetch target range specified by a plurality of read requests for the file from the client;
The buffer control device stores partial data acquired by the file acquisition device in the buffer, and reads partial data corresponding to a read request transmitted from the client device after the plurality of read requests from the buffer. A communication system characterized by transmitting to the client.
A communication method in which a client and a file server communicate partial data of a file according to a file sharing protocol,
In response to the file designation from the client, obtain a file identifier from the file server,
Creating a partial data prefetch request for a predetermined range of file data corresponding to the file identifier;
Sending the prefetch request to the server according to TCP;
Holding the partial data of the file included in the response corresponding to the prefetch request in a buffer;
Based on a read status of partial data from the buffer in response to a read request of the file from the client, a prefetch target range of the file is determined, and a prefetch request for the determined prefetch target range is sent to the server according to TCP A communication method comprising: storing partial data of a file transmitted and received from the server in the buffer for further read request from the client.