JP2016525256A - 冗長データアクセスを提供するための方法および装置 - Google Patents

Abstract

様々な実施形態が、冗長データアクセスを提供するための方法および装置を提供する。特に、データアイテムを求めるクライアントリクエストへの応答は、対応する選択された複数のサーバのそれぞれによってクライアントに提供されるデータアイテムのデータセグメントを選択することを含む。特に、データセグメントは、データアイテムと比較してサイズが小さく、送信されたデータセグメントの真部分集合を用いてデータアイテムが構築され得るように、構成される。

Description

本発明は、一般的に、冗長データアクセスを提供するための方法および装置に関する。

この項目では、本発明のよりよい理解を容易にする助けとなり得る態様を紹介する。したがって、この項目の記載は、この観点から読まれるべきであり、先行技術に何が含まれるのか、または先行技術に何が含まれないのか、に関する承認として理解されるべきではない。

いくつかの知られている冗長データアクセスのソリューションでは、クライアントが、Ｎ個のリクエストを異なる複数のサーバに送り、返答として受信された第１の応答を処理する。

以下の概要においてはいくつかの単純化がなされる場合があり得、それは、様々な例示的な実施形態のいくつかの態様を強調し紹介するためであることが意図されているのであるが、そのような単純化が本発明の範囲を限定するためのものであることは、意図されていない。当業者が本発明の概念を作り用いることを可能にするのに十分な好適で例示的な実施形態の詳細な説明が、後の項目で続くことになる。

様々な実施形態が、冗長データアクセスを提供するための方法および装置を提供する。特に、データアイテムを求めるクライアントリクエストへの応答は、対応する選択された複数のサーバのそれぞれによってクライアントに提供されるデータアイテムのデータセグメントを選択することを含む。特に、データセグメントは、データアイテムと比較してサイズが小さく、送信されたデータセグメントの真部分集合を用いてデータアイテムが構築され得るように構成される。

第１の実施形態では、冗長データアクセスを提供するための装置が提供される。この装置は、データ記憶装置と、データ記憶装置に通信可能に接続されたプロセッサとを含む。プロセッサは：データアイテムを選択し、データアイテムとエンコーディングアルゴリズムとに基づいて複数のデータセグメントリクエストを決定し、複数のデータセグメントリクエストに対応する複数のサーバを決定し、複数のデータセグメントリクエストを対応する複数のサーバに送信するようにプログラムされる。

第２の実施形態では、冗長データアクセスを提供するシステムが提供される。システムは、複数のクライアントと、複数のサーバと、複数のクライアントと複数のサーバとに通信可能に接続されたコントローラとを含む。クライアントの少なくとも１つは、データアイテムをリクエストするように構成される。選択された複数のサーバの少なくともそれぞれは：データアイテムの少なくとも１つをまたはデータアイテムと関連するデータセグメントを記憶するように構成される。コントローラは：少なくとも１つクライアントからのデータアイテムリクエストに基づいてデータアイテムを選択し、データアイテムとエンコーディングアルゴリズムとに基づいて複数のデータセグメントリクエストを決定し、複数のデータセグメントリクエストに対応し複数のサーバの部分集合である複数のターゲットサーバを決定し、複数のデータセグメントリクエストを対応する複数のターゲットサーバに送信するようにプログラムされる。

第３の実施形態では、冗長データアクセスを提供するための方法が提供される。この方法は：データアイテムを選択するステップと、データアイテムとエンコーディングアルゴリズムとに基づいて複数のデータセグメントリクエストを決定するステップと、複数のデータセグメントリクエストに対応する複数のサーバを決定するステップと、複数のデータセグメントリクエストを、対応する複数のサーバに送信するステップとを含む。

第４の実施形態では、コンピュータによって実行されるとコンピュータに方法を実行させる命令を記憶するための非一時的でコンピュータ可読な記憶媒体が提供される。この方法は：データアイテムを選択するステップと、データアイテムとエンコーディングアルゴリズムとに基づいて複数のデータセグメントリクエストを決定するステップと、複数のデータセグメントリクエストに対応する複数のサーバを決定するステップと、複数のデータセグメントリクエストを、対応する複数のサーバに送信するステップとを含む。

上述した実施形態のいくつかでは、複数のデータセグメントリクエストが、複数のデータセグメントリクエストに応答して複数のサーバから受信される１組の予測されるデータセグメントがデータアイテムと比較してそのデータセグメント構成要素のサイズが小さく、１組の予測されるデータセグメントの真部分集合を用いてデータアイテムが構築され得るように構成される。

上述した実施形態のいくつかでは、エンコーディングアルゴリズムが、データアイテムを、いくつかの文字データセグメントと文字データセグメントの２つ以上と論理的に関係する１つまたは複数のデータセグメントとに分離することを含む。

上述した実施形態のいくつかでは、プロセッサが、さらに、ネットワーク経由で送られたビットパターンの推定される最適化に基づいてエンコーディングアルゴリズムを選択するようにプログラムされる、または、方法が、さらに：ネットワーク経由で送られたビットパターンの推定される最適化に基づいてエンコーディングアルゴリズムを選択するステップを含む。

上述した実施形態のいくつかでは、プロセッサが、さらに、１つまたは複数のシステム特性に基づいてエンコーディングアルゴリズムを選択するようにプログラムされる、または、方法が、さらに、１つまたは複数のシステム特性に基づいてエンコーディングアルゴリズムを選択するステップを含む。

上述した実施形態のいくつかでは、エンコーディングアルゴリズムが、１つまたは複数のシステム特性に基づくデータセグメントのサイズを備える。

上述した実施形態のいくつかでは、エンコーディングアルゴリズムが、複数のサーバの少なくとも一部に対応する複数の作業負荷に基づく。

上述した実施形態のいくつかでは、プロセッサが、さらに、エンコーディングアルゴリズムベースで複数のサーバの少なくとも１つと１つまたは複数のメッセージを交換することを選択するようにプログラムされる、または、方法が、さらに：エンコーディングアルゴリズムベースで複数のサーバの少なくとも１つと１つまたは複数のメッセージを交換することを選択するステップを含む。

上述した実施形態のいくつかでは、複数のデータセグメントリクエストが、エンコーディングアルゴリズムディレクティブを含む。

上述した実施形態のいくつかでは、プロセッサが、さらに、複数のサーバから複数のサーバ応答を受信し、デコーディングアルゴリズムに基づいて複数のサーバ応答からデータアイテムを構築するようにプログラムされる、または、方法が、さらに：複数のサーバから複数のサーバ応答を受信するステップと、デコーディングアルゴリズムに基づいて複数のサーバ応答からデータアイテムを構築するステップとを含む。ここで、複数のサーバ応答は、１組の予測されるサーバ応答全体の真部分集合である。

