Für mich war ein VPN bisher nur eine "Verschleierung" über irgendeinen Server-Verbund.
Verschleierung ist nichts weiter als z.B. beim surfen das HTTPS statt HTTP, es wird über eine Verschlüsselung mit dem Server kommuniziert. Das hat mit VPN aber nicht viel zu tun, obwohl es ähnliche Mechanismen sind. VPN geht da halt noch einen Schritt weiter und übernimmt das komplette Datenhandling incl der Ver- und Endschlüsselung für den Datenaustausch. Es ist ein Tunnel durch das Internet, bei dem Du mit der Gegenseite verbunden bist, als würde jemand eine unglaublich lange Netzwerkleitung durch diesen Tunnel von Punkt A nach Punkt B legen und Du bist genau an dem Netzwerkkabel angestöpselt.
Für mich waren das jetzt über die Traceroute einfach ein paar Hop' s. Wenn mir einer dieser Hop' s auf dem Weg zum Spielerserver Probleme macht, kann ich diesen durch Nutzung eines VPN überhaupt umgehen?
Theoretisch schon, praktisch aber kaum, es kommt drauf an, wo sich der andere VPN-Punkt sich befindet.
Beispiel Auto:
Wenn Du von Karlsruhe aus nach Frankfurt fährst, dann machst du das über die A5, die zufällig im Kreuz Walldorf eine Riesenbaustelle hat.
Es kann aber auch anders laufen: Walldorf ist komplett dicht, dann lotst Dich Dein Navi über die A6 als Umgehungsstrecke und hast evtl mit den Baustellen dort zu kämpfen. Das nur mal als Beispiel, dass auch dynamisch anders geroutet werden kann.
Gelangst Du aber über einen Autotransporter (=VPN-Kanal) von Karlsruhe nach Köln, fährst Du selbst nur noch über die A3 nach Frankfurt, die Walldorfer Baustelle umgehst Du, musst aber trotzdem die Zeit nach Köln (über die A61 und A1) mit auf Deine Reisezeit Köln=>Frankfurt drauf packen.
Selbst beeinflussen kannst Du Deine Route aber nicht so einfach. Es sei denn, auf dem Spieleserver ist (extra für Dich) eine VPN-Software installiert. dann gehen Deine Spieledaten nur noch vom VPN-Server an den Spieleserver. Da jedoch ist schon der Haken: Der VPN-Kanal ist i.d.R. auch per UDP realisiert, um das ganze nicht zu zäh zu gestalten. Und schon hast du das Problem einfach nur verlagert auf eine andere Netzwerkschicht, die du auch nicht beeinflussen kannst. Kannst du den auf TCP umstellen, hast Du einen langsameren aber robusten Kanal. Das hilft im Grunde genommen aber auch nicht weiter.
Also du bist davon überzeugt, dass Paketverluste zu einem schlechteren Spielerlebnis führen, wogegen eine stärkere Korrektur(oder Verschachtelung), die dazu führt, dass kein(weniger) Paket(e) verloren geht(en), zu einem besseren Spielerlebnis führt? Wird durch ein stärkeres(höheres?) Interleaving nicht automatisch auch eine Verzögerung erzeugt?
Das kann man nicht so pauschal sagen, die Zeit nimmt zu, weil das Interleaving ja mehrere Datenpakete verschachtelt, um dadurch eine bessere Fehlerkorrektur zu bekommen, das benötigt Zeit. Auf der anderen Seite ist ein Paketverlust, also wegen Fehlern verworfene Datenpakete, ab einer bestimmten Größenordnung auch störend. Der Datenfluss wird holperig, die Daten zum Spieleserver und zurück kommen nur noch stotternd an. Was ist besser? Irgendwo ist das immer ein Balanceakt.
Der Datenaustausch mit dem Spieleserver ist grob vereinfach wie folgt:
Du bewegst Deine Spielfigur, zielst, ballerst usw, (nur) diese "Telemetriedaten" werden zum Spieleserver übertragen, und von dort an die anderen Spieler Deiner Partie weiter gegeben. Gleichzeitig erhältst Du die Telemetriedaten der anderen Spieler. Deine Spielesoftware wertet diese aus und Du kannst sehen, wie die anderen Spieler sich bewegen, auf Dich zielen und schießen usw. Mehr ist es im Grunde genommen nicht.
Wenn nun ein einzelner Datensatz der Telemetriedaten wegen Fehlern verloren geht, spielt das keine Rolle, denn der nächste Datensatz kommt direkt im Anschluss und Du siehst max. ein leichtes Ruckeln der gegnerischen Figuren.
Ist der Verlust an Daten zu hoch, siehst Du ggf. zu spät, dass Dich jemand genau auf's Korn nimmt und der Blattschuss ist gesichert.
Ist, durch was auch immer, der Datenfluss zu Dir zu langsam, ist es im Grunde genommen das gleiche, denn Du reagierst schlicht immer zu spät, solange du keine hellseherischen Kräfte hast. Als vernünftiger Jedimeister, der die Zukunft erblicken kann kein Problem, als normaler irdischer Zocker sieht es aber anders aus und Du bist schnell dematerialisiert.
da ich dachte gelesen zu haben, das Paketverluste kein Problem dargestellt haben. Paketverlust hast du auch nicht explizit verwendet aber ich habe es aus deinem Text so interpretiert.
Ein Paketverlust ist nichts weiter als durch Fehler verworfene Datenpakete.
In Grenzen ist das auch kein Problem. Beim Telefonieren geschieht das gleiche ja auch mit den Sprachdaten:
Wenn da mal ein Paket verlustig geht, verstehst du das Gesprochene ja weiterhin, sind es zu viele fehlerhafte Pakete, wird es unverständlich bis hin zur Stille. Beim Spiel ist es identisch, der Gegner macht nur einmal einen minimal größeren Schritt nach vorne, nachdem er eine unmerklich kurze Pause länger still stand. Solange das nur wenige Pakete sind, ist der Spielverlauf dadurch nicht gefährdet. Sind es zu viele Pakete, hast du Pech gehabt.
Diese minimalen Verzögerungen sind aber normalerweise nicht das Problem, siehe auch die Schilderung von simple, der ja per LTE flüssiger spielen konnte - da sind die Paketlaufzeiten ja technisch bedingt etwas länger. Das scheint ja nicht wirklich zu stören, weil es sich um kleine 2-stellige ms-Werte handelt und er damit im Grunde genommen zufrieden war.
Wie kann man ein UDP Problem einkreisen, wie würde man versuchen UDP Pakete als TCP zu verschicken
So was gibt es nicht, das sind 2 Paar schuhe: UDP ist eine Art von Datenübermittlung, TCP eine andere. UDP ist eine Einbahnstraße ohne Handshake und Bestätigung des fehlerfreien Empfangs, dass muss ggf. der Spieleprogrammierer selbst auf seien Weise nachflicken, wenn benötigt. Meist ist das nicht erforderlich, siehe die Beschreibung der Telemetriedaten.
TCP hat das von vorne herein schon implementiert, das erspart der Software diese zusätzlichen Schritte, bremst den Datendurchsatz aber aus. Mein Gedanke war, ob es in der Spielesoftware die Möglichkeit gibt, statt UDP diese Telemetriedaten per TCP zu senden und zu empfangen.
Das einfach nur, um zu schauen, was sich am Ergebnis ändert/verbessert/verschlechtert.