Ping Pong Schema - Revision history

Arnold at 14:25, 5 February 2006

2006-02-05T14:25:28Z

Arnold at 17:32, 4 February 2006

2006-02-04T17:32:26Z

Arnold at 17:26, 4 February 2006

2006-02-04T17:26:54Z

← Older revision		Revision as of 17:26, 4 February 2006
Line 11:		Line 11:
	Das Ping Pong Schema besteht aus drei Teilen:<br>		Das Ping Pong Schema besteht aus drei Teilen:<br>
	<br>		<br>
			[[Pong Begrenzung\|Pong Begrenzung]]
	==Pong Begrenzung==		==Pong Begrenzung==
	*:Pong sollte nur gesendet werden (1):		*:Pong sollte nur gesendet werden (1):
Line 41:		Line 42:
	nur im Notfall verwenden		nur im Notfall verwenden
	enthalten auch Pongs, mit denen keine Verbindung aufgebaut werden kann		enthalten auch Pongs, mit denen keine Verbindung aufgebaut werden kann

			<br>
			[[Gnutella\|zurück zum Index]]

Arnold at 17:24, 4 February 2006

2006-02-04T17:24:09Z

← Older revision		Revision as of 17:24, 4 February 2006
Line 10:		Line 10:
	<br>		<br>
	Das Ping Pong Schema besteht aus drei Teilen:<br>		Das Ping Pong Schema besteht aus drei Teilen:<br>
			<br>
	*Pong Begrenzung:		==Pong Begrenzung==
	*:Pong sollte nur gesendet werden (1):		*:Pong sollte nur gesendet werden (1):
	:wenn Servent nicht hinter Firewall		:wenn Servent nicht hinter Firewall

Arnold at 17:23, 4 February 2006

2006-02-04T17:23:19Z

← Older revision		Revision as of 17:23, 4 February 2006
Line 17:		Line 17:
	:wenn (1) beachtet wird, reichen 10 Pongs, aber welche?		:wenn (1) beachtet wird, reichen 10 Pongs, aber welche?
	:Bei Pongs mit niedrigem Hopcount ist es wahrscheinlicher, dass die Servents noch mit Gnet verbunden sind, aber ein hoher Hopcount ist nützlicher um den Horizont zu erweitern		:Bei Pongs mit niedrigem Hopcount ist es wahrscheinlicher, dass die Servents noch mit Gnet verbunden sind, aber ein hoher Hopcount ist nützlicher um den Horizont zu erweitern
	:Lösung: erster Pong mit Hopcount 1, ..., letzter Pong mit Hopcount 10 ~~>br>~~		:Lösung: erster Pong mit Hopcount 1, ..., letzter Pong mit Hopcount 10
	<br>		<br>
	*Pong Caching:		*Pong Caching:
	Pong Begrenzung ~~löst~~ noch nicht Problem von zuviel gesendeten Pings		*:Durch die Pong Begrenzung wird noch nicht das Problem von zuviel gesendeten Pings gelöst. Zwei aufeinander folgende Pings werden den gleichen Effekt im Gnet auslösen.
			*:Daher:
	zwei aufeinander folgende Pings werden gleichen Effekt ausnutzen
	~~cachen~~ der neusten Pongs ~~Vermeidung~~ des Broadcastings von Pings		:cachen der neusten Pongs und dadurch Vermeidung des Broadcastings von Pings
	Pong-Cache alle 3 Sekunden aktualisieren (mit TTL von 5-7)		:Pong-Cache alle 3 Sekunden aktualisieren (mit TTL von 5-7)
	~~ensteht~~ dadurch nicht noch mehr Netzwerkverkehr?		*:Ensteht dadurch nicht noch mehr Netzwerkverkehr?
	~~nein;~~ Ergebnis von Analysen: Pings ~~zum~~ ~~aktualisieren~~ von Pong-Caches ~~werden~~ meistens mit Pongs aus Pong-Caches beantworten		*:Nein. Ergebnis von Analysen zu dieser Implementation ergaben, dass die Pings zur Aktualisierung von Pong-Caches meistens mit Pongs aus Pong-Caches beantworten werden!
			<br>
	Ping Multiplexing:		*Ping Multiplexing:
	wenn mehrere Pings schnell hintereinander ankommen und noch kein Pong-Cache vorhanden:
			*:Wenn mehrere Pings schnell hintereinander ankommen und noch kein Pong-Cache vorhanden ist, werden die Pings bisher trotzdem per Broadcast weitergeleitet und erzeugen dadurch unnötigen Traffic im Gnet. Dies kann vermieden werden, wenn Multiplexing verwendet wird:
	Broadcast der Pings
		⚫	:Pings nicht sofort beanworten
	Vermeidung durch Multiplexing:
		⚫	:mehrere Pings zu einem zusammenfassen
