massiv-devel Mailing List for Massively multiplayer game middleware

Mam to taky bez problemu. Na obou pocitacich.
Ondrej

PT> Co to je ? Ja zkompiluju vse bez chyb, a navic SerializerTest je prece friend v evente...
PT> Jsi si jisty ze mas versi event.h 1.8? Rozdil mezi 1.7 a 1.8 je pouze v tom friendu na ten SerializerTest.

PT> Petr

PT>   ----- Original Message ----- 
PT>   From: Marek Vondrak 
PT>   To: mas...@li... 
PT>   Sent: Tuesday, July 30, 2002 7:26 PM
PT>   Subject: [Massiv-devel] bug report


PT>   Ahoj Petre, tohle si oprav:

PT>    runin ..\ nmake /f makefile.win32 .bin/win32_x86/optimized_debug/core.lib
PT>   '.bin/win32_x86/optimized_debug/core.lib' is up-to-date
PT>    runin ..\..\ext\cryptopp\ nmake /f makefile.win32 .bin/win32_x86/optimized_debug/cryptopp.lib
PT>   '.bin/win32_x86/optimized_debug/cryptopp.lib' is up-to-date
PT>    cl /nologo /W3 /G5 /YX /ZI /MD /Fp".bin/win32_x86/optimized_debug/massiv.pch" /Fd".bin/win32_x86/optimized_debug/massiv.pdb" /GX /GR /c /Fo.bin/win32_x86/optimized_debug/test_serializer.obj
PT> /D__WIN32__ /D__MSVC__ /D__X86__ /D__OPTIMIZE__ /D__DEBUG__     /I.. /I..\..\ext\cryptopp /I..\global /I..\logger /I..\net /I..\object /I..\other /I..\pointer /I..\property /I..\registry
PT> /I..\serializer /I..\status /I..\sysevent /Tp test_serializer.cpp
PT>   test_serializer.cpp
PT>   d:\massiv\root\src\core\test\test_serializer.cpp(510) : error C2248: 'Massiv::Core::Event::local_schedule_index' : cannot access private member declared in class 'Massiv::Core::Event'
PT>           d:\massiv\root\src\core\object\event.h(189) : see declaration of 'Massiv::Core::Event::local_schedule_index'
PT>           d:\massiv\root\src\core\object\event.h(43) : see declaration of 'Massiv::Core::Event'
PT>   ...



-- 
 Ondrej                            mailto:oc...@ma...

Co to je ? Ja zkompiluju vse bez chyb, a navic SerializerTest je prece =
friend v evente...
Jsi si jisty ze mas versi event.h 1.8? Rozdil mezi 1.7 a 1.8 je pouze v =
tom friendu na ten SerializerTest.

Petr

  ----- Original Message -----=20
  From: Marek Vondrak=20
  To: mas...@li...=20
  Sent: Tuesday, July 30, 2002 7:26 PM
  Subject: [Massiv-devel] bug report


  Ahoj Petre, tohle si oprav:

   runin ..\ nmake /f makefile.win32 =
.bin/win32_x86/optimized_debug/core.lib
  '.bin/win32_x86/optimized_debug/core.lib' is up-to-date
   runin ..\..\ext\cryptopp\ nmake /f makefile.win32 =
.bin/win32_x86/optimized_debug/cryptopp.lib
  '.bin/win32_x86/optimized_debug/cryptopp.lib' is up-to-date
   cl /nologo /W3 /G5 /YX /ZI /MD =
/Fp".bin/win32_x86/optimized_debug/massiv.pch" =
/Fd".bin/win32_x86/optimized_debug/massiv.pdb" /GX /GR /c =
/Fo.bin/win32_x86/optimized_debug/test_serializer.obj /D__WIN32__ =
/D__MSVC__ /D__X86__ /D__OPTIMIZE__ /D__DEBUG__     /I.. =
/I..\..\ext\cryptopp /I..\global /I..\logger /I..\net /I..\object =
/I..\other /I..\pointer /I..\property /I..\registry /I..\serializer =
/I..\status /I..\sysevent /Tp test_serializer.cpp
  test_serializer.cpp
  d:\massiv\root\src\core\test\test_serializer.cpp(510) : error C2248: =
'Massiv::Core::Event::local_schedule_index' : cannot access private =
member declared in class 'Massiv::Core::Event'
          d:\massiv\root\src\core\object\event.h(189) : see declaration =
of 'Massiv::Core::Event::local_schedule_index'
          d:\massiv\root\src\core\object\event.h(43) : see declaration =
of 'Massiv::Core::Event'
  ...

Ahoj Petre, tohle si oprav:

 runin ..\ nmake /f makefile.win32 =
.bin/win32_x86/optimized_debug/core.lib
'.bin/win32_x86/optimized_debug/core.lib' is up-to-date
 runin ..\..\ext\cryptopp\ nmake /f makefile.win32 =
.bin/win32_x86/optimized_debug/cryptopp.lib
'.bin/win32_x86/optimized_debug/cryptopp.lib' is up-to-date
 cl /nologo /W3 /G5 /YX /ZI /MD =
