JP2013218387A - Packet communication device and method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To prevent the deterioration of communication efficiency, that is, the sharp increase of a file transfer time in the case of using a WebDAV (Web Distributed Authoring and Versioning) for easily editing a file on a server by extending an HTTP (Hyper Text Transfer Protocol) for a WAN (Wide Area Network) whose communication delay is large.SOLUTION: In a network in which a client side proxy is installed on a client side, and a server side proxy is installed on a server side, when receiving a second request following a first request transmitted by the client and corresponding to a response including a list of multiple files to the first request, the client side proxy or the server side proxy transmits a request for acquiring multiple files pertinent to the list to the server without waiting for further requests from the client, and pre-fetches the substance of the multiple files pertinent to the list of multiple files as a response to the multiple file acquisition request from the server.

Description

  The present invention relates to a packet communication apparatus and method.

  In the web system, when displaying information from the server on the client side, the web browser analyzes the HTML between the client and server, and sends a GET request for the object to the server each time an object is found. Usually, since the number of simultaneous connections from a browser to one server is limited, a web page is read many times between client and server.

  When the client and server are connected by a wide-area network (Wide Area Network: WAN) such as an intercontinental submarine cable, communication using the Hyper Text Transfer Protocol (HTTP) is significantly less efficient. To do. In a network with a large delay, it takes a long time from when a client sends a request until a response is returned from the server, and the client needs to wait during that time. Since this is performed many times, it takes a long time to complete the display after requesting the web page.

  For example, in order to prevent delays in invoking web page inline objects that are downloaded from a server via a satellite link when the client and server communicate via a satellite link, the distributed proxy server may acquire A technique for prefetching an inline object is disclosed in Patent Document 1.

  Further, there is a system called WebDAV (Web Distributed Authoring and Versioning) that extends the HTTP system and makes it easy to edit files on the server (Non-patent Document 1). In WebDAV, files and folders on the server can be operated via a WebDAV client. In WebDAV, requests similar to HTTP are used, and a request called PROPFIND is used to get property information about files in the folder.

WO1999008429A

IETF RFC2518 “HTTP Extensions for Distributed Authoring-WEBDAV”

  However, unlike HTTP, in WebDAV, a file does not have a master-slave relationship such as a basic component and an inline object that accompanies the basic component. Prefetching is not possible.

  Therefore, an object of the present invention is to realize an appropriate file list acquisition method when WebDAV is used over a WAN.

  In addition, even if WebDAV obtains file list information, it cannot determine whether the files should be transferred unless the next request is known. End up. Therefore, another object of the present invention is to efficiently transfer a plurality of files only when necessary. Another object is to realize high-speed transfer of appropriate files when WebDAV is used over a WAN.

  In order to solve at least one of the problems, an aspect of the present invention is a system including a client-side proxy connected to a client and a server-side proxy connected to a server. In the communication method of relaying the communication of the server, the server transmits a response to the request from the client between the client and the server. When a response including a list of multiple files obtained by the request is transmitted to the client and a second request related to the list is received from the client, the server does not wait for the request from the client and For multiple files corresponding to the above list It sends a request for a communication method of the entity of the plurality of files corresponding to the list of the plurality of files as a response to the plurality file acquisition request, the prefetch from the server, and wherein the.

  Another aspect is a proxy system that controls communication of data stored in a server between a client device and a server device, the client communication unit communicating with the client, the server communication unit communicating with the server, When receiving a request for acquiring at least one of the plurality of information included in the response to the first request from the client, the server acquires the request for acquiring the plurality of information included in the response. And a transmission control unit that transmits the response to the client when the response to the plurality of information acquisition requests is received from the server.

  A plurality of files are efficiently transferred from the server to the client by communication according to HTTP or WebDAV.