⚫	Pings nicht sofort beanworten
		⚫	:beim Senden der Pongs drauf achten, dass auf alle Pings geantwortet wird (vorher GUID speichern)
⚫	mehrere Pings zu einem zusammenfassen
⚫	beim Senden der Pongs drauf achten, dass auf alle Pings geantwortet wird (vorher GUID speichern)
	Beachten von alten Clients:		Beachten von alten Clients:
	Begrenzung der eingehenden Pings		Begrenzung der eingehenden Pings

Arnold at 17:10, 4 February 2006

2006-02-04T17:10:55Z

← Older revision		Revision as of 17:10, 4 February 2006
Line 9:		Line 9:
	*Fairness: wenn User Ping sendet, wird Pong garantiert<br>		*Fairness: wenn User Ping sendet, wird Pong garantiert<br>
	<br>		<br>
	Das Ping Pong Schema besteht aus drei Teilen:		Das Ping Pong Schema besteht aus drei Teilen:<br>
	Pong Begrenzung:		*Pong Begrenzung:
	Pong nur ~~senden~~ (*):		*:Pong sollte nur gesendet werden (1):
	~~wenn~~ Servent nicht hinter Firewall		:wenn Servent nicht hinter Firewall
	~~eingehende~~ Verbindungen akzeptiert		:eingehende Verbindungen akzeptiert werden
	~~nur~~ begrenzte Anzahl an Pongs weiterleiten		*:Nur begrenzte Anzahl an Pongs weiterleiten
	~~wenn~~ (*) beachtet wird, reichen 10 Pongs, aber welche?		:wenn (1) beachtet wird, reichen 10 Pongs, aber welche?
			:Bei Pongs mit niedrigem Hopcount ist es wahrscheinlicher, dass die Servents noch mit Gnet verbunden sind, aber ein hoher Hopcount ist nützlicher um den Horizont zu erweitern
	Pong Begrenzung:
	~~bei~~ ~~Pongs~~ mit ~~niedrigem~~ Hopcount, ~~wahrscheinlicher~~ ~~daß~~ ~~Servents~~ ~~noch~~ im ~~GNET~~ ~~sind~~		:Lösung: erster Pong mit Hopcount 1, ..., letzter Pong mit Hopcount 10 >br>
			<br>
	hohem Hopcount ist nützlicher um Horizont zu erweitern
		⚫	*Pong Caching:
	erster Pong mit Hopcount 1, ..., letzter Pong mit Hopcount 10
⚫	Pong Caching:
	Pong Begrenzung löst noch nicht Problem von zuviel gesendeten Pings		Pong Begrenzung löst noch nicht Problem von zuviel gesendeten Pings
	zwei aufeinander folgende Pings werden gleichen Effekt ausnutzen		zwei aufeinander folgende Pings werden gleichen Effekt ausnutzen

Arnold at 16:56, 4 February 2006

2006-02-04T16:56:30Z

← Older revision		Revision as of 16:56, 4 February 2006
Line 7:		Line 7:
	*Effizienz: Bandbreite für Pings und Pongs auf ca. 100 Byte/Sec/Verbindung begrenzen		*Effizienz: Bandbreite für Pings und Pongs auf ca. 100 Byte/Sec/Verbindung begrenzen
	*Qualität: wenn User A Pong von User B empfängt, hat B eingehende Verbindungen in den letzten 15 Sekunden akzeptiert		*Qualität: wenn User A Pong von User B empfängt, hat B eingehende Verbindungen in den letzten 15 Sekunden akzeptiert
	*Fairness: wenn User Ping sendet, wird Pong garantiert		*Fairness: wenn User Ping sendet, wird Pong garantiert<br>
			<br>

	Ping Pong Schema besteht aus drei Teilen:		Das Ping Pong Schema besteht aus drei Teilen:
	Pong Begrenzung:		Pong Begrenzung:
	Pong nur senden (*):		Pong nur senden (*):

