Warum Gnutella gut skaliert - Revision history

89.12.54.153 at 03:21, 23 February 2007

89.12.54.153 — Fri, 23 Feb 2007 03:21:55 GMT

←Older revision		Revision as of 03:21, 23 February 2007



-	Das Einzige, was ~~Knutella~~ 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.	+	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.		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.

ArneBab at 23:11, 9 January 2007

ArneBab — Tue, 09 Jan 2007 23:11:45 GMT

←Older revision		Revision as of 23:11, 9 January 2007

	Aber das galt nur fÃ¼r Gnutella 0.4.		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 ~~Broastcast~~-Anfragen verursacht.	+	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 ([http://de.gnufu.net Deutsch], [http://en.gnufu.net Englisch]).		Wenn sie genaueres Ã¼ber die Methoden nachlesen wollen, mit denen das bewerkstelligt wird, kÃ¶nnen sie im GnuFU Leitfaden fÃ¼ndig werden ([http://de.gnufu.net Deutsch], [http://en.gnufu.net Englisch]).

139.20.64.26 at 13:05, 9 January 2007

139.20.64.26 — Tue, 09 Jan 2007 13:05:55 GMT

←Older revision		Revision as of 13:05, 9 January 2007

	Aber das galt nur fÃ¼r Gnutella 0.4.		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 ~~Borastcast~~-Anfragen verursacht.	+	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 Broastcast-Anfragen verursacht.

	Wenn sie genaueres Ã¼ber die Methoden nachlesen wollen, mit denen das bewerkstelligt wird, kÃ¶nnen sie im GnuFU Leitfaden fÃ¼ndig werden ([http://de.gnufu.net Deutsch], [http://en.gnufu.net Englisch]).		Wenn sie genaueres Ã¼ber die Methoden nachlesen wollen, mit denen das bewerkstelligt wird, kÃ¶nnen sie im GnuFU Leitfaden fÃ¼ndig werden ([http://de.gnufu.net Deutsch], [http://en.gnufu.net Englisch]).

-	Hier mÃ¶chte ich die Informationen auf die Aussage begrenzen, 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 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).	+	Hier mÃ¶chte ich die Informationen auf die Aussage begrenzen, 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 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.		In heutiger Zeit ist Gnutella also ein recht strukturiertes und sehr flexibles Netzwerk.

139.20.64.26 at 13:04, 9 January 2007

139.20.64.26 — Tue, 09 Jan 2007 13:04:54 GMT

←Older revision		Revision as of 13:04, 9 January 2007

	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 lÃ¤ufen wÃ¼rde. Als Gegendarstellung mÃ¶chte ich ihnen zeigen, warum Gnutella heute sehr 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 lÃ¤ufen 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 ~~Boradcast~~-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 Modell kÃ¶nnen sie leicht sehen, wieso es nicht skalieren kann.	+	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 Modell kÃ¶nnen sie leicht sehen, wieso es nicht skalieren kann.

	Aber das galt nur fÃ¼r Gnutella 0.4.		Aber das galt nur fÃ¼r Gnutella 0.4.

ArneBab at 14:41, 22 November 2006

ArneBab — Wed, 22 Nov 2006 14:41:50 GMT

←Older revision		Revision as of 14:41, 22 November 2006

	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 Borastcast-Anfragen verursacht.		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 Borastcast-Anfragen verursacht.

-	Wenn sie genaueres Ã¼ber die Methoden nachlesen wollen, mit denen das bewerkstelligt wird, kÃ¶nnen sie im GnuFU Leitfaden fÃ¼ndig werden ([~~[GnuFU_de\|~~Deutsch]], [~~[GnuFU_en\|~~Englisch]]).	+	Wenn sie genaueres Ã¼ber die Methoden nachlesen wollen, mit denen das bewerkstelligt wird, kÃ¶nnen sie im GnuFU Leitfaden fÃ¼ndig werden ([http://de.gnufu.net Deutsch], [http://en.gnufu.net Englisch]).

	Hier mÃ¶chte ich die Informationen auf die Aussage begrenzen, 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 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).		Hier mÃ¶chte ich die Informationen auf die Aussage begrenzen, 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 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).

ArneBab at 14:40, 22 November 2006

ArneBab — Wed, 22 Nov 2006 14:40:30 GMT

←Older revision		Revision as of 14:40, 22 November 2006

	Viel SpaÃŸ mit Gnutella!		Viel SpaÃŸ mit Gnutella!

-	[[Benutzer:ArneBab\|ArneBab]] 15:29, 22. Nov 2006 (CET)	+	[http://basis.gnufu.net/gnufu/index.php/Benutzer:ArneBab ArneBab] 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).		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).

ArneBab at 14:39, 22 November 2006

ArneBab — Wed, 22 Nov 2006 14:39:43 GMT

←Older revision		Revision as of 14:39, 22 November 2006

-	''Dieser Artikel stammt von [http://gnufu.net GnuFU: Gnutella fÃ¼r Benutzer]. Da Phex das Gnutella-Netzwerk nutzt, scheint er passend ~~zu sein~~.[[User:ArneBab\|Arne]]''	+	''Dieser Artikel stammt von [http://gnufu.net GnuFU: Gnutella fÃ¼r Benutzer]. Da Phex das Gnutella-Netzwerk nutzt, scheint er mir passend.-[[User:ArneBab\|Arne]]''

	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 lÃ¤ufen wÃ¼rde. Als Gegendarstellung mÃ¶chte ich ihnen zeigen, warum Gnutella heute sehr 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 lÃ¤ufen wÃ¼rde. Als Gegendarstellung mÃ¶chte ich ihnen zeigen, warum Gnutella heute sehr gut skaliert.

ArneBab at 14:39, 22 November 2006

ArneBab — Wed, 22 Nov 2006 14:39:21 GMT

New page

''Dieser Artikel stammt von [http://gnufu.net GnuFU: Gnutella fÃ¼r Benutzer]. Da Phex das Gnutella-Netzwerk nutzt, scheint er passend zu sein.[[User:ArneBab|Arne]]''

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 lÃ¤ufen 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 Boradcast-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 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 Borastcast-Anfragen verursacht.

Wenn sie genaueres Ã¼ber die Methoden nachlesen wollen, mit denen das bewerkstelligt wird, kÃ¶nnen sie im GnuFU Leitfaden fÃ¼ndig werden ([[GnuFU_de|Deutsch]], [[GnuFU_en|Englisch]]).

Hier mÃ¶chte ich die Informationen auf die Aussage begrenzen, 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 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 Knutella 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!

[[Benutzer:ArneBab|ArneBab]] 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).