JP2006197601A - ネットワークにおけるデータ伝送に対しプライオリティを割り当てる方法および該方法を使用したネットワーク - Google Patents

Abstract

【課題】ネットワークにおけるデータ伝送に対するプライオリティの割り当てにあたり、コンフリクトやボトルネックなどのマネージメントを自動的に行うようにし、しかも自動的に得られた結果に対しユーザまたはアプリケーション手段が変更を加えることができるようにする。
【解決手段】特定のデータユニットに対しリクエストを送出する第１のノードと、このリクエストを受け取って分析する第２のノードが設けられており、このノードは、要求されたデータユニットを自身が提供できることを検出し、要求されたデータユニットを提供できることを表すメッセージを第１のノードへ送信する。第１のノードはメッセージを受信して選択し、第２のノードへ第２のリクエストを送信して、特定のデータユニットの伝送を要求する。第２のノードはこの第２のリクエストの受信に応じて特定のデータユニットを伝送する。
【選択図】図１

Description

本発明は全般的にいえばネットワーク通信に関する。詳しくは本発明は、ネットワークにおけるデータ伝送に対しプライオリティすなわち優先度を割り当てる方法および該方法を使用したネットワークに関する。

たとえば分散型ストレージシステム（Distributed Storage Systems DSS）などのようなネットワークの場合、データ伝送とは実行すべきタスクと捉えることができる。データ伝送はしばしばリクエストまたはタスクに応答する。この場合、タスクをたとえばサーチタスクあるいはデータ伝送タスクとすることができ、これにはタスクに関与する各ノード間で行われる特有のメッセージフローが伴う。通常、複数の（データ伝送）タスクを同時に並行して実行させることができる。その結果、帯域幅、記憶スペースあるいは他のパラメータに関するキャパシティの制限に起因して、コンフリクトあるいはボトルネックといった状況が引き起こされる可能性がある。

たとえばヨーロッパ特許出願EP 1 427 141に記載されているOwnerZoneのようなピア・ツー・ピアベースのネットワークにおける種々のノードは、記憶スペースあるいは伝送レートといった他のノードのリソースの割り当てを試行することができる。利用可能なりソースがすべてのリクエストのマネージメントに不十分であるならば、この種のボトルネックまたはコンフリクトを回避するための効果的なやり方を見つけることができる。これは自動的に、つまりユーザの介入なく行われることになる。ただしいくつかの事例では、自動的に見つけ出されたソリューションの変更をユーザまたはアプリケーションが行えるとよい。コンフリクトおよびボトルネックのマネージメントにおいては、複数の制御メッセージに基づく各ノード間の通信が伴う。これらの制御メッセージを言語の一部とすることもでき、たとえば分散型ストレージ通信および制御の言語の一部とすることもできる。

発明の概要
本発明によれば、コンフリクトやボトルネックなどのマネージメントを自動的に行うことができ、しかも自動的に得られた結果に対しユーザまたはアプリケーション手段が変更を加えることができる。この場合、二重レイヤのプライオリティシステムの定義をベースとしており、これには暗黙的プライオリティと呼ばれる第１レイヤと明示的プライオリティと呼ばれる第２レイヤが含まれており、この場合、暗黙的プライオリティは一般に明示的プライオリティよりも高い。したがって明示的プライオリティのレイヤは、複数のタスクにおいて同一の暗黙的なプライオリティである場合のみ用いられる。これら２つのレイヤの各々を、さらに複数の種々のレベルに分割することができる。

有利には、本発明はネットワークにおいて通信にかかる手間がごく僅かで済む。さらに本発明によれば、ネットワーク内のデータスループット、記憶容量ならびにデータのアベイラビリティの向上を実現できる。

本発明によれば、記憶スペース、伝送レート、ノードアベイラビリティ等に関するコンフリクトおよびボトルネックが、プライオリティのセットおよびネットワーク内のノードにより適用されたルールを用いてマネージメントされ、あるいは回避される。この場合、ルールはノードに固有であるのに対し、プライオリティは二重のレイヤのプライオリティとして２つのステップで計算される。第１レイヤはいわゆる暗黙的プライオリティであって、これは関与するすべてのノードが従うルールまたは関係について定義されたものである。第２レイヤのプロパティはいわゆる明示的プライオリティであって、これはユーザまたはアプリケーションにより定義されたものである。

２段階のプライオリティによるコンセプトのもつ利点は、これによってタスク固有のプライオリティおよび／またはノード固有のプライオリティが使われることであり、ここではこれを「暗黙的プライオリティ」と称し、ユーザまたはアプリケーションによって定義する必要がなく、他方、付加的な明示的プライオリティには、ユーザまたはアプリケーションによって交換可能および変更可能な情報としてプライオリティレベルを割り当てることが含まれる。換言すれば、暗黙的プライオリティはユーザ入力なしで自動的に生成可能である。ユーザあるいはアプリケーションは、適切であるとみなせば暗黙的プライオリティの割り当てまたは変更を実行することができる。

本発明の利点は、たとえばオーナーゾーン OwnerZoneとして実装されたＤＳＳなどにおけるコンフリクトおよびボトルネックを適切にマネージメントまたは回避できることであり、これによりデータスループットが改善され、さらによいのは記憶容量の活用ならびにデータアベイラビリティの向上ならびにネットワークブロックの回避が行われることである。

本発明による方法はネットワークにおけるデータ伝送に対しプライオリティを割り当てる方法である。これによればデータ伝送において、特定のデータユニットまたは特定のタイプのデータユニットを表す第１のリクエストを送出する第１のノードと、この第１のリクエストを受信し分析する少なくとも１つの第２ノードが設けられており、第２のノードは、要求されたデータユニットを自身が提供できることを検出して第１のノードに対し、要求されたデータユニットを自身が提供できることを表す第１のメッセージを送信する。第１のノードはこの第１のメッセージを受信して選択し、第２のノードに対し第２のリクエストを送信して特定のデータユニットの伝送を要求し、第２のノードはこの第２のリクエストの受信に応答して特定のデータユニットを伝送する。本発明による方法によれば第１のステップにおいて、第１のリクエストまたは第２のリクエストあるいはそれら双方に対し、第１のプライオリティに対応する識別子を割り当てる。第２のステップにおいて第２のノードは、第１のプライオリティに対応する識別子を評価し、この識別子に基づき第２のプライオリティを計算する。さらに第３のステップにおいて第２のノードは、要求された特定のデータユニットを伝送し、その際、計算されたプライオリティがこの伝送に割り当てられる。なお、ここで述べておくと、要求されたデータユニットの伝送は必ずしも、リクエストを発した第１のノード宛でなくともよい。また、第３のノードが伝送されたデータユニットの受け取り側であり、第１のノードは開始ノードにすぎない可能性もある。これはたとえば第１のノードがユーザインタフェース、スケジュールマネージャ等を有する理由による。このケースでは、第１のノードが少なくとも第２のリクエストを上述の第３のノードへも送信するのがよい。

対応するディバイスには、本発明による方法の各ステップを実行する個々の手段が含まれている。

上述の特定のデータユニットまたは特定のタイプのデータユニットをたとえば、決められたタイトルをもつムービーのビデオデータ、あるいは決められた特定の俳優が含まれている入手可能なすべてのムービーのビデオデータ等とすることができる。この情報を、たとえばメタデータのマークとしてデータユニットに割り当てることができ、たとえばこれをＸＭＬフォーマットとすることができる。

従属請求項、以下の説明ならびに図面には本発明の有利な実施形態が示されている。

次に、添付の図面を参照しながら本発明の実施例について説明する。

実施例
以下では本発明についてオーナーゾーンＯｗｎｅｒＺｏｎｅに関する実施例について説明する。これはピア・ツー・ピアベースのネットワーク構造であり、この場合、ノードは固有のノード識別子と共通のピアグループ識別子をもち、ピアグループに属する各ノードは互いに自由に通信可能であり、メッセージおよび他のデータ等を交換可能である。本発明を他の形式のネットワークにも適用可能であり、ノード自体が完全に自律的に組織編成を行うネットワークのために殊に有利である。

１．プライオリティのコンセプト
本発明によれば、第１レイヤのプライオリティと第２レイヤのプライオリティとの間の区別に関与する２ステージコンセプトという概念が導入される。第１レイヤすなわち暗黙的プライオリティは相対的なプライオリティであり、つまり含まれているノードたとえばオーナーゾーン内のピアが従うプライオリティ関係である。これらは明示的な値を有しておらず、たとえばそれらに対応づけられた数値のプライオリティレベルあるいはプライオリティ番号を有していない。したがって暗黙的プライオリティのセットによって表されるのは、ノードの固有の「知識」であり、つまりこれはノードが従うルールのセットに依存する。有利には暗黙的プライオリティを自動的に生成可能であり、そのためユーザまたはアプリケーションはそれらを定義する必要がない。第２レイヤすなわち明示的プライオリティには、変更可能または削除可能な情報の一部分としてプライオリティレベルたとえば数値または他の識別子が含まれている。ユーザあるいはアプリケーションは、適切であるとみなせば割り当てまたは変更を実行できる。明示的プライオリティレベルを相対的なものとすることができ、たとえば「高」および「低」とすることができ、あるいは整数または一般には何らかのランク付けされた用語とすることができる。１つのタスクの明示的プライオリティのレベルは１つのタスクに割り当てられ、これを他のタスクの明示的プライオリティと比較することができ、必要であればこれにより判定を下すことができる。たとえばこれは、２つのタスクのいずれがハードウェアアクセス、メモリスペース、処理パワー等に対しいっそう高いプライオリティを獲得するのかを決定するような場合である。

