Ping Pong Schema

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