JP5803924B2 - データ転送システム - Google Patents

データ転送システム Download PDF

Info

Publication number
JP5803924B2
JP5803924B2 JP2012531671A JP2012531671A JP5803924B2 JP 5803924 B2 JP5803924 B2 JP 5803924B2 JP 2012531671 A JP2012531671 A JP 2012531671A JP 2012531671 A JP2012531671 A JP 2012531671A JP 5803924 B2 JP5803924 B2 JP 5803924B2
Authority
JP
Japan
Prior art keywords
site
server
domain resolution
domain
parent
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.)
Active
Application number
JP2012531671A
Other languages
English (en)
Other versions
JPWO2012029247A1 (ja
Inventor
泰寛 宮尾
泰寛 宮尾
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2012531671A priority Critical patent/JP5803924B2/ja
Publication of JPWO2012029247A1 publication Critical patent/JPWO2012029247A1/ja
Application granted granted Critical
Publication of JP5803924B2 publication Critical patent/JP5803924B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/0864—Round trip delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/70—Routing based on monitoring results
    • 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/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • 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/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • 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/563—Data redirection of data network streams
    • 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
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols

Description

本発明は、データ転送システムにかかり、特に、ネットワーク上に分散配置された複数のコンピュータ間でデータを転送するシステムに関する。
インターネットにおいては、地理的に分散配置された各サイト間でデータ転送が行われている。近年、コンピュータの普及、及び、ネットワーク技術の発達により、各サイト間で送受信されるデータ転送量は増大して来ている。このため、データ転送量が増大しても高速にデータ転送できることが望まれる。
ここで、例えば、図１に示すようなデータ転送システムを考える。図１に示すデータ転送システムは、クライアント装置４１〜４４と、分配システム２２と、から構成されている。分配システム２２は、クライアント装置４１〜４４に対してコンテンツの投稿、配信などの種々のサービスを行なうもので、複数のサイト１０１〜１０４とそれらをつなぐサブネットワーク１８とからなる。
ここで、上述したサイト１０１〜１０４とは、例えば、図２の符号１０２に示すように、データを処理、もしくは蓄積できるサーバ装置（ＯＧＳ２０２，ＤＲＳ３０２，ＰＳ５０３，５０４，５０５）を１つもしくは複数設置する場所を指すものとする。そして、サーバ装置は、マルチレイヤスイッチ１９によって、インターネットにアクセスするために位置するエッジルータ２０とつながる。
上記サイトを識別する具体的な方法としては、都市、もしくは、国がある。また、サイトの設置形態としては、サーバ装置をラックに格納してビル内のフロアーに設置するような小型のものから、巨大数のサーバ装置群を専用に収容するインターネットデータセンター（iDC）まである。
サイト間でデータの高速な転送が必要とされる具体的な例は、特許文献２にあるようなCDN（Contents Delivery Network：コンテンツ配信網）にいくつか見られる。まず、CDNにおいて、コンテンツホルダーから発行されたWebサイトや動画等のコンテンツデータがホスティングされているサイト（オリジンサイトとも呼ぶ）から、エンドユーザへの配信を行うエッジサイトへデータを複製する場合がある。そして、CDNにおける別の例としては、コンテンツユーザがアクセスしたエッジサイトに、期限が有効な所望のコンテンツがキャッシュされていない場合、上記オリジンサイトからエッジサイトへコンテンツデータを転送する場合がある。更に、別の例としては、オリジンサイトで動的に生成されるようなそもそもキャッシュ不能なデータを、オリジンサイトからエンドユーザがアクセスしたエッジサイトに転送する場合がある。これらのすべての例においては、オリジンサイトからエッジサイトにデータを高速に転送することができれば、エンドユーザの体感や満足度が高めることができる。
一方で、上述したCDNでは、アクセス頻度の高いものに対してはキャッシュすることで効果を上げてきたが、ロングテールのようにアクセス頻度が極めて低いがそうしたコンテンツが多数ある場合は、もはやキャッシュは有効ではない。つまり、そのようなコンテンツに最初にユーザがアクセスしたエッジサイトでは、ほとんどがオリジンサイトまでコンテンツデータを取りにいく必要が生じる。
よってユーザ体感を上げるためには、オリジンサイトからエッジサイトに高速にデータを転送する必要が出てくる。
ここで、特許文献１では、コンテンツを保持しているオリジンサイトと、クライアントのアクセス先であるエッジサイトと、の間に中継サイトを入れた、アプリケーションレベルでのマルチホップなパスを用いることで、スループットを高めようとする方法を開示している。ここでは、送受信間でのパケットの往復でかかった遅延であるRound Trip Time（以降RTTと省略）等の計測に基づいて２ホップパスである選択候補を決定し、それらと直通パスのなかから試験的なデータのダウンロードに基づいて最適なパスを選ぶ。
また、非特許文献１では、取得したいコンテンツのデータをセグメント化して並列転送させることでスループットを向上させようとする技術を開示している。ここでは、あるクライアントがファイルを要求すると、その入口サイトで要求をブロック毎にわけて新たに付与したURIを含むHTTPリクエストを、予め割当てられた出口サイトに転送する。そして出口サイトからはもとのURIに対するレインジヘッダをもつHTTPリクエストをオリジンサイトに転送する。こうしてHTTPレスポンスとして、各ブロックは複数の出口サイトを経由する経路上を入口サイトまで並列に転送され、入口サイトで組み立てられてクライアントまで転送される。なお、以下では、HTTPリクエストおよびHTTPレスポンスは、特に断りのない限り、ＧＥＴメソッドに関するものを指すものとする。
また、非特許文献２では、各サイトをつなぐ全域分配木を、各サイト間のオーバレイパスのボトルネック帯域が最大になるように決定する方法が示されている。上述した特許文献１や非特許文献１とは異なり、ホップ数の制限がないので、その分スループットを向上させる可能性がある。
また、非特許文献３では、インターネット上でのオーバレイ網において、あるオーバレイノードから別のオーバレイノードへつながるポイントツーポイントのオーバレイパスを、各オーバレイノード間の性能測定に基づいて動的に設定することが開示されている。
また、非特許文献４では、セグメント化して得られる各ブロックをモジュロが等しい単位でサブストリーム化し、各サブストリームのある部分（複数のブロックからなる）を単位として、それを異なるピアから受信して一旦組立て、また別のピアにサブストリームのある部分を提供することで、ストリーミングサービスを非常に多くのピアに同時に提供することを実現している。
上述した技術は、いずれもインターネットの上にアプリケーションレベルのネットワークをオーバレイして設置し、アプリケーションレベルのスループットを増大させることを狙いとしている。
ここで、アプリケーションレベルのオーバレイネットワークを構成する各サイト間では、アプリケーションデータを転送するためにTCPコネクションが終端される。アプリケーションレベルのスループットを制御するには、TCPの性質について把握しておく必要がある。以降、クライアント、プロキシサーバ、オリジンサーバの間で、HTTPデータを転送するために設定されるTCPコネクションを、ここではHTTPコネクションと呼ぶことにする。
サーバ装置、あるいはエンドユーザのPCのようなエンドシステム間でHTTP（HyperText Transfer Protocol）のようなアプリケーションのデータを誤りなく転送するためには、TCP（Transmission Control Protocol）が用いられる。TCPでは、送信したデータに対して受信確認の応答を受信・処理することで誤りなくデータを受信するものである。
非特許文献５にもあるように、そのスループットは、RTT、およびパケット損失率に依存する。ここで、RTTには、送受信間での往復での伝搬遅延と、往復時の装置内におけるパケットのプロトコル処理遅延および回線上への転送遅延等が含まれる。なお、送受信間の往復では往路と復路で同一の経路を通過するとは限らない。
一般に、送受信間でインターネット上でのホップ数が大きくなるとパケット損失率が増加し、また特に異なる大陸もしくは諸島間をつなぐ海底ケーブルによるAS間のリンクを含む場合は、その伝搬遅延によりRTTが大きくなる。これによりTCPによるデータ転送時のスループットは低下する。
また、TCPのフロー制御では、受信応答なしに連続して送出できるデータ量の上限を決めるウィンドサイズを、受信応答の戻りかたに応じて動的に変更する。この制御は、Additive increase multiplicative decrease則に基づいている。よってパケットのロスがあると判断された場合、そのときのウィンドサイズを半分にするため、データを転送できる量が半減する。
従って、非特許文献６にあるように、こうしたＴＣＰの性質を考慮して、アプリケーションレベルでのスループットを増大させるには２つの方法が考えられる。一つは、アプリケーションレベルの中継装置をおいてＲＴＴを減らすことである。ここで、最大ウィンドサイズをW、リンクeでのＲＴＴをTeとすれば、そのリンクにおけるスループットは、W/Teとなるので、あるパスhでのスループットは各リンクでのスループットの中の最小値となり、パスhに含まれるリンクの集合をEhとすれば、min_{e∈Eh} W/Teで計算できる。よって、パスにおける最大のTeが最小になるようにパスを選べばスループットは最大化できる。
もうひとつの方法は、隣接サイト間でＴＣＰコネクションを並列に設定することであり、コネクション数をZとすれば、スループットはZ*W/Teとなる。また、パケット損失をひとつ検出した場合、１本だけ設定したＴＣＰコネクションにおいて最大ウィンドサイズＷをZ倍にしておいたとすれば、ウィンドサイズはZ*W/2に減少するが、ＴＣＰコネクションをZ個並列に設定しておけば、パケット損失は一つのコネクションにおいてのみ検出されることになるので、最大ウィンドサイズの合計は、W/2+(Z-1)*Wとなって、差し引きは(Z-1)*W/2となる。よって並列設定数Zが大きいほどスループットが高くなることが期待できる。
C. Bornstein, T. Canfiled, G. Miller, S. B. Rao, and R. Sundaram, “Optimal routeselection in a content delivery network,” US patent 7,274,658, Sep. 25, 2007. F. Thomson Leighton and Daniel M. Lewin, “Global hosting system,”USpatent 6,108,703, August 22, 2000. D. Karger, E. Lehman, F.T. Leighton, M. Levine, D. Lewin, and R.Panigrahy, “Method and apparatus for distributing requests among a plurality ofresources,” US patent 7127513, October 24, 2006.
K. Park and V. S. Pai, "Scale and performance in the CoBlitz large-file distributionservice," NSDI’06. G. Kwon and J. W. Byers, "ROMA: Reliable overlay multicast withloosely coupled TCP connections, " IEEE INFOCOM 2004. D. Anderson, H. Balakrishnan, F. Kaashoek, and R. Morris, "Resilientoverlay networks, " in Proc. 18th ACM SOSP, October 2001. B. Li, S. Xie, Y. Qu, G. Keung, C. Lin, J. Liu, and X. Zhang, "Inside the newcoolstreaming: principles, measurements and performance implications," IEEE INFOCOM’08. J. Padhye,V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP throughput: A simple modeland its empirical validation,"ACM SIGCOMM Computer Communication Review, vol.28no.4, pp. 303-314, Oct. 1998. Y. Liu, Y. Gu, H. Zhang, W. Gong, and D. Towsley, "Application levelrelay for high bandwidth data transport," GridNet 2004. http://en.wikipedia.org/wiki/Representational_State_Transfer http://en.wikipedia.org/wiki/Squid_(software) R. Cohen and G. Kaempfer, "A unicast based approach for streamingmulticast", IEEE INFOCOM 2001. Y. Miyao, "An optimal design scheme for global overlay networks withenhanced data transfer throughput, "ICC2010. D. G. Thaler, and C. V. Ravishankar, "Using name-based mappings toincrease hit rates," IEEE/ACM Transactions on Networking vol. 6, No. 1, pp.1-14, February 1998. HTTP1.1, IETF RFC2616, June, 1999.http://www.w3.org/Protocols/rfc2616/rfc2616.html http://en.wikipedia.org/wiki/Ajax_programming
しかしながら、上述した文献に開示された技術では、以下のような問題がある。まず、上記特許文献１には、まだオリジンサイトとエッジサイトの間のスループットを増大させる余地がのこっている。なぜなら、中継サイトになる候補のサイトからのみRTTを測定するので、片方向しかみておらず、ルートの非対称性が大きいサイト間がある場合は、適切な制御ができないからである。また、エッジサーバからオリジンサーバまで最大２ホップまでしか考慮されておらず、よりホップ数が許さればサイト間のRTTが押さえられてスループットが増大する可能性があるからである。
また、非特許文献２では、（上記特許文献１における２ホップという制限を越えて）配信経路を最適化するが、動的な最適化の具体的方法が示されていない。また、非特許文献３は、動的にポイントツーポイントのオーバレイパスの設定を行うが、複数のサイトへの分配には対応していない。また、動的再構成のための性能測定と、その統計値の取得は別々の手順で実行する必要がある。
さらに、上記特許文献１では、動的にエッジサーバとオリジンサーバとのポイントツーポイントの経路設定できても、オリジンサーバから複数のエッジサーバに効率的に分配する経路を設定することができない。なぜならオリジンサイトへの直通パスと中継サイトを含む２つの経路候補の中から一つを選ぶ際に、中継サイトに欲しいデータがキャッシュされているかどうかを判断指標にいれないからである。
また、非特許文献４は、並列分割転送する分、スループットを増大できるが、サイトに複数のサーバを設置して収容能力を増大させるような状況には対応していない。なぜならいわゆるピアツーピア形式でファウルをクライアント同士で分配することを前提としているからである。
また、非特許文献１は、まだスループットを増大させる余地がある。なぜなら、分割したブロック毎に中継サーバを割り当てるが、それは２ホップ目におけるものだけだからである。また、非特許文献１では、ブロック数が増えると処理負荷や必要資源が増加するという問題がある。なぜなら、ブロックを転送する毎にHTTPコネクションを設定する必要があり、また、ドメイン解決のためのメッセージ処理数が増えるからである。
さらに、非特許文献４の問題点としてすでに記述しているが、上記特許文献１以外の技術では、サイト内でのサーバクラスタ化による収容能力の増大を考慮することができない。
このため、本発明の目的は、上述した課題である、ネットワーク上に分散配置された複数のサーバ装置間におけるデータ転送のスループットを改善する、ことにある。
上記目的を達成すべく、本発明の一形態であるデータ転送システムは、
コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されており、
前記ドメイン解決サーバが、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を備え、
前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である親サイトにあるプロキシサーバを自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
という構成を採る。
また、本発明の他の形態であるドメイン解決サーバは、
コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバとを設置したサイトが、ネットワークを介して複数接続されている場合における前記ドメイン解決サーバであって、
各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を備え、
前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
という構成を採る。
また、本発明の他の形態であるプログラムは、
コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバとを設置したサイトが、ネットワークを介して複数接続されている場合における前記ドメイン解決サーバに組み込まれるプログラムであって、
前記ドメイン解決サーバに、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を実現すると共に、
前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
という構成を採る。
また、本発明の他の形態であるデータ転送方法は、
コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおけるデータ転送方法であって、
前記ドメイン解決サーバが、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測し、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定し、前記ドメインに対応するプロキシサーバを割り当てると共に、
前記経路設定時に、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
前記割り当て時に、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
という構成を採る。
本発明は、以上のように構成されるため、これによると、ネットワーク上に分散配置された複数のサーバコンピュータ間におけるデータ転送のスループットの向上を図ることができる。
データ転送システム全体の構成を示すブロック図である。 第１の実施形態におけるサイト内の構成を示すブロック図である。 第１の実施形態におけるドメイン解決サーバの構成を示すブロック図である。 第１の実施形態における親DRS記憶部のテーブル構成を示す図である。 第１の実施形態におけるRTT統計記憶部のテーブル構成を示す図である。 第１の実施形態における親DRS決定部の動作を示すフローチャートである。 第１の実施形態における親DRS決定部の動作を示すフローチャートである。 第１の実施形態におけるPS割当て部の動作を示すフローチャートである。 第１の実施形態におけるPS割当て部の動作を示すフローチャートである。 第１の実施形態の実施例におけるDRS間のRTT計測とRTT統計情報取得の説明図である。 第１の実施形態の実施例における最適分配木の作成と親DRS記憶部のテーブル構成の説明図である。 第１の実施形態の実施例として、ドメイン解決要求・応答メッセージの転送とHTTPリクエスト／レスポンスのデータ転送の一連の動きを示す説明図である。 第１の実施形態の実施例として、オリジンサイトから各サイトにデータを分配する動作の説明図である。 第２の実施形態におけるDRSの構成を示すブロック図である。 第２の実施形態におけるDRSの分配木算出部の動作を示すフローチャートである。 第２の実施形態におけるDRSのPS割当て部の動作を示すフローチャートである。 第２の実施形態における実施例として、ドメイン解決・要求メッセージの転送とHTTPリクエスト・レスポンスのデータ転送に関する一連の動作の説明図である。 第３の実施形態におけるOGSの構成を示すブロック図である。 第３の実施形態におけるOGSの発行処理部の動作を示すフローチャートである。 第３の実施形態におけるOGSのクライアント処理部の動作を示すフローチャートである。 第３の実施形態におけるDRSの親ＰＳキャッシュ部のテーブル構成を示す図である。 第３の実施形態におけるDRSのＰＳ割り当て部の動作を示すフローチャートである。 第３の実施形態におけるDRSのＰＳ割り当て部の動作を示すフローチャートである。 第３の実施形態におけるDRSのＰＳ割り当て部の動作を示すフローチャートである。 第３の実施形態におけるクライアントの構成を示すブロック図である。 第３の実施形態におけるクライアントの背景処理部の動作を示すフローチャートである。 第３の実施形態における実施例として、クライアントとエッジサイトとの間の一連の動作を示す説明図である。 第３の実施形態の実施例において、オリジンサイトからクライアントまでの転送経路上でのサブストリームの並列転送を示す説明図である。 第４の実施形態におけるサイトの構成を示すブロック図である。 第４の実施形態におけるDRSのPS割当て部の動作を示すフローチャートである。 第４の実施形態における実施例として、サブストリーム乗換えを示す説明図である。 本発明の付記１−１におけるデータ転送システムの構成を示すブロック図である。 本発明の付記２−１におけるデータ転送システムの構成を示すブロック図である。
＜実施形態１＞
本発明の第１の実施形態を、図１乃至図１１を参照して説明する。図１乃至図５は、データ転送システムの構成を示す図であり、図６乃至図１１は、データ転送システムの動作を示す図である。
［システム全体構成］
図１に示すように、本発明におけるデータ転送システムは、クライアント４１〜４４と、分配システム２２と、からなる。そして、分配システム２２は、クライアント４１〜４４に対して、コンテンツの投稿や配信のサービスを行なうもので、複数のサイト１０１〜１０４と、それらをつなぐサブネットワーク１８と、により構成されている。
上記クライアント４１〜４４は、所定のユーザが操作するパーソナルコンピュータなどの情報処理端末であり、適切なサイトに誘導されて、HTTPを用いてコンテンツをアップロードしたり、ダウンロードしたりする機能を有する。また、クライアント４１〜４４は、サブネットワーク１８とは同じもしくは独立のネットワークを通じて、サイト１０１〜１０４とコンテンツをやり取りする。
図２に示すように、サイト１０２は、オリジンサーバ（OGS）２０２と、ドメイン解決サーバ３０２（DRS）、プロキシサーバ（PS）５０３〜５０５と、マルチレイヤスイッチ（MLS）１９と、エッジルータ２０と、を備えている。
オリジンサーバ（OGS）２０２は、コンテンツのアップロードを受け付ける。ドメイン解決サーバ（DRS）３０２は、他のサイトのDRSからの要求に基づいて、コンテンツデータ要求（HTTPリクエスト）を転送する先のプロキシサーバ（PS）のアドレスの解決を行う。エッジルータ２０は、サイト内の各装置とサブネットワークとの接続をIPレベルで行うものである。MLS１９は、OGS２０２、PS５０３〜５０５、DRS３０２、エッジルータ２０を接続する。
なお、全てのサイト１０１〜１０４はほぼ同一の構成を採っているため、ここでは、符号１０２に示すサイトのみを説明する。以下、各構成について詳述する。
［オリジンサーバ（OGS）］
まず、オリジンサーバ２０２（OGS）は、ドメイン毎に転送先のＰＳのドメイン解決を要求する既存のクライアントやプロキシサーバＰＳを前提に、異なるＵＲＩ毎に次ホップのサイト内に複数あるPSの一つを割当てるため、特許文献２にあるようなURIの変換を行う。なお、ＵＲＩ単位でドメイン解決要求をすることができる場合は、このＵＲＩの変換は不要になる。すなわちOGS２０２では、コンテンツ発行者から新たにアップロードされたコンテンツのデータを、ＨＤＤ等の記憶装置に格納した後、そのファイルに以下のようなO-URIを付与する。
O-URI-- http://www.site1.song.net/videocast/channel3/item2/
ここでO-URIの構成の仕方について説明しておく。「song.net」は、この配信サービスを提供する主体を示し、「site1」は、このコンテンツが発行者からアップロードされた先であるオリジンサイトを示し、「www」は、オリジンサーバとしてのホスト名を示している。配信サービス提供主体がN個のサイトを運営している場合、例えば各サイトをsite1,…, siteNと示す。」
次にO-URIのパスの部分において、「videocast」はコンテンツ提供サービスの名称を、「channel3」は、個別のチャンネルを、「item2」は、個別の配信プログラムをそれぞれ示している。
次に、O-URIをハッシュして（この値をここでは1578とする）、それにfをつけて得られるf1578というドメインをwwwと入れ替えて、次のようにF-URIを得る。
F-URI: http://f1578.site1.song.net/videocast/channel3/item2/
ここで説明を簡単にするため、以下のようにドメインの呼び方をつける。
「Oドメイン」：site1.song.net オリジンサイトに対応するサブドメイン。詳細は後述するが、オリジンサイトを示すドメインを含ませることで、オリジンサイト毎にそれをルートにもつ有向分配木を作成してドメイン解決要求をその分配木上の経路にそって転送することができるようになる。
「Fドメイン」：f1578.site1.song.net 異なるO-URIに対応するように変換されたのちのドメイン名。
O-URIは、ポータルサイトでデータを取得するためのリンクとして使われ、それをクリックすると、O-URIを含むHTTPリクエストがオリジンサイトに送られ、そこから番組ファイルを取得するために使われるメタデータがHTTPレスポンスとしてクライアントにダウンロードされる。下記はそのメタデータに含まれる情報である。
O-URI: http://www.site1.song.net/videocast/channel3/item2/
エッジサイトDRSのアドレス：291.47.234.12, 291.47.234.13
F-URI: http://f1578.site1.song.net/videocast/channel3/item2/
ここで、エッジサイトに設置されたDRSのアドレスは、クライアントがメタデータの要求をしてきたタイミングで、そのクライアントのＩＰアドレスに基づいて、クライアントを誘導すべき最寄りのエッジサイトのDRSのアドレスとしてオリジンサーバが決定する。ここではDRSの障害を考慮して、２つのDRSアドレスが２つ記載されている。
上記のメタデータはＸＭＬ形式で記述してもよい。こうして、URIが指定されたリソースの状態をXML形式で提供するＷｅｂサービスは、RESTfulと呼ばれる（非特許文献７参照）。
なお、特許文献１でも、上記の同じように、異なるURIのコンテンツ毎にキャッシュサーバを割当てるため、オリジナルのURIに対してハッシングを行って仮想サーバを割当て、オリジナルのURIをパスの部分にもっていって、その前にAkamaiの仮想サーバのドメインをつけることで、新たなURIを作る。一方、本発明では、上記とは異なり、配信用のサイトのみならずオリジンサイトもサービス運用者が同時に運用するので、オリジナルのURI全体を変換後のURIのパス部分に埋め込む必要はない。
［プロキシサーバ（PS）］
本発明で用いるプロキシサーバ５０３〜５０５（以下PSと略す）では、非特許文献８にあるような既存のものへの機能追加機能は最低限にしている。以下にPSの構成及び動作について説明する。
プロキシサーバ５０３〜５０５は、親となるサイトのＰＳからもらったブロックを、キャッシュもしくは記憶しておき、次に別のサイトから要求があったときに備える。ここで分配木の転送経路上で隣接するサイトにおいて、ルートにより近い側のサイト、つまり、上流側のサイトを親サイト、ルートからより遠い側のサイト、つまり下流側のサイトを子サイトと、それぞれ呼ぶ。
ＰＳは、HTTPリクエストを受信すると、そこに含まれるURIのデータを格納している場合は、それをHTTPレスポンスとして返す。格納していない場合は、DRSにFドメインに対して割当てられるPSのアドレスを得るために、ドメイン解決要求をし、戻ってきたら、そのPSのアドレスに向けて、HTTPリクエストを転送する。HTTPリクエストに対して、HTTPレスポンスが戻ってきたら、そのURIに対して要求していたサーバにHTTPレスポンスを返送する。
ＰＳでのデータ転送と蓄積は、ＨＴＴＰコンテンツのデータは入出力が速いメモリ上で扱うことを前提とする。これは特にオリジンサイトにおいては、ＯＧＳにおいてメモリよりも読み出しが遅いＨＤＤにあるデータを、ＰＳにキャッシュさせてから転送に使うことで、性能向上を図っている。
［ドメイン解決サーバ（DRS）］
図３に示すように、ドメイン解決サーバ（DRS）３０２は、送信装置１４と、受信装置１５と、データ処理装置８と、記憶装置９と、を備えている。送信装置１４および受信装置１５は、他のサイトのDRSとドメイン解決要求・応答メッセージおよびRTT統計値要求・応答メッセージをそれぞれやりとりしている。
データ処理装置８は、プログラムが組み込まれることで構築された、PS割当て部８１と、親DRS決定部８２と、を備えている。ここで、「親DRS」とは、ドメイン解決要求を次に転送すべき親サイトのDRSを指す。また、「親サイト」とは、後述するように生成された有向分配木の転送経路上で隣接する２サイトの中で、ルートにより近い側のサイト、つまり、上流側のサイトを指す。
親DRS決定部８２（計測手段、経路設定手段）は、ドメイン解決要求を送るべき親サイトのDRSのアドレスを決定する。PS割り当て部８１（割り当て手段）は、子サイトのDRSからの要求に基づいて、各サブストリームに対して自サイトで割り当てるべきPSのアドレスを決定する。
受信装置１５は、ドメイン解決応答はPS割り当て部８１に、RTT統計値応答は親DRS決定部８２にそれぞれ渡す。また、記憶装置９は、ローカルPS記憶部９１と、親PSキャッシュ部９２と、親DRS記憶部９３と、RTT統計行列記憶部９４と、RTT統計処理記憶部９５と、分配木記憶部９６と、からなる。
上記ローカルPS記憶部９１は、自サイトにあるPSのアドレスと、タイムアウト回数と、状態の組合せからなるエントリを格納している。親PSキャッシュ部９２は、親DRSから解決応答として受取ったＦドメインと親PSアドレスとの組合せを含むエントリをテーブルとして持つ。
親DRS記憶部９３は、親DRS決定部８２が算出した、オリジンサイトをルートとする有向分配木において、自分に対する親サイトのDRSのアドレスとその状態を記憶する。また、この親DRS記憶部９３内のTTLは、この情報が有効である残り時間を示し、この値は時間経過とともに小さくなる。このテーブルの特徴は、HTTPリクエストの転送先ではなく、ドメイン解決のための転送先が書いてあることである。また、通常のシステムでは、URIによらず共通の親PSを割当てていたが、本発明で割当てる親DRSは、オリジンサイト毎に異なる。
ローカルＰＳ記憶部９３は、ローカルサイト内に設置されている各ＰＳのアドレスと、その状態が格納されている。
RTT行列記憶部９４は、サイトiからサイトjへのRTTを所定の回数の測定した結果から得られる統計値が行列状に格納されている。ここで、他のサイトから自サイトへのＲＴＴ統計値は、ＲＴＴ統計値応答に対して受信したＲＴＴ統計値応答内に記載された値を、また自サイトから他サイトへ測定した値は自サイトのRTT統計記憶部９５内のテーブルにあるＲＴＴの最小値（図５参照）を、それぞれRTT行列記憶部９４の対応するエントリにコピーしたものである。
ここで、図４は、親DRS記憶部９３のテーブル構成を示す図である。このテーブルは、Oドメインと、オリジンサイトのDRSのアドレスと、親サイトのDRSのアドレスと、親サイトのDRSの状態と、からなる。
また、図５は、DRSi (i=1,…,N)におけるRTT統計記憶部９４のテーブル構成を示す図である。自分以外の他の全てのサイトに関するＮ−１個のエントリをもつ。DRSjに対するエントリは、DRSj(j=1,..,i-1,i+1,...,N)のアドレスと、過去Ｍ回分のＲＴＴの測定値TjM,...,Tj1と、それらの最小値 min(Tj1,...,TjM)と、DRSの状態の組合せとなっている。新たな測定値を得たら、Ｍ個あるRTTの過去の測定値を左側にシフトさせて、TjMは削除し、一番右の空いたTi1のところに最新の測定値を書くとともに、過去Ｍ回分のRTTの最小値を更新する。この処理自体は、親DRS決定部８２が行う。
［親DRS決定部の動作］
次に、上述したシステムの動作を説明する。はじめに、図６ａ、図６ｂを参照して、親DRS決定部８２の動作について説明する。
図６ａは、他サイトのDRSへのＲＴＴ統計値要求の送信に対するＲＴＴ統計値応答の受信により、自サイトからその他サイトへのＲＴＴの測定を同時に行いつつ、ＲＴＴ統計値が変動した場合は分配木を再構成する動作を示している。なお、非特許文献１にもあるように、分配木は各サイト間のスループットを全て最大化させるためのものである。
まず、ステップＳ６１で、各サイト１０１等の親DRS決定部８２は、RTT統計値要求を定期的に他の全てのサイト１０２等のDRS３０２等へ送信する。この間隔は、予め設定された任意の間隔であるが、例えば、１５−３０分である。このときタイムアウト回数Ｎは０にしておく。
ここで、ＲＴＴ統計値要求は、下記のＵＲＩをもつＨＴＴＰリクエストとする。
http://(要求先のDRSのアドレス)/RTTstatistics
続いて、ステップＳ６２で、ＲＴＴ統計値要求を送った他のサイト１０２等のDRSjから、
ＲＴＴ統計値のベクトル
{(DRS1,T1),..,(DRSj-1,Tj-1,),(DRSj+1,Tj+1),…,(DRSN,TN)}
（ただし、TkはDRSｊからDRSｋに対して測ったＲＴＴの統計値）
を含むRTT統計値応答がタイムアウトせずに戻ってきたら、RTTの測定値（要求を送ってから応答が届くまでの時間）をRTT統計記憶部９５に書き込んで、統計値を更新し、その更新値でさらにRTT行列記憶部９４を更新する。なお、ＲＴＴ統計値応答は、上記RTT統計値のベクトルをＸＭＬで記述したものを用いてもよい。
タイムアウトした場合は、Nをインクリメントし、もう一度要求を送る。これを繰り返して、Ｎが所定値（例えば３）を超えた場合は、使用不可という状態をRTT統計記憶部９５の状態のところに書き込む。また、RTT行列記憶部９４では、使用不可を書き込む。そして、ＲＴＴ統計値応答メッセージ内にある、応答のあったサイトから他の全てのサイトに対して得られたＲＴＴ統計値を、RTT行列記憶部９４に書き込む。この動作はＲＴＴ統計値要求を出した他のすべてのサイトに関して行う。
次に、ステップ６３で、RTT行列記憶部９４を参照して、各サイトがオリジンサイトとなる最適分配木を算出する。そして、分配木記憶部９６を参照して分配木に変更があるＯドメインがある場合は、そのＯドメインに対する親サイトのDRSを抽出して、親DRS記憶部９３を更新し、親PSキャッシュ部９２において、変更のあった分配木に対応する部分（O-ドメインで識別）をクリアし、更にローカルPSのアドレスキャッシュにおいて、該当Oドメインを含む全てのB-URIのエントリを管理手順で強制的にクリアして、ステップ６１に飛ぶ。
これらのクリアを行うのは、分配木の再構成があった場合に、上記各テーブルの更新をＴＴＬに頼るのではなく、直ちに再構成が反映されるようにするためである。
なお、上述したように親DRS（親ドメイン解決サーバ）を特定する方法は、例えば、構成された有向分配木の転送経路上で隣接するサイトにおいて、ルートにより近い側のサイト、つまり、上流側のサイトのDRSを、親DRSとして特定する。
ステップ６３においては、各サイトのDRSは、予め他の全てのサイトのDRSのアドレスを知っているものとする。これは、例えばシステム全体をつかさどる管理システムが、サイトの追加もしくは離脱の度に稼動する全てのサイトにDRSのアドレスを通知することで実現する。
また、ステップ６３において最適な有向分配木を算出する一つの方法として、非特許文献９にあるようなボトルネック（帯域が最小のリンク）を最大化する方法がある。この方法の目的は各サイト間の転送スループットを最大化することである。
ここで、隣接サイト間のＲＴＴと最大ウィンドサイズＷが与えられれば、パケットロスがないとした場合の隣接サイト間のリンクeでのスループットはW/Teで与えられるので、あるサイト間のパスhでのスループットは、hに含まれるリンクeの集合Ehとすると、そのパス上のボトルネックであるmin_{e∈Eh}W/Te で与えられる。よって各リンクでＷは一定であるとすれば、Teをコストとして、最小全域木を作る手順の一つであるプリム法を応用すれば、各サイト間のスループットを最大化できる。証明は、非特許文献１０に記述されている方法を参考にすれば導かれるがここでは省略する。この手順では部分木に対してノードを追加していくのに、部分木に付加することが可能なリンクのなかでRTT統計行列記憶部の中に格納されているRTT統計値が最小のリンクの先にあるノードを追加していく。
なお、ここで仮想リンクとは、サイトＡからサイトＢへのリンクが物理的なものではなく、インターネットもしくは専用網の転送機能によって実現されているようなものをさす。ここでの分配木を作る手順は、ノード数Ｎ、有向リンク数Ｎ（Ｎ−１）のフルメッシュな有向グラフから、最適な有向分配木を抽出することであるともいえる。
また、ステップ６３において、最適な有向分配木を算出するもう一つの方法として、ダイクストラのアルゴリズムがある。ただし、サイトiからサイトjへのエッジのコストにはＲＴＴ統計値を付与する。なぜなら各エッジサイトからオリジンサイトでのリンク上でのＲＴＴの総和を最小にする最短パスツリーを算出したいからである。これは、サイト内でのドメイン解決の時間を無視すれば、クライアントがエッジサイトに取得したいファイルに関して最初にＨＴＴＰリクエストを出してから、エッジサイトが初めてＨＴＴＰレスポンスを受信するまでの時間を概算するものである。このいわゆるスタートアップ時間は、各エッジサイトからオリジンサイトまでの方向のパス上の各サイト間の仮想リンクでのＲＴＴ統計値の総和の２倍で与えられる。例えば、後述する図１０においては、Ｓ５，Ｓ６，Ｓ８、Ｓ１０，Ｓ１１，Ｓ１３，Ｓ１５，Ｓ１６，Ｓ１８，Ｓ２３，Ｓ２４，Ｓ２５で関る仮想リンクのRTT統計値の総和を取ったものに相当する。
また、図６ｂは、他のサイトのDRSからRTT統計値要求を受けた場合の処理である。ステップＳ６５でRTT統計値要求を他サイトのDRSより受信したら、ステップＳ６６でRTT統計記憶部９５に記憶されている各リモートDRSに関するRTT統計値を、RTT統計値応答に載せて要求してきたDRSに送信して終了する。
［PS割当て部の動作］
次に、図７ａ、図７ｂを参照して、DRS３０２のPS割当て部８１の動作について説明する。図７ａは、PS割り当て部８１におけるドメイン解決の動作を示すものである。ドメイン解決に関するメッセージは、１）クライアントもしくは子サイトのDRS、２）ローカルＰＳ、および、３）親サイトのDRS、とやり取りするが、それぞれに対して手順が以下のようになる。
まず、ステップＳ７１で、クライアントもしくは自サイトプロキシからFドメインに対する親PSのドメイン解決要求があると、ステップＳ７２で、（１）Ｆドメインに自分と同じＯドメインを含む場合は、ドメイン解決応答でＯＧＳのアドレスを返す。（２）Ｆドメインに自分と同じＯドメインを含まない場合であり、対応エントリが親ＰＳキャッシュ部９２にある場合は、そのドメイン解決応答する。（３）対応エントリが無い場合は、親DRS記憶部９３を参照して当該Oドメインに対応する親DRSに対してFドメインの親PSアドレスの解決を要求する。
また、ステップＳ７３で、親サイトのDRSからドメイン解決応答があったら、ステップＳ７４で、Fドメインに対して割当てられたPSのアドレスを親PSキャッシュ部９２にキャッシュし、解決要求していたローカルPSに対して割当てられたアドレスで応答する。
また、ステップＳ７５で、子サイトのDRSからFドメインに対するドメイン解決要求があったら、ステップＳ７６で、ローカルPS記憶部９１を参照してロバストハッシングによりFドメインに対応するPSアドレスを決定し、解決要求してきた子DRSにそのアドレスを応答して終了する。
図７ｂは、PS割当て部８１におけるローカルPSの監視動作を示すものである。ステップＳ７７で、前回の監視動作から一定時間経過後、タイムアウト回数Ｎを０にして、ローカルPS記憶部９１にある各PSアドレスに向けてpingを送信する。ステップＳ７８で、（１）タイムアウトせずに戻ってきた場合は、そのPSの状態を使用化とする。（２）タイムアウトした場合は、Nをインクリメントしてpingを再び送信する。そのタイムアウト回数が一定数以上になった場合は、そのPSの状態を使用不可とする。そしてステップB７に戻る。
［ステップＳ７６におけるPS割当てアルゴリズム］
図７ａのステップＳ７６におけるロバストハッシングとしては、非特許文献１１、もしくは、特許文献３にある方法に基づいて行う。これは、同じコンテンツが複数のPSに複製されることをなるべく防ぐ一方で、PSが増設もしくは減設されたときに、既存のPSを割当てられているFドメインに別のPSが割当てられるような割合を最小にするためのものである。もし、あるサーバが使用不可になった場合は、そこに転送していた子PSがあらたに子DRSに解決要求をして、それがさらに親DRSに要求をしてくるので、そこに新たに割当てることになる。
次に、上述した本発明の第１の実施形態における効果について説明する。本実施形態によると、各サイトをノードにもつ分配木はアプリケーションレベルでのホップ数を制限なしに最適に構成されるので、ホップ数に制限がある場合に比べて、アプリケーションレベルでのスループットをより向上させることができる。つまり、オリジンサイトが異なる毎に最適な分配木を構成するので、オリジンサイトに関らず固定的な分配木を用いる場合比べて、どのサイトからコンテンツを取得しようとしてもよりスループットを向上させることができる。
また、分配木は、各サイト間で測ったRTTベースに、オリジンサイトをルートとしてもつ有向グラフとして作成されるので、サイト間の転送状態における非対称性が大きくても（例えば、サイトＡからＢへのＲＴＴとサイトＢからＡへのＲＴＴの差が大きいこと）、スループットをより最適化することができる。
そして、自サイトから他サイトへのＲＴＴ測定と、他サイトからのＲＴＴ統計情報の取得を同時に行うので、非特許文献３にあるようにそれらを別々の手順で行う必要がなくなり、処理量が削減できる。
［実施例］
次に第１の実施形態におけるさらに具体的な実施例を、図８及び図９を参照して説明する。図８、図９は、親DRS決定部８２の動作を示している。
図８では、DRS１におけるＲＴＴ統計情報の取得、ＲＴＴ測定とＲＴＴ行列の作成の例を示している。ここでは、DRS１が、DRS２,DRS３,DRS４にそれぞれRTT統計情報要求を送った後、ＲＴＴ統計情報応答が戻ってくると同時にRTTを測定する。そして、RTT行列記憶部９４において、各DRSから応答のあったＲＴＴ統計情報は、各DRSが要求側であるエントリに書き込まれる。また、ＲＴＴの測定値は、RTT統計記憶部９５に書き込まれ、その結果新たに得られるＲＴＴ統計値は、自分（DRS１）が要求側のエントリに書き込まれる。つまり、ＲＴＴ統計情報要求を送信してから応答があるまでの時間として計測されたRTTの値は、RSS統計記憶部９５に格納され、統計値として処理された結果がRTT行列記憶部９４に書き込まれる。
図９は、RTT行列記憶部９４の内容に基づいて、親DRS記憶部９３のテーブルを作成する動作例を示している。ここでは、まず、各DRSがオリジンサイトになる有向分配木が４つ作成される。そして、各DRSにおける、オリジンサイト毎の親DRSの対応表は図９に示すようになり、これが親DRSアドレス記憶部９３に組み込まれることになる。つまり、構成された有向分配木の転送経路上で隣接するサイトにおいて、ルートにより近い側のサイト、つまり、上流側のサイトのDRSが、親DRS（親ドメイン解決サーバ）として特定される。
次に、図１０は、ＰＳ割当て部８１の動作により、クライアントが要求したデータをオリジンサイトまで取りに行くための連係動作の実施例を示している。
まず、クライアントは、取得したいデータのF-URIと、データを取得するＰＳの解決に使用すべき親サイト１０２のDRS３０２のアドレスとを、OGS２０４から取得したメタデータ内に持っており、HTTPリクエストを送信すべきPSのアドレスを得るために、F-URIに含まれるFドメインに対するドメイン解決要求をDRS３０２に送信する。（Ｓ１）。これは、下記のURIを含むHTTPリクエストを用いてもよい。
http://(DSR302のアドレス)/PSes/ f1578.site1.song.tv
続いて、DRS３０２は、それに対してサイト内で割当てるPSをPS５０２と決定したら、そのアドレスp.q.r1.s1を持ってクライアントに応答する（Ｓ２）。この応答は、下記の情報をXML形式で記述したものを本文に含むHTTPレスポンスでもよい。
f1578.site1.song.tv p.q.r1.s1
次に、クラアント４５は、PS５０２に対してHTTPリクエストを送信する（Ｓ３）。PS502は、HTTPリクエストを受取ったら、そのURIが示すデータをキャッシュしていないので、ローカルのDRS３０２に、Fドメインを、HTTPリクエストを転送すべき親PSのアドレスに解決する要求をだす（Ｓ４）。これはDNSプロトコルで行ってもよい。
すると、DRS３０２は、該当するFドメインに対して親PSアドレスのキャッシュを持っていないので、親DRS記憶部９３を参照して、Oドメインに対応する親DRSであるDRS301にFドメインの解決要求を出す（Ｓ５）。これは下記のURIを含むHTTPリクエストを用いてもよい。
http://(DSR302のアドレス)/PSes/f1578.site1.song.tv
するとDRS301は、PS505を割当てて、そのアドレスp.q.r2.s2でDRS302に解決応答する（Ｓ６）。この応答は下記の情報をXML形式で記述したものを本文に含むHTTPレスポンスでもよい。
f1578.site1.song.tv p.q.r2.s2
このように指定したＵＲＩに対して、そのリソースの状態をＸＭＬファイルで応答するＷｅｂサービスはRESTfulと呼ばれる（非特許文献７）。
その応答を受取ったDRS302は、Ｓ４で解決要求をしていたPS502に解決応答する（Ｓ７）。Ｓ４での解決要求がDNSプロトコルで行われた場合は、Ｓ７の解決応答もDNSプロトコルで行われる。
同様の手順をオリジンサイト１０４まで繰り返すと、HTTPリクエストはORG204まで転送される（Ｓ２１）。これに対してORG204は、F-URIで指定されたデータをHTTPレスポンスで同一サイト内のPS512に返送する（Ｓ２２）。これはさらに、PS507、PS505、PS502と転送され（Ｓ２３，Ｓ２４，Ｓ２５）、最後にクライアント４５に届く（Ｓ２６）。
図１１は、特にアクセス頻度の高いデータをオリジンサイトから予め各サイトに配置しておくための一連の動作の実施例を示している。
まず、オリジンサイト104のDRSは、その分配木上のリーフサイトであるサイト１０２のDRSに、配置したいコンテンツのURIにPSを割当てるようドメイン解決要求を出す（Ｔ１）。ここで「リーフサイト」とは、有向分配木において、さらに転送先のサイトがない一番先端のサイトを指す。
そして、サイト１０２のDRSから解決応答が戻ってくると（Ｔ２）、割当てられたPSに対して、そのコンテンツに対するURIに対してHTTPリクエストを出すように駆動する（Ｔ３）。これにより、サイト102内のPSは、HTTPリクエストを次に転送すべきサイト１０１内のPSに転送する（Ｔ４）。
より詳細な手順は、図１０と同じなので省略する。同様にして、HTTPリクエストは、Ｔ５，Ｔ６のように分配木上のサイト１０２からオリジンサイト１０４まで転送される。そして、これに基づいてオリジンサイト１０４から配置したいデータが、サイト１０３，１０１を経由してサイト１０２に届く（Ｔ７，Ｔ８，Ｔ９）。サイト103、101内のPSはデータを中継すると同時に本来のPSの機能としてこのデータをそれぞれ格納する。
これにより、リーフサイトから要求を上げていくだけで、ノンリーフサイトにはオリジンサイトからデータが転送されるときにキャッシュされる。よって、オリジンサイトから他の全てのサイトにHTTPリクエストを出すように指令する必要がない。また、エッジサイトからHTTPリクエスト／レスポンスでデータを取ってくるのと同じ仕組みでデータ配置ができ、PSやDRSに新たにオリジンサイトから各サイトへのプッシュ型配信のための手段を組込むための付加的なコストがかからなくてすむ。
また、上記システムによると、転送すべきコンテンツのデータのみならず、転送のためのオーバレイネットワークの制御に用いるデータもＨＴＴＰリクエストとＸＭＬファイルを含むＨＴＴＰレスポンスを用いて転送することで、使用するプロトコルがＨＴＴＰに統一できるので、コンテンツ分配・配信のためのオーバレイネットワークの運用が簡素化される。また制御に用いるＨＴＴＰレスポンスはＸＭＬ形式で記述することができるので、機能拡張が柔軟にできるようになる。
＜実施形態２＞
次に、本発明の第２の実施の形態について、図１２乃至図１５を参照して説明する。ここでは、上述した第１の実施形態とは異なり、各DRSにおける親DRSの解決は、全てオリジンサイトのDRSが行う、という構成を採っている。
図１２は、DRSの構成を示すブロック図である。この図に示すように、本実施形態におけるDRSは、データ処理装置８のみが図５と異なり、PS割当て部８１と、分配木算出部８２と、を備えている。
そして、分配木記憶部９６には、分配木算出部８３を用いて決定した、自サイトがルートとなる分配木に基づいて、自サイトを除いた各サイトとその親サイトとの組合せのエントリが記憶される。
次に、第２の実施形態の動作について説明する。図１３は、分配木算出部８３で自分がルートの分配木を作成するための動作を示す流れ図である。
ステップＳ６１、Ｓ６２は、実施形態１で説明した図６ａと同じである。ステップＳ６３’は、図６ａのステップＳ６３とは異なり、自サイトがオリジンサイトとなる有向分配木のみを算出する。そして、分配木記憶部９６を参照して、あらたに算出された分配木の構成が変わった場合は、分配木記憶部９６を更新し、そこから親DRSに変更のあった他のサイトを割り出して、変更がある全てのサイトのDRSに新しい親DRSを通知してステップＳ６１に戻る。この通知は、HTTP PUT リクエストを用いて行ってもよい。
なお、分配木算出部８３が他のサイトからのＲＴＴ統計値要求に対して行う動作は、図６ｂと同じなので、その説明は省略する。
図１４は、PS割当て部８１の自サイト内のドメイン解決に関する動作を示すフローチャートである。ここでは、図７ａに追加する機能についてのみ説明する。
ステップＳ７９で、あるオリジンサイトのDRSから親DRSの変更があったら、ステップＳ８０で、親DRS記憶部９３を更新し、親PSキャッシュ部９２で、オリジンサイトのDRSに対応するOドメイン（親DRS記憶部を参照すればわかる）を含む全Fドメインのエントリをクリアし、ローカルPSのアドレスキャッシュにおいて、当該Oドメインを含む全てのB-URIのエントリを管理手順で強制クリアする。
これらのクリアを行うのは、分配木の再構成があった場合に、上記各テーブルの更新をＴＴＬに頼るのではなく、直ちに再構成が反映されるようにするためである。上記に加えて、図７ｂと同じローカルＰＳの監視動作を行う。
以上説明した第２の実施形態の構成によると、各DRSは、自らがルートとなる分配木のみを算出して、その再構成後に更新のあった親DRSを他の全てのDRSに通知する。よって、各サイトのDRSが独立に親DRSテーブルを作成する分散型の第１の実施形態に比べて、次の効果がある。ひとつは、各DRSが持つ親DRSテーブルの内容が一致しないことでHTTP転送パスの最適性が失われる時間を削減することができる。最適性が失われたことの端的な例としては、分配木の再構成の前後でパスが変化したために、HTTPリクエストが再び同じPSに戻ってくることも起こりうる。これはPSが自分のアドレスをX-Forwarded-Forヘッダ内に記載されていることを見つければ、検出することができる。
また、上述した第１の実施形態では、各サイトのDRSが各DRSのサイトがルートとなる分配木をすべて算出する必要があるのに対して、この第２の実施形態では、自分がルートとなる分配木だけ算出すればよいので、計算量が削減できる。
次に、図１５を参照して、第２の実施形態に関する実施例を説明する。ここでは、実施形態１で説明した図１０の場合とは異なり、オリジンサイトのDRS３０４は、分配木が変更されたら親DRSの変わった各DRSに対して、Ｏドメインと親DRSの組合せを通知する。ここでは、Ｕ１，Ｕ２，Ｕ３で、DRS３０２，DRS３０１，DRS３０３に、親DRSを通知している。なお、他の動作は図１０と同じであるため、その詳細な説明は省略する。
＜実施形態３＞
次に、本発明の第３の実施形態を説明する。ここでは、第１、２の実施形態で設定された最適分配木による経路上において、スループットをより向上させるために、予めORGでファイルを分割してできたブロックのデータを、サイト間で並列に転送する点に特徴を有する。ただし、ブロック毎ではなく、並列転送されるサブストリーム単位でドメイン解決をすることで、制御負荷を削減する。
［オリジンサーバ（OGS）］
図１６に示すように、本実施形態におけるオリジンサーバOGS２は、送信装置１２、受信装置１３、処理装置１０、記憶装置７からなる。
処理装置１０（コンテンツ配信手段）は、プログラムが組み込まれることで構築された、発行処理部１００１と、Webサーバ処理部１００２と、クライアント処理部１００３と、を備える。
Webサーバ処理部１００２は、クライアントから受信したHTTPリクエストに対して、コンテンツのデータを送信したり、格納してあるデータをＨＴＭＬデータに作り上げてそれをＨＴＴＰで送り出したりする機能を有する。特に、本実施形態では、後述するように、経路上の同一のサイトに設置された複数のPSに対して、コンテンツを分割したブロック群からなるサブストリームデータを、クライアントに対して並列配信する。
発行処理部１００１は、取得したデータに対してURIを付与・変換する等の加工アプリケーションにより実現される。
クライアント処理部１００３は、Ｗｅｂサーバ処理部１００２からクライアントからのメタデータ要求を受取ったら、対応するメタデータを取り出し、クライアントのＩＰアドレスに基づいて地理データ記憶部７３を参照して、最寄りのエッジサイトのDRSを決定し、メタデータに書き加えて、Ｗｅｂサーバ処理部１００２に渡す。
記憶装置７は、ブロック記憶部７１と、メタデータ記憶部７２と、地理データ記憶部７３と、からなる。ブロック記憶部７１は、アップロードされたコンテンツのデータを記憶する。メタデータ記憶部７２には、Ｏ−ＵＲＩやパラメトリック表現したB-URIや発行者が付与したメタデータが記憶される。地理データ記憶部７３には、各サイトのDRSのアドレスと、それが対応するＩＰアドレスの範囲が格納されている。なお、記憶装置７は、例えば比較的容量の大きいストレージサーバ等で実現される。
次に、図１７ａを用いてORGの発行処理部７１における動作について詳しく説明する。まず、ステップＳ１７１で、Webサーバ処理部１００２からアップリードされたデータを渡されたら、ステップＳ１７２でファイルを１つもしくは複数のブロックに分割して、それぞれにURIをつけ、ブロック記憶部７１に格納する。その後、ステップＳ１７３で、メタデータを生成して、発行者からのメタデータと統合して、新たなメタデータを作り、URIを付与して対応したメタデータ記憶部７２に格納する。
次に、ステップＳ１２７でブロック毎につけるURIについて説明する。まず、各ブロックは必ずしも同じサイズである必要はない。そして、各ブロックを並列転送する際、同一PS間のHTTPコネクション上を転送されるブロックの集合をサブストリームデータと呼ぶことにする。すなわち、並列転送とは、それぞれがコンテンツを分割した複数のブロック（分割データ）を含む各サブストリームを複数、同時に転送していることといえる。
ただし、クライアントで受信後に直ちにビデオ再生できるようにするために、各ブロックは、巡回的に異なるサブストリームに属するようにする。すなわち、サブストリームの総数をZとすると、ブロックIDに対するサブストリームIDは、次で与える。
(サブストリームID)= {(ブロックID)-1} mod Z+1
つまり、各ブロックに、コンテンツが再生される順番に対応した識別番号であるブロックIDが付与されている場合には、ブロックID（実際には、ブロックID-1）をサブストリームの総数Zで割り、その余りの値（実際には、余りの値+1）を、当該ブロックが配置されるサブストリームのIDとする。このとき、各サブストリームには、ブロックIDが小さい順に先頭から配置することで、コンテンツ上における再生順序が早い順に、各ブロックが各サブストリームの先頭側から分散して配置される。これにより、各サブストリームが並列転送されても、コンテンツの先頭から配信することができる。
そして、サブストリーム単位でPSを割当てるようなドメイン解決をPSが行うことができるように、次に示すようなURIの変換を行う。なお、サブストリームの総数は、予めＺ＝３と与えられているものとする。また、ORG（ここではsite1で識別される）において、アップロード直後番組ファイル毎に付与されるURI（これをO-URIと呼ぶことにする）は、次のような構造をもつものとする。
O-URI： http://www.site1.song.net/videocast/channel3/item2/
ここで、「song.net」はこの配信サービスを提供する主体を示し、「site1」はこのコンテンツが発行者からアップロードされた先であるオリジンサイトを示し、「www」はオリジンサーバとしてのホスト名を示している。配信サービス提供主体がN個のサイトを運営している場合、例えば各サイトをsite1,…, siteNと示す。また、パスの部分において、「videocast」はコンテンツ提供サービスの名称を、「channel3」は個別のチャンネルを、「item2」は個別の配信プログラムをそれぞれ示している。
このファイルをセグメント化して得られるブロックに付与するURIは、O-URIの再後尾にブロック番号を示すものを加えて、B-URIと呼ぶことにする。
B-URI： http://www.site1.song.net/videocast/channel3/item2/block6
なお、背景技術のところでも記述したように、非特許文献１でも、B-URI相当のものを含むHTTPリクエストを中継経路上のPSに転送するが、B-URIを付与するのは本発明ではOGSであるのに対して、上記非特許文献ではO-URI相当を含むHTTPリクエストをクライアントから最初に転送されたプロキシが行う。
次にB-URIは、ＰＳが同一アイテム内のブロックから複数構成されるサブストリーム単位でプロキシサーバを割り当てることができるように、以下のように変換される。すなわち、
（１）まずO-URIをハッシュして（この値をここでは1578とする）、それにfをつけたf1578をもうけ、次にサブストリーム数３にzをつけたz3と一緒にしてz3f1578というドメインを作る。
（２）次にブロックIDの6に対するサブストリームIDの２とサブストリーム総数３に対して、s2というドメイン作る。
（３）最後に、上記を結合したs2.z3f1578というドメインを、最初のB-URIのwwwと入れ替える。
すると変換後のB-URIは次のようになる。
http://s2.z3f1578.site1.song.net/videocast/channel3/item2/block6
ここで、z3f1578.site1.song.netのように同一ファイルに対応するドメインをＦドメインと呼び、s2.z3f1578.site1.song.netのように同一ファイルの異なるサブストリームに対応するドメインをSドメインと呼ぶことにする。なお、もしクライアントもしくはＰＳが既存のものとは違って、ＵＲＩ毎にドメイン解決を要求できる場合は、f1578の部分は不要になる。
上記のように変換されたＵＲＩはユーザが目的のファイルを取得する際に用いるメタデータに書き込まれ、メタデータ記憶部７２に格納される。
なお、上記の変換でz3という記号を挿入したのは、転送先のＰＳに関するドメイン解決要求を親サイトのDRSに送る際に、同一Fドメインに対応する３つの全てのSドメインのそれぞれについて解決要求のメッセージを送るのではなく、最初にいずれかのＳドメインに関するドメイン解決要求がローカルなＰＳからあったら、ＦドメインについてＰＳ割当てのためのドメイン解決要求をする。これは、例えば次に示すＵＲＩをもつＨＴＴＰリクエストで行うことができる。
http://(親DRSのアドレス)/PSes?F-domain= z3f1578.site1.song.net.
これを受信した親DRSは、z3から直ちに３つのSドメインを再生して、それぞれにＰＳを割当てることができる。この３つの組合せは例えば次のように表現できる。
s1.z3f1578.site1.song.tv v.w.x.y1
s2.z3f1578.site1.song.tv v.w.x.y2
s3.z3f1578.site1.song.tv v.w.x.y3
上記の情報はＸＭＬ形式で記述して親DRSへのＨＴＴＰレスポンスに含めることができる。そしてこのような指定したＵＲＩに対して、そのリソースの状態をＸＭＬファイルで応答するＷｅｂサービスはRESTfulと呼ばれる（非特許文献７）。
ここで、逐次再生が必要でなく、単純にファイル全体を並列に転送したい場合は、例えばファイル全体を３つのブロックにわけ、変換されたB-URIとしては
http://s1.z3f1578.site1.song.net/videocast/channel3/item2/block1
http://s2.z3f1578.site1.song.net/videocast/channel3/item2/block2
http://s3.z3f1578.site1.song.net/videocast/channel3/item2/block3
というように、サブストリームＩＤとブロックＩＤが１対１のB-URIをサブストリーム総数だけ準備すれば十分である。
次に、ステップＳ１７３でのメタデータについて説明する。OGSは、次のようなメタデータを作ってメタデータ記憶部７２に格納する。これはクライアントからO-URIを含むHTTPリクエストでアクセスされる。
Ｏ−ＵＲＩ: http://www.site1.song.net/videocast/channel3/item2/
エッジサイトDRSのアドレス: 291.47.234.12、291.47.234.13
サブストリーム１内のB-URI群：
http://s1.z3f1578.site1.song.net/videocast/channel3/item2/block(3n+1);
n=0,..,1000
サブストリーム２内のB-URI群：
http://s2.z3f1578.site1.song.net/videocast/channel3/item2/block(3n+2);
n=0…,1000
サブストリーム３内のB-URI群：
http://s3.z3f1578.site1.song.net/videocast/channel3/item2/block(3n+3);
n=0,…,1000
上記において、ここで番組ファイルを組み立てるために取得すべきブロックに関するB-URIをそのまま全て書き下すとブロック総数が多い場合に情報量が肥大するので、それを防ぐために、サブストリーム毎にパラメトリックな表現を用いている。また、クライアントを誘導すべきエッジサイトのDRSのアドレスは、クライアントがメタデータを要求してきた時点そのクライアントのＩＰアドレス等に基づいて決定される。ここではDRSの障害を考慮して、決定された最適なエッジサイトにおけるDRSのアドレスが２つ記載されている。
次に、図１７ｂを用いてクライアント処理部１００３の動作について説明する。
ステップＳ１７５で、Webサーバ処理部１００２からメタデータ要求メッセージを渡されたら、ステップＳ１７６で、地理データ記憶部７３とクライアントIPアドレスを参照して、誘導先のエッジサイトのDRSアドレスを決定し、ステップＳ１７７で要求O-URIに対応するB-URI群や発行者が記述したメタデータをメタデータ記憶部から取り出して、DRSアドレスを更に書き加えて、Webサーバ処理部１００２に渡して終了する。
［ドメイン解決サーバ（DRS）］
DRSの構成は、第１の実施形態にあるように、分配木の再構成を分散的に行う場合は図５と同じであり、第２の実施形態にあるように分配木の再構成を集中的に行う場合は、図１２と同じである。
ここで、図１８に、ＤＲＳが有する親ＰＳキャッシュ部のテーブル構成を示す。第１、第２の実施形態では、Ｆドメインと親ＰＳアドレスの組合せを含むエントリを持つのに対して、本実施形態では、同一Ｆドメインに対する各Ｓドメインと親ＰＳアドレスの組合せを含むエントリをもつ。
次にDRSの動作について説明する。第１の実施形態にあるように、分配木の再構成を分散的に行う場合は、親DRS決定部の動作は図６と同じである。また、第２の実施形態にあるように分配木の再構成を集中的に行う場合は、分配木算出部の動作も図１３と同じである。具体的に、図１９ａ，ｂ，ｃを用いて、分配木の再構成を分散的に行う場合の、PS割当て部８１の動作について説明する。
図１９ａは、クライアントもしくはローカルＰＳからＳドメインに対するドメイン解決要求があったときの動作を示すフローチャートである。ステップＳ１９１で、クライアントFドメインから親PSアドレスへの解決要求あったら、ステップＳ１９２で、各Sドメインに対して、（１）親PSキャッシュ部にあるアドレスを応答、（２）ない場合は全Sドメインに対してローカルPSを割当てて、応答する。
ステップＳ１９３で、ローカルPSからSドメインに対する親PSアドレスの解決要求あったら、ステップＳ１９４で、（１）Sドメインに自分と同じOドメインを含む場合は、アドレス解決応答でOGSのアドレスを返す。（２）含まない場合は、親PSキャッシュ部にあるアドレスを応答し、（３）ない場合は親DRS記憶部を参照して、Oドメインに対応する親DRSに、Fドメインから親PSアドレスへの解決要求を送る。ここで、ローカルPSからのドメイン解決要求と応答は、既存のDNSプロトコルを用いて行われる。
図１９ｂは、PS割当て部８１において、親サイトのDRSからのドメイン解決応答があった、もしくは子サイトのDRSから全てのＳドメインに対するドメイン解決要求があった場合のときの動作を示すフローチャートである。
ステップＳ１９５で、親サイトのDRSからドメイン解決応答があったら、ステップＳ１９６で、Ｓドメインに対して割当てられたPSのアドレスを親PSキャッシュ部にキャッシュし、解決要求していたローカルPSに対して割当てられたアドレスで応答する。ステップＳ１９７で、子サイトのDRSから全てのＳドメインに対するドメイン解決要求があったら、ステップＳ１９８で、ローカルPS記憶部を参照してロバストハッシングにより各Ｓドメインに対応するPSアドレス群を決定し、解決要求してきた子DRSにそのアドレスを応答して終了する。
なお、上記ステップＳ１９８におけるロバストハッシングとしては、非特許文献１１もしくは特許文献３の方法に基づいて行う。これは、同じコンテンツが複数のPSに複製されることをなるべく防ぐ一方で、PSが増設もしくは減設されたときに、既存のPSを割当てられているSドメインに別のPSが割当てられるような割合を最小にするためのものである。
図１９ｃは、PS割当て部８１におけるローカルPSの監視動作を示すものである。ステップＳ１９９で、前回の監視動作から一定時間経過後、タイムアウト回数Ｎを０にして、ローカルPS記憶部にある各PSアドレスに向けてpingを送信する。ステップＳ２００でタイムアウトせずに戻ってきた場合は、そのPSの状態を使用化とする。タイムアウトした場合はNをインクリメントしてpingを再び送信する。そのタイムアウト回数が一定数以上になった場合は、そのPSの状態を使用不可とする。そしてステップＳ１９９に戻る。
［プロキシサーバ（ＰＳ）］
次に、本実施形態におけるプロキシサーバ（ＰＳ）について説明する。各サブストリームは個別のドメイン名を持っているので、ローカルサイトの各ＰＳは、ローカルサイトのDRSを使って、サブストリーム単位で親サイトのＰＳアドレスを解決させる。次に、解決された親ＰＳのアドレスに対して単一のＨＴＴＰパーシステントコネクションを設定して、同じサブストリーム内の各ブロックについて、その同一コネクション上をパイプライン形式で、すなわちＢ−ＵＲＩでのブロック番号が大きくなる順番で連続してＨＴＴＰリクエストを出し、ＨＴＴＰレスポンスでブロックのデータを取得する。
ここでは上述のメタデータに含まれる異なるＵＲＩすなわちブロック単位でＨＴＴＰコネクションを設定することはしない。パーシステントコネクションおよびパイプライニングについては非特許文献１２に記載がある。
［クライアント］
次に、本実施形態におけるクライアントについて説明する。図２０に示すように、クライアント４１は、送信装置２２と受信装置２３とデータ処理装置２４と記憶装置１１と入力装置２５と出力装置２１とからからなる。ここで、入力装置２５および出力装置２１は、ユーザが使うものであり、例えばそれぞれキーボード、液晶ディスプレイである。
データ処理装置２４は、再生処理部２４０２と、表示処理部２４０１と、背景処理部２４０３とからなる。表示処理部２４０１は、ユーザの入力装置２５からの入力信号に基づいて表示を変更し、また再生処理部２４０２から受取ったデータを処理して出力装置２１に渡す。
背景処理部２４０３は、送受信装置を通じて表示処理部２４０１からの指示でデータの送受信を行う。そのために、エッジサイトのDRSとの間でドメイン解決も行う。なお、背景処理部２４０３と表示処理部２４０１は、Webブラウザの主要な機能に含まれる。
再生処理部２４０２は、背景処理部２４０３から再生開始の支持があったら、ブロック記憶部１１０１からブロックを順番に取り出し、ビデオであれば復号化を行って出力装置２１に表示する。なお、記憶装置１１は、ブロック記憶部１１０１とメタデータ記憶部１１０２とからなる。
次に、クライアントの動作について説明する。まず、出力装置２１で示されているＷｅｂ画面上に示された番組アイテムへのリンクに関して、入力装置２５からそのリンクがクリックされた信号が表示処理手段に伝わると、メタデータの要求をＯＲＧに送る。その後表示処理部２４０１は、ＯＧＳからメタデータを取得すると、それをメタデータ記憶部１１０２に格納し、背景処理部２４０３にコンテンツ取得の指示をだす。
図２１は、クライアントの背景処理部２４０３のその後の動作を説明するためのフローチャートである。ステップＳ２１１で、表示処理部２４０１からコンテンツデータ取得指示を受けたら、ステップＳ２１２で、メタデータ記憶部１１０２からメタデータを取り出して、メタデータのファイル内に記載されたパラメトリックなＵＲＩ群における全てのＳドメインに対してまとめてＰＳのドメイン解決を行う。
ステップＳ２１３で、ドメイン解決された各PSにパーシステントなＨＴＴＰコネクションを設定し、同じサブストリームに属する異なるブロックに対するHTTPリクエストを、パイプライン形式で転送して終了する。
ステップＳ２１４で、Ｂ−ＵＲＩに関するＨＴＴＰレスポンスとしてブロックデータを受信したら、ステップＳ２１５で、ブロック記憶部１１０１に格納する。ステップＳ２１６で、取得したブロックがＦドメインに関して先頭ブロックである場合は、再生処理部２４０２に再生開始の指示を行う。
本実施形態は、以上のような構成により、ファイルをセグメント化してブロック単位で転送する場合でも、サブストリーム単位でドメイン解決をするので、ブロック単位（ここではB-URIで識別される）でドメイン解決を行なう場合に比べてドメイン解決に必要となるメッセージ数を削減することができる。
さらに、各サブストリームにPSを割当てるためのドメイン解決をまとめて行うので、サブストリーム毎に行う場合に比べてドメイン解決に必要となるメッセージ数を削減することができる。
また、クライアントとＰＳ間、経路上の１組のＰＳ間では、サブストリーム単位でパーシステントコネクションが設定されて、同じサブストリームに含まれる各ブロックは一旦設定された同一のパーシステントコネクション上を転送するので、非特許文献１におけるように、ＰＳがブロック単位でＨＴＴＰコネクションを設定するのに比べて処理付加や設定遅延を削減することができる。
次に、本実施形態における動作を説明する。まず、図２２は、ドメイン解決の動作例を示す。クライアントがアクセスするトップページには、メタデータ情報へのリンクが張られている。これはＯ−ＵＲＩをもっている。これをクリックすると、ＯＧＳよりメタデータ（各サブストリーム内のB-URIをパラメトリック表現してある）と、上述した背景処理部２４０３を実現するjavascriptプログラムがダウンロードされる（Ｔ１）。ここで、クライアントのＷｅｂブラウザにおいて動作するプログラムであるＪａｖａｓｃｒｉｐｔについては、非特許文献１３に記述がある。
次に、クライアントの背景処理部２４０３は、メタデータに含まれるs1,s2,s3のドメインについて、メタデータ内に示されているDRS３０２にまとめてドメイン解決要求すると、それぞれのドメインについて、同一のサイト１０２内に設置された複数のPS、つまり、PS504,505,506のアドレスが解決される（Ｔ２）。
次に、それぞれ解決されたアドレスをもつPSに対して、パーシステントコネクションを設定し、各サブストリームに含まれる最初のブロックに相当するURIを含むHTTPリクエストを出す（Ｔ３，Ｔ４，Ｔ５）。すると、各PSにはキャッシュが無いので、それぞれのPSはローカルDRS３０２に、それぞれ担当するＳドメインについて、親PSのドメイン解決要求を出す（Ｔ６，Ｔ７，Ｔ８）。
次に、DRS３０２のＰＳ割当て部は、Ｔ６，Ｔ７，Ｔ８のドメイン解決要求のいずれか一つを最初に受取ったタイミングで、親サイトDRS３０１にFドメインの解決要求を出す（Ｔ９）。これに対して、DRS301がDRS302へ、s1,s2,s3を含む各ドメインにそれぞれPS501、PS502、PS503のアドレスを応答してきたら（Ｔ１０）、PS501, PS502, PS503にそれぞれ対応するPSのアドレスで解決応答する（Ｔ１１，Ｔ１２，Ｔ１３）。これらのPSは、受取った親PSに対してパーシステントコネクションを設定し、サブストリームIDであるs１，s２，s３をそれぞれもつＢ−ＵＲＩを含むHTTPリクエストをHTTP1.1のパイプライン形式で送出する（Ｔ１４，Ｔ１５，Ｔ１６）。
なお、クライアントも、PSも、URI変換により同じドメイン名をもつサブストリーム内の各ブロックに対しては、最初にそのドメインに対して割当てるべきPSが解決されたら、以降はブロック毎にドメイン解決することなく、HTTPリクエストを出すことができる。
図２３は、サブストリームの並列転送状況とサブストリーム内のブロック番号の順番を示す説明図である。この場合サブストリームは３つあり、各サブストリームで転送されるブロックとその順番は
s1： block1, block4, block7 , ....
s2： block2, block5, block8, ....
s3： block3, block6, block9, ....
となる。
オリジンサイト103でst1,st2,st3に割当てたPSは507, 508, 509である。中継サイト101でst1,st2,st3に割当てたPSは501, 502, 503である。エッジサイト102でst1,st2,st3に割当てたPSは504, 505, 506である。クライアント４６の内部において背景処理部が各コネクションからラウンドロビンのように受信したブロックは、クライアント内の再生処理部において順番に組み立て・再生される。
以上のように、本実施形態では、オリジンサイト１０３が、経路上の同一のサイトに設置された複数のPSに対して、コンテンツを分割したブロック群からなるサブストリームデータを並列配信するため、スループットをより向上させることができる。
なお、上記では、実施形態１，２で説明したように、ドメイン解決サーバにて設定した有向分配木に基づく経路に従って、同一サイト上の複数のPSに対して複数のサブストリームデータを並列転送する場合を説明したが、予め設定された経路に従って、同一サイト上の複数のPSに対して、複数のサブストリームデータを並列転送してもよい。
＜実施形態４＞
次に、本発明の第４の実施形態について図面を参照して詳細に説明する。本実施形態では、クライアントがブラウザ上から設定できるHTTPコネクション数が限られている場合に、転送網内では、その定数倍のサブストリームを用いて高速転送する、という構成を有している点に特徴を有する。
図２４は、サイトの構成を説明する図である。第１の実施形態に加えて、あらたにサイト内に変換サーバ（中継サーバ）２３０１，２３０２（以下、「ＴＳ」と呼ぶ）が加わる。この変換サーバ２３０１，２３０２は、コネクション設定数に制限のあるクライアントとのデータのやり取りを直接行うと共に、同じサイト内のPSとHTTPコネクションを設定してデータのやり取りをおこなう。これにより、TSはサブストリームの載せ替えを行う。具体的には、PSとの間で、所定のセッション数にてサブストリームデータの送受信を行うと共に、クライアントに対しては、当該クライアントが接続可能なセッション数の上限数の範囲内にサブストリームデータを集約して、クライアントに転送する機能（転送手段）を有する。
ただし、TSはPSと違ってURIで区別できるブロックのキャッシュは行わない。TSとPSには異なるIPアドレスが付与され、DRS３０２は、送られてきたデータのソースアドレスをみてTSとPSを区別することができるものとする。
図２５は、DRS３０２のPS割当て部の動作を示すフローチャートである。ここでは、第３の実施形態と異なる部分について説明する。図１９ａを変形して次のようになる。
ステップＳ２５１で、クライアントからFドメインの解決要求がHTTPリクエストとしてあったら、ステップＳ２５２で、該当する全SドメインのそれぞれにTSを割当てて、そのアドレスを返す。ただし、異なるTSのアドレスは、クライアントのコネクション設定上限数以下になるようにする。
ステップＳ２５３で、TSからSドメインの解決要求があったら、ステップＳ２５４で、対応するSドメインに割当てたローカルPSがローカルPSキャッシュ部にある場合はそれを応答し、ない場合はロバストハッシングにより全てのSドメインに対してローカルPSを割り当ててそのアドレスを応答する。
ステップＳ２５５で、ローカルなPSからSドメインに関して解決要求があったら、ステップＳ２５６で、（１）（２）親PSキャッシュ部を参照して応答し、（３）無い場合は、Oドメインに対応する親DRSに、全てのSドメインに対する親PSのドメイン解決要求をする。TSはPSと同じ動作をするが、ＰＳはＨＴＴＰレスポンスが戻って来たらそのデータをキャッシュしてもよいが、ＴＳはキャッシュしない。
ステップＳ２５６におけるロバストハッシングとしては、非特許文献１１もしくは特許文献３の方法に基づいて行う。これは、同じコンテンツが複数のPSに複製されることをなるべく防ぐ一方で、PSが増設もしくは減設されたときに、既存のPSを割当てられているSドメインに別のPSが割当てられるような割合を最小にするためのものである。
本実施形態は、以上のように構成することにより、サブストリームを載せ替えるためのTSをPSとクライアントの間に入れるので、クライアントにHTTPコネクション設定数の上限があっても、これとは独立に、分配網内では並列転送するサブストリーム総数を設定してスループットの向上を図ることができる。
次に、第４の実施形態における実施例について説明する。図２６は、クライアント４５、DRS３０２, TS２３０１，２３０２、PS５０１〜５０６の間の連携動作を示す図である。ここではクライアントが終端できるHTTPコネクションが「２」であるのに対して、転送網内ではサブストリーム総数を「６」として並列転送を行うようにTSサーバがサブストリームの載せ換えを行う。
以下IDがnであるサブストリームをssnと略記することにする。
クライアントはコネクション数上限「２」で、メタデータ内で指定されたDRS３０２にFドメインの解決を要求すると、ss1, ss2, ss3にはTS２３０１のアドレスを、ss4, ss5, ss6にはTS2302のアドレスで解決応答されてくる。するとクライアントは、TS2301およびTS2302にそれぞれパーシステントコネクションを設定して、ss1, ss2, ss3 およびss4, ss5, ss6に属するブロックのURI（B-URI）を含むHTTPリクエストをパイプライン形式で送信する。すなわち、ＴＳ２３０１へは、
block1, block2, block3, block7, block8, block9,…
にそれぞれ対応するB-URIを含むＨＴＴＰリクエストをその順番でＴＳ２３０１に送る。
また、ＴＳ２３０２には
block4, block5, block6, block10, block11, block12,…
にそれぞれ対応するB-URIを含むＨＴＴＰリクエストをその順番でＴＳ２３０２に送る。
これらを受取ったTS２３０１は、ss1, ss2, ss3の各サブストリームIDを含むＢ−ＵＲＩを始めて検出したら、DRS３０２に各Sドメインの解決要求を転送する。同様にして、TS230２は各Sドメインの解決要求をDRS３５に転送する。これらの要求はDNSプロトコルを用いて行われる。
そして、DRS３０２は、ss1, ss2, ss3に関する各Sドメインの解決要求に対してPS501、PS502、PS502を割当ててTS2301に応答したとする。またDRS302はss4, ss5, ss6に関する各Sドメインの解決要求に対してPS504、PS505、PS506をそれぞれ割当ててTS2302に応答したとする。するとTS2301はPS501, PS502, PS503に対してパーシステントコネクションを設定して、各Sドメインに対応するB-URIを含むリクエストを対応する各パーシステントコネクション上に転送する。
同様に、TS2302は、PS504, PS505, PS506に対してそれぞれパーシステントコネクションを設定して、各ドメインに対応するB-URIを含むリクエストを対応する各パーシステントコネクション上に転送する。PSは自分がデータを保持する場合は、TSにブロックを返すが、無い場合はDRSに親サイトのPSのドメイン解決を要求する。
なお、上記各実施形態においてプログラムは、記憶装置に記憶されていたり、コンピュータが読み取り可能な記録媒体に記録されている。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、及び、半導体メモリ等の可搬性を有する媒体である。
以上、上記各実施形態を参照して本願発明を説明したが、本願発明は、上述した実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明の範囲内で当業者が理解しうる様々な変更をすることができる。
なお、本発明は、日本国にて２０１０年９月２日に特許出願された特願２０１０−１９６４１６の特許出願に基づく優先権主張の利益を享受するものであり、当該特許出願に記載された内容は、全て本明細書に含まれるものとする。
＜付記＞
上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明におけるデータ転送システムの構成の概略を、図２７及び図２８のブロック図を参照して説明する。また、本発明におけるプログラム、情報処理方法等の構成の概略について説明する。但し、本発明は、以下の構成に限定されない。
（付記１−１：図２７参照）
コンテンツが蓄積されたオリジンサーバ５０１０と、要求されたコンテンツを転送する複数のプロキシサーバ５０２０と、クライアント６０００がデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバ５０３０と、を設置したサイト５０００，５１００，５２００が、ネットワークを介して複数接続されており、
前記ドメイン解決サーバ５０３０が、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段５０３１と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段５０３２と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段５０３３と、を備え、
前記経路設定手段５０３２は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
前記割り当て手段５０３３は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である親サイトにあるプロキシサーバを自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
データ転送システム。
（付記１−２）
付記１−１に記載のデータ転送システムであって、
前記計測手段は、各サイトに設置されたドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、
データ転送システム。
（付記１−３）
付記１−２に記載のデータ転送システムであって、
前記計測手段は、前記リンクパラメータとして、前記各サイトにそれぞれ設置された前記各ドメイン解決サーバ間におけるラウンドトリップタイムを計測し、
前記経路決定手段は、前記各経路上における各サイト間のラウンドトリップタイムのうちの最大値が最小となる経路を設定する、
データ転送システム。
（付記１−４）
付記１−２に記載のデータ転送システムであって、
前記計測手段は、前記リンクパラメータとして、前記各サイトにそれぞれ設置された前期各ドメイン解決サーバ間におけるラウンドトリップタイムを計測し、
前記経路決定手段は、前記各経路上における各サイト間のラウンドトリップタイムの総和が最小となる経路を設定する、
データ転送システム。
（付記１−５）
付記１−２乃至１−４のいずれかに記載のデータ転送システムであって、
前記ドメイン解決サーバの前記計測手段は、他のドメイン解決サーバに対して、自己であるドメイン解決サーバと他のドメイン解決サーバとの間における前記リンクパラメータを計測すると共に、この計測時に、他のドメイン解決サーバに対して当該他のドメイン解決サーバが既に計測した計測結果を要求して取得する、
データ転送システム。
（付記１−６）
付記１−１乃至１−５のいずれかに記載のデータ転送システムであって、
前記ドメイン解決サーバが備える前記計測手段と前記経路設定手段とは、予め設定されたタイミングで作動して、経路及び親ドメイン解決サーバの設定を行う、
データ転送システム。
（付記１−７）
付記１−１乃至１−６のいずれかに記載のデータ転送システムであって、
前記各サイトの各ドメイン解決サーバが備えた前記経路設定手段は、自サイトの前記オリジンサーバが記憶されているコンテンツを配信する経路を決定すると共に、前記親ドメイン解決サーバを決定して、他のドメイン解決サーバに通知し、前記他のドメイン解決サーバは、それに基づいて親ドメイン解決サーバを設定する、
データ転送システム。
（付記１−８）
コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバとを設置したサイトが、ネットワークを介して複数接続されている場合における前記ドメイン解決サーバであって、
各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を備え、
前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
ドメイン解決サーバ。
（付記１−９）
付記１−８に記載のドメイン解決サーバであって、
前記計測手段は、各サイトに設定された各ドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、
ドメイン解決サーバ。
（付記１−１０）
コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバとを設置したサイトが、ネットワークを介して複数接続されている場合における前記ドメイン解決サーバに組み込まれるプログラムであって、
前記ドメイン解決サーバに、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を実現すると共に、
前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
プログラム。
（付記１−１１）
付記１−１０に記載のプログラムであって、
前記計測手段は、各サイトに設定された各ドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、
プログラム。
（付記１−１２）
コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおけるデータ転送方法であって、
前記ドメイン解決サーバが、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測し、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定し、前記ドメインに対応するプロキシサーバを割り当てると共に、
前記経路設定時に、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
前記割り当て時に、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
データ転送方法。
（付記１−１３）
付記１−１２に記載のデータ転送方法であって、
前記リンクパラメータの計測時に、各サイトに設定された各ドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、
データ転送方法。
（付記２−１：図２８参照）
コンテンツが蓄積されたオリジンサーバ７０１０と、要求されたコンテンツを転送する複数のプロキシサーバ７０２０と、クライアント８０００がデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバ７０３０と、を設置したサイト７０００，７１００，７２００が、ネットワークを介して複数接続されており、
前記オリジンサーバ７０１０は、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが１つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与するコンテンツ処理手段７０１１を備え、
前記ドメイン解決サーバ７０３０は、前記各サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定する割り当て手段７０３１を備え、
前記割り当て手段７０３１は、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームのドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求をするときに、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、
データ転送システム。
（付記２−２）
付記２−１に記載のデータ転送システムであって、
前記オリジンサーバが有する前記コンテンツ処理手段は、前記各ブロックには、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームのドメインを含む識別子を付与する、
データ転送システム。
（付記２−３）
付記２−１又は２−２に記載のデータ転送システムであって、
前記オリジンサーバが有する前記コンテンツ処理手段は、前記サブストリームの総数を含む前記識別子を、前記ブロックに付与する、
データ転送システム。
（付記２−４）
付記２−１乃至２−３のいずれかに記載のデータ転送システムであって、
前記クライアントがアクセスしたエッジサイトにおいて、前記クライアントと前記プロキシサーバとの間に、前記コンテンツを転送する中継サーバを備え、
前記ドメイン解決サーバの割り当て手段は、前記クライアントのドメイン解決要求に対して、前記クライアントが設定可能なコネクション数の上限以内の中継サーバを割当てる、
データ転送システム。
（付記２−５）
コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記オリジンサーバであって、
コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが１つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与するコンテンツ処理手段を備え、
前記コンテンツ処理手段は、前記各ブロックに、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームに対応するドメインを含む識別子を付与する、
オリジンサーバ。
（付記２−６）
付記２−５に記載のオリジンサーバであって、
前記コンテンツ処理手段は、サブストリームの総数を含む前記識別子を、前記ブロックに付与する、
オリジンサーバ。
（付記２−７）
コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記オリジンサーバに組み込まれるプログラムであって、
前記オリジンサーバに、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが１つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与するコンテンツ処理手段を実現させると共に、
前記コンテンツ処理手段は、前記各ブロックに、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームに対応するドメインを含む識別子を付与する、
プログラム。
（付記２−８）
コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記ドメイン解決サーバであって、
前記オリジンサーバにて、コンテンツを分割してできるブロックに、当該ブロックが１つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子が付与されており、
前記サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定する割り当て手段を備え、
前記割り当て手段は、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームに対応するドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの所与の経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求において、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、
ドメイン解決サーバ。
（付記２−９）
コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記ドメイン解決サーバに組み込まれるプログラムであって、
前記オリジンサーバにて、コンテンツを分割してできるブロックに、当該ブロックが１つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子が付与されており、
前記ドメイン解決サーバに、前記サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定する割り当て手段を実現すると共に、
前記割り当て手段は、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームに対応するドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの所与の経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求において、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、
プログラム。
（付記２−１０）
コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおけるデータ転送方法であって、
前記オリジンサーバが、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが１つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与し、
前記ドメイン解決サーバが、前記各サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定し、
前記ドメイン解決サーバによるプロキシサーバの割り当て時に、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームのドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求をするときに、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、
データ転送方法。
（付記２−１１）
付記２−１０に記載のデータ転送方法であって、
前記オリジンサーバが前記ブロックに識別子を付与するときに、前記各ブロックには、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームのドメインを含む識別子を付与する、
データ転送方法。
以上のように、本発明は、ネットワーク運用単位であるASの多数から構成されるインターネット上に地理的に分散配置された複数のサーバサイトもしくはデータセンタからのコンテンツデータの配信サービスやアプリケーションデータの配信サービスといった用途に適用できる。また、本発明によれば、オリジンサイトからエッジサイト間へのコンテンツの分配のみならず、OGSのアプリケーションで処理した結果を、１つもしくは複数の中継サイトを経由してエンドユーザのWebクライアントに転送するアプリケーション配信にも使える。
１０１〜１０４ サイト
２０２，２０４ オリジンサーバ（OGS）
１２ 送信装置
１３ 受信装置
１０ 処理装置
１００１ 発行処理部
１００２ Webサーバ処理部
１００３ クライアント処理部
７ 記憶装置
７１ ブロック記憶部
７２ メタデータ記憶部
７３ 地理データ記憶部
３０１〜３０４ ドメイン解決サーバ（DRS）
１４ 送信装置
１５ 受信装置
８ データ処理装置
８１ ＰＳ割り当て部
８２ 親ＤＲＳ決定部
８３ 分配木算出部
９ 記憶装置
９１ ローカルＰＳ記憶部
９２ 親ＰＳキャッシュ部
９３ 親ＤＲＳ記憶部
９４ ＲＴＴ行列記憶部
９５ ＲＴＴ統計記憶部
９６ 分配木記憶部
４１〜４５ クライアント
２１ 出力装置
２２ 送信装置
２３ 受信装置
２４ データ処理装置
２５ 入力装置
２４０１ 表示処理部
２４０２ 再生処理部
２４０３ 背景処理部
１１ 記憶装置
１１０１ ブロック記憶部
１１０２ メタデータ記憶部
５０１〜５１２ プロキシサーバ（PS）
１８ サブネットワーク
１９ マルチレイヤスイッチ
２０ エッジルータ
２３０１，２３０２ 変換サーバ（ＴＳ）

Claims (13)

  1. コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されており、
    前記ドメイン解決サーバが、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を備え、
    前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
    前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である親サイトにあるプロキシサーバを自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
    データ転送システム。
  2. 請求項１に記載のデータ転送システムであって、
    前記計測手段は、各サイトに設置されたドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、
    データ転送システム。
  3. 請求項２に記載のデータ転送システムであって、
    前記計測手段は、前記リンクパラメータとして、前記各サイトにそれぞれ設置された前記各ドメイン解決サーバ間におけるラウンドトリップタイムを計測し、
    前記経路設定手段は、前記各経路上における各サイト間のラウンドトリップタイムのうちの最大値が最小となる経路を設定する、
    データ転送システム。
  4. 請求項２に記載のデータ転送システムであって、
    前記計測手段は、前記リンクパラメータとして、前記各サイトにそれぞれ設置された前期各ドメイン解決サーバ間におけるラウンドトリップタイムを計測し、
    前記経路設定手段は、前記各経路上における各サイト間のラウンドトリップタイムの総和が最小となる経路を設定する、
    データ転送システム。
  5. 請求項２乃至４のいずれかに記載のデータ転送システムであって、
    前記ドメイン解決サーバの前記計測手段は、他のドメイン解決サーバに対して、自己であるドメイン解決サーバと他のドメイン解決サーバとの間における前記リンクパラメータを計測すると共に、この計測時に、他のドメイン解決サーバに対して当該他のドメイン解決サーバが既に計測した計測結果を要求して取得する、
    データ転送システム。
  6. 請求項１乃至５のいずれかに記載のデータ転送システムであって、
    前記ドメイン解決サーバが備える前記計測手段と前記経路設定手段とは、予め設定されたタイミングで作動して、経路及び親ドメイン解決サーバの設定を行う、
    データ転送システム。
  7. 請求項１乃至６のいずれかに記載のデータ転送システムであって、
    前記各サイトの各ドメイン解決サーバが備えた前記経路設定手段は、自サイトの前記オリジンサーバが記憶されているコンテンツを配信する経路を決定すると共に、前記親ドメイン解決サーバを決定して、他のドメイン解決サーバに通知し、前記他のドメイン解決サーバは、それに基づいて親ドメイン解決サーバを設定する、
    データ転送システム。
  8. コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバとを設置したサイトが、ネットワークを介して複数接続されている場合における前記ドメイン解決サーバであって、
    各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を備え、
    前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
    前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
    ドメイン解決サーバ。
  9. 請求項８に記載のドメイン解決サーバであって、
    前記計測手段は、各サイトに設定された各ドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、
    ドメイン解決サーバ。
  10. コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバとを設置したサイトが、ネットワークを介して複数接続されている場合における前記ドメイン解決サーバに組み込まれるプログラムであって、
    前記ドメイン解決サーバに、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を実現すると共に、
    前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
    前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
    プログラム。
  11. 請求項１０に記載のプログラムであって、
    前記計測手段は、各サイトに設定された各ドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、
    プログラム。
  12. コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおけるデータ転送方法であって、
    前記ドメイン解決サーバが、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測し、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定し、前記ドメインに対応するプロキシサーバを割り当てると共に、
    前記経路設定時に、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、
    前記割り当て時に、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、
    データ転送方法。
  13. 請求項１２に記載のデータ転送方法であって、
    前記リンクパラメータの計測時に、各サイトに設定された各ドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、
    データ転送方法。
JP2012531671A 2010-09-02 2011-08-23 データ転送システム Active JP5803924B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012531671A JP5803924B2 (ja) 2010-09-02 2011-08-23 データ転送システム

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2010196416 2010-09-02
JP2010196416 2010-09-02
PCT/JP2011/004665 WO2012029247A1 (ja) 2010-09-02 2011-08-23 データ転送システム
JP2012531671A JP5803924B2 (ja) 2010-09-02 2011-08-23 データ転送システム

Publications (2)

Publication Number Publication Date
JPWO2012029247A1 JPWO2012029247A1 (ja) 2013-10-28
JP5803924B2 true JP5803924B2 (ja) 2015-11-04

Family

ID=45772374

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012531671A Active JP5803924B2 (ja) 2010-09-02 2011-08-23 データ転送システム

Country Status (3)

Country Link
US (1) US20130151664A1 (ja)
JP (1) JP5803924B2 (ja)
WO (1) WO2012029247A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10715484B1 (en) 2019-12-11 2020-07-14 CallFire, Inc. Domain management and synchronization system
JP7248600B2 (ja) * 2020-01-21 2023-03-29 株式会社日立製作所 計算機システム及びデータ転送の制御方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6108703A (en) * 1998-07-14 2000-08-22 Massachusetts Institute Of Technology Global hosting system
US20040133391A1 (en) * 2002-09-12 2004-07-08 Antonio Bovo Non-invasive estimation of round trip time a packet-oriented acknowledge-based transmission system
US6820133B1 (en) * 2000-02-07 2004-11-16 Netli, Inc. System and method for high-performance delivery of web content using high-performance communications protocol between the first and second specialized intermediate nodes to optimize a measure of communications performance between the source and the destination
JP2009522877A (ja) * 2005-12-30 2009-06-11 アカマイ テクノロジーズ，インク． 任意のデータフロー用の高信頼性、高スループット、高パフォーマンス転送及びルーティングメカニズム

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7424526B1 (en) * 2001-07-31 2008-09-09 Sprint Communications Company L.P. Internet service node incorporating a bandwidth measurement device and associated methods for evaluating data transfers

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6108703A (en) * 1998-07-14 2000-08-22 Massachusetts Institute Of Technology Global hosting system
US6820133B1 (en) * 2000-02-07 2004-11-16 Netli, Inc. System and method for high-performance delivery of web content using high-performance communications protocol between the first and second specialized intermediate nodes to optimize a measure of communications performance between the source and the destination
US20040133391A1 (en) * 2002-09-12 2004-07-08 Antonio Bovo Non-invasive estimation of round trip time a packet-oriented acknowledge-based transmission system
JP2009522877A (ja) * 2005-12-30 2009-06-11 アカマイ テクノロジーズ，インク． 任意のデータフロー用の高信頼性、高スループット、高パフォーマンス転送及びルーティングメカニズム

Also Published As

Publication number Publication date
US20130151664A1 (en) 2013-06-13
WO2012029247A1 (ja) 2012-03-08
JPWO2012029247A1 (ja) 2013-10-28

Similar Documents

Publication Publication Date Title
US9769072B2 (en) Method and apparatus for scalable content routing and mobility in named data networks
JP5050095B2 (ja) Ｐ２ｐコンテンツ共有のための方法、システム、及びノード
US7978631B1 (en) Method and apparatus for encoding and mapping of virtual addresses for clusters
EP2901308B1 (en) Load distribution in data networks
US9515920B2 (en) Name-based neighbor discovery and multi-hop service discovery in information-centric networks
CN102984289B (zh) 促进nat穿透的方法以及移动设备
US10567332B2 (en) Content delivery network optimization system
US10263950B2 (en) Directing clients based on communication format
CN107733950B (zh) 用于访问网站的方法和装置
TWI584194B (zh) 在一服務導向架構（ｓｏａ）網路中尋求服務之技術
US20120191769A1 (en) Site-aware distributed file system access from outside enterprise network
Xie et al. Supporting seamless virtual machine migration via named data networking in cloud data center
JP5716745B2 (ja) データ転送システム
CN101110830A (zh) 创建多维地址协议的方法、装置和系统
JP5803924B2 (ja) データ転送システム
Ijaz et al. A survey and comparison on overlay‐underlay mapping techniques in peer‐to‐peer overlay networks
CN109644160B (zh) 通过分类在icn中进行名称解析和制作者选择的混合方法
JP2011150382A (ja) コンテンツ配信システムと方法およびプログラム
Shukla et al. Towards software defined low maintenance structured peer-to-peer overlays
Stevens et al. Analysis of an anycast based overlay system for scalable service discovery and execution
Banerjee et al. The survey, research challenges, and opportunities in ICN
Ndlovu et al. A review of service discovery schemes in wireless mesh networks
Umaparvathi et al. Analysis of creido enhanced chord overlay protocol under different movement models in delay tolerant networks
Rubambiza et al. EdgeRDV: A Framework for Edge Workload Management at Scale
Li et al. SVDR: A scalable virtual domain-based routing scheme for CCN

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140711

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150609

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150703

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: 20150804

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150817

R150 Certificate of patent or registration of utility model

Ref document number: 5803924

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150