It is a sequence diagram showing the communication system in Example 1 of this invention. It is a network block diagram in a present Example. It is a figure showing the internal structure of the client side proxy in a present Example. It is a figure showing the internal structure of the server side proxy in a present Example. It is a figure showing the data management table of the client side proxy and server side proxy in a present Example. It is a flowchart showing operation | movement of the client side proxy in Example 1 of this invention. It is a flowchart showing operation | movement of the server side proxy in Example 1 of this invention. It is a sequence diagram showing the communication system in Example 2 of this invention. It is a flowchart showing the operation | movement of the client side proxy in Example 2 of this invention. It is a flowchart showing operation | movement of the server side proxy in Example 2 of this invention. It is a sequence diagram showing the communication system in Example 3 of this invention. It is a flowchart showing the operation | movement of the client side proxy in Example 3 of this invention. It is a flowchart showing operation | movement of the server side proxy in Example 3 of this invention. It is a sequence diagram showing the communication system in Example 4 of this invention. It is a figure showing the internal structure of the client side proxy in Example 4 of this invention. It is a figure showing the internal structure of the server side proxy in Example 4 of this invention. It is a figure showing the data management table of the client side proxy and server side proxy in Example 4 of this invention. It is a flowchart showing the operation | movement of the client side proxy in Example 4 of this invention. It is a flowchart showing operation | movement of the server side proxy in Example 4 of this invention.

  FIG. 2 is a diagram illustrating a network configuration in the present embodiment.

  The client side proxy (12) is installed in the same LAN (13) as the client (11), and the client side proxy (12) communicates with the WAN (14). Similarly, a server side proxy (15) is installed in the same LAN (17) as the server (16), and the server side proxy (15) communicates with the WAN. The client-side proxy (12) and the server-side proxy (15) operate in a coordinated manner, so that communication can be performed while suppressing performance degradation even in a WAN having a delay larger than that of a LAN.

  In this embodiment, a system in which the client side proxy (12) and the server side proxy (15) operate in cooperation will be described. However, the client side proxy (12) or the server proxy (15) also functions as the other proxy. The proxy system may omit the other process.

  A communication sequence in the first embodiment of the present invention is shown in FIG. FIG. 1 shows a sequence of at least one client (11), client-side proxy (12), server-side proxy (15), and server (16) involved in communication.

  When a client accesses a folder on the server, first, the client issues a request (101) called PROPFIND to the folder. This request is received by the client side proxy (12) and transferred to the server side proxy (15) via the WAN (111).

  When the server-side proxy (15) receives PROPFIND, it further forwards it to the server (16) (121). The server (16) that has received the PROPFIND generates a response to it and returns it to the WAN side toward the client (122). This response includes a list of files in the folder. The response is transferred to the client-side proxy (12) by the server-side proxy (15) (112), and the server-side proxy (15) analyzes the response to PROPFIND and obtains a list of files in the folder. Furthermore, it is transferred to the client (11) by the client side proxy (12) (102). The client side proxy (12) similarly analyzes this response and acquires a file list. The client (11) analyzes this response separately from the client side proxy (12) and the server side proxy (15) to obtain a file list.

  The client (11) which acquired the file list transmits a request to each file in order. The request (103) for the first file sent from the client (11) is transferred by the client side proxy (12) (113), transferred by the server side proxy (15) (123) and received by the server (16). Is done. The server (16) transmits the file as a response to the request (123) (124).

  First, the operation of the server side proxy (15) will be described. The server side proxy (15) which received the response (124) transfers this to the client side proxy (12) (114). At the same time, the server side proxy (15) transmits a request for the next file in the file list to the server (16) instead of the client (11) (125). The server (16) transmits a file as a response to this (126). The server-side proxy (15) that has received the file (one of the files in the file list) transfers the file to the client-side proxy (12) (115), and if the next file exists in the file list. A request for that is transmitted (127). When the server side proxy (15) receives the response to the request (128), it transfers it to the client side proxy (12) (116). Since there is no next file in the file list, the server side proxy (15) discards the file list and completes the operation.

  Next, the operation of the client side proxy (12) will be described. The client-side proxy (12) receives the response of the file 1 (114), acquires the file 1, and transfers the file 1 to the client (11) (104). The client (11) transmits a request for the file 2 (105). On the other hand, since the response of the file 2 is sent from the server side proxy (15) (115), the client side proxy (12) sends a request and response to the file 2 to the client (11). The response is transmitted (106). A similar operation is repeated for all files in the file list (107, 116, 108), and the file list is discarded to complete the operation.

  The above operation is performed independently for each set of the client (11) and the server (16) in both the client side proxy (12) and the server side proxy (15). The client (11) and server (16) are identified using the IP address in the packet header.

  As described above, the server-side proxy 15 reads a plurality of files corresponding to “207 Multi-Status” when receiving the designation of the file corresponding to “207 Multi-Status” included in the response to “PROPFIND”. In this example, the files 1-3 are sent to the client-side proxy 12 by “200 OK”.

  FIG. 3 is a diagram showing the internal configuration of the client side proxy (12). The server-side proxy (12) is a communication device that mediates communication between the client 11 and the server 16 and transmits and receives packets. For example, the server-side proxy (12) is between the client 11 and the WAN. Alternatively, it may be a gateway device of a local network on the client side. The client is, for example, an information processing device or a wireless information processing terminal. The local network may be configured by at least one of wired and wireless.

  The LAN side connection management unit (301) communicates with the client (11). In the request from the client (11), the request determination unit (302) identifies the client (11) that transmitted the request. In addition, it is determined whether the request is a trigger for a prefetch operation such as PROPFIND or GET.

  When the prefetch operation is not being performed, the received request is sent to the request transmission unit (305) as it is and is transmitted to the server side proxy (15). During the prefetch operation, the request is temporarily registered in the data management unit (304).

  The data management unit (304) has a table for each client (11) identified by the IP address, and manages the request / response state and its data. For example, if there are three clients, there are three tables (311 to 313). When a request is received, the table is searched using the path name as a key, and a request received flag is set. If a prefetched response is received, a response received flag is set. The table entry is periodically checked, and if the request has been received and the response has been received, the response is transmitted to the client via the response transmission unit (303). If no response is registered when the request is received, the request may be transmitted to the server-side proxy (15) via the request transmission unit (305).

  The request transmission unit (305) transmits the request received from the request determination unit (302) or the data management unit (304) using the WAN side connection management unit (307).

  The WAN side connection management unit (307) controls communication with the server side proxy (15) through the WAN.

  The response analysis unit (306) analyzes the IP address of the response received from the server-side proxy (15) and determines which client (11) it is for. If it is a response to PROPFIND, its contents are also analyzed to obtain a file list and registered in the data management unit (304). At the same time, it is passed to the response transmission unit (303) and transferred to the client (11). If it is a response to GET, it is registered in the data management unit (304).

  The response transmission unit (303) transfers the response data received from the response analysis unit (306) or the data management unit (304) to the LAN side connection management unit (301) and transfers it to the client (11).

  FIG. 4 is a diagram showing the internal configuration of the server-side proxy (15). The server-side proxy (15) is a communication device that mediates communication between the client and the server and transmits and receives packets, and is one example between the server and the WAN. Alternatively, it may be a local network gateway device on the server side. The server is an information processing apparatus, for example. The local network on the server side may be configured by at least one of wired and wireless. The WAN side connection management unit (401) communicates with the client side proxy (12).

  In the request from the client side proxy, the request determination unit (402) identifies the client (11) that transmitted the request. In addition, it is determined whether the request is a trigger for a prefetch operation such as PROPFIND or GET.

  When the prefetch operation is not in progress, the received request is sent to the request transmission unit (405) as it is and transmitted to the server. When the prefetch operation is being performed, the request is once registered in the data management unit (404).

  Similar to the client-side proxy (12), the data management unit (404) has a data management table for each client (11), and manages the request / response state and its data. For example, if there are three clients (11), there are three tables (411 to 413). During the prefetch operation, the table is periodically checked, and if there is an entry that has not been prefetched, the prefetch is performed, and thus the URL is passed to the request transmission unit (405). When a request is received from the client side proxy (12), if the corresponding response is not transmitted, the request is preferentially transferred to the request transmission unit (405) and transmitted to the server (16).

  The request transmission unit (405) transmits the request received from the request determination unit (402) or the data management unit (404) using the LAN side connection management unit (407). The LAN side connection management unit (406) controls communication between the server side proxy (15) and the server (16).

  The response analysis unit (406) analyzes the response to PROPFIND received from the server (15), acquires a file list, and registers it in the data management unit (404). At the same time, the data is transferred to the client (16) via the response transmission unit (403). If the response is a response to GET, it is registered in the data management unit (404).

  The response transmission unit (403) transfers the response data received from the response analysis unit (406) or the data management unit (404) to the client side proxy (12) via the WAN side connection management unit (401).

  FIG. 5 shows data management tables (311 and 411) in the data management unit of (a) client side proxy and (b) server side proxy. The data management table (311) of the client side proxy has, for each target file, a file URL (351), a prefetched response (352), and three types of flags that take a value of 1 or 0. The flags are “request received from client (353)”, “response received from server-side proxy (354)”, and “response sent to client (355)”.

  The “request received from client (353)” flag is set to 1 when a request for the file is received from the client. Even if the value of the flag is other than 0 or 1, a value that can identify whether or not a request from the client has been received may be used.

  The “response received from server side proxy (354)” flag is set to 1 when the file is received from the server side proxy. Even if the value of the flag is other than 1, a value that can identify whether or not a response is received from the server-side proxy may be used. If both of these flags are 1, the response is sent from the client-side proxy to the client, and the “response sent to client (355)” flag is set to 1. If the “response sent to client (355)” flag is 1, the corresponding entry is deleted.

  The server-side proxy data management table has, for each target file, a file URL (451), a prefetched response (452), and three types of flags that take a value of 1 or 0. The flags are “prefetch request transmitted to server (453)”, “request received from client side proxy (454)”, and “response received from server (456)”.

  The “prefetch request sent to server (453)” flag is set to 1 when a request for the file is sent to the server. Even if the value of the flag is other than 0 or 1, a value that can identify whether or not a prefetch request is transmitted to the server may be used. The “request received from client side proxy (454)” flag is set to 1 when a request is received from the client side proxy. The “response received from server (455)” flag is set to 1 when a response is received from the server. When this flag is 1, the response is sent to the client-side proxy and the entry is deleted.

  FIG. 6 is a flowchart showing the operation of the client side proxy (12). In the initial state, it waits until a packet is received on the LAN side (501). When receiving the packet on the LAN side, the client side proxy (12) separates the packet for each source and destination IP address (502). If the packet is a PROPFIND request (503), the client side proxy (12) transfers it to the server side proxy (504) and shifts to a GET wait state. If it is another request (551), it is similarly forwarded to the server side proxy (552), but it does not prepare for prefetching, but waits for a response from the server side proxy (15) (553). Transfer to the client (11) (554) and return to the initial state (501).

  Until the response of PROPFIND (504) transferred to the server-side proxy is received, the client-side proxy (12) waits for processing related to the PROPFIND (504) (505). When the response of PROPFIND (504) is received, the client side proxy (12) transfers the response to the client (11) (506). The client-side proxy (12) analyzes this response to create a file list and registers it in the data management unit (404) (507).

  Subsequently, the client side proxy (12) waits for a GET request from the client (508). Upon receiving the GET, the client side proxy (12) transfers it to the server side proxy (15) (509) and waits until a response to the GET request is received (510). If received, the client side proxy (12) transfers (511) to the client (11) and waits for prefetch data from the server side proxy (15) (512). When a request other than GET is received (555), the request is similarly transferred to the server side proxy (15) (556), but a response is received from the WAN side (557), and it is sent to the client (11). Transfer (558) and return to the initial state (501).

  When the prefetch data from the server side proxy (15) is received (512), the client side proxy (12) stores it in the data management unit (304) (513) and waits for a request from the client (514). ). When the request is received, the file corresponding to the request is read from the prefetch data stored in the data management unit (304), and the stored prefetch data is transmitted as a response to the client (515).

  If a file remains in the file list, 512 and subsequent steps are repeated (516). Either all the data has been transferred or the prefetched data is discarded due to timeout and the process returns to the initial state (501) (517).

  The above operation is performed independently for each set of the client (11) and the server (16) in both the client side proxy (12) and the server side proxy (15). The client (11) and server (16) are identified using the IP address in the packet header.

  FIG. 7 is a flowchart showing the operation of the server side proxy (15). In the initial state, it waits until a packet is received on the WAN side (601). Upon reception, the server side proxy (15) separates the source IP address and the destination IP address (602). If the packet is a PROPFIND request (603), the server side proxy (15) transfers to the server (16) (604) and shifts to a GET wait state. If it is another request (651), the server-side proxy (15) forwards to the server (16) (652), but does not prepare for prefetching, and the server-side proxy (15) receives from the server (16). Waiting for the response to be received (653), it is transferred to the client (11) side (654), and the process returns to the initial state (601).

  On the other hand, after step 603, the server side proxy (15) waits until the response of PROPFIND (604) transferred to the server (16) is received (605), and when received, transfers to the client side proxy (15). (606). The server side proxy (15) analyzes the response to PROPFIND (604), creates a file list, and registers it in the data management unit (404) (607).

  Subsequently, a GET request from the client side proxy (12) is awaited (608). When the GET is received, the server side proxy (15) transfers it to the server (16) (609), and waits until a response is received (610). If it is received, it is transferred to the client side proxy (12) (611), and a prefetch request for the next file is transmitted according to the file list registered in the data management unit (404) (612). When a request other than GET is received (655), the server-side proxy (15) forwards to the server (656), but waits to receive a response from the server (16) (657) and sends it to the client. Transfer to the side proxy (12) (658), and return to the initial state (601).

  On the other hand, when prefetch data from the server (16) is received in step 612 (613), the server side proxy (15) transmits to the client side proxy (614).

  According to the file list, the server-side proxy (15) repeats 612 and subsequent steps if there are any files not received from the server (615). Either all the data has been transferred or the prefetched data is discarded due to a timeout and the process returns to the initial state (601) (616).

  The above operation is performed independently for each set of the client (11) and the server (16) in both the client side proxy (12) and the server side proxy (15). The client (11) and server (16) are identified using the IP address in the packet header.

  FIG. 8 shows a communication sequence in the second embodiment of the present invention. FIG. 8 shows a sequence of the client (11), the client side proxy (12), the server side proxy (15), and the server (16) related to communication. It is assumed that the communication of the WAN conforms to the WebDAV standard protocol while maintaining the same communication efficiency as that of the first embodiment by the method of the present embodiment. Thereby, it is possible to prevent communication on the WAN from being judged as abnormal communication and blocked by a security system such as a firewall, Intrusion Detection System / Intrusion Protection System, and Deep Packet Inspection.

  Procedures 701, 702, 711, 712, 721, and 722 are the same as the PROPFIND request and its response in the same manner as the procedures 101, 102, 111, 112, 121, and 122 of FIG.

  The client (11) which acquired the file list transmits a request to each file in order. The request (703) for the first file transmitted from the client (11) is received by the client side proxy (12). When the client-side proxy (12) analyzes this request and determines that the file (file 1) is included in the file list that is a response to the PROPFIND request, the client-side proxy (12) transfers this request to the server-side proxy (15). (713). Further, the client-side proxy (12) is not the file (file 1) specified by the request (707) from the client, but requests (714, 715) for other files (files 2, 3) in the file list. Also issue. These requests are transmitted to the server side proxy (15) without waiting for a response to the previous request (714, 715).

  When the server-side proxy (15) receives the request from the client-side proxy (12) (713), the request for the file (file 1) specified in the first request from the client is received in the file list. It transmits to the server (16) on behalf of the client (11) (723). The server (16) transmits the file 1 as a response to this (724). The server side proxy (15) which received this transfers (716) this file to the client side proxy (12).

  Further, in response to the reception of the file 1 from the server (16), the server side proxy (15) transmits a request for the next file (file 2) if there is a next file (file 2) in the file list including the received file 1. (725). When the server side proxy (15) receives the response to the request (726), it transfers it to the client side proxy (12) (717). Furthermore, if the next file is also prefetched in the same manner as steps 725, 726, and 717 (727, 728, and 718), the server side proxy (15) discards the file list if there is no next file in the file list. To complete the operation. This request may be started after receiving a response to the previous request, or a plurality of requests may be transmitted simultaneously.

  When the proxy on the client side (12) receives the response of the file 1 (716), it transfers it to the client (11) (704). The client (11) transmits a request for the file 2 (705). On the other hand, since the response of the file 2 is received from the server side proxy (15) (717), the response is transmitted to the client (11) when the request and response for the file 2 are completed (706). A similar operation is repeated for all files in the file list (718, 707, 708), the file list is discarded, and the operation is completed.

  The above operation is performed independently for each set of the client (11) and the server (16) in both the client side proxy (12) and the server side proxy (15). The client (11) and server (16) are identified using the IP address in the packet header.

  FIG. 9 is a flowchart showing the operation of the client side proxy (12) in the second embodiment. Steps 801 to 807 and 851 to 854 are the same as steps 501 to 507 and 551 to 554 in FIG.

  Next, it waits for a GET request from the client (808). Upon receiving the GET request, the client-side proxy (12) issues a prefetch request for the files in the file list in response to this (809). This request is sent without waiting for a response to the previous request. This is repeated until a request is transmitted for all files in the file list (810). When a request other than GET is received (855), the request is similarly transferred to the server side proxy (15) (856), but a response is received from the WAN side (857), and it is sent to the client (11). Transfer (858) and return to the initial state (801).

  When a response to the first request is received from the server-side proxy (15) (811), the client-side proxy (12) transfers this to the client (812). When the client-side proxy (12) receives the prefetch data from the server-side proxy (15) (813), it stores it in the data management unit (304) (814) and waits for a request from the client (815) ). When the request is received, the client side proxy (12) transmits the stored data as a response to the client (816).

  If a file remains in the file list, steps 812 and after are repeated (817). Either all data has been transferred or the prefetched data is discarded due to a timeout and the process returns to the initial state (801) (818). The above operation is performed independently for each set of the client (11) and the server (16) in both the client side proxy (12) and the server side proxy (15). The client (11) and server (16) are identified using the IP address in the packet header.

  FIG. 10 is a flowchart showing the operation of the server side proxy (15) in the second embodiment. Steps 901 to 907 and 951 to 954 are the same as steps 601 to 607 and 651 to 654 in FIG. Subsequently, a prefetch request from the client side proxy (12) is awaited (908). Since a plurality of prefetch requests are sent corresponding to the number of files included in the file list, the server-side proxy (15) repeats this until it receives all requests corresponding to the number of files included in the file list. (909). Subsequently, the prefetch requests are sequentially transferred to the server (16) (910), and the system waits until a response is received (911). When the response is received, the server side proxy (15) transfers them to the client side proxy (12) (912). When a request other than GET is received (955), the server-side proxy (15) similarly transfers to the server (16) (956), but the server-side proxy (15) receives a request other than GET from the server (16). Waiting for the reception of the response corresponding to the request (957), it transfers it to the client side proxy (12) (958), and returns to the initial state (901).

  If a file that has not been acquired from the server remains in the file list, 910 and subsequent steps are repeated (913). Either all the data has been transferred or the prefetched data is discarded due to a timeout and the process returns to the initial state (901) (914). The above operation is performed independently for each set of the client (11) and the server (16) in both the client side proxy (12) and the server side proxy (15). The client (11) and server (16) are identified using the IP address in the packet header.

  Since the configuration in the apparatus is the same as that in the first embodiment, it is omitted here.

  In the above description of the second embodiment, it has been described that a request to be prefetched and a response are associated with each other and communication control between proxies is performed using information obtained by communication according to WebDAV. This control prevents communications on the WAN from being detected as abnormal communications and blocked by a security system such as a firewall, Intrusion Detection System / Intrusion Protection System, or Deep Packet Inspection. be able to.

  FIG. 11 shows a communication sequence in the third embodiment of the present invention. In this example, the method of the second embodiment is applied to HTTP. As in the case of the second embodiment, since the communication on the WAN conforms to the HTTP standard by the method of this embodiment, it is possible to prevent the security system from determining that the communication is abnormal and blocking it. .

  When the client reads a web page from the server, it first issues a request (1001) called GET to the HTML file. This is received by the client side proxy (12) and transferred over the WAN to the server side proxy (15) (1011). Upon receiving this, the server side proxy (15) further transfers it to the server (16) (1021). Upon receiving the GET for HTML, the server (16) returns the HTML file to the client (1022). This response (1022) is a response “200 OK” according to HTTP, and includes a list of files in the folder. The response is transferred to the client-side proxy (12) by the server-side proxy (15) (1012), and the server-side proxy (15) obtains a list of files in the folder by analyzing the response. Further, it is transferred to the client (11) by the client side proxy (12) (1002). The client side proxy (12) similarly analyzes this response and acquires a file list. The client (11) analyzes this response independently of the client side proxy (12) and the server side proxy (15) to obtain a file list.

  The client (11) which acquired the file list transmits a request to each file in order. The request (1003) for the first file transmitted from the client (11) is received by the client side proxy (12).

  When the client-side proxy (12) analyzes the request and determines that the file is included in the file list, the client-side proxy (12) transfers the request to the server-side proxy (15) (1013). When the client-side proxy (12) determines that the file specified by the request from the client 11 is a file (file 1) included in the file list acquired by the response (1012) of “200 OK”, the file Issues requests for other files (file2, 3) in the list. These requests are transmitted to the server side proxy (15) without waiting for a response to the previous request (1014, 1015). That is, when a request for specifying one file included in the file list is received from the client, the client-side proxy (12) waits for a request from the client (11) for requests for other files included in the file list. Without issuing a prefetch request (1014, 1015) to the server side proxy (15).

  When the server-side proxy (15) receives the request from the client-side proxy (12) (1013), it sends a request for the file in the file list to the server (16) instead of the client (11) (1023). . The server (16) transmits a file as a response to this (1024).

  The server-side proxy (15) that has received this forwards (1016) this file to the client-side proxy (12), and if there is another file in the file list acquired in the response (1022), sends a request for it to the server It transmits to (16) (1025).

  When the server side proxy (15) receives the response to the request (1026), the server side proxy (15) transfers the response to the client side proxy (12) (1017). Other files are similarly prefetched (1027, 1028, 1018). In addition, the server side proxy (15). A file request corresponding to a prefetch request transmitted from the client side proxy (12) may be transmitted to the server (16). Since there is no next file in the file list, the server side proxy (15) discards the file list and completes the operation. This request is started after receiving a response to the previous request.

    When the proxy on the client side (12) receives the response of the file 1 (1016), it transfers it to the client (11) (1004). The client (11) transmits a request for the file 2 included in the file list (1005). On the other hand, since the response of the file 2 is transmitted from the server side proxy (15) (1017), the client side proxy (12) holds the request for the file 2 and receives the response to the client (11). On the other hand, a response corresponding to the request for the held file 2 is transmitted (1006). A similar operation is repeated for the files included in the file list (1018, 1007, 1008), and the file list is discarded from the buffer to complete the operation.

  The above operation is performed independently for each set of the client (11) and the server (16) in both the client side proxy (12) and the server side proxy (15). The client (11) and server (16) are identified using the IP address in the packet header.

  FIG. 12 is a flowchart illustrating the operation of the client-side proxy (12) in the third embodiment. In the initial state, it waits until a packet is received on the LAN side (1101). When received, the source and destination IP addresses are separated (1102). If the packet is a GET request for HTML (1103), the packet is transferred to the server side proxy (1104), and a transition to the GET wait state is made. If it is another request (1151), it is similarly transferred to the server side proxy (15) (1152), but it does not prepare for prefetching, but waits for a response to be received from the server side proxy (15) (1153). It is transferred to the client (11) (1154), and the process returns to the initial state (1101).

  Wait until a GET (1104) response to the HTML transferred to the server-side proxy is received (1105), and if received, transfer to the client (11) (1106). At the same time, the response is analyzed to create a file list and registered in the data management unit (304) (1107).

  Subsequently, a GET request from the client is awaited (1108). Upon receiving a GET request for a file included in the file list, the client side proxy issues a prefetch request for the file in the file list as a trigger (1109). These requests are sent without waiting for a response to the previous request. This is repeated until the request is transmitted not only for the file specified by the GET request from the client but also for the file included in the file list specified by the GET request (1110). When a request other than GET is received (1155), the request is similarly transferred to the server side proxy (15) (1156), but a response is received from the WAN side (1157), and the request is sent to the client (11). Transfer (1158) and return to the initial state (1101).

  When a response to the first request is received from the server-side proxy (15) (1111), the client-side proxy (12) transfers this to the client (1112). When the prefetch data from the server side proxy (15) is received (1113), the client side proxy (12) stores it in the data management unit (304) (1114) and waits for a request from the client (1115). ). Upon receiving a request from the client, the client side proxy (12) reads from the data stored in the file corresponding to the file specified by the request, and transmits the data to the client as a response (1116).

  If the file remains in the file list, the client-side proxy (12) repeats the steps after 1112 (1117). The client-side proxy (12) completes the transfer of all data, or discards the prefetched data due to timeout and returns to the initial state (1101) (1118).

  The above operation is performed independently for each set of the client (11) and the server (16) in both the client side proxy (12) and the server side proxy (15). The client (11) and server (16) are identified using the IP address in the packet header.

  FIG. 13 is a flowchart illustrating the operation of the server-side proxy (15) in the third embodiment. In the initial state, it waits until a packet is received on the WAN side (1201). When received, it is separated for each source and destination IP address (1202). If the packet is a GET request for HTML (1203), the packet is transferred to the server (16) (1204), and shifts to a GET wait state. If it is another request (1251), it is similarly transferred to the server (16) (1252), but it does not prepare for prefetching, and waits for a response from the server (16) (1253). Transfer to (11) (1254) and return to the initial state (1201).

  It waits until a response of GET (1204) for the HTML transferred to the server (16) is received (1205), and when it is received, it transfers it to the client side proxy (15) (1206). At the same time, this response is analyzed to create a file list (1207).

  Next, a prefetch request from the client side proxy (12) is awaited (1208). Reference numerals 1014 and 1015 in FIG. 11 are prefetch requests. Since a plurality of requests are sent continuously, this is repeated until all requests are received (1209). Subsequently, this is sequentially transferred to the server (16) (1210) and waits until a response is received (1211). If at least one response is received, the server side proxy (15) transfers the response to the client side proxy (12) (1212). Note that, as indicated by 1023 to 1028 in FIG. 11, the server-side proxy may transmit a request for another file after receiving a response to the request for one file from the server.

  When a request other than GET is received (1255), the request is similarly transferred to the server (1256), but a response is received from the server (16) (1257) and transferred to the client-side proxy (12). (1258), the process returns to the initial state (1201).

  If a file remains in the file list, the processes after 1210 are repeated (1213). Either all data has been transferred or the prefetched data is discarded due to a timeout and the process returns to the initial state (1201) (1214). The above operation is performed independently for each set of the client (11) and the server (16) in both the client side proxy (12) and the server side proxy (15). The client (11) and server (16) are identified using the IP address in the packet header.

  Since the configuration in the apparatus is the same as that in the first embodiment, it is omitted here.

  FIG. 14 shows a fourth embodiment of the present invention. In this example, when a plurality of clients of the first embodiment download the same folder, the data read by the proxy is held in the buffer and is not deleted by access from one client. The data transfer amount is reduced by holding the data in a buffer for access from the client and transferring the file to a plurality of clients.

  In this example, the client B (11b) is added in the case of the first embodiment, and the download is attempted to the same folder as the client A (11a). Since the sequence of the client A (11a) is the same as that of the first embodiment, the details are omitted.

  The client-side proxy (12) manages the number of clients that are simultaneously accessing each folder by using a value called folder count (1410). When the PROPFIND (201) is received from the client A (11a), the client side proxy (12) updates the folder count (1410) to 1. While this value is 1, the PROPFIND (1401) is transmitted from the client B (11b), and the client side proxy (12) receiving it updates the folder count to 2 (1411). The client side proxy (12) holds a response to PROPFIND and sends it to the client B (11b) (1402). In response, the client (11) issues a GET to the file in the folder (1403). Since the response to this is also held by the client side proxy (12), the client side proxy (12) transmits it as it is. (1404).

  On the other hand, the transfer to the client A (11a) ends with the file 3 (208), and the folder count of the client side proxy (12) becomes 1 (1412).

  The transfer to the client B (11b) continues with the file 2 (1405, 1406) and the file 3 (1407, 1408), and ends. At this time, since the folder count of the client-side proxy (12) is 1, this counter and the files in the folder are deleted and the process is terminated.

  FIG. 15 is a diagram showing the internal configuration of the client side proxy (12). In the present embodiment, a shared data pool (1501) and a folder table (1502) are added to the configuration of the first embodiment. The response data is not stored in the data management table for each client, but is stored in the shared data pool (1501) shared between the clients (11a, 11b). The folder table (1502) is a table showing the number of clients accessing the folder for each folder. Others are the same as FIG.

  FIG. 16 is a diagram showing the internal configuration of the server-side proxy (15). In the present embodiment, a shared data pool (1601) and a folder table (1602) are added to the configuration of the first embodiment. These have the same functions as those of the client side proxy. Others are the same as FIG.

  FIG. 17A shows data management tables (311 to 313) in the data management unit (304) of the client side proxy (12). FIG. 17B shows a data management table (411 to 413) in the data management unit (404) of the server side proxy. The difference from the first embodiment is that there is no response content (352, 452) item because responses are not managed in these tables.

  FIG. 17C shows a data table of the shared data pool (1501, 1601). This has URL (1551), response contents (1552), and information (1553) of the folder to which the file belongs. The folder information may be a simple folder name or a pointer to an entry in a folder table to be described later. This data is shared by all clients (11a, 11b), and even if it is data prefetched by a request from another client, this data is transmitted as a response if it is in this.

  FIG. 17D shows a folder table (1502). This has a folder name (1554) and a counter (1555), and the counter (1555) indicates the number of clients accessing the folder for each folder, and takes a value of 1 or more. When the transfer of all files in the folder is completed, the proxy checks the folder table (1502), and if the value of the counter (1555) is 2 or more, there are other clients accessing the file, Do not delete. On the other hand, if the value of the counter (1555) is 1, there is no other client accessing, so the file is deleted.

  FIG. 18 is a flowchart showing the operation of the client side proxy (12). In the initial state, it waits until a packet is received on the LAN side (1801). When received, the source and destination IP addresses are separated (1802). If the packet is a PROPFIND request (1803), the folder table is counted up (1804). If it is another request (1851), it is similarly transferred to the server-side proxy (15) (1852), but waits for a response from the server-side proxy (15) (1853) and is sent to the client (11). (1854) and return to the initial state (1801).

  If the folder count is 2 or more (1805), since there is data read by another client, the data (response to PROPFIND) is transmitted as a response to the client (11) (1806). If the folder count is 1, the PROPFIND request is transferred to the server-side proxy (15) (1807), and a transition is made to the GET wait state. The system waits until a PROPFIND response transferred to the server-side proxy (15) is received (1808), and when received, transfers it to the client (11) (1809). At the same time, this response is analyzed to create a file list (1810).

  Next, it waits for a GET request from the client (1811). When a request other than GET is received (1855), the request is similarly transferred to the server side proxy (15) (556), but a response is received from the WAN side (557), and then it is sent to the client (11). Transfer (558) and return to the initial state (501).

  When GET is received, the folder count is referred to (1812), and if it is 2 or more, since there is data read by another client, the data is transmitted as a response to the client (1813). This is repeated until all the files in the folder have been transferred or timed out (1814), and when completed, the folder count is counted down (1815).

  If the folder count is 1, the request is transferred to the server-side proxy (15) (1816), waits until a response is received (1817), and if received, transferred to the client (11) ( 1817), it waits for prefetch data from the server side proxy (15) (1818). When prefetch data is received from the server side proxy (15) (1818), it is stored in the data management unit (304) (1820), and a request from the client is awaited (1821). When the request is received, the stored data is transmitted as a response to the client (1822).

  If a file remains in the file list, 512 and the subsequent steps are repeated (1823). When all the data has been transferred or the folder count is counted down due to a timeout, the process returns to the initial state (1801) (1824).

  FIG. 19 is a flowchart showing the operation of the server side proxy (15). In the initial state, it waits until a packet is received on the WAN side (1901). When received, the source and destination IP addresses are separated (1902). If the packet is a PROPFIND request (1903), the folder table is counted up (1904). If it is another request (1951), it is similarly transferred to the server (16) (1952), but waits to receive a response from the server (16) (1953) and forwards it to the client side proxy (12). (1954), the process returns to the initial state (1901).

  If the folder count is 2 or more (1905), since there is data read by another client, the data (response to PROPFIND) is sent as a response to the client side proxy (12) (1906). If the folder count is 1, the PROPFIND request is transferred to the server (16) (1907), and a transition is made to the GET wait state. The system waits until a PROPFIND response transferred to the server (16) is received (1908), and when received, transfers it to the client-side proxy (12) (1909). At the same time, this response is analyzed to create a file list (1910).

  Next, a GET request from the client side proxy (12) is awaited (1911). If a request other than GET is received (1955), the request is similarly transferred to the server (1956), but a response is received from the server (16) (1957) and transferred to the client-side proxy (12). (1958), the process returns to the initial state (1901).

  When GET is received, the folder count is referred to (1912), and if it is 2 or more, data read by another client exists, so that data is transmitted as a response to the client side proxy (12) (1913). This is repeated until all the files in the folder have been transferred or timed out (1914), and when completed, the folder count is counted down (1915).

  If the folder count is 1, the request is transferred to the server (16) (1916), and the system waits until a response is received (1917). If it is received, it is transferred to the client side proxy (12) (1918), and a prefetch request for the next file is transmitted (1919). When prefetch data is received from the server (16) (1920), it is transmitted to the client side proxy (1921). If a file remains in the file list, steps 1919 and after are repeated (1922). Either all the data has been transferred or the prefetched data is discarded due to a timeout and the process returns to the initial state (1901) (1923).

  According to the above-described embodiment, it is possible to efficiently transfer a plurality of files from the server according to the usage status of the client by communication according to HTTP or WebDAV.

