Archiv verlassen und diese Seite im Standarddesign anzeigen : UDP und Sicherheit vor Paketloss
Bei UDP hat man ja im Gegensatz zu TCP ja keine Garantien, daß ein Paket ankommt. Wenn ich jetzt UDP aber auch diese Garantie brauche, wie geht man dann am Besten vor?
Die Pakete haben sowieso eine ID, aber einfach nur zu gucken ob Lücken im Paketstrom sind, wäre wohl nicht sinnvoll, da man ja keine Garantien über die Reihenfolge hat. Ich habe daran gedacht bei einer Lücke einen Timestamp zu nehmen und mit der erwarteten Id in einer Liste speichern. Dann bei jedem Paket schauen, ob es eines der bisher Fehlenden ist. Wenn die Zeitdifferenz zu groß wird, schickt man ein Error Paket zurück, welches die Id des fehlenden Pakets enthält.
Nur könnte das nicht realtiv aufwendig werden? Ich weiß nicht, wie fragmentiert so eine Paketfolge üblicherweise ist (die Pakete gehen nicht übers Internet und werden im LAN wenig geroutet). Auch habe ich überlegt, ggf. erstmal einen Schwung Pakete zu empfangen und die zu sortieren.
Welche Möglichkeiten hat man sonst um zu gewährleisten, daß alle Daten einen auch erreichen?
Danke!
Man vergibt einfach fortlaufende Nummern.
Neomi
2008-01-28, 16:16:28
Du willst also alle Datenpakete garantiert bekommen und mußt sie dann noch sortieren, um sie in der richtigen Reihenfolge zu haben. Du willst also das haben, was TCP bietet. Warum nutzt du dann nicht einfach TCP?
Ja, man kann einen Nagel auch mit einem Schraubenzieher in die Wand hauen, sinnvoll ist es aber nicht.
Du willst also alle Datenpakete garantiert bekommen und mußt sie dann noch sortieren, um sie in der richtigen Reihenfolge zu haben. Du willst also das haben, was TCP bietet. Warum nutzt du dann nicht einfach TCP?
Ich weiß zwar die genauen Gründe nicht mehr, aber ich hab im Hinterkopf, dass das eine schlechte Idee ist.
Ich such mal ob ich das entsprechende Zeug nochmal finden kann.
Das z.B. http://www.gamasutra.com/view/feature/3374/the_internet_sucks_or_what_i_.php?page=5
Neomi
2008-01-28, 16:50:23
Das z.B. http://www.gamasutra.com/view/feature/3374/the_internet_sucks_or_what_i_.php?page=5
Ja, UDP ist gut wenn man fehlende Pakete verkraften kann, dann stottert eine Spielfigur eben kurz und das wars.
Wenn man die Pakete aber garantiert benötigt (und das war ja Teil der Frage, Latenzanforderungen dagegen nicht), dann muß man mit UDP das komplette Warten, Neuanfordern, Warten, Sortieren, ... selbst erledigen und kommt wieder auf die gleichen Latenzen. In dem Fall kann man auch gleich zu TCP greifen, bei solchen Anforderungen ist es eben das geeignetere Werkzeug.
Bietchiebatchie
2008-01-28, 16:55:50
Das z.B. http://www.gamasutra.com/view/feature/3374/the_internet_sucks_or_what_i_.php?page=5
Interessant - aber irgendwie kann ich mir nicht vorstellen das TCP zu der Zeit so unbrauchbar war. Diablo kam schon Ende 96 raus und hat sicherlich auch TCP unterstützt. Ok, könnte man noch sagen, das war Host-Client. Aber April 98 kam StarCraft raus und das war reines P2P.
Monger
2008-01-28, 17:50:33
Das intelligenteste ist, eben gegenüber verlorenen Paketen robust zu reagieren.
Bei Netzwerkspielen heißt das: im schlimmsten Fall bleibt halt der Charakter für einen Moment stehen, und springt dann beim nächsten Datenpaket. Unschön, aber was geschehen ist, ist geschehen. Ein uraltes Paket anzufordern, macht da schlicht keinen Sinn.
Kommt halt auf die konkrete Anwendung an. Wenn man eine robuste Verbindung braucht, muss man halt zu TCP greifen - mit allen Vor- und Nachteilen. Für Echtzeitanwendungen ist nunmal UDP die bessere Wahl, auch wenn das manchmal zu seltsamen Effekten führt.
Shink
2008-01-28, 17:56:11
TCP ist sicher nicht immer die beste Wahl.
Bei WLan mit schlechtem Empfang ist TCP z.B. ebenfalls Grütze (schlechter Durchsatz -> dann drosseln wir mal die Datenrate denn wir überfordern die Infrastruktur wahrscheinlich)
Wenn man die Pakete aber garantiert benötigt (und das war ja Teil der Frage, Latenzanforderungen dagegen nicht), dann muß man mit UDP das komplette Warten, Neuanfordern, Warten, Sortieren, ... selbst erledigen und kommt wieder auf die gleichen Latenzen. In dem Fall kann man auch gleich zu TCP greifen, bei solchen Anforderungen ist es eben das geeignetere Werkzeug.
Du hast das Problem nicht verstanden. Bei TCP/IP kommt gar nichts mehr wenn ein Packet verloren geht. Auch nix nachfolgendes. Das heißt man hat extreme Zwangspausen drin, in denen wenigstens schonmal was neueres übertragen werden könnte.
Zudem drosselt TCP/IP automatisch wie schon angesprochen und noch mehr so lustige Dinge. TCP/IP taugt nix für Spiele.
Neomi
2008-01-28, 18:20:33
Du hast das Problem nicht verstanden. Bei TCP/IP kommt gar nichts mehr wenn ein Packet verloren geht. Auch nix nachfolgendes. Das heißt man hat extreme Zwangspausen drin, in denen wenigstens schonmal was neueres übertragen werden könnte.
Das Problem habe ich durchaus verstanden. Damit nichts mehr kommt, muß schon die Verbindung verlorengehen, ein verlorenes Paket wird durch TCP einfach nochmal geschickt. Und was will man mit neueren Daten, wenn diese auf den fehlenden aufbauen?
Zudem drosselt TCP/IP automatisch wie schon angesprochen und noch mehr so lustige Dinge. TCP/IP taugt nix für Spiele.
Automatische Drosselung war zumindest früher durchaus sinnvoll und ist es heute in manchen Situationen immer noch. Daß es nichts für Spiele taugt, ist Quatsch, es gibt nämlich mehr Anwendungsmöglichkeiten (ja, auch in Spielen) als nur Echtzeit-Updates für Multiplayer mit niedriger Latenz. Nebenbei bist du der erste, der überhaupt Spiele in die Diskussion gebracht hat.
Die Anforderungen des Threadstarters waren:
- kein Paket darf verlorengehen
Das wars, nichts weiter. Kein Anforderung zur maximalen Latenz, keine Hinweise zur Verendung bzw. Art der Applikation. Daher: the right tool for the right job -> TCP. Bei anderen Anforderungen mag UDP durchaus besser geeignet sein, bei diesen ist es das nicht. Anderenfalls sind die genannten Anforderungen unvollständig bzw. falsch.
Das Problem habe ich durchaus verstanden. Damit nichts mehr kommt, muß schon die Verbindung verlorengehen, ein verlorenes Paket wird durch TCP einfach nochmal geschickt. Und was will man mit neueren Daten, wenn diese auf den fehlenden aufbauen?
Schonmal übertragen haben, anstatt 5s zu warten bis überhaupt das verloren gegangene Packet mal ankommt und sie dann zu übertragen. Und das ist durchaus ein realistisches Szenario.
Nasenbaer
2008-01-28, 20:00:45
Schonmal übertragen haben, anstatt 5s zu warten bis überhaupt das verloren gegangene Packet mal ankommt und sie dann zu übertragen. Und das ist durchaus ein realistisches Szenario.
Wie gesagt mag das bei Spielen auch nicht immer praktisch sein TCP zu wählen aber "Gast" hat nie von Spielen oder garantierten Latenzen geredet. Er wollte nur, dass alle irgendwann heile ankommt - genau dafür is TCP i.O.
Ja, hab's gerade auch selber gemerkt. Muss am Forum liegen :D
Vielen Dank. Es geht nicht um Spiele, aber schon um Echtzeit. Das heißt die Latenz ist wichtig, aber gleichzeitig sind die Pakete wichtig und müssen ihr Ziel erreichen. Die Anwendung robust gegenüber fehlenden Paketen machen wird nicht möglich sein.
Shink
2008-01-29, 08:54:40
Echtzeit und TCP ist aber nicht wirklich sinnvoll (bzw. möglich) finde ich.
TCP ist ja toll, aber da es viele für etwas verwenden, das EINE der Eigenschaften benötigt (hier z.B. Schutz gegen Paketverlust) handelt man sich gleich den Protokoll-Overhead für alle anderen Funktionen ein und das ist meistens wirklich unnötig.
Nicht umsonst basieren selbst Dinge wie NFS (Network File System) eben nicht auf TCP.
Um was für eine Anwendung gehts denn? Wie groß sind die Pakete (müssen sie gesplittet werden)? Wie häufig wird gesendet? Kann man verlorengegangene Pakete tatsächlich nicht "erraten" o.ä.?
Um was für eine Anwendung gehts denn? Wie groß sind die Pakete (müssen sie gesplittet werden)? Wie häufig wird gesendet? Kann man verlorengegangene Pakete tatsächlich nicht "erraten" o.ä.?Es geht um die Kommunikation in Kraftfahrzeugen (in erster Linie Bussen) und Experimenten zu IP-basierter Kommunikation verschiedener Komponenten. Vielleicht könnten auch einige Dinge erraten oder geschätzt werden, man darph es aus Gründen der Sicherheit aber nicht. Gleichzeitig gibt es jede Menge Video- und Sensordaten, genau Zhlen habe ich nicht, weiß nur es muß viel, schnell, sicher übertragen werden. :(
Monger
2008-01-29, 09:34:07
Vielen Dank. Es geht nicht um Spiele, aber schon um Echtzeit. Das heißt die Latenz ist wichtig, aber gleichzeitig sind die Pakete wichtig und müssen ihr Ziel erreichen. Die Anwendung robust gegenüber fehlenden Paketen machen wird nicht möglich sein.
Das ist aber nunmal ein Widerspruch. Entweder läuft deine Anwendung in Echtzeit ab - dann muss sie aber auch mit allen Problemen zurecht kommen können die halt so im Zeitbetrieb auftauchen können, oder sie läuft fehlerfrei ab - dann musst du dir aber gegebenenfalls so viel Zeit nehmen wie eben nötig ist.
Für beides gibt es Anwendungsfälle. Eine Wettersimulation muss nicht in Echtzeit passieren, aber sie muss präzise sein. Eine Militärübung muss in Echtzeit ablaufen, da ist aber Präzision auch nicht so irrsinnig wichtig, schließlich ist die Korrektur in aller Regel ne Millisekunde später schon da.
Edit: auch bei Kraftfahrzeugen musst du davon ausgehen, dass ein Sensor aus irgendeinem Grunde mal zu langsam oder gar nicht antwortet, und damit muss deine Anwendung natürlich auch umgehen können. Oder du setzst gleich auf ein völlig anderes Protokoll, wie z.B. Token Ring. Da sind gewisse Echtzeitanforderungen nämlich garantiert! ;)
rotalever
2008-01-29, 17:08:06
WOW hat meines Wissens auch TCP. Und da hat man einen Ping von 200ms und das kann schon nerven. Wie man hier im Forum lesen kann, kann man durch eine Einstellung im Windows bewirken das der Ping auf ein niedrigeres Niveau absinkt. Dadurch, dass Windows die Pakete schneller/direkt ohne zu warten verschickt. Hätte man direkt UDP genommen und da eben eine Art TCP drauf emuliert (d.h. Pakete sortieren, etc.), dann wäre das vermutlich trotzdem schneller als das normale TCP, weil da das OS nicht mehr blockiert. Man kann natürlich einfach die Einstellungen im System vornehmen, ein DAU aber vll. nicht, aber der möchte das Spiel spielen.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.