Query Routing Protocol

Um den auch hohen Anteil am Traffic vom Gnet durch das Broadcasten von Querys zu verhindern, wurde bei der neuen Version (v0.6) das Query Routing Protocol implementiert.

alle Ressourcen (Dateien) werden in Stichworte aufgeteilt Bsp.: „goodbook“ ergibt „good“ und „book“ Idee: Routing Tabellen für Queries benutzen Servents propagieren ihre Stichworte an ihre Nachbarn Query-Anfrage wird nur weitergeleitet, wenn alle Stichworte bei dem verbundenen Servent existieren Vermeiden von hoher Netzbelastung durch Hashing und Zusammenfassung Bsp.: good=2, book=5  Array: 001001 QRP: Aufbau der Routing Tabellen: Array von Nummern Nummern geben minimale Distanz zu Datei an unendlich, wenn Datei nicht existiert erster Ansatz: Routing Tabellen an jede Verbindung propagieren braucht aber noch viel Bandbreite Routing Information von Servent X führt noch zu Aktualisierungen im GNET, wenn X schon wieder offline bessere Implementation: nur Leafs senden RTs an Ultrapeer Ultrapeers propagieren keine Routing Tabellen keine ständigen Aktualisierungen Komprimierung der RTs (z.B. mit Huffman Kodierung) QRP: wann finden Updates statt? Idealerweise, bei neuen oder beendeten Verbindung, oder bei Änderung der Dateiliste Verbesserung: RTs nur propagieren, wenn Verbindung mehrere Minuten bestehen bleibt Servents sollten immer nur ein Update in T Minuten verschicken bei minimalen Veränderungen im Update: Differenz von alter RT und neuer RT bilden dadurch viele Nullen, lassen sich gut komprimieren nur ein neuer Nachrichtentyp muss zum Gnutella Protokoll hinzugefügt werden: ROUTE_TABLE_UPDATE