MASSIV Massively Multiplayer Online Game Middleware
 

Massiv - Meetings

Info

  • Zakladni historie vyvoje projektu MASSIV (schuzky, udalosti).
  • Datum tvaru DD.MM.YYYY.
  • S(Stepan), V(Markoid), B(Petr), O(Octa), M(Marek), H(Martin), T(Tuma)
2.4.2004
  • Projekt uspesne obhajen.
1.4.2004 [SVBOM ]
  • Zkouska prezentace projektu na necisto u Octy.
  • Predvadecka Far Cry a Warcraft III na datovem projektoru.
26.3.2004 [S OM ]
  • Predvadeni projektu u oponenta pred obhajobou. Yaghob se tvari spokejene. Naivne sami upozornujeme na nedostatky, kterymi projekt trpi. Tyto informace pak Yaghob pouzije u obhajoby proti nam.
17.3.2004 [SVBOMH ] (3 dny)
  • Posledni hacks pred odevzdanim 18.3.2004. Markoid opravuje zavaznou chybu v Node database.
7.3.2004 [S BOMHT] (1 den)
  • Dopoledne predvadecka u Tumy.
  • Opet weekend hacks u Stepana. Opravy replikacniho protokolu a poslednich chyb pred odevzdanim projektu 18.3.2004.
  • Nektere featury byly pro jistotu trapne vypnuty (docasne), misto toho, aby se doladily.
  • Cteni dokumentace a opravy.
8.12.2003 [SVBOMH ] (2 dny)
  • Dalsi weekend session u Stepana. Opravy dalsich chyb.
  • Ukazuje se, ze projekt nemuzeme do terminu odevzdat. Nekteri clenove naivne doufaji, ze se podari behem nasledujiciho tydne napsat dokumentaci a spravit jadro plus demo.
30.11.2003 [SVBOMH ] (3 dny)
  • Weekend hacks u Stepana. Cilem bylo rozchodit konecne Demo (zejmena spravit dobre zname chyby v jadre) a pripravit projekt k odevzdani planovane na prosinec 2003.
  • Ukazalo se, ze spousta veci nechodi a nejsme je schopni behem vikendu spravit. Rada jinych chyb ale byla opravena.
  • Porad se jeste doufa, ze se chyby podari do pristiho vikendu (nejpozdeji na nem) spravit.
  • Parba na GameCube.
12.9.2003 [SVBO H ] (4h)
  • Schuze na Male Strane po prazdninach. Pokec o aktualni versi, planovani dalsiho vyvoje jako je user-friendly sprava serveru ci archivu, automaticke vytvareni accountu ci zmeny v jadre a v libu. Jak je zvykem na schuzich bez vedeni, jednalo se spis o ruzne veci kdo zrovna mel co na srdci, nez schuze s jasnymi body ci zaverem. Jako obvykle se projevovalo znacne odskakovani od tematu ci ladeji serveru na pritomnem pocitaci.
23.6.2003 [SVBO HT] (4h)
  • Schuze s vedoucim. Probirany veci ohledne obhajoby projektu - kdy bude hotovo, na co se zamerit, co vynechat (load balancing, bandwitch limitation). Na obhajobe bude nutno pokec o archivaci, proc byla zavrzena nekonzistentni zaloha, a take se bude hodit srovnani s jinyma MMOxxx enginama, v cem jsme lepsi apod.
  • Resena reprezentace mapy. Vysledek chceme ala Populous 3. Vyskova mapa pro kazdy sektor, kolize entit jen jednoduche pomoci flaziku v tilech mapy. Reseno jak delat napr. vybuchy, ktere se musi projevit do okolnich sektoru - udalosti maji radius a rozesilaji se okolnim sektoru do dane vzdalenosti. Nutne zrejme budou i jine udalosti, ktere se nebudou rozesilat po sektorech, ale primo se poslou danym entitam (pripadne replikam).
  • Stoupik a Markoid sepisuji plan co je nutno udelat na klientovi pro co nejvetsi pokroky smerem k obhajobe.
  • Probirany dalsi veci jako data manager ci jakym zpusobem bude klient pracovat s rsa klici apod.
9.6.2003 [SVBO H ] (3.5h)
  • Probirano vykopani nekterych casti object id mimo (class id, archivable flazik). Archivable flazik bude dynamicky (vyuziti pro rpc zpravy) ulozen primo v objectu, pri nacitani z archivu se nastavu na true.
  • Reseni dalsi veci v jadru - rpc zpravy, data mnager, ...
  • Probirano jake formaty pro modely apod. Skeletalni animaci asi nebudem uvazovat, pro jednoduchost zustanem u klasickych animaci modelu pomoci keyframu, nebot k tem budeme mit jednoduse data.
  • Stepan ma za ukol do tydne zprovoznit jednoduchy (zatim jen 2d) renderer.
  • Reseny potencionalni moznosti budoucnosti massivu, v soucasne versi asi nic moc vyhlidky.
  • Naplanovana schuze s vedoucim za 14 dni.