上述した実施形態のいくつかでは、選択された複数のサーバが、さらに：複数のデータセグメントリクエストの１つを受信し、そのデータセグメントリクエストとデータセグメントのエンコーディングアルゴリズムとに基づいてサーバ応答を決定し、サーバ応答をコントローラに送信するように構成される。

第５の実施形態では、冗長データアクセスを提供するための装置が提供される。この装置は、データ記憶装置と、データ記憶装置に通信可能に接続されたプロセッサとを含む。プロセッサは：データアイテムを選択し、データアイテムとエンコーディングアルゴリズムとに基づいて複数のデータセグメントを決定し、複数のデータセグメントリクエストに対応する少なくとも１つのサーバを決定し、対応する複数のサーバの少なくとも１つに複数のデータセグメントを送信するようにプログラムされている。

上述した実施形態のいくつかでは、プロセッサは、さらに、少なくとも１つの第２のサーバから第２の複数のデータセグメントを受信し、第２の複数のデータセグメントとデコーディングアルゴリズムとに基づいて、第２のデータアイテムを構築するようにプログラムされ、または、方法は、さらに：少なくとも１つの第２のサーバから第２の複数のデータセグメントを受信するステップと、第２の複数のデータセグメントとデコーディングアルゴリズムとに基づいて、第２のデータアイテムを構築するステップとを含む。ここで、第２の複数のデータセグメントは、第２のデータアイテムと関連する１組のデータセグメントの全体の真部分集合である。

様々な実施形態が、添付の図面に図解されており、各図面は、下記の通りである。

冗長データアクセスを提供するための冗長データアクセスシステム１００のある実施形態を図解する図である。 冗長データアクセスシステム（たとえば、図１のシステム１００）が冗長データアクセスを提供するための方法２００のある実施形態を図解する流れ図である。 コントローラ（たとえば、図１のコントローラ１４０）が図２のステップ２４０に図解されているように「Ｎ個」の決定されたサーバリクエストを送信するための方法３００のある実施形態を図解する流れ図である。 クライアントまたはコントローラ（たとえば、図１のクライアント１２０の１つまたはコントローラ１４０）が図２のステップ２８０に図解されているようにデータアイテムを再構築するための方法４００のある実施形態を図解する流れ図である。 図１のクライアント１２０の１つ、サーバ１３０の１つまたはコントローラ１４０など、様々な装置５００のある実施形態を概略的に図解する図である。

理解を容易にするため、同一の参照番号が、実質的に同じもしくは同様の構造または実質的に同じもしくは同様の機能を有する要素を示すために、用いられている。

本明細書および図面は、本発明の原理を単に例証するものである。したがって、当業者は、たとえ本明細書において明示的に説明されずまたは示されていなくても、本発明の原理を具体化し本発明の範囲内に含まれる様々な仕組みを考案できることが認識されるであろう。さらに、本明細書に記載されるすべての例は、主に、本発明の原理およびさらなる技術に対して本発明者によって貢献される概念を、読者が理解するのを支援するための教育的な目的のためのみであることが明確に意図されており、それらの例は、そのような特に記載されている例および条件には限定されないものとして、解釈されるべきである。さらには、本明細書に記載されている様々な実施形態は、いくつかの実施形態が新たな実施形態を形成するために１つまたは複数の他の実施形態と組み合わされ得るから、必ずしも相互に排他的ではない。

本明細書で用いられる場合に、「または（ｏｒ）」という用語は、（たとえば、「またはそれ以外」または「または代替的には」などのように）そうではないと示されていない限り、非排他的ＯＲを意味する。さらに、本明細書で用いられる場合に、要素の間の関係を記述するのに用いられる単語は、そうではないと示されていない限り、直接的な関係または介在する要素の存在を含むように、広く解釈されるべきである。たとえば、ある要素が別の要素に「接続されている」または「結合されている」と称されるときには、その要素は、その別の要素と直接的に接続もしくは結合されていることがあり得るし、または、介在する要素が存在していることもあり得る。対照的に、ある要素が別の要素と「直接的に接続されている」または「直接的に結合されている」と称されるときには、介在する要素は存在しない。同様に、「間に」、「隣接して」などの単語も、同様の態様で解釈されるべきである。

様々な実施形態が、冗長データアクセスを提供するための方法および装置を提供する。特に、あるデータアイテムを求めるクライアントリクエストへの応答は、対応する選択された複数のサーバのそれぞれによってクライアントに提供されるデータアイテムのデータセグメントを選択することを含む。特に、データセグメントは、データアイテムと比較するとサイズが小さく、送信されたデータセグメントの真部分集合を用いて構築され得るように、構成される。

有利なことに、送信されたデータセグメントの真部分集合を用いてデータアイテムを再構築することによって、データアイテムが失われたまたは遅延したデータセグメントを受信する前に構築され得るために、応答はロバストネスおよびレイテンシ特性を改善し得る。さらに、データセグメントがそれらのそれぞれの通信経路上を並列的に送られ得るために、全体的な送信時間が短縮され得る。

図１は、冗長データアクセスを提供するための冗長データアクセスシステム１００のある実施形態を図解している。冗長データアクセスシステム１００は、通信経路を経由して確立される通信フローを通じて、１つまたは複数のサーバ１３０−１−１３０−ｎ上に存在する１つまたは複数のデータアイテム（明瞭にする目的で図示せず）にアクセスする１つまたは複数のクライアント１２０−１−１２０−ｎ（集合的に、クライアント１２０と称する）を含む。１つまたは複数のデータアイテムの記憶または１つまたは複数のデータアイテムへのアクセスは、コントローラ１４０によって制御される。通信経路は、リンク１２５−１−１２５−ｎ（集合的に、リンク１２５と称する）の適切な１つと、ネットワーク１１０と、リンク１３５−１−１３５−ｎ（集合的に、リンク１３５と称する）の適切な１つとを含む。

本明細書で定義されるように、「データアイテム」とは：たとえばファイル、ウェブページ、データストリームまたはメッセージなどのように、クライアントとサーバとの間で送信され得る任意の適切なデータとして、広く解釈される。さらに、本明細書で定義されるように、「データセグメント」とは、通常の形式またはエンコードされた形式でデータアイテムの全部または一部を表すデータとして、広く解釈される。

ネットワーク１１０は、任意の数のアクセスノードおよびエッジノード、ネットワークデバイス、ならびに任意の数および構成のリンクを含む。さらに、ネットワーク１１０は、任意の組合せおよび任意の数の、以下を含むワイヤレスネットワークまたはワイヤラインネットワークを含み得ることが認識されるべきである：すなわち、ＬＴＥ、ＧＳＭ（登録商標）、ＣＤＭＡ、ローカルエリアネットワーク（ＬＡＮ）、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）などである。

