Home


Community


Resources

File Center
Links




Since April 10th, 2000



View Developers' Corner Pages INVITE OTHERS | HELP | FEEDBACK
GUEST LOG IN | JOIN GROUP  
  Back to all pages
開発者のコーナー
Index | Scaling GnutellaNet | Windows GUID and PUSH | Protocol | The Daily Spam

開発 : スケーラビリティー

GnutellaNetを成長させる

Last update: 6 April 2000


洪水用水門を閉じること

疑うまでもなく、GnutellaNetにおける問題はユーザである。 さて、われわれはそのような問題を解決するために十分なことがでず、いまだGnutellaNetは十分に成功したわけではないが、僕らができることはユーザを良い方向に導くことだ。

そして誰が何を言おうと、GnutellaNetはスケーラブルである。そのプロトコルは非常に知的で修正せずに僕らは長いこと使い続けることができる。今のところ、#gnutelladev IRCでトラフィックを緩和しようという議論は多くはなされていない。Gnutellaプロトコルを実装している全てのクライアントは、悪いパケットをネットワークからすぐに取り除くけるように省トラフィック管理の機能を実装しなければならない。

しかし、benhが指摘したように、Gnutellaはさらに巨大なレベルへスケールアップするための何かを必要としている。

ping の洪水を管理すること
すべてのGnutellaクライアントはpingの洪水の罪で有罪だ。毎分ネットワーク上の全てのクライアントはネットワーク上のほかの全てのサーバを発見するためPINGメッセージをブロードキャストする。2000のサーバが存在すると、一分間に4百万の無駄なメッセージが生じる。

実際は、クライアントはネットワークを知ることにそれほど意欲的なわけではない。ネットワークの大部分は他のサーバへ向かうPONGメッセージを聴くことによって発見される。私が理解している範囲では現在のクライアントにすでに実装済みである

また既に実装されているものは、好きなときにいつでもネットワークを発見できる機能である。おそらく起動したときにのみ自動的にネットワークを検出しその後に手動での検出をするようにすればもっと良くなるだろう。そうすればネットワークに溢れるPINGのパケットを大幅に削減することになるだろう。

現在クライアントが実装していない機能で思いつくものはPONGキャッチャーだ。それぞれのクライアントは知っているサーバの全リストに容易に応答できるが、まだそうなってはいない。一見するとこの機能は安全でないと思われるかもしれない。でもそうではない。起きうる最悪のことは間違ったホストが報告されるということだ。いくつかの妥当な応答がある限りひどいことにはならない。 クライアントは間違った応答の数が最小になるように捕まえるPONGの情報をタイムアウトするべきだ。もしクライアントが合理的な数の既知のサーバに応答することができれば、PINGを送るべきではない。そうすればネットワーク上のPINGパケットの数を最小限に抑えることができるだろう。

初心者がクエリースパムをすること
多くのGnutellaユーザは次のような一つあるいはそれ以上の攻撃で有罪である:

  • 頭の悪いクエリーを送ること
  • たくさんの頭の悪いクエリーを送ること
  • チャットするためにクエリー機能を使うこと

    こういったことは全てトラフィックでGnutellaネットワークを潰してしまう。この問題を取り除く簡単な方法がある:

  • ソケット毎一定時間毎にクエリーの数の最大値を設ける。最大値を超えるクエリーの全てに"スパムを止めてください"という応答をしてフォワードしないようにする。
  • 一つのソケットで一定の時間内に複製されたクエリーをボツにする。これでGnutellaNetで他のみんなを邪魔して喜ぶskr1pt kiddiesを防止することができる。
  • 拡張されたASCII文字のクエリーは全てボツにする。(このアイデアはnauserによる)
  • ボツにした方がいい放送禁止用語のリストを決める。 (このアイデアはnauserによる)
  • クエリーの応答をキャッチできるようにする。これはGnutellaNetにとってメリットがあるがどうかわからない。だから僕はやりたいとは思わないしまだ実装されていない機能だ。
  • Skr1pt kiddi3z とパケットの妨害
    オープンなプロトコルの抱える問題は、そのオープンさがskr1pt kiddiesの障壁を劇的に低くしてしまうことだ。僕はそこらじゅうに多くの妨害パケットが走っていると思っている。それらのいくつかは数十キロバイトもの負荷サイズがある。そして僕は60kバイトもの負荷のあるPINGパケットを少なからず見た。うん、もう明らかなんだけど、非ゼロな負荷を持つPINGパケットはボツにすべきだ。プロトコルが示しているように、実体のあるサイズで構成されるべき唯一のパケットはクエリーへの応答だけである。

    さらに、未知の機能を持つすべてのパケットはボツにすべきだ。 これについては様々な異論があると思う、でもメジャーな開発者の了承なしに新しい機能を追加するべきではない。未知の機能を勝手に実装するのはGnutellaの普及を妨げるだけである。

    チャット?
    絶対に実装してはならない機能はチャットである。狂気の惨状にしてはならない:チャットのパケットを送ってはならない。






    Wego.com, Inc., does not claim ownership of or take responsibility for any content on this site.
    There is no warranty or guarantee on anything downloaded from this site.
    Gnutella Website Support