Zdravim vospolok.

Pred par dnami som si povedal, ze skodim na kolene velmi primitivnu travianlike hru (broste nejaku browser game). Nie z dovodu, ze chcem hru, ale z dovodu sa nieco naucit. Myslienka pola to postavit na html/php/javascripte, vsetko. Ziadne ine technologie. Vymyslel som si uplne primitivny koncept a zacal som kodit "na kolene" (treba chapat tak, ze som si povedal, ze budem riesit veci za chodu). Skodil som si tazbu surovin. Skodil som si vyrobu tajtrlikov (chap vojacikov ). Nejak intuitivne som si myslel, ze utoky budu problem a potvdilo sa, ked som zacal uvazovat akoby sa to dalo spravit. A to je dovod, preco pisem na forum . Pokial sa totiz hraci navzajom nemuseli ovplyvnovat, tak to bolo lahke programovanie aj na "statickych technologiach". Tu mi to pride uz trochu krkolomne. Dam priklad jednej modelovej situacie a koncept riesenia + vzniknute mozne problemy a potom nejake otazky. Vsetko je postavene na zapise timestampov udalosti do DB. Priklad: Dam zvysit lvl niecoho, zapisem cas, kedy sa ma ukoncit a pri najblizsej aktivite uzivatela zratam potrebne veci a updatujem DB. Pohoda. Zahrnme utoky.
time 0: uzivatel_1 zada update minigu surovin z lvl 1 na lvl 2 (tento update skonci v case time 3)
time 1: uzivatel_1 sa odhlasi
time 2: uzivatel_2 posle utok na uzivatela_1
time 3: mal by sa skoncit update (nedoslo k vyhodnoteniu a zapisu do DB lebo uzivatel_1 sa stale neprihlasil, to znamena ze v DB je stale len informacia kedy k tomu ma dojst)
time 4: malo by dojst k utoku uzivatela_2 na uzivatela_1, ktory sposoby downgrade tazby o 1 lvl
time 5: uzivatel_1 sa prihlasi => musi sa vyhodnotit vsetko vyssie

a teraz:

myslienka je to tahat z DB chronologicky a hned spatne zapisovat vyhodnotenie kazdej situacie a znova nacitat vsetko co sa ma udiat a znova zapisat (pride mi to dost krkolomne, pomale a drevorubacske => asi isto to nebude spravne riesenie, no nic ine funkcne mi nenapada)

Ja sa pyta ako sa riesia podobne veci. Je mozne to pri feeeeeest dobrom navrhu spravit aj staticky alebo sa nevyhnem socketom (nodeJS alebo nieco pod.), pripadne da sa to ROZUMNE, resp. je rozumne spravit skript, ktory bude bezat na servri ako timeline a spracovavat vsetky zmeny co sa udeju? Proste co je spravne riesenie? Moje vedomosti ohladom webovych technologii, ktore momentalne mam toto nezvladaju
Dik za info

Pytajte sa ak nechapete

Najlepsie riesenie ktore takto narychlo vidim je ukladat si taketo zmeny do osobitnej tabulky, kde bude teda zaznamenane o aku zmenu sa jedna a kedy sa ma vykonat. A ako si pisal, tak na serveri nechat bezat skript, ktory to z tejto tabulky bude v spravnom case vytahovat a realizovat. Kedze taketo nieco moze byt na databazu celkom zataz, mozno by si sa mohol pozriet na nejaku databazu typu Redis.

Tym linkom na crona mam chapat, ze on sa ma starat o vyhodnocovanie veci z danej tabulky v DB?

na toto je najlepsie pouzit queue / job systemy. Napr. laravel framework ma podporu pre queues a ako backend vie pouzit bud databazu (ale to nie je idealne z hladiska performance), redis alebo ine systemy ktore sa specializuju na queues.

https://laravel.com/docs/5.2/queues#delayed-jobs

Na to netreba ani cron, ani node.js, ani sockety, ani zaiden shedulery. To ide spravit cistou aplikacnou logikou - lazy evaluation

Takze modluva situacia:
- poiuivatel 1 je odhlaseny, pouzivatel 2 vykona nejaku akciu, ak sa tyka pouzivatela 1 musis vyhodnotitaktualny stav pouzivatela 1.
- pouzivatel 1 je odhlaseny, pouzivatel 2 zada akciu ktora v case o X casovych jednotiek bude interagovat s poiivatelom 1. Pouzivatel 2 sa odhlasy. Ubehne X casovych jednotiek. prihlasi sa lubovolny pouzivatel a vtedy sa vyhodnotia stavy oboch.