クライアント１２０は、リンク１２５の１つまたは複数を経由してネットワーク１１０上で情報（たとえば、パケット）を送信または受信することができる任意のタイプの通信デバイスを含み得る。たとえば、通信デバイスは、シンクライアント、スマートフォン（たとえば、クライアント１２０−１）、パーソナルコンピュータまたはラップトップコンピュータ（たとえば、クライアント１１０−１）、サーバ、ネットワークデバイス、タブレット（たとえば、クライアント１２０−ｎ）、テレビ受像器のセットトップボックス、メディアプレイヤなどであり得る。通信デバイスは、処理もしくは記憶などのタスクの一部を実行するために、例示的なシステム内部の他のリソースに依存することがあり得るし、または、タスクを独立して実行できる場合もあり得る。この図には３つのクライアントが図解されているが、システム１００がより少数のまたはより多数のクライアントを含み得ることが認識されるべきである。さらに、動作の最中の様々な時刻においてクライアントがシステムに加えられ得るまたはシステムから減らされ得るのであるから、任意のある時刻におけるクライアントの数は動的であり得る。

リンク１２５および１３５は：ワイヤレス通信（たとえば、ＬＴＥ、ＧＳＭ、ＣＤＭＡ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、ＷＬＡＮ通信（たとえば、ＷｉＦｉ）、パケットネットワーク通信（たとえば、ＩＰ）、ブロードバンド通信（たとえば、ＤＯＣＳＩＳおよびＤＳＬ）、記憶装置通信（たとえば、ファイバチャネル、ｉＳＣＳＩ）など１つまたは複数の通信チャネル上の通信をサポートする。単一の接続として示されてはいるが、通信チャネル１２５および１３５は任意の数の通信チャネルまたは任意の組合せの通信チャネルであり得る、ということが理解されるべきである。

サーバ１３０は、データアイテムまたはデータセグメントを記憶し、情報（たとえば、パケット）をリンク１３５の１つもしくは複数を経由してネットワーク１１０上を送信または受信することができる任意の適切なデバイスを含み得る。

コントローラ１４０は、クライアント（たとえば、クライアント１２０−１）に提供されるデータアイテムのデータセグメントを、対応する選択された複数のサーバ１３０のそれぞれによって選択することができる任意の適切なデバイスを含み得る。特に、これらのデータセグメントは、データアイテムと比較するとサイズが小さく、送信されるデータセグメントの真部分集合を用いてデータアイテムが構築され得るように、構成されている。

本図ではただ１つのコントローラが図解されているだけであるが、システム１００はより多くのコントローラを含む場合もあり得る、ということが理解されるべきである。コントローラ１４０は、ネットワーク１１０を通じてクライアント１２０および１３０に接続されるように図解されているが、システム１００では任意の適切な構成で位置決めされ得る、ということもさらに理解されるべきである。コントローラは、別個のデバイスとして図解されているが、クライアント１２０またはサーバ１３０の１つまたは複数の内部に存在することもあり得る（たとえば、コントローラの機能が、１つまたは複数のクライアント、サーバもしくはコントローラの間に分散されることもあり得る）、ということもさらにまた理解されるべきである。

コントローラ１４０のいくつかの実施形態では、コントローラは、クライアント１２０とネットワーク１１０との間に位置決めされる。たとえば、コントローラは、エッジデバイスまたはデータセンタ内部のデバイスであり得る。これらの実施形態の１つでは、コントローラは、クライアントリクエストを受信し、クライアントリクエストに基づいていくつかのサーバデータセグメントリクエストを決定し、サーバデータセグメントリクエストのそれぞれを選択されたサーバに送信し、サーバから応答を受信して、応答しているサーバの少なくとも一部から適切なコンテンツセグメントを受信したときには、リクエストされたデータアイテムを組み立てる。

コントローラ１４０のいくつかの実施形態では、コントローラは、クライアント１２０の１つまたは複数の内部にある。

コントローラ１４０のいくつかの実施形態では、コントローラは、サーバ１３０の１つまたは複数の内部にある。

コントローラ１４０のいくつかの実施形態では、コントローラは、クライアント１２０の１つもしくは複数またはサーバ１３０の１つもしくは複数の内部に少なくとも部分的に分散されている。

いくつかの実施形態では、コントローラ１４０は、どのデータセグメントを選択されたサーバが提供するのかを識別する選択されたサーバのそれぞれに情報を送信することによって、データセグメントを提供するサーバと通信する。

図２は、冗長データアクセスシステム（たとえば、図１のシステム１００）が冗長データアクセスを提供するための方法２００のある実施形態を図解する流れ図を示す。この方法は、ステップ２０５で開始し：データアイテムをリクエストするステップ（ステップ２２０）と、データアイテムとエンコーディングアルゴリズムとに基づいて、「Ｎ個」の決定されたサーバリクエストを送信するステップ（ステップ２４０）と、受信されたサーバリクエストに応答して、「Ｍ個」のサーバ応答を送信するステップ（ステップ２６０）と、決定されたサーバリクエストに対応する受信されたサーバ応答から、データアイテムを構築するステップ（ステップ２８０）とを含み、この方法は、ステップ３９５で終了する。

方法２００では、ステップ２２０は、（たとえば、図１のクライアント１２０の１つによって）データアイテムをリクエストするステップを含む。特に、この方法を実行する装置は、データアイテム取得トリガイベントを受信し、識別されたデータアイテムを取得するためのリクエストを始動する。データアイテム取得トリガイベントとは：（ｉ）ユーザインターフェース（たとえば、クライアントデバイス上でのウェブページに対するプロンプトなど）からリクエストを受信する、（ｉｉ）ある動作を実行するのに要求されるデータアイテムを決定する（たとえば、用いるためにファイルをダウンロードするなど、データアイテムを取得するための要件を決定するアプリケーションから）、または（ｉｉｉ）同様のことなど、取得されるデータアイテムを識別する任意の適切なイベントであり得る。識別されたデータアイテムを取得するためのリクエストとは、たとえば：（ｉ）ネットワーク上でサーバまたはコントローラへのリクエストを送る（たとえば、図１のサーバ１３０またはコントローラ１４０の１つまたは複数が、図１のネットワーク１１０上で、ＨＴＴＰプロトコル経由でウェブページをリクエストする）、（ｉｉ）内部通信チャネル経由でリクエストを送る（たとえば、クライアントが、内部通信チャネル経由で、同じデータセンタまたはデバイス内部のコントローラと通信する）、または（ｉｉｉ）同様のことなど、データアイテムをソースから取得するための任意の適切な方法であり得る。

方法２００では、ステップ２４０は、データアイテムとエンコーディングアルゴリズムとに基づいて、「Ｎ個」の決定されたサーバリクエストを（たとえば、図１のコントローラ１４０によって、図１のサーバ１３０の「Ｎ個」に）送信するステップを含む。特に、リクエストされたデータアイテムを表すための１組のデータセグメントと、選択された１組のデータセグメントのそれぞれに対してそれぞれのリクエストを向けるための１組の対応するサーバとを決定するためには、あるアルゴリズムが用いられる。たとえば、４バイトである「０ｘＡ５Ｃ３」で構成されるデータアイテムは、３つのデータセグメントであるＡ、Ｂ、および