Arnold at 16:49, 4 February 2006

2006-02-04T16:49:57Z

← Older revision		Revision as of 16:49, 4 February 2006
Line 1:		Line 1:
			Da die alte Ping/Pong Methode mindestens 50% der gesamten Bandbreite des Gnet benötigt und ausserdem viele IP-Adressen aus den Pong-Nachrichten nicht erreichbar sind oder keine keine eingehenden Verbindungen akzeptieren, war es schwierig für neue Servents Verbindungen zum GNET aufzubauen. <br>
	Probleme:

	alte Ping/Pong Methode benötigt mindestens 50% der gesamten Bandbreite des GNET
			Daher wurde bei neuen Version von Gnutella (v0.6) das Ping Pong Schema implementiert. Die Idee hinter dem Schema ist es Pongs zu cachen und nur die besten Pongs zu senden. Dadurch wird ein wesentlich kleinerer Anteil der Bandbreite genutzt. <br>
	viele IP-Adressen aus den Pong-Nachrichten:
			Trotzdem wird die Kompatiblität zu alten Clients bewahrt. <br>
	sind nicht erreichbar
			<br>
	akzeptieren keine eingehenden Verbindungen
			Die Ziele des Schemas sind:
	 schwierig Verbindungen im GNET aufzubauen
		⚫	*Effizienz: Bandbreite für Pings und Pongs auf ca. 100 Byte/Sec/Verbindung begrenzen
	Idee:
		⚫	*Qualität: wenn User A Pong von User B empfängt, hat B eingehende Verbindungen in den letzten 15 Sekunden akzeptiert
	Pongs cachen und nur die besten Pongs senden
		⚫	*Fairness: wenn User Ping sendet, wird Pong garantiert
	wesentlich kleineren Anteil der Bandbreite nutzen

	trotzdem kompatibel zu alten Clients bleiben
	Ziele:
⚫	Effizienz: Bandbreite für Pings und Pongs auf ca. 100 Byte/Sec/Verbindung begrenzen
⚫	Qualität: wenn User A Pong von User B empfängt, hat B eingehende Verbindungen in den letzten 15 Sekunden akzeptiert
⚫	Fairness: wenn User Ping sendet, wird Pong garantiert
	Ping Pong Schema besteht aus drei Teilen:		Ping Pong Schema besteht aus drei Teilen:
	Pong Begrenzung:		Pong Begrenzung:

Arnold at 16:42, 4 February 2006

2006-02-04T16:42:57Z

New page

Probleme:
alte Ping/Pong Methode benötigt mindestens 50% der gesamten Bandbreite des GNET
viele IP-Adressen aus den Pong-Nachrichten:
sind nicht erreichbar
akzeptieren keine eingehenden Verbindungen
 schwierig Verbindungen im GNET aufzubauen
