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.
Die Idee hinter QRP ist Routing Routing Tabellen für Querys zu benutzen. Dazu werden alle Ressourcen (Dateien) eines Servents in Stichworte aufgeteilt.
Bsp.: „goodbook“ ergibt „good“ und „book“
Servents ermitteln die Stichworte aus ihren Dateien und propagieren die Stichworte an ihre Nachbarn. Eine Query-Anfrage wird nur dann weitergeleitet, wenn alle Stichworte bei dem verbundenen Servent existieren.
Um eine hohe Netzbelastung durch das Propagieren der Stichworte zu vermeiden wird Hashing benutzt und desweiteren werden die Daten noch zusammengefasst.
Bsp.: Hashing: good=2, book=5 -> Zusammenfassen zu einem 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