Chalmers tekniska högskola EDA390 Datakommunikation och Distribuerade system 2005-04-29

Tidsfördröjningskompensation i distribuerade nätverksmiljöer Chalmers tekniska högskola EDA390 Datakommunikation och Distribuerade system 2005-04-29 Av: Oscar Andersson 820109-5638 Andreas Sjöstrand 800508-0117

Innehållsförteckning Tidsfördröjning i distribuerade nätverksmiljöer... 3 Inledning... 3 Bakgrund... 3 Effekter av fördröjningen... 3 Fördröjningskompensation... 5 Existerande exempel... 8 Slutsats... 10 Referenser... 11 2

Tidsfördröjning i distribuerade nätverksmiljöer. Inledning Vi har valt att skriva om Tidsfördröjningskompensation i distribuerade nätverksmiljöer då vi tyckte att detta var ett intressant ämne. Tidsfördröjning är ett problem som man stöter på i många sammanhang, inte minst i de populära onlinespelen. I onlinespel som ofta kräver snabba beslut är det viktigt att man får en korrekt bild av världen och omedelbart får respons på utförda handlingar. En viktig egenskap för de distribuerade spelen är att användarna ska uppfatta situationen som rättvis. Spelare som upplever en längre fördröjning än sina motspelare bör inte uppfatta detta som ofördelaktigt. Uppsatsen beskriver problemet med tidsfördröjning, vad som orsakar det, vilka nackdelar det medför och hur man tekniskt ska gå tillväga för att kunna minska och dölja problemen som tidsfördröjningen medför. Vi har även tagit med ett exempel som tar upp hur problemet har lösts i ett kommersiellt spel. Bakgrund Inom mjukvaruutvecklingen för en distribuerad miljö är fördröjningskompensation ett viktigt område. Fördröjningskompensation innebär att man vill minimera problemen som uppstår av den ofrånkomliga fördröjningen då klienter interagerar med varandra. Fördröjningen kommer av att det tar tid för klienter som befinner sig på geografiskt olika platser att tala med varandra. Dessa fördröjningar beror bland annat på fysiskt avstånd mellan datorer, mängden trafik på nätet och kvaliteten på uppkopplingen mot nätet. Längs med sträckan som ett datapaket färdas från en dator till en annan är det routrar som bidrar till den mesta fördröjningen. På grund av kö i buffrarna i dessa nätverksenheter blir tiden det tar för ett paket att nå sin slutdestination högre än vad som kunde förväntas om man enbart räknade med ljusets hastighet från en punkt till en annan. Fördröjningen ökas även av att gatewaynoderna inspekterar och redigerar pakethuvudena, t.ex. hopp-counten i time to live fältet ökas med ett för varje nod som paketet passerar. Andra källor till fördröjningar är att paket kan komma att förvaras under korta tider i switchar och bryggor under färden från sändare till mottagare. Är avståndet mellan sändare och mottagare stort medför detta inte hög fördröjning enbart på grund av att det fysiska avståndet är stort utan att paketet måste passera ett ökat antal routrar. Då data skickas vi sattelit bidrar länken till en stor del av fördröjningen på grund av det stora avståndet som paketen måste färdas. Bandbredden är alltså inte den enda faktorn som spelar in i nätverksfördröjningen. Bandbredden via en sattelit kan vara hög medan fördröjningen kan ligga på över 5 sekunder då avståndet mellan sändare och sattelit är stor. [4] Om man gör en noggrann undersökning hur lång tid det tar att skicka ett paket från sändare till användare mäter man den tid det tar från att första biten i datapaketet skickats till dess att sista biten i paketet mottas. Till följd av detta sätt att räkna blir det alltså en större fördröjning ju mer bitar paketet består av. Effekter av fördröjningen Ett exempel på en distribuerad miljö är onlinespel där en stor mängd användare har möjlighet att i realtid interagera med varandra. I ett onlinespel är det viktigt att varje spelare har en så 3

