Ping Pong Schema
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 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