Tak sa to da spravit len ak sa jedna o velmi jednoduchu aplikaciu resp. prototyp. Na vacsom projekte to velmi zneprehladni kod a zneefektivni vykonavanie. Napriklad, ak bude chciet niekde inde vypisat zoznam vsetkych hracov tak mozno bude musiet u kazdeho kontrolovat ci stav je aktualny a prepocitat ho. Dalej ak sa ma presne v tom case vykonat nejaka akcia ako napriklad odoslanie nejakej notifikacie niekomu tak sa to tiez neda spravit tymto sposobom.

Ked chceme mat elegantne riesenie, ktore je aj rozsiritelne tak treba pouzit nejaky delayed jobs pattern.

Praveze nie, toto ide pekne zakryt domenovym modelom. Rovnake to je aj zo zoznamom vstekych hracov. Tam rozdiel nie je.
No notifikacie su druha vec, v tomto pripade by som som aplikacnu vrtvu nechal rovnaku a jdne co by nashedulovany task spravil, by bolo, ze by prebehol vsteky neakualne stavy.

aj tak je to imho zbytocne zvysena komplexnost modelu a performance loss, kedze zmeny stavov neprebiehaju asynchronne. schedulovany task je dost dirty riesenie.

harrison314 napísal:Na to netreba ani cron, ani node.js, ani sockety, ani zaiden shedulery. To ide spravit cistou aplikacnou logikou - lazy evaluation

Takze modluva situacia:
- poiuivatel 1 je odhlaseny, pouzivatel 2 vykona nejaku akciu, ak sa tyka pouzivatela 1 musis vyhodnotitaktualny stav pouzivatela 1.
- pouzivatel 1 je odhlaseny, pouzivatel 2 zada akciu ktora v case o X casovych jednotiek bude interagovat s poiivatelom 1. Pouzivatel 2 sa odhlasy. Ubehne X casovych jednotiek. prihlasi sa lubovolny pouzivatel a vtedy sa vyhodnotia stavy oboch.

Ja som sa to snazil robit presne tymto sposobom. Nechcel som ale vyhodnocovat vsetkych uzivatelov, ktori by existovali cez akciu kazdeho jedneho single uzivatela. Prislo mi to vykonovo narocne (dojem, nestudoval som teoriu tych veci). V principe sa to nelisi od mojej myslienky vykonavat veci chronologicky pri aktivite nejakeho uzivatela, ktoreho sa tyka interakcie danych uzivatelov. Cize vyhodnotit jeho a dalsieho "naviazaneho". Presne takou logikou aku som spominal v prvom poste. Pti tej modelovej situacii sa mi nepacilo nasledovne. Uveniem an prikalde, aby to nebolo len takto teoreticke a nic nehovoriace. pouzijem ten priklad z prveho postu a aby sa to zle necitalo, tak este raz

time 0: uzivatel_1 zada update minigu surovin z lvl 1 na lvl 2 (tento update skonci v case time 3)
time 1: uzivatel_1 sa odhlasi
time 2: uzivatel_2 posle utok na uzivatela_1
time 3: mal by sa skoncit update (nedoslo k vyhodnoteniu a zapisu do DB lebo uzivatel_1 sa stale neprihlasil, to znamena ze v DB je stale len informacia kedy k tomu ma dojst)
time 4: malo by dojst k utoku uzivatela_2 na uzivatela_1, ktory sposoby downgrade tazby o 1 lvl
time 5: uzivatel_1 sa prihlasi => musi sa vyhodnotit vsetko vyssie

Mojou logikou by to zbehlo takto.

1. vybrali by sa vsetky timestampy ukoncenia danych akcii pri aktivite uzivatela_1 v case t5 a usporiadali od najnizsieho
2. prepocitavanie udalosti
2.1 spocitam vytazene suroviny od casu time 1 po cas time 3 pretoze tu nedoslo k ziadnej zmene zapisem do DB
2.2 spocitam vytazene suroviny od casu time 3 po cas time 4 pretoze dojde k zmene a zapisem do DB
2.3 vyhodnotim utok, znizim lvl miningu z lvl 2 na lvl 1 a zapisem do DB
2.4 spocitam vytazene suroviny od castu time 4 po cas time 5

Samozrejme som uvazoval, ze medzitym sa uzivatel 2 nerpihlasil, ak by sa niekde v strede povedzme medzi casmi t3 a t4 prihlasil, tak by doslo k vyhodnotenie vsetkeho az po jeho prihlasenie, pretoze je v interakcii s uzivatelom 1.