korrekt bild av världen som möjligt. Om systemet har en hög fördröjning och om det inte finns någon fördröjningskompensation medför detta en rad problem. Om en användare på grund av fördröjning har en gammal bild av ett spels tillstånd medför detta att användaren utför handlingar utifrån detta gamla tillstånd. Utförda handlingar skickas till en server eller direkt till medspelare med ytterligare fördröjning som följd. Feedback på utförda handlingar kommer först då servern skickar tillbaka information om spelets tillstånd. Feedbacken kan t.ex. vara en uppdaterad bild av vart man för närvarande befinner sig i ett spel. Har man tidigare utfört handlingar efter ett gammalt tillstånd kan denna feedback uppfattas som att spelet hackar och beter sig underligt. Om flera användare interagerar med varandra är det viktigt att alla har så lika uppfattning om spelets tillstånd som möjligt. Problemet försvåras av att de olika användarna kan uppleva olika långa fördröjningar. En annan aspekt är att spelet ska upplevas som rättvist. I spel som kräver snabba reflexer kan input från användare som har en lång fördröjning orsaka att detta uppfattas som om det var användaren som reagerade långsamt. Detta är ett vanligt och irriterande problem för européer som kopplar upp sig mot servrar på den amerikanska västkusten. Många upplever att det är ofördelaktigt att spela mot amerikanska spelare som bor mycket närmare servrarna och på så sätt upplever en kortare fördröjning. Problemet med fördröjning existerar inte enbart i distribuerade nätverksmiljöer. Som ett exempel kan man nämna den mänskliga hjärnan. Hjärnan kan kompensera för de fördröjningar som sker från att man med sina sinnen uppfattar sin omgivning till dess att kroppen svarar på signalerna i form att muskelrörelser. Fördröjningen här beror på hastigheten av nervimpulserna men också på att hjärnan lägger tid på att planera vilka impulser den ska skicka ut till kroppens muskler. För en människa behöver hjärnans medfödda kompensationsförmåga inte vara livsavgörande då människan har en förmåga att lära sig kompensera genom erfarenhet. För lägre stående djur däremot är hjärnans kompensationsförmåga en livsviktig egenskap. [3] För att man ska kunna interagera med ett program på ett så naturligt sätt som möjligt är det viktigt att programmet till så hög grad som möjligt inte orsakar ytterligare fördröjningar. För att hjärnan ska uppfatta ett spel som realistiskt är det alltså viktigt att spelets tillstånd är samma som det tillstånd man interagerar med och att input tillspelet påverkar spelet på ett sådant sätt som hade varit fallet i den riktiga världen. Målet med fördröjningskompensation är att minimera problemen som uppkommer på grund av fördröjningen. Man vill att system med hög fördröjning ska för användaren uppfattas som om det endast vore frågan om en kort fördröjning. Teknikerna som används för att lösa problemet har utvecklats i takt med att kraven på kompensation har ökat. 4