/Fp".bin/win32_x86/optimized_debug/massiv.pch" =
/Fd".bin/win32_x86/optimized_debug/massiv.pdb" /GX /GR /c =
/Fo.bin/win32_x86/optimized_debug/test_serializer.obj /D__WIN32__ =
/D__MSVC__ /D__X86__ /D__OPTIMIZE__ /D__DEBUG__     /I.. =
/I..\..\ext\cryptopp /I..\global /I..\logger /I..\net /I..\object =
/I..\other /I..\pointer /I..\property /I..\registry /I..\serializer =
/I..\status /I..\sysevent /Tp test_serializer.cpp
test_serializer.cpp
d:\massiv\root\src\core\test\test_serializer.cpp(510) : error C2248: =
'Massiv::Core::Event::local_schedule_index' : cannot access private =
member declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(189) : see declaration of =
'Massiv::Core::Event::local_schedule_index'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(567) : error C2248: =
'Massiv::Core::Event::execution_time' : cannot access private member =
declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(179) : see declaration of =
'Massiv::Core::Event::execution_time'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(568) : error C2248: =
'Massiv::Core::Event::local_schedule_index' : cannot access private =
member declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(189) : see declaration of =
'Massiv::Core::Event::local_schedule_index'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(569) : error C2248: =
'Massiv::Core::Event::object_to_deliver' : cannot access private member =
declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(182) : see declaration of =
'Massiv::Core::Event::object_to_deliver'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(571) : error C2248: =
'Massiv::Core::Event::execution_time' : cannot access private member =
declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(179) : see declaration of =
'Massiv::Core::Event::execution_time'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(572) : error C2248: =
'Massiv::Core::Event::local_schedule_index' : cannot access private =
member declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(189) : see declaration of =
'Massiv::Core::Event::local_schedule_index'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(573) : error C2248: =
'Massiv::Core::Event::object_to_deliver' : cannot access private member =
declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(182) : see declaration of =
'Massiv::Core::Event::object_to_deliver'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(593) : error C2248: =
'Massiv::Core::Event::execution_time' : cannot access private member =
declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(179) : see declaration of =
'Massiv::Core::Event::execution_time'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(594) : error C2248: =
'Massiv::Core::Event::local_schedule_index' : cannot access private =
member declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(189) : see declaration of =
'Massiv::Core::Event::local_schedule_index'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(595) : error C2248: =
'Massiv::Core::Event::object_to_deliver' : cannot access private member =
declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(182) : see declaration of =
'Massiv::Core::Event::object_to_deliver'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(597) : error C2248: =
'Massiv::Core::Event::execution_time' : cannot access private member =
declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(179) : see declaration of =
'Massiv::Core::Event::execution_time'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(598) : error C2248: =
'Massiv::Core::Event::local_schedule_index' : cannot access private =
member declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(189) : see declaration of =
'Massiv::Core::Event::local_schedule_index'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(599) : error C2248: =
'Massiv::Core::Event::object_to_deliver' : cannot access private member =
declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(182) : see declaration of =
'Massiv::Core::Event::object_to_deliver'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(609) : error C2248: =
'Massiv::Core::LocalSchedule::events' : cannot access private member =
declared in class 'Massiv::Core::LocalSchedule'
        d:\massiv\root\src\core\object\local_schedule.h(250) : see =
declaration of 'Massiv::Core::LocalSchedule::events'
        d:\massiv\root\src\core\object\local_schedule.h(88) : see =
declaration of 'Massiv::Core::LocalSchedule'
d:\massiv\root\src\core\test\test_serializer.cpp(609) : error C2248: =
'Massiv::Core::LocalSchedule::events' : cannot access private member =
declared in class 'Massiv::Core::LocalSchedule'
        d:\massiv\root\src\core\object\local_schedule.h(250) : see =
declaration of 'Massiv::Core::LocalSchedule::events'
        d:\massiv\root\src\core\object\local_schedule.h(88) : see =
declaration of 'Massiv::Core::LocalSchedule'
d:\massiv\root\src\core\test\test_serializer.cpp(611) : error C2248: =
'Massiv::Core::Event::execution_time' : cannot access private member =
declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(179) : see declaration of =
'Massiv::Core::Event::execution_time'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(612) : error C2248: =
'Massiv::Core::Event::local_schedule_index' : cannot access private =
member declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(189) : see declaration of =
'Massiv::Core::Event::local_schedule_index'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(613) : error C2248: =
'Massiv::Core::Event::object_to_deliver' : cannot access private member =
declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(182) : see declaration of =
'Massiv::Core::Event::object_to_deliver'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(617) : error C2248: =
'Massiv::Core::Event::execution_time' : cannot access private member =
declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(179) : see declaration of =
'Massiv::Core::Event::execution_time'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(618) : error C2248: =
'Massiv::Core::Event::local_schedule_index' : cannot access private =
member declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(189) : see declaration of =
'Massiv::Core::Event::local_schedule_index'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(619) : error C2248: =
'Massiv::Core::Event::object_to_deliver' : cannot access private member =
declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(182) : see declaration of =
'Massiv::Core::Event::object_to_deliver'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(625) : error C2248: =
'Massiv::Core::LocalSchedule::events' : cannot access private member =
declared in class 'Massiv::Core::LocalSchedule'
        d:\massiv\root\src\core\object\local_schedule.h(250) : see =
declaration of 'Massiv::Core::LocalSchedule::events'
        d:\massiv\root\src\core\object\local_schedule.h(88) : see =
declaration of 'Massiv::Core::LocalSchedule'
d:\massiv\root\src\core\test\test_serializer.cpp(625) : error C2248: =
'Massiv::Core::LocalSchedule::events' : cannot access private member =
declared in class 'Massiv::Core::LocalSchedule'
        d:\massiv\root\src\core\object\local_schedule.h(250) : see =
declaration of 'Massiv::Core::LocalSchedule::events'
        d:\massiv\root\src\core\object\local_schedule.h(88) : see =
declaration of 'Massiv::Core::LocalSchedule'
d:\massiv\root\src\core\test\test_serializer.cpp(627) : error C2248: =
'Massiv::Core::Event::execution_time' : cannot access private member =
declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(179) : see declaration of =
'Massiv::Core::Event::execution_time'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(628) : error C2248: =
'Massiv::Core::Event::local_schedule_index' : cannot access private =
member declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(189) : see declaration of =
'Massiv::Core::Event::local_schedule_index'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(629) : error C2248: =
'Massiv::Core::Event::object_to_deliver' : cannot access private member =
declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(182) : see declaration of =
'Massiv::Core::Event::object_to_deliver'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(633) : error C2248: =
'Massiv::Core::Event::execution_time' : cannot access private member =
declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(179) : see declaration of =
'Massiv::Core::Event::execution_time'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(634) : error C2248: =
'Massiv::Core::Event::local_schedule_index' : cannot access private =
member declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(189) : see declaration of =
'Massiv::Core::Event::local_schedule_index'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'
d:\massiv\root\src\core\test\test_serializer.cpp(635) : error C2248: =
'Massiv::Core::Event::object_to_deliver' : cannot access private member =
declared in class 'Massiv::Core::Event'
        d:\massiv\root\src\core\object\event.h(182) : see declaration of =
'Massiv::Core::Event::object_to_deliver'
        d:\massiv\root\src\core\object\event.h(43) : see declaration of =
'Massiv::Core::Event'

Nasledujici veci bych co nejdrive chtel doresit:

1) jakym zpusobem se bude urcovat tracked_by_provider?
    - napr. podobna vlastnost objektu jako, zda to je GC root se =
nastavuje tak, ze prislusna class zdedi z GCRootObject
    bylo by dobre kdyby se to nejakym zpusobem sjednotilo =
(TrackedObject?)

2) co udelat, kdyz odmigruje objekt, na ktery ukazuje strong pointer?
    - zavest teda strong =3D> migruje?

3) pojmenovavani vygenerovanych veci:
    napr. stuby pro vzdalene objekty by se mohly generovat do =
Massiv::Core::RMIStub<Iface>
    co s ObjectFactories? zmenit ObjectFactory na CommonObjectFactory a =
konkretni "verze" generovat do Massiv::Core::ObjectFactory<ClassType>
    rozdil zde je navic taky ten, ze ObjectFactory pro dany typ musi byt =
