massiv-crap Mailing List for Massively multiplayer game middleware

From: "Stepan Vondrak"
> > Todle myslim neni potreba. Kdyz je vynucena replikace sektoru,
> > tak sektor ma strongy na entity, tudiz by jeho replikace
> > vynutila replikaci vsech entity, tudiz i tech, ktere nebyly
> > replikovany explicitne. I kdyz vcera me napadlo proc to
> > nefunguje, ale ted si na to nemuzu vzpomenout, takze
> > by to asi fungovalo (?).
>
> Veta zacinala "kdyz by tam ten pointer nebyl". A ClientSector _nema_
strong
> pointers na ClientEntity v nem, nejake pointery mezi Sector a Entity
> replikace ClientSector a ClientEntity neovlivni, protoze pointery
> Sector-ClientSector a Entity-ClientEntity nejsou replikacni.


Jasne.
No proste bych na to kaslal - to, ze explicitni replikace entity vynuti
replikaci clientsectoru myslim nejak prezijem (ja teda jo).

Petr

Ahoj,
vite nekdo, jestli je potreba udelat znova zpravu pro
komisi jako loni? Podle pravidel to vypada, ze spis ne
("Standardni doba pro vypracovani Projektu je jeden rok.
Pokud neni projekt po teto dobe prihlasen k obhajobe,
je resitelsky kolektiv povinen vypracovat prubeznou
zpravu o stavu praci na projektu.")

Marekus

PT> Caues,
PT> Procistil jsem demo/config, ale neni me treba
PT> jasne, proc je predefinovana hodnota
PT> Network::blowfish_key_length, ve zdrojacich
PT> je default 10, v settings 16. Bude to fungovat
PT> kdyz se to smazne?


Proc by nefungovalo?
Asi tam nekdo neco zkousel a commitnul 16 ( nejspis ja ).
Muzes klidne dat tech 10 i do settings.
Octa

Ahoj
commitnul jsem trosku pozmenenou verzi net.
resit by to 100% melo tohle:
1) vicenasobne ohlasovani node manageru o zmenach na connections.
2) nenastane, ze by se zavolal callback jindy nez z next_tick().
Vyzkousejte prosim. Melo by to podle mne resit i ohlasovani connection
closed misto connection lost.
Co to neresi ( zatim nevim, jak to ciste udelat, nechce se mi do
klienta - client_main.cpp includovat global )
oznameni SERVICE nodu, ze se klient ciste odpojil pomoci QUIT z
prihlasovaci obrazovky.
Octa

On Tuesday 23 of December 2003 20:40, Petr Tovarys wrote:
> From: "Stepan Vondrak"
>
> > On Tuesday 23 of December 2003 01:14, Marek Vondrak wrote:
> > > Priznavam, ze nevim o co tu jde. Kazdopadne entity musi byt nalinkovany
>
> na
>
> > > sektor pres strong ptr (je jedno jakym smerem) ze dvou duvodu. Sektor a
> > > entity v nem musi byt migracni skupina a entity nejsou gc roots.
> >
> > Tady jde o to, ze je strong pointer z ClientEntity na ClientSector. Takze
>
> kdyz
>
> > se replikuje entita a prejde do jineho sektoru, zacne se z nej najednou
>
> take
>
> > vsechno replikovat, i kdyz tomu pred tim tak nebylo. Kdyz by tam ten
>
> strong
>
> > pointer nebyl, muselo by se:
> > - Explicitne replikovat jak sektory tak entity v nem.
>
> To uz se deje ted.
>
> > - Kazdy sektor si pamatovat, kam se replikuje (to by mohla poskytovat
>
> nejaka
>
> > metoda v ReplicaServer, tam se to vi).
> > - Pri linknuti nove entity do sektoru explicitne pridat jeji
> > client_entite takto pamatovane replikacni requesty.
>
> Todle myslim neni potreba. Kdyz je vynucena replikace sektoru,
> tak sektor ma strongy na entity, tudiz by jeho replikace
> vynutila replikaci vsech entity, tudiz i tech, ktere nebyly
> replikovany explicitne. I kdyz vcera me napadlo proc to
> nefunguje, ale ted si na to nemuzu vzpomenout, takze
> by to asi fungovalo (?).

Veta zacinala "kdyz by tam ten pointer nebyl". A ClientSector _nema_ strong 
pointers na ClientEntity v nem, nejake pointery mezi Sector a Entity 
replikace ClientSector a ClientEntity neovlivni, protoze pointery 
Sector-ClientSector a Entity-ClientEntity nejsou replikacni.

-- Stoupik

From: "Stepan Vondrak"