１．１ 暗黙的プライオリティ
伝送のマネージメントを円滑に支援し、１つのオーナーゾーン内のノード間およびそれらのアクション間におけるコンフリクトおよびボトルネックを回避する目的で、各ノードは以下の暗黙的なルールに従うようインプリメントされる。

基本的なルールは「最初に来たものが最初にサービスされる First come, first served」である。たとえば、タスクをセットアップしタスクの開始時間を設定するノードによって定義されるTaskInitTimeパラメータの評価がインプリメントされている。この場合、タスクをたとえばサーチのタスクあるいはデータ伝送のタスクとすることができ、これはタスクに関与する各ノード間で行われる特有のメッセージフローをもっている。オーナーゾーン内のすべてのノードは自身のすべてのアクションにおいて、いっそう早い時点に開始されたタスクがそれよりもあとの時点で開始されたタスクよりも優先されることに留意する。また、いっそう早い時点で受信されたメッセージは通常、それよりもあとの時点で受信されたメッセージよりも優先される。つまりノードは一般に、TaskInitTimeパラメータにより与えられたリクエストの開始順序で受信したリクエストに応答する。したがって、関連するすべてのノードに存在する共通のタイムベースが有用である。

本発明の１つの観点によればこのルールの例外としてデータ伝送タスクは、関連する先行のサーチタスクから所定の範囲で自身のプライオリティを継承することができる。このことが有用である理由は、一般にサーチタスクは見つけられたコンテンツ部分に対しデータ伝送タスクをセットアップする意図を伴って発せられる可能性があるからである。この目的でノードは、いっそう早い時点のサーチリクエストに関連する１つのコンテンツ部分の伝送が、そのサーチリクエストのTaskInitTime後に与えられた期間Ｔ_ｗｆｔ（「伝送待ち時間」、たとえば５秒）内では、それよりもあとのサーチリクエストに関するコンテンツ部分の伝送よりも高いプライオリティをもつようにする。とはいえ、他のタスクにもっと高いプライオリティをもたせることができ、一例としてノードは、たとえばライブストリームのレコーディングタスクなどのために即座に伝送を開始する必要があるケースでは、このような逸脱を例外扱いすることができる。

第２のルールとして挙げられるのは、個々のノードに関与する他のすべての実行中の伝送またはスケジューリングされた伝送を考慮して、必要とされるリソースを利用できる場合のみ、タスクまたはデータ伝送が許可されることである。つまりノードはタスク開始前、そのタスクに関与することになるノードのリソースを最初にチェックするか、あるいは場合によってはオーナーゾーンにおけるすべてのノードについて概略を取得する。これにより特定の期間にわたり伝送が開始され、これにはその時点で十分な記憶容量と十分な伝送キャパシティすなわち起こり得る伝送の十分なレートと回数に応じることのできるノードだけが含まれる。これはソースノードとデスティネーションノードの双方に関わる。必要であれば、ノードは伝送が可能になる時点まで意図する伝送を遅延させる。伝送に関与するノードは個々のリソースを割り当てる。それらのリソースを、たとえばタスクのキャンセルによって割り当て解除することができる。したがって、２つのタスクが互いに阻止し合う状況つまりはネットワーク全体が阻止される状況が回避される。

第３のルールとして挙げられるのは、実行中の伝送はそれらを開始したノードにより明示的にキャンセルされないかぎり阻止されるべきではないことである。つまりあるノードは、自身の伝送をセットアップするためにリソースを取得する目的で、他のノードからの実行中の伝送をキャンセルできない。伝送を開始したノードに対してのみ、それをキャンセルする許可が与えられている。この場合、そのノードは必要であればさらに別の伝送をセットアップすることができる。

第４のルールとして挙げられるのは、占有するリソースが利用可能となる期間に対してのみ、すなわち実行中の伝送が完了しているかあるいは完了することになる期間に対してのみ、伝送のスケジューリングが許可されることである。つまりノードは、特定の期間にわたりデータ伝送に関与する可能性のあるリソースのアベイラビリティについて最初にチェックする。その際、デスティネーションノードにおいて十分な記憶容量を利用でき、かつソースノードとデスティネーションノードの双方で十分な伝送キャパシティすなわち十分な伝送レートと伝送回数に応じることのできるノードと期間に対してのみ、伝送が開始される。この場合、関与するノードによって、伝送が行われる期間に対し個々のリソースが割り当てられる。伝送がすでにスタートしたか否かにかかわらず、伝送のキャンセルによりどのような時点でもリソースを割り当て解除できる。したがって、他のノードに対し自身のリソースを提供することのできるいずれのノードにも、リソースがいつ「登録」されるのか、他のいずれのノードにおいてあるいは何の目的でそれが行われるのかをコントロールするタイムテーブルを設けることができる。

第５のルールとして挙げられるのは、リアルタイム伝送またはストリーミング伝送は非リアルタイム伝送またはファイル伝送よりも高いプライオリティをもつことである。より一般的な視点でいえばリアルタイムデータとは、プレイバック品質を落とすことなくソースデータレートを低減することのできないデータのことである。 このアイデアとは、ファイル伝送は一般にどのようなビットレートでもどのような期間にわたってもネットワークリソースに従い適切に行うことができる一方、たとえばオーディオデータおよび／またはビデオデータなどのリアルタイム伝送またはストリーミング伝送は精確なタイミングで行われることが要求され、これには消費されるコンテンツたとえばユーザが見たり聞いたりするコンテンツをプレイバックする必要性を伴う可能性がある、というものである。あるノードは、実行中のノンリアルタイム伝送／ファイル伝送を、ビットレートと伝送期間の双方を変更することにより、たとえば'ModifyTransfer-Request("modify")'のような所定のリクエストメッセージを用いて、速度を下げたり速度を上げたりすることができる。伝送レートと伝送期間の積はファイルサイズであり、したがってこれは変更されないままである。タスクを開始したノードがこれを禁止するための１つの可能性は、AllowTransferSpeedChangeのようなタスク関連パラメータを導入して、これに対し"false（偽）"をセットすることである。

第６のルールは、レコーディングのための伝送はプレイバックのための伝送よりも高いプライオリティを常にもつことである。このルールは先に挙げたルールよりも下位におかれるものであって、つまりファイル伝送はストリーミング伝送よりも常に低いプライオリティを有する。ここで前提とすることができるのは、あるコンテンツ部分のレコーディングに対しては時間制限が存在するということであり、その理由は、以降の時点ではなく現在そのコンテンツ部分を利用できる一方、あるコンテンツ部分のプレイバックは以降の時点であっても行えるからである。したがってレコーディングタスクがプレイバックタスクと競合する場合、ノードは有利にはリソースをレコーディングタスクに割り当てることになる。さらにそのノードはレコーディングタスクを実行できるよう、プレイバックタスクをキャンセルすることさえできる。このことは、アプリケーションまたはユーザによって一般に許可されているならば、アプリケーションレベルまたはユーザレベルで行うことができる。たとえば、プレイバック伝送が所定の期間にわたりスケジューリングされており、アプリケーションが同じ期間中にそれとは別のコンテンツ部分のレコーディングを行おうとする一方、リソースがそれを許可しないような場合、アプリケーションはスケジューリングされているプレイバック伝送をキャンセルし、その代わりに新たなレコーディング伝送をスケジューリングすることができる。

この状況が発生する可能性があるのはたとえば、２つのレコーディング機器と１つのプレイバック機器と１つの受信機および１つのディスプレイを備えたホームネットワークなどにおいてである。この場合、プレイバック機器から再生されているムービーをユーザがディスプレイで見ている間、レコーディング装置の一方が受信機から到来するビデオストリームを記録する。しばらく経過した後、レコーディング機器の記憶ディバイスがいっぱいになり、かつネットワークとレコーディング機器が、第２のレコーディング機器においてレコーディングをシームレスに継続できるように構成されているものとすれば、ネットワーク上のトラフィックはおそらく、１台目のレコーディング機器から２台目のレコーディング機器への切り替え中、高まることになる。しかしながらこの付加的なトラフィックはレコーディングのために必要であり、したがってこれはプレイバックデータよりもいっそう高いプライオリティを有する。このような状況では、レコーディングされたデータを首尾一貫させる目的で、プレイバックが短期間中断されるとしても、このことを許容できる。

