massiv-devel Mailing List for Massively multiplayer game middleware

On Fri, 28 Feb 2003, Petr Tovarys wrote:

> 5) Do souboru BIN/massiv.server_nodes.conf
>    do polozky client_node_object_type_id je nutno
>    zapsat class type id ClientNode tridy.
>    To zjistite ze src/demo/lib/factories.list,
>    kde class type id rovno radku na kterem se trida nachazi
>    (v seznamu factories).
>    Cili pokud factories.list vypada takto
>
> # Factory database.
> # Automatically generated by factlist.pl version 1. Do not modify.
>
> FactoryDatabase 1
>
> 1571960449
>
> Demo::Lib::ClientAccount client_account_factory.h
> Demo_Lib_ClientAccount_Factory
> Demo::Lib::ClientNode client_node_factory.h Demo_Lib_ClientNode_Factory
> Demo::Lib::ClientNodeBase client_node_base_factory.h
> Demo_Lib_ClientNodeBase_Factory
> ...
>
>    Tak class type id je "1" (druhy radek, ale cislovani je od 0).


Ehm mail to trochu preformatoval, no dulezite je, na kterem
radku je Demo::Lib::ClientNode.



Jinak by se mela konat schuze v tydnu (ut, st, ct),
mozna i schuze u vedouciho. Kdy kde?

Petr

Caues,
Demo je na cvsku.

Stav zdrojaku:
Vsechno v src/demo jde prelozit.
core/test jde prelozit a jde spustit.
Server testy nejdou prelozit.

Aktualni verse dema nefunguje (po pripojeni
clienta server spadne) kvuli prolemum pri
serializaci properties pri migraci a archivaci,
to snad fixne Stepan brzo.

Jak to spustit (pozdeji sepisu nejake docy na cvs).

