EXAMENSARBETE. Matchresultat i realtid. En komparativ studie av realtidsteknologier för webbläsarapplikationer. Jimmy Fjellström 2013

EXAMENSARBETE Matchresultat i realtid En komparativ studie av realtidsteknologier för webbläsarapplikationer 2013 Filosofie kandidatexamen Systemvetenskap Luleå tekniska universitet

FÖRORD Denna studie är ett examensarbete om 15 högskolepoäng och den avslutande delen i en systemvetenskaplig kandidatexamen vid Luleå Tekniska Universitet och Institutionen för system- och rymdteknik. Jag vill framföra ett varmt tack till min familj som stöttat mig på vägen mot min examen och till Lina som fått mig att nå ända fram. I

SAMMANFATTNING Realtidskommunikation mellan server och klient är något som används inom många olika områden; allt från att spela online-spel till att följa börsmarknaden. Den gemensamma nämnaren för denna typ av kommunikation är att något kommuniceras mellan två eller fler parter där det är önskvärt att ha minsta möjliga fördröjning vid leveransen av skickade meddelanden. Detta för att skapa en följsam användarupplevelse som upplevs ske i verklig tid. I denna komparativa studie behandlas realtidskommunikation genom utveckling av en webbläsarapplikation för matchresultat i realtid där skickat data analyseras med fokus på vilken betydelse faktorerna trafikmängd, responstid, skalbarhet, bandbredd och kompatibilitet har. De realtidsteknologier som använts för att möjliggöra kommunikationen mellan server och klient i denna studie har, på anmodan av uppdragsgivaren, baserats på ramverket Socket.IO som möjliggör denna sorts kommunikation genom teknologierna WebSockets, HTMLfile, XHR Polling och JSONP Polling. WebSockets, vilket är den nyaste teknologin, uppvisade resultat som var klart bättre än övriga realtidsteknologier gällande alla nämnda faktorer utom kompatibilitet där dess jämförelsevis nya uppkomst begränsar teknologin till enbart de nyaste, mest uppdaterade webbläsarna. HTMLfile visade sig vara närmsta konkurrent till WebSockets gällande trafikmängd och responstid, men dess brist på generell kompatibilitet kan komma att vara väldigt avgörande för implementationer av denna teknologi då denna typ av förbindelse bara kan åstadkommas i webbläsaren Internet Explorer. Den mest generella implementationen möjliggjordes genom XHR- och JSONP Polling, vilka har stöd i både de gamla och nya versionerna av de vanligaste webbläsarna. Dessa realtidsteknologier uppvisade dock avsevärt mycket större trafikmängd och längre responstider och därigenom även högre belastning på servern och lägre skalbarhet. Valet av realtidsteknologi kan, baserat på de resultat denna studie påvisat, göras grundade på de faktorer som behandlas. Däremot uppvisar dessa resultat att valet av realtidsteknologi bäst baseras på det kontext den skall användas i där WebSockets är det bästa valet om en implementation av denna realtidsteknologi är möjlig. II

ABSTRACT Real-time communication between server and client is something that is used in various areas; from playing online games to following the stock market. The common denominator for this type of communication is that something is being communicated between two or more parties where it is desirable to have the least possible delay in the delivery of sent messages in order to create a smooth user experience that is experienced as real-time. In this comparative study real-time communication is dealt with through the development of a browser application for game results in real-time, where the transmitted data is then analyzed focusing on the importance of traffic, response time, scalability, bandwidth and compatibility. The real-time technologies used to enable communication between the server and client in this study are, at the request of the client, based on the framework Socket.IO which enables this kind of communication through the technologies WebSockets, HTMLfile, XHR Polling and JSONP Polling. WebSockets, which is the newest technology, showed results that were significantly better than the other real-time technologies considering all named factors except compatibility where it s comparatively recent origin restricts the technology to only the newest, most up to date browsers. HTMLfile proved to be the closest competitor to WebSockets regarding traffic and response time, but its lack of general compatibility may prove to be crucial for implementations of this technology, considering that this type of connection can only be achieved in the Internet Explorer browser. The most general implementation was made possible through XHR- and JSONP Polling, which are supported in both the old and new versions of the major browsers. These real-time technologies, however, showed significantly greater traffic and longer response times and thus higher load on the server and lower scalability. The choice of real-time technology can, based on the results this study demonstrated, be based on the factors considered. However, these results show that the choice of real-time technology is best based on the context it is going to be used in where WebSockets is the best choice if an implementation of this real-time technology is possible. III

INNEHÅLLSFÖRTECKNING FÖRORD... I SAMMANFATTNING... II ABSTRACT... III ORDFÖRKLARING... 1 1. INLEDNING... 3 1.1. BAKGRUND... 3 1.2. PROBLEMDISKUSSION... 4 1.3. FORSKNINGSFRÅGA... 6 1.4. SYFTE... 6 2. TEORI... 6 2.1. REALTIDSKOMMUNIKATION... 6 2.1.1. REALTIDSTEKNOLOGIER... 6 2.2. REFERENSRAM... 7 2.3. PRECISERING OCH AVGRÄNSNINGAR... 9 3. METOD... 11 3.1. UTVECKLING AV WEBBLÄSARAPPLIKATION... 11 3.1.1. SCENARIO FÖR MATCHRESULTAT... 14 3.1.2. UTVECKLINGSVERKTYG... 14 3.2. UTFÖRANDE AV EXPERIMENT... 15 3.3. FORSKNINGSSYFTE... 16 3.4. FORSKNINGSANSATS... 16 3.5. FORSKNINGSSTRATEGI... 16 3.6. VALIDITET OCH RELIABILITET... 17 3.6.1. VALIDITET... 17 3.6.2. RELIABILITET... 17 4. EMPIRI... 18 4.1. DATA... 18 4.1.1. TRAFIKMÄNGD FÖR ADMINISTRATÖRSGRÄNSSNITTET... 19 4.1.2. TRAFIKMÄNGD FÖR ETT ÅSKÅDARGRÄNSSNITT... 20 4.1.3. RESPONSTID PÅ LOKALT NÄTVERK... 20 4.1.4. RESPONSTID PÅ 3G-NÄTVERK... 20

5. ANALYS... 22 5.1. TRAFIKMÄNGD... 22 5.2. RESPONSTID... 23 5.3. SKALBARHET... 25 5.4. BANDBREDD... 26 5.5. KOMPATIBILITET... 28 6. DISKUSSION OCH SLUTSATSER... 29 6.1. BESVARANDE AV FORSKNINGSFRÅGA OCH SYFTE... 29 6.2. DISKUSSION... 29 6.3. SLUTSATSER... 31 6.4. METODDISKUSSION... 33 6.5. FÖRSLAG TILL FORTSATT FORSKNING... 34 7. REFERENSER... 35 BILAGA 1: KOMPLETT DATA FÖR TRAFIKMÄNGD... 38 BILAGA 2: KOMPLETT DATA FÖR RESPONSTIDER... 47

ORDFÖRKLARING Denna studie innehåller en del ord och begrepp som här förklaras närmare: KLIENT I denna studie menas med klient en användare som använder en webbläsare i en dator. Webbläsarapplikationen som utvecklats i denna studie har använts av en användare i en webbläsare och innefattas därför i begreppet klient. Alla klienter som förekommit i experimenten i denna studie har varit baserade på samma dator. När fler klienter än en använts har en webbläsare med flera flikar använts. SERVER Med server menas i denna studie den node.js-webbserver som använts för att möjliggöra realtidskommunikation. En server används i allmänhet som en mellanhand för att sköta andra datorers eller datorprograms kommunikation med varandra. Den utför olika tjänster såsom att skicka data mellan parter eller att lagra filer (TechTerms, 2011). I denna studie har servern tagit emot data från en klient och skickat tillbaka ett programmatiskt inställt svar med ny data till klienten. HTTP HTTP står för Hypertext Transfer Protocol och är det vanligaste protokollet som används vid kommunikation på World Wide Web (WWW). Det används för att överföra information mellan klient och server i form av webbsidor. Protokollet skickas när en klient begär något från en server eller vice versa och innehåller den nödvändiga informationen som krävs för att möjliggöra kommunikation mellan dessa två parter (W3C, 1999). Detta kan t.ex. vara att en användare klickar på en länk i en webbläsare varpå servern besvarar denna begäran med att skicka användaren till den webbsida som begärts. TCP TCP står för Transmission Control Protocol och är det vanligaste protokollet som används vid kommunikation på Internet. Det används för att överföra data mellan två parter och vanligen används TCP-port 80 till detta. Porten kan kontrolleras administrativt för att försäkra att bara tillåtna anslutningar mellan två parter görs. De två parterna kan vara t.ex. två datorer eller en dator och en webbserver. HTTP-protokoll används ofta över en TCPanslutning för att kommunicera på WWW, vilket använder Internet för att möjliggöra kommunikation (W3C, 2004). 1