Idee:
Pongs cachen und nur die besten Pongs senden
wesentlich kleineren Anteil der Bandbreite nutzen
trotzdem kompatibel zu alten Clients bleiben
Ziele:
Effizienz: Bandbreite für Pings und Pongs auf ca. 100 Byte/Sec/Verbindung begrenzen
Qualität: wenn User A Pong von User B empfängt, hat B eingehende Verbindungen in den letzten 15 Sekunden akzeptiert
Fairness: wenn User Ping sendet, wird Pong garantiert
Ping Pong Schema besteht aus drei Teilen:
Pong Begrenzung:
Pong nur senden (*):
wenn Servent nicht hinter Firewall
eingehende Verbindungen akzeptiert
nur begrenzte Anzahl an Pongs weiterleiten
wenn (*) beachtet wird, reichen 10 Pongs, aber welche?
Pong Begrenzung:
bei Pongs mit niedrigem Hopcount, wahrscheinlicher daß Servents noch im GNET sind
hohem Hopcount ist nützlicher um Horizont zu erweitern
erster Pong mit Hopcount 1, ..., letzter Pong mit Hopcount 10
Pong Caching:
Pong Begrenzung löst noch nicht Problem von zuviel gesendeten Pings
zwei aufeinander folgende Pings werden gleichen Effekt ausnutzen
cachen der neusten Pongs Vermeidung des Broadcastings von Pings
Pong-Cache alle 3 Sekunden aktualisieren (mit TTL von 5-7)
ensteht dadurch nicht noch mehr Netzwerkverkehr?
nein; Ergebnis von Analysen: Pings zum aktualisieren von Pong-Caches werden meistens mit Pongs aus Pong-Caches beantworten
Ping Multiplexing:
wenn mehrere Pings schnell hintereinander ankommen und noch kein Pong-Cache vorhanden:
Broadcast der Pings
Vermeidung durch Multiplexing:
Pings nicht sofort beanworten
mehrere Pings zu einem zusammenfassen
beim Senden der Pongs drauf achten, dass auf alle Pings geantwortet wird (vorher GUID speichern)
Beachten von alten Clients:
Begrenzung der eingehenden Pings
wird bestimmte Rate überschritten, Ping verwerfen
Rate durch Ankunftszeit des letzten Pings bestimmen
alte Clients (Identifizierung über Connect 0.4) sollten nur ein Ping alle 30 Sekunden erhalten, um kein Broadcast auszulösen
Pongs von alten Clients sollten in seperatem Cache behandelt werden
nur im Notfall verwenden
enthalten auch Pongs, mit denen keine Verbindung aufgebaut werden kann

← Older revision		Revision as of 14:25, 5 February 2006
Line 1:		Line 1:
	Da die alte Ping/Pong Methode mindestens 50% der gesamten Bandbreite des Gnet ~~benötigt~~ und ~~ausserdem~~ viele IP-Adressen aus den Pong-Nachrichten nicht erreichbar ~~sind~~ oder ~~keine~~ keine eingehenden Verbindungen ~~akzeptieren,~~ war es schwierig für neue Servents Verbindungen zum GNET aufzubauen. <br>		Da die alte Ping/Pong Methode mindestens 50% der gesamten Bandbreite des Gnet benötigte und außerdem viele IP-Adressen aus den Pong-Nachrichten nicht erreichbar waren oder keine eingehenden Verbindungen akzeptierten war es schwierig für neue Servents Verbindungen zum GNET aufzubauen. <br>

	Daher wurde bei neuen Version von Gnutella (v0.6) das Ping Pong Schema implementiert. Die Idee hinter dem Schema ist es Pongs zu cachen und nur die besten Pongs zu senden. Dadurch wird ein wesentlich kleinerer Anteil ~~der~~ Bandbreite genutzt. <br>		Daher wurde bei der neuen Version von Gnutella (v0.6) das Ping Pong Schema implementiert. Die Idee hinter dem Schema ist, Pongs zu cachen und nur die besten Pongs zu senden. Dadurch wird ein wesentlich kleinerer Anteil an Bandbreite genutzt. <br>
	Trotzdem wird die Kompatiblität zu alten Clients bewahrt. <br>		Trotzdem wird die Kompatiblität zu alten Clients bewahrt. <br>
	<br>		<br>
