|
|
| ■■■ jnudev
> プロポーザル > Monaco Proposal |
| ■■■ここでは、gPulpで出されたプロポーザル及び、Jnutellaが独自に出した、今後出していくプロポーザルを記載していく。 |
 gPulpで出されたプロポーザルの翻訳はカワサキが主に行った．不具合はカワサキまで
カワサキ
kawasaki@jnutella.org
XXXXxxxxx． |
|
Gnutella
NG Monaco Proposal 14/04/2000
コメントはこちらLambla@bouygtel.com
Monaco Proposalは、次世代のプロトコルについてのアイディアを詳述しています。
このシステムのゴールは以下の通りです。（順不同）
--分散ネットワークの全般的な不可の軽減
--分散ネットワークへ落とす、遅い接続に対する方法の提示
--未来の増大を見込んだ慎重性のあるメカニズムの提供
--ネットワークをスケーラブルにする
意味について
メッセージ：メッセージはバイナリヘッダーとペイロードです
ペイロード：メッセージの中身です
ファンクション：バイナリヘッダー内のメッセージのタイプを定義づけるバイトです
サーバント：Gnutellaのプロトコル-コンプライアント(compliant)のエージェントを定義します
このバイトはフォームOxnnにより表現されます
メッセージの名前
Function 0x00: PING
Function 0x01: PONG
Function 0x80: QUERY
Function 0x81: QUERY REPLY
Function 0x40: PUSH
“古い”プロトコルについて
現在のプロトコルを完全に変えたい人々と話して、彼らはASCIIを使いたいかまたは、IRCを使いたいかという目的のために、古いプロトコルを破壊するという意味において、すべての作業は実際に行われました
考えるに、この新しいプロトコルの成功のためには、我々はすでに実装されたものをベースにプロトコルを作り出していくべきでしょう。
プロトコル変更の提案：
接続：相互接続ネットワークに基づくヒエラルキー（階層構造）
互いのサーバントは、スピードクラス(SC)で合図をしあいます。幾つかのSCは以下のようにして定義されるべきです：
モデム
DSL / Cable
T1
これはただの例なのですが、しかし４又は５個のSCは定義されるべきです。サーバントは決定します、何がそのクライアントのSCなのか、彼の接続から決定します。
サーバントの接続をAlice、そしてホストをBobと名づけましょう。Aliceが
Bobと接続したときに、彼女は彼のSCをチェックします。もし彼女自身が持つSCと等しいか又は上位にあれば、現状の接続を保ち、接続を認めます
Carolineという名の三番目のサーバントがAliceに接続します。Aliceは接続を認めます。AliceはCarolineのSCをチェックします。Carolineがケーブルモデムの使用を楽しんでいるときには、そしてAliceは唯一のモデムユーザーとして、Aliceは次のようなことを決定します。つまり、AliceがCarolineに繋がっているべきではなく、彼女がその接続よりもより早い他のホストを見つけるべきであるということをです。これらすべての通信がCarolineとAliceの間には存在し、こうして分散ネットワークにはブロードキャストがされなくてすむようになります。
Aliceは、Carolineに彼女自身が持つホスト、（それはここにBobがいるというものだが）、のアドレスをTTLが１であるというメッセージを付けて送ります。そのメッセージは、リダイレクトコネクション(REDIRECT
CONNECTION)と名づけられていて、BobのSCフラグを含んでいます。BobがADSL接続であるとして、Carolineはその時にBobへの接続を決定します。
こうして、分散ネットワークへの接続はなお大変易しいものであり、誰もが誰からもアクセスできますが、進行中のある種のヒエラルキーは存在します。それは“バックボーン”を自動的に生成するというものです。
そして次に：
そして我々がホストへの催促の接続とてサーバントをモデムSCを定義し、すべてのインカミングの接続を受け入れますが、より早い接続におけるほかのサーバントへの再分配も行います。
この際には、ネットワークは接続間で負担を再分配すべきです。以下の例を見てください：
今何故Bobはすべてを集結すべきで(Alice、Daphne、Eloise、Francois)、CarolineはDamienだけと繋がっているべきなのでしょうか？
これはRC(Redirect Connection)メッセージの面白い部分です。BobとCarolineは両方とも次のことを知っています。それは、自分たちがどれだけたくさんのモデムユーザーを、次の段落で詳細される通信プロセスによって、ホストしているかということをです。今、Bobが一人のユーザーを選んだとして、Francoisだとしましょう、彼にRCを送ります。Francoisはその時、自動的にCarolineに接続し、結果同じSCのホストを横断した多くのサーバントの共有が行われます。
これは、我々に新しいメッセージをもたらしています、私はこれをSCワイドメッセージ(SCW)と名づけました。Aliceが新しいモデムユーザーをホストしている場合、彼女はBobに対してSCWでそのことを伝えます。するとBobは、彼女が現在3人のモデムユーザーをホストしていることが分かります。次にもしBobに対して4つめのモデムユーザーが接続してきた場合、彼はAliceに対して
その接続をリダイレクトしようとはしないということです。
分散ネットワーク内にあまりに多くのSCWは存在できるのでしょうか？互いのSCサーバントはまさにユーザーの共有をしていて、他のものもまったく同様です。
そこには、たくさんありすぎるということはなく、ゆえに過剰な接続の大半が抑制されるということになります。
それでは分散ネットワークは私が提案している3つのSC、3つのT1接続、9つのケーブル／ADSL接続、32のモデムユーザーを持つようになるのでしょうか？
今ネットワークはヒエラルキー(階層構造)で、スケーラブルで、かつ分散しています。しかし、また改善の余地はありそうです。
今のメッセージの振る舞いを修正する
まず最初に、メッセージはコントロールバイトを用いて始まるべきであり、または終わるべきです。これにより、パーサーはソケットの流れの中でメッセージがいつ始まり、いつ終わるのかを知ることができるのです。
メッセージの終わりで、我々は、互いのメッセージにおいての転送エラーを見つけ出し、価値のないエラーを無くす、ハッシュを提供するかもしれない。
Ping / pong メッセージ
以前私が提案したヒエラルキーシステムを用いると、クライアントが接続をするために他のホストを見つける手間が省けることになりますし、もし必要であれば接続のあるホストによって広告を出します。そして、仮にこの特徴が必要とされていれば、我々は応答を得るためにPingをだすという情報のリクエストの概念を削り落とすべきです。というのは、メッセージの数が、ネットワークに接続されたサーバントの数とともに、指数関数的に増えているためです。
毎回n分ごとに送信される、拡張PONGメッセージだけが存在すべきで、それだけが今日と同じ情報をもつネットワークを越えてブロードキャストを行う。そしてクライアントは、n+1分ごとにブロードキャストしなかったサーバに対しての確認要求を削除すべきです。
Query / Query response （クエリー／クエリー応答）
クエリー／クエリー応答は、今日行われているような形では働くべきではありません。もし、クエリーが、分散ネットワークに対してブロードキャストされるべきでなら、クエリー応答は放射点(emission
point)に戻るようにされるべきです。そして、それがどのように動くべきかという私のアイディアはこうです：
Aliceはクエリーメッセージを送ります、そのメッセージはGUIDと共に、DNを横断してブロードキャストされます。互いのサーバントは、特定のサーバントは特定のGUIDを送るということを覚えます。そして、Aliceが必要としている特定のファイルを見つけるように遠方のコンピュータに指示を出します。それは新しいGUIDによってクエリー応答を作り出すべきであり、新しいGUIDは元のメッセージのGUIDを持つメッセージにreply-to-flagを付け加えます。その際にクエリー応答を得ている互いのサーバントは、新しいGUIDを元のメッセージを送ったサーバントに向けて送り返します。このようにして、クエリー応答はすべてのDNに必要以上にブロードキャストしないようになります。
何故クエリー応答は、元のGUIDだけを持つべきではないのでしょうか？明らかに、互いのGUIDは、世界的に一意であるべきで、そのためサーバントは既知のGUIDを持つメッセージを、それを分析することなく、落とすことができます。ということは、ヘッダーに最初の16ビットのGUIDをチェックするよりも、機能を分析する方が常に時間がかかります。
ファイルのダウンロードの効率は、クエリー応答でのファイルのハッシュ(MD5、CRC、その他)を提供することによって、最終的には高められます。これによって、幾つかのサーバントが同じファイルを持っているときに、マルチパートで効率的にダウンロードされることが可能になります。ハッシュは、二つのファイルが同じ物であることを確認させる唯一の方法です。
リクエスト要求とファイアウォールアクセス
まだ議論の最中です。私は本当に、まったくこのトピックについては分かりません。
モデムユーザーを代理する
これらのシステムを使うことでいっそう、我々は、モデムから検索の要求を代理することで、帯域幅の要求を最大化でき、そしてPONGメッセージを代理します。
モデムをホスティングしている互いのサーバントは、 共有され、キャッシュされているファイルのリストを受け取ることになります。そしてクエリーはホストに到着したときに、モデムサーバントにたいして返答を返します。
同様に、モデムサーバントのファイルは 、ホストサーバントのPONGメッセージで送られることになります。それではまるでそれが同じファイルシステムであるかのように作用します。モデムユーザーは、彼らからの別の接続に対してのリダイレクトとは別に彼らはIncomingの接続を受け取っておらず、ネットワークにおいて知られる必要もありません。
|
|
|