によって表され得る。ここで、Ａはデータアイテムの半分を表すデータセグメントであり（たとえば、「０ｘＡ５」）、Ｂはデータアイテムの残りの半分を表すデータセグメントであり（たとえば、「０ｘＣ３」）、データセグメント

はデータセグメントＡおよびＢのビット単位の排他的論理和（たとえば、０ｘ６６）を表す。さらに、このアルゴリズムはデータアイテムを表すために３つのデータセグメントを選択するため、「Ｎ」は３であり得るのであって、リクエストは、各データセグメントのそれぞれをリクエストしている３つの異なるサーバに送られ得る。

方法２００では、ステップ２６０は、ステップ２４０で送信されて受信されたサーバリクエストに応答して、「Ｍ個」のサーバ応答を（たとえば、図１のサーバ１３０の「Ｍ個」によって）送信するステップを含む。特に、データアイテムに対するサーバリクエストを受信するサーバの部分集合のそれぞれは、リクエストされたデータセグメントを提供することによって、応答する。データアイテムはデータセグメントの真部分集合を用いることによって構築され得るのであるから、「Ｍ」は「Ｎ」よりも小さいかまたは「Ｎ」と同一であり得る（たとえば、サーバの１つがその対応するサーバリクエストを受信しなかった場合）。

方法２００では、ステップ２８０は、ステップ２６０で受信されたサーバ応答から（たとえば、図１のコントローラ１４０によって、またはクライアント１２０の１つによって）データアイテムを構築するステップを含む。特に、この方法のステップを実行する装置は、データアイテムを構築するのに十分なデータセグメントの真部分集合を受信すると、データアイテムを構築する。たとえば、上述した例を用いると、この装置は、集合

の任意の２つのデータセグメントを受信した後で、データアイテムを構築し得る。

ステップ２６０のいくつかの実施形態では、サーバ（たとえば、図１のサーバ１３０）の１つまたは複数が、データアイテムと、データアイテムに関係する１つまたは複数のデータセグメントとを記憶する。

ステップ２６０のいくつかの実施形態では、１つまたは複数のサーバが、データアイテムだけを記憶する。そして、この１つまたは複数のサーバは、サーバリクエストを受信すると、リクエストされたデータセグメントを決定し得る、ということが理解されるべきである。これらの実施形態のいくつかでは、サーバは、次に、同じデータセグメントを求める将来のリクエストに関する処理コストを減少させるために、リクエストを処理した後で、データセグメントを記憶することがあり得る。さらなる実施形態では、データセグメントの記憶は、利用可能な記憶装置がある閾値を下回る場合や、または、直近のリクエスト以後の時間経過などのイベントがあると、消去されることがあり得る。

図３は、コントローラ（たとえば、図１のコントローラ１４０）が図２のステップ２４０に図解されているように「Ｎ個」の決定されたサーバリクエストを送信するための方法３００のある実施形態を図解する流れ図を示す。この方法は、ステップ３０５で開始し：データアイテムを選択するステップ（ステップ３１０）と、データアイテムとエンコーディングアルゴリズムとに基づいて「Ｎ個」のデータセグメントリクエストを決定するステップ（ステップ３２０）と、「Ｎ個」のデータセグメントに対応する「Ｎ個」のサーバを決定するステップ（ステップ３４０）と、データセグメントリクエストが送信されるべきだと決定される（ステップ３６０）の間に、選択された「Ｎ個」のデータセグメントリクエストのそれぞれを対応するサーバに送信するステップ（ステップ３８０）とを含む。この方法は、ステップ３９５で終了する。

方法３００では、ステップ３１０は、データアイテムを選択するステップを含む。データアイテムの選択は、たとえば：（ｉ）データアイテムを特定するリクエストをクライアント（たとえば、図１のクライアント１２０−１）から受信するステップ、（ｉｉ）ユーザインターフェース（たとえば、クライアントデバイス上などの）からリクエストを受信するステップ、（ｉｉｉ）動作を実行するのに要求される（たとえば、データアイテムを取得するための要件を決定するアプリケーションから）データアイテムを決定するステップ、または（ｉｖ）同様のステップなど、任意の適切な方法を含み得る。

方法３００では、ステップ３２０は、データアイテムとエンコーディングアルゴリズムとに基づいて「Ｎ個」のデータセグメントリクエストを決定するステップを含む。特に、その１組の「Ｎ個」のデータセグメントリクエストは、それらのデータセグメントリクエストの結果として生じる１組のデータセグメントが、データアイテムと比較してサイズが小さい１組のデータセグメントを提供するように決定され、データセグメントの真部分集合を用いてデータアイテムが構築され得るように構成される。

方法３００では、ステップ３４０は、「Ｎ個」のデータセグメントリクエストと対応する「Ｎ個」のサーバを決定するステップを含む。特に、サーバは、「Ｎ個」のデータセグメントセグメントリクエストのそれぞれに対する対応するデータセグメントで応答するように、選択される。サーバは：（ｉ）ランダムな選択、（ｉｉ）ラウンドロビン式の選択、（ｉｉｉ）サービス計量（たとえば、レイテンシ）の質を用いて、（ｉｖ）コスト計量を用いて、（ｖ）経路またはリソースの多様性の考慮を用いて（たとえば、輻輳もしくは故障したリンクまたはコンポーネントにおいて複数のデータセグメントが失われてしまうリスクを最小化するために）、または（ｖｉ）同様のステップ、などを含む任意の適切な方法に基づいて、選択され得る。１つのサーバが複数のデータセグメントを供給するように選択されることもあり得る、ということが理解されるべきである。

方法３００では、ステップ３６０は、送信すべき何らかのデータセグメントリクエストが存在するかどうかを決定するステップを含む。この方法を実行する装置が、送信すべきデータセグメントリクエストを有する場合には、この方法はステップ３８０に進むが、それ以外の場合には、この方法はステップ３９５で終了する。この決定は：（ｉ）データセグメントリクエストのすべてが送信されたと決定するステップ、（ｉｉ）データアイテムを構築するために十分なデータセグメントが受信されたと決定するステップ、または（ｉｉｉ）同様のステップ、などの任意の適切な方法を含み得る。

方法３００では、ステップ３８０は、ステップ３２０で決定されたデータセグメントリクエストを、ステップ３４０で決定された対応するサーバに、従来型の送信技術を用いて送信するステップを含む。

ステップ３２０のいくつかの実施形態では、決定は、データアイテムに関する情報を取得するステップを含む。データアイテムに関する情報は、（ｉ）データアイテムをホストしているサーバとのメッセージの交換、（ｉｉ）データアイテムに対して責任を有する管理システムとのメッセージの交換、または（ｉｉｉ）同様のステップ、などの任意の適切な方法によって取得され得る。