Line 15:		Line 15:
	*wenn Servent nicht hinter Firewall		*wenn Servent nicht hinter Firewall
	*eingehende Verbindungen akzeptiert werden		*eingehende Verbindungen akzeptiert werden
	Nur begrenzte Anzahl an Pongs weiterleiten		Nur begrenzte Anzahl an Pongs weiterleiten:
	*wenn (1) beachtet wird, reichen 10 Pongs, aber welche?		*wenn (1) beachtet wird, reichen 10 Pongs; aber welche?
	*Bei Pongs mit niedrigem Hopcount ist es wahrscheinlicher, dass die Servents noch mit Gnet verbunden sind, aber ein hoher Hopcount ist nützlicher um den Horizont zu erweitern		*Bei Pongs mit niedrigem Hopcount ist es wahrscheinlicher, dass die Servents noch mit dem Gnet verbunden sind; aber ein hoher Hopcount ist nützlicher um den Horizont zu erweitern.
	*Lösung: erster Pong mit Hopcount 1, ..., letzter Pong mit Hopcount 10		*Lösung: erster Pong mit Hopcount 1, ..., letzter Pong mit Hopcount 10
	<br>		<br>
	==Pong Caching==		==Pong Caching==
	Durch die Pong Begrenzung wird noch nicht das Problem von zuviel gesendeten Pings gelöst. Zwei aufeinander folgende Pings werden ~~den~~ ~~gleichen~~ Effekt im Gnet auslösen.		Durch die Pong Begrenzung wird noch nicht das Problem von zuviel gesendeten Pings gelöst. Zwei aufeinander folgende Pings werden einen sehr ähnlichen Effekt im Gnet auslösen, was das Broadcasten der Pings und das Empfangen der Pongs betrifft.
	Daher:		Daher:
	*cachen der neusten Pongs und dadurch Vermeidung des Broadcastings von Pings		*cachen der neusten Pongs und dadurch Vermeidung des Broadcastings von Pings
	*Pong-Cache alle 3 Sekunden aktualisieren (mit TTL von 5-7)		*Pong-Cache alle 3 Sekunden aktualisieren (mit TTL von 5-7)
	Ensteht dadurch nicht noch mehr Netzwerkverkehr?		Ensteht dadurch nicht noch mehr Netzwerkverkehr?
	Nein. ~~Ergebnis~~ von Analysen zu dieser Implementation ergaben, dass die Pings zur Aktualisierung von Pong-Caches meistens mit Pongs aus Pong-Caches beantworten werden!		Nein. Ergebnisse von Analysen zu dieser Implementation ergaben, dass die Pings zur Aktualisierung von Pong-Caches meistens mit Pongs aus Pong-Caches beantworten werden!
	<br>		<br>
	==Ping Multiplexing==		==Ping Multiplexing==
Line 34:		Line 34:
	*beim Senden der Pongs drauf achten, dass auf alle Pings geantwortet wird (vorher GUID speichern)		*beim Senden der Pongs drauf achten, dass auf alle Pings geantwortet wird (vorher GUID speichern)
	<br>		<br>
	Um alten Clients zu ~~beachten~~ wird die Anzahl der eingehenden Pings begrenzt:		Um die Kompatibilität zu alten Clients zu bewahren wird die Anzahl der eingehenden Pings begrenzt:
	*wird bestimmte Rate überschritten, Ping verwerfen		*wird bestimmte Rate überschritten, Ping verwerfen
	*Rate durch Ankunftszeit des letzten Pings bestimmen		*Rate durch Ankunftszeit des letzten Pings bestimmen
	Alte Clients (Identifizierung über Connect 0.4) sollten nur ein Ping alle 30 Sekunden erhalten, um kein Broadcast auszulösen.		Alte Clients (Identifizierung über Connect 0.4) sollten nur ein Ping alle 30 Sekunden erhalten, um kein Broadcast im Gnet auszulösen.
	Pongs von alten Clients sollten in seperatem Cache behandelt werden:		Pongs von alten Clients sollten in seperatem Cache behandelt werden:
	*nur im Notfall verwenden		*nur im Notfall verwenden
	*enthalten auch Pongs, mit denen keine Verbindung aufgebaut werden kann		*enthalten auch Pongs, mit denen keine Verbindung aufgebaut werden kann!
			<br>

	<br>		<br>
	[[Gnutella\|zurück zum Index]]		[[Gnutella\|zurück zum Index]]