27.5.2003 [SVBO ] (3.5h)
  • Synch rpc - idea threadovaneho zpracovani synchronnich volani, aby caste volani srpc nezpusobilo neustale zanorovani rekurze hlavni smycky. V jednom okamziku bezi prave jedno vlakno, pri prijmu resultu pro nejake vlakno se dane vlakno probudi.
    Problem s archivaci - dokud existuje aspon jedno srpc volani, nelze zacit archivaci, a proto stejne srpc volani nesmi byt mnoho.
  • SRPC server -> client zakazano.
  • SRPC client -> server asi pujde udelat, jen se musi v requestu pridat dalsi object id nodu klienta, aby se poznalo, kam odpoved poslat.
  • SRPC na replikach (pokud je replika pritomna, lze u funkce rict, ze se ma zavola primo na replice) nebude. Dalsi zbytecna feature, pro kterou zatim neni pouziti.
  • Vycisteni Objectu - oddeleni publiv/private interfacu, automaticke pripichovani pri vyvolani funkce apod. Vycisti Markoid.
    Mne nic nerikajici obrazek (snad takhlen nejak):
    Object -> ObjectProperty / invoke_xxx -> pin -> Object::xxx.
  • Problem volani rpc na potomcich, ktere neznam (ale mam jejich class id). Nutno upravit object pointery.
  • Reseny kompilacni problemy - namespaces v libu a kolize stdext s microsoftimy headery.
14.5.2003 [SVB H ] (4h)
  • Reseno skryti serveroidnich entit pred klientem. Hlavni problem je, ze pokud bychom chteli replikovat cast entity (pozici), musi klient znat vsechny tridy z entity zdedene, protoze pri replice dostane object id objektu, a ten bude mit dane class id. Proto je nutno zavest neco jako ClientEntity, na kterou ma entita odkaz, replikace entity na klienta se deleguje pres replikaci ClientEntity.
  • Reseni replik a jak vubec animovat a resit "oneshot" udalosti typu (ted zde nastala exploze; hrac zmenil zbran; ...). Oneshot udalosti asi nejde moc delat pomoci obecneho replikacniho protokolu. Idea posilat specialni udalosti replikam na klienta? Stepan dostal za ukol to prostudovat.
  • Chceme nejak resit pridavani novych klientu za behu - pouzit data manager? Zrusit informace o nodech z registry.
  • Lib: Resena hiearchie trid. Velka debata, skoro flameware. Markoid prosazuje vicenasobnou virtualni dedicnost s hafem interfacu, stoupik a boovie prosazuji celou zakladni funkcnost do jedineho objektu (entita - fyzika, visual, logic).
    Debata se zvrhla v debatu, ktery BSPator byl lepsi a rychlejsi, dynamicka/staticka alokace vertexu :-)
  • Object: Zavest jednotne pojmenovavani funkci, aby nekolidovaly jmena funkci s libovyma rozsirenima?
  • Lib: Mapa - Jak na sousedni sektory, jak na oblastni dotazy, a jak na relikace ze sousednich sektoru na klienta.
    Idea: Replikacni grupa - ne cely sektor, ale mnozina "vlastnenych" datovych obektu (entita a jeji batoh, ...). Zda se objekt replikuje, uz pak rozhoduje logika libu (napr. nereplikuji se neviditelne entity).
  • Reseni veci ohledne IDL a sync/async volani (rpc objekty).
7.5.2003 [SVBO H ] (3.5h)
  • Kolize - jen trivialni jako klasicke 2d, zadne pretlacovani apodobne vychytavky.
  • Timesync s NTP serverem zatim ne, hlavne doladit chybky v aktualni versi.
  • Marekus - nejak se neozyva, navic ma brzy odjet pryc - je nutno zprovoznit blowfish exchange bug a dokoncit jeho zdrojaky.
  • Debatovani o sync rpc. Zda to ma byt vlastnost funkce nebo pointeru (zrejme funkce). Jak ziskat out parametry z resultu. Vyreseno odsouvani udalosti, kdyz udalost nemuze byt provedena (objekt pinned apod.).
  • Probirano nove IDL. Prenos GC root vlastnosti z dedicnosti do IDL.
  • A dale probiran klasicky mix vsech problemu, jak koho zrovna napadlo.
26.3.2003 [SVBOMHT]
  • Predvadecka dema u vedouciho. Predvedeni zakladni verse konzole a nekolika prikazu.
  • Probrano co kdo udelal, nejake plany do budoucna.
19.3.2002] [SVBOM ]
  • Normalni schuze, ale zapis se asi ztratil, takze strucne.
  • Pripravy na novy system #include. Jak opravit mingw linkovani -\).
  • Jak resit zalohovani treba accountu, protoze nelze zaarchivivat stav tak jak je, resp. nelze jej unarchivnout. Asi nejaky callback pri nacitani zalohy - vsechny accounty se naswapuji a vyvola se callback na procisteni dat pred vlastnim spustenim simulace.
  • ...
6.3.2003 [SVBOMH ] (3.5h)
  • Probirany veci ohledne rpcgenu, namespacy apod.
  • Probirano pausovani casu na server - zda ma byt moznost zapausovat cas. Pak je problem jak resit dorucovani zprav od adminitratora a vubec aby mohl admin neco provadet v simulaci. Zrejme pausovani bude ponechano na skriptu, bude to vyhodnejsi pro obe strany.
  • Predvadecka demo klienta a servera na Octove notebooku. Krome nekolika bugu mel uspech :-)
  • Marekus dostava za ukol prekopani vyjimek a logeru.
  • Kazdy by si mel vyzkouset napsat nejakou jednoduchou Lib, aby si vyzkousel praci s IDL a pointery.
  • Probirano jak udelat system krabicek posilajicich si impulsy jako v Q-cku v Quarku. Hlavne by si to meli promyslet Octa a Haf.
