TCP und Spiele
-
die protokolle sind sehr an die engines/spiele gebunden und entsprechend spezialisiert. Selbst wenn spiele technisch sehr aenlich wirken, z.b. quake3A, CS, UT; haben sie intern komplet andere netzwerk architekturen.
manche verschicken events und anhand dieser events simulieren sich die clients ihre welt zusammen, manche verschicken die simulationsdaten selbst (im einfachsten fall position + orientierung). Die protokolle nutzen besonderheiten von spielen/engines aus, z.B. werden daten anhand von spiellogik 'optimiert', wenn also jemand eine granate geworfen hat, wird er vielleicht 20s keine werfen koennen, das kann in die kompression der netzwerkpackete einfliessen. wenn jemand hinter einer wand (von dir aus gesehen) ist, muss seine positionierung nicht uebertragen werden, wenn du in einem rennspiel 200km/h faehrst, wirst du deine position sehr vorhersagbar aendern (aufgrund von physic) und wenn bei dir im spiel irgendwo blut spritzt und jemand anderes sieht das nicht weil ein packet verloren gegangen ist, wird es egal sein, wenn du jedoch deine waffe wechselst, ist es vielleicht sehr wichtig in Q3A, in Tribes hingegen hast du nur 2 waffen und du wirst die sehr sehr selten wechseln, und das spiel ist dermassen schnell, dass du eher auf die art der geschosse achtest, als auf was jemand in der hand hat. in manchen spielen simuileren die clients die welt und der server arbeitet als ein router, in manchen simuliert der server die welt und die clients sind terminals, das wirkt sich sehr darauf aus welche datenmengen hoch und runter fliessen, wie gross und frequent die packete sind.es ist wie mit physik engines, an sich sollen alle ganz offensichtlich dasselbe machen, aber die architektur, die algorithmen, die implementierung und die integration in die engine machen einen riesen unterschied aus. du hast keinen vorteil dadurch es zu standardisieren, nichtmal eine einheitliche schnittstelle, da die integration viel ausmacht.
-
Viele Spiele nutzen beides, sowohl TCP, als auch UDP.
UDP verwendet man für die Sachen, wo eine geringe Latenz wichtig ist.
TCP für Dinge, wo es absolut wichtig ist, dass die Nachricht beim Gegenüber ankommt.InGame Text Chat würde man z.B. mit TCP realisieren.
InGame Voice Chat allerdings via UDP.
-
Ohne Garantie auf Wahrheit:
In LoL werden Positionsinformationen der Spieler per UDP in kurzen Zyklen übertragen, die genaue Information der Position ist häufig nicht so wichtig, da sich die Spieler quasi die ganze Zeit in Bewegung befinden und die Positionen in kurzen Intervallen aktualisiert werden.
Anders sieht´s beim Aktivieren von Abilities aus, das ist kritisch und könnte daher über TCP/IP übertragen werden. (oder mittels mehrerer UDP Pakete, weil nach dem Aktivieren der Ability ein Cooldown runetrläuft, der Mehrfachaktivierung verhindert).Nur zwei Gedanken...
-
Vorschlag: Man erfindet ein Protokoll, das beides kann. Ähnlich wie ENet kann man auf einer Verbindung mehrere Channels aufmachen, die entweder stabil wie TCP oder eben unreliable wie UDP sind. Oder eine Mischung aus beiden. Vorteil: Während auf TCP-Pakete eines Channels gewartet wird, können bereits UDP-Pakete eines anderen Channels empfangen werden. Alles über die selbe Verbindung. Was spricht dagegen?
-
Daß wir schon TCP und UDP haben?
-
Vielleicht will er ja das, was Game-Engines bereits von Hand machen, "standardisieren" und wiederverwendbar machen, sodass nicht jede Engine das Rad neu erfinden muss. Also ein abstrakteres Protokoll auf TCP und UDP aufsetzen, welches die besagten Channels anbietet.
Stabiler Channel = TCP-Verbindung mit eigenem Port auf unterer Ebene
"Schneller" Channel = UDP-Verbindung mit eigenem Port auf unterer Ebene
-
Ich seh den Vorteil eines solchen Standards nicht. Ist doch alles viel zu speziell. In ner 0815 Büroanwendung braucht man sowas jedenfalls nicht.
-
Tyrdal schrieb:
Ich seh den Vorteil eines solchen Standards nicht. Ist doch alles viel zu speziell. In ner 0815 Büroanwendung braucht man sowas jedenfalls nicht.
Dafür ist es ja auch nicht gedacht. Wie GG schon richtig erkannt hat, habe ich überlegt, ein eigenes solches Protokoll zu erfinden. Die Idee ist, dass man beispielweise 2 stabile und 1 instabilen Channel erzeugt, die alle über die selbe Verbindung laufen. Dadurch kann eine Verbindung besser ausgelastet werden. Wird beispielweise auf einem stabilen Channel auf die Neusendung eines Pakets gewartet, können die anderen beiden weiterhin Daten empfangen. Also eine Art Multiplexing im Protokoll.
-
314159265358979 schrieb:
Dadurch kann eine Verbindung besser ausgelastet werden.
Was meinst du genau mit "Auslastung"?
314159265358979 schrieb:
Also eine Art Multiplexing im Protokoll.
Das würde bedeuten, du erfindest in deinem Protokoll eine eigene Art von Ports, um die Channels zu unterscheiden, wenn ich das richtig verstanden habe?
Dann hättest du ja am Ende wieder ein TCP und ein UDP implementiert. Vorausgesetzt du schaffst es die ganzen Technologien von TCP (Flusssteuerung, Slow Start, Congestion Control, usw.) nachzubauen.
Den einzigen Vorteil, den ich da jetzt sehe, ist dass man auf TCP/UDP-Ebene nur einen Port belegt, über den das eigene Protokoll läuft. Das könnte vielleicht irgendwelche Vorteile bzgl. Ports in Firewall öffnen usw. haben, da je Anwendung nur einer benutzt wird.
-
Ich vermute, SCTP hast du dir schon angeguckt?
-
GyroGearloose schrieb:
Was meinst du genau mit "Auslastung"?
Angenommen, man entscheidet sich, für seine Anwendung TCP zu verwenden. Nun kann es sein, dass TCP feststellt, dass ein Paket verloren gegangen oder fehlerhaft ist. Bis dieses Paket nicht angekommen ist, ist die Verbindung in dieser Richtung blockiert. Das kann man natürlich umgehen, indem man mehrere Verbindungen öffnet. Das ist allerdings ineffizient und verbraucht weitere Portnummern.
GyroGearloose schrieb:
Das würde bedeuten, du erfindest in deinem Protokoll eine eigene Art von Ports, um die Channels zu unterscheiden, wenn ich das richtig verstanden habe?
Genau.
GyroGearloose schrieb:
Dann hättest du ja am Ende wieder ein TCP und ein UDP implementiert. Vorausgesetzt du schaffst es die ganzen Technologien von TCP (Flusssteuerung, Slow Start, Congestion Control, usw.) nachzubauen.
Den einzigen Vorteil, den ich da jetzt sehe, ist dass man auf TCP/UDP-Ebene nur einen Port belegt, über den das eigene Protokoll läuft. Das könnte vielleicht irgendwelche Vorteile bzgl. Ports in Firewall öffnen usw. haben, da je Anwendung nur einer benutzt wird.Prioritäten für Channels z.B.
-
314159265358979 schrieb:
Vorschlag: Man erfindet ein Protokoll, das beides kann. Ähnlich wie ENet kann man auf einer Verbindung mehrere Channels aufmachen, die entweder stabil wie TCP oder eben unreliable wie UDP sind. Oder eine Mischung aus beiden. Vorteil: Während auf TCP-Pakete eines Channels gewartet wird, können bereits UDP-Pakete eines anderen Channels empfangen werden. Alles über die selbe Verbindung. Was spricht dagegen?
Sowas baut man üblicherweise als L7 Protokoll auf UDP auf.
Guck dir mal die RakNet an, die macht ziemlich genau das was du beschreibst. Zusätzlich kann man noch Prioritäten vergeben und wenn ich mich richtig erinnere komprimiert die RakNet auch automatisch.
-
hustbaer schrieb:
Sowas baut man üblicherweise als L7 Protokoll auf UDP auf.
Äh, L7? Korrigier mich, wenn ich falsch liege, aber Session Management geschieht doch auf L5.
hustbaer schrieb:
Guck dir mal die RakNet an, die macht ziemlich genau das was du beschreibst. Zusätzlich kann man noch Prioritäten vergeben und wenn ich mich richtig erinnere komprimiert die RakNet auch automatisch.
Sieht nach ziemlichem bloat aus.
-
Alles oberhalb von L4 wird doch sowieso nur der Anwendung abgewickelt, da werden L5 - L7 doch nicht mehr unterschieden.
-
314159265358979 schrieb:
hustbaer schrieb:
Sowas baut man üblicherweise als L7 Protokoll auf UDP auf.
Äh, L7? Korrigier mich, wenn ich falsch liege, aber Session Management geschieht doch auf L5.
Ich schreibe L7 weil ich immer L7 schreibe wenn ich von dem spreche was Anwendungsprogramme machen.
Du hast aber Recht, eigentlich wäre es L5.hustbaer schrieb:
Guck dir mal die RakNet an, die macht ziemlich genau das was du beschreibst. Zusätzlich kann man noch Prioritäten vergeben und wenn ich mich richtig erinnere komprimiert die RakNet auch automatisch.
Sieht nach ziemlichem bloat aus.
Was ist bloat?
Die RakNet ist eigentlich relativ schlank - zumindest dafür was sie alles kann. Und wenn sich in den letzten paar Versionen nicht gerade sehr viel geändert hat, dann kann man die auch relativ "low level" verwenden, so dass man wirklich nur den ganzen Connection/Session Management Teil verwendet, und die diversen zusätzlichen Features eben nicht.
-
DocShoe schrieb:
Alles oberhalb von L4 wird doch sowieso nur der Anwendung abgewickelt, da werden L5 - L7 doch nicht mehr unterschieden.
Das stimmt so nicht. Wie hustbaer im anderen Thread richtigerweise gesagt hat, ist auf L5 die TCP-Session beheimatet. L6 macht Dinge wie Verschlüsselung, Komprimierung und Zeichenkodierung. L7 macht dann das "eigentliche" Protokoll der Anwendung.
hustbaer schrieb:
Was ist bloat?
Die RakNet ist eigentlich relativ schlank - zumindest dafür was sie alles kann. Und wenn sich in den letzten paar Versionen nicht gerade sehr viel geändert hat, dann kann man die auch relativ "low level" verwenden, so dass man wirklich nur den ganzen Connection/Session Management Teil verwendet, und die diversen zusätzlichen Features eben nicht.Ich hab jetzt nur einen groben Blick darüber geworfen. Aber wenn ich sehe, dass ein RakNetPeer so viele Funktionen hat, dass sie bei mir nicht mehr auf eine Seite passen, ist das schon etwas viel.
Abgesehen davon ist die Challenge, ein solches Protokoll zu erfinden und zu implementieren, sowieso interessanter.
-
GyroGearloose schrieb:
Vielleicht will er ja das, was Game-Engines bereits von Hand machen, "standardisieren" und wiederverwendbar machen, sodass nicht jede Engine das Rad neu erfinden muss.
ein standard braucht man um kompatibilitaet zu erreichen, aber genau das braucht man bei custom server/clients nicht.
entweder man will quick&dirty ein spiel machen, dann nimmt man eine der vielen network engines z.b. raknet von http://www.jenkinssoftware.com/
oder man will ein qualitaetsspiel machen, dann lizensiert man sich zwar z.b. UE3, aber dennoch wird jemand am network code frickeln bis es fuer das spiel optimal ist und der ist dann zu keinem anderen spiel kompatibel, selbst wenn zwei spiele auf UE3 basieren.wenn es eine notwendigkeit fuer einen standard gegeben haette, haetten die leute die damit arbeiten einen geschaffen. wieso sollte jemand vom fach einen "standard" nutzen der von einer person erfunden wird, die fragt, weshalb tcp und udp ueberhaupt koexistieren?
http://xkcd.com/927/
http://www.pcats.org/system/files/Dilbert-StandardsMeeting.jpg
-
rapso schrieb:
wieso sollte jemand vom fach einen "standard" nutzen der von einer person erfunden wird, die fragt, weshalb tcp und udp ueberhaupt koexistieren?
Äh, wie bitte? Das habe ich aber nie gefragt.
-
314159265358979 schrieb:
GyroGearloose schrieb:
Dann hättest du ja am Ende wieder ein TCP und ein UDP implementiert. Vorausgesetzt du schaffst es die ganzen Technologien von TCP (Flusssteuerung, Slow Start, Congestion Control, usw.) nachzubauen.
Den einzigen Vorteil, den ich da jetzt sehe, ist dass man auf TCP/UDP-Ebene nur einen Port belegt, über den das eigene Protokoll läuft. Das könnte vielleicht irgendwelche Vorteile bzgl. Ports in Firewall öffnen usw. haben, da je Anwendung nur einer benutzt wird.Prioritäten für Channels z.B.
und um genau diese moeglichkeit beraubst du dich mit deinem plan. kein geraet zwischen dir und dem spieleserver kann mit deinen prioritaeten und channels was anfangen. durch die unterscheidung auf L4 kannst du in deinem lan und der spieleprovider in seinem netz fuer die richtige priorisierung sorgen. dem internet ist das ohnehin egal. du priorisierst also nur in deiner anwendung. das kannst du auch mit mehreren sessions. hmmm
-
Aus genau diesem Grund habe ich auch beschlossen, mein Protokoll auf UDP aufzubauen. Und nur falls das falsch rübergekommen ist: Ich habe nicht vor, TCP nachzuprogrammieren oder UDP und TCP zu verschmelzen oder sowas. Das Protokoll ist von grundauf neu designt und ich habe TCP nur als Vergleich herangezogen.
