Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Do Mär 28, 2024 22:55

Foren-Übersicht » Sonstiges » Meinungen zu den Projekten
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 84 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5, 6  Nächste
Autor Nachricht
 Betreff des Beitrags: Re: Massive Universe Online
BeitragVerfasst: Do Aug 02, 2012 13:04 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich hab mir mal das Server-Konzept angeguckt und kann da noch ein bisschen was zu sagen.
Der Communication Server ist ein Proxy und damit die Schwachstelle im Konzept.
Proxies sind der übliche "single point of fail" und haben eigentlich wenige Vorteil(Load balancing und ein Kanal kommunikation).
Im Konzept hat dieser Servertyp kein nachteil, wenn er entfernt wird, daher würde ich ihn raus lassen.
Die Session Server sind für die Session zum Client zuständig, wie der name es ja sagt ^^

Daher würde der Client zu einem Session Server verbinden und über diesen sich auch validieren.
Ich würde aber die Kommunikation nicht vollständig über den Session Server machen, sondern ihn so simple wie möglich halten.
Session server kann man relativ einfach aufstellen und über ein DNS Eintrag, mit RoundRobin load balancen.

Euere Game Server sind auch sehr komplex gestrickt, zum einem wird sharding verwendet aber auch clustering.
"Clustering is a bitch!", da steckt viel Wahrheit drin.
Die Synchronisierung von Servern untereinander, was notwendig ist, wenn spieler über gameserver hinweg miteinander interagieren sollen, endet in sehr viel logik code, noch mehr bugs und sehr hohen latenzen.
Es gibt viele Probleme zu Lösen, Hardware ausnutzung, load balancing, spieler interaktion, client überlastungs verhindern.
Selbst wenn die Server stand halten und 100 Spieler auf einem Pfleck rum wuseln, dann wird der Client definitiv nicht mit klar kommen, 100 Akteure zu rendern, Physik zu berechnen und so weiter ist in der Regel overkill.
Entsteht ein Interessanter Punkt oder böswillige Absichten und es sammeln sich mehrere hundert leute an einem Pfleck, dann kann man so das Game lahm legen, nicht weil die Server nicht stand halten, sondern die Clients nicht mit halten können.
Guild Wars, Tera, WoW Cata und bestimmt noch mehr setzten hier auf sharding und phase shifting.
Also die Welt wird in Zonen zerteilt und jede Zone kann n mal parallel existieren(je eine Instanz der Zone).
Je nach Game kann man frei zwischen den Kanälen hin und her switchen, bis das Limit einer Instanz erreich ist.
Dafür braucht man nur ein Server, den man mehrmals startet und vereinfacht das Konzept damit sehr.
Um mit Spielern zwischen mehreren Instanzen zu interagieren werden alle in eine gemeinsame verschoben.

Solch ein umfangreiches Konzept kann man nicht eben aus dem Ärmel schütteln, selbst mit meiner Jahrelanger Erfahrung, als Gameserver Entwickler setzt ich mich hin und baue diverse Konzepte und wäge immer wieder gegeneinander ab.
Was aber einfach ist, ist das Kritisieren eines bereits bestehenden Konzeptes, da man Probleme Punkte schnell wieder erkennt und entsprechend Anmerken kann.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Massive Universe Online
BeitragVerfasst: Do Aug 02, 2012 14:53 
Offline
DGL Member
Benutzeravatar

Registriert: Di Apr 29, 2008 18:56
Beiträge: 1213
Programmiersprache: Delphi/FPC
Hey,

erstmal Danke für die Tipps, die werden wir in die Entwicklung mit einbeziehen und das ganze noch einmal übedenken. Ein paar Sachen will ich aber nochmal etwas genauer erklären, denn ich glaub das kahm im Beitrag nicht so richtig rüber.

