あるマルチキャストを示すIDをmulticast_IDとしましょう。Node_ID=multicast_IDとなるノードをノードYとします。ノードYには
{multicast_ID1,[IP_P,IP_Q,IP_R...]}
を格納しています。ただし、IP_Xはマルチキャストの送信先のIPアドレスとします。ノードZがmulticast_IDでマルチキャストしたい場合、ノードYに通信を行います。ノードYはノードZに応じてIP_P,IP_Q,IP_RにP2Pマルチキャストを行うわけです。この方法は、階層化させることでより複雑化することができます。例えば、先ほどのmulticast_ID1の通信先であるノードPに{multicast_ID2,[IP_A,IP_B,IP_C]}とすることができます。
{{name,IP_P},{name,IP_Q},{name,IP_R}....}
コンテンツ名nameを取得したいノードXはノードYにコンテンツ送信要求をするはずです。ではノードYはどのようにしてダウンロード先の最適化を行うのでしょうか？それにはいくつか方法が考えられます。
1)ラウンドロビン
同じコンテンツを保持するノードに対して、順番にダウンロード元になってもらう方法です。実装は簡単ですが必ずしもダウンロード元の負荷が平等に分散されるとは限りません。また遅延や帯域等の影響を考慮していません。
2)最小セッション数
ダウンロード元になりうるノードP、ノードQ、ノードR...は自分が現在ダウンロードをしているセッション数を定期的にノードYに教えます。ノードYはセッション数が一番少ないノードに優先的にダウンロード元になるようにします。この方法ではCPUの負荷についてはラウンドロビンよりも考慮していますが、遅延や帯域の影響を考慮していません。
3)遅延測定方法
ノードYはノードP,Q,R...に対してpingを打ち、遅延時間を測定します。遅延時間が遅いほどネットワーク的には近いと予測できるので、そのノードを優先的にダウンロード元にします。ただし、ダウンロード先とダウンロード元両間の近さは必ずしも保障していません。ストリーム用CDNには有効でしょう。
4)ドメイン調査方法
ノードYはダウンロード元となるノードXについてDNSの逆引きからドメインを知ります。また、ノードYはノードP,Q,R...のドメインについても予め知っているとします。両者のドメインからネットワークの近さについてある程度予測できます。このことよりダウンロード先とダウンロード元両間の遅延時間を最適化することが部分的にできます。このドメインを使った方法は独自のドメインを利用している人などは必ずしも適用できません。
実際には上記の方法を複合的に使い、それらを重み付けするのが一般的だと思われます。本トピックに関心がある方はCDNや負荷分散に関する文献を読まれると良いでしょう。
さて、匿名通信路においてCrowdsという技術があります。これはユーザがプロキシとなり、ユーザ間でランダムにトラフィックを転送して最終的にはWEBにアクセスするということです。このようにすれば、WEBサーバからは誰からWEBにアクセスしたか分かりません。このアイデアを分散ハッシュテーブルで実現させましょう。
ノードXがアクセスしたいURLをurl_1としましょう。Node_ID=hash(url_1)となるノードをノードYとします。ノードXはノードYに対して分散ハッシュテーブルで要求を掛ける時に複数のノードを介するはずです。これらのノードが全てプロキシとなるのです。ですから、ノードYはだれからurl_1にアクセスするように要求されているかわかりません。また異なるURLであるurl_2においてhash(url_1)≠hash(url_2)ですから、URLが違う場合にはWEBにアクセスするノードも、また中間でプロキシとなるノードも異なり、経路も変わるはずです。
もちろん、ノード群が乱数を使ってさらに経路をランダムにさせることも可能です。