19.2.2003 [ VB MH ] (3h)
  • Reseno nazvoslovi ve strukture demo hry. Jak prejmenovat skript, jake codename pro demo. Navrhy v mailech.
  • Probirano jak ma vypadat pack/unpack utility na volume soubory, s tim souvisejici pack/unpack na archivy, a odpovidajici zmeny ve filesystemu (iteratory ve volume). Vseho se ujima Marekus.
  • Haf dostava za ukol podpurne struktury pro skript - zatim 3d vector (plus odpovidajici property).
  • Probirano jak reprezentovat v demu mapu, pohyb entit po ni, kolize, reprezentace replik. Zrejme bude jen jednoducha reprezentace (co se tyce migracni skupiny) - ctvercovy sektor, ktery ma linky na sousedni sektory a entity; lokalni optimalizace (typu octree apod.) se uz stara mimo migracni skupinu. Dalsiho zpracovani (a zmen) se ujima Markoid.
  • Resen dalsi postup pri inicializaci skriptu - vytvareni account objektu, node objektu, callbacky z jadra do skriptu apod. Co nejrychleji se pokusi Boovie zprovoznit, tak aby se daly psat jiz finalni skripty.
  • Reseny otazky sjednoceni konvence system time, massiv time a simulation time, a souvisejici upravy v time manageru.
5.2.2003 [SVBOMH ] (4h)
  • Reseni startupu systemu - initial archive, ziskani referenci na zakladni objekty, aby vse mohlo bezet.
  • Probiran stav PVectoru a jeho serializace a vyuziti ve skriptu.
  • Jsou "dobre a slozite" replikace (serializace) k necemu uzitecne (napriklad chytry PVector)? Kdyz nekdo chce replikovat velke pole tak je stejne divny...
  • Resena struktura napojeni client node objektu, account objektu a server node objektu. Jak mezi sebou budou komunikovat, jak se budou vytvaret a zalohovat. Je nutno napsat jejich IDL apod.
  • Probirano jak asi bude fungovat console a prikazy posilane na server.
  • Plan na 14 dni,aby se rozchodilo pripojovani klientu, account objekt, konzole (ukazka pro Tumu).
14.1.2003
  • Projektove komisi odeslana finalni verse zpravy o stavu projektu po roce.
9.1.2003 [SVBO H ] (2.5h)
  • Prvni schuze po svatcich.
  • Probirany jak by mela fungovat komunikace klienta a server. Napriklad manipulace s inventorarem. K nicemu poradnemu se nedoslo, spousta otevrenych problemu.
  • Probirano jak by mohl vypadat klient - jednoduchy 3D pomoci opengl. Multimedialni knihovny by mel psat Stepan, mozna i vyuziti zdrojaku ze starsich projektu, nicmene Stepan se nejak flaka a tudiz ma hodne prace a malo casu.
  • Je nutno dodelat repliky v jadre. Stepan se k tomu stale nema.
  • A dalsi diskuze o rucnych vecech, na coz si uz nevzpominam.
  • S Tumou doresena finalni verse zpravy pro projektovou komisi.
5.12.2002 [SVBOM T] (3h)
  • Schuze na Male Strane - nejdrive kecaci schuze clenu teamu, pozdeji schuze s vedoucim.
  • Probirany testovani a implementace sitove verse. Jak rozchodit testovaci servery s funkcni siti.
  • Probiran postup praci. Ukazany debug vypisy server testu "local_migration".
  • Rozdany ukoly. Do konce roku moc casu nezbyva, nutnost dopsat zpravu pro komisi a hruby roadmap do finalni verse massivu. Podrobnejsi zapis viz. shrnovaci mail od Tumy.
  • Probirany personalni problemy Hafa. Delsi rozprava obecne o personalnich zmenach. Vyreseni prevzal na sva bedra vedouci.
7.11.2002 [S BO HT] (2.5h)
  • Schuze na Male Strane s vedoucim. Probiran aktualni vyvoj - veci, ktere mely byt hotove a (ne)jsou. Hruby plan na dokonceni a otestovani jadra tak, aby bylo provozu schopne.
  • Az na nejake drobnosti asi nic vic zajimaveho.
31.10.2002 [SVB ] (3.5h)
  • Diskuze o GC, pinned objektech, synchronnim RPC aneb jak to vsechno rozhodit spolu s archivaci. Vysledne reseni RPC se zda byt daleko jednodussi, nez se puvodne predpokladalo. Info bude pridano do develop docu na cvs.
  • Trohu natuknuta safe serializace a obecne komplikace s replikama, pri serializaci object pointeru.
  • Obecne lamentovani na nekterymi cleny teamu a zdrojaky. Planovani dalsi schuze s Tumou na Male Strane.
  • Stoupik neustale usinal.
  • Nevyreseno co s broadcast searchem.