ステップ３２０のいくつかの実施形態では、決定は、システムに関する情報を取得するステップを含む。システムに関する情報は：（ｉ）ネットワークにおける通信経路のレイテンシなどの、サービスパラメータの質、（ｉｉ）システムコンポーネントの記憶装置コスト、ネットワークコスト、もしくは処理コストなどのコストパラメータ、（ｉｉｉ）送信プロトコルなどの送信パラメータ、または（ｉｖ）同様のもの、などの任意の適切な情報であり得る。

ステップ３２０のいくつかの実施形態では、エンコーディングアルゴリズムは、データアイテムを、いくつかの文字データセグメントと、それらの文字データセグメントの２つ以上に論理的に関係する１つまたは複数のデータセグメントとに分離することを含む。これらの実施形態のいくつかでは、データアイテムは、「Ｘ個」の文字データセグメントと「Ｙ個」の論理的に関係するデータセグメントとに分割される。これらの実施形態のいくつかでは、Ｘ＝２でありＹ＝１である。いくつかの他の実施形態では、Ｘ＝３でありＹ＝２である。論理的に関係するデータセグメントは、文字データセグメントから：（ｉ）文字データセグメントの加算もしくは減算などのバイト単位の演算、（ｉｉ）文字データセグメントの減算もしくは排他的論理和などのビット単位の演算、または（ｉｉｉ）同様の演算などの、任意の適切なアルゴリズムを用いて、決定され得る。

ステップ３２０のいくつかの実施形態では、エンコーディングアルゴリズムは、ネットワーク経由で送られたビットパターンの推定された最適化に基づいて、エンコーディングアルゴリズムを選択することを含む。たとえば、ほとんど０であるビットを送るのが有利である場合には、いくつかのエンコーディングアルゴリズムの間で比較が行われ得るのであって、結果として得られるパターンにおいて０のパーセンテージがより高いビットを計算することになるアルゴリズムを選択する。

ステップ３２０のいくつかの実施形態では、エンコーディングアルゴリズムは、送信単位特性などの１つまたは複数のシステム特性に基づいてエンコーディングアルゴリズムを選択することを含む。これらの実施形態のいくつかでは、データセグメントのサイズは、ネットワーク上でパケットがフラグメント化するオーバヘッドを減少させるために、システムパラメータに基づくことがあり得る。たとえば、いくつかのイーサネット（登録商標）ネットワークは、１５００バイトの標準的ＭＴＵ（最大送信単位）を用いる。５０００バイトのコンテンツをそれぞれが１５００バイトの４つのデータセグメントとしてエンコードすることによって、同じ量の４つのデータセグメントが送られ（５０００／１５００を切り上げ）、帯域幅のオーバヘッドが軽減される。別の例として、いくつかのルータのスイッチングファブリックは、一定の最適なセルサイズ（たとえば、１２８バイト）に対して設計されている。そのようなセルサイズの整数倍にエンコードすることによって、ネットワーク経由でのルータにおける転送オーバヘッドが縮小され得る。第３の例として、記憶装置（たとえば、ディスクドライブ）が、記憶のために一定のブロックサイズ（たとえば、４０９６バイト）を用いることがあり得るが、そのようなブロックサイズに対してエンコードすることによって、それらのディスクのための読み出し効率が改善され得る。同様にして、クライアントのキャッシュサイズとネットワーク要素の中間バッファサイズとは、データセグメントのサイズを決定するための基礎となり得る。

ステップ３２０のいくつかの実施形態において、エンコーディングアルゴリズムは、サーバの作業負荷に基づいてエンコーディングアルゴリズムを選択することを含む。
これらの実施形態のいくつかでは、選択は、コストに基づくサーバの選択に基づく。たとえば、より安価なＣＰＵ、記憶装置、またはネットワーク帯域幅を備えたサーバが選択されることがあり得る。この例において、選択されたサーバ構成が１Ｇｂｐｓでデータを配信することが可能であり、与えられているアプリケーションが５秒以内に配信されなければならない１０Ｇｂの大きなファイルを用いる場合には、データアイテムが３つのデータセグメントにエンコードされ、データアイテムを再構築するためにはその中の２つが必要とされるように、エンコーディングアルゴリズムは選択され得る。２つの応答するサーバは、すると、与えられたサービス品質デッドラインを満足し得る（すなわち、サーバ当たり配信される５Ｇｂ／１Ｇｂｐｓのサーバ配信速度＝５秒）、ということが理解されるべきである。

ステップ３２０のいくつかの実施形態では、データセグメントリクエストは、データアイテム識別子（たとえば、ＵＲＬまたはファイル名などのデータアイテムを識別する名称）だけを含む。これらの実施形態のいくつかでは、サーバは、データアイテムの１つのデータセグメントだけを記憶するように、構成される。たとえば、サーバがデータアイテムの「Ｂ」データセグメントだけを記憶する｛ｈｔｔｐ：／／ｗｗｗ．ａｌｃａｔｅｌ−ｌｕｃｅｎｔ．ｃｏｍ／｝を取得するというデータセグメントリクエストは、サーバに「Ｂ」データセグメントをリクエストする。

ステップ３２０のいくつかの実施形態では、データセグメントリクエストは、データアイテム識別子（たとえば、ＵＲＬまたはファイル名などのデータアイテムを識別する名称）と、エンコーディングアルゴリズムディレクティブとを含む。エンコーディングアルゴリズムディレクティブとは、特定のデータセグメントを提供するためにはデータアイテムをどのようにエンコードすべきかに関する情報をサーバに提供する任意の適切なディレクティブであり得る。いくつかの実施形態では、エンコーディングアルゴリズムディレクティブは、知られているデータセグメントのインデクスであり得る。たとえば、｛Ａ，Ｂ，Ａ＋Ｂ｝を用いるエンコーディングアルゴリズムが設定されている｛ｈｔｔｐ：／／ｗｗｗ．ａｌｃａｔｅｌ−ｌｕｃｅｎｔ．ｃｏｍ／，“２”｝を取得するというデータセグメントリクエストは、サーバが、データアイテムの「Ｂ」データセグメントを返すことを特定する。いくつかの他の実施形態では、エンコーディングアルゴリズムディレクティブは、｛Ｎ／２（１），Ｎ／２（２），Ｎ／２（１＋２）｝などのデータセグメントエンコーディングアルゴリズムのテーブルへのインデクスであり得るが、ここで、「２」の選択は、データアイテムの上述した「Ｂ」データセグメントエンコーディングと等しいことがあり得るＮ／２（２）のデータセグメントアルゴリズムを特定する。ステップ３２０のいくつかの実施形態では、エンコーディングアルゴリズムディレクティブは、サーバがデータセグメントを決定するためのエンコーディングアルゴリズムを特定する。たとえば、｛ｈｔｔｐ：／／ｗｗｗ．ａｌｃａｔｅｌ−ｌｕｃｅｎｔ．ｃｏｍ／，“Ｎ／２（１＋２）”｝を取得するというデータセグメントリクエストは、サーバが、データアイテムの第１の半分と第２の半分とのバイト単位での加算を返すことを特定し得る。データアイテムに対して適用される特定のデータセグメントエンコーディングアルゴリズムを特定するためには、任意の適切なプロトコルが用いられ得るということが理解されるべきである。

