Ping Pong Schema: Difference between revisions
No edit summary |
No edit summary |
||
| 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): |
|||
*wenn Servent nicht hinter Firewall |
|||
*eingehende Verbindungen akzeptiert werden |
|||
Nur begrenzte Anzahl an Pongs weiterleiten |
|||
*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 |
|||
*Lösung: erster Pong mit Hopcount 1, ..., letzter Pong mit Hopcount 10 |
|||
<br> |
<br> |
||
==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. |
|||
Daher: |
|||
*cachen der neusten Pongs und dadurch 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 zu dieser Implementation ergaben, dass die Pings zur Aktualisierung von Pong-Caches meistens mit Pongs aus Pong-Caches beantworten werden! |
|||
<br> |
<br> |
||
==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: |
|||
*Pings nicht sofort beanworten |
|||
*mehrere Pings zu einem zusammenfassen |
|||
*beim Senden der Pongs drauf achten, dass auf alle Pings geantwortet wird (vorher GUID speichern) |
|||
<br> |
|||
Beachten von alten Clients: |
|||
Um alten Clients zu beachten wird die Anzahl der eingehenden Pings begrenzt: |
|||
*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 |
Pongs von alten Clients sollten in seperatem Cache behandelt werden: |
||
*nur im Notfall verwenden |
|||
*enthalten auch Pongs, mit denen keine Verbindung aufgebaut werden kann |
|||
<br> |
<br> |
||
Revision as of 17:32, 4 February 2006
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.
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.
Trotzdem wird die Kompatiblität zu alten Clients bewahrt.
Die Ziele des Schemas sind:
- 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
Das Ping Pong Schema besteht aus drei Teilen:
Pong Begrenzung
Pong sollte nur gesendet werden (1):
- wenn Servent nicht hinter Firewall
- eingehende Verbindungen akzeptiert werden
Nur begrenzte Anzahl an Pongs weiterleiten
- 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
- Lösung: erster Pong mit Hopcount 1, ..., letzter Pong mit Hopcount 10
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. Daher:
- cachen der neusten Pongs und dadurch 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 zu dieser Implementation ergaben, dass die Pings zur Aktualisierung von Pong-Caches meistens mit Pongs aus Pong-Caches beantworten werden!
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:
- Pings nicht sofort beanworten
- mehrere Pings zu einem zusammenfassen
- beim Senden der Pongs drauf achten, dass auf alle Pings geantwortet wird (vorher GUID speichern)
Um alten Clients zu beachten wird die Anzahl der eingehenden Pings begrenzt:
- 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