Der CommunicationServer ist nicht wirklich ein Proxy. Er dient lediglich dazu fehlende oder globale Informationen zu verbreiten, als eine Art Informationszentrum. Er ist die erste Komponente des Servers die gestartet wird. Alle anderen melden sich dann mit ihrer IP und Port beim CommunicationServer. Wenn ein Client oder eine Komponente des Servers z.B. eine IP vom Sektor X benötigt, dann wird beim CommunicationServer nachgefragt und dann eine direkte Verbindung zum Sektor hergestellt. Man könnte ihn auch als eine Art DNS-Server bezeichnen. Der DNS Eintrag wird dann auch auf den CommunicationServer gelegt. Man kann das zwar auch alles über den SessionServer machen, wie du das gesagt hast, aber ich finde das so etwas übersichtlicher, weil man dann globale Datenpackete über einen extra Server schicken kann (z.B. globale Systemnachrichten oder sowas in der Art).

Der GameServer verwaltet ja die Sektoren. Jeder Sektor hat seinen eigenen TCP-UDP-Server über den er die Komminukation abwickelt. Da ein Sektor auch im Game ein geschlossenes System ist, findet keine großartige Interaktion zwischen Spielern über verschiedene Sektoren statt (außer vlt das Nachrichten System). Natürlich gibt es eine max. Anzahl an Spielern die sich gleichzeitig in einem Sektor aufhalten dürfen. Mehrer Instanzen wollten wir eigentlich vermeiden, weil das wie eine Art Paralleluniversum wirkt, und das find ich persönlich ein bischen verwirrend. Wenn der Sektor voll ist kann man einfach nicht mehr rein. Bei Battlestar Galactica Online wurde das genauso gelöst. Einziger Nachteil: Wenn man wirklich in den Sektor muss/will, und dieser voll ist, hat man ein Problem.

Das man so ein Konzept nicht an einem Tag entwickelt ist klar. Wir sitzen seit über einem Monat an dem Design. Das kahm zwar im Beitrag nicht so rüber, aber es hat lange gedauert und wir haben uns auch viele Gedanken darüber gemacht, wie es am bessten funktioniert, oder wo Probleme auftreten könnten.

MfG Bergmann.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Massive Universe Online
BeitragVerfasst: Do Aug 02, 2012 16:43 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Schau dir mal diese Artikel an: Networking For Game Programmers. Da steht unter anderem drin warum TCP und UDP mischen keine gute Idee ist. Und in welche Fallen man laufen kann. Auch die Diskussionen unter den Artikeln sind mitunter sehr hilfreich.

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Massive Universe Online
BeitragVerfasst: Do Aug 02, 2012 18:51 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Der communication server kann dann aber auch durch eine db ersetzt werden.
Solch ein service register macht sinn, wenn man dynamische serverstrukturen hat, die sich so schnell ändern, dass die geschwindigkeit einer sql/nosql db nicht mehr hinterher kommt und/oder logik drin steckt.
In dem 2. Fall würde ich mir sorgen machen, wieso es einer logik bedarf.

Die Zone-Server sollten Game-Server spawnen, damit Kann man game spezifische infos vom zone-server bekommen, die zonen selber sind wohl fix, können also über normale konfig files reguliert werden und die kann jeder server kennen.
Beruflich nutze ich lokale Konfigs und konfigs über db.
Sind die zone-server dynamisch, dann müssen die irgendwie erzeugt und frei gegeben werden, dieser prozess wäre dann die Informationsquelle.
Nun noch das problem verfügbarkeit. Dies kann man über eine service tabelle und ein cronjob lösen. Der cronjob pingt jeden konfigurierten service, kann statistiken abfragen und in die db prügeln. Sowas habe ich schon in mehreren projekten gesehen und verwendet.
Dieser service hat ein ping abgesetzt und bei erfolg eine socketverbindung auf gemacht, zur internen admin schnittstelle und weitere server infos abgefragt, z.b userzahl, server load.
Der vorteil, das teil kann in wenigen minuten mit php zusammen gezimmert werden, kann buggy und unsicher sein aber das macht nix, ist ja ein interner service, der keinen ausfall zufolge hat, wenn er nicht mehr läuft.

