client_recommendation

ユーザーに推奨されること

導入
安定したGnutellaNet環境を推進するために、広く使われるようになる前にすべてのクライアントは最小限の機能を実装しなければならない。この節ではその最小限の機能はどんなものなのかを概観する。

GnutellaNetクライアントがこれらのガイドラインを遵守することは絶対に必要というわけではないが、そのように実装することはGnutellaコミュニティーの最大の利益になる。この節では例としてだけではなく機能実装の例をも紹介する。

この節で議論されている事柄あるいは新しい事柄に関して何かあればGnutellaDev Client Requirement Groupの議論に参加して下さい。

Flood とスパムの防止機構
簡潔に言うと、floodとスパムの防止機構は絶対に必要である。floodとスパムの防止機構無く使用されるあらゆるクライアントはGnutellaNetの安定を脅かす悪いクライアントや悪いユーザやSkr1pt kiddi3zに対する増幅器になりうる。

Flood 防止機構
Flood防止機構は未定の時間内に全く同じパケットが送られてこないか接続を監視することから取りかかる。

スパム防止機構
スパム防止機構は受信したGnutellaNetのメッセージを簡単に評価することからはじめる、もっと詳しい情報はメッセージの妥当性の節を参照してください。

スパム防止機構は開発者がそうしようと思うだけ複雑になりうる。１接続毎に時間に基づいたパケット型の分析はよく設計されたスパムを発見するのに非常に効率的になりうる。

メッセージの経路選択
十分なルーティング機能がなければ、クライアントはとんでもない程の不必要なトラフィックを発生してしまう。効率的なルーティングはクライアントが目撃するだろうパケットの複製の数を減らし帯域幅全体の使用量を減少させる。

GnutellaNetに悪影響をもたらしている貧弱なルーティングのよい例が今日そこらじゅうを通過しているpushリクエストのレベルに見られる。Gnutella 0.56 はpushリクエストをルーティングせず、すべての開いている接続にブロードキャストしている。このことは本来のQuery Hits (0x81)メッセージを考慮していない不必要な経路にPush Requests (0x40) を送ることになる。Pongs (0x01)とQuery Hits (0x81)を除くと、Pushリクエストは現在のGnutellaNetのトラフィックの60%以上を占めると見積もられている。

メッセージ妥当性検証規則
あるパケットを受け取った後にクライアントが最初に行うべきことはメッセージの妥当性を検証することである。

確定的なものではないが以下にいくつかの妥当性検証規則がある。クライアントの設計や議論のためのたたき台として使ってください。

HOPS と TTL
GnutellaクライアントにHOPSとTTLを管理する規則を使用させることは安定し効率的なGnutellaNetを維持するのに必要なことである。ハードコーディングされたTTLの最大値が7であるとすると妥当性評価は以下のように仮定する。以下の妥当性評価は仕様的にふさわしく、そのようにコーディングされるべきである。TTLの最大値7はGnutellaNetのセクションに濃密に相互接続されているクライアントにより広くさらされる機会を提供するように決定された。GnutellaNetが改善され、さらに星状になれば、段階的により低いTTL値になる可能性がある。

評価アクション説明
Hops > 7 メッセージをボツにするこのメッセージは既にTTLの最大値7を超過してしまっている。
TTL > 50 メッセージをボツにするこのメッセージはスパムの疑いがある、あるいはTTLのバグをもった古いクライアントからブロードキャストされている。
TTL > 7 かつ TTL <= 50 TTL = 7 ユーザがTTLを設定できるいくつかのクライアントがあり、8から50までの値は熱心なユーザのものである可能性もあるので、ボツにしてしまうよりは値を7まで低下させなさい。
TTL + Hops > 7 TTL = 7 - Hops そのTTL値をTTLの最大値7にするように再調整しなさい。

ペイロード識別子
以下のペイロード識別子のみが有効である。もしこのリストに載っていないペイロード識別子を持つパケットを受信したら、それはボツにすべきである。もし20以上の無効な識別子をある接続から受け取ったら、その接続は切断すべきである。その接続を切断するまで20までは容認することにより、hopメッセージをマネージメント機能のために現行のプロトコルに追加する能力が残される。

識別子 (Function Code) 説明
0x00 Ping
0x01 Pong (Ping への応答)
0x40 Push
0x80 Query
0x81 Query Hits (Query への応答)

パケットのサイズ
どのくらいの大きさのパケットになると大きすぎるのだろう？GNUTELLA/0.4プロトコルはペイロードサイズのために4バイト最大4,294,967,296バイトのペイロードまでを許容する。明らかにこのことはGnutellaNetをダメにしてしまうようなあまりにも大きいパケットの余地を残していて制限を施したクライアントが使用される必要がある。現在GnutellaNetを回っている最大のパケットはQuery Hits (0x81)である。

Ping - 0x00 ペイロード識別子
ペイロード長固定 0 バイトのみ
Pingメッセージは0バイトのペイロード長を持つべきである。もしそれがペイロード長を持っていたら、スパムかお粗末に書かれたクライアントなのでそのメッセージを破棄しなさい。

Pong - 0x01 ペイロード識別子
ペイロード長固定 14 バイトのみ
Pongメッセージは14バイトのペイロード長を持つべきである。それより大きかたり小さかったりするペイロードはスパムかそのことを遵守してないお粗末なクライアントである。もしそれが14バイトでなければ破棄しなさい。

Push - 0x40 ペイロード識別子
ペイロード長固定 26 バイトのみ
Push リクエストは26バイトのペイロード長を持つべきである。それより大きかったり小さかったりするペイロードサイズはスパムかプロトコルの仕様を遵守しないお粗末なクライアントである。もしペイロードが26バイトでなければPushリクエストを破棄しなさい。

Query - 0x80 ペイロード識別子
ペイロード長変数最大 257 バイト
Queryメッセージ内の検索基準フィールドは理論的なペイロード長がヘッダのペイロードフィールドで許される最大値(4,294,967,296バイト)にできるように終端にnullが付いている。255バイトより長い検索基準をもQueryは何らかのスパムかクライアントのエラーである。もし257バイトより大きかったり小さかったりするQueryメッセージがあれば破棄しなさい。

Query Hits - 0x81 ペイロード識別子
ペイロード長変数最大 67,075 バイト
Query Hitsメッセージは理論的にはそのメッセージヘッダ中のペイロード長フィールドで許されている4,294,967,296にまで大きくなりうる。ファイル名毎に255バイトの最大値を許可すると263バイトを消費する。そのメッセージヘッダがと67,075バイトのペイロードの最大値を生成するペイロードが返って来るべくファイル名に255という最大値許可している。Queryメッセージの長さに67,075バイトまで許容するというのは極端に寛容であり、それより大きないかなるメッセージも破棄しなさい。

目録

このページはJnutella.org メンバーによって運営されています

不都合は、members@jnutella.org　までよろしくお願いしますm(_ _)m