massiv-devel Mailing List for Massively multiplayer game middleware

mscc> Cau, udelal jsem cast testu na posilani zprav
mscc> - ale kdyz jsem si s tim hral, tak jsem narazil
mscc> na par problemu:

mscc> - Pokud server zacne po navazani spojeni posilat 
mscc>   UDP zpravy driv, nez dostane nejakou (UDP) 
mscc>   zpravu od klienta, tak to poradne nefunguje. 
mscc>   S TCP zpravami problem neni. Zkus se na to taky 
mscc>   mrknout, to pripojovani jsi psal ty, takze bys
mscc>   do nej mel lip videt nez ja. Dokonce v takovem
mscc>   pripade ani klient neodesle svoje zpravy...
mscc>   Pri ladeni jsem zjistil, ze server ty UDP zpravy
mscc>   normalne odesle, klientovi do socketu _neco_
mscc>   prijde - ale to neco ma vzdycky delku 1. Klient
mscc>   pak porad dokola kouka na ten UDP socket a zrejme
mscc>   se z toho tak vzrusi, ze uz ani nic neodesle...
mscc>   Abys tuhle situaci vyvolal, nahrad v 
mscc>   netserver_test.cpp ve funkci network_traffic_tests
mscc>   prvni radek 
mscc>     while( current_time < ( loop_begin + 5 ) )
mscc>   radkem 
mscc>     while( current_time < ( loop_begin + 1 ) ),
mscc>   popr. (pokud by to nenastalo)
mscc>     while( current_time < ( loop_begin ) )

Na tohle se podivam, neco me napada, ale jeste si nejsem jisty.

mscc>   Jo, a necommituj zadne zmeny v mych funkcich
mscc>   v net(server|client)_test.(cpp|h) - jinak to
mscc>   pak nezmergujem dohromady!

No nejake zmeny udelat musim, treba ted delam neco s loggerem, tak
snad to nebude problem zmergovat, je toho malo.

mscc> - Je urcite dobre UDPSocketxxx::receive_data? 
mscc>   Moc nechapu, proc funguji radky
mscc>    recvbuf.resize( j );
mscc>    // looks ugly hehe, works well.
mscc>    recvbuf.resize( 
mscc>        ::recvfrom( 
mscc>               sock, 
mscc>               ( char * ) recvbuf.get_buffer(), 
mscc>               j, 0, &ra,   &ra_size 
mscc>               ) 
mscc>        );

Pr. na socketu jsou 3 UDP packety, velikost bytu je 100b
j ma hodnotu 100, ale tim, ze zavolam recv, prijmu jenom prvni packet,
ktery je kratsi, aby dobre fungovala statistika a UDP checksum, je
potreba aby recvbuf byl stejne velikosti, jako prijata data. Na
zacatku ho nastavim na velikost vsech dat na socketu ( nevim, kolik je
tam UDP packetu, treba jen jeden ... ) a pak to podle potreby resiznu.
Ja si myslim, ze je to spravne. Kazdopadne si muzes vyzkouset, ze bez
toho druheho resize to nebude fungovat...

mscc>    Kdyt prece parametry se vyhodnocuji nejdriv, 
mscc>    takze nejdriv se zapise do bufferu, a pak 
mscc>    se teprve ten buffer resizne? Navic - proc tam
mscc>    je 2x resize hned po sobe?


mscc>    A jeste ve stejne funkci:
mscc>      ::recvfrom( sock, NULL, j, 0, &ra, &ra_size );
mscc>    Co to ma delat? O tom, ze by vystupni buffer
mscc>    mohl mit hodnotu NULL jsem v dokumentaci nic
mscc>    nenasel.

To je ok, pokud na ten UDP socket prisel nejakej packet, kterej je
kratsi nez prazdnej message, tak to proste zahodi.

mscc> Tak se na to mrkni, moc se mi nechce psat dalsi 
mscc> testy nebo tyhle rozsirovat, dokud tohle neodhalime...

mscc> Marek

Octa

-- 
Best regards,
 Ondrej                            mailto:oc...@ma...

Cau,
tak jsem trochu prozkoumal to XSLT - neni to=20
primo zadnej format, ale jednoduchy deklarativni
jazyk, pomoci ktereho se daji celkem jednoduse
delat transformace z XML na spoustu jinych veci.
(primo napr. na XHTML, HTML, RTF, TXT, ... - je=20
akorat potreba znat ten cilovy format). Nebo=20
se daji k dokumentu XML pridat udaje o formatovani
ve forme XFO (soucast definice XSLT) a pomoci
existujici konvertoru prevest napr. na PDF (zrejme
i vcetne hyperlinku), PS, TeX, ...