HTML HTML står för Hypertext Markup Language och är det vanligaste sättet att bygga upp en webbsida. Det används för att bestämma den grundläggande strukturen på en webbsida och innehåller information för t.ex. vilken titel en webbsida skall ha (W3C, 1999). HTML innehåller som dock ingen information om hur innehållet kan finjusteras eller göras mer personligt utseendemässigt. CSS CSS står för Cascading Style Sheets och används till att stilisera utseendet på t.ex. en webbsida (W3C, 2011). Genom CSS kan bl.a. textfärg, teckensnitt och marginaler på bilder bestämmas. BUGG En bugg är i denna studie ett fel i en webbläsarapplikation som gör att den möjligen inte fungerar ändamålsenligt utan behöver åtgärdas programmatiskt på något sätt. SOCKET.IO Socket.IO benämns i denna studie som ett ramverk. Med detta menas ett javascript-baserat ramverk som installeras på en node.js-server för att möjliggöra realtidskommunikation. Javascript är ett dynamiskt skriptspråk inom programmering och används bl.a. i HTML-kod för att utföra funktioner på webbsidor (W3C, 2013). Inom ramverket Socket.IO finns valmöjligheter att programmatiskt använda olika realtidsteknologier och det är dessa som legat till grund för denna studie. 2

1. INLEDNING I detta inledande avsnitt behandlas det valda studieområdet utifrån områdets bakgrund och dess problematik. Även studiens forskningsfråga och dess syfte redogörs. 1.1. BAKGRUND Internet används idag till stor del för att möjliggöra kommunikation mellan människor från en plats till en annan och denna kommunikation är i det närmaste världsomfattande. Fram till för några år sedan har en stor del av denna kommunikation bestått av olika request- och response-metoder, eller begäran och svar-metoder, baserat på HTTP-protokoll. Detta betyder att en klient, vilket i denna studie innebär detsamma som en användare genom en webbläsare, skickar en begäran till en server och denna server skickar sedan tillbaka ett svar baserat på vad som skickats i begäran (Qigang & Xiangyang, 2012). Detta kan exempelvis innebära att en användare läser en dagstidning i sin webbläsare och sedan klickar på en nyhetslänk, möjligtvis ett matchresultat. Funktionaliteten bakom nyhetslänken skickar då en begäran till den tillhörande servern som sedan skickar tillbaka ett svar i form av den webbsida användaren vill få tillgång till. Denna kommunikation sker genom att en klient aktivt begär något från servern. När användaren klickar på nyhetslänken i sin webbläsare görs en begäran till en server efter specifik data. Servern svarar sedan klienten genom att skicka tillbaka den begärda datan till klienten om den existerar på servern. I de fall där den förfrågade datan inte finns lagrad på servern kan istället ett felmeddelande, vanligen med felkod 404, skickas tillbaka från servern. Detta felmeddelande underrättar användaren om att den förfrågade datan inte kunde hittas. Denna typ av kommunikation mellan klient och server kallas sammanfattningsvis för halvduplex kommunikation (Aresh, 2012). Med detta menas att kommunikationen endast sker åt ett håll i taget mellan två parter. I experimenten i denna studie sker halv-duplex kommunikation från klient till server då det är klienten som aktivt begär något från servern och servern endast svarar med det svar den är programmerad att ge. För att kringgå intrycket av denna begäran och svar-baserade kommunikation där klienten alltid aktivt måste begära något för att uppnå sitt ändamål och för att begränsa kraven på användarens interaktion med webbläsaren utvecklades metoder som på olika sätt gör en begäran från klient till server automatisk (Aresh, 2012). Därigenom skapades också illusionen av realtidskommunikation i webbläsare. Uppkomsten av WebSockets i samband med lanseringen av HTML5 har gjort det möjligt att, via ett uppgraderat HTTP-protokoll kallat The WebSocket Protocol, upprätta en förbindelse mellan klient och server på andra villkor än tidigare (Ubl & Kitamura, 2010). Denna kommunikation sker över en TCP-anslutning och är full-duplex, vilket möjliggör att både klient och server kan skicka data till den andra parten, i realtid. 3

Det finns flera olika realtidsteknologier att tillämpa för att förverkliga realtidskommunikation i webbläsare och webbläsarapplikationer och denna studie åskådliggör ett urval av dem baserat på ett ramverk som heter Socket.IO där både äldre sedan länge etablerade realtidsteknologier och den senaste av dem, WebSockets, möjliggörs. 1.2. PROBLEMDISKUSSION De teknologier för realtidskommunikation som varit etablerade sedan före uppkomsten av HTML5, vilket möjliggjorde WebSockets, är alla någon form av simulering av realtid, där utvecklarna både använt sig av och kringgått de regler som finns för kommunikation mellan server och klient (Synodinos, 2008). Dessa teknologier är dock utvecklade under lång tid och det har beroende på kontext därför även utvecklats väl anpassade metoder som kan åtgärda uppkomna problem. Dessa fördelar finns inte hos WebSockets vilket är en ny teknologi i sammanhanget. Problematiken inom området existerar både i sedan länge etablerade realtidsteknologier och i nyare. Bland de första teknologierna för vad som då kallades realtid finns något som kallas short-polling. Den här teknologin automatiserar klientens begäran mot servern och skickar dessa kontinuerligt baserat på ett bestämt tidsintervall. Det största problemet med den här teknologin är konfigureringen av tidsintervallet för klientens begäran och den påverkan detta har på den mängd trafik som skickas (Synodinos, 2008). Problematiken menas ligga i att det vid korta uppdateringsintervall skickas större mängd trafik vilket också medför större krav på servern. Det är inte heller säkert att det sänds tillbaka ny data från servern till klienten utan bara ett tomt svar, vilket även gör att mängden trafik som skickas är större än vad den skulle behöva vara. Skulle tidsintervallet vara för långt finns dock risk för att ny data missas, vilket gör att realtidskomponenten går förlorad. För att motverka problematiken med short-polling kan istället long-polling användas, vilket gör att svaret på klientens begäran endast skickas från servern när det programmatiskt inställda tidsintervallet löper ut (Qigang & Xiangyang, 2012). Även om short- och long-polling i stora drag fungerar på samma sätt bortsett från tidsintervallet är den största skillnaden mot short-polling att servern istället för att direkt när begäran kommer till servern skicka ett svar till klienten istället sparar klientens begäran och håller förbindelsen levande tills dess att det programmatiskt inställda tidsintervallet löper ut (ibid.). När tidsintervallet löpt ut skickas begärd data från servern och klienten skickar på nytt en begäran till servern och en ny förbindelse mellan klient och server upprättas. För denna teknologi menas den största problematiken ligga i att en server kan behöva upprätthålla förbindelser till fler än en klient samtidigt, vilket gör att servern blir hårt belastad (ibid.). Long-polling kan till skillnad från short-polling även användas till tvåvägskommunikation, vilket kräver två separata HTTPprotokoll (Synodinos, 2008). Detta menas dock medföra stor problematik gällande trafikmängd och belastning på servern då detta gör att trafiken ökar tvåfalt för varje klient. XHR Polling och JSONP Polling har liknande funktionalitet som long-polling, men istället för att vänta ut tidsintervallet innan servern skickar tillbaka ett svar skickas istället svaret tillbaka när ny data finns tillgänglig på servern eller att ett programmatiskt tidsintervall löpt ut. 4

