Netzwerk allgemein (TCP) - UDP Flaschenhals

Übersicht

BlitzMax, BlitzMax NG

Beginners-Corner

	Mathias-Kwiatkowski Betreff: Netzwerk allgemein (TCP) - UDP Flaschenhals	Mo, Mai 19, 2014 22:59 Antworten mit Zitat
habe ich in sache tcp eine möglichkeit den flaschenhals vom clienten herrauszufinden? und wie verhällt es sich wenn dieser dicht ist? kommt dann noch etwas rein oder geht dann gar nichts mehr? wie ist es im verhältniss zu udp? ich meine bei udp (ungesicherter datentransfair) gehen daten verloren aber die die ankommen landen die auch im "flaschen hals"? oder hat es etwas mit der packetgrösse im allgemeinen zu tun? wenn ja wie gross darf ein packet bei tcp und bei udp sein? wie oft darf man daten rausfeuern wenn man nicht weiss ob der flaschenhals voll ist? so das sind einige grundfragen die ich habe, die mir bei meinem projekt grade auffallen. ich danke im vorraus für eure antworten. Edit: In sachen udp gibt es noch eine frage und zwar kann ich wenn ich W drücke die ganze zeit rausfeuern player will laufen? und wenn W nicht gedrückt wird player will nicht laufen? oder sollte man auch da auf traffik ein wenig acht geben? so nun sind alle fragen geschrieben, wie immer danke für eure antworten, im vorrraus.
Skype: Anarchie1984 http://projektworks.de/maxbase/ Icq - Erneuert am 21.08.2017 Yahoo - Erneuert am 21.08.2017

Mathias-Kwiatkowski

Betreff: Netzwerk allgemein (TCP) - UDP Flaschenhals

Mo, Mai 19, 2014 22:59
Antworten mit Zitat

habe ich in sache tcp eine möglichkeit den flaschenhals vom clienten herrauszufinden?
und wie verhällt es sich wenn dieser dicht ist? kommt dann noch etwas rein oder geht dann gar nichts mehr?
wie ist es im verhältniss zu udp?
ich meine bei udp (ungesicherter datentransfair) gehen daten verloren aber die die ankommen landen die auch im "flaschen hals"?
oder hat es etwas mit der packetgrösse im allgemeinen zu tun? wenn ja wie gross darf ein packet bei tcp und bei udp sein? wie oft darf man daten rausfeuern wenn man nicht weiss ob der flaschenhals voll ist?

so das sind einige grundfragen die ich habe, die mir bei meinem projekt grade auffallen.
ich danke im vorraus für eure antworten.

Edit: In sachen udp gibt es noch eine frage
und zwar kann ich wenn ich W drücke die ganze zeit rausfeuern player will laufen?
und wenn W nicht gedrückt wird player will nicht laufen?

oder sollte man auch da auf traffik ein wenig acht geben?

so nun sind alle fragen geschrieben, wie immer danke für eure antworten, im vorrraus.

Skype: Anarchie1984
http://projektworks.de/maxbase/
Icq - Erneuert am 21.08.2017
Yahoo - Erneuert am 21.08.2017

	DAK	Di, Mai 20, 2014 9:08 Antworten mit Zitat
