帯域幅障害(bandwidth barrier):
完全分散型であるGnutellaネットワーク上には、帯域幅や処理能力の異なる様々なピアが存在し、複雑なトポロジーを形成しています。それゆえにT3回線のような高速なピアにモデム回線のような遅いピアが挟まった場合、遅いピアはネットワーク上を流れる大量のトラフィックを処理できず、多くのパケットが破棄されてしまいます。そしてネットワークが小さく分断され、検索パフォーマンスが悪化します。この現象を帯域幅障害と呼びます。BearShareやLimeWireといったサーバントは、遅いピアをネットワークの隅に配置します。またブロードバンドノード上で走るClip2 Reflectorのようなスーパーピアは、遅いピアと高速なネットワークの緩衝となりネットワークのトポロジーを効率よくする役割を果たしています。
ブロードキャスト(Broadcasting):
Gnutellaネットワーク上のメッセージは二通りの方法で送信されます。まず、それらはブロードキャスト、つまりあなたのネットワーク地平線（パケット到達領域）のすべてのホストに送信されるかもしれません。Pingと検索リクエストはブロードキャストです。
次に、メッセージは経路選択、つまり特定の場所にだけ送信されるかもしれません。経路選択されたすべてのメッセージが目的の送り先へ直接届くわけではありません。それらは転送中に他のホストを経由するかもしれません、たとえば、Aが検索リクエストをブロードキャストし、Bがそれを受け取ってブロードキャストし、Cがそれを受け取って検索結果で応答するような場合、Cはその検索結果を経路選択してBへ送り返し、今度はBがそれをAへと経路選択します。Pongと検索結果はGnutellaネットワーク上で経路選択されます。Pushリクエストに関しては、それを経路選択するサーバントもあるし、Gnutellaネットワーク上でブロードキャストするサーバントもあります。Pushリクエストをブロードキャストする正当な理由はありません。そして良いサーバントは絶対にPushリクエストをブロードキャストしません。
補足：ZDNETなどがオリジナルGnutella 0.56を配布しているため、GNet上には未だにオリジナルGnutellaが一定割合稼動しているようです。しかし、Gnutella 0.56はpushリクエストをブロードキャストするのでネットワークの健康のためにこれを使用しない方がいいでしょう。
破棄されたパケット(Dropped packets):
パケットすなわち、データの小さな「小包」は時々Gnutellaネットワーク上で破棄されたり、紛失したりします。これにはいくつかの原因がありえます。たとえば、サーバントAはサーバントBが転送してくるデータレートを維持できないかもしれません。あるいは、サーバントBはバグのあるGnutellaクローンを走らせているかもしれません。
ファイヤーウォール(Firewall):
ファイヤーウォールは、その内側のコンピュータだけをファイヤーウォールを通して外のネットワークへ接続を許可するような保護メカニズムです。ファイヤーウォールは外側のコンピュータにネットワーク内の任意のコンピュータへの接続することを許しません。ファイヤーウォールの外側のサーバントがファイヤーウォール内のコンピュータからファイルをダウンロードしようとした場合、ファイヤーウォールはこの接続を妨げます。普通、ファイヤーウォールと通じて接続し、欲しいファイルをアップロードしてくれるようにファイヤーウォールの内側のサーバントへ要請するためにpushリクエストが送信されるでしょう。ファイルを要求したサーバント自身が（別の）ファイヤーウォールの内側にある場合、このアップロードもブロックされてしまい、ファイルを転送する手段はありません。
完全分散型の(fully distributed):
ピアツーピアネットワークの中でも中心が存在しないネットワークのことを指します。完全分散型ネットワークは単一のノードに依存しないので、あるノードがシャットダウンしてもネットワーク全体は全く影響を受けません。
Gnutellaネットワークは、中心が存在しないので完全分散型になります。
Napsterはファイルの転送に関してはピア同士で行われますが、ファイルインデックスを管理する中央のサーバが存在し、検索作業はこの中央のサーバを通して行われます。それゆえに、NapsterのネットワークはハイブリッドP2P(hybrid P2P)と呼ばれます。
GUID:
Global Unique Identifier（地球上で一意の識別子）の短縮形で、GUIDはGnutellaネットワーク上のホストやメッセージを一意に識別するために使われるランダムな文字列です。このおかげでネットワーク上でやりとりされる重複したメッセージを防止できます。
地平線/パケット到達領域(Horizon):
地平線はある一定の時間内にコミュニケートすることのできるGnutellaサーバントの集合です。Gnutellaネットワークの分散化されたその性質上、あなたの地平線は活動的なGnutellaネットワーク全体を包含するわけではありません。
ホップス(hops):
あるパケットが通過したホストの数。
ホスト(Host):
ピア(Peer)を参照してください。
ホストキャッチャー(Host Catcher):
あなたがGnutellaネットワークに参加し、pingリクエストを送信したとき、他のGnutellaホストはpongで応答ます。Gnutellaソフトウェアのホストキャッチャーはpongを送ってきたホストを追跡し続けるので、接続することのできる活動中のGnutellaホストのリストを手に入れることが出来ます。ほとんどのGnutellaサーバントは何らかの自動接続機能を持っています。これらの自動接続は通常ホストキャッチャーが作ったリストによって作られています。
メッセージ(Message):
Gnutellaネットワーク上でやりとりされるすべての情報は、5つのメッセージタイプのうちのどれかです。それはping, pong, 検索リクエスト,検索応答, pushリクエストのどれかです。
補足：実はGNet上には6つのメッセージタイプが存在します。2001年2月に6番目のメッセージタイプであるPongFollowup(0x02)のプロポーザルがGDFで策定されました。このメッセージタイプは、GNet上で度々問題になった帯域幅障害（モデム回線などの遅いノードがGNetのボトルネックになってしまいネットワークのスケーラビリティー向上の妨げになっている問題）を克服しネットワークを効率よく自己組織化するために策定されました。
PongFollowupは、ttl==2&&hops==0のpingに応答する場合とrouter.limewire.comに接続する場合に発行されるメッセージです。Gnutellaプロトコルを構成している各メッセージは以下のようなヘッダ+ペイロードといった構造になっています。
ヘッダ
[メッセージGUID | ペイロード識別子(0x00, 0x01...etc) | TTL | hops | ペイロード長]
ペイロード
ping(0x00) [ペイロードなし] ブロードキャストされる
pong(0x01)
[ポート番号 | IPアドレス | 共有ファイル数 | 共有ファイル合計サイズ(KB)]
ルーティングされる
pong followup(0x02)
[ホストスピード(kbit/s)| 空きincomingスロット数 | incomigスロット数 |ホストの起動時間(min) | サーバント GUID]
query/search request(0x80)
[応答ホストの最低スピード(kbit/s) | 検索文字列+null]
ブロードキャストされる
query hit/search results/QHD(0x81)
[ヒット件数 | ポート番号 | IPアドレス | ホストの速度(kbit/s) | 検索結果集合{ファイルインデックス,ファイルサイズ(Bytes), ファイル名+null+null} | ベンダーコード |オープンデータサイズ | オープンデータ(firewall flag, busy flag) | プライベートデータ | サーバントGUID]
ルーティングされる
push request(0x40)
[サーバントGUID | ファイルインデックス | 自分のIPアドレス | 自分のポート番号]
ルーティングされる
ノード(Node):
ピア(Peer)を参照してください。
ピア(Peer):
二つのコンピュータがお互いにコミュニケートし合い、似たような役割を果たしているような場合、それらはピアであると考えられます。たとえば、あるオフィスのデスクトップコンピュータがオフィス内のメールサーバーとやりとりするかもしれませんが、それらはメールサーバがサーバーの役割をデスクトップコンピュータがクライアントとしての役割を演じているのでピアではありません。Gnutellaのピアツーピアモデルでは、ネットワークは完全にピアで構成されているのでサーバは必要ありません。Gnutellaネットワークへ接続しようとしているコンピュータは「ノード」あるいは「ホスト」を参照します。
ピング(Ping):
新しいユーザがGnutellaネットワークに参加した場合、ユーザは「ping リクエスト」というメッセージをネットワークへブロードキャストして、ネットワークに存在していることを知らせます。このpingを受け取ったノードは、このメッセージをうけっ取ったことを知らせるためにpingしたユーザへpongを送り返します。
ポング(Pong):
Gnutellaネットワーク上のあるノードがpingリクエストを受け取った場合、pong（時々「ping応答」と言及されることもある）で応答します。このpongには、応答したホストのIPアドレスとポート番号と一緒に、そのホストが共有しているファイルの数と合計サイズが含まれています。
ポート(Port):
インターネット上でコミュニケーションを行うコンピュータ上の各アプリケーションには、特定のポート番号が割り当てられています。ほとんどのサーバント上で、Gnutellaのためのデフォルトポートは6346です。これはGnutellaソフトウェアを走らせているサーバントはポート6346を開いていることを意味します。しかし、ユーザは彼のコンピュータのGnutellaに割り当てられたポート番号を変更することができ、ポートを変更しても6346以外のポートを開いている他のサーバントともコミュニケートできるます。
プッシュリクエスト(Push request):
あるサーバントがファイヤーウォール内にある場合、他のホストはファイルをダウンロードするためにサーバントへ直接接続することができません。こういう状況では、ホストはpushリクエストを送り、ファイヤーウォール内のサーバントに外側へ接続を張ってファイルをアップロードしてくれるように依頼して、ファイルをダウンロードしようとします。
ルーティング(Routing):
ブロードキャスト(Broadcasting)を参照してください。
検索(Search):
あるサーバントが検索リクエストを初期化した場合、検索リクエストを発行したサーバントによって指定された最低スピードと検索文字列を含んだ検索メッセージがGnutellaネットワーク上にブロードキャストされます。また、クエリーメッセージとも呼ばれます。
検索結果(Search result):
あるホストが検索結果を受け取り、検索条件を満たすファイルがあった場合、ホストは検索結果メッセージで応答します。検索結果メッセージはファイル名とサイズのリストと一緒に検索結果メッセージを送ってきたサーバントのIPアドレス、ポート番号、スピードを含んでいます。検索結果はクエリーヒットとも呼ばれています。
サーバント(Servent):
サーバーとクライアントの組み合わせです、古い中央集権的なファイル共有モデルでは、サーバーと呼ばれる情報の配給者がおり、クライアントと呼ばれる情報の要求者がいました。分散化されたGnutellaモデルでは、ネットワーク上のコンピュータのそれぞれがサーバーであり、クライアントでもあります、それゆえに「サーバント」と呼ばれるのです。
TTL(Time to Live):
「TTL」と短縮され、Time to Live はメッセージが破棄されるまでにGnutellaネットワーク上で作られるhopsの数をあらわしています。メッセージを見たサーバントは、それぞれそのメッセージのTTLを1だけ減らします。TTLが0になったとき、そのメッセージは破棄されることになります。これは、メッセージがGnutellaネットワーク上であっちこっちでたらめに行き来するのを防止します。ほとんどのGnutellaクローンはTTLを7あたりに設定しており、ユーザが設定を変更できるようになっているものもあります。
