JP5948111B2 - Packet communication apparatus and method - Google Patents
Packet communication apparatus and method Download PDFInfo
- Publication number
- JP5948111B2 JP5948111B2 JP2012085993A JP2012085993A JP5948111B2 JP 5948111 B2 JP5948111 B2 JP 5948111B2 JP 2012085993 A JP2012085993 A JP 2012085993A JP 2012085993 A JP2012085993 A JP 2012085993A JP 5948111 B2 JP5948111 B2 JP 5948111B2
- Authority
- JP
- Japan
- Prior art keywords
- client
- request
- server
- file
- side proxy
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
Description
本発明は、パケット通信装置および方法に関する。 The present invention relates to a packet communication apparatus and method.
ウェブシステムにおいて、クライアント側で、サーバからの情報を表示しようとする場合、クライアントサーバ間で、ウェブブラウザはHTMLを解析し、オブジェクトを発見するたびにそのオブジェクトに対するGETリクエストをサーバに送信する。通常ブラウザから一つのサーバへの同時接続数は制限されているため、ウェブページの読み込みにはクライアント・サーバ間の往復が多数回行われることとなる。 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.
クライアントとサーバが大陸間海底ケーブルなどの遅延の大きなワイドエリアネットワーク (Wide Area Network: WAN)により接続されている場合、ハイパーテキスト転送プロトコル (Hyper Text Transfer Protocol: HTTP)による通信は、効率が著しく低下する。遅延の大きなネットワークでは、クライアントがリクエストを送信してからサーバからレスポンスが返ってくるまで長い時間がかかり、クライアントはその間待機する必要を生じる。これが多数回行われるためウェブページをリクエストしてから表示が完了するまでの時間が長くなる。 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
また、ＨＴＴＰ方式を拡張して、サーバ上のファイルを容易に編集可能としたWebDAV (Web Distributed Authoring and Versioning) という方式がある（非特許文献１）。WebDAVではサーバ上のファイルやフォルダをWebDAVクライアント経由で操作可能である。WebDAVでもHTTPと同様のリクエストが用いられるほか、フォルダ内のファイルに関するプロパティ情報を取得するためのPROPFINDというリクエストが用いられる。 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.
しかしながら、ＷｅｂＤＡＶではＨＴＴＰと異なり、ファイルが基本コンポーネントとそれに付随するインラインオブジェクトのような主従関係になっておらず、特許文献１の技術を適用しても、ファイルの関係性を見出すことができないため先読みすることはできない。
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, and even if the technique of
そこで、本発明では、WebDAVをWAN経由で利用する場合に、適切なファイル一覧の取得方法を実現することを、一目的とする。 Therefore, an object of the present invention is to realize an appropriate file list acquisition method when WebDAV is used over a WAN.
また、WebDAVではファイル一覧の情報を取得したとしても、次のリクエストが判明しないとそれらのファイルを転送するべきか否かを断定できないため、ファイルの転送が不要な場合にもファイルの転送を行ってしまう。そこで本発明では、必要な場合のみに複数のファイルを効率的に転送することを他の目的とする。また、WebDAVを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.
図２は本実施例におけるネットワーク構成を表す図である。 FIG. 2 is a diagram illustrating a network configuration in the present embodiment.
クライアント（１１）と同一のLAN（１３）内にクライアント側プロキシ（１２）を設置し、クライアント側プロキシ（１２）がWAN（１４）との通信を行う。同様に、サーバ（１６）と同一のLAN（１７）内にサーバ側プロキシ（１５）を設置し、サーバ側プロキシ（１５）がWANとの通信を行う。クライアント側プロキシ（１２）とサーバ側プロキシ（１５）が協調して動作することにより、ＬＡＮに比べて遅延の大きなWANでも性能劣化を抑えて通信を行うことを可能とする。 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.
クライアントがサーバ上のフォルダにアクセスする際、まず、クライアントは、そのフォルダに対してPROPFINDというリクエスト（１０１）を発行する。このリクエストは、クライアント側プロキシ（１２）で受信され、サーバ側プロキシ（１５）へとWANを介してを転送される（１１１）。 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).
サーバ側プロキシ（１５）は、PROPFINDを受信すると、サーバ（１６）へさらに転送する（１２１）。PROPFINDを受信したサーバ（１６）はそれに対するレスポンスを生成し、クライアントに向けてＷＡＮ側へ返送する（１２２）。このレスポンスにはフォルダ内のファイル一覧が含まれる。同レスポンスはサーバ側プロキシ（１５）でクライアント側プロキシ（１２）へ転送され（１１２）、サーバ側プロキシ（１５）は、ＰＲＯＰＦＩＮＤに対するレスポンスを解析し、フォルダ内のファイル一覧を取得する。さらにクライアント側プロキシ（１２）でクライアント（１１）へ転送される（１０２）。クライアント側プロキシ（１２）でも同様にこのレスポンスを解析し、ファイル一覧を取得する。クライアント（１１）はクライアント側プロキシ（１２）およびサーバ側プロキシ（１５）とは、別にこのレスポンスを解析してファイル一覧を取得する。 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
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。 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-
図３はクライアント側プロキシ（１２）の内部構成を表す図である。サーバ側プロキシ（１２）は、クライアント１１とサーバ１６の間の通信を仲介し、パケットを送受信する通信装置であって、クライアント１１とＷＡＮの間にあるのが一例である。または、クライアント側の局所ネットワークのゲートウェイ装置であってもよい。クライアントは、例えば情報処理装置、無線情報処理端末である。局所ネットワークは、有線、無線少なくともいずれかで構成されてもよい。
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
LAN側コネクション管理部（３０１）はクライアント（１１）との通信を行う。クライアント（１１）からのリクエストはリクエスト判定部（３０２）にて、リクエストを送信したクライアント（１１）が識別される。また、そのリクエストがPROPFINDやGETなど、プリフェッチ動作の契機となるものかどうかが判定される。 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).
データ管理部（３０４）はIPアドレスで識別されるクライアント（１１）ごとにテーブルを持ち、リクエスト・レスポンスの状態とそのデータを管理する。例えばクライアントが３台あれば３つのテーブル（３１１〜３１３）を持つ。リクエストを受信すればそのパス名をキーとしてテーブルを検索して、リクエスト受信済みのフラグを立てる。またプリフェッチされたレスポンスを受信すればレスポンス受信済みのフラグを立てる。テーブルのエントリは定期的に調べられ、リクエスト受信済みかつレスポンス受信済みであれば、レスポンスをレスポンス送信部（３０３）を介して、クライアントへ送信する。リクエスト受信時にレスポンスが登録されていなければ、リクエストをリクエスト送信部（３０５）を介してサーバ側プロキシ（１５）へ送信してもよい。 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).
リクエスト送信部（３０５）は、リクエスト判定部（３０２）またはデータ管理部（３０４）から受け取ったリクエストをWAN側コネクション管理部（３０７）を用いて送信する。 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).
WAN側コネクション管理部（３０７）は、WANを通じてサーバ側プロキシ（１５）との通信の制御を行う。 The WAN side connection management unit (307) controls communication with the server side proxy (15) through the WAN.
レスポンス解析部（３０６）ではサーバ側プロキシ（１５）から受信したレスポンスのIPアドレスを解析して、どのクライアント（１１）に対するものであるか判断する。また、PROPFINDに対するレスポンスであればその内容も解析しファイル一覧を取得してデータ管理部（３０４）に登録する。同時にレスポンス送信部（３０３）に渡してクライアント（１１）へ転送する。GETに対するレスポンスであればデータ管理部（３０４）に登録する。 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).
レスポンス送信部（３０３）ではレスポンス解析部（３０６）またはデータ管理部（３０４）から受信したレスポンスデータをLAN側コネクション管理部（３０１）に渡してクライアント（１１）へ転送する。 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).
図４はサーバ側プロキシ（１５）の内部構成を表す図である。サーバ側プロキシ（１５）は、クライアントとサーバの間の通信を仲介し、パケットを送受信する通信装置であって、サーバとＷＡＮの間にあるのが一例である。または、サーバ側の局所ネットワークのゲートウェイ装置であってもよい。サーバは、例えば情報処理装置である。サーバ側の局所ネットワークは、有線、無線少なくともいずれかで構成されてもよい。WAN側コネクション管理部（４０１）はクライアント側プロキシ（１２）との通信を行う。 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).
クライアント側プロキシからのリクエストはリクエスト判定部（４０２）にて、リクエストを送信したクライアント（１１）が識別される。また、そのリクエストがPROPFINDやGETなど、プリフェッチ動作の契機となるものかどうかが判定される。 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).
データ管理部（４０４）は、クライアント側プロキシ（１２）と同様にクライアント（１１）ごとにデータ管理テーブルを持ち、リクエスト・レスポンスの状態とそのデータを管理する。例えばクライアント（１１）が３台あれば３つのテーブル（４１１〜４１３）を持つ。プリフェッチ動作中は、テーブルは定期的に調べられ、プリフェッチ未了のエントリがあればプリフェッチを行うため、リクエスト送信部（４０５）へURLを渡す。クライアント側プロキシ（１２）からリクエストを受信した場合、該当レスポンスを送信していなければ、そのリクエストを優先的にリクエスト送信部（４０５）へ渡し、サーバ（１６）へ送信する。 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).
リクエスト送信部（４０５）は、リクエスト判定部（４０２）またはデータ管理部（４０４）から受け取ったリクエストをLAN側コネクション管理部（４０７）を用いて送信する。LAN側コネクション管理部（４０６）は、サーバ側プロキシ（１５）とサーバ（１６）との通信を制御する。 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).
レスポンス解析部（４０６）ではサーバ（１５）から受信したPROPFINDに対するレスポンスを解析しファイル一覧を取得してデータ管理部（４０４）に登録する。同時にレスポンス送信部（４０３）を介してクライアント（１６）へ転送する。またレスポンスがGETに対するレスポンスであればデータ管理部（４０４）に登録する。 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).
レスポンス送信部（４０３）は、レスポンス解析部（４０６）またはデータ管理部（４０４）から受信したレスポンスデータをWAN側コネクション管理部（４０１）を介してクライアント側プロキシ（１２）へ転送する。 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).
図５は、(a)クライアント側プロキシおよび(b)サーバ側プロキシのデータ管理部における、データ管理テーブル（３１１，４１１）を示す。クライアント側プロキシのデータ管理テーブル（３１１）は対象となるファイルごとに、ファイルのURL（３５１）、プリフェッチしたレスポンス（３５２）、および1または0の値をとる3種類のフラグを持っている。フラグは「クライアントからリクエスト受信済み（３５３）」、「サーバ側プロキシからレスポンス受信済み（３５４）」、「クライアントにレスポンス送信済み（３５５）」である。 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)”.
「クライアントからリクエスト受信済み（３５３）」フラグは、そのファイルに対するリクエストをクライアントから受信したとき1に設定される。フラグの値は、０，１以外であっても、クライアントからのリクエストが受信されたかか否かを、識別できる値を用いてもよい。 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.
「サーバ側プロキシからレスポンス受信済み（３５４）」フラグはそのファイルをサーバ側プロキシから受信したとき1に設定される。フラグの値は、１以外であっても、サーバ側プロキシからレスポンスが受信されたかか否かを、識別できる値を用いてもよい。これらのフラグの両方が1となっていれば、レスポンスはクライアント側プロキシからクライアントへ送信され、「クライアントにレスポンス送信済み（３５５）」フラグが1に設定される。「クライアントにレスポンス送信済み（３５５）」フラグが1であれば該当エントリは削除される。 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.
サーバ側プロキシのデータ管理テーブルは対象となるファイルごとに、ファイルのURL（４５１）、プリフェッチしたレスポンス（４５２）、および1または0の値をとる3種類のフラグを持っている。フラグは「サーバにプリフェッチリクエスト送信済み（４５３）」、「クライアント側プロキシからリクエスト受信済み（４５４）」、「サーバからレスポンス受信済み（４５６）」である。 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)”.
「サーバにプリフェッチリクエスト送信済み（４５３）」フラグは、そのファイルに対するリクエストをサーバに送信したとき1に設定される。フラグの値は、０，１以外であっても、サーバにプリフェッチリクエストが送信されたかか否かを、識別できる値を用いてもよい。「クライアント側プロキシからリクエスト受信済み（４５４）」フラグはクライアント側プロキシからリクエストを受信したときに1に設定される。「サーバからレスポンス受信済み（４５５）」フラグはサーバからレスポンスを受信したときに1に設定される。このフラグが1のときにレスポンスはクライアント側プロキシに送信され、エントリが削除される。 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.
図６はクライアント側プロキシ（１２）の動作を表すフローチャートである。初期状態ではLAN側でパケットを受信するまで待機する（５０１）。クライアント側プロキシ（１２）は、ＬＡＮ側でパケットを受信すると、送信元および宛先IPアドレスごとに分離する（５０２）。そのパケットがPROPFINDリクエストであれば（５０３）、クライアント側プロキシ（１２）は、サーバ側プロキシへ転送して（５０４）、GET待ち状態へ移行する。その他のリクエストであれば（５５１）、同様にサーバ側プロキシへ転送する（５５２）が、プリフェッチの準備は行わず、サーバ側プロキシ（１５）からレスポンスを受信するのを待って（５５３）それをクライアント（１１）へ転送し（５５４）、初期状態（５０１）へ戻る。 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).
サーバ側プロキシへ転送したPROPFIND（５０４）のレスポンスが受信されるまで、クライアント側プロキシ（１２）は、当該ＰＲＯＰＦＩＮＤ（５０４）に関する処理を待機する（５０５）。ＰＲＯＰＦＩＮＤ（５０４）のレスポンスが受信されると、クライアント側プロキシ（１２）は、そのレスポンスをクライアント（１１）へ転送する（５０６）。また、クライアント側プロキシ（１２）は、このレスポンスを解析してファイル一覧を作成し、データ管理部（４０４）に登録する（５０７）。 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).
続いて、クライアント側プロキシ（１２）は、クライアントからのGETリクエストを待ちうける（５０８）。GETを受信すると、クライアント側プロキシ（１２）は、これをサーバ側プロキシ（１５）へ転送し（５０９）、ＧＥＴリクエストに対するレスポンスを受信するまで待機する（５１０）。クライアント側プロキシ（１２）は、受信されればクライアント（１１）へ転送（５１１）し、サーバ側プロキシ（１５）からのプリフェッチデータを待ちうける（５１２）。GET以外のリクエストを受信した場合（５５５）は、同様にサーバ側プロキシ（１５）へ転送する（５５６）が、WAN側からレスポンスを受信するのを待って（５５７）それをクライアント（１１）へ転送し（５５８）、初期状態（５０１）へ戻る。 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).
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。 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.
図７は、サーバ側プロキシ（１５）の動作を表すフローチャートである。初期状態ではWAN側でパケットを受信するまで待機する（６０１）。サーバ側プロキシ（１５）は、受信すると送信元および宛先IPアドレスごとに分離する（６０２）。そのパケットがPROPFINDリクエストであれば（６０３）、サーバ側プロキシ（１５）は、サーバ（１６）へ転送して（６０４）GET待ち状態へ移行する。その他のリクエストであれば（６５１）、サーバ側プロキシ（１５）は、サーバ（１６）へ転送する（６５２）が、プリフェッチの準備は行わず、サーバ側プロキシ（１５）は、サーバ（１６）からレスポンスを受信するのを待って（６５３）それをクライアント（１１）側へ転送し（６５４）、初期状態（６０１）へ戻る。 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).
一方、サーバ側プロキシ（１５）は、ステップ６０３の後、サーバ（１６）へ転送したPROPFIND（６０４）のレスポンスが受信されるまで待機し（６０５）受信されるとクライアント側プロキシ（１５）へ転送する（６０６）。また、サーバ側プロキシ（１５）は、ＰＲＯＰＦＩＮＤ（６０４）に対するレスポンスを解析してファイル一覧を作成し、データ管理部（４０４）に登録する（６０７）。 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).
続いてクライアント側プロキシ（１２）からのGETリクエストを待ちうける（６０８）。GETを受信すると、サーバ側プロキシ（１５）は、これをサーバ（１６）へ転送し（６０９）、それに対するレスポンスを受信するまで待機する（６１０）。受信されればクライアント側プロキシ（１２）へ転送し（６１１）、データ管理部（４０４）に登録されているファイル一覧に従って、次のファイルに対するプリフェッチリクエストを送信する（６１２）。GET以外のリクエストを受信した場合（６５５）は、サーバ側プロキシ（１５）は、にサーバへ転送する（６５６）が、サーバ（１６）からレスポンスを受信するのを待って（６５７）それをクライアント側プロキシ（１２）へ転送し（６５８）、初期状態（６０１）へ戻る。 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).
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。 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.
本発明の第二の実施例における通信シーケンスを図８に示す。図８では通信にかかわる、クライアント（１１）、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）、およびサーバ（１６）のシーケンスを示している。本実施例の方式により、実施例１の場合と比べて同等の通信効率を保ちながら、WAN上の通信をWebDAVの標準プロトコルにのっとったものとする。それによりWAN上の通信がファイアウォール、Intrusion Detection System/Intrusion Protection System、Deep Packet Inspectionなどのセキュリティシステムにより、異常な通信であると判断されて遮断されることを防ぐことができる。 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.
手順７０１、７０２、７１１、７１２、７２１、７２２は、図１の手順１０１、１０２、１１１、１１２、１２１、１２２と同様にＰＲＯＰＦＩＮＤのリクエストとそのレスポンスと同様である。
ファイル一覧を取得したクライアント（１１）は、各ファイルに対して順にリクエストを送信する。クライアント（１１）から送信された最初のファイルに対するリクエスト（７０３）は、クライアント側プロキシ（１２）によって受信される。クライアント側プロキシ（１２）は、このリクエストを解析して、ＰＲＯＰＦＩＮＤリクエストに対するレスポンスであるファイル一覧中に含まれるファイル（ファイル１）であると判断すると、このリクエストをサーバ側プロキシ（１５）へ転送する（７１３）。さらに、クライアント側プロキシ（１２）は、クライアントからのリクエスト（７０７）で指定されるファイル（ファイル１）ではないが、ファイル一覧にある他のファイル（ファイル２、３）に対するリクエスト（７１４、７１５）も発行する。これらのリクエストは前のリクエストに対するレスポンスを待つことなくサーバ側プロキシ（１５）へ送信される（７１４，７１５）。
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 (
サーバ側プロキシ（１５）は、クライアント側プロキシ（１２）からのリクエストを受信（７１３）すると、ファイル一覧中のファイルで、クライアントからの最初のリクエストで指定されたファイル（ファイル１）に対するリクエストを、クライアント（１１）に代わってサーバ（１６）に送信する（７２３）。サーバ（１６）は、これに対するレスポンスとしてファイル１を送信する（７２４）。これを受信したサーバ側プロキシ（１５）は、このファイルをクライアント側プロキシ（１２）へ転送（７１６）する。
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
また、サーバ側プロキシ（１５）は、サーバ（１６）からのファイル１の受信に応じて、受信したファイル１が含まれるファイル一覧に次のファイル（ファイル２）があればそれに対するリクエストを送信する（７２５）。サーバ側プロキシ（１５）が同リクエストに対するレスポンスを受信（７２６）すると、これをクライアント側プロキシ（１２）へ転送する（７１７）。さらに、次のファイルも、ステップ７２５、７２６、７１７と同様にプリフェッチを行うと（７２７，７２８，７１８）、サーバ側プロキシ（１５）は、ファイル一覧に次のファイルがない場合、ファイル一覧を破棄して動作を完了する。このリクエストは前のリクエストに対するレスポンスを受信してから開始してもよいし、複数のリクエストを同時に送信してもよい。
Further, in response to the reception of the
クライアント側プロキシ（１２）は、ファイル１のレスポンスを受信（７１６）すると、これをクライアント（１１）へ転送する（７０４）。クライアント（１１）はファイル２に対するリクエストを送信する（７０５）。一方でファイル２のレスポンスは、サーバ側プロキシ（１５）より受信される（７１７）ので、ファイル２に対するリクエストとレスポンスがそろった段階で、クライアント（１１）に対してレスポンスを送信する（７０６）。同様の動作をファイル一覧中の全てのファイルに対して繰り返し（７１８，７０７，７０８）、ファイル一覧を破棄して動作を完了する。
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
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。 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
続いてクライアントからのGETリクエストを待ちうける（８０８）。クライアント側プロキシ（１２）は、GETリクエストを受信するとこれを契機にファイル一覧中のファイルに対してプリフェッチリクエストを発行する（８０９）。このリクエストは前のリクエストに対するレスポンスを待たずに送信される。ファイル一覧中の全てのファイルに対してリクエストを送信するまでこれを繰り返す（８１０）。GET以外のリクエストを受信した場合（８５５）は、同様にサーバ側プロキシ（１５）へ転送する（８５６）が、WAN側からレスポンスを受信するのを待って（８５７）それをクライアント（１１）へ転送し（８５８）、初期状態（８０１）へ戻る。 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).
ファイル一覧にファイルが残っていれば、８１２以降を繰り返す（８１７）。すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（８０１）に戻る（８１８）。上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。 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.
図１０は第二の実施例におけるサーバ側プロキシ（１５）の動作を表すフローチャートである。ステップ９０１ないし９０７、９５１ないし９５４は、図７のステップ６０１ないし６０７、６５１ないし６５４と同様である。 続いてクライアント側プロキシ（１２）からのプリフェッチリクエストを待ちうける（９０８）。プリフェッチリクエストは、ファイル一覧に含まれるファイルの数に対応して複数送られるため、サーバ側プロキシ（１５）は、ファイル一覧に含まれるファイルの数に対応する全てのリクエストを受信するまでこれを繰り返す（９０９）。続いて、プリフェッチリクエストを順次サーバ（１６）へ転送し（９１０）、それに対するレスポンスを受信するまで待機する（９１１）。サーバ側プロキシ（１５）は、レスポンスが受信されればクライアント側プロキシ（１２）へ、それらを転送する（９１２）。GET以外のリクエストを受信した場合（９５５）は、サーバ側プロキシ（１５）は、同様にサーバ（１６）へ転送する（９５６）が、サーバ側プロキシ（１５）は、サーバ（１６）からGET以外のリクエストに対応するレスポンスを受信するのを待って（９５７）それをクライアント側プロキシ（１２）へ転送し（９５８）、初期状態（９０１）へ戻る。
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
ファイル一覧にサーバから取得していないファイルが残っていれば、９１０以降を繰り返す（９１３）。すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（９０１）に戻る（９１４）。上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。 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.
以上の実施例２の説明により、ＷｅｂＤＡＶに従った通信により得られた情報を用いて、プリフェッチするリクエストとレスポンスとを対応づけ、プロキシ間での通信制御を行うことを説明した。その制御により、WAN上の通信がファイアウォール、Intrusion Detection System/Intrusion Protection System、Deep Packet Inspectionなどのセキュリティシステムにより、プリフェッチするための通信が、異常な通信であると判断されて遮断されることを防ぐことができる。 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.
本発明の第三の実施例における通信シーケンスを図１１に示す。この例では実施例２の方式をHTTPに適用している。本実施例の方式により、実施例２の場合と同様に、WAN上の通信はHTTPの標準にのっとったものとなるため、セキュリティシステムにより異常な通信として判断され遮断されることを防ぐことができる。 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. .
クライアントが、サーバからウェブページを読み込む場合、まずHTMLファイルに対してGETというリクエスト（１００１）を発行する。これはクライアント側プロキシ（１２）で受信され、サーバ側プロキシ（１５）へとWAN上を転送される（１０１１）。サーバ側プロキシ（１５）はこれを受信すると、サーバ（１６）へさらに転送する（１０２１）。HTMLに対するGETを受信したサーバ（１６）は、そのHTMLファイルをクライアントへ返送する（１０２２）。このレスポンス（１０２２）は、ＨＴＴＰに従った「２００ ＯＫ」というレスポンスであり、フォルダ内のファイル一覧が含まれる。同レスポンスはサーバ側プロキシ（１５）でクライアント側プロキシ（１２）へ転送され（１０１２）、サーバ側プロキシ（１５）は、このレスポンスを解析することによりフォルダ内のファイル一覧を取得する。さらにクライアント側プロキシ（１２）でクライアント（１１）へ転送される（１００２）。クライアント側プロキシ（１２）でも同様にこのレスポンスを解析し、ファイル一覧を取得する。クライアント（１１）はクライアント側プロキシ（１２）およびサーバ側プロキシ（１５）とは、独立してこのレスポンスを解析してファイル一覧を取得する。 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).
クライアント側プロキシ（１２）は、このリクエストを解析して、ファイル一覧中に含まれるファイルであると判断すると、このリクエストをサーバ側プロキシ（１５）へ転送する（１０１３）。クライアント１１からのリクエストで指定されるファイルが「２００ ＯＫ」のレスポンス（１０１２）で取得したファイル一覧中に含まれるファイル（file 1）であると、クライアント側プロキシ（１２）が判断すると、そのファイル一覧の他のファイル(file2, 3)に対するリクエストも発行する。これらのリクエストは前のリクエストに対するレスポンスを待つことなくサーバ側プロキシ（１５）へ送信される（１０１４，１０１５）。つまり、クライアントからファイル一覧に含まれる一のファイルを指定するリクエストがくると、クライアント側プロキシ（１２）は、ファイル一覧に含まれる他のファイルについてのリクエストも、クライアント（１１）からのリクエストを待つことなく、サーバ側プロキシ（１５）にプリフェッチリクエスト（１０１４、１０１５）を発行する。
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
サーバ側プロキシ（１５）は、クライアント側プロキシ（１２）からのリクエストを受信（１０１３）すると、ファイル一覧中のファイルに対するリクエストを、クライアント（１１）に代わってサーバ（１６）に送信する（１０２３）。サーバ（１６）はこれに対するレスポンスとしてファイルを送信する（１０２４）。 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
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。 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.
図１２は、実施例３におけるクライアント側プロキシ（１２）の動作を表すフローチャートである。初期状態ではLAN側でパケットを受信するまで待機する（１１０１）。受信すると送信元および宛先IPアドレスごとに分離する（１１０２）。そのパケットがHTMLに対するGETリクエストであれば（１１０３）サーバ側プロキシへ転送して（１１０４）GET待ち状態へ移行する。その他のリクエストであれば（１１５１）、同様にサーバ側プロキシ（１５）へ転送する（１１５２）が、プリフェッチの準備は行わず、サーバ側プロキシ（１５）からレスポンスを受信するのを待って（１１５３）それをクライアント（１１）へ転送し（１１５４）、初期状態（１１０１）へ戻る。 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).
サーバ側プロキシへ転送したHTMLに対するGET（１１０４）のレスポンスが受信されるまで待機し（１１０５）受信されるとクライアント（１１）へ転送する（１１０６）。同時にこのレスポンスを解析してファイル一覧を作成し、データ管理部（３０４）に登録する（１１０７）。 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).
続いてクライアントからのGETリクエストを待ちうける（１１０８）。ファイル一覧に含まれるファイルに対するGETリクエストを受信すると、クライアント側プロキシは、これを契機にファイル一覧中のファイルに対してプリフェッチリクエストを発行する（１１０９）。これらのリクエストは前のリクエストに対するレスポンスを待たずに送信される。また、クライアントからのＧＥＴリクエストで指定されるファイルだけでなく、ＧＥＴリクエストで特定されるファイル一覧に含まれるファイルに対してリクエストを送信するまでこれを繰り返す（１１１０）。GET以外のリクエストを受信した場合（１１５５）は、同様にサーバ側プロキシ（１５）へ転送する（１１５６）が、WAN側からレスポンスを受信するのを待って（１１５７）それをクライアント（１１）へ転送し（１１５８）、初期状態（１１０１）へ戻る。 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).
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。 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.
図１３は、実施例３におけるサーバ側プロキシ（１５）の動作を表すフローチャートである。初期状態ではWAN側でパケットを受信するまで待機する（１２０１）。受信すると送信元および宛先IPアドレスごとに分離する（１２０２）。そのパケットがHTMLに対するGETリクエストであれば（１２０３）サーバ（１６）へ転送して（１２０４）GET待ち状態へ移行する。その他のリクエストであれば（１２５１）、同様にサーバ（１６）へ転送する（１２５２）が、プリフェッチの準備は行わず、サーバ（１６）からレスポンスを受信するのを待って（１２５３）それをクライアント（１１）へ転送し（１２５４）、初期状態（１２０１）へ戻る。 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).
サーバ（１６）へ転送したHTMLに対するGET（１２０４）のレスポンスが受信されるまで待機し（１２０５）受信されるとクライアント側プロキシ（１５）へ転送する（１２０６）。同時にこのレスポンスを解析してファイル一覧を作成する（１２０７）。 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).
GET以外のリクエストを受信した場合（１２５５）は、同様にサーバへ転送する（１２５６）が、サーバ（１６）からレスポンスを受信するのを待って（１２５７）それをクライアント側プロキシ（１２）へ転送し（１２５８）、初期状態（１２０１）へ戻る。 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).
ファイル一覧にファイルが残っていれば、１２１０以降を繰り返す（１２１３）。すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（１２０１）に戻る（１２１４）。 上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。 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.
クライアント側プロキシ（１２）では、フォルダカウント（１４１０）という値を用いてフォルダごとの同時アクセスしているクライアント数を管理する。クライアントＡ（１１ａ）からのPROPFIND（２０１）を受信すると、クライアント側プロキシ（１２）は、フォルダカウント（１４１０）を1に更新する。この値が1である間にクライアントＢ（１１ｂ）からPROPFIND（１４０１）が送信され、これを受信したクライアント側プロキシ（１２）は、フォルダカウントを2に更新する（１４１１）。クライアント側プロキシ（１２）は、PROPFINDに対するレスポンスを保持し、これをクライアントＢ（１１ｂ）に送信する（１４０２）。これを受けて、クライアント（１１）がフォルダ内のファイルに対してGETを発行する（１４０３）。これに対するレスポンスもクライアント側プロキシ（１２）が保持しているため、クライアント側プロキシ（１２）はそれをそのまま送信する。（１４０４）。 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).
一方でクライアントA（１１ａ）への転送はファイル3にて終了し（２０８）、クライアント側プロキシ（１２）のフォルダカウントは1となる（１４１２）。 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).
クライアントB（１１ｂ）への転送はファイル2（１４０５、１４０６）、ファイル3（１４０７、１４０８）と続き、終了する。このときクライアント側プロキシ（１２）のフォルダカウントが1であるので、このカウンタおよびフォルダ内のファイルを削除して終了する。 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.
図１７(a)はクライアント側プロキシ（１２）のデータ管理部（３０４）における、データ管理テーブル（３１１〜３１３）を示す。また図１７(b)はサーバ側プロキシのデータ管理部（４０４）における、データ管理テーブル（４１１〜４１３）を示す。実施例１との違いは、これらのテーブルではレスポンスを管理しないため、レスポンス内容（３５２、４５２）の項目がない点である。 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.
図１７(c)は共有データプール（１５０１、１６０１）のデータテーブルを示す。これは、URL（１５５１）、レスポンス内容（１５５２）、ファイルが属するフォルダの情報（１５５３）を持つ。フォルダの情報は単なるフォルダ名でも、後述するフォルダテーブルのエントリへのポインタでよい。このデータはすべてのクライアント（１１ａ、１１ｂ）で共有され、他のクライアントのリクエストによりプリフェッチされたデータであっても、データがこの中にあればこのデータをレスポンスとして送信する。 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.
図１７(d)はフォルダテーブル（１５０２）を示す。これは、フォルダ名（１５５４）とカウンタ（１５５５）を持ち、カウンタ（１５５５）はフォルダごとにそのフォルダにアクセスしているクライアントの数を示しており、1以上の値をとる。フォルダ内全ファイルの転送が完了すると、プロキシはフォルダテーブル（１５０２）をチェックし、カウンタ（１５５５）の値が2以上であれば、他にアクセスしているクライアントがいるため同フォルダ内のファイルを削除しない。一方カウンタ（１５５５）の値が1であった場合は、他にアクセスしているクライアントがいないのでファイルを削除する。 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, and the files in the folder are deleted. 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.
図１８はクライアント側プロキシ（１２）の動作を表すフローチャートである。初期状態ではLAN側でパケットを受信するまで待機する（１８０１）。受信すると送信元および宛先IPアドレスごとに分離する（１８０２）。そのパケットがPROPFINDリクエストであれば（１８０３）フォルダテーブルをカウントアップする（１８０４）。その他のリクエストであれば（１８５１）、同様にサーバ側プロキシ（１５）へ転送する（１８５２）が、サーバ側プロキシ（１５）からレスポンスを受信するのを待って（１８５３）それをクライアント（１１）へ転送し（１８５４）、初期状態（１８０１）へ戻る。 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).
フォルダカウントが2以上であれば（１８０５）、他のクライアントが読み込んだデータが存在するため、そのデータ（PROPFINDに対するレスポンス）をレスポンスとしてクライアント（１１）へ送信する（１８０６）。フォルダカウントが1であれば、PROPFINDリクエストをサーバ側プロキシ（１５）へ転送して（１８０７）GET待ち状態へ移行する。サーバ側プロキシ（１５）へ転送したPROPFINDのレスポンスが受信されるまで待機し（１８０８）受信されるとクライアント（１１）へ転送する（１８０９）。同時にこのレスポンスを解析してファイル一覧を作成する（１８１０）。 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).
続いてクライアントからのGETリクエストを待ちうける（１８１１）。GET以外のリクエストを受信した場合（１８５５）は、同様にサーバ側プロキシ（１５）へ転送する（５５６）が、WAN側からレスポンスを受信するのを待って（５５７）それをクライアント（１１）へ転送し（５５８）、初期状態（５０１）へ戻る。 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).
GETを受信した場合、フォルダカウントを参照し（１８１２）、2以上であれば他のクライアントが読み込んだデータが存在するため、そのデータをレスポンスとしてクライアントへ送信する（１８１３）。フォルダ内の全ファイルを転送完了するかタイムアウトするまでこれを繰り返し（１８１４）、終了したらフォルダカウントをカウントダウンする（１８１５）。 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).
フォルダカウントが1であった場合、リクエストをサーバ側プロキシ（１５）へ転送し（１８１６）、それに対するレスポンスを受信するまで待機して（１８１７）、受信されればクライアント（１１）へ転送し（１８１７）、サーバ側プロキシ（１５）からのプリフェッチデータを待ちうける（１８１８）。 サーバ側プロキシ（１５）からのプリフェッチデータを受信すると（１８１８）、これをデータ管理部（３０４）に保存して（１８２０）、クライアントからのリクエストを待ちうける（１８２１）。リクエストを受信すると保存していたデータをレスポンスとしてクライアントに送信する（１８２２）。 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).
図１９はサーバ側プロキシ（１５）の動作を表すフローチャートである。初期状態ではWAN側でパケットを受信するまで待機する（１９０１）。受信すると送信元および宛先IPアドレスごとに分離する（１９０２）。そのパケットがPROPFINDリクエストであれば（１９０３）フォルダテーブルをカウントアップする（１９０４）。その他のリクエストであれば（１９５１）、同様にサーバ（１６）へ転送する（１９５２）が、サーバ（１６）からレスポンスを受信するのを待って（１９５３）それをクライアント側プロキシ（１２）へ転送し（１９５４）、初期状態（１９０１）へ戻る。 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).
フォルダカウントが2以上であれば（１９０５）、他のクライアントが読み込んだデータが存在するため、そのデータ（PROPFINDに対するレスポンス）をレスポンスとしてクライアント側プロキシ（１２）へ送信する（１９０６）。フォルダカウントが1であれば、PROPFINDリクエストをサーバ（１６）へ転送して（１９０７）GET待ち状態へ移行する。サーバ（１６）へ転送したPROPFINDのレスポンスが受信されるまで待機し（１９０８）受信されるとクライアント側プロキシ（１２）へ転送する（１９０９）。同時にこのレスポンスを解析してファイル一覧を作成する（１９１０）。 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).
続いてクライアント側プロキシ（１２）からのGETリクエストを待ちうける（１９１１）。GET以外のリクエストを受信した場合（１９５５）は、同様にサーバへ転送する（１９５６）が、サーバ（１６）からレスポンスを受信するのを待って（１９５７）それをクライアント側プロキシ（１２）へ転送し（１９５８）、初期状態（１９０１）へ戻る。 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).
GETを受信した場合、フォルダカウントを参照し（１９１２）、2以上であれば他のクライアントが読み込んだデータが存在するため、そのデータをレスポンスとしてクライアント側プロキシ（１２）へ送信する（１９１３）。フォルダ内の全ファイルを転送完了するかタイムアウトするまでこれを繰り返し（１９１４）、終了したらフォルダカウントをカウントダウンする（１９１５）。 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).
フォルダカウントが1であった場合、リクエストをサーバ（１６）へ転送し（１９１６）、それに対するレスポンスを受信するまで待機する（１９１７）。受信されればクライアント側プロキシ（１２）へ転送し（１９１８）、次のファイルに対するプリフェッチリクエストを送信する（１９１９）。 サーバ（１６）からのプリフェッチデータを受信すると（１９２０）、クライアント側プロキシに送信する（１９２１）。ファイル一覧にファイルが残っていれば、１９１９以降を繰り返す（１９２２）。すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（１９０１）に戻る（１９２３）。 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 (13)
前記クライアントと前記サーバとに接続され、前記クライアントおよび前記サーバの間の通信を中継するプロキシシステムが、
前記サーバから取得したファイル一覧を含むレスポンスを、前記クライアントに送信し、
前記クライアントからの、前記ファイル一覧に含まれる第一のファイルを指定する第一のリクエストの受信を契機として、
前記クライアントから、前記ファイル一覧に含まれる前記第一のファイル以外の第二のファイルを指定する第二のリクエストを受信しなくても、前記ファイル一覧に含まれる、前記第二のファイルをプリフェッチするための第三のリクエストを前記サーバへ送信し、
前記サーバから、前記第三のリクエストに対するレスポンスである前記第二のファイルをプリフェッチする
ことを特徴とする通信方法。 It said server to the request from the client between the client and servers are in the form method of communication for transmitting a response,
A proxy system connected to the client and the server and relaying communication between the client and the server,
A response including the file list obtained from the server, and sends it to the client,
From the client, the receiving of the first request specifies the first file that is part of the file list as a trigger,
From the client, without receiving the second request specifying the second file other than the first file included in the file list, Ru contained in the file list prefetch the second file Send a third request to the server to
A communication method comprising prefetching the second file as a response to the third request from the server .
前記プロキシシステムは、サーバ側プロキシとクライアント側プロキシとを含み、
前記プリフェッチは、前記サーバ側プロキシで行い、
前記サーバ側プロキシは、
一つ以上のファイル取得を要求する第三のリクエストを前記サーバへ送信し、
前記第三のリクエストに対するレスポンスとしてプリフェッチした一つ以上の前記第二のファイルを前記クライアント側プロキシに送信し、
前記クライアント側プロキシは、
前記サーバ側プロキシから前記一つ以上の第二のファイルを受信して保存し、
受信した前記第二のファイルの一つを取得するための前記第二のリクエストを前記クライアントから受信した場合に、保存している該当する前記第二のファイルの一つを前記クライアントに送信する
ことを特徴とする通信方法。 The communication method according to claim 1, comprising:
The proxy system includes a server side proxy and a client side proxy,
The prefetch is performed by the server side proxy,
The server side proxy
Sending a third request to the server requesting one or more file acquisitions;
Sending one or more of the second file prefetched as a response to the third request to the client-side proxy,
The client-side proxy is
Said receives and stores the server-side proxy or found before Symbol one or more second files,
If the second request for acquiring the one of said received second file received from the client, sending one of said second file corresponding is stored in the client A communication method characterized by the above.
前記クライアント側プロキシは、
前記クライアントから前記第一のリクエストを受信した後に、前記クライアントから、前記第二のリクエストを受信した場合、
前記第二のリクエストに対するレスポンスとなるべき前記第二のファイルを前記サーバ側プロキシから受信していない場合に、前記第二リクエストを前記サーバ側プロキシに転送する
ことを特徴とする通信方法。 The communication method according to claim 2,
The client-side proxy is
If after receiving the first request from the client, from the client, receiving the second request,
Communication method characterized by transferring the second file to a response against the second request if not received from the server side proxy, the second request to the server side proxy.
前記サーバ側プロキシは、
前記クライアント側プロキシから前記第二のファイルを指定する前記第二のリクエストを受信した場合に、
当該サーバ側プロキシが、前記第二のファイルを指定する前記第三のリクエストを未送信の場合に、前記第二のリクエストを前記第三のリクエストとして他のリクエストより優先的に前記サーバに送信する
ことを特徴とする通信方法。 The communication method according to claim 3, wherein
The server-side proxy,
When receiving the second request specifying the second file from the client-side proxy,
The server-side proxy, if the unsent the third request specifying the second file, sending the second request to the third priority to the server from other requests as request signal A communication method characterized by:
前記プロキシシステムは、サーバ側プロキシとクライアント側プロキシとを含み、
前記クライアント側プロキシは、
一つ以上のファイル取得を要求する第三のリクエストを前記サーバ側プロキシへ送信し、
前記サーバ側プロキシは、
前記第三のリクエストを前記サーバに転送し、
前記サーバから前記第三のリクエストに対するレスポンスとして一つ以上の前記第二のファイルを受信し、
前記一つ以上の第二のファイルを前記クライアント側プロキシへ転送し、
前記クライアント側プロキシは、
前記サーバ側プロキシから前記一つ以上の第二のファイルを受信して保存し、
受信した前記第二のファイルの一つを取得するための前記第二のリクエストを前記クライアントから受信した場合に、保存している該当する前記第二のファイルの一つを前記クライアントに送信する
ことを特徴とする通信方法。 A communication how according to claim 1,
The proxy system includes a server side proxy and a client side proxy,
The client-side proxy is
Send a third request to the server-side proxy requesting one or more file acquisitions;
The server side proxy
Forward the third request to the server ;
Receiving said one or more of the second file as a response to the third request from the server,
Transfer the one or more second files to the client-side proxy,
The client-side proxy is
Said receives and stores the server-side proxy or found before Symbol one or more second files,
If the second request for acquiring the one of said received second file received from the client, sending one of said second file corresponding is stored in the client A communication method characterized by the above.
前記クライアント側プロキシは、前記第三のリクエストにより複数のファイル取得を要求する場合、
前記第三のリクエストにより複数のファイル取得を要求する場合、
前記第三のリクエストとして、一つのファイル取得を要求するリクエストを送信し、
当該リクエストに対するレスポンスである一つの前記第二のファイルを受信する前に、次のファイル取得を要求する次のリクエストを、前記第三のリクエストとして送信する
ことを特徴とする通信方法。 The communication method according to claim 5, comprising:
When the client side proxy requests acquisition of a plurality of files by the third request,
When requesting acquisition of a plurality of files by the third request ,
As the third request, sending a request for one of the files acquisition,
Before receiving one of the second file is a response to the request, the next request for acquired next file, that sends as the third request
Communication method, wherein a call.
前記クライアント側プロキシは、
複数の前記クライアントに接続され、
前記ファイル一覧に含まれ、プリフェッチされた前記第二のファイルを保存し、
第一の前記クライアントがリクエストしたファイルと同一のファイルに対するリクエストを、第二の前記クライアントから受信した場合に、
前記第二のクライアントに対して、保存した前記ファイルを送信する
ことを特徴とする通信方法。 The communication method according to claim 2 ,
The client-side proxy is
Connected to a plurality of said clients,
Included in the file list, and save the prefetched the second file,
A request for the first pre-chrysanthemum client request files identical to the file, when received from the second of the client,
Communication method, characterized in that to said second client, to send the file saved.
前記クライアント側プロキシは、複数の前記クライアントに接続され、
前記サーバ側プロキシは、
前記ファイル一覧に含まれプリフェッチされた前記第二のファイルを保存し、
第一の前記クライアントがリクエストしたファイルと同一のファイルに対する、第二の前記クライアントからのリクエストを受信した場合に、
前記第二のクライアントに対するレスポンスとして、保存した前記ファイルを送信する
ことを特徴とする通信方法。 The communication method of claim 2,
The client side proxy is connected to a plurality of the clients,
The server side proxy
The files included in the list to save the pre-fetched the second file,
If the first pre chrysanthemum client has received for the same file and the file requested, the request from the second of the client,
The second as a response against the client, the communication method characterized in that to send the file saved.
前記クライアント側プロキシ及び前記サーバ側プロキシは、ＷｅｂＤＡＶに従う通信であって、
前記第一のリクエストは、ＰＲＯＰＦＩＮＤであり、
前記ファイル一覧は、前記ファイルの実体の場所を示すＵＲＬであって、「２０７ ＭｕｔｌｉＳｔａｔｕｓ」というレスポンスに含まれ、
前記第２のリクエストは、当該ファイルの実体の取得を要求するためのＧＥＴリクエストである
ことを特徴とする通信方法。 The communication method according to claim 2 ,
The client-side proxy and the server side proxy is a communication according to WebDAV,
Wherein the first request is PROPFIND,
Before notated Airu list, a URL indicating the location of the entity of the file, is included in the response of "207 MutliSta tus",
The second request, Ru GET request der for requesting acquisition of the entity of the file
Communication how to characterized a call.
前記クライアント側プロキシ及び前記サーバ側プロキシは、ＨＴＴＰプロトコルに従う通信であって、
前記第一のリクエストがＨＴＭＬファイルに対するＧＥＴリクエストであり、
前記前記ファイル一覧は、「２００ ＯＫ」というレスポンスに含まれ、
前記第２のリクエストは、当該ファイルの実体の取得を要求するためのＧＥＴリクエストである
ことを特徴とする通信方法。 The communication method according to claim 2 ,
The client-side proxy and the server side proxy is a communication according to HTTP protocol,
The first request is a GET request for the HTML file,
Wherein the file list is included in the response of "200 OK",
The second request, Ru GET request der for requesting acquisition of the entity of the file
Communication how to characterized a call.
前記クライアントと通信するクライアント通信部と、
前記サーバと通信するサーバ通信部と、
通信制御部と、を有し、
前記通信制御部は、
前記クライアントからの、第一のリクエストに対して前記サーバから取得したレスポンスが示す、前記サーバに格納されている複数の情報のうち、一つの第一の前記情報の取得要求を前記クライアントから受信したことを契機として、前記レスポンスが示す、前記第一の情報を含む複数の前記情報の取得要求を、前記サーバに送信し、
前記複数の情報取得要求に対するレスポンスである前記複数の情報を前記サーバから受信した場合、前記クライアントに当該複数の情報を送信する
ことを特徴とするプロキシシステム。 Between client and server, a proxy system that performs communication control of information stored in said server,
A client communication unit that communicates with the client,
A server communication unit that communicates with the server,
A communication control unit,
The communication control unit
From the client, and against the first request indicating a response obtained from the server, the one of the plurality of information stored in the server, receiving one of the acquisition request of the first of said information from said client and that as a trigger was, the indicated response, the acquisition request of the plurality of the information including the first information, and sends to the server,
When receiving the plurality of information is a response to the plurality of information acquisition request from the previous SL server that sends the plurality of information to the client
Proxy system, wherein a call.
前記通信制御部は、
バッファを備え、
ＷｅｂＤＡＶプロトコルに従う、前記クライアントからの送信される前記第一のリクエストであるＰＲＯＰＦＩＮＤに対する前記サーバからのレスポンスに基づいて、特定されるフォルダに含まれるファイルのＵＲＬを用いて、前記フォルダに含まれるいずれか一のファイルの取得要求を前記クライアントから受信した場合、前記フォルダに含まれる他のファイルも前記サーバからプリフェッチして前記バッファに保存し、
前記クライアントからの前記他のファイルの取得要求に応じて、保存したファイルをクライアントに送信する
ことを特徴とするプロキシシステム。 The proxy system according to claim 11 , wherein
The communication control unit
With a buffer,
Cormorant follow the WebDAV protocol, based on the response from the server for the PROPFIND is the first request sent from the client, using the URL of the files contained in the folder specified, included in the folder When an acquisition request for any one file is received from the client, other files included in the folder are also prefetched from the server and stored in the buffer ,
In response to the acquisition request of the other files from the client, that sends the saved file to the client
Proxy system, wherein a call.
前記クライアント通信部は、複数の前記クライアントと通信し、
前記通信制御部は、前記複数のクライアントから、ＰＲＯＰＦＩＮＤを受信した場合、前記バッファに保存したファイルを当該複数のクライアントにそれぞれ送信し、当該ファイルを前記バッファから削除する
ことを特徴とするプロキシシステム。 The proxy system according to claim 12 , comprising:
The client communication unit communicates with a plurality of the clients,
Said communication control unit, said plurality of clients, when receiving the PROPFIND, the files stored in the buffer and sends each of the plurality of clients, to delete the file from the buffer
Proxy system, wherein a call.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012085993A JP5948111B2 (en) | 2012-04-05 | 2012-04-05 | Packet communication apparatus and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012085993A JP5948111B2 (en) | 2012-04-05 | 2012-04-05 | Packet communication apparatus and method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2013218387A JP2013218387A (en) | 2013-10-24 |
| JP5948111B2 true JP5948111B2 (en) | 2016-07-06 |
Family
ID=49590441
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2012085993A Expired - Fee Related JP5948111B2 (en) | 2012-04-05 | 2012-04-05 | Packet communication apparatus and method |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5948111B2 (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2015001784A (en) * | 2013-06-13 | 2015-01-05 | 富士通株式会社 | Information processing system, information processing apparatus, and information processing program |
| JP6344520B2 (en) * | 2015-02-19 | 2018-06-20 | 富士通株式会社 | COMMUNICATION DEVICE, INFORMATION PROCESSING METHOD, AND INFORMATION PROCESSING PROGRAM |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4514872B2 (en) * | 2000-01-26 | 2010-07-28 | シャープ株式会社 | Information acquisition apparatus, information acquisition method, and computer-readable recording medium on which information acquisition program is recorded |
| JP2003186785A (en) * | 2001-12-14 | 2003-07-04 | Sanyo Electric Co Ltd | Local server, information delivery system and user terminal devices |
| JP5172169B2 (en) * | 2007-02-16 | 2013-03-27 | シャープ株式会社 | Content display device, television receiver, content display method, content display control program, and recording medium |
| JP5439761B2 (en) * | 2008-07-25 | 2014-03-12 | 富士通株式会社 | Content reproduction apparatus, content reproduction method, and content reproduction program |
| JP5442541B2 (en) * | 2010-06-21 | 2014-03-12 | 日本電信電話株式会社 | WEB information acquisition method and apparatus |
-
2012
- 2012-04-05 JP JP2012085993A patent/JP5948111B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2013218387A (en) | 2013-10-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10630758B2 (en) | Method and system for fulfilling server push directives on an edge proxy | |
| TWI444079B (en) | Method, processor, computer program product, and apparatus for binding/aggregating multiple interfaces at application layer layer | |
| US20190020562A1 (en) | Latency measurement in resource requests | |
| US9253065B2 (en) | Latency measurement in resource requests | |
| Bormann et al. | CoAP (constrained application protocol) over TCP, TLS, and WebSockets | |
| EP2272239B1 (en) | Server selection for routing content to a client using application layer redirection | |
| US8924528B1 (en) | Latency measurement in resource requests | |
| US20180375952A1 (en) | Method and apparatus for reducing network resource transmission size using delta compression | |
| WO2015096801A1 (en) | Method and apparatus for accelerating data transmission in a network communication system | |
| US8984164B2 (en) | Methods for reducing latency in network connections and systems thereof | |
| US10367871B2 (en) | System and method for all-in-one content stream in content-centric networks | |
| CN103312807B (en) | Data transmission method, apparatus and system | |
| CN102656579A (en) | Internet infrastructure survey | |
| US20110280247A1 (en) | System and method for reducing latency via multiple network connections | |
| JP2009140290A (en) | Content repeater, content relay system, content relay method and program | |
| CN103581361A (en) | Domain name resolution proxy method, device and system | |
| CN112929411A (en) | Distributed file transmission method, server and private cloud equipment | |
| US20110173248A1 (en) | Method for providing on-path content distribution | |
| JP5948111B2 (en) | Packet communication apparatus and method | |
| EP2677723A1 (en) | System and method for cookie-based browser identification and tracking | |
| WO2013180255A1 (en) | Communication devices and method | |
| US10110646B2 (en) | Non-intrusive proxy system and method for applications without proxy support | |
| US20110282926A1 (en) | Relay apparatus, recording medium storing a relay program, and a relay method | |
| JP2013088998A5 (en) | ||
| Blanchet | Postellation: an enhanced delay-tolerant network (dtn) implementation with video streaming and automated network attachment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20141107 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20151020 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20151218 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20160510 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20160606 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 5948111 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
| LAPS | Cancellation because of no payment of annual fees |