> On Tuesday 23 of December 2003 01:14, Marek Vondrak wrote:
>
> > Priznavam, ze nevim o co tu jde. Kazdopadne entity musi byt nalinkovany
na
> > sektor pres strong ptr (je jedno jakym smerem) ze dvou duvodu. Sektor a
> > entity v nem musi byt migracni skupina a entity nejsou gc roots.
>
> Tady jde o to, ze je strong pointer z ClientEntity na ClientSector. Takze
kdyz
> se replikuje entita a prejde do jineho sektoru, zacne se z nej najednou
take
> vsechno replikovat, i kdyz tomu pred tim tak nebylo. Kdyz by tam ten
strong
> pointer nebyl, muselo by se:
> - Explicitne replikovat jak sektory tak entity v nem.


To uz se deje ted.


> - Kazdy sektor si pamatovat, kam se replikuje (to by mohla poskytovat
nejaka
> metoda v ReplicaServer, tam se to vi).
> - Pri linknuti nove entity do sektoru explicitne pridat jeji client_entite
> takto pamatovane replikacni requesty.


Todle myslim neni potreba. Kdyz je vynucena replikace sektoru,
tak sektor ma strongy na entity, tudiz by jeho replikace
vynutila replikaci vsech entity, tudiz i tech, ktere nebyly
replikovany explicitne. I kdyz vcera me napadlo proc to
nefunguje, ale ted si na to nemuzu vzpomenout, takze
by to asi fungovalo (?).

Petr

From: "Ondrej Pecta"


>
> MV>    >Eee, chapu to spravne, ze pri SystemMessage::send() network zavola
> MV>    >callback do node manageru? Jestli jo, tak je zas neco divne v
networku,
> MV>    >protoze jsem se kdysi pri designu callbacku dohodli (a je to i v
dokumentaci
> MV>    >v node manageru), ze se ty callbacky smi volat jen z
Network::next_tick()
> MV>    >prave kvuli takovymdle vecem.
>
> Nic proti chlapi, ale ty 4 callbacky, ktere vola network, tak se
> vzdycky volaji z next_tick()
> jedna se o connection lost / closed + created
> dale o async connection failed.


Problem byl v sendovani message v node mgr, melo by byt fixnuto jak je
zmineno
v jinem mailu.


> Jediny problem, jak Markoid zminuje, je s tim disconnect, ktery je ted
> blbe ( staci si v Global::system_shutdown() zakomentovat to
> close_all_connections( true ). Ale to porad podle mne neni to, o cem
> je tenhle thread.
> Vyresi to vase problemy, ale zase se musi jinak vyresit odpojeni
> klienta z logovaci obrazovky ( kdyz se tam da quit, tak service, ke
> kteremu je pripojen, neni notifikovan o jeho odpojeni a konexi na
> anonymous klienta zavre s connection lost ). Resenim je pri stisku
> QUIT v logovaci obrazovce zavolat close_all_connection( true );


Jukni na
node_manager_client.cpp:NodeManager::Client::disconnect(),
a pripadne ji uprav (asi jen nahradit tim close_all_connection()?).


Petr

On Tuesday 23 of December 2003 01:14, Marek Vondrak wrote:

> Priznavam, ze nevim o co tu jde. Kazdopadne entity musi byt nalinkovany na
> sektor pres strong ptr (je jedno jakym smerem) ze dvou duvodu. Sektor a
> entity v nem musi byt migracni skupina a entity nejsou gc roots.

Tady jde o to, ze je strong pointer z ClientEntity na ClientSector. Takze kdyz 
se replikuje entita a prejde do jineho sektoru, zacne se z nej najednou take 
vsechno replikovat, i kdyz tomu pred tim tak nebylo. Kdyz by tam ten strong 
pointer nebyl, muselo by se:
- Explicitne replikovat jak sektory tak entity v nem.
- Kazdy sektor si pamatovat, kam se replikuje (to by mohla poskytovat nejaka 
metoda v ReplicaServer, tam se to vi).
- Pri linknuti nove entity do sektoru explicitne pridat jeji client_entite 
takto pamatovane replikacni requesty.

-- Stoupik

On Tuesday 23 of December 2003 01:23, Marek Vondrak wrote:

>    >Eee, chapu to spravne, ze pri SystemMessage::send() network zavola
>    >callback do node manageru? Jestli jo, tak je zas neco divne v networku,
>    >protoze jsem se kdysi pri designu callbacku dohodli (a je to i v
>    > dokumentaci v node manageru), ze se ty callbacky smi volat jen z
>    > Network::next_tick() prave kvuli takovymdle vecem.
>
> Myslim, ze to tak bohuzel je. Prave tohohle jsem se taky obaval, ale

Taky se pridam. Asi to tak je a ty hope( stats.get() ) bugy v replication byly 
zpusobeny prave tim - tj. pri posilani replikacniho update se zavolalo 
node_disconnected(), node_info se zrusilo a pak se podelala ta iterace v 
ReplicaServer::next_tick(). Jinak si to vysvetlit nedovedu (sam jsem to nikdy 
nevidel, mam jenom all.log od Markoida). V replikacich jsem to nejak 
"opravil" - node_disconnected() nemaze primo node_info, jenom z nej zrusi 
requesty, verze a backlog, takze se nekdy casem smaze pri update, proto 
is_empty(). Pekne prasecina imo...

-- Stoupik

   >Co se tyce toho problemu se send(), k tomu se asi bude muset =
vyjadrit Haf (i kdyz uz jasne rekl, ze mu to pri send leze do toho =
callbacku). Kazdopadne lze overit treba tak, ze se tam da breakpoint a =
pak se posle do develu vypis zasobniku.

Jeste jedna poznamka (pisu po pameti, kdyz jsem to pred tydnem ladil):
Kdyz si v puvodnich zdrojacich dm inkrementu ten iterator _pred_ send a =
pouziju ty "spatne" configy a source data, tak se to nepolozi, pokud kod =
necham byt jak byl, tak se polozi 100 % (puvodni verze). Tedy se ten =
callback musi volat, protoze jinak by nemohlo dojit k zneplatneni =
iteratoru (smazani prvku, na ktery ukazuje, v dusledku vyvolani =
callbacku).

-- Markoid

   >Jediny problem, jak Markoid zminuje, je s tim disconnect, ktery je =
ted
   >blbe ( staci si v Global::system_shutdown() zakomentovat to
   >close_all_connections( true ).

To je jeden z problemu (3):

1) connection lost/closed je signalizovano nekolikrat pro stejnou =
connection
2) reinicializace network hazi vyjimky tykajici se stavu pred =
inicializaci (napr. opet connection/lost)
3) gcallbacks:system_shutdown volano i pri quitu utilit
4) signalizace connection closed misto connection lost
5) neefektivni pocitani crc
[ invalid checksum errors zda se uz zmizely ]