Pokud bychom to chteli pouzit na dokumentaci,=20
znamenalo by to psat jeji "zdrojaky" v XML...
napr. v XHTML, coz je HTML upravene tak, aby to
bylo zaroven XML (tj. vsechny znacky musi byt
parove, ..., + prida se na zacatek par=20
konfiguracnich radku).

Marek


--------------------
Po=B9lete p=F8=E1n=ED do nov=E9ho roku sv=FDm bl=EDzk=FDm z http://pohl=
ednice.centrum.cz

> aspon ja) XSLT neumime. Me asi za nekolik dni dojde
> prace a i kdyz o Vanocich asi nebudu mit moc casu, tak
> bych celkem rad mel neco aspon v programu - mam se

No, jeste by se mohl zmenit interface v net tak, aby se ven vracely akorat
reference na ty bitiostreambuffery, protoze spousta veci je na nich
definovana tak, ze se s nimi pracuje jako s "hodnotou". Tim by se rovnez
procistily zdrojaky a zbavily konstrukci typu, UDPOBuffer * buffer = &(
*it );. Jo a jeste jedno upozorneni, nepouzivejte C-style pretypovani, ale
nahradte je checked_cast<>resp. static_cast<>).

-- Markoid

Caues,

Kdyz se zavola Regitsry::load_from_config_file(), tak se neprepisou
hodnoty aktualne ulozene v registry hodnotami ze souboru.
Diky tomu je nemozne konfigurovat massiv pomoci souboru
massiv.conf, protoze load se vola az jsou vytvoreny
globalni objekty, ktere uz vytvorily vsechny cvary
na default hodnoty v registry.

Petr

Marek Vondrak wrote:
> Cau,
> udelal jsem ve statistikach novy objekt, ktery meri rozdily v system 
> time. Hodilo by se to pro mereni casu, ktery ubehl napr. od vstupu do 
> urcite funkce, apod. Stavajici problem: Global::system_time() vraci 
> systemovy cas, ne cas sezrany nasim procesem. Mel by se pro tyto ucely 
> zavest dalsi cas nebo se na to vykaslat? Napriklad pro ucely mereni fps 
> na klientovi je rozumne merit ten cas skutecne jako systemovy.


Ja bych se na to vykaslal. Jakou informaci navic by to dalo? Dle me zadnou.

Petr

Marek Vondrak wrote:
> Cau,
> vypada to, ze se budou muset udelat nasledujici zmeny:
> 1) refresh repliky znamena refresh cele replikacni skupiny - to muze 
> zpusobit nejake implementacni problemy, protoze pointer replicas nejsou 
> monitored pointery
> 2) explicitni smazani repliky = okamzite smazani cele replikacni skupiny 
> (stejne problemy jako 1))
> 2) jsou na repliku povoleny strong pointery? strong-property jiste ne 
> (note: pointer replica je vzdy weak), protoze to by znamenalo, ze 
> replika je zahrnuta do jine migracni skupiny. co ale stack-strong? pokud 
> ano, replikacni skupinu lze smazat po vyprseni timeoutu az kdyz na ni 
> neexistuje stack-strong


Zde je dobre pripomenout o co vlastne jde.
Proc chceme stack strong na repliku? Abychom meli
zajisteno, ze na ni muzeme sahat porad, a nikdo nam
ji pod rukama nezrusi.
Samozrejme pro asnyc rpc todle vubec neni potreba.
Jde jen o sync rpc, kdy gc bude mazat repliky
timeoutem behem toho, kdy ma nekdo strong na repliku
behem vyvolani sync rpc volani.

Je moznost rict, ze stack strong na repliku
muze behem sync rpc volani prestat byt validni,
ale to je asi divne a tezko uhlidatelne. Takze
zbyva jedine timeout mazani replik pozdrzovat,
dokud vsechny repliky z jedne replikacni skupiny
uz nejsou stack referenced.

Btw. z bodu 1 a 2 vyplyva, ze smaznuti repliky
neni zas tak rychla operace - znamena to enumerovat
celou replikacni skupinu, a tu celou smazat.


Petr