14.10.2002 [SVB MH] (3h)
  • Stoupik si vyjasnoval nejake veci ohledne generovani factories.
  • Vyjasnovani Hafovi, co vlastne chceme po versovani dat, snad uz je vse jasne.
  • Probrano jak udelat archivaci s podporou vlaken - o komunikaci s vlaknem se nebude starat primo object manager nebo archiv, ale az volume (resp. zapisovani do souboru).
  • Probiran komunikace mezi Nody (ala poznamky z communication.txt) - problemy s objekty na klientu, migrace z/do klienta, pripojovani klienta apod. Vysledky budou shrnuty do communication.txt.
  • A dalsi implementacni veci (templaty, kompilatory, ...).
7.10.2002 [S OMH]
  • Zapis chybi (Stoupik muze nekdy dodelat :) Probirany pravdepodobne veci tykajici se sitove vrstvy a ukoly pro Hafa.
3.10.2002 [SV OMHT]
  • Schuze na Male Strane u vedouciho. Probiran aktualni stav projektu po prazdninach. Vypracovan predbezny plan na dokonceni jadra massivu.
  • Probirana zprava o projektu, potencialni vyhazova Hafa. Odevzdani zpravy komisi nespecha, staci az v ledni 2003 (rok od oficialniho startu projektu).
1.7.2002 - 1.10.2002:
  • Prazdniny.
1.6.2002 - 1.7.2002:
  • Zkouskove obdobi.
20.5.2002: [SVBO H]
  • Objevuje se znova moznost odswapovavat objekty na disk, pokud na ne neni dlouho pristupovano. Puvodne myslenka odswapovavat objekty, ktere jsou aktivni pouze pokud je pripojen odpovidajici hrac. Jednalo by se o neprilis slozitou modifikaci ObjectPointeru, dalsi zmeny v ObjectManageru, ale nic sloziteho.
  • Problem komunikace client/server - jak identifikovat klienty (vlastni serverid, serverid prejmenovano na nodeid), jak vubec pripojovat klienty k simulaci - chceme (asi) vsechno aby behalo na stejnych protokolech jako simulacni servery (nechceme "prasit" specialni pripady pro clienty). Je nutno to co nejdrive navrhnout poradne (a finalne).
  • Debaty o vsem moznem, nesetrideno...jak ma fungovat versovani souboru; jak je posilani eventu ovlivneno garbage collectorem; organizace schuzek pres zkouskove obdobi pripadne prazdniny; a dalsi implementacni detaily...
13.5.2002: [SVBOMH]
  • Debata o serializacich a migracnich skupinach. Strucne shrnuto: Co se replikuje z objektu se urcuje podle ciloveho objektu - factory ciloveho objektu vraci masku, se kterou jsou testovany property, zda se maji replikovat. Podobne jsou urcovany, ktere objekty patri do replikacnich skupin (vlastnost object pointeru).
  • Debata o dalsim reorganizovani zdrojaku - casti nesouvisejici s massivem a spravou objektu oddeleny jako samostatne, na massiv nezavisle, knihovnicky.
  • Debata o tom, jak bude presne fungovat schedulovani udalosti, jak jsou organizovany v lokalnim schedule, a jak jsou prenaseny pres sit.
  • A dalsi debaty o implementacnich problemech.
  • Pridany dalsi ukoly pro nektere cleny teamu:
    • Marekus - Vyssi vrstva sitoveho interface.
    • Haf - Krome nerozmysleneho versovani souboru, obecny, os independent vlaknovy api s jednoduchymi zamky.
    • Ostatni maji praci naplanovanou.
6.5.2002: [SVBOM ]
  • Velka debata o garbage collectoru - zda budeme delat obecny, distribuovany - vyuziti v simulacich, ktere uvazujeme, bude minimalni, navic je distribuovana verse slozita (prostorova i sitova narocnost, aby fungoval velke timeouty) a nikdo nevi zda by to opravdu fungovalo. Nakonec rozhodnuto, ze se GC bude delat, ne vsak distribuovany, ale pouze lokalni na kazdem serveru. To znamena, ze nelze mit strong pointer na vzdaleny objekt.
  • Naznak problemu pri prevodu stareho save sveta na nove verse skriptu - slozite, nejde delat zcela automaticky. Napriklad problem identifikace property v objektu, kdyz dojde ke zmenen hiearchie predku apod.
  • A dale probirany ruzne implementacni veci - sit, registry.
29.4.2002: [SVBOM ]
  • Debata ohledne implementace low-level sitove vrstvy. Sprava paketu a sitovych streamu. Pokud chce nekdo poslat paket, zazada si o sitovy stream a po naplneni jej "unlockne". A dalsi hafo implementacnich detailu.
  • Probirany detaily ohledne migrace objektu. Jak vykonsturovat objektu ze streamu, aby se spravne zrestaurovaly tucne pointery. Nemoznost migrovat repliku. Dokud neni objekt dorucen (muze cekat na nejakem serveru na dokonceni broadcastu), tak je pausnuty, vsechny zpravy pro nej jsou pozastaveny.
  • Debata o reprezentaci vyhledavacich struktur (mapy apod.), jak informovat (a zda je vubec nutno) objekty, kdyz jsou replikovany ci presouvany na jiny server. Jak vubec tyto struktury zalohovat, lepe receno jak je "unarchivovat" pokud se maji rozmistit na jinou strukturu serveru nez byla zaloha. Problem stale otevren.