rucne inicializovana a registrovana, zatimco RMIStub<> ne a tudiz
    se na nej staci odkazovat primo nazvem typu

4) net (Octa):
    je nutne, aby se vsechno alokovalo dynamicky? (decryptor, encryptor, =
adresa, ...)
    v ostatnich castech massivu se vsude s bitstreama pracuje hodnotou, =
tudiz veskere interfacy by se mely zmenit z XXXBuffer * na XXXBuffer &

    kdyz se nekde pracuje s kontejnerama v STL, tak se obvykle ukladaji =
do tech kontejneru primo prvky jako hodnoty, ne pointery
    (je skutecne treba mit std::list<XXXBuffer *>?)?

    layout

5) threading:
    _laskave_ predelat podle predchozich komentaru a zmenit layout

6) filesys:
    tak jak teda? bude Marekus schopen upravit ty cvary?

-- Markoid

Cau,

tady zase seznamuju ostatni cleny (patrne asi jenom Boovieho) s novymi =
featurami v ObjectModel:

1) RTTI rozsireno o moznost zjistovat typy, nazvy a stavy veskerych =
Properties
2) debugovaci vypisy Properties, Objects (operator<<)
3) dokoncen GC, moznost ulozit image lokalni pameti a prohlednout si ho =
ve GraphViz
4) zacatek RPC/RMI:
Remote<Interface>  znamena pointer na vzdaleny objekt, umoznujici
vyvolavat vzdalene metody na tomto objektu pres zadany interface

-- Markoid

----- Original Message -----
From: "Petr Tovarys" <pto...@ss...>
To: "MASSIV-DEVEL" <mas...@li...>
Sent: Saturday, July 27, 2002 7:55 PM
Subject: [Massiv-devel] ukol: safe serialization & net::zpracovani paketu


>
> Caute,
>
> A) Bezpecne serializace - Chce to rozmyslet jak se budou zpracovavat
> spatne serializace (spatny paket, ...).
> Je nutno:
>  1) Presne urcit jake vyjimky mohou vybublat ze serializaci, a ktere
> lze zastavit a pritom aby bylo zaruceno, ze system je v konzistentnim
> stavu. Napriklad serializace mohou hodit vyjimku cteni za konec
bitstreamu,
> maji to serializatory premapovat na nejakou obecnou vyjimku typu
> "chyba serializace"? Jak zarucit konzistenci napriklad pri serializaci
> object pointeru, kdo vi kde se tam vsude hrabe do vnitrnich struktur
> manazeru?

ObjectPointer je udelan tak, ze inicializace ze streamu bude probihat
pomoci std. prirazovani do ObjectPointeru a tam je samozrejme
udelano to, ze se veskere kontroly provedou pred vlastni
modifikaci dat. struktur; tudiz chyba nema nikdy fatalni dusledek.

>  2) Co se spatnymi pakety (bitstreamy) - nekdo by mel vyhodnocovat
> od koho prisel spatny paket a podle toho urcit akci (odpojeni klienta,
> info adminovi, ...)? Nejaky obecny chytry objekt zpracovavajici ruzne
> statistiky celeho Massiv Core?

to by se asi hodilo

>
> B) Jen pro shrnuti jak ma probihat zpracovani paketu:
> Pres sit mohou cestovat pouze zpravy tridy SystemMessage.
> 1) Prijem paketu sitovou vrstvou a jeho odkryptovani.
> 2) Z paketu je vytvoren BitIStream.
> 3) BitIStream je predan staticke metode
>  SystemMessage::dispatch_system_message_from_packet()
>  spolu s informace od koho paket prisel apod.
> 4) Tato funkce z bitstreamu vytvori odpovidajici SystemMessage
>  a ten vlozi do globalni systemove fronty udalosti.
> 5) V kazdem ticku jsou pak zpravy vyzvednuty z fronty a zpracovany
>  postupne.
> 6) Kazda SystemMessage projde serii filtru, ktere testuji

Tohle si nedokazu predstavit. Podle me bohate staci to, ze data jsou
kryptovana, tudiz se jim da duverovat. Pokud ten, kdo bude stream
cist a podle toho neco delat, narazi na chybu, hodi vyjimku a je povinen
vratit datove struktury do puvodniho stavu.
Psat ale specialni filtr, ktery nejprve vsechno otestuje a teprve pak,
se preda dal by bylo asi dost tezke, nebot interni struktura streamu
asi bude dost divoka a nikdo neni schopen predem rict, jak bude
vypadat (viz automaticke serializovani, apod.) - je to rizeno
1) implementaci serializatoru primitvnich typu
2) poradim serializaci, tj. to urcuje skriptem generovany kod podle IDL

Markoid

Caue,

1) to Markoid: Jak to teda udelat s tema pointrama na objekty v object
manageru, jak jsme se kdysi bavili - jestli ma object manager vnitrne
pracovat jiz s ObjectPointrem a ne s Object *. Jednim z duvodu bylo
swapovani, a ted nevim jestli byl nejaky problem i s garbag collectorem.
Mam prepsat ty Object * na ObjectPointer?

2) ObjectPointery & archivace (serializace):
Jenom abych se ujistil jak ma fungovat nacteni ze zalohy (a tudiz zvolil
rozumny format zalohovaciho souboru):
Jak jsme se kdysi bavili o obnovovani objektu z migracniho paketu - je nutno
nejdrive vytvorit vsechny objekty z migracniho paketu a teprve pote
je vyserializovat z paketu. Kvuli ObjectPointerum neslo vytvaret
a vyserializovat objekty postupne jeden po druhem.
Predpokladam ze to plati stale. Tudiz pri obnovni ze zalohy je nejdrive
nutno vytvorit vsechny objekty ze zalohy a pote je teprve vsechny
vyserializovat. Ted me napada ze ne vsechny objekty, ale staci je vytvaret
po migracnich skupinach.

3) Archivacni soubor: Je jasne, ze archivacni soubor nebude proste textak
kde budou objekty za sebou. Jednak je nutno v nem nejak indexovat podle
migracnich grup a objektu, dvak v budoucnu chceme spojit archivacni soubor
spolu se swapem na odswapovavani souboru, trak jestli jsem to spravne
pochopil ten Volume, tak ten data ktera se sejvujou do nej jsou
rozkouskovana
na bloky a ty bloky nejsou ukladany fyzicky za sebe v souboru, cili vysledek
bude rozhazeny pro lidske oko.
Tudiz ale nelze provadet nejake ty rucni upravy, ktere se puvodne
zamyslely na upgrade skriptu (ze se na to pusti nejaky skriptik apod).
Jinak co se tyce swapovani, videl bych to tak, ze globalni zaloha
bude textova, lokalni zalohy (aby nebyly videny pro hrace) budou
binarni (jelikoz budou soucasne swapy, jak jsem psal kdysi v poznamce
o swapovani).

