TCP und Spiele
-
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.
-
das habe ich gar nicht gemeint.
314159265358979 schrieb:
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.
du brauchst verschiedene verbindungen, unabhaengig vom protokoll. oder anders gesagt: wenn du keine unterschiedlichen verbindungen (von mir aus auch durch udp-portkombinationen) fuer deine unterschiedlichen channels benutzt, kann kein geraet, das man heute kaufen kann, irgendeine prioriesierung vornehmen. du musst also die switch- und routerhersteller davon ueberzeugen auch in deine prioritaetsinformationen zu schauen, sonst ist das konzept schon bei deiner fritzbox gescheitert.
nebenbei: die information der priorisierung direkt auf L2 (pcp aka p-bit), L2,5 (exp) und L3 (dscp) zu transportieren ist nichts was du neu erfinden musst. nur interessiert es deinen provider halt nicht, was du ihm da schickst. ausnahmen sind z.b. voip+internetprovider, die sichergehen wollen, dass das telefon auch beim torrentuser gut klingelt (fritzbox). da werden datenstroeme unterschieden.edit und fazit:
in deinem lan kannst du existierende techniken benutzen, da das der einzige ort ist, auf den du wirklich einfluss hast, und end-to-end zaehlt eh nur verbindungsorientert oder nicht. gibt's also auch schon. ich sehe jetzt keinen praktischen nutzen. aber als hobbyprojekt kannst du das ja machen.
-
@mezzo mix:
Klar wäre es schön, wenn alle an der Übertragung beteiligten Geräte zwischen wichtigen und weniger wichtigen Paketen unterscheiden könnten.Es ist aber nicht nötig um eine "gemischte" (reliable/unreliable) Kommunikation mit einem eigzigen UDP Port (Quadruple) zu machen.
Was man nämlich immer Kontrollieren kann, sind die ganzen Timeouts und die Art und Weise wie Resends gehandhabt werden.
Unwichtige Informationen werden einfach gar nie wiederholt wenn sie nicht beim 1. Versuch durchgehen - das reicht für die meisten Status-Updates.
Wichtigere Informationen kann man über ACKs mit Sequence-Nummern bestätigen lassen, und einen Resend machen wenn zu lange kein "passender" ACK kommt.
Superwichtige Informationen kann man vielleicht sogar gleich immer 2x verschicken, oder nach z.B. avg(Ping) * 1.3 automatisch neu verschicken, auch wenn in der Zeit überhaupt kein ACK vom Peer gekommen ist.Was auch gut ist: wenn man mehrere Channels erlaubt, kann man pro Channels einstellen was er "können" soll. z.B. gibt es manchmal Dinge die "reliable" sein müssen, aber nicht "ordered" etc.
-
gut, nach deiner erklaerung habe ich jetzt wenigstens verstanden, was das vorhaben ist.