22.4.2002: [SVB MH]
  • Probirano nekolik variant jak by mohlo fungovat hledani objektu a updatovani cache provideru. Ponechano na Booviem at si teda vybere kterou chce, neb vsechny jsou asi stejne (malo) efektivni a tezko odhadnout jak se to nakonec bude chovat v realnem provozu.
  • Probirano jak preprasit adresarovou strukturu na cvsku (public/private zdrojaky pro uzivatele apod.). Hlavnim bastlirem zvolen Markoid.
  • Zacaly se pouzivat tasks a bugs na sourceforgi. Bugs pouzivat i pro dotazy a komentare na nejasnosti ve zdrojacich.
  • Natuknuto jak bude vypadat broadcast.
  • A dalsi implementacni dohadovani.
15.4.2002: [SVBOM ]
  • Net - Vlastni reliable posilani paketu nad UDP nebude, vyuzije se pro reliable primo tcp/ip. Pro kazdeho klienta se vytvori dve spojeni - tcp/ip i upd soucasne.
  • Je nutno vymyslet strukturu serveru pro potreby brodcastu, globalni hledani objektu a pro detekci spadleho serveru. Zatim nechceme broadcasty "kazdy s kazdym".
  • Archivator - Mozna pobezi v jinem threadu (bude dostavat data od object manageru a plivat je na disk).
  • Archivace objektu pri zapisu, kdy se jeho stav ulozi do streamu - primo se zapise ve tvaru, ktery se bude zapisovat v sejvu na disk (takze to bude stringoidni stream).
  • Nutno udelat poradek ve vyjimkach a statusech. Ve statusu kody budou rozdeleny do skupin podle odpovidajicich facilities.
  • Probirano bublani zaspinovani pro vektor, jak naimplementovat. Pokud chceme chytry vektor (pri read pristupu pro operator[] se bezaspini), tak naroky na pamet vektoru zrostou nekolikanasobne.
  • Probirano jak udelat generator object factories (problemy s templaty, ...).
8.4.2002: [SVBO H]
  • Probirany implementacni veci ohledne sitove vrstvy.
  • Probiran garbage collector.
    • Ma smysl povolovat strong pointer na vzdaleny objekt? Chceme takhle universalni system? Pak by stacily lokalni garbage collectory.
    • Neudelat ekvivalenci tucny pointer == strong pointer, netucny pointer == weak pointer?
    • Pri obecnem GC problem kdyz nektery server nepojede (nemuze se zrusit zadny objekt, co kdyby na nej nekdo ukazoval z nebeziciho serveru).
    • Probirano jak to zkomplikuje/zjednodussi programovani skreta nahanejiciho Bendera :-)
  • Nesmi se ukazovat (vytvorit pointer) na member objekt.
  • U property nestaci jen odkaz na hlavni objekt (zaspineni sebe + hlavniho objektu). Zaspinovani bude bublat postupne nahoru az k hlavnimu objektu. Property bude mit odkaz na nejblizi "nad" objekt. Tucny pointer ma odkaz na hlavni objekt.
  • Syncovani casu : Syncovat se bude vuce nejakemu master serveru (a ten muze mapovat presne virtualni cas na realny cas). Pokud nebude dostupny, server se bude syncat s ostatnima tak, aby meli cas zhruba stejny jako ostatni (pak jiz nemusi odpovidat presne mapovani virtualniho casu na realny cas).
  • Vytvoreni tucneho pointeru na repliku musi hodit error.
  • Prekopat adresarovou strukturu, dat nekam common veci, aby napr. net library neikludovala z core. Vypichnout includy (jak bude skript inkludovat veci z core). Jsme toho aktualne vubec schopni?
1.4.2002:
  • Velikonoce.
18.3.2002: [SVBOM ]
  • Probirany problemy prekladacu pri kompilaci jadra massivu. Asi optimalizacni bug v msvc 6 i 7. Hodilo byse vyzkouset jine kompilatory (pod windowsema).
  • Skupiny objektu - Udrzuje se graf spojeni objektu podle pointeru. Kazdy objekt si drzi mnozinu sousednich objektu ve skupine (objekty, na ktere ukazuje, nebo objekty, ktere si ukazuji na nej).
  • Tucnost a dalsi flagy se drzi pouze v Property, ne v ObjectPointeru.
  • Zakazat template ve skript objektech ano ci ne? Nakonec teda tak, ze pokud to kompilatory zvladnou (zatim nezvladnou?), tak proc ne.
  • A dale probirany dalsi problemy - co vlastne ma obsahovat PVector, neustale predelavane serializery, jak to proboha vlastne bude cele fungovat, jak je to se sedmakem ci povinnost mit projekt pri ukonceni studia :-)