4) To Marekus: Ty BitIOStreamy jsou docela bugove,
u BitIStream::tail() je napsano ze aktualni pozici alignuje na hranici
bajtu, ale podle me ji nealignuje "smerem ke konci" ale smerem "ke predu"
bufferu, coz je jine chovani alignu nez treba u fukce
BitIStream::align_to_byte(), kde align == skip. Spravne chovani podle me
ma byt alignuti ke konci. Volani samotneho tail() byse melo chovat
stejne jako kdybych zavolal align_to_byte() a potom az tail().
Dalsi chyby v BitOStream::write_bitistream() jsou na sf.


Petr

Caute,

A) Bezpecne serializace - Chce to rozmyslet jak se budou zpracovavat
spatne serializace (spatny paket, ...).
Je nutno:
 1) Presne urcit jake vyjimky mohou vybublat ze serializaci, a ktere
lze zastavit a pritom aby bylo zaruceno, ze system je v konzistentnim
stavu. Napriklad serializace mohou hodit vyjimku cteni za konec bitstreamu,
maji to serializatory premapovat na nejakou obecnou vyjimku typu
"chyba serializace"? Jak zarucit konzistenci napriklad pri serializaci
object pointeru, kdo vi kde se tam vsude hrabe do vnitrnich struktur
manazeru?

 2) Co se spatnymi pakety (bitstreamy) - nekdo by mel vyhodnocovat
od koho prisel spatny paket a podle toho urcit akci (odpojeni klienta,
info adminovi, ...)? Nejaky obecny chytry objekt zpracovavajici ruzne
statistiky celeho Massiv Core?


B) Jen pro shrnuti jak ma probihat zpracovani paketu:
Pres sit mohou cestovat pouze zpravy tridy SystemMessage.
1) Prijem paketu sitovou vrstvou a jeho odkryptovani.
2) Z paketu je vytvoren BitIStream.
3) BitIStream je predan staticke metode
 SystemMessage::dispatch_system_message_from_packet()
 spolu s informace od koho paket prisel apod.
4) Tato funkce z bitstreamu vytvori odpovidajici SystemMessage
 a ten vlozi do globalni systemove fronty udalosti.
5) V kazdem ticku jsou pak zpravy vyzvednuty z fronty a zpracovany
 postupne.
6) Kazda SystemMessage projde serii filtru, ktere testuji
 ruzne bezpecnostni veci (jak jsem o tom psal kdysi v pojednani
 o komunikaci).
7) Nyni se predpoklada, ze do teto faze projdou uz jen "bezpecne"
 zpravy, a ty jsou predany ObjectManageru,ktery je uz nejak zpracuje.

1-3) ma na starosti sitova vrstva, co dela Octa (Marekus??).
4), SystemMessage a frontu hodim na cvs az premapuju ServerId na NodeId.
Tot pro dnesek vse, bye,


Petr

Ahoj, tak uz mi nic posilat nemusite, uz jsem na to prisel a delam na tom, dodelavam i to lock a unlock netobufferu, ted budu 4 dny bez netu, nedeli vecer to tam hodim.
Octa 

Hello Petr,
Tuesday, July 16, 2002, 7:41:34 PM, you wrote:

PT> Caute,
PT> Neco z minula:

PT> 1) Muze nekdo sepsat ideu jak se maji posilat a prijimaji pakety a jak se
PT> s nima presne pracuje (netbitiostreamams a jejich metoda send() nebo lock()
PT> nebo jak? Net::get_packet()? .....?), jak zazadat (koho) o sitovy paket
PT> na poslani, jak ziskat prijate pakety, ...

PT> 1.1) Pracuje nekdo na te tom Network api? Asi ne, takze to asi skusim nejak
PT> podle svych predstav.

ad 1) posilani delam ja, prijimani podle posledni dohody marekus,
takze to posilani (jestli jsem pochopil tvoji otazku )

void Network::lock(
        ServerId    id,
        StreamType  stream_type,
        UInt32      tag
        );
vrati ukazatel na TCPOBuffer nebo UDPOBuffer podle stream_type( STREAM_UNRELIABLE nebo STREAM_RELIABLE )
pracuje se s tim jako s BitOStream
ten prvni parametr se musi zmenit, mel by to byt nejaky hash na
serverid a veci s nim spojene ( socketcp, socketudp, rsa,
blowfishencryptor, blowfishencryptor ). Netusim ale, jak ten hash
pouzivate, koukal jsem, ze ten serverid uz nejaky hash ma v sobe, tak
aby to nebyl moc veliky bordel, chtelo by se nad tim asi zamyslet.
POkud nekdo strucne napisete, jak se pouziva ten hash_map, tak budu
vdecny - staci na jednoduchem priklade. Ja to pak predelam na
hash_map. Dik. Tohle je NUTNE k dalsi praci. Ten bitiostream totiz
musi ukazovat na nejakou strukturu ci "neco", co obsahuje vyse zminene
informace o serveru ). To "neco" by se vytvorilo pri vzniku
spojeni. Myslim, ze Boovie rika neco o hashovani, tak to sem taham.

uvolneni streamu a pripadne odeslani.
void Network::unlock
        (
        TCPOBuffer *  netbuffer
        );

void Network::unlock
        (
        UDPOBuffer *  netbuffer,
        bool    flush_allowed=true
        );
u UDP je mozne nastavit, zda se muze odelat. U tcp se je buffer hned
pripraven k odeslani. To odesilani jestli se dobre pamatuju by se melo
periodicky volat z nejake vysi vrstvy a tak jsem tam zatim udelal
metodu void Network::send_all_messages() ktera ty uvolnene buffery (to
znamena TCP automaticky, UDP jen flush_allowed=true) odesle. Jestli se
mylim, tak me kamenujte. UDP Buffer lze explicitne pripravit na
odeslani take volanim
void Network::flush
    (
    UDPOBuffer *  netbuffer
    )


To prijimani fakt nevim, musime to dat dohromady. Zas bude nejaka
metoda vyssi vrstvy, ktera bude message prijimat
Net::retrieve_messages()  ???
a pak by mela byt nejaka metoda Net::get_message( ServerID, stream_type
)
ktera by mela vracet BitIStream ( uz dekodovany asi )

To je asi vse zatim, ja bych se ted vrhnul na to odesilani, na ten
hash_map toho nodeid (nebo jak tomu ted rikate ) k ostatnim vecem, co
se serveru tyka. Pak by nebyl problem dodelat to odesilani.