ステップ３２０のいくつかの実施形態では、データセグメントリクエストは、反復的ブロックベースでデータアイテムをエンコードするためのディレクティブを含む。特に、エンコーディングアルゴリズムは、データアイテム全体ではなくデータアイテムの一部に対して適用される。たとえば、２Ｍバイトであるデータアイテム（たとえば、ビデオ）に対しては、｛Ａ，Ｂ，Ａ＋Ｂ｝というエンコーディングアルゴリズムが、１０００バイトごとに適用され得る。有利であることに、ストリーミングデータアイテムが、反復ベースでデータアイテムをエンコードすることによって、レイテンシとロバストネスとの改善を実現し得る。

ステップ３６０および３８０のいくつかの実施形態では、データセグメントリクエストが、並列的に送信される。

ステップ３６０および３８０のいくつかの実施形態では、１つまたは複数のデータセグメントリクエストが再送される。これらの実施形態のいくつかでは、データセグメントリクエストが、別のサーバに再送される（すなわち、この方法を実行する装置は、再送されたデータセグメントリクエストに対応する少なくとも１つのサーバを決定するために、ステップ３４０に戻る）。これらの実施形態のいくつかでは、再送されたデータセグメントリクエストは、先行する成功裏になされたサーバ応答がそこから受信されたサーバに送られる。有利であることに、失敗したリクエストを、そこからの応答が成功裏に受信されたサーバに再度試みることは、パフォーマンスを向上させる場合があり得る。

さらなる実施形態では、再送されるデータセグメントリクエストは、データセグメントリクエストの１つが失敗したリクエストであるという決定に基づく。これらの実施形態のいくつかでは、データセグメントリクエストの再度の試みは、第１の成功裏になされたサーバ応答の受信と関連する時間閾値を超えることに基づく。あるそのような実施形態では、タイムスタンプＴ１が、データセグメントリクエストを送信した時に決定される（たとえば、ステップ３６０の開始、または、ステップ３８０における第１のもしくは最後のデータセグメントリクエストを送信した時）。第２のタイムスタンプＴ２は、任意のサーバからの第１のサーバ応答を完全に受信した後に、決定される。データセグメントリクエストの再度の試みは、よって、Ｔ１＋１５０％＊（Ｔ２−Ｔ１）：というアルゴリズムに基づく期間の後に１つまたは複数のサーバ応答が受信されていないという決定に基づく。

送信プロトコルがＨＴＴＰである１つまたは複数のデータセグメントリクエストを再送するいくつかの実施形態においては、既存のＴＣＰ接続が再度用いられる。

１つまたは複数のデータセグメントリクエストを再送するいくつかの実施形態では、コントローラは、データセグメントが異なる順序で送信されるサーバ応答を受信するように構成されている。これらの実施形態のいくつかでは、この順序は逆順である。たとえば、Ｎバイトのデータセグメントについては、そのバイトの再送されるデータセグメントリクエストの送信は、逆の順序（すなわち、バイトＮ−１から開始する）である。有利であることに、別のサーバからの部分的に受信された応答は、より迅速に構築され得る（たとえば、後述されるステップ４６０で説明されるように）。

図４は、クライアントまたはコントローラ（たとえば、図１のクライアント１２０の１つまたはコントローラ１４０）が図２のステップ２８０に図解されているようにデータアイテムを再構築するための方法４００の実施形態を図解する流れ図を示している。この方法は：先に送信された「Ｎ個」のサーバリクエストの１つに対応するサーバ応答を受信するステップ（ステップ４２０）と、データアイテムが受信されたサーバ応答から構築され得ると決定される場合には、決定されたデコーディングアルゴリズムに基づいて、受信されたサーバ応答からデータアイテムを構築するステップ（ステップ４６０）と、そうでない場合には、別のサーバ応答を受信するためにステップ４２０に戻るステップ（ステップ４４０）とを含む。この方法は、ステップ４９５で終了する。

方法４００では、ステップ４２０は、先に送信された（たとえば、図３のステップ３８０）「Ｎ個」のサーバリクエストの１つに対応するサーバ応答を受信するステップを含む。特に、サーバ応答は、対応するサーバリクエストにおいて特定されたデータセグメントを含む。

方法４００では、ステップ４４０は、受信されたサーバ応答からデータアイテムが構築され得るかどうかを決定するステップを含む。データアイテムが構築され得る場合には、この方法はステップ４６０に進み、そうでない場合には、この方法はステップ４２０に進む。この決定は、また、ステップ４９５に進むタイムアウトルーチンまたはエラールーチンも含み得ることが理解されるべきである。

方法４００では、ステップ４６０は、決定されたデコーディングアルゴリズムに基づいて、受信されたサーバ応答からデータアイテムを構築するステップを含む。特に、デコーディングアルゴリズムは、エンコーディングアルゴリズムとステップ４２０で受信されたデータセグメントとに基づく。たとえば、｛Ａ，Ｂ，Ａ＋Ｂ｝のエンコーディングアルゴリズムを用いると、２つのデータセグメントの任意の組合せ（｛Ａ，Ｂ｝，｛Ａ，Ａ＋Ｂ｝または｛Ｂ，Ａ＋Ｂ｝）は、リクエストされたデータアイテムを再構築するのに十分である。特に、｛Ａ，Ｂ｝は２つのデータセグメントの単純な連結であり、Ｂ＝（Ａ＋Ｂ）−（Ａ）であることを観察することによって、すなわち、２つの受信されたブロックのバイト単位での減算を行うことによって、｛Ａ，Ａ＋Ｂ｝が構築され得る。同様に、Ａ＝（Ａ＋Ｂ）−（Ｂ）であることを観察することによって、｛Ｂ，Ａ＋Ｂ｝が構築され得る。

図３および４を参照すると、エンコーディングアルゴリズムがＸ＝２の文字データセグメントとＹ＝１の論理的に関係するデータセグメントとを含む第１の例では、１０００個のＡＳＣＩＩキャラクタで構成されるＨＴＭＬウェブページは、それぞれが５００バイトの３つのデータセグメントとして、エンコードされ得る。ここで、Ａは第１の５００バイトであり、Ｂは第２の５００バイトであり、ＣはデータセグメントＡおよびＢのバイト単位での加算（たとえば、Ａ＋Ｂ）である。この例では、任意の２つのリクエストが受信されると直ちに、コントローラは、ページをレンダリングするために３つの異なるサーバにデータセグメントＡ、ＢおよびＡ＋Ｂをリクエストし得る。有利であることに、この方式は、記憶装置の５０％増加を要求する可能性があるが、リクエストの１／３が失敗または遅延することを許容しながら、２／１のファクタで送信レイテンシを潜在的に改善させることが可能である。