Fördröjningskompensationstekniker Internet är ett IP nätverk som används av många personer samtidigt. Eftersom IP enbart är ett best effort protokoll så erbjuder det ingen garanti hur lång tid det tar för ett datapaket att nå fram, det garanterar inte ens att ett datapaket kommer fram överhuvudtaget. Transportgarantin sker i transportlagret om TCP används och på applikationsnivån om UDP används. Ett problem man stöter på då man vill beräkna den tid det tar för ett datapaket att skickas från en dator till en annan är att datorerna i fråga ofta inte har synkroniserade klockor. Om dess klockor var synkroniserade skulle man kunna använda tidstämplar där mottagaren av datan kunde läsa av en tidstämpel och på så sätt avgöra hur lång tid transporten tog. Det finns metoder för att synkronisera klockor hos olika dator men dessa är endast approximativa. En av dessa metoder är att de två datorerna som interagerar med varandra synkroniserar sina klockor med hjälp av en GPS klocka Ett bra sätt att räkna ut hur lång tid det tar för ett datapaket att skickas är att använda sig av Round Trip Time (RTT). En RTT är den tid det tar för ett paket att skickas mellan sändare och mottagare. Detta ger en ungerfärlig bild av hur lång fördröjningen är mellan två noder men ger ingen garanti på att inte fördröjningen kommer ändras inom en snar framtid. Den ger heller ingen bild av hur lång tid det tar för ett paket att traversera en riktning utan beskriver enbart den totala tiden. Två problem man stöter på då man ska räkna ut fördröjningen är jitter och droppade paket. Jitter är oförutsedda täta förekomster av skiftningar i fördröjningen. Paketförlust är då ett paket droppas innan det når sin slutdestination. Paketdroppning beror på överfulla buffrar, buffrar som fylls på snabbare än de töms. Kommer ett paket till en router med fylld buffer måste routern droppa ett paket. För att minska problemen med droppad paket kan man anpassa trafiken av paket till den svagaste länken. Den svagaste länken som klarar av minst trafik är ofta de länkar som är närmast sammankopplade med klientdatorerna, t.ex. om en klient sitter med en modemuppkoppling. När man designar ett program som behöver skicka data över Internet är ett av designproblem att bestämma sig för vilken typ av uppkoppling som bör krävas av användaren. Högt ställda krav kan ge mer sofistikerade program med det kan orsaka att en stor del av målgruppen inte kan använda programmet då de sitter bakom långsamma uppkopplingar. Eftersom fördröjningen mellan två noder hela tiden förändras är det en fördel att mäta RTT för många paket och räkna ut ett medelvärde, ett högstavärde och ett minstavärde, detta brukar ofta kallas att ping:a en dator. Ju mer paket man mäter RTT på desto större chans är det att man får ett tillförlitligt medelvärde. Fördröjning påverkas av mängden trafik på nätet. Då trafiken längs en sträcka ökar riskerar buffrar i routrarna längs med vägen att bli överfulla och det får till följd att fördröjningen ökar. För att veta hur mycket mängden trafik påverkar fördröjningen får man mäta fördröjningen under olika nätverksbelastningar. För att till så hög grad som möjligt undvika fördröjningar på grund av för hög trafik bör programmen som skickar data över nätet optimeras så att de skickar så lite data som möjligt. Ett sätt man kan optimera koden är att mottagare och sändare har mycket gemensam kod över hur instruktioner ska uppfattas. Ett exempel på detta är att en server skickar iväg instruktioner om ett objekt. Klienten i sin tur tar emot instruktionerna och förstår hur objektet påverkas av instruktionerna och det får tillföljd att servern inte hela tiden behöver tala om en exakt position för objektet. 5