Udelal jsem do vlaken, kriticke sekce a semaforu hazeni vyjimek -
takze je jasne, ze vlakna dodelane nebyly - omluva Markoidovi.
Dale jsem fixnul code style.

Udelal jsem novou vyjimku v exeption.h pro vlakno a semafor. Vyjimku pro
zamek jsem pouzil jiz hotovou - je tam pro zamky vic vyjimek, v
soucasnosti jsou asi zbytecne.

Doufam ze uz se mi code style a dalsi zalezitosti dostaly pod kuzi, takze
se takove veci uz nebudou objevovat.

V thread.h, synch.h a semaph.h je jsou nadefinovany nejake makra pro
hazeni vyjimek. Tyto makra se pouzivaji v win32 a unix zdrojacich stejne,
takze jsem je placl sem.

Zmena: ThreadRoutine pro vlakno - nyni vraci int misto unsigned int.

Hafik

Marek Vondrak wrote:
>>U filosofu (ne rpc) a local_migration se nearchivuje automaticky,
>>ale je nutno to nastavit pres command lajnu
>>"-a" nebo "--enable-archivation".
> 
> 
> Takze se vubec netestuje nahodny swapout?


Ja psal vyse o archivaci.
Swap-out lze zapnout pre object manager setting
neco jako debug_force_swap_out_of...., ale to jsem uz
psal myslim v nejakem starsim mailu.
Funguje to tak, ze v kazdem ticku se odswapuji vsechny
objekty (pokud to de), ktere maji naplanovanou udalost
na dany tick.


>>U filosofu (ne rpc) lze spustit simulaci z archivu.
>>To se udela pres
>>"-l <archive>" nebo "--load-from-archive <archive>".
>>takze napriklad
>>./test_server -l massiv_1.archive
> 
> 
> To se nacte kompletni stav nebo se archiv zacne povazovat za swap a nacita
> se to z nej az podle potreby? Pokud se chape jako swap, tak pokud vim, tak
> se ten swap file v prubehu meni, takze by neslo stejny "archiv" poustet
> vicekrat (coz tady lze).


Archiv se zacne povazovat za swap, a objekty se postupne
nasosavaji podle naplanovanych udalosti.
Ano, swap - v nasem pripade ten archiv primo, se za behu meni,
nicmene mas pravdu, ze stejny archiv lze spoustet vicekrat a to
z jednoducheho duvodu - pri ukonceni aplikace se core nijak zatim
neeshutdownuje, cili se swap nezavre, cili se zmeny nezapisou,
cili archiv zustane beze zmeny. Ja sice volam Volume::remove( streamy ),
ale ty se ocivide hned nepropaguji do fyzickeho souboru,
takze archiv take zustane beze zmeny.
A vzhledem k tomu, ze defaultne nejsou zapnute swap-outy jak jsem
psal vyse, nedojde ani k zadnemu zapisu do swapu (archivu), takze take
zustane beze zmeny.

Pokud by se zaplo to swap-out, a zbytek zustal beze zmeny,
tak ten soubor by se mel dostat do nekonzistetniho a podivneho
stavu.

Jinak oficialne to bude fungovat tak, ze pri otevreni archivu
se archiv zkopiruje do swap_souboru, aby nedoslo k prepsani archivu.


Petr

Cau,
vypada to, ze se budou muset udelat nasledujici zmeny:
1) refresh repliky znamena refresh cele replikacni skupiny - to muze =
zpusobit nejake implementacni problemy, protoze pointer replicas nejsou =
monitored pointery
2) explicitni smazani repliky =3D okamzite smazani cele replikacni =
skupiny (stejne problemy jako 1))
2) jsou na repliku povoleny strong pointery? strong-property jiste ne =
(note: pointer replica je vzdy weak), protoze to by znamenalo, ze =
replika je zahrnuta do jine migracni skupiny. co ale stack-strong? pokud =
ano, replikacni skupinu lze smazat po vyprseni timeoutu az kdyz na ni =
neexistuje stack-strong

-- Markoid

>
> U filosofu (ne rpc) a local_migration se nearchivuje automaticky,
> ale je nutno to nastavit pres command lajnu
> "-a" nebo "--enable-archivation".

Takze se vubec netestuje nahodny swapout?

> U filosofu (ne rpc) lze spustit simulaci z archivu.
> To se udela pres
> "-l <archive>" nebo "--load-from-archive <archive>".
> takze napriklad
> ./test_server -l massiv_1.archive

