Ennek a bejegyzésnek a témája most elég technikai jellegű lesz, nem titkoltan azzal a szándékkal, hogy hátha felkelti valaki hozzáértő érdeklődését és beszáll a fejlesztésbe a gyorsabb haladás érdekében. Egy-két újabb konceptrajzot is beraktunk a szövegbe, hogy a többieknek is jusson valami csemege.
Kicsit több mint egy hónapja publikáltam a launchpad-on a majdani szerverünk prototípusának kezdetleges állapotban lévő forráskódját. Ezzel a célunk egy szerver keretrendszer kialakítása, amelyből majd a trunk-ba illesztve a szerver programunk első bevethető verziója fejlődne ki. Az alábbiakban ennek az általunk tervezett felépítését és nagyvonalú működését mutatom be.
A szerver öt önálló binárisként (és processzként) futtatott kiszolgáló egységből áll: master, worker, auth, chat és logger. Ezek mind képesek külön számítógépen futni vagy alapesetben a master indítja a többi processzt – vagy azokat, amelyek azonos hoston futnak vele - forkkal. A processzek egymással tcp kapcsolaton beszélnek, meghatározott portokon keresztül.
A master felügyeli egy un. masterporton kapcsolódva a többiek futását, statisztikát gyűjt róluk, indítja és leállítja a szolgáltatásokat. Később egy szöveges (ncurses alapú) konzolt is megvalósítunk, amin keresztül közvetlenül lehet felügyelni a szerver futását.
Minden processzt alapvetően azonos felépítéssel tervezünk, aminek az alapelemeit az ACE Framework adja. Az un. half-sync/half-async mintát használjuk. Ennek az a lényege, hogy egy threadben kezeljük a hálózati kapcsolatokat és a forgalom (küldés és fogadás) lebonyolítását az ACE_Reactor és kapcsolódó osztályok segítségével és egy másik – ehhez képest aszinkron módon futó - thread-ben végezzük a beérkezett üzenetek feldolgozását és a kiszolgáló funkciók futtatását. A két thread egymással egy üzenetsoron keresztül kommunikál.
A kiszolgálók tehát úgy működnek, hogy a hálózati kapcsolatokon beérkező üzenetek egy üzenetsorba kerülnek, amiből egy feldolgozó thread veszi ki, és dolgozik velük. Opcionálisan threadpool-t is használhatunk, ami azt jelenti, hogy egyszerre több feldolgozó szál vár üzenetre, és így párhuzamosan üzenet feldolgozása is futhat – amennyiben ez megoldható és szükség van rá.
A master által végzett feladatokat már leírtam, következzen most a többi négy kiszolgáló.
A logger processz végzi a szerverben a többi kiszolgálótól érkező logbejegyzések rögzítését fáljba vagy adabázisba. A konkrét feladatokat megvalósító rész készülhet luában is, mert nincsen szükség a c++ sebességelőnyére ebben az esetben, viszont talán kevesebb kóddal és rugalmasabban megvalósítható (esetleg akár menet közben is cserélhető).
A chat processz végzi a szerverben a felhasználói csevegés és egyéb hasonló feladatok (pl. hírek, bejelentések) lebonyolítását. Alapvetően csatornák vannak, amelyekhez felhasználók kapcsolódnak és az adott csatornára küldött üzeneteket szórja szét a tagoknak. A megvalósítás itt is lehetne akár luában.
Az auth processz végzi a szerverben a felhasználók azonosítását a nevük és jelszavuk alapján ill. az un. „game session” létrehozását. A felhasználói adatokat és jogosultságokat egy Postgresql alapú adatbázisban tároljuk. Ezt az adatbáziskezelőt használjuk igény szerint máshol is. A megvalósítás itt is lehetne akár luában.
A worker végzi a szerverben a felhasználói hálózati kapcsolatok kezelését a RakNet rutinkönyvtár segítségével, az entitásrendszer és szabályrendszer szkriptek futtatását és az entitások egymáshoz való térbeli viszonyát követő (máshol talán fizika modulnak hívott) proximity motor futtatását. A szkriptek fájlrendszeren (esetleg adabázisban) foglalnak helyet, az entitások adatai pedig egy entitásadatbázisban.
Ez a processz valósítja meg a játékszerver legfontosabb funkcionalitását, a többi kiszolgáló tulajdonképpen az erről leválasztható és önállóan működni tudó funkciókból jött létre.
Ezek voltak a legfontosabb információk a Solarah Online első szerverprogramjáról ill. arról, hogy hogy akarjuk kialakítani. Feltűnhetett, hogy nincsen szó itt klaszterezésről, terheléselosztásról, monitorozhatóságról, távoli menedzselhetőségről, stb. Ezeket a tulajdonságokat, képességeket nem akarjuk mindjárt ebben a szerververzióban megvalósítani. Próbálunk (épeszű idő és munka árán) megvalósítható célokat kitűzni magunk elé, és a fokozatosság elvét követjük.
Remélem minden mondat értelmesre sikerült. Kérdéseiteket és észrevételeiteket a honlapon megtalálható kontaktokra írjátok.
3 megjegyzés:
Höh Ez mind szép és jó de bonyolult és érdekes :D
Lua az jó ötlet :P
Viszont szerintem egy darabig jól el lesztek vele :P
Addig is hajrá!
Már nagyon várom a következő bejegyzést!!!!
A két csatolt kép nagyon hangulatos.
Főleg a második. Eddig messze a legjobb SO képek.
A játékosok azonosítását név+jelszó alapján azért nem tartom szerencsésnek, mert eleve nem kedvelem azokat a rendszereket amik simán tárolják a választott jelszavamat. Azokat főleg nem amelyek emlékeztetőnek visszaküldik a jelszavamat, mert akkor tuti, hogy valahol mindenféle kódolás nélkül egyszerűen elrakták azt az adatbázisban.
Én azt a megoldást pártolom, hogy a jelszót egy megfelelő adattal kombinálva kódolva tárolja a program. És amikor legközelebb belépek akkor már csak azt tudja ellenőrizni, hogy az éppen beírt jelszavam ugyanazon módon lekódolva egyezik-e a kódolt jelszóval.
Germo: a felhasználókat név és jelszó alapján azonosítjuk, arról viszont nem írtam, hogy hogyan tároljuk a jelszavakat az adatbázisban. :)
Ha jól emlékszem erről konkrétan nem beszéltünk még a csapatban, de én is azt a megoldást preferálom, hogy egy md5/sha1 hash-t tárolnánk csak a jelszó helyett, és ezt hasonlítanánk azonosításkor.
Megjegyzés küldése