Tie notifikacie by bol problem, nad tym som sa nezamyslal (aby bezali nejak "real time"). Nepochopil som ako si to myslel. U mna jedina myslienka ajax volanie a vyhodnocovanie nevyhodnoteneho (znova drevorubacske a vykonovo narocne riesenie z mojho pohladu a hlavne by to povyhodnocovalo vsetko v DB, tak zbytocne by som vo vela pripadoch mal toby kodu na lazy evaluation).

ropman napísal:na toto je najlepsie pouzit queue / job systemy. Napr. laravel framework ma podporu pre queues a ako backend vie pouzit bud databazu (ale to nie je idealne z hladiska performance), redis alebo ine systemy ktore sa specializuju na queues.

https://laravel.com/docs/5.2/queues#delayed-jobs

Ten queue framework vyzera zaujimavo. Ked uz pre nic, tak zo zaujimavosti sa na to pozriem.

Rozumny objektovy model nie je nikdy overhead a komplexnost sa nim rozbija. No to je na inu diskusiu.
To ako to implementuje zalezi od poziadaviek.

lazy evaluation je sice super ale zlozita... hocico na styl message queue je 100x jednoduchsie

Mne lazy evaluation nepride zlozita
Aj message queue je podla mna fajn.
ja by som sa az tak nebal poklesu performace. Pretoze pri kazdej interakcii sa musi vyhodnotit aktualny stav, pricom naplanovanie interakcie je tiez interakcia.

tak rocket science to zrovna nie je ale tak si to porovnajme:

Lazy evaluation:
1. Vznikne interakcia.
2. Zistis ci interakcia zahrnuje inych offline hracov a zostavis zozname updatov.
3. Uzamknes cast zoznamu ktora sa tyka offline hracov aby ich nezacali vykonavat ak sa prihlasia v nevhodnu dobu.
4. Vykonas operacie

Message queue:
1. Vznikne interakcia
2. Posles o tom spravu do queue.


Prve je vacsia zabava nakodit a druhe je celkovo elegantnejsie riesenie.

OK, s msg queue s stretavam prvykrat v zivote. Ideologikcy (blokovo) ako by sa ten moj priklad al napisat cez msg queue? A ako to cca funguje. V par vetach.
Anyway, pride mi najrozumnejsia nejaka technologia takeho charakteru, ze poslem "co chcem spravit a kedy to spravit" a v danom case zbehne vykonanie toho "co chcem spravit".

javatar napísal:Message queue:
1. Vznikne interakcia
2. Posles o tom spravu do queue.

Toto je sice fajn, ale co potom? Tam to musis spracovavat tak isto.

S.T.E.A.L.T.H:
Uplne najprimitivnejsie riesenie

1. Mas prioritny front obsahujucy operacie ktore je potrebne vykonat
2. Akykolvek hrac moze donho vkladat ked je to potrebne
3a) Mas osobitny proces ktory ho spracovava, v takom pripade nevkladas veci do frontu ale posielas ich tomu procesu nech sa zbavis concurrency problemov
3b) Vzy ked sa niekde prihlasi tak sa front zamkne a vykona sa vsetko az do momentalneho casu

//autoeditácia príspevku (06 Máj 2016, 14:22)

harrison314 napísal:Toto je sice fajn, ale co potom? Tam to musis spracovavat tak isto.

Message Queue nie je len udajova struktura. Mal by sa o svoje spravy starat sam.

javatar napísal:Message Queue nie je len udajova struktura. Mal by sa o svoje spravy starat sam.

Viem co to je.
Mna skor zaujimalo, ako tie spravy potom spracujes, co si napisal.

OMG vsak tam to zavisi od implementacie. Nech si uz on ucri ci chce mat spravy ulozene v DB a bude mu kazdych x sekund bezat scheduler ktory bude spravy premienat na sql prikazy a executovat ich alebo mu bude na serveri bezet proces/service ktora bude robit defacto to iste.

Ak si fakt robi projekt len pre seba tak by som sa performance velmi nepozeral, aj tak sa naexperimentuje dost.
Ak to urobi stylom 3b tak mu nic specialne netreba. Len ten prioritny front.

Vdaka zatial za rady, budem sa s tym hrat

//autoeditácia príspevku (09 Máj 2016, 14:38)
Este sa spytam jednu vec, a to na "lockovanie". Ked budem pouzivat mysql, kde budem mat ulozene timestampy udalosti, ktore sa maju vykonavat, bude stacit pouzit tranzakciu na zabranenie updatov od inych uzivatelov alebo ako by som to mal locknut? Nikdy som sa tym nezapodieval, nebolo potrebne. Vdaka.