To se nacte kompletni stav nebo se archiv zacne povazovat za swap a nacita
se to z nej az podle potreby? Pokud se chape jako swap, tak pokud vim, tak
se ten swap file v prubehu meni, takze by neslo stejny "archiv" poustet
vicekrat (coz tady lze).

-- Markoid

Ahoj,
bylo by mozne do kazdeho makefile vygenerovat umely target =
"force_%jmeno_souboru.cpp%", ktery zajisti prelozeni konkretniho .cpp? =
Vzhledem k tomu, ze nazvy cpp pouzivame jedinecne, pouzivalo by se to =
prijemne oproti nmake -f makefile.msvc =
..\..\..\.binjfdjfdlsjfldsjfldsjfldjfldjfdjfds\src\core\sfjdsfhdshfldshfl=
dsfhldsf.obj.
-- Markoid

Cau,
udelal jsem ve statistikach novy objekt, ktery meri rozdily v system =
time. Hodilo by se to pro mereni casu, ktery ubehl napr. od vstupu do =
urcite funkce, apod. Stavajici problem: Global::system_time() vraci =
systemovy cas, ne cas sezrany nasim procesem. Mel by se pro tyto ucely =
zavest dalsi cas nebo se na to vykaslat? Napriklad pro ucely mereni fps =
na klientovi je rozumne merit ten cas skutecne jako systemovy.

-- Markoid

Caues,
Poznamky k server testum:

U local migration server testu byly zrusen argument
"-d" pro disablovani debug swapovani - viz. nize.

Server testy pri spusteni se pokusi nacist "massiv.conf",
pokud ho nenajdou, pokracuje se s default nastaveni.
Takze vsechny nastaveni object manageru jako debug
swapovani a local migration nastavovat pres massiv.conf.

Aby to bylo jednodussi, server testy pri ukonceni
zapisou "massiv.conf.x", ve kterem je obsah registry
po skonceni programu. Takze staci ho zkopirovat na
massiv.conf a upravit.
Mimojine se tak lze precist vsechny statistiky.

U filosofu (ne rpc) a local_migration se nearchivuje automaticky,
ale je nutno to nastavit pres command lajnu
"-a" nebo "--enable-archivation".

U filosofu (ne rpc) lze spustit simulaci z archivu.
To se udela pres
"-l <archive>" nebo "--load-from-archive <archive>".
takze napriklad
./test_server -l massiv_1.archive


Petr

> A kdyz uz jsme u te dokumentace, myslim, ze tady byl
> kdysi mejl s otazkou, v cem se bude psat dokumentace
> (bud na nej nebyly zadne odpovedi, nebo jsem je prehlid).
> Ja bych jako moznost navrhoval XSLT, ze ktereho se
> pokud vim daji generovat i dalsi formaty (HTML, RTF,
> TXT, ...). Problem je, ze asi nikdo z nas (rozhodne
> aspon ja) XSLT neumime. Me asi za nekolik dni dojde
> prace a i kdyz o Vanocich asi nebudu mit moc casu, tak
> bych celkem rad mel neco aspon v programu - mam se
> podivat, jestli by XSLT bylo pouzitelne?

XSLT vubec neznam, ale muzes to prozkoumat. Jo, a kdybys skutecne nemel co
na praci, hodila by se do budoucna "pack/unpack" utitila, ktera kopiruje
std::fstreamy do volume a zase zpatky (spravovani volumes); nejaky stupidni
interface pro parametry z commandline (pokud se nerekne, ze se vscehno
nastavuje via registry), apod.

-- Markoid

Caues,

> Registry::load_from_config_file() predpokladam asi
> nevycisti svuj obsah na zacatku - tedy pouze prida
> obsah z daneho souboru a tedy jiz existujici cvary
> a nody, ktere nejsou v config file, budou existovat
> i po load_from_config_file()(?).

Predpokladas spravne, mazani z registry neni vubec
podporovano (na nejake schuzce se dospelo k zaveru,
ze neni treba :)

> Rozhodne pripsat todle chovani do dokumentace k registry.

OK.

A kdyz uz jsme u te dokumentace, myslim, ze tady byl
kdysi mejl s otazkou, v cem se bude psat dokumentace
(bud na nej nebyly zadne odpovedi, nebo jsem je prehlid).
Ja bych jako moznost navrhoval XSLT, ze ktereho se
pokud vim daji generovat i dalsi formaty (HTML, RTF, 
TXT, ...). Problem je, ze asi nikdo z nas (rozhodne 
aspon ja) XSLT neumime. Me asi za nekolik dni dojde
prace a i kdyz o Vanocich asi nebudu mit moc casu, tak
bych celkem rad mel neco aspon v programu - mam se
podivat, jestli by XSLT bylo pouzitelne? 

