Server, UDP <> TCP, flow control, congestion avoidance, reliability...
-
Hallo ich hoffe der Titel ruft die Leute nach hier welche Antworten haben, ggf. Links Posten oder Mitdiskutieren möchten.
Ein Problem das wohl nicht nur mich "plagt" :
Was ich bräuchte wäre eigentlich ein Gameserver, möglichst Opensource, gut Dokumetiert, Kostenlos.... die Eierlegendewollmilchsau.Nun da ich nichts in dieser Richtung gefunden habe, habe ich mich selbst hingesetzt und mich etwas tiefer mit der Materie Protokolle beschäftigt und möchte mich essenziell auf folgende Seite(n) beziehen: http://gafferongames.com/networking-for-game-programmers/ da hier eigentlich viel von dem erklärt wird was mir in den (original) Dokumentationen von Boost::Asio und UDT fehlt.
TCP bietet nun ja alles was das Herz begehrt hat aber den Nachteil das es "Stoppt" alsbald ein packet als "Lost" gilt, was bei oftmaligem datenaustausch, Spielen mit wenig Latenz wie in meinem Fall, schonmal zu Schwierigkeiten führen kann (was HIER eigentlich gut Erklärt wird).
UDP bietet nichts davon, es gibt allerdings Ansätze alles so zu implementieren das dieser "Stopp-Effekt" von TCP nicht in Erscheinung tritt, dies hat natürlich einiges an Programmieraufwand zur Folge.
Wie ich oben schon erwähnt habe habe ich mir 2 Library´s (Boost::Asio und UDT) angeschaut jedoch fehlen mir hier weitergehende Klassenspezifische informationen aus den Originaldokumentationen für genau diese Implementationen bzw Konfigurationen.
Die Seite http://www.highscore.de/cpp/boost/ finde ich schonmal nicht schlecht, leider wird hier ausschlisslich auf TCP (Kapitel 7) eingegangen und nicht auf die Punkte die mich hier Interessieren würden.
Von daher würde ich diesen Beitrag hier gerne zur "Erkentnissgewinnung" und allgemeinen Diskussionsplatform sowie zur Sammlung Interessanter Links nutzen und einige Fragen stellen.
1) Frage: Sollte man die Negativums welche TCP bezüglich Latenz (hier auf simple Art beschrieben: http://www.gafferongames.com/networking-for-game-programmers/udp-vs-tcp ) mit sich bringt Beiseite schieben und sich auf die zuverlässigkeit setzen?
* Ich persöhnlich neige hier NEIN zu sagen und tendiere zu UDP, möchte aber gerne andere Meinungen (bitte mit Begründungen) hierzu lesen.
________
2) Da Ich zu UDP tendiere sollte Ich mich nun natürlich entscheiden mit welchen "Hilfsmitteln" ich arbeiten möchte.
__
a) Einen Server und einen Client "frei Hand" zu Programmieren wäre möglich aber Zeitaufwendig zudem besteht die Gefahr sich in Kleinigkeiten zu verrennen.
__
b) Hilfsmittel in Form von Library´s zu verwenden hat hingegen den Vorteil das einiges schon "vorgefertigt" und "vorkonfiguriert" ist und schon einige Leute an der Fehlerbehebung gearbeitet haben.
Idealerweise sollten gute Dokumentationen, Tutorials und Beispiele bestehen. Leider liegt das bei den beiden erwähnten Library´s "nur" in einer Form vor welche beschreibt wie man sie in die eigenen Projekte implementieren kann, auf die im Titel angesprochenen Mechanismen wird kaum eingegangen (oder ich habe diese passagen schlichtweg überlesen und bitte um Entschuldigung).
Um unter UDP die erforderlichen Mechanismen zu Implementieren erfordet es (meinerseits zumindest) weitergehende Literatur welche sich Speziell auf diese Mechanismen und die Implemtierung bzw Konfiguration der Library´s mit den zu erwartenden Folgen, Vor- und Nach- Teilen beziehen.
______
Von daher bitte Ich hier an dieser Stelle um Links, da ich selber beim Googlen nicht wirklich fündig geworden bin, alternativ würden mir auch Vorschläge zu anderen Library´s weiterhelfen oder gar Vorschläge ein gänzlich anderes (wenig bekannteres Protokoll) zu wählen welches mir beim studieren der RFC´s nicht ins Auge gesprungen ist oder deren Vorteile mir entgangen sind.
Ich hoffe auf viele Links, einen zur Diskussion anregenden Beitrag, natürlich auch auf Antworten welches mir und ggf. anderen die Wahl erleichtern und entschuldige mich für die recht lange Enführung meiner Gedankengänge zu den mich beschäftigenden Fragen.
Grüsse
-
Jetzt nur aus dem Kopf:
Ich hatte vor Ewigkeiten mal nach fertigen Libs gesucht und AFAIK auch ein paar Projekte gefunden, welche auf UDP basierten und z.Z. auch schon erfolgreich eingesetzt worden sind (jedenfalls laut mancher Referenzliste). Ist natürlich nicht immer alles umsonst...
http://www.jenkinssoftware.com/ RaKNet
http://hawksoft.com/hawknl/
...(Suche nach "game network library")
Oder muss das zwingend auf Boost basieren etc.?
-
Was du brauchst, hängt ganz von deinem Anwendungsfall ab!
Du könntest übrigens auch UDP und TCP kombinieren.
-
Ich denke ansonsten wären auch noch enet und zoidcom zu nennen. Und hier gibts eine exzellente FAQ zum Thema.
-
Hi schrieb:
Du könntest übrigens auch UDP und TCP kombinieren.
da waere ich auch fuer, dinge die sicher uebertragen werden sollen mit tcp (z.b. datentransfer) und dinge die schnell aber mit verlusten uebertragen werden sollen mit udp verschicken.
ich hab bei mir alles auf udp basierend gemacht und wichtige dinge werden serialisiert uebertragen, sprich. es wird ein packet abgeschickt das sicher sein soll und dann wartet der versender bis die packete auf der gegenseite einen counter um 1 erhoeht haben, falls das nach n-ms nicht passiert, wiederhole ich das verschicken (aber mit der selben packet ID, damit auf der gegenseite der counter nicht aus versehen zweimal angehoben wird.
'wichtig' sind fuer mich dinge wie login und weapon change usw. unwichtig sind die ganzen positionsaenderungen.
selten dass etwas wichtig und schnell sein muss, deswegen laeuft es so ausreichend gut (schlechter als tcp es machen wuerde, natuerlich).
-
@Pill Aman, danke für die Links, dass nicht immer alles umsonst ist, ist schon klar aber es ist halt eine mir selbst auferlegte Vorlage.
Hawk kannte ich bisher noch nicht, HawkNL und HawkVoice lesen sich Interessant, werde ich mich nun näher mit beschäftigten und auch der GameEngine mal eine ernsthafte Chance geben, eigentlich bin ich mit Irrlicht bisher sehr zufrieden und es liegt da auch schon einiges an Arbeit vor, dennoch ist es nie zu spät sich Alternativen anzuschauen, das habe ich bei OGRE und anderen Engines damals auch gemacht war aber nicht wirklich überzeugt.@Hi, Mein Anwendungsfall ist am ehesten zu vergleichen mit einem FPS/RPG, es Handelt sich um ein ein Weltraumspiel das nicht alleine Kampfbasierend und wenn nicht aus der "Cockpit-Perspektive" sondern wie ein FSP aufgebaut ist, hier geht es mehr um Taktik-Flottenverbands-Kämpfe, das heisst es sind nicht ganz so viele Datenübertragungen pro Sekunde notwendig, dennoch ist mir die Latenz wichtig da die Raumschiffe voll Steuerbar sein werden und Millisekunden bei Entscheidungen über Sieg und Niederlage einer Flotte schon eine Rolle spielen, zudem sollen auch weniger Actionreiche Marktwirtschaftliche und Politische Inhalte in Form eines freien Marktes und Interstellaren Handelsabkommen/Embargos sowie Kriege und somit fehlende Resourcen, mangelnde Ware,preisliche Inflation... mit einbezogen werden, was eine recht umfangreiche Datenbank-Kontrolle und Anbindung erfordert, dies aber nur nebenbei.
Über einen Mix von TCP und UDP lässt sich sicherlich nachdenken, dies wird aber wohl erst dann geschehen wenn ich bei der weiteren Programmierung bin und mich für eines der Hilfsmittel entschieden habe und dessen Möglichkeiten und Leistungsfähigkeit sowie die Zuverlässigkeit kenne.@dot, auch dir Danke für deine Links, auch Enet und Zoidcom werde ich mir im Detail anschauen, beide lesen sich sehr Interressant, ich werde im Zweifel mal mehrere Testprojekte mit Enet, Zoidcom und dem oben bereits erwähnten HawkNL machen und mich dann wohl für das entscheiden welches kann was ich brauche, implementationsfreundlich ist, mir am meisten liegt und die beste mögliche Dokumentation sowie eine gute Community bietet.
@rapso, auch dir Danke für deine Ausführungen, das mit dem Wichtig und Unwichtig stimmt schon, allerdings kommt es hier Beispielsweise auch auf die Anwendung an.
Weaponchange (bei mir wäre das austauschen der Munition) wäre hier insofern wichtig da es einen Unterschied macht ob man nicht trifft, nur geringen Schaden zufügt oder vollen Schaden macht und dadurch ggf. eine ganze Flotte "Untergeht" weil man der einzige damagedealer ist, im Falle eines Energietransfer´s wäre das noch fataler, alle Waffen fallen aus, Schilde versagen, Rettungsmassnahmen können nicht ergriffen werden... auch Positionsanagben sind mir Wichtig da auch ungelenkte Flugkörper als Waffen zur verfügung stehen werden und es schon wichtig ist WO sie treffen und WO sich der Gegner befindet, zudem sind hier auch Gesichtspunkte wie Cheating im bezug auf maximal mögliche geschwindigkeiten zu beachten.
Auf Client und Serverseite wird eine Physicsengine laufen, auf Clientseite zum Interpolieren und Simulieren auf der Serverseite zum nachrechnen.
Wichtig sind diese Informationen für den Spielablauf sicherlich nicht, da stimme ich dir zu, allerdings denke ich das ein Spieler das anders sehen wird.
Kompromisse wird man immer machen müssen, ich werde dann sehen welche ich machen werden muss.----------------------------
Ich Danke allen die geantwortet haben schonmal recht herzlich und werde mich nun mit den Drei genannten Alternativen auseinandersetzen, denn auch ich bin der Auffassung das man nicht das Rad neu erfinden muss solange es keine Signifikanten verbesserungsmöglichkeiten gibt.
Falls auch nochjemand seine Ideen einfliessen lassen möchten um ggf. auch anderen, welche die oft gestellte Frage nach Netzwerkanbindung für Multiplayernutzung und die Entscheidung darrüber was zu wählen ist, zu erleichtern oder sich jemand mit den selben oder ähnlichen Fragen bzw. Entscheidungsnöten angesprochen fühlt aber noch einiges Unklar ist bitte ich einfach zu Posten.
Danke nochmals.
Liebe Grüsse