エンコーディングアルゴリズムがＸ＝３の文字データセグメントとＹ＝２の論理的に関係するデータセグメントとを含む第２の例では、１２００個のＡＳＣＩＩキャラクタで構成されるＨＴＭＬウェブページは：｛Ａ，Ｂ，Ｃ，Ａ＋Ｂ−Ｃ，Ａ−Ｂ＋Ｃ｝などのそれぞれが４００バイトの５つのデータセグメントとして、エンコードされ得る。ここで、Ａは第１の４００バイトであり、Ｂは第２の４００バイトであり、Ｃは最後の４００バイトであり、Ａ＋Ｂ−ＣとＡ−Ｂ＋ＣとはデータセグメントＡ、ＢおよびＣのバイト単位での操作である。この例では、任意の３つのリクエストが受信されると直ちに、コントローラは、ページをレンダリングするために５つの異なるサーバにデータセグメントＡ，Ｂ，Ｃ，Ａ＋Ｂ−ＣおよびＡ−Ｂ＋Ｃをリクエストし得る。３つのデータセグメントの任意の組合せが元のページを再構築するのに十分であることが観察され得る。有利であることに、この方式は、記憶装置の６７％増加を要求する可能性があるが、リクエストの２／５が失敗または遅延することを許容しながら、３／１のファクタで送信レイテンシを潜在的に改善させることが可能である。

主に特定のシーケンスとして示され説明されているが、方法３００、４００または５００に示されているステップは、任意の適切なシーケンスで実行され得るということが理解されるべきである。さらに、１つのステップによって識別されたステップが、そのシーケンスにおいて１つまたは複数の他のステップでも実行され得るし、または、複数のステップの共通の動作が一度だけ実行されることもあり得る。

主にデータアイテムはデータ記憶装置である場合が示されているが、いくつかの実施形態では、データアイテムはデバイス間で送られるメッセージでもあり得ることが認識されるべきである。たとえば、１つのそのような実施形態では、メッセージ（たとえば、リクエスト）はいくつかのセグメント（たとえば、

を用いてエンコードされた３つのセグメントなど）としてエンコードされ、サーバに送られる。データアイテムがデータ記憶装置であるような実施形態と同様に、そのようなエンコーディングは、有利であることに、パケットが、異なる複数の経路に沿ってルーティングされるときに、３３％のパケット損失を許容し、遅延変動を減少させ得る。これらの実施形態のいくつかでは、メッセージは、モバイルハンドセットと基地との間をワイヤレスネットワーク経由で送信される。

様々な上述された方法のステップはプログラムされたコンピュータによって行われ得るということが認識されるべきである。本明細書では、いくつかの実施形態は、また、プログラム記憶装置、たとえば、データ記憶媒体に及ぶことが意図されているが、これらは、マシン可読もしくはコンピュータ可読であり、マシン実行可能な、もしくはコンピュータ実行可能なプログラムの命令をエンコードし、ここで、前記命令は、前記上述された方法のステップのうちのいくつか、または全部を行う。プログラム記憶装置は、たとえば、デジタルメモリ、磁気ディスクおよび磁気テープなどの磁気記憶媒体、ハードドライブ、または光学的に可読なデータ記憶媒体でもあり得る。実施形態は、また、上述された方法の前記ステップを実行するようにプログラムされたコンピュータに及ぶことが、意図されている。

図５は、図１のクライアント１２０の１つ、サーバ１３０の１つまたはコントローラ１４０など、様々な装置５００のある実施形態を概略的に図解している。装置５００は、プロセッサ５１０と、データ記憶装置５１１と、オプションであるがＩ／Ｏインターフェース５３０とを含む。

プロセッサ５１０は、装置５００の動作を制御する。プロセッサ５１０は、データ記憶装置５１１と協働する。

データ記憶装置５１１は、プロセッサ５１０によって実行可能なプログラム５２０を記憶する。データ記憶装置５１１は、また、オプションであるが、データアイテム、エンコーディングアルゴリズムまたは同様のものなどのプログラムデータも、必要に応じて記憶することがあり得る。

プロセッサ実行可能なプログラム５２０は、Ｉ／Ｏインターフェースプログラム５２１、データアイテムリクエストプログラム５２３、データアイテム受信プログラム５２５またはサーバプログラム５２７を含み得る。プロセッサ５１０は、プロセッサ実行可能なプログラム５２０と協働する。

Ｉ／Ｏインターフェース５３０は、必要に応じて、上述されたように、図１のリンク１２５または１３５を経由しての通信をサポートするために、プロセッサ５１０およびＩ／Ｏインターフェースプログラム５２１と協働する。Ｉ／Ｏインターフェースプログラム５２１は、図２のステップ２４０もしくは２６０、図３のステップ３１０もしくは３８０、または図４のステップ４２０の１つまたは複数を、上述されたように、必要に応じて実行する。

データアイテムリクエストプログラム５２３は、図２のステップ２２０もしくは２４０、または図３の方法３００のステップの１つまたは複数を、上述されたように、必要に応じて実行する。

データアイテム受信プログラム５２５は、図２のステップ２８０または図３の方法４００のステップの１つまたは複数を、上述されたように、必要に応じて実行する。

サーバプログラム５２７は、図２のステップ２６０の１つまたは複数を、上述されたように、必要に応じて実行する。

いくつかの実施形態において、プロセッサ５１０は、プロセッサ／ＣＰＵコアなどのリソースを含むことがあり得るし、Ｉ／Ｏインターフェース５３０は、任意の適切なネットワークインターフェースを含むことがあり得るし、または、データ記憶装置５１１は、メモリもしくは記憶装置を含むことがあり得る。さらに、装置５００は、以下のような、任意の適切な物理ハードウェア構成であり得る：すなわち、１つまたは複数のサーバと、プロセッサ、メモリ、ネットワークインターフェース、または記憶装置などのコンポーネントから構成されるブレードとである。これらの実施形態のいくつかでは、装置５００は、相互にリモートであるクラウドネットワークリソースを含むことがあり得る。

いくつかの実施形態では、装置５００が、１つまたは複数の仮想マシンである場合があり得る。これらの実施形態のいくつかにおいて、仮想マシンの１つまたは複数が、異なるマシンからのコンポーネントを含むことがあり得るし、または、地理的に分散されていることもあり得る。たとえば、データ記憶装置５１１とプロセッサ５１０とが、２つの異なる物理マシンに存在することがあり得る。