Jinak v Praze jsem nedele vecer az streda vecer, tak me kamenujte.
Dik cau Octa

Jo jeste neco, mam takovy VETSI problem a prosbu:
problem je, ze jsem kvuli bordelu na KAM nedostal kolej na pristi rok
(ani na odvolani - na 17.listopadu, protoze si mysli, ze jdu do
sestaku. Dekan MFF UK mi ale dovololil opakovat rocnik, takze jdu do
pateho rocniku - to je ale nezajima ) Rad bych samozrejme
na koleji bydlel a mel internet k dispozici ( a samozrejme pracoval na
projektu ). Mam notebook, takze
nezaberu moc mista, na koleji bych byl tak od 17:00 a rano bych zase
vypadnul. Na kolejne bych samozrejme prispival, nebyl bych tu o
vikendech a vypadnul bych ve ctvrtek vecer. Pokud vite o nekom, kdo by to
prezil nebo mi dokazal nejak pomoci, tak dejte vedet. Obracim se
hlavne na kolejisty Boovieho a Hafa - treba o nekom vi, ze tu nebude.
Moc by mi to ulehcilo zivot. Dikes za jakekoliv info.

Hello Petr,
Tuesday, July 16, 2002, 7:41:34 PM, you wrote:

PT> Caute,
PT> Neco z minula:

PT> 1) Muze nekdo sepsat ideu jak se maji posilat a prijimaji pakety a jak se
PT> s nima presne pracuje (netbitiostreamams a jejich metoda send() nebo lock()
PT> nebo jak? Net::get_packet()? .....?), jak zazadat (koho) o sitovy paket
PT> na poslani, jak ziskat prijate pakety, ...

PT> 1.1) Pracuje nekdo na te tom Network api? Asi ne, takze to asi skusim nejak
PT> podle svych predstav.

PT> 2) Jak poznat ze grupa se ma odswapovat?

PT> 2.1) K cemu swapovani vubec zavadet? Respektive kdo si vezme na sva bedra
PT> load balancing - jeho navrh jak ma fungovat?

PT> 3) V zari se bude psat zprava o projektu pro komisi, kde se mimo jine
PT> uvadi kdo kolik ceho dosud na projektu udelal. Jen upozornuji, abyste si
PT> praci na Massivu dopre naplanovali do te doby...

PT> Petr




PT> -------------------------------------------------------
PT> This sf.net email is sponsored by: Jabber - The world's fastest growing 
PT> real-time communications platform! Don't just IM. Build it in! 
PT> http://www.jabber.com/osdn/xim
PT> _______________________________________________
PT> Massiv-devel mailing list
PT> Mas...@li...
PT> https://lists.sourceforge.net/lists/listinfo/massiv-devel

ad 1)
ja to napisu hned jak budu mit chvilku, byl jsem ted 10 dni ve
francii. Vim, ze to specha, fakt se na to hned mrknu - zkusim to
dneska (nedele) vecer.
Octa

-- 
 Ondrej                            mailto:oc...@ma...

>
> > 1) ObjectManagement/GC:
>
> Takhle to podle me melo byt, ale ted nevim co myslis tim, aby to bylo
> dostatecne efektivni, protoze do pointeru vubec nevidim :) ale podle
> toho co pises je mozne, aby strong nebyl monitored a tudiz
> byl efektivnejsi(?).

Monitored znamena, ze jakakoliv zmena je oznamena jak objektu, ktery
pointer vlastni, tak objektu, na ktery se ukazuje
-> overhead

Protoze k tomu Stepan  zatim nic nerekl, nebudu to nijak predelavat, ale
pokud by to opravdu bylo strong => migruje, pak se muzou zrusit ty
migracni bity, protoze uz to bude urceno tim strongness / weakness.

>
> >2) Swapovani objektu:
> >
> No zni to docela dobre, ideov proti tomu nemam namitek :) Ale
> 1/ Porad si nejsem nejak jisty k cemu swapovani vubec zavadet.
> 2/ Implementace:
> Spis nez dalsi object manager bych to udelas soucasti aktualniho
> object manageru (stejne jako je ted GC, tak by pribyl SC - Swap
> Collector),
> tzn. testovani zda je objekt lokalni by bylo
> if( gc.is_local( id ) || sc.is_swapped( id ) ) ..
> V tom problem neni.
> Problem je pri archivaci, nebot pri zapocati archivace je nutno
> oflagovat vsechny objekty ( "archive on write" ), coz by znamenalo
> naswapovani vsech odswapovanych objektu, coz by uz rozhodne nebylo
> "neviditelne pro uzivatele".
> Moznosti:
> 1/ Swapovaci node - Bezici uplne v jinem procesu (jinem pocitaci), na nej
> by se posilaly migracni grupy. Neumel by simulovat objekty, ale jen
> migrovat
> a ukladat do souboru.
> Tohle bych rozhodne nedelal, protoze by se tim jen zeslozitela komunikace
> mezi nody.

to bych taky nedelal

> 2/ Udelat swapovaci soubor primo archivacnim souborem. Tento archivacni
> soubor by byl binarni (mozna by ani nemusel).
> Pri zapocati archivace by se aktualni soubor asynchronne zkopiroval
> do noveho souboru, ktery by reprezentoval aktualni save. Tim by byly
> sejvnuty vsechny odswapovane objekty a tudiz by se nemusely vubec
> flagovat.

to by bylo asi nejjednodussi, navic protoze uz mame zaklad filesys/volume,
nebyl by to ani problem

> Dalsi problem je - jak poznat ze grupa se ma odswapovat?
> Idealne chceme pokud plati:
> - s zadnym objektem ze skupiny po urcitou dobu nikdo nekomunikoval (a
> ani vnitrni komunikace v ramci skupiny).
> - zadny objekt ze skupiny nema na blizkou dobu naplanovanou zadnou udalost
> (tzn. minimum z heap lokalnich schedule objektu ve skupine).
> Napada nekoho jak todle delat? A vubec cely load balancing
> by si nekdo mohl vzit jako pekny ukol na premysleni :)

Load balancing musime udelat tak jako tak a rozhodnuti o deaktivaci objektu
/ swapout
bude jen vedlejsi produkt tohodle.

>
> >3) Filesys:
> >
> > jakym zpusobem udrzovat databazi o verzich souboru
> >
> >Moznosti jsou v zasade dve:
> >a) co soubor, to soubor na disku + nejaka nami spravovana extra
> > databaze tech verzi a specialnich atributu
> >b) vsechno to cpat do jednoho "pak" souboru
>
>
> Me se libi spise varianta a)
> Spis bych to videt ala quake, tedy a) s tim, ze lze namapovat
> i vice pak souboru...ale jinak je mi to jedno.