Diese probleme sind aber noch überwchaubar, um ein vielfaches schlimmer sind fehlentscheidungen, wenn es um Daten geht.
Eine falsche datenhalting kann dafür sorgen das der code ins unermässliche wächst, threading und sync probleme auftreten und die einfachsten aufgaben zu sehr komplexen abläufen werden. Da hab ich in der vergangenheit sehr viel durch try and error gelernt.
Wenn ihr euch also mit der Struktur sicher seit, dann geht den nächsten schritt und tut rein logisch mal ein user einloggen, sich inder welt bewegen und ausloggen. Schaut die hopps an, was passiert, wenn ein service weg bricht und wägt das konzept erneut ab.

Zur Lösung von BSGO sag ich mal besser nix, ich kenne den code und hatte auch einen der Entwickler im Meeting.

Wir hatten mal mit einem weiterem Konzept gespielt, als wir ein mmo für ipad und diverser anderer tablets designed haben. Da das ipad arge perf probs hat mussten wir die userzahl runter drehen aber wir wollten nicht pc spieler oder leute mit ipad2, galaxy tab oder anderen schnelleren systemen auf diese usercount runter zwingen.
Daher haben die Server sichtbarkeitslisten angefertigt, welche grob alle nicht möglichen sichtbarkeiten entfernt hat, dann wurde ein ranking aufgebaut, jede interaktion mit einem spieler hat Punkte verteilt und der client hat dann die sichtbare usercount fest gelegt und konnte zur not auch sagen, dass er wen in der liste hoch priorisieren soll.
Der server hat dann entsprechend eine liste an die session gehangen und nur aktualisierungen von spielern, die in der liste sind, gesendet.
Wenn man also jemanden in die grp eingeladen hat, dann wurde er hoch bewertet, jemand chattet mit dir, er bekommt punkte, du hast ein freund, der in die nähe gekommen ist, der bekommt entsprechend genug punkte, dass er in die liste rutscht, gilde genauso.
Leider ging das game nicht in produktion, also kann ich nix über die pflege der zahlen sagen.

Wegen tcp und udp.
Mein rat, lass udp weg, es macht kein sinn 2 protokolle zu nutzen, noch dazu kann man tcp soweit tweaken,dass es nahezu gleiche performance bringt. Man kann windowing, ack an und abschalten, tcp kann paket batching auf anforderung und die latenz reicht alle mal.
Udp support macht es unnötig komplex.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Massive Universe Online
BeitragVerfasst: Do Aug 02, 2012 19:54 
Offline
DGL Member
Benutzeravatar

Registriert: Di Apr 29, 2008 18:56
Beiträge: 1213
Programmiersprache: Delphi/FPC
Hey,

