Query Routing Protocol: Difference between revisions

From
Jump to navigation Jump to search
No edit summary
No edit summary
 
Line 6: Line 6:
Um eine hohe Netzbelastung durch das Propagieren der Stichworte zu vermeiden wird Hashing benutzt und desweiteren werden die Daten noch zusammengefasst.
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
Bsp.: Hashing: good=2, book=5 -> Zusammenfassen zu einem Array: 001001
<br>
<br>
<br>
[[Gnutella|zurück zum Index]]
[[Gnutella|zurück zum Index]]
<br>
<br>
<br>
==QRP==
==QRP==

Latest revision as of 14:52, 5 February 2006

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


zurück zum Index

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 Routing Tabellen an Ultrapeer
  • Ultrapeers propagieren keine Routing Tabellen
  • keine ständigen Aktualisierungen
  • Komprimierung der Routing Tabellen (z.B. mit Huffman Kodierung)


Wann sollen nun Updates stattfinden?

  • Idealerweise, bei neuen oder beendeten Verbindung, oder bei Änderung der Dateiliste
  • Verbesserung: Routing Tabellen 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


Durch die Implementation von QRP muss nur ein neuer Nachrichtentyp dem Gnutella Protokoll hinzugefügt werden: ROUTE_TABLE_UPDATE

zurück zum Index