Co se tyce toho problemu se send(), k tomu se asi bude muset vyjadrit =
Haf (i kdyz uz jasne rekl, ze mu to pri send leze do toho callbacku). =
Kazdopadne lze overit treba tak, ze se tam da breakpoint a pak se posle =
do develu vypis zasobniku.

-- Markoid

MV>    >Eee, chapu to spravne, ze pri SystemMessage::send() network zavola
MV>    >callback do node manageru? Jestli jo, tak je zas neco divne v networku,
MV>    >protoze jsem se kdysi pri designu callbacku dohodli (a je to i v dokumentaci
MV>    >v node manageru), ze se ty callbacky smi volat jen z Network::next_tick()
MV>    >prave kvuli takovymdle vecem.

MV> Myslim, ze to tak bohuzel je. Prave tohohle jsem se taky
MV> obaval, ale nechtelo se mi to psat do develu. Co je v dokumentaci
MV> network, je uplne fuk, protoze podle mych poslednich zkusenosti,
MV> je implementace casto uplne jinak a to bud z duvodu, ze
MV> dokumentaci psal nekdo jiny, dokumentace byla napsana hned blbe,
MV> nebo ze ji pri provadeni zmen v kodu nikdo _neupdatoval_ (je treba
MV> provadet hned, pri jakekoliv zmene).
MV> Co si vynucuje jiny subsystem, network vubec nebere na
MV> zretel, jak vidime napr. pri system:connect/disconnect vs
MV> zpracovani callbacku.