11.3.2002: [SVBO H]
  • Probirany problemy se serializery. Kde drzet informaci pro serializer? V typu nebo mimo? Pouzit namemangling? Zakazat templaty uplne pro skriptovaci objekty? Jak vlastne slozity bude IDL (jazyk pro popis skriptovacich objektu)?
  • Properties - Musi byt vzdy owned nejakym objektem nebo je lze pouzivat i lokalne? Nutno zavest nejaky INVALID stav properties, pokud neni replikovana (viz. nize) a pristup na ni (i read) vede k vyjimce.
  • Groupy - skupiny objektu. Hodi se rozlisovat near a far pointery (programator skriptu o nich vi). Near pointery tvori ekvivalenci na objektech, jejiz tridy tvori nase skupiny (groupy). Nakonec pointer "nese" tyto informace:
    • Tucnost - 0/1 - Pokud je 1, objekt na ktery ukazuje patri do jedne skupiny z pohledu predavani.
    • Replikacni tagy - Jsou pritomny i u kazde properties.
      • Server tag - To na co ukazuje se replikuje s mym objektem mezi servery.
      • Client tag - To na co ukazuje se replikuje na clienty.
      • Trusted client tag - To na co ukazuje se replikuje na trusted clienty (administratori, game masteri, ...).
  • Tyto bitiky lze umistit bud primo do pointeru nebo do PointerEntry. Zvolena moznost PointerEntry.
  • Pri freeze se kopiruje cely objekt.
4.3.2002: [SVBO H]
  • Je nutno rozlisit delete objektu jako takoveho (napr. pri presunu mezi servery) versus vymazani objektu z cele simulace. Ve druhem pripade je nutno informovat odpovidajiciho providera, aby si updatoval svou cache.
  • Flag tracked_by_provider bude prozatim urcovan podle tridy (per class).
  • Ignorovani exceptionu bad_alloc (napr. v Cache::update() pri vkladani). Kdyz dojde pamet tak jde stejne vse do kytek. Bude pouze reservni pamet, ze ktere new bude brat pamet pokud normalni dojde, system se prepne do havarijniho stavu (v nejblizsim ticku se pokusi neco provest aby zachranil aktualni stav simulace). Pokud dojde i reservni pamet, nezachrani se nic (vyjimka -> konec aplikace).
  • Nekdo by mel vytvorit popis jak zkompilovat Massiv (pozadavky, knihovny, co, kde, jak, proc, pripadne nejake bataky).
  • Octa a Stepan za ukol navrhou high-level sitovou vrtvu.
  • Budou specialni well-known object id, pro identifikaci serveru pro skripty. Predani objektu ze serveru na jiny server proviha stejne jako poslani "zpravy" jakemukoli objektu, jen jako adresat je well-known id nejakeho serveru.
  • Dve hlavni fronty. Prvni globalni systemova fronta - pakety, input od uzivatele. Druha fronta zprav pro jednotlive objekty.
  • Objevilo se nejak ruzne druhy "casu" - lokalni cas pro invalidace cache, svetovy cas simulace pro planovani udalosti (syncovany mezi servery), ...
  • Markoid se stale snazi prosadit svuj garbage collector. Stepan se bezvysledne snazi mu to vymluvit.
19.2.2002: [SVB M ]
  • Member objekty (objekt jako "promenna" jineho objektu) libovolneho typu povoleny:
    • Odkaz z properties vede primo do "hlavniho" objektu (nejvyse v hiearchii), ne na objekt, ve kterem se property nachazi. Heslo tranzitivni uzaver :-)
    • Kazda property vi primo, zda je zamknut objekt, ve kterem se nachazi.
    • Member objekty hazeji assert (nebo vyjimky) pri pristupu, ktery neni urcen pro member objekty.
    • Member objekty nemaji vlastni id.
  • Co je vyhodnejsi? Efektivita garbage collectoru versus efektivita reference counted pointeru na PointerEntry? Zatuhaval by garbage collector simulaci?
  • Pri zapisu do objektu, ktery je oznacen pro zalohovani:
    • a) Vytvorit kopii objektu.
    • b) Udelat primo replikacni blok dat daneho objektu.
    Tezko rict co vlastne bude rychlejsi. Ad b) je asi hezcejsi.
  • Archivacni algoritmus (princip) je hotov - vylepsena verse Boovieho navrhu (ala transponovana matice casu zprav mezi servery).
  • Rozvrzeny ukoly (config variables, replikatory, fronty udalosti, sprava objektu, provideri, ...).
22.1.2002: [S B ]
  • Probiran archivace ala boovieho zpusob. Zda se, ze sepsana verse funguje, i kdyz stoupa ma stale pochyby.
  • Probirano object_id a vyhledavani objektu. Objevila se myslenka, ze vlastne bude mozno jednoduse (az na synchronizaci) precislovat providera a objekty, tzn. napriklad moznost zmenit object_id jakehokoli objektu. Ukol nejak to sepsat poradne.
  • Predavani objektu, jak vlastne bude probihat, co vypadky site. Nutnost nekolika "timestampu" (save_id z archivace, sitovy timestamp). Nakonec zrejme budeme pouzivat vlastni reliable posilani paketu nad UDP.
  • Co s vypadkama site? Zatim to bude znamenat to same jako crash serveru. Do budoucna by se hodilo vymyslet neco lepsiho (ale co zachova konzistenci sveta, zalohy atd.).
  • Probirany dalsi implementacni veci (syntax zdrojaku v net lib, ukoly, ...).
8.1.2002: [SVBOMH]
  • Probirano prubezne zalohovani (ackovani predavani objektu, zachovani konzistence). Nedoreseno.
  • Prvni informace a naznaky o garbage collectoru (zatim ve fazi "to by tam mohlo byt, kdyz uz jsme v tom").
  • Swapovani neaktivnich objektu na disk - mohlo by prinest lepsi organizaci pameti. Ale ma opravdu smysl?