Marek

Caues,

Registry::load_from_config_file() predpokladam asi
nevycisti svuj obsah na zacatku - tedy pouze prida
obsah z daneho souboru a tedy jiz existujici cvary
a nody, ktere nejsou v config file, budou existovat
i po load_from_config_file()(?).
Rozhodne pripsat todle chovani do dokumentace k registry.


Petr

> Marek Vondrak wrote:
> > - Remote<> je pointer na _interface_, tudiz by si dle me mela kazda 
> > funkce mit moznost urcit, jak se bude vyvolavat (synchronne, 
> > asynchronne, s replikacnim trikem); rozhodne bych tam nechtel mit 2 
> > (sync ano/ne) x 2 (replikacni trik ano/ne) typu ruznych RMI pointeru
> 
> 
> Huh, co je to replikacni trik?

Zda zavolani metody na tom objektu muze iniciovat jeho replikaci a pristi vyvolani metody na nem uz muze jit lokalne. Viz stare kecy ohledne replikace.

> 
> > 2) ObjectManager & GC:
> > - porad tvrdim, ze dorucene objekty zustavaji rootem v dobe doruceni; 
> > Boovie, pust si test/philosophers, nastav si breakpoint do 
> > GC::ref_count_collect(); zjistis, ze kdyz se pousti posledni reference, 
> > objekt je porad root a tudiz hnije do dalsiho behu GC (jinymi slovy u 
> > tech filozofu se uplne muze vypnout instant refcounting, protoze se 
> > nikdy nedostatne ke slovu)
> 
> 
> Todle jsme jiz vyresili soukrome, samozrejme se ukazalo ze tohle vyse
> neni pravda :) a objekty hniji z jineho duvodu - object manager
> pri volani delivered_to() nevytvari object pointer na doruceny
> objekt (ma jen Object *), tudiz se zadny ref counting nezapoji.
> 

To se musi do budoucna ale zmenit. Objekt musi byt minimalne pinned. Asi bych to videl tak, ze zustane rootem do doby, nez skoncit vyvolani te funkce.

-- Markoid

Caues,
Nesu vam novinky, veselte se.

Tak se mi prave (po fixnuti nekolika bugu :) podarilo
nacist filozofy v pulce obeda ze zalohy
a dosimulovat jejich zranici, huraa!

Nez odfarim na Vanoce domu, tak jeste stihnu akorat
tak todle vsecko dat dohromady a komitnout,
coz zahrnuje
- Zruseni server testu takoveho toho co nic nedela,
misto toho tam dam nejake spolecne nastaveni
pro vsechny servery (parsovani z command lajny, jako
zda swapovat, zda nacist ze zalohy, local migrace apod.).
- Dalsi upravy uz by nemely nijak kolidovat.

Dale pokud by nekdo nahodou chtel pres Vanoce zprovoznit
dva komunikujici servery - zatim na to neni pripraven
NodeManager.
Aby to fungovalo (posilani systemovych zprav), je nutno
pro kazdy server vygenerovat jeho node id a zastupne object id
a tudle informaci vlozit do NodeManager::connected_server_nodes.
(lokalni server se registruje pres NodeManager::initialize()).

Dale jelikoz nefunguje global search, je nutno udelat vsechny
objekty tracked (pro pripad ze by se na ne nekdo ptal
a nebyly lokalni) a mezi servery rozdistribuovat
informaci o providerech (ObjectManager::register_remote_provider()).
Timto, pokud se nebude nekdo odkazovat na neexistujici objekt,
nedojde k vyvolani global searchu a mela bu fungovat
distribuovana simulace, pokud tam nebude hafo bugu,
jako ze asi ano.

Ja se pokusim pres Vanoce vymyslet jak todle pripojovani
serveru a rozdistribuovani informaci udelat obecne - teda
pokud se toho nechce ujmout nekdo jiny? Asi ne co.
Taky by si mohl nekdo (heh) vymyslet ten global search - kdysi se
mluvilo o nejake hiearchii nodu, ktere budou tvorit
sit - to asi padlo bych rek(?). Takze proste jen broadcast
na vsechny servery (s osetrenim, kdyz objekt zrovna migruje)?

