I arbetet jämförs kommunikation i Ajax med kommunikation i Websockets som är en äldre respektive nyare teknik som används vid realtidsbaserade applikationer. Två applikationer skapas som används för att mäta bandbreddskonsumtion samt nätverksfördröjning beroende på parametrarna datastorlek och uppdateringsfrekvens, som i kombination förväntas påverka mätresultaten. Syftet är att hitta samband mellan parametrarna för att visa vid vilka typer av applikationer Websocket lönar sig bäst och därmed ge understöd för beslut om migration från den gamla tekniken Ajax till den nyare tekniken Websockets.Resultatet av arbetet visar att kommunikation med låg datastorlek per anrop leder till störst vinst med Websockets samt att Websockets oavsett datastorlek eller uppdateringsfrekvens är betydligt bättre än Ajax. För framtida arbete förväntas främst undersöka hur även antalet samtida uppkopplade användare kan påverka resultatet.

Arbetet ger en omfattande bakgrund till vilka problem som måste hanteras i utvecklandet av flerspelarspel som ska spelas över internet. Arbetet fokuserar främst på de problem som uppstår på grund av nätverksfördröjning och jitter. Olika tekniker presenteras för att hantera dessa problem men arbetet fokuserar på tekniken lokal fördröjning. Arbetet utvärderar om det går att anpassa den lokala fördröjningen mot att matcha nuvarande nätverksegenskaper utan att påverka spelarens spelupplevelse negativt. För att utveckla denna hypotes utvecklades ett utvärderingsspel som har använts i en dubbelblind kvantitativ undersökning där spelarens spelupplevelse utvärderades. Resultaten från den undersökning som genomfördes var att dynamisk lokal fördröjning är att föredra då spel spelas över instabila nätverk som påverkas kraftigt av jitter.

With the development of the Internet, new network services with strict network latency requirements have been made possible. These services are implemented as distributed systems deployed across multiple geographical locations. To provide low response time, these services require knowledge about the current network latency. Unfortunately, network latency among geo-distributed sites often change, thus distributed services rely on continuous network latency measurements. One goal of such measurements is to differentiate between momentary latency spikes from relatively long-term latency changes. The differentiation is achieved through statistical processing of the collected samples. This approach of high-frequency network latency measurements has high overhead, slow to identify network latency changes and lacks accuracy. We propose a novel approach for network latency estimation by correlating network paths to network latency. We demonstrate that network latency can be accurately estimated by first measuring and identifying the network path used and then fetching the expected latency for that network path based on previous set of measurements. Based on these principles, we introduce Sudan traceroute, a network latency estimation tool. Sudan traceroute can be used to both reduce the latency estimation time as well as to reduce the overhead of network path measurements. Sudan traceroute uses an improved path detection mechanism that sends only a few carefully selected probes in order to identify the current network path. We have developed and evaluated Sudan traceroute in a test environment and evaluated the feasibility of Sudan traceroute on real-world networks using Amazon EC2. Using Sudan traceroute we have shortened the time it takes for hosts to identify network latency level changes compared to existing approaches. / Med utvecklingen av Internet har nya nätverkstjänster med strikta fördröjningskrav möjliggjorts. Dessa tjänster är implementerade som distribuerade system spridda över flera geografiska platser. För att tillgodose låg svarstid kräver dessa tjänster kunskap om svarstiden i det nuvarande nätverket. Tyvärr ändras ofta nätverksfördröjningen bland geodistribuerade webbplatser, således är distribuerade tjänster beroende av kontinuerliga mätvärden för nätverksfördröjning. Ett mål med sådana mätningar är att skilja mellan momenta ökade svarstider från relativt långsiktiga förändringar av svarstiden. Differentieringen uppnås genom statistisk bearbetning av de samlade mätningarna. Denna högfrekventa insamling av mätningar av nätverksfördröjningen har höga overheadkostnader, identifierar ändringar långsamt och saknar noggrannhet. Vi föreslår ett nytt tillvägagångssätt för beräkningen av nätverksfördröjning genom att korrelera nätverksvägar till nätverksfördröjning. Vi visar att nätverksfördröjningen kan vara exakt uppskattad genom att man först mäter och identifierar den nätverksväg som används och sedan hämtar den förväntade fördröjningen för den nätverksvägen baserad på en tidigare uppsättning av mätningar. Baserat på dessa principer introducerar vi Sudan traceroute, ett Verktyg för att uppskatta nätverksfördröjning. Sudan traceroute kan användas för att både minska tiden att uppskatta fördröjningen samt att minska overhead för mätningarna i nätverket. Sudan traceroute använder en förbättrad vägdetekteringsmekanism som bara skickar några försiktigt valda prober för att identifiera den aktuella vägen i nätverket. Vi har utvecklat och utvärderat Sudan traceroute i en testmiljö och utvärderade genomförbarheten av Sudan traceroute i verkliga nätverk med hjälp av Amazon EC2. Med hjälp av Sudan traceroute har vi förkortat den tid det tar för värdar att identifiera nätverksfördröjnings förändringar jämfört med befintliga tillvägagångssätt.