--.12.2001:
  • Vanoce.
18.12.2001: [SVO H]
  • Reseny nejake implementacni veci (script object, int x int32 x int64, vraceni hodnoty i infa jako v STL tedy jako pair bool a hodnoty, psat std:: (ne using namespace std)).
  • Multijazycnost: zatim vse bude delano asscii only (dolnich 127 znaku), podpora unicode asi nebude zadna sranda, zatim si tim nebudeme pritezovat.
  • Rozchozeno opet CVS; ukoly na Vanoce.
11.12.2001: [SVB H]
  • Markoidova prednaska o object factory, script object a properties (vicenasobna virtualni dedicnost mozna i u scriptovacich objektu, rezie za to pry neni velika). (Kdo neslysel neuveri, ze zdrojaku nepochopi :-)
  • To, jak se replikuje property neni v jejim popisu primo, ale mimo jako specialni objekt, ktery je zodpovedny za replikaci dane property.
  • Zverejnena aktualni verse Massiv core a dana do cvs. Nektere casti silne nedokumentovane.
  • Nutno sestavit nejaka pravidla na praci s CVS.
  • Zalohovani - Pokud chceme aby pad jednoho serveru nijak neovlivnil beh ostatnich serveru, muze dochazet k nekonzistencim v hernim svete (a v podstate neni mozna jejich detekce).
4.12.2001: [SVBO H]
  • Masiv core ve vyvoji. Blizsi info neni zatim moc znamo.
  • Shrnuto secure spojeni - bude potreba, ale ted to nijak nehori.
  • Status ve vyjimkach - pouzit i pro vraceni informaci z funkci? Ne, status ma byt jen popis chyb pro logger zprav a navic kazda takova funkce by ovlivnila vsechny zdrojaky (nutno menit headery statusu). Slozitejsi informace z funkci se vraceji lokalnimi enumy.
  • Vyjimky - Nemely by byt alokace behem vyvolavani vyjimek (vyvolani dvou vyjimek soucasne ma za nasledek nehezke ukonceni aplikace). To ovlivni pouzivani napr. stringu ve vyjimkach a zrejme taky logger.
  • Sitova vrstva - Posilani paketu bude napasovano na interface iostreamu. Paket se bude tvarit jako bitovy stream. Jednotlive data se pak budou pakovat na co nejmensi pocet bitu, nutnych pro prenost dat (integery parametrizovane kolik bitu staci pro prenos v paketu apod. Parametrizace je soucasti kodu, neni soucasti paketu.).
  • Je nejaky limit na maximalni velikost UDP paketu?
  • Jak delat prubezny save sveta?
    • Pausa serveru, vsechny objekty se ulozi na disk, pote pokracovani simulace.
    • Jednorazove vytvoreni kopii vsech objektu a pak prubezny zapis objektu na disk na pozadi.
    • Jednorazove se otaguji vsechny objekty. Tyto se pak postupne zapisuji na pozadi na disk. Pri simulaci pokud dojde k zapisu do property objektu a jeste neni ulozen (je otagovan), dojde k duplikaci objektu.
      Problemy: Pri kazdem zapisu kontrola zda je objekt otagovan a pripadna duplikace - vetsi rezie na praci s properties, ale my je chceme co nejrychlejsi. Dalsi problem je nutnost ke kazde property mit pointr na objekt (pro testovani tagy), docela velky narust dat.
    • Stejne jako predchozi, akorat pri otagovani objektu se take zrusi cache pointeru na objekty. Pak kdyz nekdo pristoupi na objekt (nacteni do cache - pristup na id/pointer), dojde k duplikaci objektu. Narozdil od prechozi mznosti neni nutno skladovat pointery na objekty u kazde properties.
      Problemy: Duplikace i pri read cteni objektu. Teoreticky(?) muze dojit k duplikaci skoro vsech objektu v jedinem okamziku.
  • Prubezny save - Pokud pobezi ve stejnem threadu jako simulace, pak je nutno pouzivat asynchronni zapisy na disk. Pokud pobezi v jinem threadu, je nutna nejaka synchronizace se simulaci.
27.11.2001: [SVBO H]
  • Budou se pouzivat IOStreamy (viz. schuzka 26.10.2001 :).
  • Probirano jak na stringy, na cem se vlastne dohodlo?
    Potreba budou dva typy stringu - klasicky asscii charovy a pak nejaky multijazycny (unicode). Logger musi umet pracovat s obema. Multijazycne stringy se musi nejak prevadet do ruznych kodovani pri zapisu do souboru, pokud nechceme unicode soubory (grep apod. asi neumi pracovat s unicode).
  • Probirany moznosti vyuzivat dalsi knihovny (boost?).
  • Standardni vyjimky se neloguji, loguji se pouze vyjimky zdedene z nasi tridy Exception. Vyjimkou bad_alloc (logovani pres handlery?).
  • Layout: Psat using namespace std misto std:: u jmen.
  • Probirany pozadavky na secure spojeni, jak to napasovat na UDP. SSL. Octa by mel na to mrknout podrobneji do priste.
20.11.2001: [ ]
  • Schuzka se nekonala.