Realtidskomponenten blir därför mer påtaglig än vid användandet av long-polling (Synodinos, 2008). HTTP Streaming, i denna studie implementerat som HTMLfile genom Socket.IO, delar problematiken med long-pollings multipla samtidiga öppna förbindelser och dess belastning på servern, men istället för att skicka ett fullständigt svar till klienten varje gång ny data finns tillgänglig på servern behåller servern förbindelsen öppen och skickar ett endast partiellt svar till klienten där meddelandena bäddas in i skript (Lubbers & Greco, 2011), något som menas medföra överflödig data då meddelandena innehåller onödiga tecken och därigenom mer data. Detta kan dock beroende på scenario ändå innebära mindre data än vad som skickas med short-, long-, XHR- och JSONP Polling. Den största problematiken med HTMLfile menas vara att servern endast skickar partiella svar på klientens begäran. På så vis hålls förbindelsen levande och en brandvägg eller en proxy kan avsluta förbindelsen mellan klient och server genom att buffra det endast partiella svaret från servern (ibid.). I dessa fall betyder det att en förbindelse mellan server och klient inte kan hållas levande utan avbryts, vilket leder till att data inte kan skickas däremellan. Det största problemet med WebSockets är idag att dess webbläsarkompatibilitet är sämre än de övriga realtidsteknologierna. Detta menas delvis bero på att det är ett nytt sätt att möjliggöra kommunikation mellan server och klient på och att teknologin inte är färdigutvecklad än (W3C, 2013). Den slutgiltiga lanseringen av HTML5 har inte skett än och några av de mest framstående anledningarna är enligt Web Real-Time Communications Working Group (W3C), att de teknologier som omfattas av den nya standarden måste vara både bakåt- och framåtkompatibla och även göras tillgängliga på all hårdvara som hanterar HTML. Dessa innefattar t.ex. tv-apparater, smart phones och surfplattor (ibid.). Vidare menar utvecklarna på W3C att den nya standarden HTML5 kommer att nå statusen rekommenderad standard och därigenom även vara officiellt lanserad innan slutet av år 2014 (ibid.). Den mest frekvent återkommande problematiken inom realtidskommunikation i det litteraturunderlag denna studie baserats på är den trafikmängd som består av s.k. headerdata. Med headerdata menas den för HTTP-anslutningar obligatoriska data som skickas med vid varje begäran från en klient till en server samt vid varje svar som skickas tillbaka från servern (Ye, 2011). Detta är ett gemensamt problem för alla i denna studie innefattade realtidsteknologier förutom WebSockets som kommunicerar mellan server och klient på andra villkor än de andra realtidsteknologierna. WebSockets skickar bara headerdata en gång, när den skapar en förbindelse mellan server och klient och därefter skickas bara den mängd data som de skickade meddelandena innehåller (ibid.). Denna onödiga trafik kallas också för overhead, då den påverkar trafikmängden genom att skicka med data utöver det som är tänkt att skickas. Overhead är något som återfinns även i meddelanden som skickas mellan server och klient och beroende på vilken realtidsteknologi som används skiljer sig storleken på den overhead som ingår i den totala trafikmängden. Gällande headerdata innebär problematiken runt detta jämförelsevis i denna studie att om ett meddelande om 46 bytes skickas från klient till server med WebSockets tillkommer även 5

en engångsmängd headerdata om 408 bytes för begäran och 93 bytes för svar för att starta förbindelsen. Då WebSockets bara skickar headerdata en gång belastar nästa meddelande som skickas istället servern med endast 46 bytes. Detta till skillnad mot de andra realtidsteknologierna i denna studie som för varje skickat meddelande fortsätter att belasta servern med både headerdata och meddelandedata. 1.3. FORSKNINGSFRÅGA Vilken realtidsteknologi är bäst lämpad att använda till en webbläsarapplikation för matchresultat i realtid och vilka begränsningar finns för de olika realtidsteknologierna? 1.4. SYFTE Syftet med denna studie är att jämföra samt analysera för- och nackdelar med utvalda realtidsteknologier genom att efter utveckling av en webbläsarapplikation för matchresultat i realtid genomföra en komparativ studie utifrån en teoretiskt fastställd referensram. 2. TEORI I detta avsnitt redovisas den teori som legat till grund för denna studie. Denna sammanfattas slutligen i den teoretiska referensramen som tagits fram för studien. 2.1. REALTIDSKOMMUNIKATION För att möjliggöra realtidskommunikation i webbläsare, vilket i denna studie åskådliggörs i form av en webbläsarapplikation för matchresultat, krävs minst en server och minst en klient. Utöver detta krävs också en fungerande implementation av logiken bakom kommunikationen. De nödvändiga komponenterna skiljer sig inte mellan de olika teknologierna för realtidskommunikation, men de kan implementeras på olika sätt. I denna studie har dock samma förutsättningar använts för alla realtidsteknologier för att få konsekventa resultat från experimenten. Med klient avses en användare genom en webbläsare. I denna studie menas utöver detta även att en klient använder sig av en webbläsare i en dator, stationär eller bärbar. Därför går studien inte att direkt relatera till övriga medier som har en webbläsare. 2.1.1. REALTIDSTEKNOLOGIER Realtidskommunikation mellan server och klient kan möjliggöras genom att använda olika realtidsteknologier. Dessa teknologier har tidigare alla varit en form av att förbigå det existerande protokollet för kommunikation över Internet, HTTP. Med introduktionen av den nya realtidsteknologin WebSockets introducerades även ett nytt protokoll, the WebSocket 6

Protocol, som uppgraderar HTTP-protokollet och därigenom möjliggör full-duplex kommunikation mellan server och klient över en TCP-anslutning (Fette & Melnikov, 2011). 2.2. REFERENSRAM Bo, Jie, Junliang & Xiangwu (2009) menar att behovet av realtid uppkommer beroende på kontext. De menar att kravet på realtid skildras i huruvida ett meddelande som skickas mellan två parter har ett behov av att besvaras inom en förutbestämd tidsram. Stöd för detta återfinns även hos Kirubashankar & Krishnamurthy (2012) som menar att detta behov finns vid kritiska funktioner där skickat data förlorar sin realtidskomponent om det inte levereras före den bestämda tidsrymden löpt ut. För att ytterligare betona vikten av att något som meddelas till en annan part i realtid också kräver ett omedelbart svar menas detta i hög grad vara gällande för situationer där data skickas i hög frekvens och har krav på leveransprecision enligt Bo, Jie, Junliang & Xiangwu (2009). Med detta menas att även ordningen i vilken meddelandena mellan två parter mottas och besvaras är betydande (ibid.) I ett önskvärt scenario är responstiden mellan meddelande och svar obefintlig enligt Bo, Jie, Junliang & Xiangwu (2009). Detta innebär i denna studie att realtidskomponenten skulle gå förlorad om en uppdatering av matchresultatet skulle ske utan att den nådde fram till klienten inom en rimlig tidsrymd eller om flera uppdateringar av matchresultatet skulle ske utan att klienten hann registrera dem som individuella uppdateringar. En i teorin som använts som underlag för denna studie återkommande faktor för realtidskommunikation är trafikmängden som skickas mellan server och klient och vice versa. Bertini, Leite & Mossé (2010) menar att en belastning som är oberäknad står i korrelation med realtidskomponenten, där ökad trafikmängd kan ge upphov till ökade fördröjningar i responstiden mellan server och klient. Trafikmängden som skickas mellan server och klient är därför av vikt för en realtidsapplikation vars mål är att leverera meddelanden om förändringar i realtid, eller med så liten responstid som möjligt. Även Lubbers & Greco (2011) menar att trafikmängden är av stor betydelse. De menar att skalbarheten för en applikation ökar när trafikmängden minskar. Detta då såväl belastningen på tillhörande server som responstiden för de kommunicerade meddelandena som skickas mellan server och klient minskar. Dessa synpunkter återfinns även hos Ye (2011) som menar att en stor trafikmängd introducerar fördröjningar i responstid för applikationer, vilket menas ha stor inverkan på huruvida applikationen har någon skalbarhet eller inte. Skalbarhet är en bred faktor som innefattar andra faktorer och är den del i teorin inom området som återkommit som en av de mest avgörande faktorerna för applikationer. Ytterligare en faktor som i denna studie tas i åtanke gällande skalbarhet är de olika realtidsteknologiernas webbläsarkompatibilitet. Med detta menas att respektive realtidsteknologi fungerar i en webbläsare endast om webbläsaren uppnått en specifik version (se Tabell 1: Webbläsarkompatibilitet för realtidsteknologier samt användarandel för webbläsare. I tabellen baseras användarantalet på Browser Statistics (2013) och realtidsteknologiernas webbläsarkompatibilitet på Rauch (2012).). 7