１．２ 明示的プライオリティ
上述の相対的な暗黙的プライオリティに加えて、本発明はオプションとしての明示的プライオリティレベルも使用され、これはたとえば「低」「高」または整数値あるいは一般に何らかのランク付けされた概念といったものであって、タスクに対応づけることのできる「プライオリティ」パラメータに基づく。明示的な「プライオリティ」パラメータを、あるタスクに対しそのタスクを開始したノードまたはユーザによってオプションとして割り当てることができる。これを明示的プライオリティレベルを利用するためのアプリケーションに関わる事柄とみなすこともできる。あるノードは、「プライオリティ」パラメータつまりはあるタスクの明示的プライオリティを、リクエストメッセージ（たとえば'ModifyTransfer- Request("modify")'）をそのタスクに関与する個々の他のノードに送信することによって変更することができる。

いずれにせよ、暗黙的プライオリティあるいは第１レイヤプライオリティは明示的プライオリティよりも上位となる。したがって明示的プライオリティレベルは、タスクが同一の暗黙的プライオリティを有するときのみ利用される。あるディバイスが１つの時点で２つ以上のタスクを実行しようとする場合、そのディバイスはそれらのタスクを暗黙的プライオリティに従い評価し、同一の暗黙的プライオリティの場合、明示的プライオリティが割り当てられているならば、それらのタスクの明示的プライオリティレベルに従い評価し、ディバイスはその評価に応じて自身のリソースを提供する。

あるノードにおいて実行される対応するユーザまたはアプリケーションがそのノードに対して適正なUseKeyを与えている場合のみ、そのノードに対し自身が開始していないタスクの明示的プライオリティレベルの変更が許可される。これは個々のコンテンツ部分と対応づけられたパラメータであって、これはユーザによりその目的でオプションとして定義されたものであり、たとえば特定の関連ユーザグループに対し関係づけることができる。さらに明示的プライオリティレベルを、タスクを開始したアプリケーションを実行するノードを介して変更することができ、あるいは１つの実施形態によればオーナーゾーン OwnerZone内のいずれかのノードを介して変更することができる。このケースでは、オーナーゾーン内の誰かであれば、割り当てられたUseKeyパラメータをもたない何らかのタスクの明示的プライオリティレベルを変更することができる。

以下では、２つの明示的プライオリティレベル「低」および「高」が定義されているが、プライオリティレベルのどのようなスキーマに対しても適用することができる。明示的プライオリティレベルがタスクＡについて定義されていない場合、そのタスクの未定義の（またはデフォルトの）値を扱うために以下のルールが適用されることになる：
同一の暗黙的プライオリティをもちおそらくは競合する他のタスクＢが「高」という明示的プライオリティレベルを有する場合、タスクＡにおける未定義の（またはデフォルトの）明示的プライオリティが「低」であるとみなされる；同一の暗黙的プライオリティをもちおそらくは競合する他のタスクＢが「低」という明示的プライオリティを有する場合、タスクＡの未定義の（またはデフォルトの）明示的プライオリティが「高」であるとみなされる。

つまり、明示的プライオリティまたは第２レベル「高」のプライオリティがあるタスクに割り当てられるのは、そのタスクが同一の暗黙的プライオリティをもつ他のタスクよりも重要なものとして意図的に扱われる場合だけであり、「低」レベルのプライオリティについてはこの逆があてはまる。

可能であるならば、他のタスクよりも高い暗黙的プライオリティまたは明示的プライオリティをもつタスクを、記憶容量や伝送レート等に関してそのタスクの要求が他のタスクの要求よりも良好に満たされるようインプリメントする必要がある。低い明示的プライオリティにセットされたタスクは、上述のそれよりも高いプライオリティのタスクが処理された後、残されたケイパビリティによってインプリメントされることになる。

１．３ プライオリティルールのインプリメンテーション
上述のプライオリティルールをインプリメントするために、各ノードは実行中のタスクおよび／またはスケジューリングされているタスクのすべてを記憶することができ、そこには「タスクおよびスケジュール用のデータベース」が含まれている。それらのタスクは開始された時点に応じて（それらのTaskInitTimeに従い）逐次順番に格納されており、個々のタスク識別子タスクＩＤ（TaskID）によって識別される。タスクが完了すると、そのタスクはデータベースから除かれる。各ノードは、要求を開始するときまたはサービスするとき、上述のプライオリティ関連ルールを適用する。

図１には、同じ暗黙的プライオリティと明示的プライオリティをもつ２つのリアルタイムストリーミング伝送Ｔｒ１，Ｔｒ２を用いたシナリオが描かれており、この場合、十分な帯域幅Ｂを利用可能である。第１の伝送Ｔｒ１は時点ｔ_ＴＲＱ１で要求され、この伝送は時点ｔ_ＳＲＱ１におけるサーチリクエストに対する応答である。ただしこれは要求後、規定の伝送待ち時間Ｔ_ｗｆｔ１を経てはじめて開始される。その目的は、それよりも高いプライオリティをもつ別の伝送が要求されているかをチェックするためである。図１の場合にはこのことは該当せず、したがって時点ｔ_ＳＲＱ１＋Ｔ_ｗｆｔ１において第１の伝送Ｔｒ１が開始する。第１の伝送Ｔｒ１の実行中、時点ｔ_ＳＲＱ２における第２のサーチリクエストにより第２の伝送リクエストが時点ｔ_ＴＲＱ２において生じる。第２の伝送Ｔｒ２は時点ｔ_ＳＲＱ２＋Ｔ_ｗｆｔ２でスタートすることができる。なぜならば求めに応じることのできるデータレートまたは帯域幅Ｂ_ｍａｘは、要求されているデータレートＲ_１＋Ｒ_２の合計よりも大きいからである。時点ｔ_ＴＲＱ１における伝送リクエストが、第１のサーチリクエストｔ_ＳＲＱ１後、Ｔ_ｗｆｔ１よりもあとに到来する可能性もある。

図２には、第１のサーチリクエスト後、Ｔ_ｗｆｔ１の期間内の時点ｔ_ＳＲＱ２に第２のサーチリクエストが到来した状況が描かれている。さらにこの場合、第２の伝送Ｔｒ２のプライオリティＰ２は第１の伝送Ｔｒ１のプライオリティＰ１よりも高く、これはたとえば双方の暗黙的プライオリティが等しいときの明示的プライオリティに基づくものである。ただしこの場合、双方の伝送を同時に実行するには帯域幅を十分に利用できない。ｔ_ＳＲＱ２＜ｔ_ＳＲＱ１＋Ｔ_ｗｆｔ１であるため、結果として第２の伝送Ｔｒ２が最初にスタートする一方、先に要求されていた他方の伝送Ｔｒ１は、Ｔｒ２が完了した後、時点ｔ_Ｅ２でスタートする。これは、図１に示した「最初に来たものが最初にサービスされるfirst-come first-servedルール」に対する先に挙げた例外である。図２において、第２のサーチリクエストが少し後から到来した場合には、つまりｔ_ＳＲＱ２＞ｔ_ＳＲＱ１＋Ｔ_ｗｆｔ１である場合には、双方が同じ暗黙的プライオリティをもっているならば、たとえば双方がリアルタイムストリーミング伝送であるならば、第１の伝送Ｔｒ１がスタートすることになる。

図３には、第２のサーチリクエストがあとから到来した場合、つまりｔ_ＳＲＱ２＞ｔ_ＳＲＱ１＋Ｔ_ｗｆｔ１である状況が描かれており、したがってここでは第１の伝送Ｔｒ１がすでにスタートしている。ただしここでは第２のサーチリクエストはいっそう高いプライオリティを有しており、たとえばＴｒ１はファイル伝送でありＴｒ２はリアルタイムストリーミング伝送であり、かつ利用可能な帯域幅は双方の伝送を並行して実行するには不十分である：Ｂ_ｍａｘ＜Ｒ_１＋Ｒ_２。このケースでは、第２の伝送Ｔｒ２はそのプライオリティが高いことからいずれにせよ時点ｔ_ＳＲＱ２＋Ｔ_ｗｆｔ２でスタートし、実行中の第１の伝送Ｔｒ１に対しては低減されたデータレートＲ_１ｒｅｄだけしか与えられない一方、第２の伝送Ｔｒ２はＢ_ｍａｘ＞Ｒ_１ｒｅｄ＋Ｒ_２で実行される。ネットワークにおける通信メッセージを可能にする目的で、少ない帯域幅残留分Ｂ_ｍａｘ−Ｒ_１ｒｅｄ−Ｒ_２が空き状態で残される。第２の伝送Ｔｒ２が時点ｔ_Ｅ２で完了した後、第１の伝送には最大限の帯域幅Ｒ_１を再び獲得する。このようにした効果は、第１の伝送Ｔｒ１がいくらか長くかかる一方、ストリーミングデータ伝送Ｔｒ２をリアルタイムで実行できることである。Ｔｒ１は非リアルタイムデータであるので、伝送Ｔｒ２が実行されている間の伝送Ｔｒ１に対するビットレート整合はデータ品質に影響を与えない。有利なことに、双方の伝送は互いに阻止し合わず、しかもネットワーク通信のための帯域幅キャパシティさえ残される。