För att lösa de här tidsfördröjningsproblemen i distribuerade miljöer som t.ex. spel så har man utvecklat några olika metoder. Den mest använda metoden kallas för Dead reckoning, [1] bygger på att klienten försöker extrapolera fram nästa tillstånd i spelet. Detta är möjligt eftersom spelets olika tillstånd räknas fram genom givna ekvationer som ger exakta speltillstånd. Eftersom klienten är medveten om vilka ekvationer som servern kommer att använda för att räkna ut nästa tillstånd så kan klienten göra samma beräkning. Därmed kan klienten få ett närliggande värde av vad servern kommer att sända till klienten. Genom att sen visa det extrapolerade värdet för användaren så är det förhoppningsvis mer relevant när servens korrekta värde når fram till klienten. För att kunna beräkna fram vad nästa tillstånd ska bli så behöver klienten förutom ekvationen även känna till hur lång RTT det är mellan klienten och servern. För att mäta detta måste klienten t.ex. ping:a servern och bibehålla svaret för att kunna använda det vid nästa tillståndsberäkning. Om man exakt vet hur lång RTT man har och allt beter sig som förväntat så kommer klientens extrapolerade värde stämma exakt med serverns tillstånd. Därmed så kommer användaren att uppleva att världen påverkas omedelbart och exakt på de inmatningar man gör. I verkliga tillämpningar är inte extrapolation perfekt eftersom vi inte exakt vet hur lång RTT man har mellan klient och server utan enbart en uppskattning. Därutöver så har man ingen möjlighet att förutse oförutsedda händelser på servern eller hur andra klienter påverkar serverns beräkningar. Så när man visar användaren det extrapolerade tillståndet så måste man så fort som serverns korrekta värde anländer visa det istället. Detta kan leda till att man t.ex. upplever att ett objekt hoppar från en position till en annan. För att göra hoppet mer mjukt kan man uppdatera bilden i flera mindre steg där man successivt flyttar positionen från den extrapolerade punkten till den korrekta. Detta kan orsaka onödiga beräkningar för klienten samt att användaren får vänta längre innan korrekt information visas. Detta kan i vissa tillämpningar vara olämpligt då användare måste reagera och göra hastiga beslut. (Bild 1) visar ett exempel hur klienten skickar en position till servern och sedan väntar på svar. För att undvika att användaren ska uppleva att objektet hoppar från den gröna positionen till den röda så gör man mellanstegen med hjälp av extrapolation som renderas på skärmen. När väl serverns resultat anländer så gör man en interpolering mellan klientens senaste uppskattade värde (blå punkt) och servens korrekta (röda punkt) för att få en mjuk övergång. Dead reckoning, är en bra teknik för att lösa problemen med att en användare gör input baserade på en gammal bild av världen. Men problemet med att användaren Bild1 inte får direkt respons på sin input utan måste vänta en hel RTT innan man får se hur inputen påverkade världen finns kvar. För att lösa detta problem så kan man använda en metod som kallas för Short circuting. Metoden går ut på att man dels skickar inputen till serven precis som i dead reconing men att man även 6

tar med användarens input när man beräknar hur nästa tillstånd ska bli. Ett problem med detta är att om servens korrekta resultat skiljer sig mycket från klientens uppskattade värde t.ex. om användaren ser att han träffar en annan spelare med ett skott på klientversionen men enligt servern gör han inte det så kan det uppfattas som mycket störande av användaren. Istället för att använda sig av Dead reckoning, för att dölja nätverks fördröjningar så kan man använda sig av en teknik som går ut på att man fördröjer uppdateringen av bilden. Tekniken kallas ibland för presentation delay [1] och går ut på att man fördröjer visningen av en uppdatering en fast tid. Genom att använda sig av tekniken kan olika klienter med olika nätverksfördröjning få samma förutsättningar. De klienterna med låg fördröjning buffrar de uppdateringar man får tills tidsintervallet är över, sen presenterar man uppdateringarna. Klienter med hög nätverksfördröjning buffrar inte lika lång tid och om de ligger nära gränsvärdet så buffrar man inte alls utan visar uppdateringen direkt. Om vi har som exempel tre klienter med fördröjningar på 20 ms, 150 ms och 200 ms fördröjningar så innebär det att klient ett kommer att buffra sina uppdateringar från servern i 180ms innan de presenteras för användaren. Klient två buffrar uppdateringarna i 50ms medan klient tre visar dem direkt. På så sätt kommer alla klienter med en fördröjning under gränsen att få samma förutsättningar. En stor nackdel med tekniken är att användaren hela tiden agerar i en fördröjd värld samt att användarens input inte direkt ger en synbar påverkning av världen. Den här tekniken kan vara mycket användbar i konstgjorda miljöer som inte ändras för snabbt och användaren inte behöver reagera snabbt på små ändringar i världen. I flera av de tillämpningar där miljön ändras snabbt så kan man använda sig av ett tillvägagångssätt som går ut på att man för varje datapaket sätter en tidstämpel som man på serversidan kan läsa av. Därmed kan man få en uppfattning om hur lång tid som har gått sen klienten skickade paketet och man kan med hjälp av det räkna baklänges och se var i världen han var vid just den tidpunkten och vilken påverkan uppdateringen hade just då. Tekniken kallas för backward reconciliation och används för att göra beräkningar mer rättvisa i t.ex. first person shooter spel där små marginaler kan avgöra om man träffar en annan spelare eller inte. För att metoden ska fungera bra så måste serven spara alla händelser och positioner som hänt under t.ex. den senaste sekunden. (Bild 2) visar ett schema över hur en spelare skickar sin position och att han skjuter mot en annan spelare men eftersom paketet först kommer fram ½ RTT senare så gör serven en avläsning av tidstämpeln och med hjälp av att man regelbundet mäter RTT mellan serven och klienten kan man göra en uppskattning hur världen såg ut för klienten när han sköt. Serven gör då beräkningar på buffrade världen vid den tiden och räknar fram om spelaren träffade (krocktest) och vilken spelarens nya position är. Bild2 7