Realtidsteknologi IE Firefox Chrome Safari Opera WebSockets 10 11 17 6 12.1 XHR Polling 5.5 3 4 3 10.61 JSONP Polling 5.5 3 4 3 10.61 HTMLfile 5.5 - - - - Antal användare 12.7 % 27.9 % 52.7 % 4.0 % 1.7 % Tabell 1: Webbläsarkompatibilitet för realtidsteknologier samt användarandel för webbläsare Baserat på Browser Statistics (2013) och Rauch (2012) är de fem vanligaste webbläsarna för datorer idag Internet Explorer (IE), Mozilla Firefox (Firefox), Google Chrome (Chrome), Safari och Opera. Bland dessa är Chrome den webbläsare med klart mest användare följt av Firefox och IE samt endast ett fåtal användare som använder Safari och Opera. De i denna studie undersökta realtidsteknologierna har olika webbläsarkompatibilitet och detta har betydelse för huruvida de olika teknologierna kan implementeras i en webbläsare med klient- och serverscenario likt det i webbläsarapplikationen för matchresultat i realtid i denna studie. TRAFIKMÄNGD Den mängd data i byte som skickas mellan klient och server eller vice versa RESPONSTID Den tid i millisekunder (ms) det tar från att en begäran skickas från en klient till en server tills dess att klienten mottagit ett svar från servern SKALBARHET I vilken mån det går att använda aktuell realtidsteknologi i stor skala BANDBREDD Hastighet på aktuell klients uppkoppling KOMPATIBILITET Vilka webbläsare som aktuell realtidsteknologi kan användas i samt andra kompatibilitetsbegränsningar som kan förekomma Figur 1: Teoretisk referensram för realtidsteknologierna i denna studie 8

Sammanfattningsvis återfinns hos Kirubashankar & Krishnamurthy (2012) underlag för samtliga av de för realtidskommunikation påverkande faktorer som tas upp i denna studie. De menar utöver att realtidskomponenten kan korreleras till att data som skickas måste levereras inom en bestämd tidsrymd även att trafikmängden är av stor vikt, då realtidsfaktorn påverkas ju större trafikmängden blir. Detta menas i sin tur kunna relateras till skalbarhet då fler anslutna klienter medför större belastning på servern och större trafikmängd. Detta menas även vara en parallell till bandbredd då lägre bandbredd anses ha mindre kapacitet för trafikmängd än en högre bandbredd. Slutligen menar Kirubashankar & Krishnamurthy (2012) att bandbredden också är av betydelse för huruvida data som skickas kommer att nå fram eller inte, då de menar att dess framgång minskar med mindre bandbredd. De faktorer som frekvent återkommit i studiens teoretiska underlag, vilka har betydelse för realtidskommunikation för en webbläsarapplikation, utgör den teoretiska referensramen för denna studie. Detta medför att studien har en teoretiskt fastställd utgångspunkt från vilken webbläsarapplikationen för matchresultat i realtid har utvecklats och experimenten har utförts. De för realtidskommunikation påverkande faktorerna som återfinns i denna studie sammanfattas i Figur 1: Teoretisk referensram för realtidsteknologierna i denna studie. 2.3. PRECISERING OCH AVGRÄNSNINGAR Studien är utförd med ett företag som uppdragsgivare och har därför avgränsats efter deras önskemål. Detta innebar en komparativ studie över de realtidsteknologier som stöds av ramverket Socket.IO. Det finns andra sätt att möjliggöra realtidskommunikation i webbläsare. Dock innefattar Socket.IO många av de möjligheter till realtidskommunikation mellan server och klient som återkommit i studiens teoretiska underlag inom området. Omfattningen för studien anses därför rimlig. Enligt Rauch (2012) har Socket.IO stöd för följande realtidsteknologier för att transportera data i webbläsarapplikationer: JSONP Polling AJAX Long Polling AJAX Multipart Streaming Forever Iframe Adobe Flash Socket WebSockets Denna studie är avgränsad till dessa realtidsteknologier: JSONP Polling AJAX Long Polling Forever Iframe WebSockets 9

I Socket.IO implementeras AJAX Long Polling under namnet XHR Polling och Forever Iframe implementeras under namnet HTMLfile. Därför benämns dessa två realtidsteknologier så även i denna studie. AJAX Multipart Streaming ger stöd för kommunikation både mellan server och klient och vice versa utan krav på kontinuerliga begäran från den sida som inte skickar data. Något som inte behövs i denna studie då administratörsgränssnittet alltid meddelar om att data skall skickas från servern till uppkopplade åskådargränssnitt. Adobe Flash Socket är teoretiskt likt WebSockets, men då Adobe Flash Socket innefattar en rad olika steg för att kunna implementeras överhuvudtaget överensstämmer det inte med de riktlinjer för realtidskommunikation som W3C (2013) fastslagit. W3C (2013) menar att en av faktorerna för att möjliggöra funktionell realtidskommunikation i webbläsare är att inga extra tillbehör eller plugins ska behöva installeras i klientens webbläsare. För detta finns stöd även hos Gutwin, Lippold & Graham (2011) som menar att detta medför att inte alla kan få åtkomst till applikationen. Detta kan exempelvis gälla klienter på publika nätverk såsom ett universitet eller någonstans där datorerna i nätverket av någon anledning är låsta på ett sätt som gör det omöjligt att installera ny programvara. Utöver att Adobe Flash Socket kräver en installation av Flash Player krävs även ytterligare åtgärder i form av t.ex. en socket policy file vilken används för att tillåta förbindelser mellan klienter och servrar (Ulhey, 2008). Detta har sammantaget gjort att både AJAX Multipart Streaming och Adobe Flash Socket exkluderats från denna studie. Nämnda short- och long-polling innefattas inte i studien då dessa inte använder samma förutsättningar som de i studien innefattade realtidsteknologierna. Detta då ett kort tidsintervall om exempelvis en sekund vid användandet av short-polling skulle innebära att realtidskomponenten var aktuell, men att en enorm belastning på servern skulle förekomma i form av trafikmängd i jämförelse med övriga realtidsteknologier. Vid ett långt tidsintervall om exempelvis 20 sekunder vid användandet av long-polling skulle belastningen på servern i form av trafikmängd minska avsevärt, men realtidskomponenten skulle gå förlorad. Detta då flera uppdateringar skulle kunna ske utan att någon av dem skickades till klienten förrän det programmatiskt inställda tidsintervallet löpt ut. Något som strider mot det Kirubashankar & Krishnamurthy (2012) menar är en viktig del av realtidskommunikation. Utöver företagets avgränsningar gällande Socket.IO och exkluderingen av short- och longpolling har även andra avgränsningar gjorts. Då webbläsarapplikationen är tänkt att åskådliggöra ett generellt koncept som kan kopplas till alla sporter med samma premisser begränsades scenariot till uppdatering av matchresultat där realtidskomponenten låg i fokus. Scenariot innebar att två lag spelar mot varandra och mål eller poäng görs allteftersom matchen spelas tills dess att matchtiden tar slut. Detta gjordes för att bemöta kriterierna fastställda i den teoretiska referensramen på bästa sätt. Sporten basket har använts som mall för applikationen, även om många andra sporter kunde använts. Valet gjordes eftersom basket är en sport där resultatet uppdateras oftare och en quarter, eller period, är kortare jämfört med andra sporter. Basket valdes medvetet för att 10