Podle planu ze schuze s vedoucim, by distribuovana verse
mela chodit na schuzi v lednu, coz bude kolem 14teho,
coz nevim jak se stihne obecne, ale to napraseni vyse
pude stihnout v pohode, doufam.

Dale je nutno (jak bylo domluveno) udelat roadmap
co chybi do dokonceni projektu. Myslim, ze na to se
upsal Stepan :-)

Ja osobne budu o Vanocich uplne mimo, a to asi i vcetne
mailu (no mozna se nekdy donutim nekam skocit).

Toz tak,


Petr

Marek Vondrak wrote:
> - Remote<> je pointer na _interface_, tudiz by si dle me mela kazda 
> funkce mit moznost urcit, jak se bude vyvolavat (synchronne, 
> asynchronne, s replikacnim trikem); rozhodne bych tam nechtel mit 2 
> (sync ano/ne) x 2 (replikacni trik ano/ne) typu ruznych RMI pointeru


Huh, co je to replikacni trik?


> 2) ObjectManager & GC:
> - porad tvrdim, ze dorucene objekty zustavaji rootem v dobe doruceni; 
> Boovie, pust si test/philosophers, nastav si breakpoint do 
> GC::ref_count_collect(); zjistis, ze kdyz se pousti posledni reference, 
> objekt je porad root a tudiz hnije do dalsiho behu GC (jinymi slovy u 
> tech filozofu se uplne muze vypnout instant refcounting, protoze se 
> nikdy nedostatne ke slovu)


Todle jsme jiz vyresili soukrome, samozrejme se ukazalo ze tohle vyse
neni pravda :) a objekty hniji z jineho duvodu - object manager
pri volani delivered_to() nevytvari object pointer na doruceny
objekt (ma jen Object *), tudiz se zadny ref counting nezapoji.


Petr

> >
> > Global::system_time() musi byt co nejrychlejsi s presnosti
> > zhruba na setiny sekundy, takze uz jen z tohoto duvodu by asi
> > nemelo byt urcovano ze systemoveho casu.
> > Aktualni implementace platform time na win32 je fakt hrozna,
> > co to je za nechutne pretypovani, zvlast z nejake struktury???
> >
>
> To nechutne pretypovani je zpusob, jak z te jejich struktury dvou DWORDU
> udelat UInt64, a pak z toho Float64. Jenze MSVC neumi pretypovat UInt64
> (interne _int64, neboli signed long long) na double (kompilator hlasi
> error), tak to zatim delam hackem - nejdrive tu strukturu pretypovat na
> Int64 (interne _int64 - to pak prepisu na Int64), a to pak na Float64.

A tohle je vysvetleni? To to nemuzes prekonvertit _korektne_ stylem
Float64 val = hi_dword * 65536 * 65536 + lo_dword;
nebo
UInt64 val;
val = ( static_cast<UInt64>( hi_dword ) << 32 );
val |= static_cast<UInt64>( lo_dword)?

Proste s timhletim pristupem tady nemas v massivu co pohledavat. Bud to
budes psat korektne, zdrzis se zbytecnych pretypovani, budes pouzivat stejny
layout jako my, budes handlovat spravne chybove stavy, nebudes vracet chyby
stylem return -1, -2, -3, aniz by nekde bylo receno, co tyhle cisla
znamenaji (kdyby to aspon byly konstanty definovane pres enumy - navic i to
je zakazano, maji se pouzivat vyjimky), naucis se pouzivat STL, nebudes si
plest iteratory a pointery, nebudes kommitovat rozvrtane zdrojaky s
polovinou zapoznamkovanych radek, nebo ne, ale pak te nezachrani ani Tuma.

<< snip >>

> >    void * arg misto void *arg,
>
> vim, pouze preklepy.
>

Rekl bych, ze vsechno jsou "preklepy".

-- Markoid

>Ahoj,
>pouzivejte prosim pro ladici vypisy logger misto std::cout=2E
>-- Markoid

ok, uz jsme se na tom domlouvali=2E
Octa



--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web=2Ecom/ =2E