Existerande exempel De bästa exemplen där dessa tekniker används är inom spelbranschen där det är mycket viktigt att användaren har roligt och att alla spelar på lika villkor. Nästan alla kommersiella spel som spelas över lokala nätverk eller Internet och som har realtidsuppdateringar av världen måste ta hänsyns till tidsfördröjningen. Det går inte att bortse från detta faktum om man vill att spelet ska bli roligt, uppfylla spelarnas krav på bra spelkänsla och snabb respons på interaktion. De mest populära spelen online är idag first person shooter spel som oftast går ut på att skjuta på varandra i en gemensam värld. Det mest kända och spelade spelet inom denna kategori är idag Counter-Strike som är en modifikation av spelet HalfLife. Eftersom spelet är oerhört snabbt och baseras på spelarens skicklighet på att röra sig i världen och skjuta på andra spelare så är tidsfördröjningen i nätverket av högsta prioritet. Vilken teknik använder Counter-Strike sig av för att lösa detta tidsfördröjningsproblem? Faktum är att Counter-Strike inte använder sig av enbart en av dessa tekniker utan kombinerar dem för att få ett så bra resultat som möjligt. Spelet är uppbyggt kring ett server/klient förhållande där servern är ansvarig för att sköta alla hantering av all spellogik vilket t.ex. innebär krockdetektion med andra spelare och beräkning om ett skott träffar någon eller inte. Klienternas roll är egentligen enbart att avläsa och skicka iväg användarens interaktion samt rendera på skärmen de uppdateringar som servern skickar tillbaka. Följande schema visar hur kommunikationen mellan servern och klienten ser ut. 1. Klienten avläser användarens inmatning som t.ex. kan vara att man vill flytta sig framåt i världen. 2. Inmatningen skickas över nätet vilket tar ½ RTT. 3. Servern avläser vilka inmatningar som har gjorts och räknar sen fram spelarens nya position samt gör krockkollidering och respons med andra spelare. 4. Resultatet skickas till klienten ½ RTT. 5. Resultatet avläses och renderas uppdateringen på klientens skärm. Men eftersom komplexiteten för att se om ett objekt kolliderar med ett annat (punkt 3) växer enligt O(n 2 ), där n är antalet objekt, så vill man inte överbelasta servern utan genomför redan på klienten (punkt 1) egna kollisionstester med statiska objekt som väggar mm. För att veta t.ex. hur långt ett objekt ska flyttas så måste man mäta klientens framerate och skicka med den tiden i datapaketet som skickas till servern. Framrate representerar hur många gånger klienten renderar om sin bild som sedan presenteras på skärmen. Frametime är tiden det tar från att man börjar läsa av användarens inmatningar till att man har kollat om servern har skickat några uppdateringar och man har renderat dem. Det är viktigt att man tar hänsyn till frametime när man beräknar olika objekts positioner för annars kommer en spelare med en bättre dator flytta sig fortare i världen eftersom hans hårdvara uppdaterar bilden oftare och därmed skickar och tar emot uppdateringar i snabbare takt. Observera att klienten dock inte skickar data till servern varje frame utan i ett bestämt intervall som inte är beroende på hur hög framerate man har. I Counter-Strike skickar man som standard 20 uppdateringar per sekund till servern medan en bra dator kan ha 300-400 frames per second. Emellertid så kontrollerar klienten alltid inkommande paket varje frame och applicerar uppdateringarna innan man renderar om bilden. 8