Podle toho co pises, mas asi spis na mysli variantu b),
tj. vlastni image soubor(y) a filesystem v nich.
To by ale znamenalo, ze bude muset Marekus zobecnit ty
adresarove sluzby z registry, nebudu to zbytecne psat znovu.

Caute,
Neco z minula:

1) Muze nekdo sepsat ideu jak se maji posilat a prijimaji pakety a jak se
s nima presne pracuje (netbitiostreamams a jejich metoda send() nebo lock()
nebo jak? Net::get_packet()? .....?), jak zazadat (koho) o sitovy paket
na poslani, jak ziskat prijate pakety, ...

1.1) Pracuje nekdo na te tom Network api? Asi ne, takze to asi skusim nejak
podle svych predstav.

2) Jak poznat ze grupa se ma odswapovat?

2.1) K cemu swapovani vubec zavadet? Respektive kdo si vezme na sva bedra
load balancing - jeho navrh jak ma fungovat?

3) V zari se bude psat zprava o projektu pro komisi, kde se mimo jine
uvadi kdo kolik ceho dosud na projektu udelal. Jen upozornuji, abyste si
praci na Massivu dopre naplanovali do te doby...

Petr

Caute,
Zde posilam novejsi versi komunikace mezi Nody.
Ke stare versi ani k migracnimu protokolu jsem nedostal zadne pripominky
(ani odpovedi na otazky), takze predpokladam, ze vsichni souhlasite.
Pokud nebudou pripominky ani k tomudle, zacnu to pomalu predelavat
na tuto versi, ktera dle meho by jiz mela fungovat.


Shrnuti stare verse:
-------------------

Problem pri migraci byl, ze klient se ruzne pripojuje a odpojuje od
simulacnich serveru. Protoze ale server nemuze iniciovat spojeni
na klienta, musi se nejak najit nejaky server, ktery spojeni ma,
a pres tento server zpravu poslat, coz rozbourava ideu, ze k poslani
paketu staci znat NodeId ciloveho adresata. Reseni, ze bude strasne
chytra sitova vrstva a vyssi se o todle nebudou starat nechceme
z ruznych duvodu.

Ve stare versi v teto situaci ruzne provadel broadcast a vubec
to bylo divne, navic neni mozne poznat, zda je jeste klient
pripojen k simulace nebo ne.

Nova verse:
----------

ObjectId bude mit novy flag - ten znamena, ze todle ObjectId reprezentuje
nejaky Node.
Musi platit, ze takoveto ObjectId MUSI byt tracked a navic jeho provider
MUSI existovat nekde v simulaci (to u tracked objektu obecne nemusi platit).

Mezi Nodem a Nodem, ktery mu pridelil jeho specialni ObjectId, musi
exstovat neustale spojeni. Spojeni s ostatnima Nodama se mohou rusit
a spojovat libovolne.
Toto neustale spojeni odpovida spojeni mezi providerem a danym ObjectId.

Specialni ObjectId jsou ignorovana lokalizacnimi cachemi, a na dotaz
na dane ObjectId odpovi odpovidajicim Nodem. Tyto informace mozna muzou
byt udelany jako persistentni polozky cache nebo v samostatnych tabulkach.

Posilani zpravy A k object O, kde O je specialni object id:
- Cache vrati, ze O odpovida node N1.
- Zjisti se, ze k N1 neexistuje spojeni a navic neni povoleno jej ani
  vytvaret. Nyni se pouzije provider prislusejici k O.
  Nyni jednak plati, ze k tomuto providerovi lze vytvarert spojeni
  a take, ze tento provider ma spojeni k N1, tudiz zpravu lze jednoduse
  prespolat pres tohoto providera.

Vyhody nove verse:
- Sitova vrstva muze byt "blba" (zadne grafy spojen, routing atd.).
- Vse se stale tvari jako migracni protokol, pribude jediny test na to,
  zda existuje spojeni na N1. Jinak jde o normalni migraci beze zmen.
Nevyhody:
- Musi existovat neustale spojeni mezi Nodem A a Nodem B, ke kteremu se
  A pripojoval (resp. provider specialniho object id Acka je na B).
  To komplikuje pad nektereho serveru, kdy je nutno pridelit specialni
  object id znova...
- Este je nutno presne doresit pripojovani a pad serveru, jak pridelovat
  specialni object id pri restartu dynamicky, zda to vubec lze. Pridelit
  staticky neni problem (pro klienty bude asi urcite), pro servery
  asi budeme chtit dynamicky (aby mohla simulace bezet i pri padu
  jednoho ci vice serveru).

Add k replikam:
Repliky lze adresovat pouze pres specialni object id, coz by melo
fungovat rozumne a nebude nutno NodeId zpristupnovat do skriptu.

Add jak poznat, ze klient uz neni pripojen k simulaci:
Nyni lze rict, ze klient je pripojen, dokud existuje spojeni
na providera jeho specialniho object id.

Ahoj,
tak az budu mit chvilku sepisu to api, jak vypada posledni verze, o jake jsme mluvili.

Octa


-- 
 Ondrej Pecta                          mailto:oc...@ma...

Caues,
Markoid wrote:


> 1) ObjectManagement/GC:
>
>Takze, aby to fungovalo, musi platit:
>    strong: urcite urcuje migracni skupinu
>    weak: muze urcovat migracni skupinu, nemusi


Ano, myslim ze presne tohle byla posledni verse na ktere jsme se
domluvili.


>Jaka jsou tedy mozna reseni:
>    - strong pointer muze ukazovat na vzdaleny objekt; v takovem pripade,
>se ale chova jako weak (to je asi blbost):


Jo, to bych zakazal.


>    - strong => migruje:
>        protoze strong implikuje migruje, tak strong je taky monitored
>        bylo by to dostatecne efektivni?


Takhle to podle me melo byt, ale ted nevim co myslis tim, aby to bylo
dostatecne efektivni, protoze do pointeru vubec nevidim :) ale podle
toho co pises je mozne, aby strong nebyl monitored a tudiz
byl efektivnejsi(?).


>    - nejakym zpusobem se to silene oprasi a strong pointer na vzdaleny
> objekt bude opravdu fungovat jako strong


To bych taky zakazal. Budem radi, kdyz bude fungovat vubec nejaka
komunikace (a konzistence), natoze se snazit delat neco navic.


>2) Swapovani objektu:
>
> Co mi ale pripada zajimavejsi je, ze by se na kazdem serveru krome
> zakladniho objectmanageru vytvoril nejaky dalsi specialni objectmanager,
> na ktery by se swapovaly cele migracni skupiny objektu. Potom swap
> objetku = odmigrovani objektu.
>
>To Boovie:
>Byl bys ochoten tohle akceptovat? Ten swapovaci object manager
> (jen seznam odswapovanych objektu a sprava tech vyhledavacich cache)
> bys totiz musel programovat ty, rovnez tak upravit stavajici cache,
> aby byly schopny dohledat objekt ve svem lokalnim swapu, apod.