Nic proti chlapi, ale ty 4 callbacky, ktere vola network, tak se
vzdycky volaji z next_tick()
jedna se o connection lost / closed + created
dale o async connection failed.
Jediny problem, jak Markoid zminuje, je s tim disconnect, ktery je ted
blbe ( staci si v Global::system_shutdown() zakomentovat to
close_all_connections( true ). Ale to porad podle mne neni to, o cem
je tenhle thread.
Vyresi to vase problemy, ale zase se musi jinak vyresit odpojeni
klienta z logovaci obrazovky ( kdyz se tam da quit, tak service, ke
kteremu je pripojen, neni notifikovan o jeho odpojeni a konexi na
anonymous klienta zavre s connection lost ). Resenim je pri stisku
QUIT v logovaci obrazovce zavolat close_all_connection( true );
Octa

   >Eee, chapu to spravne, ze pri SystemMessage::send() network zavola
   >callback do node manageru? Jestli jo, tak je zas neco divne v =
networku,
   >protoze jsem se kdysi pri designu callbacku dohodli (a je to i v =
dokumentaci
   >v node manageru), ze se ty callbacky smi volat jen z =
Network::next_tick()
   >prave kvuli takovymdle vecem.

Myslim, ze to tak bohuzel je. Prave tohohle jsem se taky obaval, ale =
nechtelo se mi to psat do develu. Co je v dokumentaci network, je uplne =
fuk, protoze podle mych poslednich zkusenosti, je implementace casto =
uplne jinak a to bud z duvodu, ze dokumentaci psal nekdo jiny, =
dokumentace byla napsana hned blbe, nebo ze ji pri provadeni zmen v kodu =
nikdo _neupdatoval_ (je treba provadet hned, pri jakekoliv zmene).
Co si vynucuje jiny subsystem, network vubec nebere na zretel, jak =
vidime napr. pri system:connect/disconnect vs zpracovani callbacku.

-- Markoid

From: "Martin Havlista"


> >    >Problem je vyresen. Bylo to tim, ze v tom cyklu (iteracnim)
> >    >service odmitla klienta kvuli spatnemu blowfish klici,
> >    >a zavolalo se callbackem remove_request( client_node_id )
> >    >v datamanageru, kde se mazal iterator, pres ktery se zaroven
iterovalo.
> >
> > Super. Ze zacatku jsem si myslel, ze by to mohlo byt tohle, ale pak co
jsem to ladil, jsem se do toho nejak zamotal a nemohl jsem najit misto, kde
by se v tom cyklu lezlo do remove request.
> > Je to tak, ze se tam leze pres globalni callback z nodemgr, kdyz selze
send?
> >
>
> Jo, presne tak.


Eee, chapu to spravne, ze pri SystemMessage::send() network zavola
callback do node manageru? Jestli jo, tak je zas neco divne v networku,
protoze jsem se kdysi pri designu callbacku dohodli (a je to i v dokumentaci
v node manageru), ze se ty callbacky smi volat jen z Network::next_tick()
prave kvuli takovymdle vecem.
Ale nezda se mi to, protoze zpravy se prece buferuji a odesilaji
v next_tick(), takze je to nejak jinak ten cyklus pres callback
o kterem se tu hovori?

Petr

>    >Problem je vyresen. Bylo to tim, ze v tom cyklu (iteracnim)
>    >service odmitla klienta kvuli spatnemu blowfish klici,
>    >a zavolalo se callbackem remove_request( client_node_id )
>    >v datamanageru, kde se mazal iterator, pres ktery se zaroven iterovalo.
>
> Super. Ze zacatku jsem si myslel, ze by to mohlo byt tohle, ale pak co jsem to ladil, jsem se do toho nejak zamotal a nemohl jsem najit misto, kde by se v tom cyklu lezlo do remove request.
> Je to tak, ze se tam leze pres globalni callback z nodemgr, kdyz selze send?
>

Jo, presne tak.

MH

   >Problem je vyresen. Bylo to tim, ze v tom cyklu (iteracnim)
   >service odmitla klienta kvuli spatnemu blowfish klici,
   >a zavolalo se callbackem remove_request( client_node_id )
   >v datamanageru, kde se mazal iterator, pres ktery se zaroven =
iterovalo.

Super. Ze zacatku jsem si myslel, ze by to mohlo byt tohle, ale pak co =
jsem to ladil, jsem se do toho nejak zamotal a nemohl jsem najit misto, =
kde by se v tom cyklu lezlo do remove request.
Je to tak, ze se tam leze pres globalni callback z nodemgr, kdyz selze =
send?

-- Markoid

SV> On Sunday 21 of December 2003 01:58, Marek Vondrak wrote:
>>   Me to jede.
>>
>>  >Hmm, nevim, esli je to neduh MSVC7.1 nebo vsech msvc, ale obcas je
>>  >
>>    >potreba i po zmene jednoho cpp prekompilovat cely program, protoze to
>>    >nejak blbe slinkuje...
>>    >cely server jsem rebuildnul a najednou to jede..
>>
>> Inkrementalni linkovani?
>> Edit and continue? (/ZI misto /zi?)

SV> Spis tim, ze jsi si menil datum zpatky a nektere obj tam zustaly s tim
SV> novejsim datem. Kdyz se pak zmeni odpovidajici zdrojak, samozrejme ze se to
SV> neprelozi a mas tam divnou starsi verzi. Kdyz se to pak nahodou slinkuje bez
SV> chyb, CPP pak nematchuje s H a nemuzes se divit, ze se to zacne chovat uplne
SV> divne.

Uz se mi to stalo vicekrat. Pote, co jsem zmenil ty datumy jsem cely
bin smazal, tim to nebylo, fakt se to MSVC 7.1 chova divne. ( zjistil
jsem, ze zasah do socket.cpp znamena prekompilovat cely massiv, pac on
to nejak blbe slinkuje )
Octa

> Takze vazeni, byl bych skutecne rad, kdbyste si to odladili. Tohle je to chyba, o ktere psal haf. Tedy:
> datamanager.cpp 1622:
> &ui = 0xdddddddd
>
> Nemuze se stat, ze kdyz tam behas v tom cyklu, tak si smazes prvek, kam si ukazujes tim iteratorem a tudiz se podela ++it?
>   Porad se spatnymi konfigy...
>   Tentokrat se polozila service (unhandled massiv exception).
>     zkousim si tady hrat s gencfg a zrejme jsem si blbe vytvoril konfigy (bylo by dobre, kdyby to umelo generovat i config_nodes_public). Spustim server s blbymi configy a ziskam nasledujici log.
>     Nejzajimavejsi je tohle:
>     Sending 'DataVersionRequest' to [ Server 0 ].

Problem je vyresen. Bylo to tim, ze v tom cyklu (iteracnim)
service odmitla klienta kvuli spatnemu blowfish klici,
a zavolalo se callbackem remove_request( client_node_id )
v datamanageru, kde se mazal iterator, pres ktery se zaroven iterovalo.

Kazdopadne patri dik Markoidovi za skvely bug report.
Jen tak dal :)