De olika kompensationsteknikerna kommer dels in under punkt 1 och 5 på klient och under punkt 3 på servern. I samband med att klienten i punkt 1 avläser inmatningen och skickar resultatet till servern så utför klienten också en Dead reckoning, beräkning tillsammans med en Short circuting för att få fram en ganska bra uppskattning av vad servern kommer att skicka som svar. Klienten utgår då från det senaste korrekta värdet från servern och buffrar resultatet av beräkningarna samt renderar dessa på skärmen så att det för användaren ser ut som om spelet flyter på som vanligt. Man vill emellertid inte extrapolera allt för långt i förväg eftersom ju längre man extrapolera på klientsidan utan att få korrekta uppdateringar av servern desto större kan felet bli. I Counter-Strike samt i några andra online spel använder man sig av en övre gräns på 100ms framtida exrapolisering, när den gränsen är nådd kan man antingen höja gränsen om man har mycket paketdropp eller så väntar man på serverns värde utan att göra några nya uppdateringar. Under punkt 3 som utförs på serven så använder Counter-Strike backward reconciliation [2] för att beräkna vilken påverkan klientens uppdaterig hade och hur världen såg ut i ljust det ögonblicket. Resultatet av beräkningen skickas tillbaka till klienten som kommer i punkt 5 att utföra en interpolation mellan resultatet som klienten räknade fram och serverns exakta uppdatering. Med hjälp av alla de olika teknikerna lyckas Counter-Strike få användaren att tro att spelet spelas utan fördröjning och med 100 % feedback på användarens inmatningar. 9

Slutsats Fördröjning inom distribuerade nätverk beror på flera olika faktorer. En av dessa faktorer är hur snabbt ljuset färdas från en punkt till en annan. Ljuset färdas med en hastighet av 300 tusen kilometer i sekunden vilket motsvarar ungefär sju varv runt jorden på en sekund. Ljusets hastighet är en universell konstant och med andra ord en faktor som inte går att förbättra. Det går alltså aldrig att helt undgå fördröjningar utan man måste lösa problemen på andra sätt. Andra faktorer som påverkar prestandan är de noder genom vilka datorpaket måste färdas igenom för att nå sina slutdestinationer. Dessa noder håller paketen under korta tider men kan även droppa paket om deras köer skulle vara fulla. Om TCP protokollet används och ett paket droppas måste paketet i fråga skickas en gång till med fördröjning som följd. Fördröjningen kan förbättras av att sändare och mottagare fysiskt placeras närmare varandra, genom att minska mängden data som skickas mellan datorerna och genom tekniskt bättre utrustning längs den väg som paketen färdas. För att bli av med problemen som fördröjningen medför kan man föröka minska fördröjningen eller använda sig av så kallad fördröjningskompensation. Några av fördröjningskompensationsteknikerna som finns att tillgå är dead reconing, short circuting, backward reconciliation och presentation delay. Dessa tekniker är till för att användaren ska uppleva att han interagerar med en korrekt bild av världen, att användaren direkt ska känna att han får feedback på utförda inputs och att användaren ska uppleva situationen som rättvis. De ovan nämnda teknikerna har alla fördelar och nackdelar, det handlar i slutändan om att göra en avvägning med hur mycket teknikerna ska få påverka programmen. 10

Referenser [1] Robert F. Bushheit, Januari 2004 Delay compensation in networked computer games. http://vorlon.cwru.edu/~vxl11/netbots/rfb_report.pdf [2] Yahn W. Bernier Latency Compensating Methods in Client/Server Ingame Protocol Design and Optimization http://www.cs.bris.ac.uk/home/dg1767/doc/bernier.pdf [3] Romi Nijhawan. "Neural delays, visual motion and the flash-lag effect", TRENDS in Cognitive Sciences, Vol. 6, No. 9, September 2002. [4] MSDN, Mars 2005 Network Latency and Throughput http://msdn.microsoft.com/library/default.asp?url=/library/enus/rpc/rpc/network_latency_and_throughput.asp 11