Query Routing Protocol - Revision history

Arnold at 14:52, 5 February 2006

2006-02-05T14:52:29Z

← Older revision		Revision as of 14:52, 5 February 2006
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==

Arnold at 14:52, 5 February 2006

2006-02-05T14:52:01Z

← Older revision		Revision as of 14:52, 5 February 2006
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>
			[[Gnutella\|zurück zum Index]]
	<br>		<br>
	==QRP==		==QRP==

Arnold at 14:51, 5 February 2006

2006-02-05T14:51:18Z

← Older revision		Revision as of 14:51, 5 February 2006
Line 7:		Line 7:
	Bsp.: Hashing: good=2, book=5 -> Zusammenfassen zu einem Array: 001001		Bsp.: Hashing: good=2, book=5 -> Zusammenfassen zu einem Array: 001001
	<br>		<br>
	QRP:		==QRP==
	Aufbau der Routing Tabellen:		Aufbau der Routing Tabellen:
	*Array von Nummern		*Array von Nummern
Line 13:		Line 13:
	*unendlich, wenn Datei nicht existiert		*unendlich, wenn Datei nicht existiert
	<br>		<br>
	~~erster~~ Ansatz: Routing Tabellen an jede Verbindung propagieren		Erster Ansatz: Routing Tabellen an jede Verbindung propagieren
	~~braucht~~ aber noch viel Bandbreite		*braucht aber noch viel Bandbreite
	~~Routing~~ Information von Servent X führt noch zu Aktualisierungen im GNET, wenn X schon wieder offline		*Routing Information von Servent X führt noch zu Aktualisierungen im GNET, wenn X schon wieder offline
			<br>
	~~bessere~~ Implementation:		Bessere Implementation:
	nur Leafs senden RTs an Ultrapeer
	~~Ultrapeers~~ ~~propagieren~~ ~~keine~~ Routing Tabellen		*nur Leafs senden Routing Tabellen an Ultrapeer
			*Ultrapeers propagieren keine Routing Tabellen
	~~keine~~ ständigen Aktualisierungen		*keine ständigen Aktualisierungen
	~~Komprimierung~~ der ~~RTs~~ (z.B. mit Huffman Kodierung)		*Komprimierung der Routing Tabellen (z.B. mit Huffman Kodierung)
	QRP:
			<br>
	wann finden Updates statt?
			Wann sollen nun Updates stattfinden?
	~~Idealerweise~~, bei neuen oder beendeten Verbindung, oder bei Änderung der Dateiliste		*Idealerweise, bei neuen oder beendeten Verbindung, oder bei Änderung der Dateiliste
	~~Verbesserung~~: ~~RTs~~ nur propagieren, wenn Verbindung mehrere Minuten bestehen bleibt		*Verbesserung: Routing Tabellen nur propagieren, wenn Verbindung mehrere Minuten bestehen bleibt
	~~Servents~~ sollten immer nur ein Update in T Minuten verschicken		*Servents sollten immer nur ein Update in T Minuten verschicken
⚫	~~bei~~ minimalen Veränderungen im Update:
			<br>
⚫	~~Differenz~~ von alter RT und neuer RT bilden
		⚫	Bei minimalen Veränderungen im Update:
⚫	~~dadurch~~ viele Nullen, lassen sich gut komprimieren
		⚫	*Differenz von alter RT und neuer RT bilden
⚫	nur ein neuer Nachrichtentyp ~~muss zum~~ Gnutella Protokoll hinzugefügt werden: ROUTE_TABLE_UPDATE
		⚫	*dadurch viele Nullen, lassen sich gut komprimieren
			<br>
		⚫	Durch die Implementation von QRP muss nur ein neuer Nachrichtentyp dem Gnutella Protokoll hinzugefügt werden: ROUTE_TABLE_UPDATE
			<br>
			<br>
			[[Gnutella\|zurück zum Index]]

Arnold at 14:45, 5 February 2006

2006-02-05T14:45:45Z

← Older revision		Revision as of 14:45, 5 February 2006
Line 1:		Line 1:
	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.<br>		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.<br>
			Die Idee hinter QRP ist Routing Routing Tabellen für Querys zu benutzen. Dazu werden alle Ressourcen (Dateien) eines Servents in Stichworte aufgeteilt. <br>

		⚫	Bsp.: „goodbook“ ergibt „good“ und „book“
	alle Ressourcen (Dateien) werden in Stichworte aufgeteilt
			<br>
⚫	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. <br>
	Idee:
			Um eine hohe Netzbelastung durch das Propagieren der Stichworte zu vermeiden wird Hashing benutzt und desweiteren werden die Daten noch zusammengefasst.
	Routing Tabellen für Queries benutzen
		⚫	Bsp.: Hashing: good=2, book=5 -> Zusammenfassen zu einem Array: 001001
	Servents propagieren ihre Stichworte an ihre Nachbarn
			<br>
⚫	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:		QRP:
	Aufbau der Routing Tabellen:		Aufbau der Routing Tabellen:
	Array von Nummern		*Array von Nummern
	Nummern geben minimale Distanz zu Datei an		*Nummern geben minimale Distanz zu Datei an
	unendlich, wenn Datei nicht existiert		*unendlich, wenn Datei nicht existiert
			<br>
	erster Ansatz: Routing Tabellen an jede Verbindung propagieren		erster Ansatz: Routing Tabellen an jede Verbindung propagieren
	braucht aber noch viel Bandbreite		braucht aber noch viel Bandbreite

Arnold at 14:31, 5 February 2006

2006-02-05T14:31:06Z

New page

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.<br>

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