korta ner tiden mellan uppdateringarna av matchresultatet samt för att korta ner tiden för experimenten, vilka alla simulerades i reell tid. De webbläsare som använts i denna studie är: Chrome 26 IE 9 Stöd för realtidskommunikation finns även, beroende på vilken realtidsteknologi som implementeras, i webbläsarna Firefox, Safari och Opera. I denna studie används dock endast Chrome 26 och IE 9 då studien ämnar åskådliggöra realtidskommunikation på en bred basis när den i möjligaste mån fungerar som den är tänkt att göra. Detta för att sedan analysera data de olika realtidsteknologiernas användning genererat, något som dessa två webbläsare stöder baserat på de realtidsteknologier som förekommer i denna studie. Utöver detta innehar dessa två webbläsare även funktionalitet för att synliggöra responstiden för den kommunikation som sker mellan klient och server genom webbläsarnas respektive Developer Tools och dess konsol där loggade meddelanden kan avläsas. 3. METOD Tillvägagångssättet för denna komparativa studie har varit att genom att ta del av litteratur inom området först skapa en teoretisk referensram ur vilken den fortsatta studien baserats. Webbläsarapplikationen för matchresultat har sedan utvecklats utifrån de för realtidskommunikation påverkande faktorer som fastställts i den teoretiska referensramen. Därefter har sammanlagt 21 experiment utförts med utgångspunkt ur den teoretiska referensramen och slutligen har analyser gjorts och slutsatser dragits från den empiri som nåtts genom de utförda experimenten. 3.1. UTVECKLING AV WEBBLÄSARAPPLIKATION Under utvecklingen av webbläsarapplikationen bestämdes först vad webbläsarapplikationen hade för mål, vilken målgruppen var för applikationen och hur den skulle kunna nå det uppsatta målet: Mål: Erbjuda åskådare matchresultat i realtid Målgrupp: Alla, oavsett kön och ålder, som är intresserade av den aktuella matchen Hur: Genom att använda realtidsteknologi Genom att möjliggöra kommunikation mellan server och klient och vice versa 11

En avgränsning gjordes sedan för vad webbläsarapplikationen skulle innehålla och den delades upp i två olika gränssnitt, ett administratörsgränssnitt och ett åskådargränssnitt. Ett administratörsgränssnitt var nödvändigt då ett gränssnitt som skickade meddelanden till servern med instruktioner om vad som skulle skickas ut till åskådarna behövdes. I denna studie motsvarar dessa meddelanden de uppdateringar av det aktuella matchresultatet som efter att servern mottagit dem automatiskt skickas till uppkopplade åskådarklienter. Administratörsgränssnittet är därför kopplat till logiken för webbläsarapplikationen och gränssnittet för åskådarna är ett endast visuellt gränssnitt där det aktuella matchresultatet uppdateras utan någon användarinteraktion. De två gränssnitten tilldelades därefter funktionalitet och behörighet: Administratör: Ändra matchresultat genom att lägga till eller ta bort mål Simulera matchresultat Nollställa matchresultat Åskådare: Se matchresultat i sin webbläsare utan att behöva uppdatera den manuellt Innan utvecklingen av logiken för att få webbläsarapplikationen att fungera ändamålsenligt gjordes en prototyp för den visuella delen av applikationen. Detta gjordes för såväl administratörsgränssnittet som för åskådargränssnittet (se Figur 2: Prototyp för webbläsarapplikation). 12 Figur 2: Prototyp för webbläsarapplikation

Webbläsaren till vänster representerar administratörsgränssnittet och webbläsaren till höger representerar åskådargränssnittet. I administratörsgränssnittet finns sex knappar under det aktuella matchresultatet, de två översta knapparna tilldelar respektive lag ett mål och de två underliggande knapparna tar bort ett mål om för många mål av någon anledning skulle tilldelas. Den större knappen längst ner till vänster används för att starta en simulering av ett matchresultat och knappen längst ner till höger används för att nollställa det aktuella matchresultatet och återgå till matchresultatet 0-0 vilket är det initiala matchresultatet vid början av varje experiment. I åskådarens webbläsare visas det aktuella matchresultatet allteftersom det blivit meddelat till servern av administratörsgränssnittet och sedan skickat från servern till åskådargränssnittet som mottagit meddelandet. När prototypen för de båda visuella delarna var färdiga utvecklades och implementerades motsvarigheten till denna för både administratörsgränssnittet och åskådargränssnittet (se Figur 3: Slutlig implementation av webbläsarapplikation). Till detta användes HTML och Cascading Style Sheets (CSS) vilka i kombination är ett vanligt sätt att bygga upp webbsidor och webbläsarapplikationer. Figur 3: Slutlig implementation av webbläsarapplikation Slutligen utvecklades och testades logiken bakom webbläsarapplikationen genom ett antal iterationer för att se att applikationen fungerade ändamålsenligt och buggfritt, d.v.s. inte hade några funktionella fel som kunde orsaka oegentligheter. Denna process inkluderade utvecklingen av den nödvändiga kommunikationen mellan server och klient och de meddelanden som skickas däremellan. För att underlätta vid experimenten utvecklades även en matchsimulator. Denna möjliggjorde automatiska uppdateringar av matchresultatet 13

genom att skicka dessa från administratörsgränssnittet till servern och sedan vidare till åskådargränssnittet utan ytterligare användarinteraktion annat än att klicka på knappen STARTA SIMULERING. Utvecklingen av prototypen till de båda gränssnitten till webbläsarapplikationen skedde i Microsoft Visio 2010 och all utveckling av logiken till webbläsarapplikationen skedde i Sublime Text 2. 3.1.1. SCENARIO FÖR MATCHRESULTAT För att möjliggöra experimenten och för att automatisera kommunikationen mellan server och klient och därigenom även skapa automatiska uppdateringar av matchresultatet användes matchsimulatorn när experimenten utfördes. Scenariot för varje matchresultat såg ut följande: Varje experiment startade med matchresultatet 0-0 En quarter pågick i 8 minuter Hemmalagets poäng uppdaterades 25 gånger kontinuerligt under hela quarterns längd med ett slumpmässigt tidsintervall mellan 5 och 30 sekunder och 1-3 poäng där tidsintervall och poäng ändrades vid varje uppdatering för att sammanlagt bli 25 stycken Bortalagets poäng uppdaterades 25 gånger kontinuerligt under hela quarterns längd med ett slumpmässigt tidsintervall mellan 5 och 30 sekunder och 1-3 poäng där tidsintervall och poäng ändrades vid varje uppdatering för att sammanlagt bli 25 stycken 3.1.2. UTVECKLINGSVERKTYG Som utvecklare finns det ofta hjälpmedel att ta till såsom olika utvecklingsmiljöer och andra verktyg som kan underlätta i utvecklingsprocessen. Beroende på vad som skall utvecklas finns också därefter anpassade hjälpmedel. För att utveckla webbläsarapplikationer, speciellt sådana som använder sig av olika sorters realtidskommunikation (node.js, 2013), finns ett ramverk som kallas node.js vilket är ett av de utvecklingsverktyg som använts i denna studie. Node.js är ett ramverk för serversidan av applikationer (McLaughlin, 2011) och det är anpassat för att gynna utvecklaren i dennes arbete med att snabbt utveckla webbläsarapplikationer som är i behov av skalbarhet, d.v.s. kunna möta behovet av ett ökat antal aktiva användare som använder applikationen (node.js, 2013). Då konceptet med webbläsarapplikationen i denna studie teoretiskt sett kan komma att brukas av ett stort antal användare samtidigt och för att skalbarhet är en faktor i den fastslagna teoretiska referensramen för denna studie är det nödvändigt att webbläsarapplikationen är anpassad till detta. För att utöka möjligheterna med node.js har även Express använts, vilket är ett ramverk för webbläsarapplikationer som utvecklas med node.js där funktionalitet både för enkel- och flersidiga webbplatser är i fokus (Express.js, 2013). Användningen av Express medförde i denna studie en förenklad användning av node.js. 14

