World server / Synchronization

[Anders Reggestad <andersr@pvv.ntnu.no>]

Den største utfordring vi har i systemet vårt er synkronisering av data.
Servern, world serverne og clientene skal ha samme fysiske verden / eller
deler av samme fysiske verden representert som datastrukturer. Disse
datastrukturene må være synkronisert både på innhold og status. Tror ikke
vi har noe krav om at de må være synkronisert til enhver tid, men over tid
må de være synkronisert. Når vi på serveren legger til et nytt objekt må
dette skje i alle delene av systemet. Når et objekt fjærnes likeså. Hadde
alt vært statisk ville det vært nok å bare sende meldinger om at dette har
inntruffet utover i systemet, men i vårt dynamiske system tror jeg vi må 
ha noe synkronisering. 

Spørsmålet er i hvilken form og hvor mye. I det ekstreme ser jeg for meg
at vi lager en transaksjonskø. Eksempler på transaksjoner : Legge til
objekt, Oppdater posisjon, Start animasjon. (Legg merke til at oppdater
posisjon er en animasjon som tar 0 tid.) Disse transaksjonene blir så
distribuert til alle ledd i systemet. På en synkronisert tidspuls så
utføres alle transaksjoner som ligger i kø. Siden det tar tid å
distribuere disse transaksjonene så kan en legge til et tidsfelt som
forteller ved hvilken fremtidig tidspuls denne transaksjonen skal utføres.
Hvis vi vet at det tar 5 pulser å distribuere en transaksjon til alle
deler av systemet så må en transaksjon når den genereres settes til å
utføres (neste tidspuls+5).  

Hva skjer da om en transaksjon ikke kommer frem i tide! Da må vi hacke
litt. Statiske opperasjoner må vi kunne anta av vi kan utføre og late som
om vi ikke merket at det kom for sent. Dynamiske opperasjoner som
animasjoner må behandles litt anderledes. Der må det gjøres et forsøk på å
simulere hva som skulle ha vært gjort. Slik at en kan oppdatere mottakeren
til den statusen som høyst sansynlig er tilstede i andre servere. Kan da
også sende et request for å få en status på objektet. Slik at eventuelle
feil kan korrigeres. Hvis dette inntreffer ofte så må
distrubusjonstidskonstanten økes likeså hvis det alltid er god margin kan
den senkes. (Litt regulerings teknikk her :) )

Det springende punket i denne løsningen er om vi klarer å synkronisere
tidspulsene og om vi klarer å fikse transaksjoner som kommer for seint.

Kan vi bruke systemklokka til å synkronisere tidspulsene på? Dette går
helt klart hvis alt går på en host og høyst sannsynlig på hoster som er
synkronisert ved hjelp at xntpd eller liggnende systemer. Men hva hvis
dette ikke er tilfelle. Da må vi legge inn noe synkroniserings meldinger.
Anta at ei melding bruker like lang tid til en host som fra en host.
(Håper dette ikke er en for urimlig antagelse, hvis det er det så er det
bare å kjøre følgende prosedyre fra begge hostene og regne litt mer på
resultatet) Host A lagrer tiden t1 og sender ei pakke til B. B lagrer sin
tid t2 og sender med en gang ei pakke tilbake til A. A lager tiden t3. Da
har en en tid t3-t1 på hvor lang roundtrip tid en har. Under forutsetning
så vil da t3 + k*n og t2 + (t3-t1)/2 + k*n være synkronisert. Der k er en
konstant tidsperiode og n er en teller. Roundtrip tid burde være mulig å
få ut av tcpip stacken, men jeg vet ikke hvordan.

Det åpne spørsmålet er om vi må gjøre det så grundig?

Dessuten så tror jeg det er utenklig å synkronisere world serverne og alle
clienten. Så en generell løsning for klienten kan være å prøve å synke
disse X antall tidspulser etter worldserverene. Dette skaper et konstant
etterslep i systemet men jeg tror det er det beste vi får til!

Anders

 ----------------------------------------------------------------------
|    ******   Anders Reggestad                                         |
|  *   *   *  Mobil tlf.   : 95044443                                  |
| *    *   *  E-Mail       : andersr@pvv.ntnu.no                       |
| *********   Post adresse : Haug Prestegård 3300 Hokksund             |
| *    *   *  Jobb adresse : FFI avdeling for Undervannsforsvar Horten |
| *    *    * Hjemmeside   : http://www.pvv.ntnu.no/~andersr           |
 ----------------------------------------------------------------------