JP2005010970A - 分散キャッシュ制御方法、ネットワークシステムおよび当該ネットワークに用いられる制御サーバないしルータ - Google Patents
分散キャッシュ制御方法、ネットワークシステムおよび当該ネットワークに用いられる制御サーバないしルータ Download PDFInfo
- Publication number
- JP2005010970A JP2005010970A JP2003172773A JP2003172773A JP2005010970A JP 2005010970 A JP2005010970 A JP 2005010970A JP 2003172773 A JP2003172773 A JP 2003172773A JP 2003172773 A JP2003172773 A JP 2003172773A JP 2005010970 A JP2005010970 A JP 2005010970A
- Authority
- JP
- Japan
- Prior art keywords
- server
- data
- cache
- control server
- control
- 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.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/288—Distributed intermediate devices, i.e. intermediate devices for interaction with other intermediate devices on the same level
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/957—Browsing optimisation, e.g. caching or content distillation
- G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
- H04L67/5681—Pre-fetching or pre-delivering data based on network characteristics
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
- H04L67/5682—Policies or rules for updating, deleting or replacing the stored data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0862—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with prefetch
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Information Transfer Between Computers (AREA)
Abstract
【課題】ネットワーク上のピークトラフィックを抑制する。
【解決手段】ネットワーク上に、複数のキャッシュサーバを連携させる制御サーバを設け、更に制御サーバに特定データの需要予測をさせる。需要の増大が見込まれるデータに関しては、制御サーバの配下にあるキャッシュサーバに予め当該データをコピーして配信する。
【選択図】 図1
【解決手段】ネットワーク上に、複数のキャッシュサーバを連携させる制御サーバを設け、更に制御サーバに特定データの需要予測をさせる。需要の増大が見込まれるデータに関しては、制御サーバの配下にあるキャッシュサーバに予め当該データをコピーして配信する。
【選択図】 図1
Description
【0001】
【発明の属する技術分野】
本発明は、情報通信ネットワークにおいてネットワーク中に分散したキャッシュの制御方法ないし制御装置およびこれらの制御方法が適用されるネットワークシステムに属する。
【0002】
【従来技術】
複数のクライアントが同一データを参照する場合、キャッシュ技術を用いることで、アクセス時に生じるネットワーク・トラフィックがクライアント−キャッシュサーバ間で閉じるため、ネットワーク全体のトラフィック量を抑制できる。しかし、大規模なネットワークで発生するトラフィックは単一のキャッシュサーバでは処理できず、通常、複数のキャッシュサーバが分散して配置される。
【0003】
特開2002−251313号公報には、複数のキャッシュサーバを連携させる技術が開示されている。本文献に開示された発明では、複数のキャッシュサーバを制御する親サーバを設けて、該親サーバ個々のキャッシュサーバが保持しているキャッシュデータの情報を格納する。更に、親サーバは、クライアントから要求のあったデータを配下のキャッシュサーバが保持しているかどうか照会し、要求されたデータを保持している配下のキャッシュサーバが有れば、当該キャッシュサーバより要求データを取得する。または要求を出したクライアントに接続されているキャッシュサーバに当該データを転送させる。このように複数のキャッシュサーバを連携させることにより、外部ネットワークへのアクセス頻度が低減し、クライアントのデータ要求に対する応答時間が短縮される。また、各キャッシュサーバが保持するキャッシュデータの量も低減することが可能である。
【0004】
特開平11−24981号公報には、キャッシュデータの先読み技術が開示されている。本文献に開示された技術では、キャッシュサーバが、アクセスしたファイルを記録するアクセス履歴データベースと、先読み選出モジュールとを備え、アクセス頻度の高いファイルとその更新間隔から次に先読みすべきデータを決定し、ネットワークのトラフィック量が空いている時間帯に予め先読みデータをキャッシュする。本技術によれば、キャッシュヒット率が向上し、ファイルアクセスが高速化する。
【0005】
また、IETF(Internet Engineering Task Force)から発行されているRFC(Request For Comment)2186には、キャッシュサーバを連携させる一方法として、ICP(Internet Cache Protocol)が規定されている。ICPを用いたネットワークの構成例を図14に示す。クライアント17,18はルータ14を介してキャッシュサーバ13に接続され、クライアント19,20はルータ16を介してキャッシュサーバ15に接続されている。ルータ14,16は内部ネットワークを介して上位のルータ12に接続される。ルータ12は外部ネットワークに接続される。ルータ14、16には、各々キャッシュデータを保持するキャッシュメモリを備えたキャッシュサーバが接続されている。
【0006】
ICPでは、クライアントから要求されたデータがキャッシュに無い場合、他のキャッシュに問い合わせ、他のキャッシュが当該データを保持している場合は、そのキャッシュからデータを取り寄せることで、ネットワーク外部へのデータの取得を行わないようにし、応答時間の向上を計っている。
【0007】
【発明が解決しようとする課題】
従来技術においては、問い合わせ時に多くのパケットが発行されるため、ネットワーク内のトラフィックは増加する傾向にある。さらに、短い時間に多くのクライアントから問い合わせが生じると、多くのキャッシュサーバがデータを取得する動作を起こすため、さらにネットワーク・トラフィックは増加する。従って、特定のコンテンツに対し突発的にアクセス要求が発生した場合などには対応できない。
本発明の目的は、ネットワーク上でのピークトラフィックを抑制することにある。
【0008】
【課題を解決するための手段】
本発明の分散キャッシュ制御方式が適用されるネットワークでは、複数のクライアントが接続するネットワークにおいて、複数のキャッシュサーバと複数のキャッシュサーバを制御する制御サーバとを備えることを特徴とする。当該制御サーバは、キャッシュサーバで保持しているデータの状態もしくは状態の変化に基づき、クライアントからアクセス要求のあったデータを保持するキャッシュサーバからデータを保持していないキャッシュサーバへデータをコピーする指示を発行することを特徴とする。
なお、その他の特徴、効果等は、実施例にて詳細に説明される。
【0009】
【発明の実施の形態】
(実施例1)
以下、実施例について、図面を用いて詳細に説明する。
(構成の説明)
図1には、本発明が適用されるネットワークの1形態について示した。17、18、19、20はクライアントであり、例えば、ネットワークに接続しているエンドユーザである。14、16は、複数のクライアントから延びる加入者線を集線する第1のルータ群であり、例えばネットワーク上に配置されたアクセスルータやBAS(Broadband Access Server)、ゲートウェイ等が第1のルータに相当する。第1のルータが集線するクライアントの数は、必ずしも複数である必要はない。便宜上、第1のルータは14、16の2つしか図示していないが、14〜16の間には、内部ネットワークに接続された第1のルータが複数配置されているものとする。以後、制御サーバの配下にある第1のルータの総称としては、「第1のルータ群」という文言を使用する。
13、15はキャッシュサーバであり、キャッシュサーバ13は第1のルータ14に、キャッシュサーバ15は第1のルータ16とそれぞれ接続している。12は複数の第1のルータ群14、16を更に集線する第2のルータであり、クライアントから見てネットワーク上で第1のルータの奥側に配置されている。第1のルータと第2のルータとは、内部ネットワークで接続されており、内部ネットワークとは、例えば、LANやその他の閉鎖網である。
10は、第1のルータ群とキャッシュサーバ、第2のルータおよび内部ネットワークを含むネットワークを示す。このようなネットワークの例としては、例えば、エンドユーザがインターネットに接続するためのアクセス網がある。図示されていないが、第2のルータ12から上に延びる線の更に上方には、10とは異なるネットワークが存在しており、本実施例の第2のルータは、他ネットワークとの接続部分に配置されている。
【0010】
第2のルータには制御サーバ11が接続されており、複数のキャッシュサーバ13、15の動作を制御している。具体的には、個々のキャッシュサーバから上がってくるキャッシュデータの要求を監視し、監視結果に基づきアクセス要求が多くなると予測されたデータのコピー命令を、配下にあるキャッシュサーバへ送信する。
更に詳細な制御サーバの動作ステップについては、後段の「動作の説明」の欄で詳述する。
【0011】
図2には、制御サーバ11の構成例を示した。30はパケットの送受信を司るパケットハンドラであり、例えば、パケットの入出力インタフェースカード等で構成される。31は配下のキャッシュサーバからの要求や応答を処理する要求処理部であり、プロセッサやASIC等で実現される。履歴表32は、配下のキャッシュサーバや下位の制御サーバからの要求の履歴が記録されるテーブルであり、メモリやハードディスクなどの記憶手段により構成される。要求処理部31は、データ処理の際に履歴表32を参照する。33は予測部であり、履歴表32の情報を元に将来のアクセス予測を行う。301は学習機能部である。後述するが、学習機能部は必ずしも必須ではない。アクセス予測を実行するには種々の方法があり、予測部33の内部構成は予測方法に応じて変わるが、ここでは、本実施例では、タイムスタンプによりアクセス予測を行なう場合の予測部の内部構成について示す。
本実施例での予測部33は、現在の時刻を示す時計34、履歴表のエントリ40に含まれる登録されているサーバIDの個数を数える計数機38、タイムスタンプフィールド40の値と時計34の値の差を求める減算器36と、予測条件を保持する閾値レジスタ35と、計数機38の出力もしくは減算器36の出力と閾値レジスタ35の値を比較する比較器37を備えている。
【0012】
図3には、予測手法としてタイムスタンプを用いた場合の履歴表の構成例を示した。履歴表32はエントリ40の集合から構成され、エントリ40は更に、実際にデータが格納される複数のフィールドにより構成されている。デフォルトの状態では、各フィールドは空白である。
41は、要求されたデータのIDを記録するデータIDフィールドである。ここで、データIDとは、クライアントから要求されたデータやコンテンツ等に対して付与されるユニークな識別子であり、例えば、データの格納先のURLやIPアドレス等が格納される。要求データに対して通し番号を付けても良い。42、44、46は、データIDフィールド41に格納されるデータを要求した直接の下位サーバのIDを記録するサーバIDフィールドである。
ここで「直接の下位サーバ」とは、自己が管理しているサーバのことであり、図1のネットワークシステムにおいては、第2のルータに対する「直接のサーバ」に相当するサーバは、キャッシュサーバ13、15となる。内部ネットワーク内に更に中継ノード装置が存在し、中継ノード装置に制御機能を備えたサーバが接続されていれば、制御サーバ11が直接管理するサーバは中継ノード装置に接続されたサーバとなるため、「直接の下位サーバ」とは当該内部ネットワークに配置されたノード装置となる。
サーバIDとは、「直接の下位サーバ」に付与されたユニークな識別子であり、例えば、各下位サーバのIPアドレスである。第2のルータが集線しているルータないしノード装置に対しユニークな番号を付与して、この番号をサーバIDフィールドに格納しても良い。但しこの場合、サーバIDと各サーバのIPアドレスの対応テーブルを管理する必要が出てくるため、管理が多少複雑になる。
各サーバIDフィールドと対をなして、各サーバにおけるキャッシュデータの登録状態を記録する状態フィールド43,45,47が設けられる。状態フィールドには、所定のキャッシュデータが、本登録状態か仮登録状態かを示す識別子が格納される。48は、エントリ40にサーバIDを登録した最終時刻を保持するタイムスタンプフィールドである。
【0013】
第2のルータ12は、配下にある第1のルータからのデータ要求パケット、ないしクライアントより要求のあったデータを元々保有しているオリジナルサーバからのデータ転送パケットを受け取ると、制御サーバに対して受信したパケットを転送する。受信パケット自体を転送する他に、受信パケットからヘッダ情報を切り出して転送しても良い。あるいは、受信パケットのコピーデータを制御サーバに転送しても良い。
パケットハンドラ30は、第2のルータからパケットを受信すると、要求処理部31へ受信パケットを転送する。要求処理部31は、予測部33を起動して、アクセス要求のあったデータあるいはオリジナルサーバから転送されてきたデータ(以下、単に”データ”と称する)の需要予測を実行させる。
【0014】
予測部33は、履歴表32を参照して該当エントリのタイムスタンプフィールドから該当データの直近の登録時刻を取得する。また、予測部33は、要求処理部31から起動命令を受信した時刻を時計34から取得する。時計34は、例えば、プロセッサに付随しているカウンタクロック等により実現可能である。取得された登録時刻と現在時刻とは減算器36に入力され、現在時刻と登録時刻との差が計算される。計算された差は、閾値レジスタ35に格納された閾値データとともに比較器に入力される。この差が、閾値レジスタに格納された値よりも小さい場合は、当該データに対するアクセス要求の間隔が閾値を超えたと判定される。すなわち、当該データに対する需要が現時点以降も増大すると判定される。格納された値よりも差が大きい場合は、当該データに対するアクセス要求の間隔がまだ閾値を越えておらず、当該データに対するアクセス需要は、現時点以降でも増大しないものと判定される。判定結果は要求処理部31へ送信される。
【0015】
要求処理部31は、予測部33から送信された結果を基に、コピー命令の実行を行う。予測部33から送信された判定結果が需要増大であった場合には、アクセス要求のあったデータを保持しているキャッシュサーバに対して、アクセス要求元であるキャッシュサーバだけではなく、配下のキャッシュサーバ全てに当該データのコピー命令を送信する。あるいは、オリジナルサーバから送信されたデータを、配下のキャッシュサーバ全部に送信する。予測部33での予測結果が需要増大でなかった場合には、当該データは、アクセス要求のあったキャッシュサーバにのみ転送される。
予測動作によるデータコピーは、将来発生するであろうクライアントからのデータ要求によるキャッシュサーバ間のデータ移動を、予測動作時まで先行して実行することを意味する。従って、本実施例を実施することにより、トラフィックがピークとなる時刻をシフトする、つまりピークトラフィックの平坦化が可能となる。
なお、本実施例の制御サーバは、数値の入力手段と操作画面とを有する管理コンソール300を備えており、閾値レジスタ35に保持させる値は装置ユーザが自由に変更可能である。
【0016】
また、制御サーバに学習機能を与えて閾値レジスタ35に保持させる値を最適化させても良い。このため、学習機能部301が設けられる。もし予測動作を行うより前に、制御サーバに配下の過半数のキャッシュサーバから要求が届いた場合、コピー指示の発行が遅れたと見なし、コピー指示の発行タイミングを早めるため、閾値レジスタの値を大きくする。一方、クライアントからの要求到着がコピー指示のタイミングに比べ遅い場合には、コピー指示の発行を遅らせるため閾値レジスタの値を小さくする。
【0017】
閾値レジスタ35の値を小さくするためにはクライアントからの要求到着がコピー指示のタイミングに比べ遅いということを判定する必要がある。従って、キャッシュサーバは、コピー指示命令が到着してからクライアントからの要求到着までにかかった時間を計測し、計測結果を制御サーバ11に送信する。このため、各キャッシュサーバは、時間を計測するための計時手段と、時間を計測したデータのデータIDと計測した時間とを対比して記憶する記録手段とを有する。記憶手段としては、例えば、メモリやディスク装置などに形成される管理テーブルでもよいし、あるいはデータIDと時間データをレジスタに直接格納してもよい。
学習動作を行なう場合、まず要求予測部31が学習機能部301を起動する。学習機能部301は、起動すると、キャッシュサーバが送信する、クライアントから送信されたデータIDと時間データの受信をパケットハンドラ30に要求し、パケットハンドラが送信するデータを計測結果表に格納する。代表値選択器は計測結果表に格納されたデータから代表値を計算、あるいは選択し、比較器に入力する。一方、比較閾値調節レジスタには、所定の閾値(調節閾値と称する)が格納されており、比較器は、代表値が入力されると調節閾値レジスタから閾値を取り込み、代表値と閾値とを比較する。
代表値が閾値よりも大きければ、クライアントからの要求到着がコピー指示のタイミングに比べ遅いと判定し、閾値レジスタに格納された閾値を、加減算器にて所定の負の値だけインクリメントする。代表値としては、各キャッシュサーバで計測された時間の累計データや計測時間の平均値などを用いることができる。また、インクリメントする値は、閾値レジスタや調節閾値レジスタ、あるいは加減算器内部のレジスタに格納しておけば良い。また、インクリメント値も、管理コンソールにてユーザが自由に設定可能である。
【0018】
履歴表32は、要求処理部31からの指示によりエントリが更新された時、更新されたエントリを学習機能部301に送信する。学習機能部301は受信したエントリを計数機に入力する。計数機はエントリに登録されているサーバIDを数え、比較器に入力する。一方、比較閾値レジスタには、所定の閾値(調節閾値と称する)が格納されており、比較器は、登録済みのサーバIDの個数(登録個数と称する)が入力されると、登録個数と調整閾値とを比較する。
登録個数が調整閾値より大きければ、予測動作を開始すべきだと判定し、加減算器に閾値レジスタに格納された閾値を、インクリメントするよう指示を出す。加減算器は、予測部が予測動作を開始していない時点でインクリメント指示を受け取った場合、閾値レジスタに格納された閾値を、所定の正の値でインクリメントする。インクリメントする値は、閾値レジスタや調節閾値レジスタ、あるいは加減算器内部のレジスタに格納しておけば良い。また、インクリメント値も、管理コンソールにてユーザが自由に設定可能である。
【0019】
学習動作を実行させるタイミングとしては、例えば、コピーデータを配下の管理サーバへ送信した時点がある。各々のキャッシュサーバは、自分がアクセス要求を行っていないデータIDのデータが制御サーバ11より送信されてきた場合、コピーデータが送信されたと判定して、時間計測を開始する。クライアントから当該データIDのデータのアクセス要求パケットが届いた場合、計測をやめ、計測時間データとデータIDとを制御サーバ11に送信する。
また、計測した時間データを制御サーバに送信する場合、2通りの方法がある。1つは、時間計測データをサーバIDの如何を問わず全て制御サーバに送信する方法であり、もう一つは、計測時間が判定のしきい値よりも大きい場合にのみ計測データを制御サーバへ送信し、小さい場合は送信しない方法である。後者の場合、制御サーバとキャッシュサーバ間のトラフィック量を低減できるという利点がある。
(動作の説明)
図1のトポロジーを有するネットワークシステムの動作形態は、以下の3種類の形態があると考えられる。
1)ネットワークシステム内に配置されたいずれのキャッシュサーバにもデータがキャッシュされていない場合。
2)ネットワークシステム内に配置されたいずれかのキャッシュサーバに、既にデータがキャッシュされており、当該データをキャッシュしていないキャッシュサーバからアクセス要求が発行される場合。
3)複数のキャッシュサーバから同じデータに対してアクセス要求が発行された場合。
まず、ネットワークシステム内にあるキャッシュサーバのいずれにもデータがキャッシュされていない場合である第1の動作例について説明する。
第1の動作例は、図4に記載したフローチャートのステップ100〜117を用いて説明される。例えば、図1のトポロジーを有するネットワークにおいて、クライアント17が、所定のデータIDのデータを取得しようとする場合、データ要求パケットをキャッシュサーバ13に送信することで前記データを要求する。本実施例では、データIDが700なる番号のデータを取得しようとしてデータ要求パケットを送信したものとする。データIDとしては、数字の他、任意の識別子を使用してよく、要はデータとデータIDとの関係が一位に定まるものであれば何でも良い。要求データのデータオリジナルサーバのURL(Unified Resource Locator)を使用しても良い。例えば、URLがhttp://www.xxx.com/id#700であったとすると、データIDとしてhttp://www.xxx.com/id#700をそのまま使用して構わない。クライアント17がキャッシュサーバ13のIPアドレスを知らない場合には、データ要求パケットをオリジナルサーバに送信する。いずれの場合でも、クライアントから送信されたデータ要求パケットは必ず第1のルータを通過することになる。第1のルータ14は、クライアントからのデータ要求パケットを受信すると、受信パケットをキャッシュサーバ13に転送する。キャッシュサーバ13は、要求されたデータを保持していない場合、更に新たなデータ要求パケットを制御サーバ11に送信する。
【0020】
次に、図4のフローチャートを用いて、制御サーバの動作フローについて説明する。
制御サーバ11は、ステップ100でデータ取得の要求を受信すると、ステップ101にて、データIDフィールドにアクセス要求を受けたデータのIDが格納されたエントリの有無を履歴表32で確認する。エントリが存在しないことは、当該IDのデータは過去にアクセス要求の無かったデータであることを意味する。ステップ102において、制御サーバ11の上位サーバに向けてデータ取得の要求パケットを送信する。図1のネットワークシステムの場合には、アクセス要求のあったデータを保持するオリジナルサーバへデータ要求パケットを送信する。
データ要求パケットの送信後、ステップ103において、履歴表32にエントリ40を新規に作成し、データIDフィールド 41に、データID 700を登録する。その後、ステップ104において、当該サーバに直接要求を送信した下位サーバのIDをサーバ IDフィールド 42に書き込む。図1に示したトポロジーのネットワークの場合、制御サーバ11に対する下位サーバとしては、キャッシュサーバ13、15のいずれかが該当し、この場合は、データ要求パケットを送信したキャッシュサーバ13のサーバIDである13がサーバIDフィールドに記録される。サーバIDとしては、13のような数字の他、IPアドレス等、各キャッシュサーバに付与した任意の識別子を用いることが可能である。状態フィールド43には、仮登録を示す値が書き込まれる。
【0021】
図5には、ステップ104が終了した後の履歴表32の状態を示した。データIDフィールドにデータID700が格納されたエントリ40が作成され、1番目のサーバIDフィールドにはサーバID13が格納されている。1番目のサーバIDフィールドと対となる1番目の状態フィールド43には、仮登録を示す状態値「仮」が格納されている。図1のトポロジーのネットワークの場合、エントリ40に作成されるサーバIDフィールドは、制御サーバ11の配下にあるキャッシュサーバの数と等しい数だけ生成される。ステップ104が終了した段階では、他のサーバIDフィールドおよび状態フィールド44〜47、タイムスタンプフィールド48は空白である。
【0022】
ステップ105で上位サーバからの応答パケット603を受信すると、ステップ106 で応答パケット中の応答コードを確認する。ここで、「応答コード」とは、要求したデータがオリジナルサーバにあったかなかったかを示す識別子であり、応答パケットに格納されている。要求データがオリジナルサーバになかった場合は、応答エラーを示す応答コードがパケットに付与される。応答コードがエラーでなければ、ステップ107に進み、当該エントリ40の状態フィールドに「仮」が記録された下位サーバ13に対して、制御サーバ11は、応答データパケットを送信する。応答データパケットの送信後、ステップ108にて、エントリ40のサーバID13の状態フィールドに本登録状態を示す状態値「本」を記録する。キャッシュサーバ13は、制御サーバから応答データパケット を受け取ると、キャッシュにデータを登録し、更にデータを要求したクライアント17に応答データパケット605を送信する。
ステップ106にて、応答コードがエラーと判断された場合、ステップ116へ処理を進め、エントリ40のサーバIDフィールドが空白でないサーバ全てに応答エラーを通知し、ステップ117で当該エントリを削除する。
【0023】
図6には、図7のステップ108を終了した後の履歴表32の状態を示す。図5に示した履歴表のエントリに比べて、状態フィールド43の値が「本」に変わっていることが判る。
【0024】
次に、すでにデータをキャッシュしているキャッシュサーバがある状態で、別のキャッシュサーバが要求を発行した場合である第2の動作例について説明する。
図1のトポロジーを有するネットワークにおいて、キャッシュサーバ13はデータIDが700のデータをキャッシュしているものとする。この場合、制御サーバ11の履歴表32には、図6に示すようなエントリ40が作成されている。つまり、サーバIDフィールドに既にデータをキャッシュしているサーバのIDが、また当該サーバIDフィールドに対応する状態フィールドに本登録状態であることを示す識別子「本」がそれぞれ格納されている。クライアント20がデータ700を取得する場合、要求パケットをキャッシュサーバ15または第1のルータ16に送信する。キャッシュサーバ15は、自己のキャッシュにデータ700を保持していないと判断すると、要求パケットを制御サーバ11に送信する。制御サーバ11は、キャッシュサーバ15からの要求を受信するが、この動作が図7のステップ100に相当する。
【0025】
以下は、図7を用いて制御サーバの動作を説明する。下位サーバであるキャッシュサーバ15からのデータアクセス要求を受信すると、制御サーバ11の要求処理部31は、ステップ101の動作を開始する。ステップ101では、履歴表32にデータ700のエントリ40があるため、ステップ111に処理を進める。エントリ40の状態フィールド43が本登録になっているため、ステップ111ではステップ113に処理を進める。
ステップ113ではエントリ40から本登録状態になっているサーバIDから一つを選択する。この動作は、要求処理部31によって実行される。ここでは、サーバIDフィールド42に記録されているキャッシュサーバ13が選択される。次のステップ114で選択されたキャッシュサーバ13に指示パケットが送信される。ステップ115でエントリ40のサーバIDフィールド44に15を、状態フィールド45に本登録を書き込むことで、エントリ40は図7に示した状態となる。
キャッシュサーバ13は、指示パケットを受信すると、指示に従いID700のデータを載せた転送パケットをキャッシュサーバ15へ送信する。キャッシュサーバ15は転送パケットを受信すると、キャッシュにデータ700を登録し、応答パケットをクライアント20へ送信する。
【0026】
最後に、複数のキャッシュサーバから同じデータに対してアクセス要求が発行された場合である第3の動作例について説明する。
図1に示すトポロジーを有するネットワークにおいて、クライアント17とクライアント20が同じデータ700の取得を試みた場合を考える。この場合、クライアント17からのデータアクセス要求が最初に制御サーバに到達し、クライアント20の発行したデータアクセス要求はその後に制御サーバに到達するものとする。
まず、クライアント17は、データ要求パケットをキャッシュサーバ13に送信する。キャッシュサーバ13はデータ700を保持していない場合、要求パケットを制御サーバ11に送信する。
制御サーバ11は図7の制御フローに従い動作し、ステップ100から104まで実行し、上位サーバに要求パケットを送信する。ステップ104の実行後、履歴表32のエントリ40は図5に示すように、データIDフィールド41が700、サーバIDフィールド42が13、状態フィールド43が仮登録となる。クライアント20はキャッシュサーバ15に要求パケットを送信し、キャッシュサーバ15は要求パケットを制御サーバ11に送信する。制御サーバ11は図7の制御フローに従い動作し、ステップ100でパケットを受信した後、ステップ101で履歴表32をチェックする。クライアント17からのアクセス要求に対する応答がステップ104まで実行されているので、履歴表32には、データIDフィールドの値が700であるエントリ40が存在する。よって、制御サーバ11はステップ111に処理を進める。ステップ111ではエントリ40をチェックする。オリジナルサーバからの応答がまだ帰ってきていないので、先に作成されたサーバIDフィールド42に対応する状態フィールド43は本登録状態になっていない。そこで、制御サーバ11は、ステップ112に処理を進める。要求処理部31は、エントリ40の空きサーバIDフィールドにキャッシュサーバ15のサーバIDを記録する。図8に、ステップ112が実行された後の履歴表32の状態を示す。
上位サーバからの応答パケットが制御サーバ11に到着すると、制御サーバ11はステップ105から処理を再開し、ステップ107において、応答パケットをキャッシュサーバ13と15にそれぞれ送信する。キャッシュサーバ13と15は、制御サーバから送信された応答パケット中のデータをキャッシュに登録し、それぞれのクライアント17と20にアクセス要求のあったデータを応答パケットとして送信する。
【0027】
なお、クライアント17と20のアクセス要求が制御サーバ11に転送されるまでのタイムラグが大きく、クライアント20からのアクセス要求が制御サーバ11に届いたのが上位サーバからの応答を制御サーバ11が受信した後になった場合、クライアント20からのアクセス要求に対する応答は、図4のフローチャートにおいて、ステップ101→ステップ111→ステップ113の経路で処理される。
また、クライアント17と20からのデータアクセス要求がほぼ同時に制御サーバ11へ転送された場合、少しでも先に到着した方のデータアクセス要求が先に処理される。このため、制御サーバ11のパケットハンドラ30は、受信したデータ要求パケットをキューイングするためのバッファメモリを備えている。
【0028】
次に、予測動作時の動作について説明する。
まず、図4のフローチャートを用いて予測動作が発生するタイミングについて説明する。一つの例としては、要求元キャッシュサーバを履歴表に本登録した時点(図4のステップ110)である。また、もう一つの例としては、要求元キャッシュサーバを履歴表32に仮登録する時点(図4のステップ104および112)である。更にもう一つの例としては、既に本登録済みのキャッシュサーバを選択する時点(図4のステップ113の時点)である。
【0029】
予測動作が図4のステップ110、104または112で発生する場合、要求元キャッシュサーバにデータを転送する時点(図4の107)で、要求元キャッシュサーバだけでなく、予測動作によってデータの宛先となったキャッシュサーバにもまとめてデータを送信する。
また、予測動作が図4のステップ113の時点で発生する場合、コピー指示を送信する時点(図4の114)で、要求元キャッシュサーバだけでなく、予測動作によってデータの宛先となったキャッシュサーバにもコピーデータを送るように指示が出される。
いずれの時点で予測動作を発生させるかは、制御サーバ11の要求処理部31へシーケンスデータを格納しておくことにより、自由に設定可能である。設定は、前述の管理コンソールを介して行なわれる。
【0030】
制御サーバ11の履歴表32が図6に示したような状態の時に、予測部33が予測動作を開始したと仮定する。予測部33は履歴表32のエントリ40を検索し、識別子「本」が登録されている状態フィールドに対応するサーバIDフィールドを選択する。一つ以上の本登録状態の下位サーバが複数あれば、いずれか一つを選択する。選択基準は任意に設定可能であるが、最初に「本」にヒットしたサーバIDフィールドに対応する下位サーバを選択すれば、履歴表の検索時間が短くてすむ。図6の状態では、本登録状態の下位サーバが一つしか無いので、サーバ13が選択される。
次に、データ700をエントリ40に記録されていない下位サーバ15にコピーするよう、制御サーバ11からサーバ13に指示パケットを送信する。制御サーバ11はエントリ40の空いているサーバIDフィールドにサーバ15のサーバID15を追加する。エントリ40は図7のようになる。サーバ13は指示パケットに従い、データ700をパケットに乗せ、サーバ15に送信する。サーバ15はパケットを受信すると、データ700をキャッシュに登録する。その後、クライアント20がデータ700の取得要求パケットを送信すると、キャッシュサーバ15はキャッシュに保持しているデータ700を乗せた応答パケットを返答する。
(実施例2)
実施例2では、複数の制御サーバを含む階層構造のネットワークに対して本発明を適用した場合の実施例である。図9には、本実施例のネットワーク構成の例を示す。
14、16、21は、それぞれクライアントからもっとも近い位置に存在する第1のルータ群であり、それぞれ複数のクライアント17〜18,19〜20、23〜24を集線している。13、15,22は、それぞれ第1のルータ14、16,21に接続されたキャッシュサーバである。12は第2のルータであり、他ネットワークとの接続部分に配置されている。11は制御サーバであり、第2のルータ12に接続されている。25と27は中間ルータに接続された制御サーバであり、中間制御ルータと称する。26と28は第1のルータと第2のルータ間に配置されたルータ群であり、以下中間ルータ群と称する。第1のルータ群と中間ルータ群とは何らかのネットワークにより接続されている。また、第2のルータと中間ルータ群とは、別のネットワークで接続されている。上記のネットワーク群には、中間制御サーバは配置されていないものとする。
【0031】
本実施例では、ネットワーク上に配置された任意のサーバから見て、クライアントに近い側に配置されるサーバを下位サーバ、コアネットワークに接続しているルータに近い側に配置されるサーバを上位サーバと呼ぶ。図9には図示されていないが、第2のルータ12の上へ延びる回線は、ネットワークトポロジー上、更に奥のネットワーク(コアネットワークと称する)に接続されている。コアネットワークに最も近い制御サーバである制御サーバ11の上位サーバは、個々のクライアントやキャッシュサーバ、ないし中間制御サーバからアクセス要求のあったデータのオリジナルデータを保持するサーバのうち、他ネットワークに存在するサーバである(オリジナルサーバと呼ぶ)。制御サーバ11とオリジナルサーバは、コアネットワークを介して接続されている。
キャッシュサーバ13、15、22は制御サーバ11と直接通信するのではなく、中間制御サーバ25、27と通信を行う。中間制御サーバは、ネットワークにより接続された配下のキャッシュサーバを制御する。例えば、制御サーバ25はキャッシュサーバ13の制御を行い、制御サーバ27は、キャッシュサーバ15と22の制御を行う。制御サーバ11は中間制御サーバ25,27の制御を行う。
【0032】
次に、図9のトポロジーのネットワークの動作例を説明する。ここでは、図9に示すような制御サーバが階層化されたトポロジーのネットワークにおいて、制御サーバ11は予測動作の結果、中間制御サーバ25が制御する任意のキャッシュサーバから中間制御サーバ27が制御するキャッシュサーバ群へデータをコピーすることを決定した場合の動作について説明する。制御サーバ11は、キャッシュサーバに対して直接指示を送信するのではなく、制御サーバ11が制御している中間制御サーバを介して指示を送信する。
【0033】
今、制御サーバ11が、下位サーバ25に下位サーバ27へデータを転送するよう指示を乗せたパケットを送信する。中間制御サーバである制御サーバ25は図10のフローに従い動作を行う。ステップ200で上位サーバである制御サーバ11からの転送指示を受信すると、ステップ201で制御サーバ25の履歴表を検索し、当該データのエントリを選択する。ステップ202でエントリから本登録されている下位サーバを一つ選択する。ここで例えば、キャッシュサーバ13を選択すると、ステップ203において、データ転送指示を乗せたパケットをサーバ13へ送信する。サーバ13はキャッシュからデータを取り出し、応答パケットを制御サーバ25へ返す。
制御サーバ25はステップ204で応答パケットを受信すると、ステップ205においてパケットで指示された制御サーバ27へデータを転送する。受信側制御サーバ27は図12のフローに従い動作する。ステップ500で制御サーバ25からの転送パケットを受信すると、ステップ501で制御サーバ27が制御している全下位サーバへのデータ転送のため、パケットを送信する。ステップ502で、履歴表から当該データに対応したエントリを削除する。
前記実施例において、データは上位サーバを経由して転送してもよい。また、前期実施例においてステップ501で一つ以上の任意の下位サーバを選択し、そのサーバにのみデータを転送し、ステップ502でエントリを削除する代わりに選択した下位サーバをエントリに登録してもよい。本実施例のようにネットワークを階層構造とした場合、あるサーバはその直接の下位サーバのみを管理すればよく、管理するデータ量を抑えることが出来る。従って、実施例1のトポロジーのネットワークに比べて大規模なネットワークにも対応可能である。
(実施例3)
本実施例では、実施例1の制御サーバとは異なるアルゴリズムを用いてデータの需要予測を行う例について、図2を用いて説明する。
パケットハンドラ30が、第2のルータ12からパケットを受信すると、要求処理部31へ受信パケットを転送する。要求処理部31は、予測部33を起動して、データの需要予測を実行させる。
予測部33は、履歴表32を検索して、需要予測を行うIDのデータがデータIDフィールドに格納されているエントリを検索する。目的のデータが格納されたエントリにヒットしたら、予測部33は当該エントリを検索して、計数器38により、空でない状態フィールド、すなわち「仮」または「本」という識別子が記録されている状態フィールドに対応するサーバIDフィールドの個数を計数する。計数されたサーバIDの個数は、計数器から比較器37に入力される。比較器37は、閾値レジスタ35から需要予測判定のための閾値を取得し、入力されたサーバの個数と比較する。計数器で計数されたサーバの個数が閾値よりも大きな場合は、当該データに対する需要が増大していると判断し、閾値よりも小さい場合は、当該データに対するアクセス需要は、現時点以降でも増大しないものと判定される。判定結果は要求処理部31へ送信される。
要求処理部31は、予測部33から送信された結果を基に、コピー命令の実行を行う。実施例1と同様に、予測部33から送信された判定結果が需要増大であった場合には、アクセス要求のあったデータを保持しているキャッシュサーバに対して、アクセス要求元であるキャッシュサーバだけではなく、配下のキャッシュサーバ全てに当該データのコピー命令を送信する。あるいは、オリジナルサーバから送信されたデータを、配下のキャッシュサーバ全部に送信する。予測部33での予測結果が需要増大でなかった場合には、当該データは、アクセス要求のあったキャッシュサーバにのみ転送される。
【0034】
実施例1と同様、制御サーバに管理コンソールを設けることで、装置ユーザが閾値レジスタの値を自由に変更可能である。例えば、閾値として制御サーバ11が管理する下位サーバの過半数を設定しておけば、本登録または仮登録された下位サーバの数が、制御サーバ11の配下のサーバの過半数を超えた場合に、アクセス要求のあったデータが需要増大に転じたと判定される。
また、予測部33に学習機能を設けて閾値レジスタに設定する閾値を最適化しても良いことも、実施例1と同様である。
(実施例4)
本実施例では、本発明のネットワークシステムの、特に第1のルータに適したノード装置の構成について説明する。本実施例のノード装置はパケット選別部を有し、クライアントがオリジナルサーバ宛に送信したデータ要求パケットをキャッシュサーバに転送できる機能を有する。図12には、本実施例のパケット選別部付きのノード装置の構造例を示す。
ルータ14の入力処理部50,52にパケット選別部51,53を追加する。入力処理部52は入力バッファ70と、経路表71と、選択器72を備える。パケット選別器53はフィルタバッファ73と、条件レジスタ74と、比較器75を備える。
入力処理部52に到着したパケットは入力バッファ70とフィルタバッファ73に取り込まれる。入力バッファ70に取り込まれたパケットの特定フィールドは経路表71を検索するキーとして用いられる。フィルタバッファ73に取り込まれたパケットの一部と条件レジスタ74の値を比較器75で比較する。比較結果は選択器72に送られる。選択器72は経路表71の出力である出力処理部55,56,57のうちの一つの番号と、サーバに接続されている出力処理部57の番号を、比較器75の出力により選択する。比較器75が真を出力したとき、比較器72は出力処理部57に対応する番号を出力し、比較器75が偽を出力したとき、比較器72は経路表71の出力を比較器72の出力とする。パケット選別器53で選別する条件として、宛先IPアドレスや、宛先ポート番号や、送り元ポート番号や、URLを用いることが出来る。また、これら複数の条件の和や積とすることもできる。スイッチ部54は各入力処理部50,52の選択器72の出力に基づき、入力バッファ70に保持されているパケットを出力処理部55,56,57のどれかに出力する。
また、ルータ14は単一の装置で選別するのではなく、図13に示すように、選別装置を多段に接続し、それぞれの装置で選別するように構成することも可能である。ルータ14に近い選別器では、宛先IPアドレスのようにパケットの固定位置にある値を用いることで高速な処理をし、サーバに近い選別器では、URLの比較など可変位置にある可変サイズの値の比較が必要な複雑で低速な処理を行うように、パイプライン処理にすることで、全体の処理速度と処理内容の高度化を両立することが出来る。
【0035】
【発明の効果】
本発明によれば、ネットワークのピークトラフィックを抑制することができる。
【図面の簡単な説明】
【図1】分散キャッシュ制御のネットワーク構成例を示す図。
【図2】制御サーバのモジュール構成図。
【図3】タイムスタンプを用いて需要予測を行う方式の履歴表の構造図。
【図4】下位サーバからの要求受信時の動作フロー図。
【図5】履歴表の状態図。
【図6】履歴表の状態図。
【図7】履歴表の状態図。
【図8】履歴表の状態図。
【図9】分散キャッシュ制御方式の階層構成時のネットワーク構成図。
【図10】上位サーバからの転送指示受信時の動作フロー図。
【図11】他サーバからのデータ転送受信時の動作フロー図。
【図12】パケット選別部つきのルータのモジュール構成図。
【図13】多段のパケット選別装置を持つルータ構成図。
【図14】従来技術におけるネットワーク構成図。
【符号の説明】
10・・・ネットワーク、11・・・制御サーバ、12・・・第2のルータ、13、15、22・・・キャッシュサーバ群、14、16・・・第1のルータ群、17〜20、23、24・・・クライアント、25、27・・・中間制御サーバ群、26、28・・・中継ノード装置、30・・・パケットハンドラ、31・・・要求処理部、32・・・履歴表、33・・・予測部、34・・・時計、35・・・閾値レジスタ、36・・・減算器、37・・・比較器、38・・・計数器、40・・・エントリ、41・・・データIDフィールド、42、44,46・・・サーバIDフィールド、43、45、47・・・状態フィールド、48・・・タイムスタンプフィールド、300・・・管理コンソール、301・・・学習機能部。
【発明の属する技術分野】
本発明は、情報通信ネットワークにおいてネットワーク中に分散したキャッシュの制御方法ないし制御装置およびこれらの制御方法が適用されるネットワークシステムに属する。
【0002】
【従来技術】
複数のクライアントが同一データを参照する場合、キャッシュ技術を用いることで、アクセス時に生じるネットワーク・トラフィックがクライアント−キャッシュサーバ間で閉じるため、ネットワーク全体のトラフィック量を抑制できる。しかし、大規模なネットワークで発生するトラフィックは単一のキャッシュサーバでは処理できず、通常、複数のキャッシュサーバが分散して配置される。
【0003】
特開2002−251313号公報には、複数のキャッシュサーバを連携させる技術が開示されている。本文献に開示された発明では、複数のキャッシュサーバを制御する親サーバを設けて、該親サーバ個々のキャッシュサーバが保持しているキャッシュデータの情報を格納する。更に、親サーバは、クライアントから要求のあったデータを配下のキャッシュサーバが保持しているかどうか照会し、要求されたデータを保持している配下のキャッシュサーバが有れば、当該キャッシュサーバより要求データを取得する。または要求を出したクライアントに接続されているキャッシュサーバに当該データを転送させる。このように複数のキャッシュサーバを連携させることにより、外部ネットワークへのアクセス頻度が低減し、クライアントのデータ要求に対する応答時間が短縮される。また、各キャッシュサーバが保持するキャッシュデータの量も低減することが可能である。
【0004】
特開平11−24981号公報には、キャッシュデータの先読み技術が開示されている。本文献に開示された技術では、キャッシュサーバが、アクセスしたファイルを記録するアクセス履歴データベースと、先読み選出モジュールとを備え、アクセス頻度の高いファイルとその更新間隔から次に先読みすべきデータを決定し、ネットワークのトラフィック量が空いている時間帯に予め先読みデータをキャッシュする。本技術によれば、キャッシュヒット率が向上し、ファイルアクセスが高速化する。
【0005】
また、IETF(Internet Engineering Task Force)から発行されているRFC(Request For Comment)2186には、キャッシュサーバを連携させる一方法として、ICP(Internet Cache Protocol)が規定されている。ICPを用いたネットワークの構成例を図14に示す。クライアント17,18はルータ14を介してキャッシュサーバ13に接続され、クライアント19,20はルータ16を介してキャッシュサーバ15に接続されている。ルータ14,16は内部ネットワークを介して上位のルータ12に接続される。ルータ12は外部ネットワークに接続される。ルータ14、16には、各々キャッシュデータを保持するキャッシュメモリを備えたキャッシュサーバが接続されている。
【0006】
ICPでは、クライアントから要求されたデータがキャッシュに無い場合、他のキャッシュに問い合わせ、他のキャッシュが当該データを保持している場合は、そのキャッシュからデータを取り寄せることで、ネットワーク外部へのデータの取得を行わないようにし、応答時間の向上を計っている。
【0007】
【発明が解決しようとする課題】
従来技術においては、問い合わせ時に多くのパケットが発行されるため、ネットワーク内のトラフィックは増加する傾向にある。さらに、短い時間に多くのクライアントから問い合わせが生じると、多くのキャッシュサーバがデータを取得する動作を起こすため、さらにネットワーク・トラフィックは増加する。従って、特定のコンテンツに対し突発的にアクセス要求が発生した場合などには対応できない。
本発明の目的は、ネットワーク上でのピークトラフィックを抑制することにある。
【0008】
【課題を解決するための手段】
本発明の分散キャッシュ制御方式が適用されるネットワークでは、複数のクライアントが接続するネットワークにおいて、複数のキャッシュサーバと複数のキャッシュサーバを制御する制御サーバとを備えることを特徴とする。当該制御サーバは、キャッシュサーバで保持しているデータの状態もしくは状態の変化に基づき、クライアントからアクセス要求のあったデータを保持するキャッシュサーバからデータを保持していないキャッシュサーバへデータをコピーする指示を発行することを特徴とする。
なお、その他の特徴、効果等は、実施例にて詳細に説明される。
【0009】
【発明の実施の形態】
(実施例1)
以下、実施例について、図面を用いて詳細に説明する。
(構成の説明)
図1には、本発明が適用されるネットワークの1形態について示した。17、18、19、20はクライアントであり、例えば、ネットワークに接続しているエンドユーザである。14、16は、複数のクライアントから延びる加入者線を集線する第1のルータ群であり、例えばネットワーク上に配置されたアクセスルータやBAS(Broadband Access Server)、ゲートウェイ等が第1のルータに相当する。第1のルータが集線するクライアントの数は、必ずしも複数である必要はない。便宜上、第1のルータは14、16の2つしか図示していないが、14〜16の間には、内部ネットワークに接続された第1のルータが複数配置されているものとする。以後、制御サーバの配下にある第1のルータの総称としては、「第1のルータ群」という文言を使用する。
13、15はキャッシュサーバであり、キャッシュサーバ13は第1のルータ14に、キャッシュサーバ15は第1のルータ16とそれぞれ接続している。12は複数の第1のルータ群14、16を更に集線する第2のルータであり、クライアントから見てネットワーク上で第1のルータの奥側に配置されている。第1のルータと第2のルータとは、内部ネットワークで接続されており、内部ネットワークとは、例えば、LANやその他の閉鎖網である。
10は、第1のルータ群とキャッシュサーバ、第2のルータおよび内部ネットワークを含むネットワークを示す。このようなネットワークの例としては、例えば、エンドユーザがインターネットに接続するためのアクセス網がある。図示されていないが、第2のルータ12から上に延びる線の更に上方には、10とは異なるネットワークが存在しており、本実施例の第2のルータは、他ネットワークとの接続部分に配置されている。
【0010】
第2のルータには制御サーバ11が接続されており、複数のキャッシュサーバ13、15の動作を制御している。具体的には、個々のキャッシュサーバから上がってくるキャッシュデータの要求を監視し、監視結果に基づきアクセス要求が多くなると予測されたデータのコピー命令を、配下にあるキャッシュサーバへ送信する。
更に詳細な制御サーバの動作ステップについては、後段の「動作の説明」の欄で詳述する。
【0011】
図2には、制御サーバ11の構成例を示した。30はパケットの送受信を司るパケットハンドラであり、例えば、パケットの入出力インタフェースカード等で構成される。31は配下のキャッシュサーバからの要求や応答を処理する要求処理部であり、プロセッサやASIC等で実現される。履歴表32は、配下のキャッシュサーバや下位の制御サーバからの要求の履歴が記録されるテーブルであり、メモリやハードディスクなどの記憶手段により構成される。要求処理部31は、データ処理の際に履歴表32を参照する。33は予測部であり、履歴表32の情報を元に将来のアクセス予測を行う。301は学習機能部である。後述するが、学習機能部は必ずしも必須ではない。アクセス予測を実行するには種々の方法があり、予測部33の内部構成は予測方法に応じて変わるが、ここでは、本実施例では、タイムスタンプによりアクセス予測を行なう場合の予測部の内部構成について示す。
本実施例での予測部33は、現在の時刻を示す時計34、履歴表のエントリ40に含まれる登録されているサーバIDの個数を数える計数機38、タイムスタンプフィールド40の値と時計34の値の差を求める減算器36と、予測条件を保持する閾値レジスタ35と、計数機38の出力もしくは減算器36の出力と閾値レジスタ35の値を比較する比較器37を備えている。
【0012】
図3には、予測手法としてタイムスタンプを用いた場合の履歴表の構成例を示した。履歴表32はエントリ40の集合から構成され、エントリ40は更に、実際にデータが格納される複数のフィールドにより構成されている。デフォルトの状態では、各フィールドは空白である。
41は、要求されたデータのIDを記録するデータIDフィールドである。ここで、データIDとは、クライアントから要求されたデータやコンテンツ等に対して付与されるユニークな識別子であり、例えば、データの格納先のURLやIPアドレス等が格納される。要求データに対して通し番号を付けても良い。42、44、46は、データIDフィールド41に格納されるデータを要求した直接の下位サーバのIDを記録するサーバIDフィールドである。
ここで「直接の下位サーバ」とは、自己が管理しているサーバのことであり、図1のネットワークシステムにおいては、第2のルータに対する「直接のサーバ」に相当するサーバは、キャッシュサーバ13、15となる。内部ネットワーク内に更に中継ノード装置が存在し、中継ノード装置に制御機能を備えたサーバが接続されていれば、制御サーバ11が直接管理するサーバは中継ノード装置に接続されたサーバとなるため、「直接の下位サーバ」とは当該内部ネットワークに配置されたノード装置となる。
サーバIDとは、「直接の下位サーバ」に付与されたユニークな識別子であり、例えば、各下位サーバのIPアドレスである。第2のルータが集線しているルータないしノード装置に対しユニークな番号を付与して、この番号をサーバIDフィールドに格納しても良い。但しこの場合、サーバIDと各サーバのIPアドレスの対応テーブルを管理する必要が出てくるため、管理が多少複雑になる。
各サーバIDフィールドと対をなして、各サーバにおけるキャッシュデータの登録状態を記録する状態フィールド43,45,47が設けられる。状態フィールドには、所定のキャッシュデータが、本登録状態か仮登録状態かを示す識別子が格納される。48は、エントリ40にサーバIDを登録した最終時刻を保持するタイムスタンプフィールドである。
【0013】
第2のルータ12は、配下にある第1のルータからのデータ要求パケット、ないしクライアントより要求のあったデータを元々保有しているオリジナルサーバからのデータ転送パケットを受け取ると、制御サーバに対して受信したパケットを転送する。受信パケット自体を転送する他に、受信パケットからヘッダ情報を切り出して転送しても良い。あるいは、受信パケットのコピーデータを制御サーバに転送しても良い。
パケットハンドラ30は、第2のルータからパケットを受信すると、要求処理部31へ受信パケットを転送する。要求処理部31は、予測部33を起動して、アクセス要求のあったデータあるいはオリジナルサーバから転送されてきたデータ(以下、単に”データ”と称する)の需要予測を実行させる。
【0014】
予測部33は、履歴表32を参照して該当エントリのタイムスタンプフィールドから該当データの直近の登録時刻を取得する。また、予測部33は、要求処理部31から起動命令を受信した時刻を時計34から取得する。時計34は、例えば、プロセッサに付随しているカウンタクロック等により実現可能である。取得された登録時刻と現在時刻とは減算器36に入力され、現在時刻と登録時刻との差が計算される。計算された差は、閾値レジスタ35に格納された閾値データとともに比較器に入力される。この差が、閾値レジスタに格納された値よりも小さい場合は、当該データに対するアクセス要求の間隔が閾値を超えたと判定される。すなわち、当該データに対する需要が現時点以降も増大すると判定される。格納された値よりも差が大きい場合は、当該データに対するアクセス要求の間隔がまだ閾値を越えておらず、当該データに対するアクセス需要は、現時点以降でも増大しないものと判定される。判定結果は要求処理部31へ送信される。
【0015】
要求処理部31は、予測部33から送信された結果を基に、コピー命令の実行を行う。予測部33から送信された判定結果が需要増大であった場合には、アクセス要求のあったデータを保持しているキャッシュサーバに対して、アクセス要求元であるキャッシュサーバだけではなく、配下のキャッシュサーバ全てに当該データのコピー命令を送信する。あるいは、オリジナルサーバから送信されたデータを、配下のキャッシュサーバ全部に送信する。予測部33での予測結果が需要増大でなかった場合には、当該データは、アクセス要求のあったキャッシュサーバにのみ転送される。
予測動作によるデータコピーは、将来発生するであろうクライアントからのデータ要求によるキャッシュサーバ間のデータ移動を、予測動作時まで先行して実行することを意味する。従って、本実施例を実施することにより、トラフィックがピークとなる時刻をシフトする、つまりピークトラフィックの平坦化が可能となる。
なお、本実施例の制御サーバは、数値の入力手段と操作画面とを有する管理コンソール300を備えており、閾値レジスタ35に保持させる値は装置ユーザが自由に変更可能である。
【0016】
また、制御サーバに学習機能を与えて閾値レジスタ35に保持させる値を最適化させても良い。このため、学習機能部301が設けられる。もし予測動作を行うより前に、制御サーバに配下の過半数のキャッシュサーバから要求が届いた場合、コピー指示の発行が遅れたと見なし、コピー指示の発行タイミングを早めるため、閾値レジスタの値を大きくする。一方、クライアントからの要求到着がコピー指示のタイミングに比べ遅い場合には、コピー指示の発行を遅らせるため閾値レジスタの値を小さくする。
【0017】
閾値レジスタ35の値を小さくするためにはクライアントからの要求到着がコピー指示のタイミングに比べ遅いということを判定する必要がある。従って、キャッシュサーバは、コピー指示命令が到着してからクライアントからの要求到着までにかかった時間を計測し、計測結果を制御サーバ11に送信する。このため、各キャッシュサーバは、時間を計測するための計時手段と、時間を計測したデータのデータIDと計測した時間とを対比して記憶する記録手段とを有する。記憶手段としては、例えば、メモリやディスク装置などに形成される管理テーブルでもよいし、あるいはデータIDと時間データをレジスタに直接格納してもよい。
学習動作を行なう場合、まず要求予測部31が学習機能部301を起動する。学習機能部301は、起動すると、キャッシュサーバが送信する、クライアントから送信されたデータIDと時間データの受信をパケットハンドラ30に要求し、パケットハンドラが送信するデータを計測結果表に格納する。代表値選択器は計測結果表に格納されたデータから代表値を計算、あるいは選択し、比較器に入力する。一方、比較閾値調節レジスタには、所定の閾値(調節閾値と称する)が格納されており、比較器は、代表値が入力されると調節閾値レジスタから閾値を取り込み、代表値と閾値とを比較する。
代表値が閾値よりも大きければ、クライアントからの要求到着がコピー指示のタイミングに比べ遅いと判定し、閾値レジスタに格納された閾値を、加減算器にて所定の負の値だけインクリメントする。代表値としては、各キャッシュサーバで計測された時間の累計データや計測時間の平均値などを用いることができる。また、インクリメントする値は、閾値レジスタや調節閾値レジスタ、あるいは加減算器内部のレジスタに格納しておけば良い。また、インクリメント値も、管理コンソールにてユーザが自由に設定可能である。
【0018】
履歴表32は、要求処理部31からの指示によりエントリが更新された時、更新されたエントリを学習機能部301に送信する。学習機能部301は受信したエントリを計数機に入力する。計数機はエントリに登録されているサーバIDを数え、比較器に入力する。一方、比較閾値レジスタには、所定の閾値(調節閾値と称する)が格納されており、比較器は、登録済みのサーバIDの個数(登録個数と称する)が入力されると、登録個数と調整閾値とを比較する。
登録個数が調整閾値より大きければ、予測動作を開始すべきだと判定し、加減算器に閾値レジスタに格納された閾値を、インクリメントするよう指示を出す。加減算器は、予測部が予測動作を開始していない時点でインクリメント指示を受け取った場合、閾値レジスタに格納された閾値を、所定の正の値でインクリメントする。インクリメントする値は、閾値レジスタや調節閾値レジスタ、あるいは加減算器内部のレジスタに格納しておけば良い。また、インクリメント値も、管理コンソールにてユーザが自由に設定可能である。
【0019】
学習動作を実行させるタイミングとしては、例えば、コピーデータを配下の管理サーバへ送信した時点がある。各々のキャッシュサーバは、自分がアクセス要求を行っていないデータIDのデータが制御サーバ11より送信されてきた場合、コピーデータが送信されたと判定して、時間計測を開始する。クライアントから当該データIDのデータのアクセス要求パケットが届いた場合、計測をやめ、計測時間データとデータIDとを制御サーバ11に送信する。
また、計測した時間データを制御サーバに送信する場合、2通りの方法がある。1つは、時間計測データをサーバIDの如何を問わず全て制御サーバに送信する方法であり、もう一つは、計測時間が判定のしきい値よりも大きい場合にのみ計測データを制御サーバへ送信し、小さい場合は送信しない方法である。後者の場合、制御サーバとキャッシュサーバ間のトラフィック量を低減できるという利点がある。
(動作の説明)
図1のトポロジーを有するネットワークシステムの動作形態は、以下の3種類の形態があると考えられる。
1)ネットワークシステム内に配置されたいずれのキャッシュサーバにもデータがキャッシュされていない場合。
2)ネットワークシステム内に配置されたいずれかのキャッシュサーバに、既にデータがキャッシュされており、当該データをキャッシュしていないキャッシュサーバからアクセス要求が発行される場合。
3)複数のキャッシュサーバから同じデータに対してアクセス要求が発行された場合。
まず、ネットワークシステム内にあるキャッシュサーバのいずれにもデータがキャッシュされていない場合である第1の動作例について説明する。
第1の動作例は、図4に記載したフローチャートのステップ100〜117を用いて説明される。例えば、図1のトポロジーを有するネットワークにおいて、クライアント17が、所定のデータIDのデータを取得しようとする場合、データ要求パケットをキャッシュサーバ13に送信することで前記データを要求する。本実施例では、データIDが700なる番号のデータを取得しようとしてデータ要求パケットを送信したものとする。データIDとしては、数字の他、任意の識別子を使用してよく、要はデータとデータIDとの関係が一位に定まるものであれば何でも良い。要求データのデータオリジナルサーバのURL(Unified Resource Locator)を使用しても良い。例えば、URLがhttp://www.xxx.com/id#700であったとすると、データIDとしてhttp://www.xxx.com/id#700をそのまま使用して構わない。クライアント17がキャッシュサーバ13のIPアドレスを知らない場合には、データ要求パケットをオリジナルサーバに送信する。いずれの場合でも、クライアントから送信されたデータ要求パケットは必ず第1のルータを通過することになる。第1のルータ14は、クライアントからのデータ要求パケットを受信すると、受信パケットをキャッシュサーバ13に転送する。キャッシュサーバ13は、要求されたデータを保持していない場合、更に新たなデータ要求パケットを制御サーバ11に送信する。
【0020】
次に、図4のフローチャートを用いて、制御サーバの動作フローについて説明する。
制御サーバ11は、ステップ100でデータ取得の要求を受信すると、ステップ101にて、データIDフィールドにアクセス要求を受けたデータのIDが格納されたエントリの有無を履歴表32で確認する。エントリが存在しないことは、当該IDのデータは過去にアクセス要求の無かったデータであることを意味する。ステップ102において、制御サーバ11の上位サーバに向けてデータ取得の要求パケットを送信する。図1のネットワークシステムの場合には、アクセス要求のあったデータを保持するオリジナルサーバへデータ要求パケットを送信する。
データ要求パケットの送信後、ステップ103において、履歴表32にエントリ40を新規に作成し、データIDフィールド 41に、データID 700を登録する。その後、ステップ104において、当該サーバに直接要求を送信した下位サーバのIDをサーバ IDフィールド 42に書き込む。図1に示したトポロジーのネットワークの場合、制御サーバ11に対する下位サーバとしては、キャッシュサーバ13、15のいずれかが該当し、この場合は、データ要求パケットを送信したキャッシュサーバ13のサーバIDである13がサーバIDフィールドに記録される。サーバIDとしては、13のような数字の他、IPアドレス等、各キャッシュサーバに付与した任意の識別子を用いることが可能である。状態フィールド43には、仮登録を示す値が書き込まれる。
【0021】
図5には、ステップ104が終了した後の履歴表32の状態を示した。データIDフィールドにデータID700が格納されたエントリ40が作成され、1番目のサーバIDフィールドにはサーバID13が格納されている。1番目のサーバIDフィールドと対となる1番目の状態フィールド43には、仮登録を示す状態値「仮」が格納されている。図1のトポロジーのネットワークの場合、エントリ40に作成されるサーバIDフィールドは、制御サーバ11の配下にあるキャッシュサーバの数と等しい数だけ生成される。ステップ104が終了した段階では、他のサーバIDフィールドおよび状態フィールド44〜47、タイムスタンプフィールド48は空白である。
【0022】
ステップ105で上位サーバからの応答パケット603を受信すると、ステップ106 で応答パケット中の応答コードを確認する。ここで、「応答コード」とは、要求したデータがオリジナルサーバにあったかなかったかを示す識別子であり、応答パケットに格納されている。要求データがオリジナルサーバになかった場合は、応答エラーを示す応答コードがパケットに付与される。応答コードがエラーでなければ、ステップ107に進み、当該エントリ40の状態フィールドに「仮」が記録された下位サーバ13に対して、制御サーバ11は、応答データパケットを送信する。応答データパケットの送信後、ステップ108にて、エントリ40のサーバID13の状態フィールドに本登録状態を示す状態値「本」を記録する。キャッシュサーバ13は、制御サーバから応答データパケット を受け取ると、キャッシュにデータを登録し、更にデータを要求したクライアント17に応答データパケット605を送信する。
ステップ106にて、応答コードがエラーと判断された場合、ステップ116へ処理を進め、エントリ40のサーバIDフィールドが空白でないサーバ全てに応答エラーを通知し、ステップ117で当該エントリを削除する。
【0023】
図6には、図7のステップ108を終了した後の履歴表32の状態を示す。図5に示した履歴表のエントリに比べて、状態フィールド43の値が「本」に変わっていることが判る。
【0024】
次に、すでにデータをキャッシュしているキャッシュサーバがある状態で、別のキャッシュサーバが要求を発行した場合である第2の動作例について説明する。
図1のトポロジーを有するネットワークにおいて、キャッシュサーバ13はデータIDが700のデータをキャッシュしているものとする。この場合、制御サーバ11の履歴表32には、図6に示すようなエントリ40が作成されている。つまり、サーバIDフィールドに既にデータをキャッシュしているサーバのIDが、また当該サーバIDフィールドに対応する状態フィールドに本登録状態であることを示す識別子「本」がそれぞれ格納されている。クライアント20がデータ700を取得する場合、要求パケットをキャッシュサーバ15または第1のルータ16に送信する。キャッシュサーバ15は、自己のキャッシュにデータ700を保持していないと判断すると、要求パケットを制御サーバ11に送信する。制御サーバ11は、キャッシュサーバ15からの要求を受信するが、この動作が図7のステップ100に相当する。
【0025】
以下は、図7を用いて制御サーバの動作を説明する。下位サーバであるキャッシュサーバ15からのデータアクセス要求を受信すると、制御サーバ11の要求処理部31は、ステップ101の動作を開始する。ステップ101では、履歴表32にデータ700のエントリ40があるため、ステップ111に処理を進める。エントリ40の状態フィールド43が本登録になっているため、ステップ111ではステップ113に処理を進める。
ステップ113ではエントリ40から本登録状態になっているサーバIDから一つを選択する。この動作は、要求処理部31によって実行される。ここでは、サーバIDフィールド42に記録されているキャッシュサーバ13が選択される。次のステップ114で選択されたキャッシュサーバ13に指示パケットが送信される。ステップ115でエントリ40のサーバIDフィールド44に15を、状態フィールド45に本登録を書き込むことで、エントリ40は図7に示した状態となる。
キャッシュサーバ13は、指示パケットを受信すると、指示に従いID700のデータを載せた転送パケットをキャッシュサーバ15へ送信する。キャッシュサーバ15は転送パケットを受信すると、キャッシュにデータ700を登録し、応答パケットをクライアント20へ送信する。
【0026】
最後に、複数のキャッシュサーバから同じデータに対してアクセス要求が発行された場合である第3の動作例について説明する。
図1に示すトポロジーを有するネットワークにおいて、クライアント17とクライアント20が同じデータ700の取得を試みた場合を考える。この場合、クライアント17からのデータアクセス要求が最初に制御サーバに到達し、クライアント20の発行したデータアクセス要求はその後に制御サーバに到達するものとする。
まず、クライアント17は、データ要求パケットをキャッシュサーバ13に送信する。キャッシュサーバ13はデータ700を保持していない場合、要求パケットを制御サーバ11に送信する。
制御サーバ11は図7の制御フローに従い動作し、ステップ100から104まで実行し、上位サーバに要求パケットを送信する。ステップ104の実行後、履歴表32のエントリ40は図5に示すように、データIDフィールド41が700、サーバIDフィールド42が13、状態フィールド43が仮登録となる。クライアント20はキャッシュサーバ15に要求パケットを送信し、キャッシュサーバ15は要求パケットを制御サーバ11に送信する。制御サーバ11は図7の制御フローに従い動作し、ステップ100でパケットを受信した後、ステップ101で履歴表32をチェックする。クライアント17からのアクセス要求に対する応答がステップ104まで実行されているので、履歴表32には、データIDフィールドの値が700であるエントリ40が存在する。よって、制御サーバ11はステップ111に処理を進める。ステップ111ではエントリ40をチェックする。オリジナルサーバからの応答がまだ帰ってきていないので、先に作成されたサーバIDフィールド42に対応する状態フィールド43は本登録状態になっていない。そこで、制御サーバ11は、ステップ112に処理を進める。要求処理部31は、エントリ40の空きサーバIDフィールドにキャッシュサーバ15のサーバIDを記録する。図8に、ステップ112が実行された後の履歴表32の状態を示す。
上位サーバからの応答パケットが制御サーバ11に到着すると、制御サーバ11はステップ105から処理を再開し、ステップ107において、応答パケットをキャッシュサーバ13と15にそれぞれ送信する。キャッシュサーバ13と15は、制御サーバから送信された応答パケット中のデータをキャッシュに登録し、それぞれのクライアント17と20にアクセス要求のあったデータを応答パケットとして送信する。
【0027】
なお、クライアント17と20のアクセス要求が制御サーバ11に転送されるまでのタイムラグが大きく、クライアント20からのアクセス要求が制御サーバ11に届いたのが上位サーバからの応答を制御サーバ11が受信した後になった場合、クライアント20からのアクセス要求に対する応答は、図4のフローチャートにおいて、ステップ101→ステップ111→ステップ113の経路で処理される。
また、クライアント17と20からのデータアクセス要求がほぼ同時に制御サーバ11へ転送された場合、少しでも先に到着した方のデータアクセス要求が先に処理される。このため、制御サーバ11のパケットハンドラ30は、受信したデータ要求パケットをキューイングするためのバッファメモリを備えている。
【0028】
次に、予測動作時の動作について説明する。
まず、図4のフローチャートを用いて予測動作が発生するタイミングについて説明する。一つの例としては、要求元キャッシュサーバを履歴表に本登録した時点(図4のステップ110)である。また、もう一つの例としては、要求元キャッシュサーバを履歴表32に仮登録する時点(図4のステップ104および112)である。更にもう一つの例としては、既に本登録済みのキャッシュサーバを選択する時点(図4のステップ113の時点)である。
【0029】
予測動作が図4のステップ110、104または112で発生する場合、要求元キャッシュサーバにデータを転送する時点(図4の107)で、要求元キャッシュサーバだけでなく、予測動作によってデータの宛先となったキャッシュサーバにもまとめてデータを送信する。
また、予測動作が図4のステップ113の時点で発生する場合、コピー指示を送信する時点(図4の114)で、要求元キャッシュサーバだけでなく、予測動作によってデータの宛先となったキャッシュサーバにもコピーデータを送るように指示が出される。
いずれの時点で予測動作を発生させるかは、制御サーバ11の要求処理部31へシーケンスデータを格納しておくことにより、自由に設定可能である。設定は、前述の管理コンソールを介して行なわれる。
【0030】
制御サーバ11の履歴表32が図6に示したような状態の時に、予測部33が予測動作を開始したと仮定する。予測部33は履歴表32のエントリ40を検索し、識別子「本」が登録されている状態フィールドに対応するサーバIDフィールドを選択する。一つ以上の本登録状態の下位サーバが複数あれば、いずれか一つを選択する。選択基準は任意に設定可能であるが、最初に「本」にヒットしたサーバIDフィールドに対応する下位サーバを選択すれば、履歴表の検索時間が短くてすむ。図6の状態では、本登録状態の下位サーバが一つしか無いので、サーバ13が選択される。
次に、データ700をエントリ40に記録されていない下位サーバ15にコピーするよう、制御サーバ11からサーバ13に指示パケットを送信する。制御サーバ11はエントリ40の空いているサーバIDフィールドにサーバ15のサーバID15を追加する。エントリ40は図7のようになる。サーバ13は指示パケットに従い、データ700をパケットに乗せ、サーバ15に送信する。サーバ15はパケットを受信すると、データ700をキャッシュに登録する。その後、クライアント20がデータ700の取得要求パケットを送信すると、キャッシュサーバ15はキャッシュに保持しているデータ700を乗せた応答パケットを返答する。
(実施例2)
実施例2では、複数の制御サーバを含む階層構造のネットワークに対して本発明を適用した場合の実施例である。図9には、本実施例のネットワーク構成の例を示す。
14、16、21は、それぞれクライアントからもっとも近い位置に存在する第1のルータ群であり、それぞれ複数のクライアント17〜18,19〜20、23〜24を集線している。13、15,22は、それぞれ第1のルータ14、16,21に接続されたキャッシュサーバである。12は第2のルータであり、他ネットワークとの接続部分に配置されている。11は制御サーバであり、第2のルータ12に接続されている。25と27は中間ルータに接続された制御サーバであり、中間制御ルータと称する。26と28は第1のルータと第2のルータ間に配置されたルータ群であり、以下中間ルータ群と称する。第1のルータ群と中間ルータ群とは何らかのネットワークにより接続されている。また、第2のルータと中間ルータ群とは、別のネットワークで接続されている。上記のネットワーク群には、中間制御サーバは配置されていないものとする。
【0031】
本実施例では、ネットワーク上に配置された任意のサーバから見て、クライアントに近い側に配置されるサーバを下位サーバ、コアネットワークに接続しているルータに近い側に配置されるサーバを上位サーバと呼ぶ。図9には図示されていないが、第2のルータ12の上へ延びる回線は、ネットワークトポロジー上、更に奥のネットワーク(コアネットワークと称する)に接続されている。コアネットワークに最も近い制御サーバである制御サーバ11の上位サーバは、個々のクライアントやキャッシュサーバ、ないし中間制御サーバからアクセス要求のあったデータのオリジナルデータを保持するサーバのうち、他ネットワークに存在するサーバである(オリジナルサーバと呼ぶ)。制御サーバ11とオリジナルサーバは、コアネットワークを介して接続されている。
キャッシュサーバ13、15、22は制御サーバ11と直接通信するのではなく、中間制御サーバ25、27と通信を行う。中間制御サーバは、ネットワークにより接続された配下のキャッシュサーバを制御する。例えば、制御サーバ25はキャッシュサーバ13の制御を行い、制御サーバ27は、キャッシュサーバ15と22の制御を行う。制御サーバ11は中間制御サーバ25,27の制御を行う。
【0032】
次に、図9のトポロジーのネットワークの動作例を説明する。ここでは、図9に示すような制御サーバが階層化されたトポロジーのネットワークにおいて、制御サーバ11は予測動作の結果、中間制御サーバ25が制御する任意のキャッシュサーバから中間制御サーバ27が制御するキャッシュサーバ群へデータをコピーすることを決定した場合の動作について説明する。制御サーバ11は、キャッシュサーバに対して直接指示を送信するのではなく、制御サーバ11が制御している中間制御サーバを介して指示を送信する。
【0033】
今、制御サーバ11が、下位サーバ25に下位サーバ27へデータを転送するよう指示を乗せたパケットを送信する。中間制御サーバである制御サーバ25は図10のフローに従い動作を行う。ステップ200で上位サーバである制御サーバ11からの転送指示を受信すると、ステップ201で制御サーバ25の履歴表を検索し、当該データのエントリを選択する。ステップ202でエントリから本登録されている下位サーバを一つ選択する。ここで例えば、キャッシュサーバ13を選択すると、ステップ203において、データ転送指示を乗せたパケットをサーバ13へ送信する。サーバ13はキャッシュからデータを取り出し、応答パケットを制御サーバ25へ返す。
制御サーバ25はステップ204で応答パケットを受信すると、ステップ205においてパケットで指示された制御サーバ27へデータを転送する。受信側制御サーバ27は図12のフローに従い動作する。ステップ500で制御サーバ25からの転送パケットを受信すると、ステップ501で制御サーバ27が制御している全下位サーバへのデータ転送のため、パケットを送信する。ステップ502で、履歴表から当該データに対応したエントリを削除する。
前記実施例において、データは上位サーバを経由して転送してもよい。また、前期実施例においてステップ501で一つ以上の任意の下位サーバを選択し、そのサーバにのみデータを転送し、ステップ502でエントリを削除する代わりに選択した下位サーバをエントリに登録してもよい。本実施例のようにネットワークを階層構造とした場合、あるサーバはその直接の下位サーバのみを管理すればよく、管理するデータ量を抑えることが出来る。従って、実施例1のトポロジーのネットワークに比べて大規模なネットワークにも対応可能である。
(実施例3)
本実施例では、実施例1の制御サーバとは異なるアルゴリズムを用いてデータの需要予測を行う例について、図2を用いて説明する。
パケットハンドラ30が、第2のルータ12からパケットを受信すると、要求処理部31へ受信パケットを転送する。要求処理部31は、予測部33を起動して、データの需要予測を実行させる。
予測部33は、履歴表32を検索して、需要予測を行うIDのデータがデータIDフィールドに格納されているエントリを検索する。目的のデータが格納されたエントリにヒットしたら、予測部33は当該エントリを検索して、計数器38により、空でない状態フィールド、すなわち「仮」または「本」という識別子が記録されている状態フィールドに対応するサーバIDフィールドの個数を計数する。計数されたサーバIDの個数は、計数器から比較器37に入力される。比較器37は、閾値レジスタ35から需要予測判定のための閾値を取得し、入力されたサーバの個数と比較する。計数器で計数されたサーバの個数が閾値よりも大きな場合は、当該データに対する需要が増大していると判断し、閾値よりも小さい場合は、当該データに対するアクセス需要は、現時点以降でも増大しないものと判定される。判定結果は要求処理部31へ送信される。
要求処理部31は、予測部33から送信された結果を基に、コピー命令の実行を行う。実施例1と同様に、予測部33から送信された判定結果が需要増大であった場合には、アクセス要求のあったデータを保持しているキャッシュサーバに対して、アクセス要求元であるキャッシュサーバだけではなく、配下のキャッシュサーバ全てに当該データのコピー命令を送信する。あるいは、オリジナルサーバから送信されたデータを、配下のキャッシュサーバ全部に送信する。予測部33での予測結果が需要増大でなかった場合には、当該データは、アクセス要求のあったキャッシュサーバにのみ転送される。
【0034】
実施例1と同様、制御サーバに管理コンソールを設けることで、装置ユーザが閾値レジスタの値を自由に変更可能である。例えば、閾値として制御サーバ11が管理する下位サーバの過半数を設定しておけば、本登録または仮登録された下位サーバの数が、制御サーバ11の配下のサーバの過半数を超えた場合に、アクセス要求のあったデータが需要増大に転じたと判定される。
また、予測部33に学習機能を設けて閾値レジスタに設定する閾値を最適化しても良いことも、実施例1と同様である。
(実施例4)
本実施例では、本発明のネットワークシステムの、特に第1のルータに適したノード装置の構成について説明する。本実施例のノード装置はパケット選別部を有し、クライアントがオリジナルサーバ宛に送信したデータ要求パケットをキャッシュサーバに転送できる機能を有する。図12には、本実施例のパケット選別部付きのノード装置の構造例を示す。
ルータ14の入力処理部50,52にパケット選別部51,53を追加する。入力処理部52は入力バッファ70と、経路表71と、選択器72を備える。パケット選別器53はフィルタバッファ73と、条件レジスタ74と、比較器75を備える。
入力処理部52に到着したパケットは入力バッファ70とフィルタバッファ73に取り込まれる。入力バッファ70に取り込まれたパケットの特定フィールドは経路表71を検索するキーとして用いられる。フィルタバッファ73に取り込まれたパケットの一部と条件レジスタ74の値を比較器75で比較する。比較結果は選択器72に送られる。選択器72は経路表71の出力である出力処理部55,56,57のうちの一つの番号と、サーバに接続されている出力処理部57の番号を、比較器75の出力により選択する。比較器75が真を出力したとき、比較器72は出力処理部57に対応する番号を出力し、比較器75が偽を出力したとき、比較器72は経路表71の出力を比較器72の出力とする。パケット選別器53で選別する条件として、宛先IPアドレスや、宛先ポート番号や、送り元ポート番号や、URLを用いることが出来る。また、これら複数の条件の和や積とすることもできる。スイッチ部54は各入力処理部50,52の選択器72の出力に基づき、入力バッファ70に保持されているパケットを出力処理部55,56,57のどれかに出力する。
また、ルータ14は単一の装置で選別するのではなく、図13に示すように、選別装置を多段に接続し、それぞれの装置で選別するように構成することも可能である。ルータ14に近い選別器では、宛先IPアドレスのようにパケットの固定位置にある値を用いることで高速な処理をし、サーバに近い選別器では、URLの比較など可変位置にある可変サイズの値の比較が必要な複雑で低速な処理を行うように、パイプライン処理にすることで、全体の処理速度と処理内容の高度化を両立することが出来る。
【0035】
【発明の効果】
本発明によれば、ネットワークのピークトラフィックを抑制することができる。
【図面の簡単な説明】
【図1】分散キャッシュ制御のネットワーク構成例を示す図。
【図2】制御サーバのモジュール構成図。
【図3】タイムスタンプを用いて需要予測を行う方式の履歴表の構造図。
【図4】下位サーバからの要求受信時の動作フロー図。
【図5】履歴表の状態図。
【図6】履歴表の状態図。
【図7】履歴表の状態図。
【図8】履歴表の状態図。
【図9】分散キャッシュ制御方式の階層構成時のネットワーク構成図。
【図10】上位サーバからの転送指示受信時の動作フロー図。
【図11】他サーバからのデータ転送受信時の動作フロー図。
【図12】パケット選別部つきのルータのモジュール構成図。
【図13】多段のパケット選別装置を持つルータ構成図。
【図14】従来技術におけるネットワーク構成図。
【符号の説明】
10・・・ネットワーク、11・・・制御サーバ、12・・・第2のルータ、13、15、22・・・キャッシュサーバ群、14、16・・・第1のルータ群、17〜20、23、24・・・クライアント、25、27・・・中間制御サーバ群、26、28・・・中継ノード装置、30・・・パケットハンドラ、31・・・要求処理部、32・・・履歴表、33・・・予測部、34・・・時計、35・・・閾値レジスタ、36・・・減算器、37・・・比較器、38・・・計数器、40・・・エントリ、41・・・データIDフィールド、42、44,46・・・サーバIDフィールド、43、45、47・・・状態フィールド、48・・・タイムスタンプフィールド、300・・・管理コンソール、301・・・学習機能部。
Claims (14)
- 複数のクライアントが接続されたキャッシュサーバと、該複数のキャッシュサーバを制御する制御サーバとを有し、
該制御サーバは、前記キャッシュサーバに対して将来アクセス要求されるデータを予測し、
該予測されたデータに対して現在アクセス要求の無いキャッシュサーバへ、該予測されたデータをコピーすることを特徴とするネットワークシステム。 - 請求項1に記載のネットワークシステムにおいて、
前記制御サーバは、キャッシュサーバに格納されたキャッシュデータに対するクライアントからのアクセス履歴を格納したテーブルを有することを特徴とするネットワークシステム。 - 請求項2に記載のネットワークシステムにおいて、前記テーブルにはキャッシュサーバで保持されているデータのIDが格納されていることを特徴とするネットワークシステム。
- 前記複数の制御サーバに接続された上位制御サーバを備えたことを特徴とするネットワークシステム。
- 複数のキャッシュサーバを備えたネットワークのキャッシュ制御方法において、
前記キャッシュサーバに対してアクセス要求されるデータを予測するステップと、
前記複数のキャッシュサーバのうちで前記予測されたデータをキャッシュしているキャッシュサーバから、該予測されたデータを他のキャッシュサーバへコピーするステップとを含むことを特徴とするキャッシュ制御方法。 - 請求項5に記載のキャッシュ制御方法において、
前記ネットワークは、前記複数のキャッシュサーバを制御する制御サーバを有し、
前記予測されたデータをキャッシュしているキャッシュサーバが無い場合には、前記制御サーバが該予測されたデータのオリジナルデータを保持するサーバへデータの転送要求を出すことを特徴とするキャッシュ制御方法。 - 請求項5に記載の分散キャッシュ制御方法において、
前記制御サーバは、キャッシュサーバで保持されているデータのIDの表である履歴表を備え、
前記制御サーバは、該履歴表の状態もしくは状態の変化に基づきアクセス要求されるデータを予測することを特徴とするキャッシュ制御方法。 - 請求項5に記載の分散キャッシュ制御方法において、
前記複数の前記制御サーバを上位の制御サーバで制御することを特徴とするキャッシュ制御方法。 - クライアントに接続された複数のキャッシュサーバに接続される制御サーバであって、
前記複数のキャッシュサーバに対してクライアントから要求されたデータのIDと該データの要求元のキャッシュサーバのIDが記録される履歴表が格納された記憶手段と、
該履歴表に基づき、次にアクセス要求されるデータを予測する予測部と、
予測されたデータをキャッシュしているキャッシュサーバに対して、当該データのコピー命令を送信する要求処理部とを備えたことを特徴とする制御サーバ。 - 請求項9に記載の制御サーバにおいて、
前記予測部は、前記履歴表に既に要求されたデータのIDが登録されているかを判断し、
該データのIDが登録されていない場合には、該履歴表に新しくエントリを作成し、該データの要求元キャッシュサーバのIDを記録し、更に該データのIDを仮登録することを特徴とする制御サーバ。 - 請求項10に記載の制御サーバにおいて、
前記要求処理部は、該データのオリジナルデータを保持するサーバに対し当該データの転送要求を送信し、
該オリジナルデータを保持するサーバから応答を受信した後、前記仮登録状態のIDを本登録状態に変更することを特徴とする制御サーバ。 - 請求項11に記載の制御サーバにおいて、
前記オリジナルデータを保有するサーバから正常に応答を受信した場合、前記エントリ中で仮登録状態のサーバに対し、該応答を転送することを特徴とする制御サーバ。 - 請求項10に記載の制御サーバにおいて、
前記履歴表に既に要求データに対応するエントリがあり、かつ本登録状態のキャッシュサーバが無い場合、当該エントリに要求元キャッシュサーバのIDを仮登録することを特徴とする制御サーバ。 - 請求項10に記載の制御サーバにおいて、
前記履歴表にエントリがあり、かつ本登録状態のキャッシュサーバが複数ある場合、前記予測部は、当該本登録状態のキャッシュサーバの一つを選択し、
前記要求処理部は、当該選択されたキャッシュサーバに対し、前記要求データを前記要求元キャッシュサーバへ転送するよう命令することを特徴とする制御サーバ。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003172773A JP2005010970A (ja) | 2003-06-18 | 2003-06-18 | 分散キャッシュ制御方法、ネットワークシステムおよび当該ネットワークに用いられる制御サーバないしルータ |
US10/862,379 US20040260769A1 (en) | 2003-06-18 | 2004-06-08 | Method and apparatus for distributed cache control and network system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003172773A JP2005010970A (ja) | 2003-06-18 | 2003-06-18 | 分散キャッシュ制御方法、ネットワークシステムおよび当該ネットワークに用いられる制御サーバないしルータ |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2005010970A true JP2005010970A (ja) | 2005-01-13 |
Family
ID=33516159
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003172773A Abandoned JP2005010970A (ja) | 2003-06-18 | 2003-06-18 | 分散キャッシュ制御方法、ネットワークシステムおよび当該ネットワークに用いられる制御サーバないしルータ |
Country Status (2)
Country | Link |
---|---|
US (1) | US20040260769A1 (ja) |
JP (1) | JP2005010970A (ja) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009147578A (ja) * | 2007-12-13 | 2009-07-02 | Fujitsu Telecom Networks Ltd | Ipネットワークにおけるスイッチ装置及びダウンストリームデータ分散配信方法 |
US7653703B2 (en) | 2005-04-27 | 2010-01-26 | Hitachi, Ltd. | Computer system with a packet transfer device using a hash value for transferring a content request |
JP2010097568A (ja) * | 2008-10-20 | 2010-04-30 | Hitachi Ltd | 情報処理システム及び情報処理システムの運用方法 |
JP2010226447A (ja) * | 2009-03-24 | 2010-10-07 | Toshiba Corp | コンテンツ配布システムおよびコンテンツ配布方法 |
WO2010131638A1 (ja) * | 2009-05-11 | 2010-11-18 | パナソニック電工株式会社 | 宅内機器管理システム |
JP2014002634A (ja) * | 2012-06-20 | 2014-01-09 | Nippon Telegr & Teleph Corp <Ntt> | 通信制御システム、集約サーバおよび通信制御方法 |
JPWO2013094047A1 (ja) * | 2011-12-21 | 2015-04-27 | 富士通株式会社 | 管理装置、管理プログラムおよび管理方法 |
US9158732B2 (en) | 2012-02-29 | 2015-10-13 | Fujitsu Limited | Distributed cache system for delivering contents to display apparatus |
US9233304B2 (en) | 2012-03-22 | 2016-01-12 | Empire Technology Development Llc | Load balancing for game |
US9442934B2 (en) | 2011-09-20 | 2016-09-13 | Fujitsu Limited | Distributed cache control technique |
Families Citing this family (51)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7792963B2 (en) * | 2003-09-04 | 2010-09-07 | Time Warner Cable, Inc. | Method to block unauthorized network traffic in a cable data network |
US7213022B2 (en) * | 2004-04-29 | 2007-05-01 | Filenet Corporation | Enterprise content management network-attached system |
US20060085374A1 (en) * | 2004-10-15 | 2006-04-20 | Filenet Corporation | Automatic records management based on business process management |
US20060085245A1 (en) * | 2004-10-19 | 2006-04-20 | Filenet Corporation | Team collaboration system with business process management and records management |
US10402756B2 (en) | 2005-10-19 | 2019-09-03 | International Business Machines Corporation | Capturing the result of an approval process/workflow and declaring it a record |
US20070088736A1 (en) * | 2005-10-19 | 2007-04-19 | Filenet Corporation | Record authentication and approval transcript |
US7856436B2 (en) * | 2005-12-23 | 2010-12-21 | International Business Machines Corporation | Dynamic holds of record dispositions during record management |
US7685367B2 (en) * | 2006-03-08 | 2010-03-23 | Microsoft Corporation | Multi-cache cooperation for response output caching |
US20070239715A1 (en) * | 2006-04-11 | 2007-10-11 | Filenet Corporation | Managing content objects having multiple applicable retention periods |
US8037029B2 (en) * | 2006-10-10 | 2011-10-11 | International Business Machines Corporation | Automated records management with hold notification and automatic receipts |
JP4386926B2 (ja) * | 2007-02-16 | 2009-12-16 | 富士通株式会社 | 暗号通信プログラム、暗号通信方法および暗号通信装置 |
US7991910B2 (en) | 2008-11-17 | 2011-08-02 | Amazon Technologies, Inc. | Updating routing information based on client location |
US8028090B2 (en) | 2008-11-17 | 2011-09-27 | Amazon Technologies, Inc. | Request routing utilizing client location information |
CN101897184B (zh) | 2007-12-11 | 2012-10-10 | 汤姆森许可贸易公司 | 对用户的内容访问进行优化的设备和方法 |
US7962597B2 (en) | 2008-03-31 | 2011-06-14 | Amazon Technologies, Inc. | Request routing based on class |
US8606996B2 (en) | 2008-03-31 | 2013-12-10 | Amazon Technologies, Inc. | Cache optimization |
US7970820B1 (en) | 2008-03-31 | 2011-06-28 | Amazon Technologies, Inc. | Locality based content distribution |
US9218000B2 (en) * | 2009-04-01 | 2015-12-22 | Honeywell International Inc. | System and method for cloud computing |
US9412137B2 (en) * | 2009-04-01 | 2016-08-09 | Honeywell International Inc. | Cloud computing for a manufacturing execution system |
US8555381B2 (en) * | 2009-04-01 | 2013-10-08 | Honeywell International Inc. | Cloud computing as a security layer |
US9495338B1 (en) * | 2010-01-28 | 2016-11-15 | Amazon Technologies, Inc. | Content distribution network |
EP2550788A1 (en) * | 2010-03-25 | 2013-01-30 | Telefonaktiebolaget LM Ericsson (publ) | Caching in mobile networks |
US9003035B1 (en) | 2010-09-28 | 2015-04-07 | Amazon Technologies, Inc. | Point of presence management in request routing |
US10958501B1 (en) | 2010-09-28 | 2021-03-23 | Amazon Technologies, Inc. | Request routing information based on client IP groupings |
US9712484B1 (en) | 2010-09-28 | 2017-07-18 | Amazon Technologies, Inc. | Managing request routing information utilizing client identifiers |
US8452874B2 (en) | 2010-11-22 | 2013-05-28 | Amazon Technologies, Inc. | Request routing processing |
US10467042B1 (en) | 2011-04-27 | 2019-11-05 | Amazon Technologies, Inc. | Optimized deployment based upon customer locality |
WO2013064505A1 (en) * | 2011-10-31 | 2013-05-10 | Nec Europe Ltd. | Method and system for determining a popularity of online content |
US8706805B2 (en) * | 2011-12-19 | 2014-04-22 | International Business Machines Corporation | Information caching system |
US8843820B1 (en) * | 2012-02-29 | 2014-09-23 | Google Inc. | Content script blacklisting for use with browser extensions |
US9154551B1 (en) | 2012-06-11 | 2015-10-06 | Amazon Technologies, Inc. | Processing DNS queries to identify pre-processing information |
US10097448B1 (en) | 2014-12-18 | 2018-10-09 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
US9826064B2 (en) * | 2015-02-23 | 2017-11-21 | Lenovo (Singapore) Pte. Ltd. | Securing sensitive data between a client and server using claim numbers |
US10225326B1 (en) | 2015-03-23 | 2019-03-05 | Amazon Technologies, Inc. | Point of presence based data uploading |
US9832141B1 (en) | 2015-05-13 | 2017-11-28 | Amazon Technologies, Inc. | Routing based request correlation |
JP2017058787A (ja) * | 2015-09-14 | 2017-03-23 | 株式会社東芝 | 無線通信装置、通信装置、無線通信システム |
US10270878B1 (en) | 2015-11-10 | 2019-04-23 | Amazon Technologies, Inc. | Routing for origin-facing points of presence |
US10853482B2 (en) | 2016-06-03 | 2020-12-01 | Honeywell International Inc. | Secure approach for providing combined environment for owners/operators and multiple third parties to cooperatively engineer, operate, and maintain an industrial process control and automation system |
US10075551B1 (en) | 2016-06-06 | 2018-09-11 | Amazon Technologies, Inc. | Request management for hierarchical cache |
US10110694B1 (en) | 2016-06-29 | 2018-10-23 | Amazon Technologies, Inc. | Adaptive transfer rate for retrieving content from a server |
US10310467B2 (en) | 2016-08-30 | 2019-06-04 | Honeywell International Inc. | Cloud-based control platform with connectivity to remote embedded devices in distributed control system |
US10469513B2 (en) | 2016-10-05 | 2019-11-05 | Amazon Technologies, Inc. | Encrypted network addresses |
CN107092973B (zh) * | 2016-11-25 | 2018-05-25 | 口碑(上海)信息技术有限公司 | 一种业务量的预测方法及装置 |
US10831549B1 (en) | 2016-12-27 | 2020-11-10 | Amazon Technologies, Inc. | Multi-region request-driven code execution system |
US11075987B1 (en) | 2017-06-12 | 2021-07-27 | Amazon Technologies, Inc. | Load estimating content delivery network |
US10742593B1 (en) | 2017-09-25 | 2020-08-11 | Amazon Technologies, Inc. | Hybrid content request routing system |
CN107944488B (zh) * | 2017-11-21 | 2018-12-11 | 清华大学 | 基于层次化深度网络的长时序列数据处理方法 |
US11237550B2 (en) | 2018-03-28 | 2022-02-01 | Honeywell International Inc. | Ultrasonic flow meter prognostics with near real-time condition based uncertainty analysis |
US10862852B1 (en) | 2018-11-16 | 2020-12-08 | Amazon Technologies, Inc. | Resolution of domain name requests in heterogeneous network environments |
US11025747B1 (en) | 2018-12-12 | 2021-06-01 | Amazon Technologies, Inc. | Content request pattern-based routing system |
CN112559574B (zh) * | 2020-12-25 | 2023-10-13 | 北京百度网讯科技有限公司 | 数据处理方法、装置、电子设备及可读存储介质 |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU2001243218A1 (en) * | 2000-02-24 | 2001-09-03 | Shin-Ping Liu | Content distribution system |
US6687846B1 (en) * | 2000-03-30 | 2004-02-03 | Intel Corporation | System and method for error handling and recovery |
US7024466B2 (en) * | 2000-04-07 | 2006-04-04 | Movielink, Llc | Network configured for delivery of content for download to a recipient |
US7032031B2 (en) * | 2000-06-23 | 2006-04-18 | Cloudshield Technologies, Inc. | Edge adapter apparatus and method |
JP2002049766A (ja) * | 2000-08-03 | 2002-02-15 | Kddi Corp | コンテンツ提供方法 |
US20020059440A1 (en) * | 2000-09-06 | 2002-05-16 | Hudson Michael D. | Client-side last-element cache network architecture |
US6651141B2 (en) * | 2000-12-29 | 2003-11-18 | Intel Corporation | System and method for populating cache servers with popular media contents |
WO2002059761A1 (en) * | 2001-01-26 | 2002-08-01 | Pictureiq Corporation | Method and apparatus for dynamic optimization and network delivery of multimedia content |
US20030115281A1 (en) * | 2001-12-13 | 2003-06-19 | Mchenry Stephen T. | Content distribution network server management system architecture |
-
2003
- 2003-06-18 JP JP2003172773A patent/JP2005010970A/ja not_active Abandoned
-
2004
- 2004-06-08 US US10/862,379 patent/US20040260769A1/en not_active Abandoned
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7653703B2 (en) | 2005-04-27 | 2010-01-26 | Hitachi, Ltd. | Computer system with a packet transfer device using a hash value for transferring a content request |
JP2009147578A (ja) * | 2007-12-13 | 2009-07-02 | Fujitsu Telecom Networks Ltd | Ipネットワークにおけるスイッチ装置及びダウンストリームデータ分散配信方法 |
JP2010097568A (ja) * | 2008-10-20 | 2010-04-30 | Hitachi Ltd | 情報処理システム及び情報処理システムの運用方法 |
JP2010226447A (ja) * | 2009-03-24 | 2010-10-07 | Toshiba Corp | コンテンツ配布システムおよびコンテンツ配布方法 |
JP5406922B2 (ja) * | 2009-05-11 | 2014-02-05 | パナソニック株式会社 | 宅内機器管理システム |
WO2010131638A1 (ja) * | 2009-05-11 | 2010-11-18 | パナソニック電工株式会社 | 宅内機器管理システム |
US8655975B2 (en) | 2009-05-11 | 2014-02-18 | Panasonic Corporation | Home appliance managing system |
US9442934B2 (en) | 2011-09-20 | 2016-09-13 | Fujitsu Limited | Distributed cache control technique |
JPWO2013094047A1 (ja) * | 2011-12-21 | 2015-04-27 | 富士通株式会社 | 管理装置、管理プログラムおよび管理方法 |
US9501428B2 (en) | 2011-12-21 | 2016-11-22 | Fujitsu Limited | Managing apparatus |
US9158732B2 (en) | 2012-02-29 | 2015-10-13 | Fujitsu Limited | Distributed cache system for delivering contents to display apparatus |
US9233304B2 (en) | 2012-03-22 | 2016-01-12 | Empire Technology Development Llc | Load balancing for game |
JP2014002634A (ja) * | 2012-06-20 | 2014-01-09 | Nippon Telegr & Teleph Corp <Ntt> | 通信制御システム、集約サーバおよび通信制御方法 |
Also Published As
Publication number | Publication date |
---|---|
US20040260769A1 (en) | 2004-12-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2005010970A (ja) | 分散キャッシュ制御方法、ネットワークシステムおよび当該ネットワークに用いられる制御サーバないしルータ | |
EP2853077B1 (en) | Method of seamless integration and independent evolution of information-centric networking via software defined networking | |
US6535509B2 (en) | Tagging for demultiplexing in a network traffic server | |
US6931435B2 (en) | Congestion control and avoidance method in a data processing system | |
US6850980B1 (en) | Content routing service protocol | |
EP1035703B1 (en) | Method and apparatus for load sharing on a wide area network | |
CN102833148B (zh) | 资源请求及资源的路由代理 | |
JP5544006B2 (ja) | 情報通信処理システム | |
JP5506444B2 (ja) | 情報システム、装置および方法 | |
JP2007066161A (ja) | キャッシュシステム | |
JP7405856B2 (ja) | レイテンシ制約下でのキャッシュのクラスタに対する効率的で柔軟な負荷分散 | |
CN108429701B (zh) | 网络加速系统 | |
US7792133B2 (en) | Packet relay device and packet method, and program | |
JP4108486B2 (ja) | Ipルータ、通信システム及びそれに用いる帯域設定方法並びにそのプログラム | |
EP0993164B1 (en) | Apparatus and method for caching of network contents | |
EP3567813B1 (en) | Method, apparatus and system for determining content acquisition path and processing request | |
WO2012024909A1 (zh) | 长连接管理装置及长连接通讯的链路资源管理方法 | |
JP2004246905A (ja) | ウェブコンテントの知的フェッチと配送のためのシステムと方法 | |
US11689458B2 (en) | Control device, control method, and program | |
JP2006262193A (ja) | 制御装置、パケット転送方法およびパケット処理装置 | |
CN102158406B (zh) | 面向计算机网络链路的智能选路方法 | |
JP2003085032A (ja) | 自己組織化キャッシュ方法およびその方法を利用可能なキャッシュサーバ | |
CN112737940B (zh) | 一种数据传输的方法和装置 | |
US8051176B2 (en) | Method and system for predicting connections in a computer network | |
US20020199017A1 (en) | Routing meta data for network file access |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060420 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060511 |
|
A762 | Written abandonment of application |
Free format text: JAPANESE INTERMEDIATE CODE: A762 Effective date: 20080423 |