Till skillnad från HTML-baserade webbläsarapplikationer som i grunden endast visar statiskt material (AngularJS, 2010) har för att få webbläsarapplikationen mer dynamisk AngularJS använts. Detta är ett ramverk som är en utökning av HTML-språket som med dess möjlighet till databindning även gör att innehållet i en webbläsarapplikation uppdateras i realtid när något förändras. Något som gör att detta ramverk lämpar sig till denna studie gällande realtidskommunikation. Slutligen har, för att möjliggöra användandet av flera olika realtidsteknologier, även Socket.IO använts under utvecklingen av webbläsarapplikationen. Något som också ligger till grund för denna studie. Socket.IO kan användas för att automatiskt välja den typ av realtidsteknologi som bäst lämpar sig att transportera data mellan server och klient utifrån förutsättningarna (Rauch, 2012). Baserat på vilken webbläsare klienten använder och vilket stöd denna har för de olika realtidsteknologierna väljs det alternativ som är bäst anpassat till detta när den aktuella webbläsarapplikationen körs. Då det även går att manuellt välja vilken realtidsteknologi som skall användas har det vid de utförda experimenten möjliggjorts testning av de olika realtidsteknologierna var för sig och på så sätt gått att skapa samma förutsättningar för alla experiment. 3.2. UTFÖRANDE AV EXPERIMENT De utförda experimenten gick alla till på följande sätt: Den realtidsteknologi som ämnades testas ställdes in programmatiskt via programkoden En webbläsare öppnades på den dator som användes vid experimenten Webbläsarapplikationen öppnades i webbläsaren Klientantal för experimentet angavs STARTA SIMULERING-knappen klickades i administratörsgränssnittet Matchen simulerades Skickad data mellan server och klient och vice versa dokumenterades För varje testad realtidsteknolog utfördes: Tre experiment på lokalt nätverk: Ett vardera för 1, 5 och 10 klienter Tre experiment på 3G-nätverk: Ett vardera för 1, 5 och 10 klienter Nämnvärt är att det inte var möjligt att genomföra något av de tre tänkta experimenten på 3G-nätverket för realtidsteknologin HTMLfile. Detta p.g.a. att servern som användes vid experimenten låg bakom en proxy, vilket stoppade anslutningarna från HTMLfile. För att testa alla faktorer i den teoretiska referensramen har förutsättningarna för experimenten anpassats efter dessa. Då HTMLfile till skillnad från de andra realtidsteknologierna bara stöds av IE har dock experimenten för HTMLfile utförts med IE som webbläsare. Detta medan det i alla andra experiment använts webbläsaren Chrome eftersom denna webbläsare tillhandahöll mer lättanvända inbyggda verktyg (Developer Tools). Detta har dock inte haft någon betydelse för utkomsten av experimenten. 15

De klienter som avses i de utförda experimenten när klientantalet varit mer än en har alla varit i form av nya flikar i webbläsaren. Samma dator har simulerat flera klienter och skickat och mottagit data som i ett verkligt scenario skulle kunna vara från olika datorer och dess användare. För att testa skalbarheten för de olika realtidsteknologierna utfördes tre experiment för varje realtidsteknologi, men med olika klientantal. Ett experiment med en klient, ett med fem klienter och ett med tio klienter. Experimenten utfördes sedan på samma sätt både på det lokala nätverket och på 3G-nätverket. Detta för att utröna huruvida bandbredden hade någon betydelse för utkomsten av experimenten. Den dator och dess programvaror samt både det lokala nätverk och det 3G-nätverk, inkluderat all utrustning som krävs till dessa uppkopplingar, som använts i denna studie har tillhandahållits av företaget där studie bedrivits. 3.3. FORSKNINGSSYFTE Denna studie är en beskrivande studie, där forskningssyftet var att belysa skillnader mellan utvalda realtidsteknologier samt för- och nackdelar med dessa. Något som skett i ett scenario där förutsättningarna varit likadana för alla realtidsteknologier. Detta scenario gäller en webbläsarapplikation för matchresultat i realtid. Användandet av de olika teknologierna har sedan jämförts med varandra utifrån en teoretisk referensram för att uppnå detta syfte. 3.4. FORSKNINGSANSATS Denna studie är baserad på en deduktiv forskningsansats. Detta menas av Bryman & Bell (2011) innebära att en genomförd studie är grundad i ett teoretiskt underlag om det område som ämnas undersökas. Det teoretiska underlag denna studie grundats på sammanfattas i studiens teoretiska referensram för realtidsteknologi. 3.5. FORSKNINGSSTRATEGI Forskningsstrategin för denna studie är komparativ med kvantitativ inriktning där experiment utan kontrollgrupp har genomförts för att åskådliggöra skillnader mellan utvalda realtidsteknologier. I studier där experiment används för att jämföra olika företeelser kan en kontrollgrupp användas, dock menar Bryman & Bell (2011) att en bättre förståelse för en företeelse även kan nås utan kontrollgrupp om den jämförs med något av liknande karaktär. I denna studie är de förekommande företeelserna alla relaterade med varandra och därför kan de också utgöra ett gott underlag för en jämförelse. 16

3.6. VALIDITET OCH RELIABILITET Validitet och reliabilitet används som mått på huruvida det man avser mäta i ett experiment verkligen är det som mäts, vilket i sådana fall ger en hög validitet, och huruvida det resultat man uppnått är pålitligt och följdriktigt vilket i sådana fall innebär att studien har en hög reliabilitet (Bryman & Bell, 2011). I denna studie rör validiteten och reliabiliteten huruvida de utförda experimenten mäter de i den teoretiska referensramen fastställda variablerna och hur pålitliga de resultat som uppnåtts vid dessa experiment är. 3.6.1. VALIDITET Bryman & Bell (2011) menar att validiteten bestäms av riktigheten i de mätningar som görs i en undersökning. Genom de i denna studie utförda experimenten tas alla de i den teoretiska referensramen fastställda faktorerna i beaktande. De påverkande faktorer som tagits fram går alla att relatera till den webbläsarapplikation som utvecklats och de experiment som utförts har alla varit baserade på den teoretiska referensramen. Validiteten görs därför gällande huruvida studien uppnått en riktighet i resultaten från de utförda experimenten utifrån de teoretiskt fastställda testvariablerna trafikmängd, responstid, skalbarhet, bandbredd och kompatibilitet. För alla experiment har samma scenario använts och samma dator vilket skapat samma förutsättningar för alla experiment och därigenom också jämförbara resultat. Variablerna trafikmängd och responstid har mätts med samma antal mätpunkter för varje testad realtidsteknologi och kan därför direkt korreleras mot den teoretiska referensramen. Bandbreddens betydelse har tagits i åtanke i de utförda experimenten genom användandet av både ett lokalt nätverk med en bandbredd på 100 Mbit/s och ett 3G-nätverk med en bandbredd på drygt 3 Mbit/s. Variabeln webbläsarkompatibilitet, ibland också kallat bara för kompatibilitet, har delvis funnits med i experimenten i form av att få de olika realtidsteknologierna att fungera ändamålsenligt och kompatibiliteten och variabeln skalbarhet är båda en viktig del i kommande analys. Sammantaget är experimenten baserade på den teoretiska referensramen, vilket innebär att validiteten för studien är hög. Därför kan också teoretiskt grundade slutsatser dras ur de resultat som nåtts genom de utförda experimenten. 3.6.2. RELIABILITET Reliabilitet är den tillförlitlighet som kan åläggas ett resultat från en undersökning enligt Bryman & Bell (2011). De menar att reliabiliteten för en undersökning beror på om det finns några påverkande faktorer som kan ha förändrat utkomsten av undersökningen, vilket i sådana fall skulle innebära en lägre reliabilitet. Skulle undersökningen leda till samma resultat om den genomfördes en gång till skulle istället reliabiliteten för undersökningen vara hög. 17