図４には、明示的プライオリティが用いられる状況が描かれている。時点ｔ_ＳＲＱ１においてホームネットワーク内で第１のサーチリクエストが発せられ、これにより第１の暗黙的プライオリティＰ_１で時点ｔ_ＳＲＱ１＋Ｔ_ｗｆｔ１にスタートする第１の伝送Ｔｒ１が生じる。その後、時点ｔ_ＳＲＱ２において第２のサーチリクエストにより、Ｐ_１と等しい第２の暗黙的プライオリティＰ_２で時点ｔ_ＳＲＱ２＋Ｔ_ｗｆｔ２に第２の伝送Ｔｒ２が生じる。この場合、双方がファイル伝送であって同じ明示的プライオリティであり、双方ともに「低」、未定義あるいは「高」である。したがって双方の伝送に対し等しいデータレート：Ｒ_１＝Ｒ_２が与えられる。ただし少し経過した後、時点ｔ_ｕでユーザは第１の伝送Ｔｒ１のプライオリティ変更を決断する。その理由はたとえば、伝送Ｔｒ１はユーザが著しく迅速に取得したいリムーバルディスクへの書き込みを行うためなどである。この目的で、図４に示されているようにユーザは第１の伝送Ｔｒ１の明示的プライオリティが高くなるよう変更することができ、あるいは択一的に第２の伝送Ｔｒ２の明示的プライオリティが低くなるよう変更することができる。その結果、第１の伝送は時点ｔ_ｕ後、いっそう高いデータレートを獲得することになり、時点ｔ_Ｅ１でいっそう速やかに完了することになる。その時点以降、第２の伝送Ｔｒ２に対しいっそう高いデータレートを与えることができ、その結果、図4に描かれているシナリオでは双方の伝送に必要とされる総時間が等しくなる。

これまで説明してきた基本的メカニズムはただ２つの伝送に関して例示したものであるけれども、それらのメカニズムをどのような個数の伝送にも利用することができるし、それらを組み合わせることもできる。たとえば、図4において時点ｔ_Ｅ１よりも後および時点ｔ_Ｅ２よりも前に、いっそう高いプライオリティをもつさらに別の伝送が要求され、図3によるメカニズムを利用してその伝送が開始されることも考えられる。

図５には、本発明の別の実施形態が示されている。この場合、ファイル伝送ＲＱ１のための第1のリクエストとファイル伝送ＲＱ２のための第2のリクエストが短期間で相前後して発せられる。これらのプライオリティＰは、連続的に上昇するものでありデフォルト値Ｐ_０からスタートするものであると考えることができるので、最初に来たものが最初にサービスされるfirst-come first-servedルールが実現されると捉えることができる。この場合、第2のリクエストＲＱ２の方に対しいっそう速やかな応答が行われ、対応する伝送Ｔ２を（おそらくは応答後、伝送待ち時間Ｔ_ｗｆｔを経てから）時点ＴＳ２でスタートさせることができる一方、第1のリクエストＲＱ１に関するコンテンツはまだ見つけ出されておらず、これはたとえばそのコンテンツを所有しているノードがビジー状態にある等の理由による。実行中の伝送Ｔ２のプライオリティＰ_２は一定に維持される一方、第1のリクエストのプライオリティは、そのリクエストに対し応答が行われて伝送Ｔ１がスタートするまでさらに上昇する。プライオリティは、時点ＴＳ１で伝送がスタートしたときの値のまま維持される。第1の伝送Ｔ１のプライオリティの方が高くなり、双方の伝送Ｔ１，Ｔ２は非リアルタイムのファイル伝送であるため、この実施形態によれば第１の伝送Ｔ１は他方の伝送Ｔ２よりも多くの帯域幅を獲得する。したがって時点ＴＥ１で第１の伝送Ｔ１の方が速やかに完了することができ、この伝送の方が早期に要求されたことから、これは意図されたとおりである。

図６には、これに類似した状況が描かれている。ただしここでは、第２のリクエストＲＱ２′の方が第１のリクエストＲＱ１′よりも高いプライオリティをもっている。たとえばこの場合、ユーザはこのリクエストＲＱ２′の方に高い明示的プライオリティを与えている。両方のリクエストは非リアルタイムのファイル伝送に対してなされたものである。第２のリクエストＲＱ２′に対し応答が行われると、伝送はそのプライオリティＰ２′をこのリクエストＲＱ２′から継承し、この伝送を（おそらくは時点Ｔ_ｗｆｔ後）時点ＴＳ２′でスタートさせることができる。第１のリクエストＲＱ１に対し応答が行われるとき、このリクエストは第２の伝送Ｔ２′よりも低いプライオリティＰ１′をもっているので、第２の伝送Ｔ２′が完了するまではごく僅かな帯域幅リソースしか与えられない。

２．コンフリクト、ボトルネックおよびそれらのマネージメントならびに回避アプローチ
コンフリクトは、２つまたはそれ以上のオペレーションが互いに競合し排除し合う状況で発生するので、それらのすべてを実行できるわけではない。たとえば一方のアプリケーションがコンテンツ部分を削除しようと試みるのに対し、他方のアプリケーションがそれを読み取ろうとする可能性がある。したがってここでは「コンフリクト」という概念はたとえばＤＳＳのようなネットワークシステム内のシステマティックなコンフリクトのことを指し、意図するタスクを実行できない状況を表す。ただし、コンフリクトを克服する手法は存在し得る。上述の例における１つの可能性として、読み取りタスク後に削除タスクを実行することもできるし、あるいは読み取りタスクをキャンセルし、それに続いて削除タスクを実行できるようにすることもできる。

ボトルネックは物理的な制約であり、たとえば低いスループットレートまたは小さい記憶容量、大きな遅延などである。したがってボトルネックは、実行されるプロセスまたはタスクを制限する要因である。したがって本発明において「ボトルネック」という概念は、意図したタスクを実行できるが、ただし制限は伴うという状況を指す。コンフリクトとは異なり、ボトルネックはタスクを阻止したり妨げたりしない。

以下のセクションでは、いくつかのコンフリクトおよびボトルネックならびにそれらのマネージメントについて説明する。また、それらを回避するためのアプローチについても述べる。

２．１ コンフリクトおよびそれらのマネージメント
コンフリクトはたとえば以下のことに関して発生する可能性がある：
・記憶容量：たとえばデスティネーションノードなどの記憶容量がデータ伝送に十分ではない可能性がある；
・伝送レート：たとえばソースノードまたはデスティネーションノードなどの伝送レートがデータ伝送に十分ではない可能性がある；
・伝送回数：ノードがマネージメント可能な伝送回数に達してしまい、それ以降の伝送リクエストを扱えなくなる可能性がある。
・アクセス：２つのノードが第３のノードのリソース（たとえば記憶容量、伝送レート、処理パワー）に同時にアクセスしようとする可能性がある）；
・応答なし：たとえばノードが切り離されているなどの理由から、予期されるところで応答を受け取れない可能性がある；
・アプリケーションまたはユーザの関心対象：対応づけられているUseKeyが未知であるため、ユーザまたはアプリケーションが所望のコンテンツ部分にアクセスできない可能性がある；
・先行の割り当て：あるノードが別のノードに対し特定のリソースを要求したとき、十分なリソースを利用可能であるという答えを受け取るが、そのリソースに割り当てようとすると、その間に第３のノードがそのリソースを割り当ててしまったため、拒否されてしまう可能性がある。
・ノードのアベイラビリティ：たとえば切断や一時的な電源オフなどの理由で、あるノードがネットワーク内で利用できないかぎり、そのリソースたとえばそこに格納されているコンテンツは他のノードとって利用不可能である。また、伝送実行中、あるいはスケジューリングされた伝送が開始される前であっても、ノードを利用できなくなる可能性がある。

記憶容量におけるコンフリクトを克服するために、メッセージおよび制御メタデータを利用することができる。たとえば記憶スペースのコンフリクトを克服する目的でアプリケーションまたはユーザは、関心または重要性の少ないコンテンツ部分を削除または移動する決定を下すことができる。これはたとえばユーザの好みに従って決定できる。これにより新たにレコーディングするためのスペースが形成される。伝送レートにおけるコンフリクトを克服する目的で、データ伝送を順次連続して実行することができる。

事前の警告として、あるいは緊急事態のみ、リソースのマネージメントを連続的に行うことができる。あるノードが個々のリクエストたとえばコンテンツの伝送に関与せよというリクエストを受け取るかまたはそれを発するとただちに、そのノードにおけるリソースが割り当てられる。この段階では、ユーザまたはアプリケーションの意図および決定が一般にはまだ既知ではないときには、サーチリクエストはまだリソースの割り当てを示唆せず、たとえば複数のマッチが見つかる可能性があり、それに対し選択が下されることになる。ただし、データ伝送がこれに続く可能性がある。したがって本発明の目的は、より早期のサーチリクエストによってサーチ結果の伝送に対しいっそう高いプライオリティを生じさせることにある。これについては以下、プライオリティのセクションで詳しく説明する。サーチリクエストの開始時点すなわちタスクＩＤが定義される時点は、タスクに関与する他のノードに通知される。