No zni to docela dobre, ideov proti tomu nemam namitek :) Ale
1/ Porad si nejsem nejak jisty k cemu swapovani vubec zavadet.
2/ Implementace:
Spis nez dalsi object manager bych to udelas soucasti aktualniho
object manageru (stejne jako je ted GC, tak by pribyl SC - Swap
Collector),
tzn. testovani zda je objekt lokalni by bylo
if( gc.is_local( id ) || sc.is_swapped( id ) ) ...
V tom problem neni.
Problem je pri archivaci, nebot pri zapocati archivace je nutno
oflagovat vsechny objekty ( "archive on write" ), coz by znamenalo
naswapovani vsech odswapovanych objektu, coz by uz rozhodne nebylo
"neviditelne pro uzivatele".
Moznosti:
1/ Swapovaci node - Bezici uplne v jinem procesu (jinem pocitaci), na nej
by se posilaly migracni grupy. Neumel by simulovat objekty, ale jen
migrovat
a ukladat do souboru.
Tohle bych rozhodne nedelal, protoze by se tim jen zeslozitela komunikace
mezi nody.
Ted me napada ze by to stejne neslo kvuli hafu dalsich veci :)
2/ Udelat swapovaci soubor primo archivacnim souborem. Tento archivacni
soubor by byl binarni (mozna by ani nemusel).
Pri zapocati archivace by se aktualni soubor asynchronne zkopiroval
do noveho souboru, ktery by reprezentoval aktualni save. Tim by byly
sejvnuty vsechny odswapovane objekty a tudiz by se nemusely vubec
flagovat.

Dalsi problem je - jak poznat ze grupa se ma odswapovat?
Idealne chceme pokud plati:
- s zadnym objektem ze skupiny po urcitou dobu nikdo nekomunikoval (a
ani vnitrni komunikace v ramci skupiny).
- zadny objekt ze skupiny nema na blizkou dobu naplanovanou zadnou udalost
(tzn. minimum z heap lokalnich schedule objektu ve skupine).
Napada nekoho jak todle delat? A vubec cely load balancing
by si nekdo mohl vzit jako pekny ukol na premysleni :)


>3) Filesys:
>
> jakym zpusobem udrzovat databazi o verzich souboru
>
>Moznosti jsou v zasade dve:
>a) co soubor, to soubor na disku + nejaka nami spravovana extra
> databaze tech verzi a specialnich atributu
>b) vsechno to cpat do jednoho "pak" souboru


Me se libi spise varianta a)
Spis bych to videt ala quake, tedy a) s tim, ze lze namapovat
i vice pak souboru...ale jinak je mi to jedno.


>Octa, Marekus:
>    net


Muze nekdo sepsat nejake to api (aspon textove) jak se teda presne
posilaji
a prijimaji pakety a jak se s nima presne pracuje (netbitiostreamams a
jejich metoda send() nebo lock() nebo jak? Net::get_packet()? .....?),
jak zazadat (koho) o sitovy paket na poslani, jak ziskat prijate pakety,
...


Jinak ted jeste zacinam trochu delat tu systemovou frontu zprav (kde se
hazeji pakety, eventy od klavesnice, atd.), kdyby snad nekoho samo od sebe
napadlo to delat taky (rad prenecham :-)
Cau,


Petr

Ahoj,
tady pisu, co se deje v "me" casti massivu:

1) ObjectManagement/GC:

Nejak tak bylo stanoveno (implementacni duvody GC), ze strong pointer =
nesmi ukazovat na vzdaleny objekt. Je vsak otazka, jestli to je spravne =
rozhodnuti. Pokud by se to tak nechalo, znamenalo by to, ze napr. =
migracni skupina musi byt urcena minimalne pomoci tech strong pointeru =
(tj. strong =3D> migruje). System totiz muze libovolnou migracni skupinu =
vzit a odmigrovat, tudiz pri migrovani musi vzit vsechny objekty =
dostupne pres strong pointery, aby neporusil tu podminku ohledne =
referencovani vzdalenych objektu.

Takze, aby to fungovalo, musi platit:
    strong: urcite urcuje migracni skupinu
    weak: muze urcovat migracni skupinu, nemusi

Jaka jsou tedy mozna reseni:
    - strong pointer muze ukazovat na vzdaleny objekt; v takovem =
pripade, se ale chova jako weak (to je asi blbost):
    - strong =3D> migruje:
        protoze strong implikuje migruje, tak strong je taky monitored
        bylo by to dostatecne efektivni?
    - nejakym zpusobem se to silene oprasi a strong pointer na vzdaleny =
objekt bude opravdu fungovat jako strong

2) Swapovani objektu:

Se Stepanem jsme dosli k zaveru, ze snazit se swapovat (transparentne) =
jednotlive objekty neni az tak efektivni. O kazdem odswapovanem objektu =
by se stejne muselo drzet v podstate minimalne to, co je ted v Object =
(aby fungovalo vsechno ostatni), tudiz by se tim asi nic neziskalo. Co =
mi ale pripada zajimavejsi je, ze by se na kazdem serveru krome =
zakladniho objectmanageru vytvoril nejaky dalsi specialni objectmanager, =
na ktery by se swapovaly cele migracni skupiny objektu. Potom swap =
objetku =3D odmigrovani objektu. Tohle ma zasadni vyhodu, ze se nikde =
nemusi drzet vazby na odswapovane objekty a cele to funguje automaticky =
(system muze migracni skupinu kdykoliv nekam presunout, tudiz i =
odswapovat a kod, ktery chce komunikovat s jinaci migracni skupinou ji =
smi stejne vzdycky jenom posilat zpravy - async).
Cele by se to dalo implementovat jako soucast load balancingu, ktery =
stejne (asi) budeme muset v nejake forme udelat.

To Boovie:
Byl bys ochoten tohle akceptovat? Ten swapovaci object manager (jen =
seznam odswapovanych objektu a sprava tech vyhledavacich cache) bys =
totiz musel programovat ty, rovnez tak upravit stavajici cache, aby byly =
schopny dohledat objekt ve svem lokalnim swapu, apod.

3) Filesys:

S ohledem na (2) jsem naprogramoval jakousi "hromadu" alokujici bloky z =
disku. Je to z toho duvodu, ze az se bude swapovat, je nemyslitelne, aby =
kazdy odswapovany objekt (kterych muze byt tisice) byl serializovan do =
vlastniho souboru. Proto jsem naprogramoval "Volume" umoznujici alokovat =
a uvolnovat retezce bloku z nejakeho "image" souboru.