Ahoj,
1) RPC:
- melo by se nekde vysvetlit, jak to funguje;
- melo by se sjednotit nazvoslovi, bud vsude RPC nebo _vsude_ RMI, ale =
ne to mixovat
- vygenerovane objekty drzici marshallovane parametry nutne pro dispatch =
funkce by se mely jmenovat nejak jinak, ne RPC_neco
- Remote<> je pointer na _interface_, tudiz by si dle me mela kazda =
funkce mit moznost urcit, jak se bude vyvolavat (synchronne, =
asynchronne, s replikacnim trikem); rozhodne bych tam nechtel mit 2 =
(sync ano/ne) x 2 (replikacni trik ano/ne) typu ruznych RMI pointeru
2) ObjectManager & GC:
- porad tvrdim, ze dorucene objekty zustavaji rootem v dobe doruceni; =
Boovie, pust si test/philosophers, nastav si breakpoint do =
GC::ref_count_collect(); zjistis, ze kdyz se pousti posledni reference, =
objekt je porad root a tudiz hnije do dalsiho behu GC (jinymi slovy u =
tech filozofu se uplne muze vypnout instant refcounting, protoze se =
nikdy nedostatne ke slovu)

-- Markoid

Ahoj,
jak jsme se posledne domluvili, co nejdrive dodelam do core zakladni =
podporu replik. Bude se akorat jednat o to, aby byl GC schopen s =
replikami spravne zachazet - tj. jen vytvareni a ruseni replik + =
ovlivnovani doby zivotnosti. Tohle naimplementuju primo do GC. Dalsi =
fazi, tj. zadani o repliky pres sit, replikacni protokol, apod. =
ponechavami na Stepanovi. Mimo jine se ukazuje rada veci, ktere bude =
muset Stepan doresit, napr. co udelat, kdyz odmigruje objekt, ktery je =
nekam replikovan (networktime na novem serveru bude samozrejme uplne =
jiny).
Jinak by se "fakt" melo urcyhlene vyresit to nazvoslovi is_replica vs =
is_replicated, protoze je v tom peknej bordel.

-- Markoid

> Ehm, sorry, chyba v lidskem faktoru (ve mne) jako obvykle :)
> Detekovat kde je chyba bylo samozrejme otazka par sekund,
> kdybych se poradne podival.
>
> Objekt se totiz archivoval dvakrat...hodila se vyjimka,
> ale to co me zajima proc mi to nic nenapsalo pri spusteni
> (logger ji nevypsal kdyz se hodila)?
> Zavolalo se akorat std::terminate() podle call stacku a pak kill;
> na vystupu  se objevilo jen "aborted".

protoze chyba nastala v kontextu, kdy neexistoval zadny aktivni catch block.
kdybys pouzival normalni debuggery, zastavi se ti to u toho throw. vubec ale
nechapu jak to souvisi s tema vlaknama... ze by gdb zase neco nepochopil?

-- Markoid

Caues,
Dalsi tema, ktere by se melo upresnit -
Pravidla pro serializace.


- TextInt::read() - Ma hazet vyjimku pokud nacteny int presahuje
   zadanou bitovou presnost? Nebo je povinnosti volaneho si to
   otestovat sam?

- Pro chytani spatnych srializaci je vyjimka
   ExSerializationError.
   Otazka - maji byt vyjimky hazene serializatory (int, float, ...),
   coz jsou nyni potomky ExIoError, potomky ExSerializationError,
   nebo ma byt ExSerializationError potomek ExIoError
   a pro spatnou serializaci chytat vyjimku ExIoError pouze?

- Pravidla by pak mela vypadat nejak takto:
   my_class.xxx_write() a my_class.xxx_read()
   - Musi hazet pouze ExSerializationError vyjimky,
     pripadne ExIoError. Ostatni vyjimky jsou brany
     jako selhani systemu -> shutdown lokalniho nodu.
     Takze napriklad inicializace pointeru (jako
     dusledek serializace) na typove nekompatibilni
     tridu (podle object id ktere se do toho rve)
     by mel hodit ExSerialziationError, neb to
     neni fatal error.
   - Pri hozeni vyjimky nemusi obnovovat stav objektu
     pred serializaci, tzn. pokud se hodi vyjimka,
     objekt muze zustat pozmenen serializaci. Samozrejme
     pozmenen pouze tak, aby byl spravne znicen
     destruktorem.

A jeste obecne je problem, kdyz serializer zmeni stav
systemu (nejak). Proste na to je bacha davat pozor,
aby napr. klient nemohl poslat tak upraveny stream, ktery
by zpusobil zmenu stavu systemu, ktera by zustala i pote,
co by se chytila vyjimka a naserializovane objekty by
se smazaly.


Petr