I denna studie rör påverkan av reliabiliteten främst användandet av 3G-nätverket, då ingen ytterligare påverkan på varken responstid eller trafikmängd föreligger. Nämnvärt är dock att den lokala datorns klocka har en felmarginal på upp till 1 millisekund (Network Time Protocol, 2013). Till detta tas ingen hänsyn i sammanställningarna av datan utan datan åskådliggörs för samtliga realtidsteknologier med de mättider som samlades in vid experimenten. Samma dator användes för samtliga experiment och därför är denna felmarginal om upp till 1 millisekund konsekvent över alla experiment. Nämnvärt är i detta hänseende att det aldrig heller förekom resultat där 1 millisekund hade gjort någon skillnad för de sammanlagda resultaten från de genomförda experimenten. Detta gör att reliabiliteten för responstiderna är hög. Ytterligare bidrag till denna uppskattning är det stora totala antalet mätpunkter på responstiderna om 30 stycken för varje experiment. Gällande trafikmängden är i.o.m. att både scenariot för alla experiment har varit detsamma och mätpunkterna för trafikmängden har varit lika många även reliabiliteten för trafikmängden hög. De experiment som utförts skulle med mycket hög sannolikhet leda till samma resultat om dessa genomfördes fler gånger eller om de genomfördes någon annanstans, vilket enligt Bryman & Bell (2011) betyder att reliabiliteten är hög. 4. EMPIRI I detta avsnitt följer en sammanställning av data som samlats in genom de utförda experimenten. Sammanställningen innehåller endast data som är nödvändiga för att synliggöra resultaten från experimenten, dock finns den fullständiga informationen för insamlat data som bilagor längst bak i denna studie (se Bilaga 1: Komplett data för trafikmängd samt Bilaga 2: Komplett data för responstider). 4.1. DATA Insamlad data återfinns här uppdelad i två delar: trafikmängd och responstid. Baserat på dessa data ges även utrymme för senare analys av variablerna skalbarhet och bandbredd från den teoretiska referensramen. Kompatibiliteten har i experimenten i möjligaste mån åsidosatts för att kunna utföra experiment där de olika realtidsteknologierna fungerar och kan jämföras med varandra. HTMLfile kunde dock inte användas till de tänkta experimenten på 3G-nätverket med gällande förutsättningar för experimenten. Detta då den server experimenten utfördes mot låg bakom en proxy, vilken stoppade anslutningar utanför företagets domän. Därför saknas data för denna realtidsteknologi för 3G-nätverk. Trafikmängden är här sammanfattad baserat på vilket gränssnitt som använts till den aktuella kommunikationen, administratörsgränssnittet eller ett åskådargränssnitt. Oavsett realtidsteknologi har administratörsgränssnittet använts för att aktivt skicka meddelanden från klient till server och ett åskådargränssnitt har använts för att aktivt begära meddelanden från server till klient. 18

För att kunna åskådliggöra trafikmängden med en matchsimulering som var likadan för alla realtidsteknologier har samma antal uppdateringar av matchresultatet använts för samtliga teknologier och experiment; 25 uppdateringar för hemmalagets mål och 25 uppdateringar för bortalagets mål. De olika teknologierna har dock olika långa tidsintervall mellan sina s.k. heartbeats, varför dessa heartbeats även är olika många för de olika teknologierna (se Bilaga 1 för komplett data för trafikmängd). Heartbeats är ett väldigt kort meddelande som skickas för att behålla förbindelsen mellan klient och server, en slags konfirmation att förbindelsen fortfarande skall hållas aktiv. Dessa heartbeats har därför räknats med i dessa sammanställningar och ingår i den totala mängd data de skickade meddelandena som skickats mellan server och klient består av. Ett tecken i ett meddelande motsvarar en byte, vilket gör att de tecken som skickas med utöver det tänkta meddelandet, overheaden, ökar den totala trafikmängden för meddelandet med det antal tecken som skickas med utöver det tänkta meddelandet. I sammanställningarna för trafikmängd menas med: Meddelanden: Den totala mängd data de skickade meddelandena består av Overhead: Den totala mängd data inom Meddelanden som utgörs av tecken utöver det tänkta meddelandet Headerbegäran: Den totala mängd data de headers som skickas vid begäran består av Headersvar: Den totala mängd data de headers som skickas vid svar består av Total data: Den totala mängd data som skickats vid ett experiment Responstiden, vilken i dessa sammanställningar anges i millisekunder (ms), är mätt med den vid experimenten använda datorns lokala klocka. Denna mätning möjliggjordes genom att det samtidigt som ett meddelande skickades från administratörsgränssnittet till servern varje gång även angavs en tidsvariabel för den aktuella tiden när meddelandet skickades varefter det sedan angavs en ny tidsvariabel för den aktuella tiden varje gång en uppdatering av matchresultatet togs emot av åskådargränssnittet. Genom att sedan subtrahera den nya tidsvariabeln med den äldre gavs responstiden mellan uppdateringen av matchresultatet i administratörsgränssnittet tills dess att matchresultatet uppdaterades i åskådargränssnittet. I experimenten för responstid har 30 mätpunkter använts för att få ett konsekvent resultat för samtliga experiment och här åskådliggörs medelvärde samt varians avrundat till tre decimaler för varje realtidsteknologi och mätpunkt (se Bilaga 2 för komplett data för responstider). 4.1.1. TRAFIKMÄNGD FÖR ADMINISTRATÖRSGRÄNSSNITTET Data som skickats mellan administratörsgränssnittet och servern är de uppdateringar av matchresultatet som skickats från administratörsgränssnittet till servern vilka servern sedan skickat tillbaka ett svar på. Beroende på använd realtidsteknologi har dessa svar varit av olika storlek och baserat på detta har ett scenario där lika många uppdateringar gjorts för alla realtidsteknologier använts. I denna sammanställning ingår även ett meddelande kallat requestupdate som skickas en gång för varje teknologi men som har olika storlek beroende på vilken teknologi som använts (se Bilaga 1 för komplett data för trafikmängd). 19

Realtidsteknologi Meddelanden Overhead Headerbegäran Headersvar Total data WebSockets 2866 bytes 610 bytes 408 bytes 93 bytes 3367 bytes HTMLfile 2088 bytes 0 bytes 20238 bytes 10792 bytes 41118 bytes XHR Polling 2028 bytes 0 bytes 30243 bytes 10863 bytes 43134 bytes JSONP Polling 2536 bytes 508 bytes 35394 bytes 10863 bytes 48793 bytes 4.1.2. TRAFIKMÄNGD FÖR ETT ÅSKÅDARGRÄNSSNITT Tabell 2: Trafikmängd för administratörsgränssnittet Data som skickats mellan ett åskådargränssnitt och servern är de uppdateringar av matchresultatet som administratörsgränssnittet tidigare skickat till servern som sedan skickas av servern till klienter med åskådargränssnitt. För att ta del av dessa uppdateringar måste åskådargränssnittet begära detta av servern. Då dessa uppdateringar är baserade på hur många uppdateringar som gjorts från administratörsgränssnittet är scenariot detsamma för åskådargränssnittet. Gällande heartbeats råder i denna sammanställning samma premisser som för administratörsgränssnittet och dessa har även i denna sammanställning räknats in i den totala mängden meddelandedata. Realtidsteknologi Meddelanden Overhead Headerbegäran Headersvar Total data WebSockets 3262 bytes 176 bytes 408 bytes 93 bytes 3763 bytes HTMLfile 4875 bytes 2185 bytes 359 bytes 0 byte 5234 bytes JSONP Polling 3760 bytes 1124 bytes 26052 bytes 7100 bytes 36912 bytes XHR Polling 2648 bytes 0 bytes 27776 bytes 6490 bytes 36914 bytes 4.1.3. RESPONSTID PÅ LOKALT NÄTVERK 20 Tabell 3: Trafikmängd för ett åskådargränssnitt För att testa responstiden för de olika realtidsteknologierna på lokalt nätverk har en bandbredd på 100 Mbit/s använts (se Tabell 4: Responstider för realtidsteknologier på lokalt nätverk). 4.1.4. RESPONSTID PÅ 3G-NÄTVERK För att även testa de olika realtidsteknologierna ur ett perspektiv där bandbredd har betydelse har dessa testats på ett 3G-nätverk, vilket innebär en kraftigt reducerad bandbredd i jämförelse med experimenten som utfördes på det lokala nätverket. Experimenten på 3G-nätverket möjliggjordes genom att den i experimenten använda datorn anslöts till en trådlös uppkoppling vilken skapades med en WiFi-hotspot med en smart phone. Samma dator och 3G-nätverk användes sedan för samtliga experiment (se Tabell 5: Responstid för realtidsteknologier på 3G-nätverk). Bandbredden på 3G-nätverket fastställdes vid experimentstillfällena till en bandbredd på 3,01 Mbit/s (se Figur 4: Bandbredd på 3Guppkopplingen vid utförda experiment).