アベイラビリティを向上させる目的で、重要なコンテンツ部分をコピーして、２つまたはそれよりも多くのノードに冗長的に格納しておくことができる。したがって、現在利用できない所定のノードに格納されているコンテンツ部分に対し他のノードからアクセスすることができる。これはアプリケーション層あるいは中間コントロール層に関する問題である。たとえばシステムは、オーナーゾーンのユーザがどのジャンルに関心があるのかを学習または質問することができ、個々のコンテンツ部分のコピーを自動的に生成することができる。さらにシステムは、レコーディングされるとわかっているコンテンツ部分の複製をリムーバルメディアに作成することもでき、オーナーゾーン内で利用可能な据え置き型メディアにそれらを格納することもできる。この目的で、ソフトウェアはノードのアベイラビリティの時間ならびにユーザが何を重要であるとみなしているのかを追従する必要がある。

同一のコンテンツ部分を種々のノードで冗長的に利用できるのであれば、何らかのアクセスコンフリクトまたは伝送レートコンフリクトを克服するためにそれらを用いることができる。たとえば、２つのノードが第３のノードにおける同一のコンテンツ部分にアクセスしようとしたならば、２つのノードのうち一方のノードを、さらに別のノードに存在するまったく同じコンテンツ部分にリダイレクトすることができる。 あるノードが種々のノード上でまったく同じコンテンツを見つけたならば、そのノードは最も高い伝送レートを提供できるノードを提供することができる。

タスク実行中、そのタスクのソースまたはデスティネーションではないノードを利用できなくなっても、このことは通常は問題ではない。
・サーチリクエストを開始したノードが利用不可能になった場合、そのサーチタスクに関与している他のノードはノード消失をタスクのキャンセルとみなし、タスクならびにそのパラメータを自身のタスクメモリから削除する。
・コンテンツあるいはそのディバイスケイパビリティに関する情報の提供を要求されたノードが利用不可能になった場合、そのノードは単に応答しないだけである。要求を出したノードはタイムアウト後、それを了解する。
・コンテンツ伝送を開始したがソース自体またはデスティネーション自体ではないノードが利用不可能になった場合、伝送の開始および終了に関する通知メッセージが単にそのノードに到達しないだけである。伝送が成功した後、ソースノードとデスティネーションノードはタスクおよびそのパラメータを通常どおり自身のタスクメモリから削除する。伝送実行中、タスクを開始したノードが再び利用可能になると、そのノードに対し何らかの通知メッセージが到達するようになり、ほとんど通常どおりタスクが完了することになる。伝送後、タスクを開始したノードが再び利用可能になった場合、そのノードは［TaskInitTime］対［現在時間プラス（予期された）伝送期間］を分析し、タスクおよびそのパラメータを自身のタスクメモリから削除する。その際にノードは、デスティネーションノード上の伝送済みコンテンツ部分をサーチすることで伝送がうまく完了したか否かをチェックすることができるし、必要であれば新たな伝送開始により再び伝送にトライすべきか否かを決定することができる。