Claims (15)

In a system including a client-side proxy connected to a client and a server-side proxy connected to a server, the communication method relays communication between the client and the server,
In a communication method in a format in which the server transmits a response to a request from the client between the client and the server,
A response including a list of a plurality of files acquired by the first request transmitted from the client is transmitted to the client;
If a second request related to the list is received from the client,
Without waiting for a request from the client, a request for acquiring a plurality of files corresponding to the list is sent to the server,
A communication method, comprising: prefetching an entity of the plurality of files corresponding to the list of the plurality of files from the server as a response to the request for acquiring the plurality of files. The communication method according to claim 1, comprising:
The prefetch is performed by the server side proxy,
The server side proxy
Sending the multiple file acquisition request to the server, sending the entity of the multiple files as a response to the multiple file acquisition request to the client side proxy,
The client-side proxy receives an entity of the plurality of files that is a response from the server-side proxy and receives a request for acquiring one of the plurality of files from the client, and corresponds as a response And transmitting one of the plurality of files to the client. The communication method according to claim 2,
In the client side proxy, after receiving the second request from the client, when receiving a third or later file acquisition request for one file in the multiple file list from the client,
When the prefetch result of the file requested in the third and subsequent file acquisition requests is not received from the server-side proxy, the third and subsequent file acquisition requests are transferred to the server-side proxy. Communication method. The communication method according to claim 3, wherein
In the server side proxy, after receiving the second request from the client side proxy,
When the server-side proxy receives the third and subsequent file acquisition requests from the client-side proxy, the server-side proxy may not send a request that matches the third and subsequent file acquisition requests to the server. For example, a request for a file that does not match the third and subsequent file acquisition requests in the multiple file list is sent to the server with priority
A communication method, comprising: transferring a file entity to the client-side proxy when a file entity is received from the server as a response to the preferentially transmitted request. The communication method according to claim 1, wherein prefetching is performed by the client side proxy,
The client side proxy sends the multiple file acquisition request,
The server-side proxy transfers the multiple file acquisition request to the server, receives a plurality of file entities as a response from the server, and transfers the plurality of file entities to the client-side proxy,
The client-side proxy receives an entity of the plurality of files that is a response from the server-side proxy and receives a request for acquiring one of the plurality of files from the client, and corresponds as a response And transmitting one of the plurality of files to the client. The communication method according to claim 5, comprising:
When the client-side proxy transmits the multiple file acquisition request, if the client-side proxy transmits an acquisition request for a certain file, the client-side proxy acquires the next file before receiving the file entity as a response to the acquisition request for the certain file. A communication method characterized by transmitting a request. The communication method according to claim 1, comprising:
The prefetch is performed by the client side proxy,
The client side proxy sends the multiple file acquisition request,
The server side proxy sends a prefetch request for the plurality of files to the server triggered by the multiple file acquisition request from the client side proxy,
Receiving a plurality of file entities as a response from the server, transferring the plurality of file entities to the client side proxy,
The client-side proxy receives an entity of the plurality of files that is a response from the server-side proxy and receives a request for acquiring one of the plurality of files from the client, and corresponds as a response And transmitting one of the plurality of files to the client.   The communication method according to claim 1, wherein the prefetching of the plurality of files is performed on a plurality of files described in a response to the first request. The communication method according to claim 1, comprising:
The client side proxy is connected to a plurality of clients,
The client-side proxy stores a response including the plurality of file lists or a response that is the file entity for a client request,
When the client-side proxy receives a request from another client for the same file requested by the client,
A communication method, wherein the stored response is reused and transmitted to the other client. A communication method according to claim 1, wherein requests from a plurality of clients are processed.
A response including the multiple file list for a request from a client or a response that is the file entity is temporarily stored in the server-side proxy,
When the server-side proxy receives a request for the same file as that requested by the client from another client,
A communication method, wherein the response stored in the other client is reused and transmitted. The communication method according to claim 1, comprising:
The client-side proxy and the server-side proxy are communication conforming to WebDAV, the first request is PROPFIND, and the list of the plurality of files is a URL indicating the location of the file, and is “207 MultiStatus”. , And the second request is a GET request for requesting acquisition of the entity of the file. The communication method according to claim 1, comprising:
The client-side proxy and the server-side proxy are communication in accordance with the HTTP protocol, and the first request is a GET request for an HTML file, and the list of the plurality of files is included in a response “200 OK”.
A communication method, wherein the second request is a GET request for requesting acquisition of an entity of the file. A proxy system that controls communication of data stored in a server between a client device and a server device,
A client communication unit that communicates with the client;
A server communication unit that communicates with the server;
When receiving an acquisition request for at least any one of the plurality of information included in the response to the first request from the client, the acquisition request for the plurality of information included in the response is received. To the server,
A proxy system comprising: a transmission control unit configured to transmit a response to the plurality of information acquisition requests from the server when the response is received from the server. The proxy system according to claim 13,
The communication control unit includes a buffer, and in accordance with the WebDAV protocol, based on a response from the server to the PROPFIND that is the first request transmitted from the client, a URL of a file included in the specified folder is obtained. When a request for acquiring any one of the files included in the folder is received from the client, the other files are also prefetched from the server, and are prefetched according to the request for acquiring the other files from the client. A proxy system, wherein the file is stored in the buffer and the file is transmitted to the client. 15. The proxy system according to claim 14, wherein
When the communication control unit receives PROPFIND from a plurality of clients and receives a file acquisition request from the plurality of clients, the communication control unit transmits a prefetched file to each of the plurality of clients, and deletes the file from the buffer. A proxy system characterized by that.

Images