プロセッサ実行可能なプログラム５２０がプロセッサ５１０上で実装されるときには、プログラムコードセグメントが、特定の論理回路に類似して動作する独自のデバイスを提供するために、プロセッサと組み合わされる。

本明細書では、たとえば、プログラムとロジックとがデータ記憶装置に記憶されており、メモリがプロセッサと通信可能に接続された実施形態に関して示され説明されているが、そのような情報は、任意の他の適切な態様で（たとえば、任意の適切な個数のメモリ、記憶装置もしくはデータベースを用いて）、任意の適切な配置のデバイスに通信可能に接続された任意の適切な配置のメモリ、記憶装置もしくはデータベースを用いて、メモリ、記憶装置もしくは内部データベースもしくは外部データベースの任意の適切な組合せに情報を記憶して、または、任意の適切な個数のアクセス可能な外部メモリ、記憶装置、もしくはデータベースを用いて、記憶されることがあり得るということが、認識されるべきである。したがって、本明細書で言及されるデータ記憶装置という用語は、メモリ、記憶装置、およびデータベースのすべての適切な組合せに及ぶことが意図されている。

本明細書および図面は、本発明の原理を例証するにすぎない。したがって、たとえ本明細書において明示的に説明されていないまたは示されていなくとも、当業者は、本発明の原理を具体化しその精神および範囲に含まれる様々な仕組みを考案できる、ということが認識されるであろう。さらに、本明細書に記載されているすべての例は、主に、読者が本発明の原理と、技術を推し進めるために本発明者によって貢献がなされた概念とを理解するのを支援するための教育的目的だけを有することが明確に意図されており、これらの例は、そのような特に記載された例および条件には限定されないと解釈されるべきである。さらに、本明細書における本発明の原理、態様、および実施形態を記載しているすべての記述、ならびにその特定の例を記載しているすべての記述は、本発明の均等物にも及ぶことが意図されている。

「プロセッサ」とラベル付けされた任意の機能ブロックを含めて、図に示された様々な要素の機能は、適切なソフトウェアとの関連でソフトウェアを実行することができるハードウェアだけではなく、専用ハードウェアを用いることにより、提供され得る。プロセッサによって提供されるとき、それらの機能は、単一の専用プロセッサにより、単一の共用プロセッサにより、または、そのうちのいくつかが共用され得る複数の個別的なプロセッサによって、提供され得る。さらに、「プロセッサ」または「コントローラ」という用語の明示的な使用は、ソフトウェアを実行することができるハードウェアを排他的に指すものとして解釈されるべきでなく、これらに限定されることはないが、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、ネットワークプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するためのリードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、および不揮発性記憶装置を、黙示的に含み得る。従来型のまたはカスタムの、他のハードウェアが含まれることもあり得る。同様に、図に示された任意のスイッチは、概念的なものにすぎない。それらの機能は、プログラムロジックの演算によって、専用ロジックによって、プログラム制御と専用ロジックの相互作用によって、または手動によっても実行され得るのであって、特定の技術が、コンテキストからより具体的に理解されるように、実装者によって選択可能である。

本明細書における任意のブロック図は本発明の原理を具体化する例証のための回路の概念図を表現している、ということが認識されるべきである。同様に、任意の流れ図、フローダイアグラム、状態遷移図、擬似コード、その他は、コンピュータまたはプロセッサが明示的に示されている場合でもそうでない場合でも、コンピュータ可読媒体において実質的に表現され得るのであって、コンピュータまたはプロセッサによってそのように実行され得る様々なプロセスを表現していることが認識されるべきである。

Claims (10)

1. 冗長データアクセスを提供するための装置であって、
   データ記憶装置と、
   データ記憶装置に通信可能に接続されたプロセッサであって、
   データアイテムを選択し、
   データアイテムとエンコーディングアルゴリズムとに基づいて複数のデータセグメントリクエストを決定し、
   複数のデータセグメントリクエストに対応する複数のサーバを決定し、
   複数のデータセグメントリクエストを対応する複数のサーバに送信する
   ように構成されたプロセッサと、
   を備える、装置。
2. 複数のデータセグメントリクエストが、複数のデータセグメントリクエストに応答して複数のサーバから受信される１組の予測されるデータセグメントがデータアイテムと比較してそのデータセグメント構成要素のサイズが小さく、１組の予測されるデータセグメントの真部分集合を用いてデータアイテムが構築され得るように構成される、請求項１に記載の装置。
3. エンコーディングアルゴリズムが、データアイテムを、いくつかの文字データセグメントと文字データセグメントの２つ以上と論理的に関係する１つまたは複数のデータセグメントとに分離することを含む、請求項１に記載の装置。
4. プロセッサが、さらに、ネットワーク経由で送られたビットパターンの推定される最適化に基づいてエンコーディングアルゴリズムを選択するように構成される、請求項１に記載の装置。
5. 複数のデータセグメントリクエストがエンコーディングアルゴリズムディレクティブを含む、請求項１に記載の装置。
6. プロセッサが、さらに、
   複数のサーバから複数のサーバ応答を受信し、
   複数のサーバ応答から、デコーディングアルゴリズムに基づいてデータアイテムを構築する
   ように構成されており、
   複数のサーバ応答が、１組の予測されるサーバ応答全体の真部分集合である、請求項１に記載の装置。
7. 冗長データアクセスを提供するための方法であって、
   データ記憶装置と通信可能に接続されたプロセッサにおいて、データアイテムを選択するステップと、
   データ記憶装置と協働するプロセッサにより、データアイテムとエンコーディングアルゴリズムとに基づいて複数のデータセグメントリクエストを決定するステップと、
   データ記憶装置と協働するプロセッサにより、複数のデータセグメントリクエストと対応する複数のサーバを決定するステップと、
   データ記憶装置と協働するプロセッサにより、複数のデータセグメントリクエストを対応する複数のサーバに送信するステップと、
   を含む、方法。
8. 複数のデータセグメントリクエストが、複数のデータセグメントリクエストに応答して複数のサーバから受信される１組の予測されるデータセグメントがデータアイテムと比較してそのデータセグメント構成要素のサイズが小さく、１組の予測されるデータセグメントの真部分集合を用いてデータアイテムが構築され得るように構成される、請求項７に記載の方法。
9. エンコーディングアルゴリズムが、データアイテムを、いくつかの文字データセグメントと文字データセグメントの２つ以上と論理的に関係する１つまたは複数のデータセグメントとに分離することを含む、請求項７に記載の方法。
10. 複数のサーバから複数のサーバ応答を受信するステップと、
    複数のサーバ応答から、デコーディングアルゴリズムに基づいてデータアイテムを構築するステップと、
    をさらに含んでおり、
    複数のサーバ応答が、１組の予測されるサーバ応答全体の真部分集合である、請求項７に記載の方法。

Images