A bilateral teleoperation system makes it possible for a human operator to interact with a remote environment and receive feedback from their actions. In this work, two different teleoperation architectures are studied, one well-established approach called position-force, and another approach called Model-Mediated Teleoperation (MMT). Position-force generates force feedback by measuring forces and sending them over the network, subject to network delay, while MMT generates nondelayed force feedback through a local environment model. The two architectures are compared in terms of transparency (quality of force feedback) and state consistency (equivalence of positions) under different network conditions. Up to 150 ms constant delay in Round Trip Time (RTT) is added. Both architectures are implemented as relatively simple versions of themselves. The case (teleoperation task) under consideration is pushing a cuboid object on a planar surface in a single direction. The MMT architecture is also studied in further detail, in terms of model complexity. Two versions of an MMT model are investigated, one simpler model that has a linear representation of energy loss and one less simple model that has a non-linear representation of energy loss. The purpose is to see what implications there are of increasing or decreasing model complexity. The results indicate that position-force has better performance in terms of both transparency and state consistency than both MMT models for all investigated network conditions. The simple version of MMT (linear model) performs better than the non-linear model, in terms of transparency and state consistency of cuboid positions, for all network conditions except the largest added delay. In terms of state consistency for the device positions, the non-linear model only performs better than the linear model with no added delay. / En distansstyrt system med tvåsidig kommunikation gör det möjligt för en mänsklig operatör att interragera med en avlägsen miljö och få återkoppling. I detta arbete studeras två olika arkitekturer för dessa typer av system. Ett väletablerat tillvägagångssätt som kallas position-force, och ett annat som kallas Model-Mediated Teleoperation (MMT). Position-force genererar kraftåterkoppling genom att mäta krafter och skicka dem över nätverket, utsatt för nätverksfördröjningar, medan MMT genererar en icke-fördröjd kraftåterkoppling från en lokalt modellerad miljö. De två arkitekturerna jämförs med avseende på ”transparency” (kvalitén på kraftåterkopplingen) och ”state consistency” (matchning av positioner) under olika nätverksförhållanden. De studerade förhållandena innefattar upp till 150 ms konstant fördröjning i tur och returtid. Båda arkitekturer implementeras som förhållandevis enkla versioner av sig själva. Det studerade fallet (operatörens uppgift) innefattar puttande på ett rätblock på en plan yta i en enkel riktning. MMT arkitekturen studeras även i vidare detalj med avseende på komplexitet hos den lokala modellen. Två versioner av MMT modellen undersöks, en enklare model som har en linjär representation av energiförlust, och en mer avancerad model som har en icke-linjär representation av energiförlust. Avsikten bakom detta är undersöka vilka implikationer som finns när komplexiteten hos modellen höjs eller sänks. Resultaten indikerar att position-force presterar bättre än MMT med avseende på både transparency och state consistency för alla undersökta nätverksfördröjningar. Den linjära MMT modellen presterar bättre än den icke-linjära modellen, med avseende på transparency och state consistency i rätblockspositioner, för alla nätverksförhållnaden utom den största pålagda fördröjningen. Vidare presterar den icke-linjära modellen bättre än den linjära modellen, med avseende på state consistency för styrande/styrd apparat, endast då ingen nätverksfördröjning läggs på.