伝送実行中、たとえば電源オフまたは切断などによってソースまたはデスティネーションノードが利用不可能になった場合、伝送をうまく完了させることができなくなる。いくつかの例外を伴うけれども一般的には、関与しているノードはタスクをそれがキャンセルされたものと見なすことになり、そのタスクおよびそのタスクのパラメータを自身のタスクメモリから、できるだけ早く削除する。この場合、種々の状況および可能性が存在する：
・実行中、ソースノードが利用不可能になった場合、デスティネーションノードはａ）すでに受信済みのコンテンツを削除する、またはｂ）そのコンテンツを保持し、新たなコンテンツＩＤ（ContentID）をそれに割り当てて、終了時点または終了ビットを通知する、またはｃ）そのコンテンツを保持し、もとのコンテンツＩＤを保持し、あとで伝送再開にトライしようという意図で、終了時点または終了ビットを通知する。ついでそのノードは、伝送タスクを中断されたものとして自身のタスクメモリにマークする。ノードがソースノード自体またはデスティネーションノード自体でなければ、そのノードはタスクを開始したノードに対し中断について通知する。そのノードはTransferStatusInformation("interrupted"）といったような特別なメッセージを用いることができ、他のノードからキャンセルリクエストが到来するのを短期間、待ち受ける。

ケースａ）およびｂ）の場合、デスティネーションノードおよびタスクを開始したノードは、そのタスクおよびそのパラメータを自身のタスクメモリから削除する。そのノードが再び利用できるようになった場合には、これと同じことが当てはまる。ケースｃ）の場合、デスティネーションノードはソースノードに対しコンタクトを取り続け、そのノードが再び利用可能になるとただちに、中断したポイントから伝送を再開し、タスクを開始したノードに対し（TransferStatusInformation("resumed")といったメッセージを用いて）通知を行う。ソースノードが所定の期間Ｔ_ｗｕａ（「利用可能になるまでの期間 "wait until available" timeたとえば１週間）以内に利用可能にならなければ、デスティネーションノードおよびタスクを開始したノードは、ケースｂ）のように振る舞うことになる。
・伝送実行中、デスティネーションノードが利用不可能になった場合、ソースノードは送信データをストップし、タスクを開始したノードに対し（それがソースノード自体またはデスティネーションノード自体でないかぎり）、たとえばTransferStatusInformation("interrpted"）メッセージなどを用いて中断について通知を行い、そのノードからキャンセルリクエストが到来するのを短期間、待ち受ける。ついでそのノードは、タスクおよびそのパラメータを自身のタスクメモリから削除する。どのリソースを利用できるのかに依存して、タスクを開始したノード（ソースノードまたはデスティネーションノード自体ではない）は、ａ）他のデスティネーションノードへの個々のコンテンツ部分の伝送を開始しようとトライし、またはｂ）元のデスティネーションノードが再び利用可能になるまで待機し、後者のケースであれば、タスクを開始したノードはそのタスクおよびそのパラメータを自身のタスクメモリに保持し続け、その伝送を中断されたものとしてマークする。元のデスティネーションノードが再び利用可能になったならば、そのノードは自身のタスクメモリをチェックして中断を検出し、伝送が中断したポイントを追跡して、そのポイントからデータを送信するようソースノードに要求することで、そのポイントから伝送を再開し、たとえばTransferStatusInformation ("resumed")メッセージなどを用いて、タスクを開始したノードに対し通知を行う。開始ノードはケースａ）の場合、伝送タスクをキャンセルし、その結果としてデスティネーションノードはすでに伝送済みのコンテンツを削除することになり、またはケースｂ）の場合、普通の伝送中のように振る舞い、つまりタスク完了通知を待ち受ける。

伝送を指定時間に対しスケジューリングすることができる。ノードが利用できない一方で、スケジューリングされた伝送をスタートさせるべき場合、以下の状況が考えられる。
・スケジューリングされた伝送のスタート時点でソースノードが利用不可能であれば、デスティネーションノードは開始ノードに対し（それがソースノードまたはデスティネーションノード自体でなければ）、たとえばTransferStatusInformation("not started")のようなメッセージを利用して、このイベントについて通知を行う。ついでそのノードは短期間、開始ノードからキャンセルリクエストが到来するのを待ち受ける。そのノードがキャンセルリクエストを受け取らなければ、そのノードは所定の期間Ｔ_ｗｕａ（たとえば１時間または１週間）にわたり、伝送をスタートさせるよう再びトライする。この期間中、開始ノードはいつでもタスクをキャンセルすることができる。キャンセルされた場合あるいは期間Ｔ_ｗｕａが経過したならば、デスティネーションノードおよび開始ノードはタスクおよびそのパラメータを自身のタスクメモリから削除する。ソースノードが再び利用可能になった場合には、これと同じことをソースノードが行う。ソースノードが所定の期間Ｔ_ｗｕａ以内に再び利用可能になり、伝送をうまく開始させることができるならば、遅延は無視されて、通常のメッセージフローが用いられる。
・スケジューリングされた伝送のスタート時点でデスティネーションノードが利用不可能であるならば、デスティネーションノードは、スケジューリングされた時点で自身へコンテンツを送信せよというソースノードに対するリクエストをスタートさせない。ソースノードは開始ノードに対し（そのノードがソースノードまたはデスティネーションノード自体ではないならば）、たとえばTransferStatusInformation("not started")メッセージなどを用いて、そのイベントについて通知を行うことになる。

利用可能なりソースに依存して開始ノードは、ａ）デスティネーションノードが再び利用可能になるのを待って伝送をスタートさせ、またはｂ）キャンセルリクエストを送信する。ケースｂ）の場合、開始ノードは他のデスティネーションノードを選択することができる。ケースａ）の場合、ソースノードおよび開始ノードはタスクおよびそのパラメータを自身のタスクメモリ内に所定の期間Ｔ_ｗｕａにわたり保持し、その後、それらを削除する。デスティネーションノードが再び利用可能になったときにも、これと同じことがあてはまる。デスティネーションノードが期間Ｔ_ｗｕａ内で再び利用可能になると、そのノードはソースノードに対しデータを送信するよう要求する。伝送をうまくスタートさせることができたならば、通常のメッセージフローが用いられる。今度はソースノードが利用不可能であるならばデスティネーションノードは、ソースノードが利用不可能になった場合についてすでに述べたようにして振る舞う。

いずれのケースにせよどのようなノードであろうと、指定された期間Ｔ_ｗｕｅを超えて延びたあらゆるタスクを、そのタスクに関連するパラメータも含めて自身のタスクメモリから削除することになる。

２．２ ボトルネックおよびそれらのマネージメント
ボトルネックははたとえば以下のことに関して発生する可能性がある：
・記憶容量：デスティネーションノードの記憶容量は、要求されたとおりに実行すべきデータ伝送には十分ではない可能性がある；
・伝送レート：ソースノードまたはデスティネーションノードにおいて利用可能な伝送レート（帯域幅）が、要求されたとおりに実行すべきデータ伝送には十分ではない可能性がある；
・処理パワーまたは処理時間：たとえばストレージノードが、受け取ったサーチリクエストすべてを同時には、あるいは所定期間内には実行できない可能性がある。

記憶容量および／または伝送レートにおけるボトルネックを克服するために、メッセージおよび制御データを利用することができる。伝送レートにおけるボトルネックを克服する目的でアプリケーションまたはユーザは、コンテンツ部分の伝送を（それがリアルタイムストリーミングコンテンツであるのか非リアルタイムファイルコンテンツであろうとなかろうと）決定することができ、ファイルのような非リアルタイムであれば低いビットレートで伝送するよう決定し、この場合、その伝送時間は長くなる。リソースが再び利用可能になるとただちに、ビットレートを再び高めて伝送時間を短くすることができる。その際、必要とされるファイル伝送のビットレートを調整するための手段を利用することができる。

リアルタイムストリーミングコンテンツをサーチして、たとえばポータブルディバイスまたはモバイルディバイスなどに対し低い伝送レートでそれを伝送する場合、サーチリクエスト中に最大ビットレートを含めることができる。要求されたコンテンツ部分を所有しかつビットレートに整合しているディバイスだけが、そのリクエストに応答することになる。処理パワーまたは処理時間に関するボトルネックのケースにおいて、ストレージノードが受け取ったサーチリクエストすべてを同時には、あるいは所定時間内には実行できない場合、そのストレージノードはまだサーチ中であることを周期的に通知する。その際、必要であればシーケンシャルに、サーチリクエストすべてをどのようなかたちにせよマネージメントすることができる。

ボトルネックを克服するため、メッセージおよび制御メタデータの枠を実質的に越えて、主としてアプリケーション層において行われるさらに別の可能性が存在する。たとえば伝送レートまたは記憶容量に関するボトルネックのケースにおいて、プレイバックまたはレコーディングの目的で意図したリアルタイムストリーミング伝送を、ビットレートを低減して、つまりは品質を落として実行させることができ、これはノードがそのことを行える場合である。

２．３ コンフリクトおよびボトルネックの回避に向けて
コンフリクトまたはボトルネックの発生する状況に必ずしも至るわけではない。たとえば、ボトルネックおよびコンフリクトを避ける目的で、あるいはその数を減らす目的で、以下のステップを事前にとることができる。
・伝送キャパシティを利用可能な状態に維持しておく：どのようなノードに対してもある程度の伝送キャパシティをいつでも残しておく目的で、（殊にモノリシックブロックとみなしたとき）オーナーゾーンにおける伝送を、すべてのノードが１つの伝送を利用できるようなキャパシティを少なくとももつようアレンジしておくべきである。開始ノードはそのことを考慮する必要がある。一般に、あるノードに格納されているコンテンツに対し常にアクセスできるようにする目的で、ノードにおいて自由に利用できる最後の伝送を、可能であればプレイバック用に確保しておくべきである。レコーディングリクエストが発生し、その際にただ１つのノードだけしか利用できない場合には、あるいはそれぞれただ１つの自由に利用可能な伝送しか残されていないノードだけしか利用できない場合には、そのノードあるいはそれらのノードのうちいずれか１つのノードがそのリクエストに応答してコンテンツをレコーディングすることになる。これ以外のすべての状況では、各ノードがプレイバック用に自由に利用できる伝送を確保しておくべきである。ただし、スケジューリングされた伝送については配慮する必要があり、たとえばスケジューリングされた伝送を、あるノードにおけるすべての可能な伝送（MaxStreams）に割り当ててはならない。
・記憶容量を利用可能な状態に維持しておく：どのようなノードでもできるかぎりあらゆる時点である程度の記憶容量を残せるようにする目的で、ノード（またはオーナーゾーン全体）に格納されているコンテンツを分析することができ、複製コンテンツ部分または類似のコンテンツ部分、あるいはまれにしかアクセスされない、またはまったくアクセスされないといった他の判定基準にマッチしたコンテンツを、削除の目的でアプリケーションまたはユーザに呈示することができる。択一的に、もっと多くの記憶容量を得るようユーザに通知したり要求したりすることができる。

レコーディングリクエストがスケジューリングされている場合、ノードまたはオーナーゾーンに格納されているコンテンツを分析することができ、同一のコンテンツまたは類似のコンテンツがすでに格納されているならば、そのことをユーザまたはアプリケーションに通知することができる。この分析にあたり、すでに格納されているコンテンツが完全なものであるか、および十分な品質のものであるのかを考慮すべきである。その場合、アプリケーションは、新たなレコーディングを実行しないよう提案することもできるし、あるいはたとえばそのコンテンツが低品質であったり不完全なものであったりしたときなどには、他のバージョンを削除するよう提案することもできる。
・早期の警告：自由に利用可能な伝送の数が１まで下がったノードは、オーナーゾーン内の他のノードに対しDeviceCapabilitiesInformationメッセージを他のノード各々に送信することができる。
・ソフト切断 soft unpulugging：可能であるときはノードは「ハード hard」に切断されのではなく常に「ソフト soft」に切断されるので、ノードは自身の差し迫った消失を他のノードへ通知することができる。このことは、たとえばアプリケーションレベルですべてのアプリケーションのクローズを利用することによって、あるいはユーザが一種のソフトウェベースのシャットダウンまたはディスコネクトを実行することなどによって実現可能となる。

以下で説明するのは、分散型ストレージシステムと、対応する分散型ストレージマネージメント用に使われ対応するメッセージおよび制御メタデータを含む制御言語とに本発明を適用した事例を説明する簡単なシナリオである。この場合、メッセージパラメータまたは引数としてそれらに含まれている特定の制御メタデータとともに、種々のメッセージまたはタスクが用いられる。表記を容易にするため、メッセージはたとえば以下のようにしてメッセージ名および引数により表現される：

すべてのメッセージは自身に固有のメッセージＩＤ（MessageID）を有しているが、見やすくためこのメッセージＩＤは省略されている。このシナリオは、図８に示した分散型ストレージシステム用のネットワーク（オーナーゾーン Owner Zone）の一例に基づいている。このネットワークは、据え置き型ストレージディバイスまたはノードＳ０〜Ｓ３たとえばＰＤＲ、ＨＤＤ、光ディスクおよびポータブルストレージディバイスまたはノードＰによって構成されている。各ノードＰ、Ｓ０〜Ｓ３はアプリケーションを実行することができ、これにはユーザインタフェースまたは別個のディバイスまたはノードとみなすこともできるリモートコントロール装置を設けることができる。ホームネットワークに対する可能な拡張として、チューナ／レシーバディバイス（たとえばＤＶＢ−ＳまたはＤＶＢ−Ｃ）、ＡＶディスプレイ／出力ディバイス、インターネットアクセス用のＡＤＳＬモデムまたはゲートウェイ等を挙げることができる。ここで例示されているシナリオの場合、分散型ストレージシステムと対話するために一般に１つのノードＳ０が用いられる。このシナリオの場合、容量制限がありネットワーク内の記憶容量をバランスよく利用するケースで、ユーザがコンテンツをコピーしようとしている。初期状態では、ノードＳ０〜Ｓ３，Ｐから成るネットワークがアクティブで稼働しており、コンテンツ伝送は行われておらず、すべてのノードはアイドル状態である。ユーザはＰに格納されているコンテンツをストレージディバイスＳ１，Ｓ２，Ｓ３のいずれかにコピーしようとしている。コンテンツは、最も空き記憶容量の大きい据え置き型ディバイスにコピーされる。

ユーザは所望のコンテンツ部分をサーチするためにディバイスＳ０を利用する。この場合、ディバイスＳ０はサーチリクエストメッセージをネットワーク内のすべてのディバイスへ送信する。ディバイスＰはメッセージを受信し、そこにコンテンツが含まれていることを検出してＳ０に応答する。ただしこのシナリオに対する変形実施形態として、コンテンツのサーチおよびコピーのタスクを開始するためにディバイスＰをＳ０の代わりに用いることができる。このケースでは、ノードＰはリクエストにマッチしたコンテンツに関するリプライを自身には送信せず、ノードＰは対応する情報を自身のコンテンツデータベースから受け取ることになる。

ユーザはどの据え置き型ストレージディバイスであろうとコンテンツを格納するつもりであるため、自身の記憶容量および伝送キャパシティについてディバイスＳ１，Ｓ２，Ｓ３に問い合わせるためにディバイスＳ０が用いられる。Ｓ１，Ｓ２，Ｓ３はそれらのディバイスのケイパビリティに関してＳ０に通知し、つまり自由に利用可能である十分な伝送レートをそれらのディバイスすべてが使える状態にあることをＳ０に通知する。この場合、ディバイスＳ１に対しては空き記憶容量の制限が観測されているのに対し、ディバイスＳ３は最大空き容量があることを示している。したがってディバイスＳ０はディバイスＰに対しディバイスＳ３へコンテンツを伝送するよう要求し、したがってこれによりネットワーク内でよくバランスのとれたかたちで記憶容量を利用することができるようになる。対応するデータ伝送完了後、ディバイスＰはディバイスＳ３にメッセージを通知する。コンテンツのレコーディング後、ディバイスＳ３はディバイスＳ０に対しうまく完了したことを通知する。

ネットワーク内における記憶容量のバランスのとれた利用すなわち各ノード間での記憶スペースのマネージメントとして挙げられるのはたとえば、自由に利用可能な最大伝送レートを呈示しているノードに、あるいはこのシナリオのように最大の絶対的または相対的記憶容量を呈示しているノードに、コンテンツ部分をレコーディングすることである。ネットワーク内の複数のストレージディバイスを１つの「モノリシックブロック monolithic block」とみなすことができ、そこではユーザはそれらのディバイスを区別する必要がない。ただしバランスのとれた記憶容量の利用は、ネットワーク内の記憶容量をマネージメントするための１つの可能なやり方にすぎない。たとえば容量制限が存在するケースなどでコンテンツをコピーする場合に、これ以外のストラテジも同様に適用することができる。

このシナリオでは、一例として挙げた以下のメッセージシーケンスが生じる：すべてのメッセージには、送信側と受信側に関する識別子と、個々のメッセージタイプに特有のパラメータが含まれている。

ここでは、ユーザは所定のタイプのコンテンツ部分たとえば"Octopussy"という題名の映画をサーチしたいものとする。ユーザの入力の結果として、ディバイスＳ０は以下のサーチリクエストをすべてのディバイスに送信し、その際、Ｓ０はＳ２に関していくつかの事前の知識があるという理由から、あるいは殊にＳ２に関心があるので、Ｓ０は特にＳ２に対しメッセージを送信する。

すべてのディバイスは、タスクＩＤ（TaskID）の関係およびタスクに関連するパラメータを一時的に記憶し、自身のデータベースをサーチする。この場合、要求されたコンテンツ部分をディバイスＰが見つけ、したがってディバイスＰは以下のメッセージをディバイスＳ０に送り戻す。

「すべての」受信側はContentInfoRequest("search")メッセージでアドレッシングされているので、ある受信側がリクエストにマッチしたコンテンツを見つけなければ、そのリクエストに対し受信側が応答する必要はないが、ディバイスＳ２は例外である。なぜならばディバイスＳ２は明受信側である明示されているからである。したがってディバイスＳ２は、自身が所望のコンテンツを所有しているか否かについて、リクエストに対し応答しなければならない。ディバイスＳ２はしばらくの間、自身のデータベースをサーチする必要があり、サーチを開始するときに以下のメッセージをディバイスＳ０に送信する。

この場合、ディバイスＳ２は要求されたコンテンツ部分を見つけない。ディバイスＳ２は「応答しなければならない」受信側としてContentInfoRequest("search")メッセージでアドレッシングされているので、ディバイスＳ２内で所望のコンテンツが見つからなかったにもかかわらず、このディバイスは以下のメッセージをディバイスＳ０へ送り戻す。

ユーザはサーチしているコンテンツを、すべてのサーチプロセスが完了する前に見つける可能性がある。したがってユーザはＳ０に対し、以下のメッセージを用いてサーチプロセスをキャンセルさせることができる。

このメッセージを受信した後、すべてのディバイスは自身のサーチプロセスを停止する。ディバイスＳ２は「応答しなければならない」受信側としてContentInfoRequest("search")メッセージでアドレッシングされているので、CancelTaskRequest("search")リクエストの受領確認としてディバイスＳ２は以下のメッセージをディバイスＳ０へ送り戻す。

ContentInfoResponseメッセージをディバイスＳ０に送信した後、ノードＰとＳ２はタスクＩＤおよび関係するパラメータを自身のテンポラリメモリから削除する。同じことはCancelTaskResponseメッセージを送信したすべてのディバイスについてあてはまる。

この場合、ユーザはサーチ結果に満足し、ディバイスＳ０はこのときリクエストメッセージをディバイスＳ１，Ｓ２，Ｓ３に送信して、それらのディバイスのケイパビリティについて問い合わる。その目的は、それらの空き記憶容量および自由に利用可能な伝送レートを取得することにある。ディバイスＳ１，Ｓ２，Ｓ３は、自身のディバイスケイパビリティについてディバイスＳ０に通知することによって応答する。

択一的に、ディバイスＳ０は以下のようなRequestDeviceCapabilityメッセージをこれら３つのすべてのノードに送信することができる。

ディバイスＳ０は、ディバイスＳ１，Ｓ２，Ｓ３の空き容量および自由に利用可能な伝送レートを評価する。ディバイスＳ１は十分な空き記憶容量をもっていないのに対し、ディバイスＳ３は最大容量を呈示している。

ネットワーク内の据え置き型ストレージディバイスの記憶容量をバランスよく利用する目的で、ディバイスＳ０はコンテンツをＰからレコーディングするために、ユーザの対話を必要とすることなく自動的にディバイスＳ３を選択し、伝送を実行するようディバイスＳ３とＰに要求する。このシナリオに対する変形例として考えられるのは、１つの受信側が省かれ、メッセージがすぐにスタートすることである。

このケースでは、ノードＰに対しInitiateTransferRequestの送信が許可されるのは、必要とされるリソースをノードＰにおいて利用できるときだけである。

このメッセージによって要求されるのは、ノードＰのロケーションにあるコンテンツ部分をノードＳ３に伝送し、そこに記録することである。コンテンツＩＤ（ContentID）は、ノードＰにおけるコンテンツ部分のロケーションを特定するＵＵＩＤである。タスクＩＤ（TaskID）はＵＵＩＤであり、これはたとえば関与するディバイスのノードＩＤと、伝送すべきコンテンツのロケーションと、タスクが開始された時点とに基づき定義することができる。ディバイスＰおよび／またはディバイスＳ３がそれらのFreeTransferRate（自由に利用可能な伝送レート）によればその時点で過度にビジー状態であるとしならば、それらはInitiateTransferResponse("denied"）メッセージ（伝送応答開始「拒否」）をディバイスＳ０に送信することになり、ついでＳ０によりCancelTaskRequest messageメッセージがディバイスＰとディバイスＳ３に送信されることによりタスクがキャンセルされ、それらのディバイスはCancelTaskResponseメッセージをディバイスＳ０に送ることにより返答する。あるいはレコーディングの再トライが以降の時点で行われることになるか、またはDeviceCapabilitiesInformationメッセージから得られるUntil（いつまで）に従いAfter（以降）パラメータを利用して、レコーディングがスケジューリングされることになる。

上述のメッセージ受信後、ディバイスＳ３およびディバイスＰはリクエストに対し受領確認を行い、個々のリソースを割り当てる。この場合、ユーザは自身が管理する所定の人員グループに、自身で定義した"John's James Bond friends"というラベルでコンテンツのコピーに対するアクセスの許可を与えたい望んでおり、それ相応にＳ０に命令する。

TransferPurpose（伝送目的）パラメータの値は"Record"（レコーディング）であるため、デスティネーションノードＳ３はデータ転送プロセスをコントロールすることになる。ついで（またはAfter（以降）パラメータに従いそれよりもあとで）ディバイスＳ３はディバイスＰに対し、個々のコンテンツデータを自身へ送信するよう要求する。

ディバイスＰはディバイスＳ３からの要求を受け取り、要求されたコンテンツとともに以下の応答メッセージをディバイスＳ３へ送信し、これによってディバイスＰからディバイスＳ３へのコンテンツデータ伝送がスタートする。

ディバイスＳ３は次にＳ０に対しレコーディングプロセスの開始について通知し、これによってユーザに対し以下のことを知らせることができる。

ディバイスＳ３は（ForwardDataRequestメッセージによりスタートさせる）伝送を制御するので、ディバイスＳ３はTransferStatusInformation(“starting”)メッセージ（伝送ステータス情報「スタート」）をディバイスＳ０へ送信する。ディバイスＰがデータ伝送を完了すると、このディバイスは以下の情報メッセージをディバイスＳ３へ送信し、これによりすべてのデータが伝送完了したことの確認が出される。このメッセージを受け取らなかったならば、ディバイスＳ３はそのことを、たとえば強制的にディバイスが切断されたなど何らかの理由で伝送が完了しなかったことの合図として用いることができる。

ディバイスＳ３はレコーディングを完了し、レコーディングがうまく完了したことについて以下の情報メッセージをディバイスＳ０へ送信し、これによりそのことをユーザに通知することができる。

ディバイスＰおよびディバイスＳ３は自身のリソースの割り当て解除を行い、こんどはディバイスＳ０がユーザに対し、伝送タスクがうまく完了したことについて通知する。

コンフリクトまたはボトルネックの発生する可能性があり、それらを制限しなければならないあらゆるネットワーク分野に対し、本発明を適用することができる。一例として挙げられるのはピア・ツー・ピア・テクノロジーをベースとするネットワークであり、たとえばOwnerZone（オーナーゾーン）またはUniversal Plug and Play (UPnP)テクノロジーなどである。

十分な帯域幅で２つのリアルタイムストリーミング伝送が行われるシナリオを示す図 不十分な帯域幅で２つのストリーミング伝送が行われるシナリオを示す図 リアルタイムストリーミング伝送およびそれと同時にファイル伝送が行われるシナリオを示す図 一方の伝送タスクの明示的プライオリティが変更された状況で２つのファイル伝送が行われるシナリオを示す図 最初に要求された伝送の前に２番目に要求された伝送がスタートする状況で２つのファイル伝送について示す図 ２つのファイル伝送について後者のファイル伝送がサーチタスクからそのプライオリティを継承する様子を示す図 本発明による方法のフローチャートである。 キャパシティ制限があるケースでコンテンツのコピーに関する１つのシナリオを例示した図

Claims (13)

1. ネットワーク内のデータ伝送に対しプライオリティを割り当てる方法において、
   第１のノードが第１のリクエストを送信し、該第１のリクエストには特定のデータユニットまたはデータユニットタイプの指示を含み、該指示は１つまたは複数のデータユニットに対応づけられたマークを表し、
   少なくとも１つの第２のノードが前記第１のリクエストを受け取って分析し、
   該第２のノードは、要求されたデータユニットを提供できることを検出して、要求されたデータユニットを提供できることを表す第１のメッセージを前記第１のノードに送信し、
   第１のノードは該第１のメッセージを受け取って選択し、
   第１のノードは、特定のデータユニットの伝送を要求する第２のリクエストを少なくとも第２のノードに送信し、第１のノードは第１のリクエストおよび／または第２のリクエストに対し、第１のプライオリティに対応する識別子を割り当て、
   第２のノードは、前記第１のプライオリティに対応する識別子を評価し、該識別子に基づき第２のプライオリティを計算し、該計算された第２のプライオリティには、第１レイヤと第２レイヤの部分的プライオリティが含まれており、前記第１レイヤの部分的プライオリティは要求されたデータ伝送タイプに依存し自動的に定義され、第２レイヤの部分的プライオリティはユーザまたはアプリケーションにより定義され、要求されるデータ伝送タイプには少なくともレコーディング、プレイバック、リアルタイムストリーミング伝送および非リアルタイム伝送が含まれ
   前記第２のノードは、前記第２のリクエストの受信に応じて特定のデータユニットを第１の伝送において送信し、該第１の伝送に対し前記計算された第２のプライオリティが割り当てられることを特徴とする、
   ネットワーク内のデータ伝送に対しプライオリティを割り当てる方法。
2. 請求項１記載の方法において、
   ネットワーク内のリクエストおよび／またはデータ伝送に割り当てられたプライオリティに対応する前記識別子を評価し、最初に第１レイヤの部分的なプライオリティを比較し、該第１レイヤの部分的プライオリティが等しければ第２レイヤの部分的プライオリティを比較することを特徴とする方法。
3. 請求項１または２記載の方法において、
   第１のノードが前記第１のリクエストにタイムスタンプを割り当てるステップと、
   第２のノードが第２のプライオリティを計算するため該タイムスタンプを評価するステップ
   を有することを特徴とする方法。
4. 請求項１から３のいずれか１項記載の方法において、
   前記第２のノードは、
   前記第２のリクエストの受信に応じて、前記タイムスタンプの時刻と現在時刻との差を計算するステップと、
   該差を規定値と比較するステップと、
   該差が前記規定値よりも小さければ第１のアルゴリズムを選択し、さもなければ該第１のアルゴリズムとは異なる第２のアルゴリズムを選択するステップと、
   選択されたアルゴリズムに従い第２のプライオリティの値を計算するステップ
   を実行することを特徴とする方法。
5. 請求項１から４のいずれか１項記載の方法において、
   前記第２のノードは、別のノードからのおよび／または別のノード宛の別のリクエストを受け取ってスケジューリングし、該別のリクエストに割り当てられたプライオリティを検出し、該別のリクエストにより前記ネットワークにおいて別の伝送が生じ、
   前記第２のノードは該別の伝送の前、該別の伝送の間または該別の伝送の後、検出されたプライオリティと計算されたプライオリティに依存して、前記第１の伝送をスタートさせることを特徴とする方法。
6. 請求項１から５のいずれか１項記載の方法において、
   前記第１の伝送と前記別の伝送を同時に実行するために十分なリソースが利用できない場合、
   前記２つの伝送の第１レイヤプライオリティを比較するステップと、
   前記第１の伝送の第１レイヤプライオリティが前記別の伝送の第１レイヤプライオリティよりも高ければ、または双方の第１レイヤプライオリティが等しくかつ前記第１の伝送の第２レイヤプライオリティが前記別の伝送の第２レイヤプライオリティよりも高ければ、前記第１の伝送をスタートさせるステップと、
   さもなければ、前記第１の伝送がリアルタイム伝送であるとき該第１の伝送を遅延させ、または前記第１の伝送が非リアルタイム伝送であれば該第１の伝送をスタートさせ、残されたリソースを利用可能にするステップ
   を有することを特徴とする方法。
7. 請求項１から６のいずれか１項記載の方法において、
   ユーザまたはアプリケーションは前記第２レイヤのプライオリティを変更可能であるが第１レイヤのプライオリティは変更不可能であることを特徴とする方法。
8. 請求項１から７のいずれか１項記載の方法において、
   実行中の伝送は中断できないことを特徴とする方法。
9. 請求項１から８のいずれか１項記載の方法において、
   第２のノードは複数の第１のリクエストを受信可能であり、該複数の第１のリクエストに対し複数の第１のメッセージによって応答可能であり、該第１のメッセージはそれぞれ個々の対応する第１のリクエストのタイムスタンプに従い連続的に順序づけられていることを特徴とする方法。
10. ネットワークノードにおいて、
    第１のノードが送信側であり特定のデータユニットであることを表す第１のリクエストを受信して分析する手段と、
    要求されたデータユニットに対し前記ネットワークノードが応じられることを検出する手段と、
    該ネットワークノードが要求されたデータユニットを供給できることを表す第１のメッセージを前記第１のノードに送信する手段と、
    特定のデータユニットの伝送を要求する第２のリクエストを受信する手段と、
    前記第１のリクエストに対応づけられた第１のプライオリティを評価する手段と、
    該第１のプライオリティに基づき第２のプライオリティを計算する手段が設けられており、該第２のプライオリティには、第１レイヤと第２レイヤの部分的プライオリティが含まれており、前記第１レイヤの部分的プライオリティは、リクエストまたはデータ伝送のタイプに依存して自動的に定義され、前記第２レイヤの部分的プライオリティはユーザまたはアプリケーションにより定義され、リクエストまたはデータ伝送のタイプには少なくともレコーディング、プレイバック、リアルタイムストリーミングおよび非リアルタイム伝送が含まれており、
    前記第２のプライオリティを前記特定のデータユニットの伝送に割り当てる手段と、
    前記第２のリクエストの受信に応じて特定のデータユニットを伝送する手段が設けられていることを特徴とする、
    ネットワークノード。
11. 請求項１０記載のネットワークノードにおいて、
    リクエストおよび／またはデータ伝送に割り当てられたプライオリティを評価する手段が設けられており、該評価手段は、最初に第１レイヤの部分的プライオリティを比較し、該第１レイヤの部分的プライオリティが等しければ第２レイヤの部分的プライオリティを比較することを特徴とするネットワークノード。
12. 請求項１０または１１記載のネットワークノードにおいて、
    第２のプライオリティを計算するためにタイムスタンプを評価する手段が設けられており、該第２のプライオリティはタイムスタンプが古ければ古いほど高く、
    前記第２のリクエストの受信に応じて、前記タイムスタンプの時刻と現在時刻との差を計算する手段と、
    該差を規定値と比較する手段と、
    該差が前記規定値よりも小さければ第１のアルゴリズムを選択し、さもなければ該第１のアルゴリズムとは異なる第２のアルゴリズムを選択する手段と、
    選択されたアルゴリズムに従い前記第２のプライオリティの値を計算する手段が設けられていることを特徴とするネットワークノード。
13. 請求項１０から１２のいずれか１項記載のネットワークノードにおいて、
    ユーザ、アプリケーションまたは他のネットワークノードからのリクエストを受信する手段と、
    計算されたプライオリティを該リクエストに応じて変更する手段が設けられていることを特徴とするネットワークノード。

Images