erstmal nur was zu TCP/UDP. Den Rest muss ich erstmal im Team besprechen.
Wir haben lange überlegt, wie genau wir es machen. Von Anfang an war klar, das wir die Verbindung über TCP machen wollen. Auf die Sache mit dem UDP sind wir gekommen, weil wir uns Sorgen um die Datenmengen gemacht haben. Wenn mal so ein Packet mit Positionsupdates verloren geht ist das nicht weiter schlimm. Also hatten wir dafür UDP vorgesehen. Wir wollten dann unser Protokoll so weit erweitern, das der Nutzer des Protokols einfach sag: hier, sende die Nachricht per UDP oder sende die Nachricht per TCP. Um das Empfangen würde sich auch das Protokoll kümmern und der Nutzer würde einfach über neue Daten informiert, egal ob diese von UDP oder von TCP kommen. Beim UDP bräuchte man lediglich einen Zeitstempel für jeden Spieler. Sobald der Zeitstempel der eingehenden Message älter ist, als der aktuelle Zeitstempel des Spielers, dann wird die Message gedropt. Das war in unserren Augen relativ einfach.
Ich hab mit den Artikel mal durchgelesen, den Lord Horazont verlinkt hat. Und da steht ja jetzt wieder was ganz anderes drin. Dort wird gesagt das man gleich alles auf UDP bauen soll?! Und in den Comments streiten sich die Leute wie kleine Kinder was besser ist :/ Ich bin immer noch der Ansicht, dass wenn das Protokoll gut konzipiert ist, und eine gute Mischung aus UDP und TCP bereitstellt, die eigentliche Logik nicht nachteilig davon beteiligt ist. Geal nutzt soweit ich weiß auch eine Mischung aus beidem, aber LittleDave ist ja zur Zeit leider inaktiv :(

MfG Bergmann.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Massive Universe Online
BeitragVerfasst: Do Aug 02, 2012 21:26 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Reine udp basierte games sind der wahnsinn, das sind in der regel Leute die irgendwo gelesen haben, dass es schneller ist und sparsamer als tcp und dann einfach los legen mit ein bisschen aufwand es sogar toll funktioniert. Die probleme treten ja auch nicht in dem tollem stabielen heimnetz auf, sondern im inet und wenn last auf die netzwerkkarte kommt, dann cpu und speicher.
Raknet ist die ausgereifteste udp basierte lib, die man im netzt finden kann und selbst die bricht unter last zusammen und bugt rum. Das thema udp hat ich vor 2-3 Jahren schon für den ersten produktiv server und im projekt, wo ich nunzugestossen bin gibt es unter last probleme mit raknet, umstellen auf tcp hat das problem gelöst.
Ich könnte nun seitenweise dazu schreiben, wieso das so ist und die einzelen osi layer und nic treiber stacks auseinander fummeln aber das hilft niemanden.
Ist udp teufelszeuch ? Nein, unter bestimmten gegebenheiten ist es praktisch. Es gab ja früher Spiele, die udp benutzt haben und es gibt heute noch services, die udp nutzen.
Ist tcp der heilige gral ? Nein aber verdammt nahe dran, wenn es um spieleserver geht.

Solange man nicht versucht mehr als 65k verbindungen pro server zu halten, mit ner 1GB speicher zurecht kommen muss oder auf sehr exotischen wlan und umts treiber stacks unterwegs ist, wird man damit glücklich.
Man kann windowing abschalten, damit pakete sofort abgeschickt werden, timeout reduzieren oder gar ignorieren und kann auch jumbo paket generieren.

Ein guter rat, konzeptioniert nicht für mehrere tausend spieler pro server, sondern eher für 100, da die komplexität des systems stark steigt, je mehr spieler man regeln will.
Das klingt immer toll aber brauchen tut man es nicht, man kann einfach den server mehrfach auf einer kiste starten und über virtuele nics laufen lassen. Dies ist wesentlich einfacher als Code für pooling und async sockets zu schreiben, von der wartbarkeit ganz zu schweigen.
Schon mal mehrere hundert threads, sockets und userdaten debugt,weil ein synchronisierungs bug im code ist, der nur unter last auftritt? Keine spassige angelegenheit und der Grund, wieso ich von den 100k user server systemen weg bin.
Bei Drakensang Online hat ein Server 5 bis maximal 10 spieler. Wie bei diablo oder wow instanzen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Massive Universe Online
BeitragVerfasst: Do Aug 02, 2012 21:57 
Offline
DGL Member
Benutzeravatar

Registriert: Di Apr 29, 2008 18:56
Beiträge: 1213
Programmiersprache: Delphi/FPC
Hey,

zu UDP/TCP: das wollt ich hören, endlich mal jmd der sich auskennt und ein Machtwort spricht :mrgreen: Also bleibt es wie gehabt bei TCP.

zur Spieleranzahl: Im Grunde planen wir ja keinen Server mit 10k Spielern, sondern 100 Sektoren mit je 100 Spielern. Die Sektoren wären dann sozusagen unsere Instanzen, mit dem kleinen Unterschied, das die Sektoren unterschiedlich sind. Dann ist unser einziges Problem der Wechsel zwischen den Sektoren, was bei einem "normalen" MMO einem Channel- bzw. Instanzwechsel gleich kommt. Also haben wir im Grunde genau das, was du vorgeschlagen hast, oder? Ein rießiges Universum mit nur 5 Spielern wäre dann doch etwas langweilig. Vorallem weil wir so gut wie keine KI einbauen wollten.

MfG Bergmann.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Massive Universe Online
BeitragVerfasst: Do Aug 02, 2012 22:21 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Mai 29, 2006 21:13
Beiträge: 142
Wohnort: Ballenstedt/Sachsen-Anhalt
Moin!
Ich antworte mal unsortiert/ungequoted. Ist ja einiges aufgelaufen hier, teilweise mittlerweile auch schon beantwortet :P

Das ursprüngliche Serverkonzept kam von mir, und war reines GameServer-"Cluster" (1 Sektor pro Thread, damit mans einfacher verteilen kann 1 Prozess) mit einem separaten DB-Server (relational,SQL) im Backend (den man ggf. unabhängig verclustern könnte). Der Communication Server war eigentlich nur als besseres DNS geplant ("Welcher Server kann mir was zu Sektor 4711 sagen?" "Der GS an [fffe::...]:1235 berechnet den"). Session-Server sollten nur die Auth machen und einen Session Key ausspucken, mit dem man dann dem Sektorserver gegenüber beweisen kann, dass man schonmal auth'd wurde.
Dann kam Bergmann... :mrgreen:

@Horazont: Danke für den Link. Ich hatte den schon irgendwo noch im Hinterkopf, aber nicht genug um aktiv wieder danach zu suchen :(

Dadurch, dass wir die Spieler ins gleiche Universum packen wollen, können wir schlecht Sektoren instantieren. Eventuell könnte man das ähnlich wie GW2 mit Overflow-Servern lösen, aber da dürfte man dann nix bauen, sonst gibt das Sync-Probleme. Die wären dann nur zum Transit, wenn man zum anderen JumpGate will.

Was TCP/UDP angeht: ja, ich will auch nur TCP und versuche die ganze Zeit Bergmann dazu zu überreden. Für ein anderes Game bin ich auch grade dabei, Sync-Code zu entwicklen der Bandbreitenschonend mehrere hundert Entities synchronisieren kann. 1000PlayerFPS nochmal als Stichwort, von denen versuche ich zu lernen, nur eine Größenordnung kleiner. {€/ Ich lese grade bei MuchDifferent, dass die bei BSGO Consulting gemacht haben. Das bist nicht zufällig du?}
RAKnet kenn ich noch aus SA:MP-Zeiten, das war laggy wie nix - einfach weil immer mal Updates großflächig nicht stattgefunden haben.

Ich hatte damals für 50-100 Spieler pro Sektor geplant. Viel mehr wird dann auch im Client echt schwierig sinnvoll zu rendern. Als Hausnummer: eine Sehr Große Flotte hat vielleicht 15-20 Schiffe.

_________________
Gott sei Dank bin ich Atheist!


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Massive Universe Online
BeitragVerfasst: Fr Aug 03, 2012 18:48 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Zitat:
ann ist unser einziges Problem der Wechsel zwischen den Sektoren, was bei einem "normalen" MMO einem Channel- bzw. Instanzwechsel gleich kommt.

Jop, nur das es 2 unterschiedliche Arten von skalierung sind.
Der wechsel von einem Channel oder von Sichtbarkeitsgruppen nennt sich phasing und teilt die Last per Usercount.
Beim wechsel von Sektor zu Sektor ist sharding und dabei wird die Last durch räumliche unterteilung realisiert.
Beide Konzepte werden in Spielen verwendet und sind definitiv besser als ein Server für alles ^^
Man kann sie auch mixen, wird auch in vielen Spielen getan.
Bei den Userzahlen, die ihr genannt habt sehe ich da keine Bedenken.

Zitat:
Ein rießiges Universum mit nur 5 Spielern wäre dann doch etwas langweilig. Vorallem weil wir so gut wie keine KI einbauen wollten.

Da hast du mich falsch verstanden, ein Sektor hätte 5 Spieler. Ihr habt 100, wenn ich das richtig rauslese.

Der Communication Server hat halt Kommunikation zum client und wenn er weg bricht, dann ist das spiel down.
Er sollte allerdings nicht aus den Konzept raus fallen. Ich hab ja schon erwähnt, dass wir auch ein ähnlichen Service verwendet haben, dieser war intern, lief als php script auf ein cronjob und hat in eine mysql db geschrieben.
Die MySQL Db konnten dann die anderen Services/Server verwenden. Damit brauchen die anderen Services nicht diesen Service kennen und sind nicht davon abhängig.

Lustigerweise heissen unsere Authentifizierungssysteme auch SessionServer ^^ wohl ein sehr offensichtliches Konzept.
Wir halten die Session zum SessionServer aufrecht, bricht diese weg, ist der User Offline/Disconnected.
Der SessionServer, ist auch der Server, der Schreiboperationen auf die Userdaten machen darf.
Also ein GameServer muss updates zum SessionServer schicken, damit dieser diese in die DB schreibt.
Damit braucht der GameServer den DB Service nicht kennen und man kommt nicht in Sync probleme.

Db ist ein weiteres Thema.
Ich bin ein großer Fan von NoSQL, da es viele Daten, die man in Spielen braucht viel einfacher zu handhaben macht.
Auf Arbeit bin ich, aufgrund der Infrastruktur, auf Relationale DBs eingeschränkt aber privat prototype ich auch mit alternativen.
Bisher hab ich mit 3 Systemen gespielt, Memcache, Cassandra und eigenen REST c# server.
Das REST System ist mein absoluter Favorit, da man so viele Vorteile hat(web caches, portables protokoll, in mono und vc#.net easy zu basteln, einfache Logik im Model möglich). Daher verwende ich dies als Caching system von userdaten aber nicht für die Datenhaltung selber.
Relationelle DB's sind toll, wenn man queries hat wie "wieviele spieler haben item Z" aber nicht wenn ich frage "gibt mir inventory von spieler X".
Da die meisten Queries eher 2. Natur sind, lohnt es sich ein NoSQL Service mit ein zu planen, wie z.B. Cassandra.
League of Legend hat ihre MySQL Server mit einer Vermitlungsschicht verbunden, welche die Daten als NoSQL verfügbar macht.
Dies ist natürlich auch eine gute Variante, vorallem weil Cassandra und Thrift recht komplex sind.
Ich hab bisher nur mit Cassandra als noSQL lösung gearbeitet und fand es an einigen stellen noch einfacher als mit sql.

Ausschweifung in meine prototypings, kann man auch getrost überspringen ^^

Wenn ich ein NoSQL Layer verwenden würde, dann würde ich Player-Binary Blobs bauen und mit diesen arbeiten.
player/id/inventory
player/id/characterinfo
player/id/mails
player/id/...

Code:
  1. struct inventoryNoSQLHeader
  2. {
  3.   uint32 bagSlotCount;
  4.   uint32 bagSlotDataOffset;//Slot* slots=reinterpret_cast<Slot*>(reinterpret_cast<uint8*>(&inventory)+bagSlotDataOffset);
  5.   uint32 bankSlotCount;
  6.   uint32 bankSlotDataOffset;//Slot* slots=reinterpret_cast<Slot*>(reinterpret_cast<uint8*>(&inventory)+bankSlotDataOffset);
  7.   uint32 mount...
  8. };
  9. // daten im binary blob
  10. inventory inv;
  11. uint8 dynamicData[blobSize-sizeof(inventoryNoSQLHeader)];
  12. // Bank struct im Model
  13. struct Bank
  14. {
  15.   uint32& Count;
  16.   Slot* Slots;
  17. };
  18. // daten lesen
  19. AutoPointerArray<uint8> response=Request("player/123456/inventory");// get binary blob
  20. Model::GetProxy("myInventory").SetData(response);// override my inventory data by swap pointer and clean up the old one
  21. // rewire:
  22. // this.Bank.Count=reinterpret_cast<inventoryNoSQLHeader*>(this.data)->bankSlotCount;
  23. // this.Bank.Slots=reinterpret_cast<Slot*>(this.data+reinterpret_cast<inventoryNoSQLHeader*>(this.data)->bankSlotDataOffset);
  24. // use it
  25. Model::GetProxy("myInventory").Bank.Count;// Bank ist
  26. Model::GetProxy("myInventory").Bank.Slots[9];


Der Vorteil bei dem Layer dazwischen ist, dass man nun an der SQLDB eine Änderung machen kann und dank des Layers wird die Änderung nicht weiter gereicht und der binary blob bleibt wie er ist.
Der Layer würde für "player/123456/inventory" diese aufrufe machen "SELECT slotnr,slotcontains FROM bag WHERE id='123456';",
"SELECT slotnr,slotcontains FROM bank WHERE id='123456';", "SELECT slotnr,slotcontains FROM mount WHERE id='123456';".
Ein Header schreiben, der wie inventory strukturiert ist und dann die slotnr,slotcontains werte nacheinander schreiben.

Den NoSQL Layer, den ich bisher gesehen hab macht es allerdings nicht so schön performant(das ist quasi meine Variante), die machen alles dynamisch, wie protobuf oder libmysql mit alles als string und strukturbeschreibungen. Okey ist eine Java Lösung gewesen ^^.
Ich würde das eher mit php scripten erschlagen, welche noSQL queries auf SQL mappen und aus den infos c++ code generieren, um nur eine Datei zu pflegen um Daten von und zu SQL, NoSQL zu bekommen.

Ausschweifung in meine prototypings Ende

Zitat:
ch lese grade bei MuchDifferent, dass die bei BSGO Consulting gemacht haben. Das bist nicht zufällig du

Ne, ich bin c++/c# Server programmierer bei Bigpoint und hab auch viel performance profiling von Unity3D gemacht, daher saßen wir mit Entwicklern von BSGO und Mumie zusammen und haben Erfahrungen ausgetauscht und über die Designs geredet.

Wieder mal hab ich wesentlich mehr geschrieben als ich eigentlich wollte -_-

Edit:
http://highscalability.com/

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Massive Universe Online
BeitragVerfasst: Fr Aug 03, 2012 19:24 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Mai 29, 2006 21:13
Beiträge: 142
Wohnort: Ballenstedt/Sachsen-Anhalt
Ich glaube, wir haben nirgendwo beschrieben wie das mit den Sektoren bei X eigentlich funktioniert, oder? Das würde erklären, warum wir hier konsequent aneinander vorbeireden ;-)

Es existiert kein "Endlosuniversum" wie BSGO das hat, sondern jedes Planetensystem ist von den anderen isoliert, wenn da nicht die Jumpgates wären. Ist sogar relativ realistisch, der interstellare Raum ist ja doch etwas leerer als der Interplanetare. Jedenfalls, daraus entsteht dann eine Art Netz von Knoten(=Systemen=Sektoren), die durch Jumpgates verbunden sind. Das bedeutet, wir brauchen kein automatisches Handover bei Bewegung oder so, wenn der User ein Jumpgate durchfliegt ist schon klar in welchem Sektor er dann rauskommt und nur dann ändert sich was. Und da kann man problemlos einen Loadingscreen, Reconnect auf den anderen Server und sowas einbauen.

Wikipedia sagt mir grade, dass das eher Shared-Nothing ist als Sharding in dem Sinne, dass die SektorServer sich untereinander gar nicht kennen, und alles was Sektorübergreifend passiert über andere Komponenten vermittelt wird.

Das sieht im Diagramm etwas doof aus, der GameServer ist mehr die physische Maschine auf der mehrere SektorServer laufen als alles andere.

TAK2004 hat geschrieben:
Der Communication Server hat halt Kommunikation zum client und wenn er weg bricht, dann ist das spiel down.
Nicht direkt. Solange keiner seinen Sektor verlassen (oder überhaupt einsteigen) will, fällt das nicht auf, wenn der weg ist. DB-Access geht durch die SessionServer, das ist eher der SPOF. Allerdings kann man die einfach load-balancen, die sind relativ dumm.

TAK2004 hat geschrieben:
Wir halten die Session zum SessionServer aufrecht, bricht diese weg, ist der User Offline/Disconnected.
Der SessionServer, ist auch der Server, der Schreiboperationen auf die Userdaten machen darf.
Also ein GameServer muss updates zum SessionServer schicken, damit dieser diese in die DB schreibt.
Damit braucht der GameServer den DB Service nicht kennen und man kommt nicht in Sync probleme.
Genauso bei uns, nur dass wir die Connection zum SessionServer nicht vom Client aus halten; eine Session simeoutet, wenn kein GameServer mehr Daten sendet (spart eine Verbindung, Client->GameServer->SessionServer reicht aus).

TAK2004 hat geschrieben:
Db ist ein weiteres Thema.
Indeed.
Aktueller Plan: nicht nur NoSQL sondern NoDB im sinne von "eigene InMemory-Struktur und ab und zu mal auf Platte serialisieren". Entspricht wohl deinem REST-Server, auch wenn wir vermutlich ein Binärprotokoll drauf fahren werden.

_________________
Gott sei Dank bin ich Atheist!


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Massive Universe Online
BeitragVerfasst: Sa Apr 13, 2013 13:18 
Offline
Compliance Officer
Benutzeravatar

Registriert: So Aug 08, 2010 08:37
Beiträge: 460
Programmiersprache: C / C++ / Lua
ich habe in der mindmap (http://muo-game.de/data/images/network_protocol.jpg) gelesen, dass ihr md5 als hashverfahren für die PW's nehmen wollt.

AUF KEINEN FALL!

MD5 ist hoffnungslos veraltet, selbst meine alte krücke könnte so ein Passwort innerhalb von Tagen knacken, ein aktueller rechner schafft das sogar noch schneller.

Ihr solltet lieber einen Algorithmus wie SHA-512 nehmen. Davon gibts übrigens einige tolle delphi/lazarus implementierungen ^^

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Massive Universe Online
BeitragVerfasst: Sa Apr 13, 2013 13:24 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Nice catch. Ich möchte auf einen IT Security Post verweisen: How to securely hash passwords?. Der enthält ziemlich state-of-the-art-Tipps, soweit ich das bewerten kann.

grüße

Disclaimer: Ich lese zwar regelmäßig die Cryptography-Liste, daher habe ich grobe Ideen wie man's richtig macht. bcrypt ist denke ich eine gute idee.

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Massive Universe Online
BeitragVerfasst: Sa Apr 13, 2013 13:50 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich verweise mal auf den üblichen Standard in sicheren Systemen.
http://de.wikipedia.org/wiki/Bcrypt

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Massive Universe Online
BeitragVerfasst: Sa Apr 13, 2013 16:37 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Mai 29, 2006 21:13
Beiträge: 142
Wohnort: Ballenstedt/Sachsen-Anhalt
Danke für den Hinweis. Welcher Depp hat das da eigentlich reingeschrieben? :shock:

Selbst ich nehm für alles SHA1, und der ist schon nicht so der Brüller. BCrypt wäre hier sicherlich das Minimum, mit mehr oder noch mehr Salz dran.

_________________
Gott sei Dank bin ich Atheist!


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Massive Universe Online
BeitragVerfasst: Di Apr 16, 2013 12:56 
Offline
Compliance Officer
Benutzeravatar

Registriert: So Aug 08, 2010 08:37
Beiträge: 460
Programmiersprache: C / C++ / Lua
Sucht euch aber am besten eine geprüfte Implementierung aus, beim selber implementieren ist man nie sicher, dass man keine Fehler gemacht hat ;)

Wenn meine Facharbeit fertig ist und halbwegs gut benotet wurde könntet ihr auch die mal durchlesen, da geht es um sichere Kommunikation Client<->Server.

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 84 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5, 6  Nächste
Foren-Übersicht » Sonstiges » Meinungen zu den Projekten


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 16 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.096s | 17 Queries | GZIP : On ]