1) Necht adresar BIN je adresar, kde je zkopcen
src/demo/config/one_client_one_server/*.

2) Zkompilujte demo_client a demo_server, nakopirujte
binary do odpovidajicich adresaru v BIN.

3) Bezte do BIN/server.
   Spustte "demo_server -s 1 -i".
   Vytvori se inicialni zaloha.

4) Prostudujte vypisy a najdete object id root account objektu
   (jako raw hodnotu). Tuto hodnotu zapiste do
   BIN/massiv.server_nodes.conf
   k nodu cislo 1 do polozky "account_object".

5) Do souboru BIN/massiv.server_nodes.conf
   do polozky client_node_object_type_id je nutno
   zapsat class type id ClientNode tridy.
   To zjistite ze src/demo/lib/factories.list,
   kde class type id rovno radku na kterem se trida nachazi
   (v seznamu factories).
   Cili pokud factories.list vypada takto

# Factory database.
# Automatically generated by factlist.pl version 1. Do not modify.

FactoryDatabase 1

1571960449

Demo::Lib::ClientAccount client_account_factory.h
Demo_Lib_ClientAccount_Factory
Demo::Lib::ClientNode client_node_factory.h Demo_Lib_ClientNode_Factory
Demo::Lib::ClientNodeBase client_node_base_factory.h
Demo_Lib_ClientNodeBase_Factory
...

   Tak class type id je "1" (druhy radek, ale cislovani je od 0).

6) Vytvorte prazdny soubor
   BIN/server/archives/regular/massiv_1.archive/massiv_1.archive.ack

7) Nyni spustte server uz bez parametru.
8) Spusttne clienta.

[[[[
Docasny - 9) Po pripojeni clienta server spadne s hlaskou "dereference
nulloveho pointeru",
protoze mu prisla migracni zprava, ale ta nema zadna naserializovana data
(pointr
na client node object.
]]]



Petr

On Fri, 28 Feb 2003, Stepan Vondrak wrote:

> Jak funguje forwardovani messages?
> Nejak tam ve Forward(ed)Message nevidim typ streamu, je to dobre?
> [tj aby ty replikace nesly S->S jako unrealiable a dal uz jako reliable]
> [jak vidim not implemented yet]


Jo to tam chybi, sem si to neuvedomil, protoze neni implementovano
execute().
K fungovani, nikdo by nemel pouzivat primo Forward(ed)Message,
pouziva je jenom NodeManager, kdokoli ostatni proste posila
zpravy normalne, vlastni forwarding vyssi vrstvy nevidi.
Jinak to funguje tak, ze kdyz node manager zjisti, ze nekdo
posila zpravu na klienta a neni prime spojeni na klienta,
zprava se zabali do ForwardMessage a posle serveru, ktery
spojeni s klientem ma.


> -i mi nevytvori .ack soubor, jenom archive. Kdyz si ho touchnu rucne (0 bytes
> velky), funguje to v pohode. (unix)


To neni bug ale feature :)
Musi se dodelat ArchiveDatabse, ale neni cas.


Petr

Caues,

Stepan vcera updatnul serializace properties ve factory
generatoru. Ale nyni se nic neserializuje, protoze novy tes

if( <PROPERTY>.should_serialize( desc ) == Property::SSR_YES )

vraci false.
Dela to pro vygenerovane rpc zpravy, a pravdepodobne
i vsude jinde.

Takze demo zas nefunguje :-)

Co s tim?
Je chyba v tom, ze se spatne inicializuje Serialized::Description?
Nebo v should_serialize()? Nebo nekde jinde?
Juknete na to, jestli tomu nekdo rozumite...

Petr

Caues,

Navic, kdyz si jeden node pridam add_node_for_synchronization()
a pak zavolam allow_synchronization(),
ale ten node na opacne starne si me _neprida_ do
add_node_for_synchronization()
tak jakmile dostane zpravu ode me tak spadne, protoze
me nema v tabulkach.

Nemelo by to cele fungovat takhle:
Kdyz chci synchronizovat cas s 1 az n jinymi nody,
tnz, aby muj cas se updatovat podle jejich,
tak reknu si ty nody pridam do tabulky pomoci
add_node_for_synchronization()
a pak zavolam
allow_synchronization().
To ze druha strana o me nevi je jedno, protoze
ja nebudu updatovat jeho cas (pouze v pride
ze on si me sam prida do tabulek).


Jo a add posilani time sync zprav - zda se, ze behem jednoho
ticku se jich posle asi 20, protoze server prijal
asi 20 zprav od klienta a az pote spadl na to,
ze nema klienta v tabulkach.


Petr

Caues,

Podle dokumentacei
 * Local node is running with other nodes to synchronize time with
 * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 * @code
 * static TimeManager &    time_manager = Global::time_manager();
 * time_manager.set_time( 10000 ); // 10 seconds. STime is still UInt64!!!
 * time_manager.add_node_for_synchronization( NodeId( 123 ) );
 * time_manager.add_node_for_synchronization( NodeId( 124 ) );
 * time_manager.allow_synchronization();
 * time_manager.unpause();
 * @endcode

kdyz ale todle zavolam na klientovi, tak zacne posilat zpravy
na server, coz nevim jestil je dobre/spatne, ale bylo to zakazano
ve verifikacnich tabulkach pri prijmu zpravy.

Co znamena add_node_for_synchronization()?
ZNamena to ze "muj cas bude updatovan podle nodu",
nebo "cas nodu bude updatovan podle meho casu"
???

Jak synchronizovat cas na klientovi?


Petr

On Friday 28 of February 2003 00:21, Petr Tovarys wrote:

> Add factories:
> Je taky nutno vymyslet updatovani factory listu, protoze kdyz se vytvori
> nova factory, takze zmeni vsechny ClassTypeId, cimz se zneplatni cely
> archiv, a musi se vygenerovat novy archiv a updatnout registry (update
> object id vsech account objektu).
> Castecne by vec vyresily ukladat type id do registry textove, ale je
> problem,
> ze factories se instanciui az po nacteni a zpracovani registry.
> No dalsi vec k zamysleni...

ClassTypeId by se melo do textoveho streamu ukladat stringove. Ted to asi neni 
kde zjistit a musi se par veci predelat, ale tak to bylo mysleno a tak to 
musi byt.

-- Stoupik

On Friday 28 of February 2003 00:48, Petr Tovarys wrote:

> Prave ze ne, swap je to same jako archiv :)
>
> Kdyz se archivovalo, zapisovalo se pomoci ARCHIVE flagu,
> tz. se zapsalo jen properties & eventy.
>
> Ale co znamena start archivu? To znamena, ze se posledni zaloha
> otevre jako swap. Ale ze swapu se nacitalo pomoci SWAP flagu,
> ktere se snazily nacitat i replikacni veci, ktere ale v
> archivu (swapu) nebyly, takze to spadlo.

No jo, ale nacitat z archivu replikacni requesty ani major version nema smysl. 
Do swapu se ale ukladat musej. Kdyz se zakaze swapovani objektu s replication 
requesty, cast se vyresi, ale co s major version. Pravda, ze archivovat ji uz 
zas tak moc neskodi, ale pak by mohla vyhledove dlouhodobe pretect tech 
32bitu (i kdyz to asi tezko).

-- Stoupik

On Fri, 28 Feb 2003, Stepan Vondrak wrote:

> Zdarec,
>
> Ready for testing, ale porad dost documented bugs ci pseudobugs. Hlavne ale
> chybi API z Objectu (tj. funkce replicate_to), neb nevim, jak provest
> konverzi ObjectId->NodeId. Boovie mi naposled rikal, ze uz tam ty specialni
> object id vazane na node id jsou. Kde a jak?


Nejsou :) Myslel jsem tim, jen ze s nima pocitam.
Ale uz je mam u sebe (konverze objectid na node id), takze
v dalsim komitu.
Rozhodne ale neni a ani nemam API jak propasovat clientovi seznamy
vsech server nodu (resp. pointeru na jejich object id).
Klient (skript) ma zatim jen pointr na prvni node, ke kteremu
se pripojil a na svuj account. Account ma pointr na node clienta.



Petr

Jak funguje forwardovani messages?
Nejak tam ve Forward(ed)Message nevidim typ streamu, je to dobre?
[tj aby ty replikace nesly S->S jako unrealiable a dal uz jako reliable]
[jak vidim not implemented yet]

Vygrep se ze zdrojaku "Boovie" - tj. moje poznamky pro Boovieho.

-i mi nevytvori .ack soubor, jenom archive. Kdyz si ho touchnu rucne (0 bytes 
velky), funguje to v pohode. (unix)

a jeden pro marekuse: Proc registry includuje PInt?


-- Stoupik

yOn Tue, 25 Feb 2003, Petr Tovarys wrote:

> Este to shrnu, co sou za problemy & postrehy:
>
> 1) makefile.gen sedi ve svem adresari, ale vse ostatni
> (headery s idl) sedi v ruznych adresarich. Stejne tak
> vysledne factories.* generovane factlistem mohou sedet
> na jinem miste.
> Krome toho, ze clovek musi zadavat presne cesty
> v kazdem makefile.genu, take factgen generuje
> spatne #ifndef XXX/YYY/ZZZ
>
> 2) Zavislost na factories, ktere se generuji soucasti
> jine knihovny.
>
> 3) pri druhem spusteni mkgen.pl se automaticky
> zdetekuji zavislosti ve vygenerovanych factories.
>
> 4) Sdileni factories mezi client.exe a server.exe - je nutno
> vse duplikovat v obou makefile.genech.
>
> 5) Pocitat s podporou inkludovani stylem
>  #include "lib/shared/accout_object_factory.h"


Update pro Stepana:
Akutne neni potreba nic z toho, takze se muzes
venovat jinym vecem.
1) a 4) a 5) jsou nyni bezvyznamne, 3) moc nevadi.

Jedina ktera by se sikla je 2), ale i bez ni to jde.


Petr

Zdarec,

Ready for testing, ale porad dost documented bugs ci pseudobugs. Hlavne ale 
chybi API z Objectu (tj. funkce replicate_to), neb nevim, jak provest 
konverzi ObjectId->NodeId. Boovie mi naposled rikal, ze uz tam ty specialni 
object id vazane na node id jsou. Kde a jak?

-- Stoupik

On Thursday 27 of February 2003 17:06, Marek Vondrak wrote:
> Stepane, Stepane,
> jestli jsi to jeste nepochopil, tak serializacni API musi mit stejny
> interface pro vsechny serializovatelne typy. Proc ma teda serializace
> objektu dalsi parametry? Jak IDL pozna, jestli se serializuje objekt nebo
> PInt, jak serializator vektoru ma rozlisovat mezi PInt a Object? Proc ten
> dalsi parametr neni soucasti Description? Rekl bych, ze v tom zas delas
> peknej bordel a ze sis to vubec nezkousel prekladat natozpak neco testovat
> (viz nefunkcnost Properties).

Je to tam jako komentar zdokumentovano (mozna teda az v dnesnim commitu). Ten 
dalsi parametr bude mit defaultni hodnotu pro tydle serializace, zatim ale 
nema, protoze bych jinak neodchytil, odkud vsude se to z core vola (abych tam 
dopsal ty spravne parametry). Defaultni parametry funguji pouze na member 
objects (tedy i pro vektory). Bordel v tom nedelam a zjevne tomu nerumite vy, 
protoze to predtim bylo uplne blbe a fungovalo to jenom nahodou.

-- Stoupik

On Fri, 28 Feb 2003, Stepan Vondrak wrote:

> On Thursday 27 of February 2003 13:05, Petr Tovarys wrote:
> > From: "Petr Tovarys" <pto...@ss...>
>
> > Takp roblem nebyl ve factories, ale v serializacnich
> > flazicich v Objectu (Object::SerializeFlags).
> >
> > Protoze nacitani ze swapu nacitalo i replikacni veci,
> > ale swap je normlani archiv, a ten se zapisoval
> > s flaziky pro archivace, ktere replikacni veci
> > nezapisovali. Tudiz pri naswapovani ty replikacni
> > veci chybely ve streamu.
> >
> > Tzn. ze swapovani flagy a archivacni flagy musi
> > byt stejne. Takze pokud replikacni veci je potreba
> > zachovat pri odwapovani objektu, tak jedine reseni
> > je zakazat odswapovani objektu, ktere se nekam
> > replikuji. O to se uz bude starat load
> > balancer.
>
> To nevim jestli je pravda.
>
> Do swapu a do archivu se proste musi zapisovat jine informace, proc by mely
> byt nutne serializacni flagy pro obe stejne, to vubec nechapu? Myslel jsem,
> ze se zapisuje pomoci CommonArchiveOperation a tam ty flagy predavam snad
> ruzne, ne? V ObjectManageru se ke swapu a k archivu pristupuje ruzne, tak
> jaky je problem tam procpat ty flagy?


Prave ze ne, swap je to same jako archiv :)

Kdyz se archivovalo, zapisovalo se pomoci ARCHIVE flagu,
tz. se zapsalo jen properties & eventy.

Ale co znamena start archivu? To znamena, ze se posledni zaloha
otevre jako swap. Ale ze swapu se nacitalo pomoci SWAP flagu,
ktere se snazily nacitat i replikacni veci, ktere ale v
archivu (swapu) nebyly, takze to spadlo.


Petr

On Thursday 27 of February 2003 13:05, Petr Tovarys wrote:
> From: "Petr Tovarys" <pto...@ss...>

> Takp roblem nebyl ve factories, ale v serializacnich
> flazicich v Objectu (Object::SerializeFlags).
>
> Protoze nacitani ze swapu nacitalo i replikacni veci,
> ale swap je normlani archiv, a ten se zapisoval
> s flaziky pro archivace, ktere replikacni veci
> nezapisovali. Tudiz pri naswapovani ty replikacni
> veci chybely ve streamu.
>
> Tzn. ze swapovani flagy a archivacni flagy musi
> byt stejne. Takze pokud replikacni veci je potreba
> zachovat pri odwapovani objektu, tak jedine reseni
> je zakazat odswapovani objektu, ktere se nekam
> replikuji. O to se uz bude starat load
> balancer.

To nevim jestli je pravda.

Do swapu a do archivu se proste musi zapisovat jine informace, proc by mely 
byt nutne serializacni flagy pro obe stejne, to vubec nechapu? Myslel jsem, 
ze se zapisuje pomoci CommonArchiveOperation a tam ty flagy predavam snad 
ruzne, ne? V ObjectManageru se ke swapu a k archivu pristupuje ruzne, tak 
jaky je problem tam procpat ty flagy?

-- Stoupik

On Fri, 28 Feb 2003, Stepan Vondrak wrote:

> > Pro windows:
> > Jeste jeden bug (?) v zavislostech, kdyz je specifikovan adresar
> > ve jmenech factories
> >
> > object/lib/account_object.h
> >
> > ->
> >
> > object/lib/account_object_factory.cpp,
> > ten obsahuje #include "object\lib\account_object_factory.h"
> >
> > ->
> >
> > pri dalsim spusteni mkgen.pl se vygeneruje
> > zavislost na vyse zminenem include, ale
> > do makefile.xxx se zapise jako
> > "objectlibaccount_object_factory.h", cili
> > bez lomitek.
> >
> > Takze prozatimni reseni je pred spustenim mkgenu
> > zavolat makefile.xxx degenerate, takze se
> > ta zavislost nevygeneruje.
>
> Buah.
> Jsou tydle veci nekde nacommitovane abych to mohl otestovat?


Nee a ani nebudou (protoze jak uz jsem psal, vsechno je ted udelano
bez specifikace cest).


> To s tim #ifdef se opravi (predchozi mail).
> Tadle chyba je patrne zapricinena tim, ze nemas v makefile.gen ty lomitka
> obackslashovane tj. melo by to byt "perl ... object\/lib\/account_object.h"
> aby se opravdu predala dopredna lomitka a neobracela se.


Jo to sem nemel, ale to by clovek _chcipl_ kdyby to mel psat,
ono se nedalo vyznat ani v tech normalnich lomitkach :-)


Petr

On Thursday 27 of February 2003 11:48, Marek Vondrak wrote:
> Ahoj,
> Stepan prekopal inicializace properties, ktere se nyni chovaji tak, ze
> defaultni konstruktor Property property nainicializuje jako nepouzitelnou.
> Vysledek je, ze Property nelze pouzit na stacku (default-initialized). To
> je zamer? Pokud ano, pak prosim, aby Stepan predelal veskere testy
> serializaci a kontejneru, ktere testuji properties prave timto (nyni
> nefunkcnim) zpusobem. Je problem nejprve Property incializovat jako root
> property a v pripade, ze je ve skutecnosti nekym vlastnena ji pak nasledne
> preinicializovat?
>

Ne zamer, pouze nedopatreni.

-- Stoupik

On Tuesday 25 of February 2003 15:42, Petr Tovarys wrote:

> Ty makefile.geny pro skripty, tak to se neda.
> Stepane, zapausuj replikace a neco s tim udelej.
>
> Dalsi problem je, ze ze skriptu mam zavislost
> na objektech v src/core/xxx, jejichz factory se
> generuji v ramci core lib. Ale jak reknu mkgenu
> v makegenu pro skript, ze headery a cpp tech factories
> zaviseji na knihovne core?
> Ted na me totiz make rve, ze nevi jak udelat ty factories v core,
> ktere inkluduju ze skriptu.

Jo v planu to bylo davno, ale znamena to udelat z makefile.gen takovy 
primitivnejsi makrojazyk, celkem nechut - bude to trvat. Plus tam je par 
nedomyslenosti (ty cesty a tak, neex. zavislosti knihoven na sobe), ktery 
snad opravim brzo.

-- Stoupik

Caues,

Add factories:
Je taky nutno vymyslet updatovani factory listu, protoze kdyz se vytvori
nova factory, takze zmeni vsechny ClassTypeId, cimz se zneplatni cely
archiv, a musi se vygenerovat novy archiv a updatnout registry (update
object id vsech account objektu).
Castecne by vec vyresily ukladat type id do registry textove, ale je
problem,
ze factories se instanciui az po nacteni a zpracovani registry.
No dalsi vec k zamysleni...

Petr

On Monday 24 of February 2003 12:51, Petr Tovarys wrote:
> Pro windows:
> Jeste jeden bug (?) v zavislostech, kdyz je specifikovan adresar
> ve jmenech factories
>
> object/lib/account_object.h
>
> ->
>
> object/lib/account_object_factory.cpp,
> ten obsahuje #include "object\lib\account_object_factory.h"
>
> ->
>
> pri dalsim spusteni mkgen.pl se vygeneruje
> zavislost na vyse zminenem include, ale
> do makefile.xxx se zapise jako
> "objectlibaccount_object_factory.h", cili
> bez lomitek.
>
> Takze prozatimni reseni je pred spustenim mkgenu
> zavolat makefile.xxx degenerate, takze se
> ta zavislost nevygeneruje.

Buah.
Jsou tydle veci nekde nacommitovane abych to mohl otestovat?
To s tim #ifdef se opravi (predchozi mail).
Tadle chyba je patrne zapricinena tim, ze nemas v makefile.gen ty lomitka 
obackslashovane tj. melo by to byt "perl ... object\/lib\/account_object.h" 
aby se opravdu predala dopredna lomitka a neobracela se.

-- Stoupik

Caues,

Tak se mi prave konecne podarilo poslat zpravu z clienta na server, tu
zpracovat
accoutem, poslat text zpet na klienta a vyprintit ho na klientovu obrazovku.
Nic moc, je tam hafo hnusnych quick hacku, ale aspon neco.

Zitra zkusim dodelat synchronizaci casu mezi serverem a clientem
a pak uz to skusim commitnout.
(Dopredu rikam, ze nepude zkompilit core/test ani zadny ze server testu,
pouze demo, takze s tim pocitejte, pokud budete potrebovat neco testovat.)
Pak uz bude skript oddelen od jadra a muze se nezavislet
pracovat na obou.


Petr

Stepane, Stepane,
jestli jsi to jeste nepochopil, tak serializacni API musi mit stejny =
interface pro vsechny serializovatelne typy. Proc ma teda serializace =
objektu dalsi parametry? Jak IDL pozna, jestli se serializuje objekt =
nebo PInt, jak serializator vektoru ma rozlisovat mezi PInt a Object? =
Proc ten dalsi parametr neni soucasti Description? Rekl bych, ze v tom =
zas delas peknej bordel a ze sis to vubec nezkousel prekladat natozpak =
neco testovat (viz nefunkcnost Properties).

-- Markoid

From: "Marek Vondrak" <mvo...@ce...>


> > proxy_node_object_id = vytvor_proxy_node_object_id( node_id );
> > // Nyni ma proxy_node_object_id class id NodeObjectu.
> >
> > WeakPointr< NodeObject > node_object = proxy_node_object_id;
> > Remote< PotomekNodeObjectu > potomek = node_object.convert();
>
> Asi jsem to nepochopil, ale nevidim duvod, proc by tohle nemelo fungovat
uz
> ted.


Tak chyba byl anekde jinde - PotomekNodeObjectu byl
abstraktni trida, ale k te se neregistruje factory, cili ani
class id, cili to slitlo, protoze aktualne nelze mit
pointr na abstraktni tridu.

Z toho duvodu sem musel z te tridy udelat neabstraktni tridu,
coz je teda prasarna.

Takze to jest dalsi todo pro Stepena - registrovat factory
i pro abstraktni tridy, aby slo delat pointery na ne.

Podle Markoida by se factory mela rozdelit na factory a metaobject,
metaobject pro kazdou tridu, factory jen pro neabstraktni.


Petr

Caues,

Nejaka prace pro Markoida:
Je potreba udelat podporu pro to, aby slo
do weak pointeru (RPC pointeru)
pro potomka NodeObject priradit 
object id s class_id NodeObjectu.

tzn. aby slo

proxy_node_object_id = vytvor_proxy_node_object_id( node_id );
// Nyni ma proxy_node_object_id class id NodeObjectu.

WeakPointr< NodeObject > node_object = proxy_node_object_id;
Remote< PotomekNodeObjectu > potomek = node_object.convert();


To, aby odpovidajici NodeObject, ktery prijme zpravy posilane
pres potomka byl opravdu PotomekNodeObjectu, uz musi
zarucit skript (client).

Zda object id ma class id NodeObjectu se netestuje
pres dedicnost, ale rychle pres 
bool ObjectId::is_proxy_node_object_id()
(to si tam zatim pridej).
Jadro vytvari proxy object id tak, ze do nich
vrazi class id NodeObjectu.


Petr

Cau,
jakym zpusobem hodlate delat interakce console -> objekty? Konkretne =
napr. prevody nazev tridy -> class_type_id, pristup k atributum objektu, =
popr. volani jeho metod? Nemelo by se tohle udelat nejak poradnejc - =
neco jako introspection API v metaobjektech, ktere by se vydelily z =
factories?

-- Markoid