With increasing access to interconnected IP networks, people demand a faster response time from Internet services. Traffic from web browsing, the second most popular service, is particularly time-sensitive. This demands reliability and a guarantee of delivery with a good quality of service from ISPs. Additionally, the majority of the population do not have the technical background to monitor the delay themselves from their home networks, and their ISPs do not have a vantage point to monitor and diagnose network problems from the users’ perspective. Hence, the aim for this research was to characterise the “in-protocol” network delay encountered during web browsing from within a LAN. This research presents TCP traffic monitoring performed on a client device as well as TCP traffic monitoring over both the client-end and the server-end devices separately observing an automated web client/server communication. This was followed by offline analysis of the captured traces where each TCP flow was dissected into: handshake, data transfer, and teardown phases. The aim behind such extraction was to enable characterisation of network round-trip delay as well as network physical delay, end host processing delay, web transfer delay, and packets lost as perceived by the end hosts during data transfer. The outcome of measuring from both end devices showed that monitoring from both ends of a client/server communication results to a more accurate measurement of the genuine delay encountered when packets traverse the network than when measuring from the client-end only. Primarily, this was concluded through the ability to distinguish between the pure network delay and the kernel processing delay experienced during the TCP handshake and teardown. Secondly, it was confirmed that the two RTTs identified in a TCP handshake are not symmetrical and that a TCP teardown RTT takes longer than the TCP handshake RTT within the same TCP flow since a server must take measures to avoid SYN flooding attacks. Thirdly, by monitoring from both end devices, it was possible to identify routing path asymmetries by calculating the physical one-way delay a packet using the forward path in comparison to the physical delay of a packet using the reverse path. Lastly, by monitoring from both end devices, it is possible to distinguish between a packet that was actually lost and a packet that arrived with a higher delay than its subsequent packet during data transfer. Furthermore, utilizing TCP flows to measure the RTT delay excluding end host processing gave a better characterisation of the RTT delay as opposed to using ICMP traffic. / Med ökande tillgång till den sammankopplade IP-nätet, krävs det en snabbare responstid från Internettjänster. Trafik från surfning, den näst mest populära tjänsten är särskilt tidskänsliga. Detta kräver tillförlitlighet och en garanti för data leverans med en god servicekvalitet från Internetleverantörer. Dessutom har de flesta av befolkningen inte den tekniska bakgrunden för att övervaka fördröjning sig från sina hemmanätverk, och deras Internetleverantörer har ingen utsiktspunkt för att övervaka och diagnostisera nätverksproblem från användarnas perspektiv. Därför syftet med denna forskning är att karakterisera “in-protokoll”  fördöljingen i nätet, som påträffas under surfning inifrån ett LAN. Denna forskning visar TCP-trafik monitoring som utförs på en klientenhet, samt separat TCP-trafik monitoring över både klient-end och serve-end enheter, för att observera en automatiserad webbklient / server-kommunikation. Detta följs av offline analys av de infångade tracer där varje TCP flöde dissekerades in: handskakning, dataöverföring, och nedkoppling faser. Syftet bakom sådan utvinning är att möjliggöra karakterisering av nätverk fördröjning samt nätverkets fysiska fördröjning, behandlingsfördröjning, webböverföringsfördröjning och förlorade paket som uppfattas av end-device under dataöverföring. The outcome of measuring from both end devices showed that monitoring from both ends of a client/server communication results to a more accurate measurement of the genuine delay encountered when packets traverse the network than when measuring from the client-end only. Primarily, this was concluded through the ability to distinguish between the pure network delay and the kernel processing delay experienced during the TCP handshake and teardown. Secondly, it was confirmed that the two RTTs identified in a TCP handshake are not symmetrical and that a TCP teardown RTT takes longer than the TCP handshake RTT within the same TCP flow since a server must take measures to avoid SYN flooding attacks. Thirdly, by monitoring from both end devices, it was possible to identify routing path asymmetries by calculating the physical one-way delay a packet using the forward path in comparison to the physical delay of a packet using the reverse path. Lastly, by monitoring from both end devices, it is possible to distinguish between a packet that was actually lost and a packet that arrived with a higher delay than its subsequent packet during data transfer. Furthermore, utilizing TCP flows to measure the RTT delay excluding end host processing gave a better characterisation of the RTT delay as opposed to using ICMP traffic. Resultatet av mätningarna från både slut-enheter visar att övervakning från båda ändar av en klient / server-kommunikation resulterar  en noggrannare mätning av fördröjningar som uppstår när paketen färdas över nätverket än vid mätning från den enda klienten. Främst avslutades detta genom förmågan att skilja mellan den rena nätfördröjningen och kernel bearbetning under TCP handskakning och nedkoppling. För det andra bekräftades att de två RTT som identifierats i en TCP handskakning inte är symmetriska och att TCP nedkoppling RTT är längre än TCP handskakning RTT inom samma TCP flödet, eftersom servern  måste vidta åtgärder för att undvika SYN översvämning attacker. För det tredje, genom att övervaka från båda avancerade enheter, var det möjligt att identifiera path asymmetrier genom att beräkna den fysiska envägsfördröjningen av ett paket på framåtriktade banan i jämförelse med den fysiska fördröjningen för ett paket på den omvända banan. Slutligen genom att övervaka från båda end enheter, är det möjligt att skilja mellan ett paket som faktiskt förlorades och ett paket som kom med en högre fördröjning än dess efterföljande paket under dataöverföring. Dessutom utnyttjande av TCP flöden för att mäta RTT exkluderat end-nod porocessering gav en bättre karakterisering av RTT fördröjning jämfört med att ICMP-trafik.