Dale taky chceme mit v systemu nejakou podporu verzovani souboru =
(grafika, textury, modely, ...) a mozna i neco jako Quake-like pak.
Haf ma za ukol vymyslet, jak by vypadalo API pro praci s takovymi =
soubory. Veci, ktere zde zajimaji me jsou:
- jakym zpusobem udrzovat databazi o verzich souboru (a pomocne =
atributy, ktere na obycejny FS jednoduse neulozis)
- jak ukladat samotne soubory

Moznosti jsou v zasade dve:
a) co soubor, to soubor na disku + nejaka nami spravovana extra databaze =
tech verzi a specialnich atributu
b) vsechno to cpat do jednoho "pak" souboru

Zajimalo by me, ktera varianta se vam zda lepsi. U moznosti b) by se =
dalo vyjit ze stavajiciho "Volume", kam by se ale jeste navic musely =
naimplementovat "adresarove sluzby". Vzhledem k tomu, ze ale uz mame =
neco podobneho v registry, tak by to nemusel byt az tak velky problem. =
Zalezi na tom, jestli by byl Marekus ochoten nejak ty adresarove sluzby =
zobecnit, aby se daly pouzit jak v registry tak pro ten filesystem.

Na zaver pripomenu, co tak ma asi kdo za ukoly, na co si vzpominam:
Haf:
    threading & synchronization - projit si archivy na sf a opravit to =
podle pripominek
    idea verzovani
    string property
Octa, Marekus:
    net
Marekus:
    ? adresarove sluzby ?
Stepan:
    class factories
    serializace
    reorganizace zdrojaku, kterou si tak pral (exceptions, ...)
Boovie:
    migrace, archivace
    ? swap object manager ?
Markoid:
    objectmanagement improvements & tests
    filesys

-- Markoid

Je nejaky duvod pro stale nejsou hotove ty trivialni bugy na sf?

Petr

Cau,
sepsal jsem nejake veci ohledne komunikace klient x server,
at to neni porad jen v neci hlave, tak nejak zhruba by to
 snad mohlo byt...
Jiz to nevyzaduje takovou tu chytrou sitovou vrstvu, jak jsem
psal drive.
Jinak na cvs je jiz sepsano jak funguje aktualni migrace objektu.
Jakekoli pripominky vitany.

Petr

------------


Komunikace mezi Nody = posilani zprav = posilani objektu = migrace
objektu.
Servery se mysli tzv. trusted Nody, kter simuluji svet a delaji
konzistentni
zalohu sveta. Klienty se mysli vsechny ostatni Nody.

Migrace objektu mezi klienty a servery:
---------------------------------------

Klient nema prideleno vlastniho object providera, ma pouze virtualniho.
Generuje ObjectId s ProviderId rovno 0.

Pri migraci objektu z klienta na server se premapuji vsechny ObjectId
s ProviderId rovno 0, ostatni ObjectId zustanou nezmenena.
Tzn. klient muze mit normalne reference na objekty ve svete a tyto
reference posilat tam a zpet.

Pri migraci ze serveru na klienta se pouze informuje system, ze dane
objekty prestavaji byt soucasti simulacniho sveta (jako by byly zniceny).
Premapovani object id neni nutno (pripadne premapovani muze udelat az
klient).

Pridelovani NodeId klientum:
---------------------------

Asi nejjednodussi bude pridelovat NodeId natvrdo jako soucast uctu.
Tzn. klienti dostanou prideleno natvrdo 1x ObjectId objektu, pomoci
ktereho se pripojuji na svou postavicku, 1x NodeId.
Diky tomu budou tabulky o pravech NodeId staticky na serverech
a neni problem, kdyz se klient pripojuje na nejaky server
a jiz je pripojen na nejaky jiny (kdyby se pridelovaly NodeId dynamicky,
muselo byse kvuli bezpecnosti provadet broadcast na vsechny servery).
Nevyhoda - Nelze udelat obecny ucet typu "guest", na ktery by se mohli
pripojit vice klientu. Musi se udelat vice uctu typu guest1, guest2, ...
Pozn.: NodeId i ObjectId prislusejici uctu klient nezna dopredu,
ale dovi se ho pri prvnim vytvareni konexe. Jde jen o to, ze toto NodeId
a ObjectId bude staticky v nejakych tabulkach na vsech serverech.

Adresace migrace:
----------------

Cil migrace je urcovan ze skriptu jako ObjectId nejakeho objektu.
Pri migraci klient -> server neni problem.
Pri migraci server -> klient je nutno nejak adresovat klienty nejakymi
objekty, o kterych servery vedi, ale tyto objekty NEjsou soucasti
zalohovani simulace.

Klient pri prvnim pripojeni dostane prideleno nekolik techto specialnich
object id od serveru, na ktery se pripojil. Tyto object id jsou
oznaceny jako tracked.

Pri broadcast searchu na specialni object id odpovi kazdy server,
ktery ma spojeni na Node, ktery vlastni dane specialni object id.

Pri posilani objektu k object se specialnim id:
- Pokud informace neni v cache, posle se na providera nebo
  broadcast search.
- Pokud infomace v cache je, ale neni spojeni na dany Node
  a ani server nemuze spojeni vytvorit, posle se zprava na providera
  nebo se provede broadcast search.

Pro optimalizaci, pokud se klient odpojuje od serveru, muze mu poslat
informaci, kam ma smerovat dalsi zpravy pro jeho specialni object id.

Jak poznat, ze nejaky klient jiz neni pripojen do simulace?
Napriklad ze ucet guest24 jiz neni vyuzivan a muze se na nej pripojit
dalsi klient?

Filtry (migracnich) zprav:
-----------------------

- Test prav & typu zpravy - zda dany node ma pravo nam poslat zpravu
  daneho typu.
- Test ciloveho prijemce zpravy - zda node, ktery poslal zpravu ma pravo
  poslat danou zpravu cilovemu adresatovi.
- Test serializace - Test zda bit stream obsahuje validni data (pri
  unserializaci nedojde k vyjimce).
- Premapovani object id vsech objektu pri migracni zprave.
- Premapovani event handlu.
- Pri migraci na untrusted server zniceni objektu ze sveta.

Jak urcovat, kterym objektum muze klient posilat zpravy?
Defaultne muze posilat zpravy jen objektu, ktery je natvrdo spjat
s jeho uctem. Muze posilat zpravy i jinym objektum (napriklad primo
sve postavicce)? Podle ceho to testovat? Natvrdo nekolik objectid podobne
jako pridelovani NodeId?