Warum Gnutella gut skaliert

Vielleicht haben Sie in einigen (fast schon antiken) Texten oder auf verschiedenen technischen Webseiten gelesen, dass ein Netzwerk wie Gnutella nicht skalieren könne, also nur bis zu einer bestimmten Zahl an Nutzern noch laufen würde. Als Gegendarstellung möchte ich ihnen zeigen, warum Gnutella heute sehr gut skaliert.

In früheren Versionen (bis zu 0.4) war Gnutella ein reines Broadcast-Netzwerk. Das heißt, dass jede Suchanfrage jeden Teilnehmer erreicht hat, so dass die Anzahl von Suchanfragen die jeden Knoten erreichen würde in einem idealen Netzwerk exakt gleich der Anzahl von abgeschickten Anfragen gewesen wäre, die alle Knoten im Netzwerk zusammen abschicken. Bei diesem alten Modell können Sie leicht sehen, wieso es nicht skalieren kann.

Aber das galt nur für Gnutella 0.4.

In der aktuellen Version von Gnutella (Gnutella 0.6), ist es nicht länger ein reines Broadcast-Netzwerk. Stattdessen wird nur noch der kleinste Teil der Netzwerklast durch Broadcast-Anfragen verursacht.

Wenn Sie genaueres über die Methoden nachlesen wollen, mit denen das bewerkstelligt wird, können Sie im GnuFU Leitfaden fündig werden (Deutsch, Englisch).

Hier möchte ich die Informationen auf die drei Kernaussagen begrenzen,

1. Dass es zwei Arten von Knoten gibt: Ultrappeers, die mit vielen anderen Ultrapeers verbunden sind (aktuell etwa 32) und vor allem Nachrichten weiterleiten und Blätter, die mit bis zu 5 Ultrapeers Kontakt haben (jeder Ultrapeer hat etwa 32 Blätter), die ihnen die Last der Suchen abnehmen, und vor allem Inhalte anbieten,
2. Dass die ersten zwei Schritte einer Suchanfrage durch Dynamische Anfragen (Dynamic Querying: DQ) abgehandelt werden, das Suchanfragen stoppt, sobald es genügend Quellen gefunden hat (auf die Art wird eine Suche gestoppt, sobald sie mindestens 250 Ergebnisse brachte), und
3. Dass die letzten zwei Schritte durch das Anfragen-Lenkungs-Protokoll (Query Routing Protocol: QRP) geführt werden, das sicherstellt, dass eine suchanfrage nur solche Quellen erreicht, die die Datei auch wirklich haben können (was meistens nur etwa 5% der Knoten sind).

In heutiger Zeit ist Gnutella also ein recht strukturiertes und sehr flexibles Netzwerk.

Um es weiter hochzuskalieren können Ultrapeers die Zahl ihrer Verbindungen über die aktuellen 32 hinaus erhöhen, wodurch Dynamische Anfragen (DQ) und das Anfragen-Lenkungs-Protokoll (QRP) noch ein gutes Stück effizienter werden.

Im Fall von DQ werden die meisten Anfragen nach verbreiteten Dateien nach der gleichen Zahl von angefragten Knoten gestoppt werden, also wird eine Erhöhung der Zahl der Verbindungen pro Knoten die Netzwerklast, die durch die ersten beiden Schritte von Anfragen nach verbreiteten Dateien verursacht wird, in keiner Weise erhöhen.

Im Fall von QRP werden Suchanfragen immernoch nur die Knoten erreichen, die passende Dateien haben können, und wenn Ultrapeers jeweils mit mehr Knoten verbunden sind (indem die Zahl der Verbindungen erhöht wird), kann jede einzelne Verbindung mehr Ergebnisse liefern, so dass DQ sogar früher stoppen wird als mit weniger Verbindungen pro Ultrapeer.

Hiermit ist Gnutella heute weit von dem Broadcast-Modell entfernt, und eine Erhöhung der Größe des Gnutella Netzwerkes kann seine Effizienz bei der Suche nach verbreiteten Dateien sogar erhöhen.

Bei seltenen Dateien schlägt QRP mit geballter Macht zu, und obwohl DQ wahrscheinlich bei allen direkten Verbindungen anfragen wird, stellt QRP sicher, dass nur solche Knoten erreicht werden, die die Inhalten auch wirklich haben können, und das können weit weniger als 0,1% des Netzes sein.

Hierbei bewirkt eine größere Anzahl von Verbindungen pro Ultrapeer, dass Knoten mit seltenen Dateien effektiv näher bei ihnen sind als vorher, so dass Gnutella auch für seltene Dateien effizienter wird, wenn die Größe des Netzwerks erhöht wird.

Hieran können Sie sehen, dass Gnutella inzwischen zu einem Netzwerk geworden ist, das für Anfragen über Schlüsselwörter extrem gut skaliert, so dass es auch für Suchen nach Metadaten und ähnlichen Konzepten sehr effizient genutzt werden kann.

Das Einzige, was Gnutella nicht gut kann, sind Suchen nach Zeichenketten, die nicht in einzelne Wörter geteilt werden können (zum Beispiel Datei-Hashes), weil dadurch QRP zusammebricht, daher werden sie wahrscheinlich kaum Knoten erreichen. Für diese Arten von Suchen arbeiten die Gnutella Programmierer an einem DHT (Distributed Hash table: Verteilte Hashtabelle), das nur für diese Arten von Zeichenketten genutzt werden wird.

Und damit ist das einzige verbleibende Problem der Spam, weil dadurch die Wirksamkeit von DQ für Suchen nach seltenen Dateien eingeschränkt wird (es kommen Antworten, die nicht sofort von sinnvollen Antworten unterschieden werden können), aber ich bin sicher, dass die Entwickler auch einen Weg finden werden, um Spam zu stoppen (zum Beispiel das Netzwerk nochmal zu vergrößern, weil dadurch die Kosten von effektivem Spammen steigen). Und selbst mit Spam ist Gnutella sehr effizient und verbraucht nur sehr wenig Bandbreite, wenn Sie als Blatt (Leaf) im Netz sind.

Ein paar Daten zum Abschluss:

• Netzwerklast im Blatt-Modus: etwa 1kB/s wenn Sie ausgehende und eingehende Last addieren, also nur etwa 1/7 der Bandbreite eines 56k Modems.
• Netzwerklast im Ultrapeer-Modus: Etwa 7kB/s, ausgehend und eingehend addiert, also etwa eine komplette DSL Leitung oder etwa 1/8 der ausgehenden Bandbreite eines aktuellen DSL-Modems (und weitaus weniger von seiner Leistung für Downloads, da die bei DSL sehr viel größer ist als die Leistung für Uploads).

Viel Spaß mit Gnutella!

— 15:29, 22. Nov 2006 (CET) —

Anmerkung: Dieser Leitfaden ignoriert, dass Suchanfragen nicht nur bei den Quellknoten Last verursachen, sondern auch bei den Leitungsknoten dazwischen. Da diese Leitungsknoten nur etwa 3% des Netzes ausmachen und davon nochmal nur 3% von einer Anfrage nach einer seltenen Datei erreicht werden, also die Last nur auf etwa 0,1% der Knoten entsteht (QRP auf den letzten beiden Schritten), wird davon die Gesamtrechnung allerdings kaum berührt.