Realtidsteknologi 1 klient 5 klienter 10 klienter WebSockets Medelvärde 9,367 ms 9,967 ms 11,200 ms Varians 1,224 ms 1,169 ms 1,046 ms HTMLfile Medelvärde 45,400 ms 48,633 ms 44,900 ms Varians 0,987 ms 28,150 ms 6,300 ms JSONP Polling Medelvärde 54,100 ms 62,733 ms 12953,733 ms Varians 6,446 ms 6,718 ms 5120,360 ms XHR Polling Medelvärde 13,667 ms 19,533 ms 16406,367 ms Varians 1,135 ms 3,222 ms 2437,182 ms Tabell 4: Responstid för realtidsteknologier på lokalt nätverk Realtidsteknologi 1 klient 5 klienter 10 klienter WebSockets Medelvärde 907,100 ms 983,200 ms 402,967 ms Varians 463,797 ms 747,678 ms 187,817 ms XHR Polling Medelvärde 417,333 ms 2403,733 ms 15502,233 ms Varians 186,202 ms 2292,254 ms 3674,987 ms JSONP Polling Medelvärde 511,733 ms 463,500 ms 16128,553 ms Varians 172,150 ms 202,321 ms 4616,664 ms HTMLfile Medelvärde - - - Varians - - - Tabell 5: Responstid för realtidsteknologier på 3G- nätverk Figur 4: Bandbredd på 3G-uppkopplingen vid utförda experiment 21

5. ANALYS I detta avsnitt redogörs de analyser som gjorts utifrån den empiri som uppnåtts. 5.1. TRAFIKMÄNGD För administratörsgränssnittet, vilket bara används av en klient, skiljer sig trafikmängden inte nämnvärt mellan HTMLfile, XHR Polling och JSONP Polling. Däremot utmärker sig WebSockets från de andra realtidsteknologierna genom att endast använda 8,2 % av den totala trafikmängd HTMLfile använder, 7,8 % av den totala trafikmängd XHR Polling använder och 6,9 % av den totala trafikmängd JSONP Polling använder (se Tabell 4: Trafikmängd för administratörsgränssnittet). Detta trots att WebSockets använder störst mängd data till både meddelanden och i den overhead som återfinns i de skickade meddelandena för administratörsgränssnittet. Den för de övriga realtidsteknologierna avsevärt mycket större totala datamängd som används för administratörsgränssnittet återfinns till största delen i den headerdata som skickas med varje meddelande. Då administratörsgränssnittet endast används av en klient kommer denna skillnad mellan de olika realtidsteknologierna vara konsekvent även om den beroende på vilken typ av webbläsarapplikation som implementeras kan förändras. Därför har trafikmängden som skickas med administratörsgränssnittet heller inte lika stor påverkan på servern som åskådargränssnitt har om dessa överstiger en klient. Gällande trafikmängd återfinns den största skillnaden mellan de olika realtidsteknologierna på åskådarsidan av webbläsarapplikationen i denna studie (se Diagram 1: Trafikmängd för ett åskådargränssnitt baserat på typ). 40000 TRAFIKMÄNGD I BYTES BASERAT PÅ TYP 35000 30000 25000 20000 15000 10000 5000 0 Meddelanden Overhead Headerbegäran Headersvar Total trafikmängd WebSockets HTMLfile JSONP Polling XHR Polling Diagram 1: Trafikmängd för ett åskådargränssnitt baserat på typ 22

Trafikmängden för åskådargränssnitt skiljer sig stort mellan de olika realtidsteknologierna. Detta främst p.g.a. att WebSockets inte belastar servern med någon headerdata utöver den gång när förbindelsen mellan server och klient skapas. Dels också p.g.a. att det när HTMLfile används inte skickas något fullständigt svar med både headersvar och meddelande på den headerbegäran som skickas från klient till server utan istället endast skickas partiella svar med meddelanden i skript-form från servern vilka skickas utan något headersvar. Detta ledde i de utförda experimenten till att HTMLfile skickade minst headerdata, följt av WebSockets, JSONP- och XHR Polling. Utmärkande för åskådargränssnitt är att WebSockets använder minst total datamängd, tätt följt av HTMLfile medan både JSONP- och XHR Polling använder nära 10 gånger så mycket total datamängd som de två förstnämnda. Den totala trafikmängden som skickats mellan servern och åskådargränssnitt är minst för WebSockets, något som dock hade varit annorlunda om HTMLfile hade använt lika lite overhead i meddelandena som WebSockets; 5,4 % istället för hela 44,8 %. Detta hade i sådana fall gjort att HTMLfile istället skulle använt minst total datamängd med över 500 bytes mindre än WebSockets. Den totala datamängd som skickas för meddelanden är för både WebSockets och HTMLfile betydligt större i förhållande till den headerdata som skickas medan förhållandet är det motsatta för JSONP- och XHR Polling. En liten notis värd att nämna gällande trafikmängd är att det vid användandet av XHR Polling inte förekommer någon overhead alls på de skickade meddelandena varken för administratörsgränssnittet eller för ett åskådargränssnitt medan det för alla de andra realtidsteknologierna förekommer overhead i meddelandena med varierande storlek vid användandet av minst ett av de två gränssnitten. 5.2. RESPONSTID Gällande responstid såg resultaten från experimenten liknande ut för både det lokala nätverket och 3G-nätverket undantaget att HTMLfile inte gick att använda när experimenten på 3G-nätverket skulle utföras varför det inte heller innefattas i diagrammet över detta. Responstiden, vilken Kirubashankar & Krishnamurthy (2012) menar är av yttersta vikt vid speciellt kritiska dataöverföringar, skiljer sig stort mellan de olika realtidsteknologierna först när klientantalet ökar. Betydelsen av en missad uppdatering av matchresultatet, vilken kan liknas vid en kritisk dataöverföring, gör att användarupplevelsen av webbläsarapplikationen är påverkad av responstiden. Det kan finnas användare som godtar en lång responstid medan andra användare vill ha så liten responstid som möjligt. Den kritiska faktorn i webbläsarapplikationen ligger därför i användarens eget tycke. Detta nämner Bo, Jie, Junliang & Xiangwu (2009) som menar att realtidskomponenten även är baserad på det kontext den återfinns i. Ingen bestämd tidsrymd inom vilken ett meddelande bör levereras från server till klient för att kunna namnges som ett matchresultat i realtid har angetts i denna studie. Dock är denna tidsrymd något som menas vara obefintlig i ett önskvärt scenario (ibid.), vilket betyder att ju mindre responstiden är desto bättre är scenariot. 23

RESPONSTID I MILLISEKUNDER FÖR LOKALT NÄTVERK 18000 16000 14000 12000 10000 8000 6000 4000 2000 0 1 klient 5 klienter 10 klienter WebSockets HTMLfile JSONP Polling XHR Polling Diagram 2: Responstid för lokalt nätverk RESPONSTID I MILLISEKUNDER FÖR 3G-NÄTVERK 18000 16000 14000 12000 10000 8000 6000 4000 2000 0 1 klient 5 klienter 10 klienter WebSockets JSONP Polling XHR Polling 24 Diagram 3: Responstid för 3G-nätverk Upp till 5 klienter är responstiden på det lokala nätverket under 65 millisekunder för samtliga realtidsteknologier, knappt märkbar för användaren av webbläsarapplikationen även om den finns där. Vid 10 klienter däremot ökar responstiden dramatiskt för både JSONP- och XHR Polling (se Diagram 2: Responstid för lokalt nätverk). Vad den stora ökningen i responstid för JSONP- och XHR Polling vid 10 klienter beror på är oklart.