Haf

   >Vlastne to moc nefunguje vubec, sorry.
   >Rezervace zustavaji porad.

Bude-li zajem, muzu poslat opravenou verzi do develu (na cvs nemam =
pristup). Ale asi neni nutne.

-- Markoid

On Sunday 21 of December 2003 20:22, Petr Tovarys wrote:
> Caues,
> Optimized nejde zkompilit, presne balancer.cpp,
> asi je nekde blbe #ifdef ENABLE_INLINE, ze stupid
> vypisu msvc nepoznam v cem je problem (nezna
> ObjectId).

Patrne nektery *inline.h dela s typy, ktere se includuji jenom v odpovidajicim 
*cpp. Reseni:
1. Pridat #include do *inline.h.
2. Presunout to do *cpp.

Pokud je #include netrivialni, doporucuje se 2.

-- Stoupik

On Sunday 21 of December 2003 01:58, Marek Vondrak wrote:
>   Me to jede.
>
>  >Hmm, nevim, esli je to neduh MSVC7.1 nebo vsech msvc, ale obcas je
>  >
>    >potreba i po zmene jednoho cpp prekompilovat cely program, protoze to
>    >nejak blbe slinkuje...
>    >cely server jsem rebuildnul a najednou to jede..
>
> Inkrementalni linkovani?
> Edit and continue? (/ZI misto /zi?)

Spis tim, ze jsi si menil datum zpatky a nektere obj tam zustaly s tim 
novejsim datem. Kdyz se pak zmeni odpovidajici zdrojak, samozrejme ze se to 
neprelozi a mas tam divnou starsi verzi. Kdyz se to pak nahodou slinkuje bez 
chyb, CPP pak nematchuje s H a nemuzes se divit, ze se to zacne chovat uplne 
divne.

-- Stoupik

   >Je tam ale drobny problem, ze pokud se tohle zavola, kdyz entita =
zrovna prechazi mezi sektory, tak to selze.

Vlastne to moc nefunguje vubec, sorry.
Rezervace zustavaji porad.

-- Markoid

   >Pouzij Entity:remove_from_layer.

Je tam ale drobny problem, ze pokud se tohle zavola, kdyz entita zrovna =
prechazi mezi sektory, tak to selze.
Oprava je jednoducha:
V removefromlayer si zapamatovat, ze se entita uz nema nikam linkovat a =
v delivered_to tohle testovat.
Opravim.

-- Markoid

   >Kdyz smazu entitu pomoci /eraseobject,
   >tak zustanou po ni stale rezervovane tiles.

Pochopitelne nemuzes objekt smazat jen tak, protoze po nem zustane =
spousta dalsich veci, jako bordel v datovych strukturach, apod.
Pouzij Entity:remove_from_layer.
Je problem podivat se do entity.idl?

-- Markoid

From: "Petr Tovarys"


> Caues,
> Procistil jsem demo/config, ale neni me treba


Teda jenom one_server_one_client :/

Petr