Ok, mal als Erstes: ich bin mir nicht sicher, ob der Ausdruck Flaschenhals hier so passt. Internetverkehr ist immer ein Flaschenhals, egal was du verwendest, da er immer langsamer ist als deine CPU, dein RAM und deine Grafikkarte. Wenn du also (wie es mir scheint dass du tust) ein vollverschränktes System hast, wo nur der Server die Bewegungen berechnet und die Clients nur ihre Steuerungsbefehle schicken, dann ist das Internet immer der Flaschenhals, egal welches Protokoll du verwendest. Um das zu umgehen kann man einen Teil der Arbeit beim Client erledigen und seltener synchronisieren. So kannst du z.B. die Bewegung des Clients generell beim Client laufen lassen und synchronisierst dann die Position des Clients 5 bis 20 Mal pro Sekunde mit dem Server. Der Server berechnet dann, ob der Client diese Distanz in der Zeit zurück legen hat können und sendet ggF. eine korrigierte Position zurück um Cheater abzufangen. Auf diese Weise kannst du (a) die Menge der Daten stark reduzieren und (b) ist es nicht mehr so dringend notwendig, dass die Verbindung auch wirklich jedes Frame schnell genug klappt. Zu TCP/UDP: TCP hat ja eine garantierte Lieferung, oder zumindest wenn die Lieferung aus was auch immer für einem Grund nicht klappt, dann wird die Verbindung gekappt. Wie das funktioniert ist A schickt B ein Paket, B schickt eine Empfangsbestätigung. Kommt keine Empfangsbestätigung in einer gewissen Zeit zurück wird das Paket noch mal geschickt. Der Rest der tollen Eigenschaften von TCP (Pakete wieder in die richtige Reihenfolge bringen und doppelte Pakete verwerfen) ist quasi gratis. UDP hat diese Absicherungen nicht, das heißt Pakete können theoretisch verloren gehen, doppelt ankommen oder in verschiedener Reihenfolge ankommen. UDP ist dabei rund doppelt so schnell wie TCP was die Latenz angeht (Bei UDP wird nur ein Paket verschickt, bei TCP nach einander zwei (Paket und Sendebestätigung)), hat aber einen ziemlich ähnlichen Datendurchsatz (da die Sendebestätigung quasi keine Daten benötigt). Das heißt, bei allem, was kein Drama ist, wenn es mal nicht ankommt, geht UDP (z.B. Bewegungsdaten), für alles Andere brauchst du TCP (z.B. Chat-Nachrichten). Bei halbwegs sinnvoll funktionierenden, nicht überlasteten Netzwerken geht UDP so ziemlich gleich gut wie TCP. Da heutzutage die meisten Netzwerke schon echt sehr schnell sind (Latenzzeiten von <50 ms) kann man auch fast immer TCP verwenden, wo man früher UDP verwendet hätte. Wo die Performanceunterschiede bei den beiden Protokollen vor 10-20 Jahren noch echt groß waren, kann man die heutzutage für kleinere Projekte quasi vernachlässigen. Viel wichtiger ist deine Synchronisationsstrategie, da eine sehr gut gemachte Synchronisation bei quasi der gleichen Leistung (=Unterschied für den Spieler kaum wahrnehmbar) oft nur ein Bruchteil (ich rede hier von Faktor 100 oder mehr) der Leistung benötigt. Falls du mehr Info brauchst und dir Englisch keine Probleme macht, schau mal hier hin: http://gafferongames.com/netwo...etworking/ Der Link erklärt das Ganze sehr gut.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Di, Mai 20, 2014 9:08
Antworten mit Zitat

Ok, mal als Erstes: ich bin mir nicht sicher, ob der Ausdruck Flaschenhals hier so passt. Internetverkehr ist immer ein Flaschenhals, egal was du verwendest, da er immer langsamer ist als deine CPU, dein RAM und deine Grafikkarte. Wenn du also (wie es mir scheint dass du tust) ein vollverschränktes System hast, wo nur der Server die Bewegungen berechnet und die Clients nur ihre Steuerungsbefehle schicken, dann ist das Internet immer der Flaschenhals, egal welches Protokoll du verwendest.

Um das zu umgehen kann man einen Teil der Arbeit beim Client erledigen und seltener synchronisieren. So kannst du z.B. die Bewegung des Clients generell beim Client laufen lassen und synchronisierst dann die Position des Clients 5 bis 20 Mal pro Sekunde mit dem Server. Der Server berechnet dann, ob der Client diese Distanz in der Zeit zurück legen hat können und sendet ggF. eine korrigierte Position zurück um Cheater abzufangen. Auf diese Weise kannst du (a) die Menge der Daten stark reduzieren und (b) ist es nicht mehr so dringend notwendig, dass die Verbindung auch wirklich jedes Frame schnell genug klappt.

Zu TCP/UDP: TCP hat ja eine garantierte Lieferung, oder zumindest wenn die Lieferung aus was auch immer für einem Grund nicht klappt, dann wird die Verbindung gekappt. Wie das funktioniert ist A schickt B ein Paket, B schickt eine Empfangsbestätigung. Kommt keine Empfangsbestätigung in einer gewissen Zeit zurück wird das Paket noch mal geschickt. Der Rest der tollen Eigenschaften von TCP (Pakete wieder in die richtige Reihenfolge bringen und doppelte Pakete verwerfen) ist quasi gratis.
UDP hat diese Absicherungen nicht, das heißt Pakete können theoretisch verloren gehen, doppelt ankommen oder in verschiedener Reihenfolge ankommen.
UDP ist dabei rund doppelt so schnell wie TCP was die Latenz angeht (Bei UDP wird nur ein Paket verschickt, bei TCP nach einander zwei (Paket und Sendebestätigung)), hat aber einen ziemlich ähnlichen Datendurchsatz (da die Sendebestätigung quasi keine Daten benötigt).

Das heißt, bei allem, was kein Drama ist, wenn es mal nicht ankommt, geht UDP (z.B. Bewegungsdaten), für alles Andere brauchst du TCP (z.B. Chat-Nachrichten).

Bei halbwegs sinnvoll funktionierenden, nicht überlasteten Netzwerken geht UDP so ziemlich gleich gut wie TCP.

Da heutzutage die meisten Netzwerke schon echt sehr schnell sind (Latenzzeiten von <50 ms) kann man auch fast immer TCP verwenden, wo man früher UDP verwendet hätte.

Wo die Performanceunterschiede bei den beiden Protokollen vor 10-20 Jahren noch echt groß waren, kann man die heutzutage für kleinere Projekte quasi vernachlässigen. Viel wichtiger ist deine Synchronisationsstrategie, da eine sehr gut gemachte Synchronisation bei quasi der gleichen Leistung (=Unterschied für den Spieler kaum wahrnehmbar) oft nur ein Bruchteil (ich rede hier von Faktor 100 oder mehr) der Leistung benötigt.

