Diskussion:Gnutella

message: Wundert es denn hier keinen, dass ein dezentrales Netzwerk keine Instanz hat, in der eine Liste steht, unter welcher IP sich noch andere Clients finden lassen?! 
Bei edonkey etc. gibt es ja immer eine feste Liste an bekannten Servern, aber ein dezentrales Netzwerk hat ja sowas nicht... wie finden sich also die Clients? Wird einfach wie wild nach draußen gepingt, und geschaut, wer antwortet? Allein das suchen von Clients würde ja gigantischen Traffic verursachen.
Danke, --Abdull 22:35, 24. Feb 2005 (CET)

message: Ist der Abschnitt Nachfolger nicht hoffnungslos veraltet ? Die dort beschriebene Designschwäche bezieht sich meines Erachtens nach auf das alte Gnutella/0.4 was heute längst durch Gnutella/0.6 abgelöst ist, in welchem z.B. Techniken wie TigerTree-Hashes oder QRP genau das ermöglichen was dort kritisiert wird.
Darüber hinaus ist Kademlia ein ganz anderes Netz und steht in keiner Verbindung zu Gnutella, kann daher also auch nicht dessen Nachfolger sein.
Ich plädiere daher dafür, den Abschnitt entweder ganz zu streichen oder die Änderungen korrekt und vollständig unter Entwicklung zu dokumentieren.
Vorschläge ?
:Das mit Kademlia stimmt im Prinzip schon auch wenn da offiziell zur Zeit nichts passiert. QRP ist eigentlich nur ein Zwischenschritt, aber für die Suche nach exakten Dateien (z.B. per SHA1) will man eigentlich Kademlia (oder ähnliches) verwenden. Evtl. entsteht aus Gnutella in Zukunft ein Hybrid-Netzwerk. Im Übrigen haben Napster und Gnutella ja auch wenig bis nichts gemein, aber trotzdem ist/war/ist Gnutella (ein) Nachfolger von Napster. --195.62.99.203 23:04, 2. Jun 2005 (CEST)
replies: text: LimeWire wird jetzt speziell für die Suche nach Hashes wohl ein Kademlia-Derivat einführen. Leider gibt es noch keine Dokumentation dazu. Damit werden die Stärken beider Netze kombiniert: Gnutella: Suche nach Wörtern/Text, Kademlia: Suche nach Hashes. --ArneBab 18:51, 10. Jul 2006 (CEST)
thread_title:  Kademlia als Nachfolger von Gnutella ? 

message: Der Hinweis "keine Ad- oder Spyware" mach irgentwie verdächtig... Margay 18:03, 15. Mai 2005 (CEST)
replies: text: Ich habe die Liste mal aufgeräumt und den Quatsch entfernt, da völlig fehl am Platz. Anscheinend haben einige die Liste auch mit einer Rangliste verwechselt. --195.62.99.203 22:57, 2. Jun 2005 (CEST)

text: Danke, gute Arbeit. Wie wäre es mit einem festen Account? Margay 20:07, 10. Jun 2005 (CEST)
thread_title:  Clients 

message: Ich würde den folgenden Teil noch einfügen: 
In den letzten Jahren wurde das Gnutella-Netzwerk allerdings deutlich weiterentwickelt, so dass die effiizienz deutlich erhöht werden konnte. Beispiele hierfür sind das QRP, mit dem Quellen sich austauschen, welche Dateien sie haben, so dass auf den letzten beiden Schritten die Anfragen nur noch an diejenigen weitergeleitet werden, die möglicherweise antworten können, und dynamische Suchanfragen, wodurch nicht alle benachbarten Systeme auf einmal angefragt werden, sondern nur so viele, bis genügend Suchergebnisse erhalten wurden (etwa 250). Gemeinsam reduzieren diese beiden Mechanismen die Netzwerklast um über 90%. 
Genauere Infos habe ich allgemeinverständlich in http://de.gnufu.net geschrieben. 
Statistiken von LimeWire und Bearshare haben gezeigt, dass QRP die benötigte Bandbreite um etwa 80-90% reduziert hat (Quelle: BearShare im GDF), während Dynamic Querying (dynamische Suchanfragen) etwa 90% ausmachen (Quelle: LimeWire im GDF).--ArneBab 18:51, 10. Jul 2006 (CEST)
thread_title: Technik

message: Welche Schwächen sind hier gemeint? 
Ohne genauere Angabe ist diese Aussage wertend, nicht informierend. 
Den Bereich, für den es erstellt wurde, kann Gnutella nämlich sehr gut: Nach Schlüsselwörtern suchen. Nur die Suche nach einem Hash-key ist ineffizient (da die internen Optimierungen, QRP und Dynammic Querying, dabei nicht greifen: Ein Hash hat keine erkennbaren Muster, nach denen der User suchen kann, und es gibt die Datei oft nur bei wenigen Usern, so dass effektiv immer das gesamte Netz durchsucht werden muss). 
Bei der Suche nach Schlüsselwörtern greifen die beiden mechanismen allerdings und sorgen für gute Skalierbarkeit. Dass Downloads auch genügend Quellen haben wrd übder das Download-Mesh sichergestellt, bei dem sich die herunterladenden und sharer gegenseitig weitere Quellen mitteilen, so dass ein BitTorrent-Effekt entsteht, ohne dass ein Server nötig wäre.--ArneBab 18:51, 10. Jul 2006 (CEST)
replies: text: Wenn ein Netzwerkknoten ausfällt, dann ist er weg. Das kann kein Protokoll verhindern, wohl aber redundante Hardware. Die "Ausfallsicherheit" (besser Redundanz) bezieht sich auf das Netz als solches. Zudem gibt es keine einzelne exakte Route zwischen zwei Knoten, d.h. fällt ein Nachbar aus, dann gibt es mit hoher Wahrscheinlichkeit noch Routen über die anderen Nachbarn, da jeder Knoten typischerweise mehr als einen Nachbarn hat. --217.87.94.190 19:37, 26. Jun. 2007 (CEST)
thread_title:  konzeptuelle Schwächen? 

message: Ich kann mich dunkel erinnern, dass der Name von einer Nussnougatcreme abgeleitet sei. In der en Wikipedia kann man dazu etwas lesen. Siehe auch bei Heise. 
--Steg (Diskussion) 12:55, 23. Jun. 2013 (CEST)
thread_title:  Namensgebung