13.11.2001: [SVBOMH]
  • Projojeni core a "skriptu": Exportuji se objekty a jejich funkce primo, nebudou virtualni interfacy pro propojeni. To znamena, ze server i skript budou muset byt zkompilovany stejnym prekladacem (se stejnym nastavenim).
    Duvody: Skripty se stejne budou distribuovat jako zdrojaky nebo se budou dodavat spolu se samotnym serverem. Take proto, aby byl maly overhead pro praci s properties.
  • Typy properties nebudou obsahovat pole, ale budou obsahovat string ci vektor. Dalsi rozsireni (mozna i o pole) pozdeji by nemel byt problem.
  • Struktura vyjimek - obshlehnout z javy (delphi?).
  • Ukol zjistit jak funguje SSL (OpenSSL).
  • Myslenka propojeni komunikace vsech serveru jakozto "posilani objektu" - neni pak nutno se zabyvat protokoly na urovni jadra massivu.
  • Uzavren layout zdrojaku.
6.11.2001: [SVBOMH]
  • Novy clen projektu (Martin).
  • Update skriptu - externi skript (perl), ktery to preparsuje versus nacteni sejvu a specialni funkce, ktera to vysejvi do nove verse sejvu.
  • Sprava objektu: Pro kazdeho pripojeneho clienta ma server seznam objektu, ktere se na nej replikuji. Update seznamu dela skript, zatim neresime jak.
  • Planovac bude pouzivat member-pointery.
  • Pro zakladni datove typy zvolena STL (STLPort).
  • Id objektu: Object factory id (mozna mimo id), server id, id counter, flags (muze pretect...).
  • Pad serveru: System zarucuje "kazdy objekt existuje alespon v jedne zaloze". Pri znovunabehnuti serveru komunikace mezi vsemi servery (hledani duplicit objektu).
30.10.2001: [SVBOM ]
  • Hruby narys tvaru skriptovaciho objektu a class (object) factory z pohledu systemu.
  • Property: timestamp - cas posledni zmeny.
  • Property Description: typ (natvrdo v systemu), string name, flagy (admin_only, FIXME: To neprectu).
  • Replikace: Zatim budeme replikovat vsechno.
  • FIXME: Zbytek nejak nedokazu interpretovat z tech zapisku.
  • Komu dorucovat zpravu? Nekdy se hodi adresatovi, nekdy se hodi aby byla informovana samotna zprava.
  • Planovac:
    • Cas - simulacni ticky versus simulacni float cas (+ sitove ticky).
    • Lze planovat vice funkci jednoho objektu. Kazdou naplanovanou funkci lze killnout pomoci builtinu. Pri migraci objektu se spolu s objektem prenasi i jeho fronta naplanovanych funkci.
    • Zacal se vymyslet nejaky sileny system planovace, strasne prolinkovany - zrejme bylo mysleni vsech ovlivneno travenim vecere, neb to byly vcelku nesmysly, takze pominmez.
    • Zatim to vypada, ze planovac bude mit jednu globalni frontu, kde budou samotne objekty, trideno bude podle minima casu naplanovanych funkci v objektu. Naplanovane funkce budou v lokalni fronte pro objekt.
  • Dynamicke atributy (pridavane za behu) - zatim ne (lze je nahradit objekty treba v batohu).
  • Trochu probirano updatovani zdrojaku (problemy pridani ci smazani atributu, funkci apod.).
26.10.2001: [SVB M ]
  • Vyjimky budou pouzity, ale jen pro fatal errory.
  • Probirany STL (STPort), QT, MSVC STL, GNU STDC++, STDC++, SGI STL. Favorite jsou STLPort a SGI STL. Problem s licenci?
  • Zakaz pouzivani IOStreamu.
  • Unicode stringy - zatim nevime, ale nejak resit multijazycnost musime (japonstina, ...).
  • Reseni layoutu zdrojaku.
  • Zrejme budeme pouzivat dokumentaci: Doxygen.
--.10.2001:
  • Vytvorena finalni verse specifikace. Specifikace schvalena komisi.
12.8.2001:
  • Aktivita temu opet klesla k nule, prestoze zacatek prazdnin signalizoval mnozstvi volneho casu pro praci na projektu.
--.7.2001:
  • Schaneni vedouciho. Navsteva u Tumy. Zda se, ze je ochotny delat vedouciho.
jaro.2001:
  • Aktivita teamu blizici se bode mrazu. Team se rozrusta o dalsiho cloveka (Marek). Nasleduje nekolik uspesnych schuzek. Nacez aktivita opet upada. Nejaktivnejsich clenem zustava Stoupik - vznika neudrzitelny soubor poznamek o architekture a mailinglisty na sourceforgi.
22.11.2000:
  • Relativne neuspesny sraz v Troji, kde se nic nevyresilo.
7.11.2000:
  • Team se rozrusta na 4 lidi (Stoupa, Systole, Markoid, Octa).
  • Prehistoricke naznaky distribuovanosti systemu a komunikace.
31.10.2000:
  • "Oficialni" pocatek vyvoje MASSIVu. I kdyz myslenka na vyvoj MASSIVU se formovala uz drive, zde se reklo, ze teda budem delat tohle. V zachvatu euforie vznikl predbezny nazev VSPVIMMHS - Vyvojovy System Pro Vyvoj Internetovych Massive Multiplayer Hernich Systemu :)