Ajax, Mysql, long polling, websocket - rövid körökre osztott böngészős RPG játékot próbálok megírni, viszont a játékosok összekapcsolásánál nem tudom mi a megfelelő megoldás, szerintetek?
A játék ugye php-ban íródik, eleinte arra gondoltam, hogy ajaxal oldom meg, de hamar bele gondoltam, hogy ez esetben nagyon nagy szerver terhelés lenne.. ugye valós időben kellenek az információk, az egymás ellen harcoló felhasználóknak. Aztán olvastam a long pollingról, de az sem sokkal jobb, mivel maga a php szál kb. 10mb ott eszik a memóriából... szóval ebből is kiábrándultam. HTML5-ben a websockettet láttam még hasonló dolgokra használni, azt pedig nem tudom, hogy php-val lehet e összekötni, mert eddig csak pyton-nal láttam :S - ahhoz meg nem értek.
Esetleg tud valaki ezeken kívül, használható megoldást, vagy én spilázom, túl és ezek közül, valamelyik használható mégis erre a célra?
Igazából a Facebook valahogy megoldottam, mert ott csak akkor megy a lekérés mikor a velem kommunikáló fél csinál valamit, de sajna nem tudtam kihámozni a megoldást :S (nem mintha nagyon hittem volna benne, hogy sikerül)
válasza:"A játék ugye php-ban íródik, eleinte arra gondoltam, hogy ajaxal oldom meg, de hamar bele gondoltam, hogy ez esetben nagyon nagy szerver terhelés lenne.. "
Azt hiszem, félreértetted az AJAX lényegét.
"Aztán olvastam a long pollingról, de az sem sokkal jobb"
A pollingot AJAX-szal oldják meg, esetleg websockettel, de az még annyira gyerekcipőben jár, hogy nem jellemző.
A legegyszerűbb megoldás a kövtekező:
Az AJAX kódod ráhív a szerverre. A szerver megnézi, tud-e érdemleges adattal szolgálni (i.e. történt-e változás a legutóbbi tényleges update óta).
Amennyiben tud, úgy "true" -t/1-et/traktort/lánchidat/taknyot küld vissza. Az AJAX-os kód erre úgy reagál, hogy lekéri a tényleges adatokat.
Eyg másik megoldás az általad is említett long-polling. Ekkor az AJAX küld egy kérést a szervernek. A szerver pedig mindaddig nem válaszol, amíg nincs értelme (amíg nincs új adat). Ez problémásabb, mivel számolni kell a timeoutokkal, egyéb eseményekkel, amelyek megzavarhatják az amúgy egyszerűnek tűnő folyamatot.
Ha van rá lehetőséged, megpróbálhatod inkább Java (J2EE) alatt implementálni a játékot (bár a Facebook frontendje PHP-s, a backend rendszer Java; nem véletlenül), akkor sokkal több kontrollod van az ilyen dolgok fölött. Sajnálatos módon, hobbi projekt esetében ez kvázi kivitelezhetetlen, mivel használható ingyenes Java webtárhely jelenleg nincs, a fizetős meg egy vagyon (kivétel ezalól a hunhonlap.hu - azt hiszem, havi olyan 500 forinttól - , de a szolgáltatás minőségéről nem tudok nyilatkozni).
PHP alatt ez segíthet valamennyit: [link]
A megosztott memória segítségével elég gyors kommunikációt tudsz megvalósítani a két játékos közt.
Köszönöm a választ, elolvastam az általad linkelt cikket, érdekesnek tűnik, de ha jól veszem ki akkor ez tulajdon képen arról szól, hogy bizonyos adatokat a memóriában tárolok le és nem valamilyen adatbázisban, ami a HDD-t használja ilyenre. Illetve ez esetben is kellene az ajax, ami (1000ms-enként a folyamatosság miatt) kérelmet indít a szerver felé.
- Ezt a módszert biztosan fel használom, de még 1-2 részében bizonytalan vagyok..
Pl. lehet, hogy a SystemID már foglalt (más által) . szerveren, akkor mi történik?
Továbbá a "permissions" paraméter mire vonatkozik?
"A játék ugye PHP-ban íródik, eleinte arra gondoltam, hogy ajaxal oldom meg, de hamar bele gondoltam, hogy ez esetben nagyon nagy szerver terhelés lenne."
:) tudom, hogy az ajax optimális esetben azt a célt szolgálja, hogy csökkentse a szerver terhelését, illetve, hogy javítsa a felhasználó élményét... no de ha 1 ajaxot 1mp-nként meghívunk, azért, hogy hátha van új információ, akkor már nem annyira kíméli a szervert. - szerintem.
válasza:Nos, pont erre kínál megoldást a shared memory. Annak az elérése gyors, így az, hogy másodpercenként érkezik egy kérés, aminek függvényében a szerver ellenőrzi ezt a "gyorstárat", majd válaszol valami rövid, tömör "true/false" -szal, elméletileg minimális terhelést jelent a szerver felé. Sajna, az elérhetőség problémáját valóban körül kell járni valahogy.
Eszerint, ha konzisztensen használod, ftok() függvénnyel előállítva a kulcsot, nem kell tartanod az ütközéstől. Más kérdés, hogy ez így nagyon rossz megoldás.
Ki kell találnod egy megfelelő kulcsmechanizmust.
X darab játékos közt folyó egy ilyen kommunikáció egy "játszma". Minden játszmához kulcsot rendelve, ezt a kulcsot felhasználva a shared memory -hoz id -ként elég jó esélyed van rá, hogy nem akadsz össze semmivel.
Permissions: Unix permissions. Csak itt arra nézve, hogy az adott memóriablokkhoz kinek milyen hozzáférése van (ugyebár minden processzhez tartozik egy user).
A requestet nem tudod megúszni, annak mindig jelen lesz az erőforráigénye. Némi rásegítésképpen bekonfigurálhatod a szervert socket reuse -ra, illetve connection keep-alive -ra.
Mindazonáltal ne feledjük, hogy, ahogyan autónál nem pótolhatja semmilyen turbó vagy egyéb nyalánkság a köbcentit, mert kompromisszumokra kényszerülsz, úgy itt nem pótolhatja semmilyen optimalizáció a durva vasat.
Kapcsolódó kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!