Falls du mehr Info brauchst und dir Englisch keine Probleme macht, schau mal hier hin: http://gafferongames.com/netwo...etworking/

Der Link erklärt das Ganze sehr gut.

Gewinner der 6. und der 68. BlitzCodeCompo

	Tritium Betreff: Re: Netzwerk allgemein (TCP) - UDP Flaschenhals	Di, Mai 20, 2014 11:46 Antworten mit Zitat
Mathias-Kwiatkowski hat Folgendes geschrieben: Edit: In sachen udp gibt es noch eine frage und zwar kann ich wenn ich W drücke die ganze zeit rausfeuern player will laufen? und wenn W nicht gedrückt wird player will nicht laufen? oder sollte man auch da auf traffik ein wenig acht geben? Naja, wenn Du irgendwo einen Flaschenhals befürchtest, dann sollte es doch selbstverständlich sein, dass Du an JEDER Stelle versuchst, möglichst wenig Traffic zu erzeugen (Ist übrigens auch ohne Flaschenhals guter Stil, ob man das nun auf Traffic, Festplattenspeicher oder sonstwas bezieht. Wenn es eine für Dich als Programmierer einfache Lösung gibt, Ressourcen zu sparen, ohne das Programm zu beeinträchtigen, dann nutze sie auch! Sonst kommt hinterher ein Mehrspieler-Pacman raus, das nur mit GBit-LAN und Quadcores läuft, aber hey, heutzutage sollte jeder ja sowas haben, ne )

Tritium

Betreff: Re: Netzwerk allgemein (TCP) - UDP Flaschenhals

Di, Mai 20, 2014 11:46
Antworten mit Zitat

Mathias-Kwiatkowski hat Folgendes geschrieben:

Edit: In sachen udp gibt es noch eine frage
und zwar kann ich wenn ich W drücke die ganze zeit rausfeuern player will laufen?
und wenn W nicht gedrückt wird player will nicht laufen?

oder sollte man auch da auf traffik ein wenig acht geben?

Naja, wenn Du irgendwo einen Flaschenhals befürchtest, dann sollte es doch selbstverständlich sein, dass Du an JEDER Stelle versuchst, möglichst wenig Traffic zu erzeugen Wink

(Ist übrigens auch ohne Flaschenhals guter Stil, ob man das nun auf Traffic, Festplattenspeicher oder sonstwas bezieht. Wenn es eine für Dich als Programmierer einfache Lösung gibt, Ressourcen zu sparen, ohne das Programm zu beeinträchtigen, dann nutze sie auch! Sonst kommt hinterher ein Mehrspieler-Pacman raus, das nur mit GBit-LAN und Quadcores läuft, aber hey, heutzutage sollte jeder ja sowas haben, ne Rolling Eyes

)

	Jolinah	Di, Mai 20, 2014 22:32 Antworten mit Zitat
Am besten suchst du nach Interpolation, Extrapolation, Dead Reckoning, Client Prediction und Lag Compensation. Damit kannst auch nur alle 200ms oder weniger ein Update senden und der Client kann trotzdem flüssige Bewegungen darstellen. Unter http://mzehr.ch/NetTest hatte ich mir früher ein kleines Tool gebaut, welches diese Mechanismen verdeutlicht (Extrapolation ist nur ganz simpel, könnte man besser machen und das Client Prediction ist nicht ganz korrekt umgesetzt, hatte ich damals falsch verstanden). Da kannst du z.B. die Senderate mal auf 0.2s stellen und dann Interpolation einschalten und die Interpolationszeit auf 0.4s festlegen. Die Bewegung ist zwar dann um 0.4s verzögert, aber einigermassen flüssig. Normal wählt man bei schnellen Spielen etwa 0.1s Interpolationszeit.

Jolinah

Di, Mai 20, 2014 22:32
Antworten mit Zitat

Am besten suchst du nach Interpolation, Extrapolation, Dead Reckoning, Client Prediction und Lag Compensation. Damit kannst auch nur alle 200ms oder weniger ein Update senden und der Client kann trotzdem flüssige Bewegungen darstellen.

Unter http://mzehr.ch/NetTest hatte ich mir früher ein kleines Tool gebaut, welches diese Mechanismen verdeutlicht (Extrapolation ist nur ganz simpel, könnte man besser machen und das Client Prediction ist nicht ganz korrekt umgesetzt, hatte ich damals falsch verstanden).

Da kannst du z.B. die Senderate mal auf 0.2s stellen und dann Interpolation einschalten und die Interpolationszeit auf 0.4s festlegen. Die Bewegung ist zwar dann um 0.4s verzögert, aber einigermassen flüssig. Normal wählt man bei schnellen Spielen etwa 0.1s Interpolationszeit.