← Older revision		Revision as of 17:32, 4 February 2006
Line 11:		Line 11:
	Das Ping Pong Schema besteht aus drei Teilen:<br>		Das Ping Pong Schema besteht aus drei Teilen:<br>
	<br>		<br>
	[[Pong Begrenzung\|Pong Begrenzung]]
	==Pong Begrenzung==		==Pong Begrenzung==
	*:Pong sollte nur gesendet werden (1):		Pong sollte nur gesendet werden (1):
	:wenn Servent nicht hinter Firewall		*wenn Servent nicht hinter Firewall
	:eingehende Verbindungen akzeptiert werden		*eingehende Verbindungen akzeptiert werden
	*:Nur begrenzte Anzahl an Pongs weiterleiten		Nur begrenzte Anzahl an Pongs weiterleiten
	:wenn (1) beachtet wird, reichen 10 Pongs, aber welche?		*wenn (1) beachtet wird, reichen 10 Pongs, aber welche?
	:Bei Pongs mit niedrigem Hopcount ist es wahrscheinlicher, dass die Servents noch mit Gnet verbunden sind, aber ein hoher Hopcount ist nützlicher um den Horizont zu erweitern		*Bei Pongs mit niedrigem Hopcount ist es wahrscheinlicher, dass die Servents noch mit Gnet verbunden sind, aber ein hoher Hopcount ist nützlicher um den Horizont zu erweitern
	:Lösung: erster Pong mit Hopcount 1, ..., letzter Pong mit Hopcount 10		*Lösung: erster Pong mit Hopcount 1, ..., letzter Pong mit Hopcount 10
	<br>		<br>
	*Pong Caching:		==Pong Caching==
	*:Durch die Pong Begrenzung wird noch nicht das Problem von zuviel gesendeten Pings gelöst. Zwei aufeinander folgende Pings werden den gleichen Effekt im Gnet auslösen.		Durch die Pong Begrenzung wird noch nicht das Problem von zuviel gesendeten Pings gelöst. Zwei aufeinander folgende Pings werden den gleichen Effekt im Gnet auslösen.
	*:Daher:		Daher:
	:cachen der neusten Pongs und dadurch Vermeidung des Broadcastings von Pings		*cachen der neusten Pongs und dadurch Vermeidung des Broadcastings von Pings
	:Pong-Cache alle 3 Sekunden aktualisieren (mit TTL von 5-7)		*Pong-Cache alle 3 Sekunden aktualisieren (mit TTL von 5-7)
	*:Ensteht dadurch nicht noch mehr Netzwerkverkehr?		Ensteht dadurch nicht noch mehr Netzwerkverkehr?
	*:Nein. Ergebnis von Analysen zu dieser Implementation ergaben, dass die Pings zur Aktualisierung von Pong-Caches meistens mit Pongs aus Pong-Caches beantworten werden!		Nein. Ergebnis von Analysen zu dieser Implementation ergaben, dass die Pings zur Aktualisierung von Pong-Caches meistens mit Pongs aus Pong-Caches beantworten werden!
	<br>		<br>
	*Ping Multiplexing:		==Ping Multiplexing==
	*:Wenn mehrere Pings schnell hintereinander ankommen und noch kein Pong-Cache vorhanden ist, werden die Pings bisher trotzdem per Broadcast weitergeleitet und erzeugen dadurch unnötigen Traffic im Gnet. Dies kann vermieden werden, wenn Multiplexing verwendet wird:		Wenn mehrere Pings schnell hintereinander ankommen und noch kein Pong-Cache vorhanden ist, werden die Pings bisher trotzdem per Broadcast weitergeleitet und erzeugen dadurch unnötigen Traffic im Gnet. Dies kann vermieden werden, wenn Multiplexing verwendet wird:
	:Pings nicht sofort beanworten		*Pings nicht sofort beanworten
	:mehrere Pings zu einem zusammenfassen		*mehrere Pings zu einem zusammenfassen
	:beim Senden der Pongs drauf achten, dass auf alle Pings geantwortet wird (vorher GUID speichern)		*beim Senden der Pongs drauf achten, dass auf alle Pings geantwortet wird (vorher GUID speichern)
			<br>
	Beachten von alten Clients:
	~~Begrenzung~~ der eingehenden Pings		Um alten Clients zu beachten wird die Anzahl der eingehenden Pings begrenzt:
	~~wird~~ bestimmte Rate überschritten, Ping verwerfen		*wird bestimmte Rate überschritten, Ping verwerfen
	~~Rate~~ durch Ankunftszeit des letzten Pings bestimmen		*Rate durch Ankunftszeit des letzten Pings bestimmen
	~~alte~~ Clients (Identifizierung über Connect 0.4) sollten nur ein Ping alle 30 Sekunden erhalten, um kein Broadcast auszulösen		Alte Clients (Identifizierung über Connect 0.4) sollten nur ein Ping alle 30 Sekunden erhalten, um kein Broadcast auszulösen.
	Pongs von alten Clients sollten in seperatem Cache behandelt werden		Pongs von alten Clients sollten in seperatem Cache behandelt werden:
	~~nur~~ im Notfall verwenden		*nur im Notfall verwenden
	~~enthalten~~ auch Pongs, mit denen keine Verbindung aufgebaut werden kann		*enthalten auch Pongs, mit denen keine Verbindung aufgebaut werden kann

	<br>		<br>