Klient-server och Peer-to- Peer applikationer

(1)

Examensarbete

Klient-server och

Peer-to-Peer applikationer

En prestandajämförelse

Författare: Jesper Tullberg, Simon Jonsson Handledare: Daniel Toll

(2)

Abstrakt

Allt fler applikationer blir på ett eller annat sätt nätverksbaserade i dag. Den

traditionella arkitekturen för nätverk är den som kallas för klient-server, men i takt med att användandet av nerladdningstjänster ökar, ökar även Peer-to-Peer arkitekturen. Denna rapport är en jämförelse mellan Peer-to-Peer och klient-server modellerna som kan ligga som grund då ett val mellan dem ska tas. I rapporten jämförs prestanda mellan de olika arkitekturerna i olika sammanhang. Vår utgångspunkt är en generell

implementation av de båda arkitekturerna i ett test som bygger på en tidigare uppsats. Därefter mäter vi hur de olika arkitekturerna presterar i en spelkontext där

kommunikationen sker på ett för spel anpassat sätt. På detta vis försöker vi ge läsare en så objektiv och informativ bild av de olika arkitekturerna som möjligt. De test som utförts visar på en annan bild än den allmänna uppfattningen, som är att klient-server är den föredragna modellen.

Nyckelord

nätverk, klient-server, p2p-nätverk, prestanda, Java

Abstract

An increasing number of applications are becoming more or less network based today. The traditional architecture for network based applications is client-server, but as usage of download services are going up, so is the Peer-to-Peer architecture. This report is a comparison between the Peer-to-Peer and client-server model, and can serve as a basis when a decision between them needs to be taken. In the report, the performance between the different architectures is compared in different contexts. Our basis is a general implementation of both architectures in a test that is derived from a previous report. On top of this, the performance of the different architectures are measured, implemented in a gaming-context. This way, we are trying to give the reader as an objective and informative picture of the different architectures as possible. The tests that have been done shows a different situation than that of the general view, which is that client-server is the preferred model.

Keywords

(3)

Förord

(4)

Innehållsförteckning

1. Introduktion...1 1.1 Syfte...1 1.2 Tidigare forskning...1 1.3 Problemformulering...1 1.4 Avgränsning/Begränsning...2 1.5 Målgrupp...2 1.6 Disposition...2 2. Bakgrund/teori...3 2.1 TCP/IP...3 2.2 UDP...3 2.3 Klient-server arkitektur...3 2.4 P2P-arkitektur...4 2.5 Nätverkskommunikation...5 2.5.1 Unicast...5 2.5.2 Broadcast...5 2.5.3 Multicast...5 3. Metod...6 3.1 Vetenskaplig ansats...6 3.2 Metodbeskrivning...6 3.2.1 Uppskalning av datamängd...6

3.2.2 Uppskalning av antal klienter - spelkommunikation...8

3.3 Metoddiskussion...9

3.3.1 UDP vs. TCP...9

3.3.2 Casting...10

3.3.3 Non- and blocking IO...10

3.3.4 Streams...10

3.3.5 Uppskalning av arkitektur...11

3.4 Etiska och samhälleliga överväganden...11

4. Resultat/Empiri...13

4.1...13

4.1.1 Uppskalning av datamängd...13

4.1.2 Uppskalning av antalet klienter...19

4.1.3 Över Internet...23

5. Analys...25

5.1 Uppskalning av datamängd, medelvärde...25

5.2 Uppskalning av datamängd, minvärde...25

5.3 Uppskalning av datamängd, standardavvikelse...26

5.4 Uppskalning av antalet klienter, medelvärde...27

5.5 Uppskalning av antalet klienter, minvärde...27

5.6 Uppskalning av antalet klienter, standardavvikelse...28

5.7 Test över Internet...28

5.8 Uppskalning av antalet klienter (2 klienter) mot 1kB dataöverföring...28

6. Diskussion...29

7. Avslutning...30

7.1 Slutsats...30

7.2 Förslag till fortsatt forskning...30

Referenser...31

(5)

(6)

1. Introduktion

I och med att fildelningens utbredning ökar, blir användningen av User Datagram Protocol (UDP), och Peer-to-Peer (P2P), allt vanligare [1][2]. 2009 stod P2P för 40-70% av all trafik på Internet [3]. I USA stod endast BitTorrent1_{, som är ett protokoll som} bygger på P2P, för mer än 30% av trafiken [3]. Jämförelsevis stod den trafik som gick via webbläsare för drygt 20% av den totala Internet trafiken [3].

Vi har studerat sex artiklar och forumtrådar på Internet där P2P och klient-server diskuteras, samt där utvecklare och andra intresserade uttrycker sina åsikter [Appendix A]. Generellt verkar det som att den stora majoriteten förespråkar att använda klient-server arkitekturen då den är effektivare och säkrare, med den enda nackdelen att den för med sig kostnader för underhåll av servrar. Det är dock svårare att hitta

vetenskapliga artiklar som styrker eller dementerar dessa åsikter.

Då statistiken i [3] indikerar att UDP och P2P är de mest använda teknikerna, medan det största intresset hos utvecklarna verkar ligga på TCP och klient-server modellen, anser vi det vara intressant att ta reda på hur de olika modellerna skiljer sig åt och hur de presterar i jämförelse med varandra. En annan viktig aspekt är säkerheten i de olika arkitekturerna, något som dock lämnas till framtida forskning då det är utanför ramen av vad denna rapport behandlar.

1.1 Syfte

Syftet med detta arbete är att presentera empiriska mätdata för att kunna ge en objektiv bild av de två arkitekturernas prestanda samt att resultatet ska ge upphov till nya

frågeställningar. Vi hoppas också att läsaren av rapporten ska få en bättre bild av hur de olika modellerna skiljer sig åt och när det lämpar sig att använda den ena eller andra arkitekturen.

1.2 Tidigare forskning

Det har bedrivits en hel del forskning inom området tidigare [18][19]. Denna forskning har tyvärr oftast varit väldigt specifik [18][19], vilket gör att den har väldigt lite att säga om hur de olika arkitekturerna beter sig i grunden, vilket gör den irrelevant för denna rapport.

Rapporten bygger dock delvis på den forskning som tidigare utförts av Johan Furberg och Johan Ölund i rapporten “Generella Peer-2-Peer plattformar” där de “undersöker om generella P2P-plattformar är ett alternativ till den traditionella klient-server modellen” [4]. Deras rapport innehåller test som kan återskapas för att möjliggöra ett jämförande av resultat.

1.3 Problemformulering

Hur skalar överföringstiden hos en P2P jämfört med en klient-server nätverksarkitektur är den genomgripande frågande, som är uppdelad i tre delfrågor. Frågeställningarna formulerades för att ge en i största mån kompletterande bild av arkitekturerna.

Delfråga 1. Hur skalar överföringstiden beroende på datamängd?

H0 - Överföringstiden mellan klient-server och P2P skiljer inte mellan varandra beroende på datamängd.

HA - Överföringstiden stiger kraftigare med en P2P arkitektur än en klient-server arkitektur då datamängden ökar.

Delfråga 2. Hur skalar överföringstiden beroende på antal klienter?

H0 - Överföringstiden mellan klient-server och P2P skiljer inte mellan varandra beroende på antal klienter.

(7)

H2A - Överföringstiden då data skickas mellan klienter ökar inte lika snabbt med en klient-server arkitektur som med en P2P arkitektur då antalet

uppkopplade klienter i nätverket ökar.

Delfråga 3. Hur påverkar Internet överföringshastigheten?

H0 - Överföringstiden då data skickas över Internet skiljer inte från överföringstiden när data skickas över LAN.

H3A - Överföringstiden då data skickas över Internet blir längre än överföringstiden för när data skickas över LAN.

1.4 Avgränsning/Begränsning

Metoden i rapporten begränsar sig till endast fem klienter, då det inte fanns fler datorer att tillgå. Denna rapport är även begränsad till att bara använda programmeringsspråket Java. Hårdvaran är begränsad till ett nätverk på 1Gb/s.

1.5 Målgrupp

Målgruppen utgörs av utvecklare som är intresserade av att utveckla

nätverksapplikationer. Testresultaten kommer vara mest värdefulla för spelutvecklare men resultatet bör även vara intressant för utvecklare inom andra områden som kan dra nytta av en bättre förståelse för de två nätverksarkitekturerna som rapporten berör. En av dessa grupper skulle till exempel kunna vara utvecklare av nedladdningstjänster.

1.6 Disposition

(8)

2. Bakgrund/teori

Ett datornätverk är telekommunikationsnätverk som tillåter datorer att utbyta data med varandra. Datorerna använder kabel- eller trådlösa uppkopplingar för att skicka datan mellan varandra.

2.1 TCP/IP

TCP/IP består av flera dussin protokoll, men endast ett par av dem utgör

huvudprotokollen, vilka är de som anses vara mest viktiga. Dessa två protokoll är IP, Internet Protocol, som tillhandahåller adressering, och TCP, Transmission Control Protocol, som ansvarar för att etablera och upprätthålla uppkopplingar samt att data transporteras pålitligt mellan olika mjukvaruprocesser. Två andra välkända protokoll som är en del av TCP/IP är HTTP, Hypertext Transfer Protocol, och FTP, File Transfer Protocol [5].

Internet är en av de stora anledningarna till varför TCP/IP ser ut som det gör idag. TCP/IP och Internet utvecklades tillsammans och TCP/IP tillhandahöll mekanismen för att implementera Internet. TCP/IP har utvecklats och anpassats för att möta de

förändrade kraven från Internet och andra mindre nätverk [5].

TCP/IP är uppbyggt med flera lager av tjänster som stöttar varandra med olika funktionalitet. I den första gruppen av tjänster finns funktionaliteten som de

huvudsakliga TCP/IP protokollen implementerar, som TCP, IP och UDP. Den andra gruppen omfattar tjänster för slutanvändare. Denna grupp omfattar bl.a. WWW och HTTP [5].

2.2 UDP

Det finns ett andra överföringsprotokoll i TCP/IP protokollen som heter UDP; User Datagram Protocol. Även om TCP är allmänt ansett viktigare och mer användbart har UDP sitt användningsområde då prestanda är att föredra över pålitlighet [5].

Då TCP/IP utvecklades insåg utvecklarna att de protokollen medförde en hel del prestandakostnader relaterade till övervakning av att paket kommer fram och att de kommer fram i rätt ordning. Även om funktionaliteten kan vara användbar, inte alltid är önskvärd. Svaret var att separera protokollet till IP och TCP. Det möjliggjorde

skapandet av ett andra överföringsprotokoll, UDP. De två attribut som oftast förknippas med UDP är snabbhet och enkelhet. Precis som TCP så ligger UDP som ett lager med överföringsprotokoll över IP, men utöver dataöverföring tillhandahåller UDP ingen övrig funktionalitet, med undantag för checksum [5].

UDP är snabbt just för att det saknar mycket av TCPs funktionalitet och detta gör protokollet oanvändbart i många fall. Men i vissa situationer är det exakt vad som behövs och protokollet används flitigt inom vissa områden, som till exempel fler-spelar spel med mera [5].

2.3 Klient-server arkitektur

Då en del av metoden utgår från spel, förklaras de olika nätverksarkitekturerna ur synvinkel från hur de vanligtvis implementeras i ett flerspelar-spel.

Den vedertagna arkitekturen för nätverk och spel i synnerhet är klient-server

(9)

emot den behandlade informationen om andra klienters, och sina egna, handlingar och utifrån denna data uppdatera den lokala klienten [6].

Då en server normalt sett endast hinner uppdateras ett fåtal gånger per sekund medan klienten uppdateras betydligt oftare uppstår ett, för det mesta, synligt problem; nämligen att spelare och övriga föremål rör sig i stora intervaller vilket skapar en hackig

förflyttning istället för en mer flytande rörelse. För att undvika detta problem har utvecklare därför infört något som kallas “dead reckoning”, vilket innebär att spelet, utifrån klientens senaste handlingar, försöker förutsäga dess nästa position. Nyckeln till denna teknik är att förutsäga med så bra precision som möjligt för att minimera

skillnaden mellan datan på servern och klienterna. Därav blir korrigeringarna från servern oftast mycket mindre och således inte märkbara för spelarna [6].

Det finns vissa fördelar med en klient-server arkitektur. En av dessa är att de har väldigt bra skalbarhet då antal spelare ökar. Detta tack vare att kommunikationen enbart ökar linjärt för servern och förblir konstant för klienten. I övrigt belastas inte klienten med komplex funktionalitet som kan dra ner prestandan och fler ansvarsområden kan hanteras av servern. Till exempel behöver inte klienten utföra, eller ha tillgång till information som berör, fysikberäkningar då detta sker på servern. Resultatet av detta är att mjukvaru-uppdateringar inte alltid behöver skickas till klienten, utan det räcker med att uppdatera servern [7].

2.4 P2P-arkitektur

En P2P arkitektur kännetecknas av att alla klienter kommunicerar direkt med varandra [8][9], istället för via en central enhet som i klient-server arkitekturen. Modellen är mest känd inom BitTorrent, där det inte krävs någon nedladdningsserver [10].

I jämförelse med klient-server arkitekturen måste därför en klient, när den uppdaterar sin data, alltid skicka denna information till alla anslutna klienter för att upplysa dessa om sin nuvarande status. Den mottagna datan hanteras därefter som om det vore ett lokalt spel [8][9].

P2P innehar vissa nackdelar på grund av dess struktur. Då klienter tar emot all data och tolkar den lokalt innebär det att spelsessioner på varje klient kan utspela sig något olika då dessa inte alltid är helt synkroniserade. För att undvika att spelet inte förlorar synkronisering kan en teknik användas där systemet väntar på att alla spelares drag är mottagna innan någonting görs. Detta innebär dock att varje spelares latency (tiden mellan förfrågan och svaret) alltid kommer vara samma som den spelare med sämst nätverksanslutning [8][9].

Som tidigare nämnt ökar antalet anslutningar i en klient-server modellen linjärt medan P2P-arkitekturen istället ökar i en mycket hög takt, då alla klienter skickar anrop till alla andra klienter, vilket kännetecknas av att varje klient har n-1 antal

uppkopplingar [8].

En av de största svårigheterna med P2P-arkitekturen är att förhindra spelarna från att fuska. Eftersom logiken och datan delas upp mellan klienterna, istället för att behandlas av en central enhet, öppnas möjligheten för manipulering samt att det blir svårt att validera att spelaren följer domänens regler [12].

Värt att nämna är att den vanligaste varianten av P2P nätverk bygger på att en klient skickar små förfrågningar till flera andra klienter som alla svarar med delar av den totala datan [13], vilket den anropande klienten sedan kombinerar. Fildelningsklienten

(10)

2.5 Nätverkskommunikation

UDP och TCP tillhandahåller olika typer av kommunikation, men UDP protokollet ger användaren fler valmöjligheter än TCP. Båda protokollen har den typ av kommunikation som kallas för Unicast, medan endast UDP tillhandahåller Unicast och Broadcast [11].

2.5.1 Unicast

Unicast är den form av kommunikation som används för att skicka information från en punkt till en annan. I denna modell finns det bara en avsändare och en mottagare. Detta är den vanligaste formen av kommunikation på LAN och över Internet. Alla LAN och IP nätverk stödjer Unicast via applikationer som till exempel HTTP, SMTP, Simple Mail Transfer Protocol, FTP och Telnet (nätverksprotokoll för textbaserad kommunikation), vilka alla använder TCP protokollet [11].

2.5.2 Broadcast

Broadcast är den form av kommunikation som används för att skicka information från en punkt till alla andra punkter. Det finns bara en avsändare men informationen går fram till alla uppkopplade mottagare. Broadcast stöds på de flesta LAN, Local Area Network, till exempel ethernet, och kan användas för att skicka samma meddelande till alla datorer i LAN:et. IPv4 stödjer också en form av broadcast som tillåter att samma paket skickas till alla mottagare i ett logiskt nätverk [11].

2.5.3 Multicast

Multicast är den form av kommunikation som används för att skicka information från en eller flera punkter till en bestämd grupp med punkter [11]. Multicast är en lovande teknik men inte användbar i dagens läge då det krävs att klienterna använder IPv6, vilket den stora majoriteten inte gör. Det finns även implementerat i IPv4, men är oftast inte påslaget, vilket visade sig då de första testen skulle köras över Internet och inte fungerade [16].

Ett exempel på en applikation som kan använda multicast är en video server som skickar ut TV kanaler över ett nätverk. Simultan leverans av högkvalitets video till ett stort antal plattformar uttömmer snabbt även en server med hög bandbredd. Detta gör skalbarheten mindre om applikationen kräver upprätthållande av hög bandbredd. Ett sätt att göra sådana applikationer skalbara är att använda nätverk med multicast [11].

(11)

3. Metod

Metoden utgörs i huvudsak av att jämföra två olika nätverksapplikationer i olika

användningsscenarier. Den ena implementerar en klient-server arkitektur och den andra implementerar en P2P arkitektur.

För att svara på den första delfrågan “Hur skalar överföringstiden beroende på datastorlek?” mäts överföringstiden för olika datamängder mellan två klienter, se stycke 3.3.1. Angående frågan “Hur skalar överföringstiden beroende på antal klienter?” mäts istället överföringstiden för olika antal klienter fast med en konstant mängd data, se stycke 3.3.2. För att testa frågan “Hur påverkar Internet överföringshastigheten?” används samma implementation som i stycke 3.3.2. Skillnaden är däremot att testen körs över Internet och endast mellan två klienter.

Applikationernas huvudsakliga syfte är att skicka information över respektive nätverk under olika omständigheter och mäta tiden det tar för informationen att komma fram. Metoden utformades för att vara relevant för både ett spelscenario samt scenariot ur [4]. De två implementationerna har utvecklats agilt och både testens genomförande och implementation har ändrats flera gånger då nya krav och fakta har framkommit, vilket förhoppningsvis ökar resultatets validitet.

Utöver att återskapa metoden från [4], vill vi utöka den då det finns vissa

implementationsspecifika detaljer i den tidigare metoden som sänker trovärdigheten av resultatet något. Till exempel används endast två datorer (klienter) som är

sammankopplade direkt med varandra, vilket kan anses vara ett orealistiskt scenario, då datorer oftast kopplas ihop via LAN eller Internet.

3.1 Vetenskaplig ansats

Metoden använder sig av en kvantitativ ansats för att testa frågeställningen. Vad detta innebär är att applikationerna i metoden utformas för att generera en stor mängd data som sedan samlas in, analyseras och tolkas.

3.2 Metodbeskrivning

I detta avsnitt beskrivs metoden i sin helhet.

3.2.1 Uppskalning av datamängd

Testens arbetsgång är väldigt liknande i detta initiala test. Den stora skillnaden är att P2P applikationen inte behöver gå via en server för att skicka data från en klient till en annan. Detta minskar värdet av resultatet något, då det till stor del går att förutse utfallet, men det är ändå intressant att se hur stora skillnaderna är och hur de olika applikationerna skalar.

Då denna metod baseras på samma metod som i [4] används sex olika datamängder. Dessa redovisas i tabell 3.1. Ur [4] används enbart värdena för implementationen med Java Socket. Dessa värden varierar från 1B till 10MB och bör ge en god indikation om hur respektive arkitektur presterar i både små och större datamängder.

Storlek 1B 1kB 10kB 100kB 1MB 10MB

Antal test 1000 1000 1000 1000 1000 100

Tabell 3.1 - Testfall för uppskalning av datamängd.

(12)

sedan all kommunikation mellan dessa två. En eko-server kan köras i två lägen, det ena som en fristående server, vilket sker med P2P, och den andra som en klient som kan ansluta till en server. Eko-serverns enda uppgift är att ta emot alla paket som den får och sedan returnera dessa till avsändaren, vilket gör både den och servern till “dumma”.

3.2.1.1 Klient-server

Bild 3.1 - Klient-server, uppskalning av datamängd. Visar dataflödet i metod.

Testet inleds med att en klient samt en eko-server ansluter till en server. Den mängd data som ska testas genereras och testet körs angivet många gånger. Då testet är klart finns tiderna för varje körning loggade.

När en körning av testet startas startar klienten timern och skickar sedan den

genererade datan till servern, som sedan vidarefodrar den till den anslutna eko-servern. Eko-servern tar emot datan och returnerar den dit den kom från. Servern tar emot datan och skickar den vidare till klienten, som tar emot datan och stoppar timern och loggar tiden till en fil.

Värt att notera är att de moment som utförs mellan timern startas och stoppas endast involverar dataöverföring och ingen annan prestandakostnad.

3.2.1.2 P2P

Bild 3.2 - P2P, uppskalning av datamängd. Visar dataflöde i metod.

Testet inleds med att en eko-klient ansluter i P2P-läge. Efter det ansluter en klient till denna. Den mängd data som ska testas genereras. och testet körs angivet många gånger. Då testet är klart finns tiderna för varje körning loggade.

När en körning av testet startas startar klienten timern och skickar sedan den genererade datan till eko-servern, som tar emot datan och returnerar den dit den kom från. Klienten tar emot datan och stoppar timern och loggar tiden till en fil.

3.2.1.3 Insamling och behandling av data

(13)

3.2.2 Uppskalning av antal klienter - spelkommunikation

Detta test syftar till att efterlikna hur ett spel kan hantera flerspelar-läge med en klient-server samt en P2P arkitektur. I en klient-klient-server arkitektur hanterar en centraliserad server all logik, som den sedan skickar ut till klienterna. Klienterna hanterar endast inmatning från användare och liknande. I en P2P arkitektur hanteras logiken lokalt i varje klient och denna logik måste sedan skickas till alla andra klienter, vilket ökar mängden data som skickas i takt med att antar klienter skalar. Det finns

implementationer som minimerar påverkan av detta, genom att köra simultana simuleringar på olika klienter, men det har vi inte tagit hänsyn till i detta test, då en implementation av en sådan simulering är mycket komplex och ökar risken för att fel uppstår. Antalet klienter begränsas till fem, både för att det saknas tillräckligt med hårdvara för att utöva ett sådant test, och för att det är ett intressant användningsscenarie för spel inom genren RTS, Real Time Strategy.

3.2.2.1 Klient-server

Bild 3.3 - Klient-server, uppskalning av antal klienter. Arkitektur.

Testet inleds med att en server startar. Efter detta ansluter minst två klienter. När server och alla klienter är anslutna, genereras 512B data. Testet körs angivet många gånger. Då testet är klart finns tiderna för varje körning loggade.

(14)

3.2.2.2 P2P

Bild 3.4 - P2P, uppskalning av antal klienter. Arkitektur.

Testet inleds med att en huvudklient ansluter. Efter det ansluter x antal vanliga klienter. När samtliga klienter är anslutna, genereras 512B data. Testet körs angivet många gånger. Då testet är klart finns tiderna för varje körning loggade.

Huvudklienten startar timern och ber klienterna skicka sin data genom att skicka ett startmeddelande till dem. Samtliga klienter skickar sin data till alla andra klienter vilket även gäller för huvudklienten som startade testet. Samtliga klienter inklusive

huvudklienten väntar tills de fått data från övriga klienter. Klienterna svarar sedan med ett slutmeddelande till huvudklienten. Huvudklienten väntar tills den mottagit

slutmeddelande från samtliga vanliga klienter och stoppar sedan timern.

3.2.2.3 Insamling och behandling av data

Den insamlade mätdatan sammanställs i kalkylark där sedan medel, median, min, max och standardavvikelse beräknas.

3.3 Metoddiskussion

Metoden anses hålla en relativt hög validitet då den dels bygger på en tidigare metod, samt att den har itererats fram över en längre period. Detta har möjliggjort en

kontinuerlig granskning och förbättring av metoden under dess utveckling.

3.3.1 UDP vs. TCP

Inledningsvis implementerades testapplikationerna med hjälp av UDP protokollet. En av anledningarna till detta var att P2P applikationer traditionellt bygger på detta protokoll samt att spel, som rapporten inledningsvis formulerades kring, oftast brukar det

protokollet. Utöver detta stödjer UDP, till skillnad från TCP, multicasting [11], vilket testen inledningsvis använde. Trots fördelarna med UDP togs beslutet slutligen att frångå det protokollet till fördel för TCP.

De nackdelar som TCP medför är ganska få, men en av dessa är att det oftast tar längre tid att skicka data över ett nätverk med TCP än det gör med UDP. Detta beror på att protokollet har en del funktionalitet som UDP saknar, vilket medför en del

(15)

kommer fram i rätt ordning, vilket UDP inte gör. Utöver detta kan data överföras som en ström, vilket innebär att datan inte behöver delas in i mindre paket. I UDP kan storleken på ett paket inte överstiga 65kB [17], vilket innebär att datan måste uppdelas manuellt.

Tack vare att ovan nämna problem kunde undvikas då TCP användes, blev

applikationernas implementation betydligt enklare vilket minimerade riskerna för fel i testen. Eftersom logiken bakom testen fortfarande var densamma påverkades inte validiteten av resultaten. Den enda skillnaden var att själva dataöverföringen

förmodligen tog något längre tid, vilket ansågs vara godkänt, då resultaten fortfarande var inbördes jämförbara eftersom de implementerade samma protokoll. Utöver detta använde de test som utförts [4] också TCP.

3.3.2 Casting

Inledningsvis, då UDP användes, implementerades applikationerna delvis med

Multicast, då den formen av kommunikation är mer effektiv än alternativen. I samband med att testen skrevs om med TCP, byttes även multicast ut mot unicast, eftersom TCP inte stödjer multicast. Detta gjorde applikationerna potentiellt långsammare, men gjorde även att testen blev mer jämförbara med tidigare utförda test. En annan anledning till varför multicasting var problematisk var att IPv4 inte stödjer det över Internet utan endast över LAN vilket skulle innebära att testen inte skulle ha någon praktisk betydelse i verkligheten, utöver för applikationer som endast kan köras på LAN.

3.3.3 Non- and blocking IO

Då Java tillhandahåller två olika implementationer av socket-kommunikation, var ett av de mer avgörande valen för testresultatens utfallande vilken implementation som skulle användas.

Standardimplementationen för input och output i Java arbetar med strömmar (till exempel byteströmmar) och är blockerande, vilket innebär att pågående ström måste jobba klart innan nästa kan påbörjas. Javas NIO (non-blocking IO) är däremot baserad på kanaler där data läses in och skrivs via buffertar. Detta innebär att NIO kan användas asynkront, vilket i sin tur innebär att det går att göra andra operationer medan data läses in. Till exempel går det att läsa in data från flera kanaler (flera klienter) samtidigt och behandla den efterhand. I den blockerande varianten går det att lösa detta genom att dela upp sin logik i olika trådar och därigenom läsa in inkommande data i varsin tråd. [14] [15]

Då det var svårt att få reda på vad som var mest relevant att använda skrevs det ett enkelt test där data skickades i en klient-server arkitektur (se spelkommunikation) över UDP-protokollet i de respektive implementationerna. Resultaten av dessa påvisade ett visst prestandaövertag för den blockerande varianten och därav föll även valet av implementation på detta. Utöver detta är en implementation med blockerande IO mindre komplex, vilket minimerar risken för felimplementationer vilket i sin tur skulle kunna påverka resultaten till att bli mindre pålitliga.

3.3.4 Streams

När implementations skrevs om till TCP ställdes frågan om hur data borde skickas. I Javas Socket-klass finns en ursprunglig funktion som läser och skriver till en byte-array. Att använda denna ger fördelen att eventuellt prestandakostnad från andra klasser inte införs, men skapar i gengäld mycket mer manuellt arbete eftersom data måste

(16)

Eftersom en egen implementation ändå leder till en viss overhead, togs beslutet att använda BufferedReader och BufferedWriter, från java.io.Reader biblioteket, istället då dessa tar hand om allt som annars skulle behövas implementeras manuellt. Utöver detta är det troligt att en riktig applikation skulle implementera dessa klasser, då de är väl testade och väl dokumenterade. Det som dock bör påpekas är att dessa

implementationer tolkar all data som text och därför införs en viss prestandakostnad för själva omvandlingen av data till text. Då detta är något som däremot är relativt linjärt och sker likadant på alla test påverkar detta inte testens inbördes jämförelse, eftersom det är en minimal prestandaförlust och att det ändå hade behövts att göras, fast manuellt.

När ett meddelande är överfört skickas det, med hjälp av BufferedWriter, ett avslutande tecken för att klargöra för mottagaren att meddelandet är slut. Detta tecken tar någon byte att överföra, vilket är jämförbart med att det hade behövts skickas över en integer eller liknande till mottagaren ändå, vilket innebär att testresultaten inte bör påverkas negativt. För att göra testresultaten så valida som möjligt har varje besluts övervägts noga, vilket förhoppningsvis minimerar att andra variabler, utöver de som testen byggs kring, påverkar testresultaten.

3.3.5 Uppskalning av arkitektur

Då testerna skulle utökas till att hantera fler klienter än två uppkom en del frågor, eftersom det inte skulle ge något mervärde att skala tidigare test med tanke på dess implementation. Beroende på hur testet skalades, påverkades även resultatet, vilket förutsågs ge mer eller mindre givna svar. Om testet gick ut på att en klient skickade till alla andra klienter skulle detta innebära att klient-server alltid skulle ha en given nackdel vid uppskalning, då all data skulle behöva gå via en server. Det var därmed ett stort problem att bestämma sig för hur data egentligen normalt flödar i ett nätverk byggt med en klient-server respektive en P2P arkitektur, för att på bästa möjliga sätt återspegla hur en applikation faktiskt skulle implementera respektive arkitektur.

Med tanke på att många applikationer körs samtidigt, sker normalt kommunikation sporadiskt och utan några direkta intervall. Kort sammanfattat går det att konstatera att det inte finns en bestämd specifikation på hur program ska sköta sin

nätverkskommunikation. Även antalet klienter som kommunicerar och hur många andra klienter dessa kommunicerar med varierar. Att enbart en klient skulle skicka data till alla andra på en och samma tidpunkt i ett nätverk sågs därmed som orealistiskt med tanke på föregående punkter. För att kunna göra ett någorlunda kontrollerat test togs därför beslutet att efterlikna hur ett spel implementerar nätverkskommunikation, då detta är relativt konsekvent i utförande för båda arkitekturerna.

3.4 Etiska och samhälleliga överväganden

I rapporten redovisas vad som observeras samt resultatet sanningsenligt. Detta uppnås genom att mätdata presenteras oförändrade och i sin helhet. Vidare diskuteras resultatet objektivt utan värderingar.

Det finns en del samhälleliga aspekter att ta ställning till i rapporten. Ur en

ekonomisk synpunkt kan valet av nätverksarkitektur skapa olika förutsättningar för ett företag eller en organisation Till exempel innebär en klient-server arkitektur att en central server måste underhållas, vilket för med sig en del kostnader.

Lagring av data bör beaktas ur ett socialt perspektiv med tanke på att informationen i en P2P arkitektur lagras på klienterna i nätverket. Detta kan medföra säkerhetsrisker och även risk för att känslig information läcker ut. I en klient-server arkitektur finns samma problem, fast då är det ägaren av servern som har tillgång till potentiellt känslig data.

(17)

beroende av det företag som tillhandahåller dessa servrar (om servern inte är intern i företaget). Därmed innebär en P2P arkitektur att kunderna/användarna har mer kontroll över nätverkets livslängd, då dessa i sin tur potentiellt kan använda programmet även efter skaparna inte längre är verksamma eller programmet inte längre underhålls.

Detta är aspekter som är viktiga att ha i åtanke både under valet och

(18)

4. Resultat/Empiri

Resultatet av metoden har mätts med hjälp av medianen, medelvärdet,

standardavvikelsen och variansen. För att göra dataurvalet så stort som möjligt har testen körts mellan 100 och 1000 gånger, vilket ökar validiteten på resultatet. Mätvärdena har noterats och sammanfattas i tabeller där det går att utläsa skillnader mellan de olika applikationerna för var test.

4.1 Resultatredovisning

Mätdata redovisas i form av tabeller med minvärde, maxvärde, medelvärde,

medianvärde och standardavvikelse. All mätdata redovisas i millisekunder om inte annat anges. Till varje tabell redovisas också ett boxlådediagram.

Det första testresultatet för dataöverföringstestet “uppskalning av datamängd” var mycket avvikande från det förväntade resultatet (att P2P skulle vara bättre i alla testen). Av denna anledning ansågs resultatet tvivelaktigt och testerna gjordes om. Resultaten från båda körningarna redovisas, men bara de senaste resultatet används i

boxlådediagramen.

Resultaten från den uppsats [4, s.48]som rapporten delvis bygger på är inkluderade i redovisningen. Detta för att underlätta jämförelse mellan de olika rapporternas resultat, då det test som heter “Uppskalning av datamängd” bygger på de test som finns i [4]. Dessa värden är märkta som “Master”, och är inte en produkt av denna rapports metod.

4.1.1 Uppskalning av datamängd

I detta avsnitt presenteras mätdatan från testen då datamängden skalades

4.1.1.1 1B dataöverföring

Mätvärden i millisekunder (1000 körningar) 1B

Datamängd 1B (P2P) 1B (P2P**) 1B (KS) 1B (KS**) 1B (Master*) Min 0,140452 0,310034 0,210184 0,477797 n/a Medelvärde 0,168236 0,366211 0,283096 0,601268 4 Median 0,156714 0,3638445 0,288381 0,5855995 n/a Max 0,370814 0,718312 0,710105 1,072826 n/a Standardavvikelse 0,032032 0,020588 0,040407 0,065849 n/a * Mätvärden i millisekunder från [4, s.48]

(19)

Bild 4.1 - Boxplot, 1B dataöverföring

Bild 4.1 visar att tiderna för klient-server applikationen har en större spridning och ett högre värde generellt, jämfört med P2P applikationen.

4.1.1.2 1kB dataöverföring

Mätvärden i millisekunder (1000 körningar) 1kB

Datamängd 1kB (P2P) 1kB (P2P**) 1kB (KS) 1kB (KS**) 1kB (Master*) Min 0,609304 0,611298 1,264505 1,114678 n/a Medelvärde 0,739768 0,758318 1,504647 1,440422 7 Median 0,7401755 0,74731 1,415367 1,4327215 n/a Max 0,985881 5,9008 85,263417 6,458987 n/a Standardavvikelse 0,042924 0,177086 2,652132 0,194962 n/a * Mätvärden i millisekunder från [4, s.48]

(20)

Bild 4.2 - Boxplot, 1kB dataöverföring

Bild 4.2 visar att tiderna för klient-server applikationen har en fortsatt större spridning och ett högre värde generellt, jämfört med P2P applikationen. Jämfört med bild 4.1 är skillnaderna mellan klient-server och P2P applikationerna större.

(21)

Bild 4.3 visar att tiderna för klient-server applikationen har en mindre spridning av resultatet än P2P applikationens tider, vilket skiljer sig från resultatet som redovisas i bild 4.1 och bild 4.2. Värdena är dock fortfarande generellt högre för klient-server applikationen.

(22)

Bild 4.4 visar på att tiderna för de båda applikationerna blir mer lika än tidigare mätningar. Klient-server applikationens tider är fortfarande högre, även om tiderna är mer lika mellan de två applikationerna än tidigare mätningar.

4.1.1.5 1MB dataöverföring

Mätvärden i millisekunder (1000 körningar) 1MB

Datamängd 1MB (P2P) 1MB (P2P**) 1MB (KS) 1MB (KS**) 1MB (Master*) Min 70,734420 161,554975 70,113068 97,65871 n/a Medelvärde 82,704118 185,071916 95,002352 140,743485 2285 Median 77,625759 184,0210145 95,9186495 142,4110415 n/a Max 151,252764 234,997464 171,056267 228,419577 n/a Standardavvikelse 18,184045 6,796429 17,063562 18,666786 n/a * Mätvärden i millisekunder från [4, s48]

(23)

Bild 4.5 - Boxplot, 1MB dataöverföring

Bild 4.5 visar på att tiderna för de båda applikationerna blir än mer lika. Dock finns det en större spridning på P2P applikationens tider än tidigare samtidigt som klient-server verkar ha en större mängd med utstickare.

4.1.1.6 10MB dataöverföring

Mätvärden i millisekunder (100 körningar) 10MB

Datamängd 10MB (P2P) 10MB (P2P**) 10MB (KS) 10MB (KS**) 10MB (Master*) Min 593,381162 1739,107197 1083,611168 1332,051813 n/a Medelvärde 829,534482 1809,230151 1219,619579 1610,943914 22662 Median 805,5942535 1808,4818775 1219,862901 1634,774218 n/a Max 1403,492503 1885,751954 1351,339013 1782,991641 n/a Standardavvikelse 107,622803 30,174936 56,826264 105,678908 n/a * Mätvärden i millisekunder från [4, s.48]

(24)

Bild 4.6 - Boxplot, 10MB dataöverföring

Av bild 4.6 går det att utläsa att P2P applikationens tider är lägre än klient-server applikationens. Dock är spridningen på värdena betydligt större.

4.1.2 Uppskalning av antalet klienter

I detta avsnitt presenteras mätdatan från testen då antal klienter skalades

4.1.2.1 Två klienter

Mätvärden i millisekunder (1000 körningar) 512B, 2 klienter

(25)

Bild 4.7 - Boxplot, 2 klienter

Bild 4.7 Visar en mindre skillnad i tiderna mellan P2P och klient-server applikationerna. P2P applikationens tider är något lägre dock.

4.1.2.2 Tre klienter

(26)

I bild 4.8 går det att se att applikationernas tider blir allt mer lika då antalet klienter ökar. Klient-server arkitekturen har en stor spridning i sina tider med ett antal avvikande resultat.

4.1.2.3 Fyra klienter

(27)

Tiderna i bild 4.9 är väldigt lika mellan de två applikationerna Klient-server

applikationens tider är dock marginellt högre fortfarande. Det går även att se att P2P har fler extrema värden gentemot klient-server.

4.1.2.4 Fem klienter

(28)

Tiderna i bild 4.10 påminner om tiderna i bild 4.9. Gemensamt för de båda bilderna är att spridningen i P2P applikationens tider är större än spridningen för klient-server applikationens tider. Detta skiljer sig från resultatet i bilderna 4.7 och 4.8.

4.1.3 Över Internet

I detta avsnitt presenteras mätdatan från testen som utfördes över Internet

4.1.3.1 Två klienter

(29)

Bild 4.11 - Boxplot, 2 klienter över Internet

(30)

5. Analys

Här presenteras en analys av de, enligt oss, intressantaste graferna.

5.1 Uppskalning av datamängd, medelvärde

Bild 5.1 - Datamängd, medelvärde

Vad som går att utläsa av tabellerna (4.1-6) är att medelvärdet för P2P applikationens tider generellt sett är lägre än det för klient-server applikationens tider. Utifrån bild 5.1 går det även att tolka det som att klient-server jämförelsevis har längre överföringstid ju större datamängden är. Dock är skillnaderna mindre vid storleksmängden 100kB och 1MB.

5.2 Uppskalning av datamängd, minvärde

(31)

Diagrammet för applikationernas minvärde följer en liknande kurva som det för medelvärdet. Även minvärdena är generellt lägre för P2P appliaktionen än för klient-server applikationen. Jämförelsevis är skillnaden mellan minvärde och medelvärde per datamängd för P2P; 1B 18%, 1kB 19%, 10kB 15%, 100kB 21%, 1MB 15%, 10MB 29% och för klient-server; 1B 25%, 1kB 16%, 10kB 23%, 100kB 17%, 1MB 17%, 10MB 18%. Skillnaderna mellan minvärdet och mellanvärdet är alltså liknade för de båda applikationerna, även om skillnaden är något större för P2P applikationen.

5.3 Uppskalning av datamängd, standardavvikelse

Bild 5.3 - Datamängd, standardavvikelse

Som det går att utläsa av tidigare tabeller och diagram för medelvärde och minvärde ökar även värdet för standardavvikelsen i takt med att datamängden ökar. Däremot är den mer fluktuerande för klient-server i och med att den vid vissa ökandande

datamängder sjunker, vilket de andra värdena inte gör. P2P har även en lägre

standardavvikelse för 1B till 100kB medan den vid 1MB och 10MB överstiger klient-server applikationens standardavvikelse.

(32)

5.4 Uppskalning av antalet klienter, medelvärde

Bild 5.4 - Flera klienter, medelvärde

Ur diagrammet från bild 5.4 går det att utläsa en viss trend med antalet ökande klienter. För P2P är denna trenden ständigt ökande och för klient-server ökar den visserligen, men är inte konstant och i jämförelse med P2P går det även utläsa en mindre lutning på kurvan vilket tyder på att ökningen med fler klienter kommer göra att P2Ps kurva går om klient-server i takt med att antalet klienter ökar.

5.5 Uppskalning av antalet klienter, minvärde

(33)

Kurvan som representerar tiderna för minvärdet då antal klienter ökar skiljer sig från tidigare diagrams kurvor. Klient-server applikationens tider sjunker då antal klienter ökar, så länge antalet klienter är fyra eller färre och för P2P håller kurvan sig relativt rak för samma antal klienter. Över fyra klienter stiger kurvan dock kraftigt, vilket tyder på att minvärdet för tiden på de båda applikationerna kommer att öka på sikt i takt med att antalet klienter ökar.

5.6 Uppskalning av antalet klienter, standardavvikelse

Bild 5.6 - Flera klienter, standardavvikelse

För standardavvikelsen går det att utläsa från bild 5.6 att klient-server håller en generellt låg avvikelse som inte ökar nämnvärt med antalet klienter, även om den fluktuerar. För P2P ökar avvikelsen i takt med att antalet klienter ökar. Detta tyder på att P2P nätverket blir mer ostabilt då antal klienter ökar.

5.7 Test över Internet

För flera klienter över Internet går det av tabell 4.11 utläsa ett helt annorlunda resultat från alla tidigare mätningar. Klient-server presterar här mycket bättre än P2P med marginal, där P2P har ett medelvärde av 237 millisekunder medan klient-server har ett medelvärde på 64 millisekunder vilket nästan är fyra gånger mindre.

Standardavvikelsen skiljer sig dock inte lika mycket, 12 ms för P2P och 7 för server. Det är värt att notera att minvärdet och medelvärdet för både P2P och klient-server är nära varandra.

5.8 Uppskalning av antalet klienter (2 klienter) mot 1kB dataöverföring

När två klienter med 512B data per klient jämförs med dataöverföring på 1kB går det att se att P2P i testfallet med flera klienter är långsammare än motsvarande

(34)

6. Diskussion

Stora delar av resultatet kan anses vara förutsägbart, då det visar på att tiderna ökar då antal klienter eller datamängden ökar, vilket kan utläsas av resultatet som presenteras i kapitel 4. Det finns dock vissa avvikelser från det förväntade resultatet som är värt att diskutera. I inledningen sammanfattades åsikter från diverse källor på Internet där den övergripande meningen var att klient-server är att föredra ur en prestandasynpunkt. Mätningarna som utförs i denna rapport tyder dock på motsatsen, att P2P presterar bättre under de flesta förhållande, vilket diskuteras i kapitel 5. Det är dock värt att notera att dataurvalet är begränsat till max fem klienter, vilket vi tror påverkar resultatet till P2P’s fördel, då P2P nätverk skalar mycket sämre i jämförelse med klient-server då antalet klienter ökar.

Vidare kan det av resultatet utläsas att standardavvikelsen ökar ju fler klienter det ingår i nätverket, vilket kan utläsas av bilderna 4.7-10 . Framförallt för P2P

applikationen där standardavvikelsen ökar markant vid fem klienter. Detta tyder på att klienterna i ett P2P nätverk påverkas av varandra i större grad än de gör i motsvarande klient-server modell. Förmodligen beror detta på att alla klienter kommunicerar med alla andra klienter i ett P2P nätverk. I ett klient-server nätverk kommunicerar alla klienter med servern som i sin tur kommunicerar med alla klienter, vilket begränsar antalet kommunikationsvägar i förhållande till P2P och då minskar risken att fel uppstår.

Jämfört med de resultat från [4, sid. 48] visar denna rapports applikationer på genomgående bättre resultat. Antagligen beror detta till stor del på att testen i denna rapport har utförts med 1 Gbit nätverkshastighet medan nätverkshastigheten i [4, sid. 48] endast var 10 Mbit. Överlag anser vi att omständigheterna och miljön kring testen skiljer sig åt så pass att det inte går att utläsa mycket av en jämförelse mellan dem. Det finns även en del variabler som inte är specificerade i [4], som till exempel vilka tekniker de använde för att skicka paket eller om de följer SI-standarden för enheter, vilket har försvårat återskapandet av det testet.

Det finns dock en del variabler även i implementationerna av testen, vilka specificeras i metoden i kapitel 3, som är värda att nämna. Vi anser till exempel att tiderna till stor del är beroende av testens implementation, vilken även diskuterades i metoddiskussionen. En annan eventuellt påverkande aspekt är den hårdvara[Appendix B] som använts vid testen, då det bara använts en begränsad mängd. Det är svårt att avgöra huruvida detta har påverkat resultaten. Likadant gäller det för hårdvaran i nätverket, som kablar och switchar som kan ha varit defekta. Detta gäller särskilt för kablar som kan vara kinkiga när de börjat bli skadade, men inte på ett sådant sätt att det märks vid normal användning.

(35)

7. Avslutning

Denna rapport har jämfört två olika nätverksarkitekturer, P2P och klient-server. De båda arkitekturerna har mäts ur en prestandasynpunkt med varierande antal klienter och datamängd. Vidare har resultatet jämförts med resultatet från ett tidigare arbete för att visa på skillnader och likheter. Syftet med rapporten har varit att presentera fakta om de olika arkitekturernas fördelar och nackdelar samt att ge läsaren en bättre bild av hur de olika arkitekturerna skiljer sig åt och när det lämpar sig att använda den ena eller andra modellen.

7.1 Slutsats

Med hänsyn till de delfrågor som ställdes i rapporten skapades ett antal hypoteser. Den första hypotesen, att överföringstiden ökar snabbare för en P2P applikation då

datamängden ökar, kan falsifieras då vi observerade motsatsen i de test som utförts. Den andra hypotesen, som sa att överföringstiden stiger kraftigare med en P2P arkitektur då antalet uppkopplade klienter i nätverket ökar, kan inte verifieras med säkerhet.

Grafernas utveckling (bild 5.4, 5.5 och 5.6) tyder dock på att hypotesen stämmer om antalet klienter skulle fortsätta öka över fem. Av resultaten framgår också att klient-server applikationen var generellt snabbare än P2P applikationen över Internet. Detta var motsatsen till de resultat som de lokala testen gav, vilket tyder på att det är svårt att förutse en nätverksarkitekturs beteende då de körs över Internet. Vidare kan slutsatsen dras att fler kommunikationsvägar ökar risken för att det blir fel i kommunikationen. Detta påverkar dock en P2P applikation i större utsträckning, då

kommunikationsvägarna är fler.

7.2 Förslag till fortsatt forskning

Det finns vissa frågor som fortfarande är obesvarade vars svar skulle kunna ge en ytterligare ökad förståelse för problemområdet. Då våra test visade på en brantare ökning för P2P då antalet klienter ökade, hade en uppskalning med fler klienter potentiellt kunnat verifiera denna hypotes. En mätning som saknas i de nuvarande testen, är ett där data skickas kontinuerligt under en förutbestämd tid för respektive arkitektur. Denna typ av användningsfall återfinns i till exempel tjänster som tillhandahåller strömning av video. Detta kan eventuellt ge en annan bild av vilken arkitektur som bör användas.

Denna rapport granskar endast de olika nätverksarkitekturerna ur en

prestandasynpunkt. En annan viktig aspekt är hur de olika modellerna hanterar data och hur detta påverkar säkerheten i applikationer som implementerar dem. Ett förslag på framtida forskning är att granska de olika modellerna ur ett säkerhetsperspektiv. Detta skulle göra det möjligt att svara på hur säkra de är i jämförelse med varandra samt vad som kan göras för att säkerheten i respektive modell. Vidare skulle det kunna leda till en diskussion kring hur dessa åtgärder påverkar prestandan och hur det i så fall påverkas denna rapports resultat.

(36)

Referenser

1. Min Zhang, Maurizio Dusi, Wolfgang John och Changjia Chen, “Analysis of UDP Trafﬁc Usage on Internet Backbone Links”, “Applications and the

Internet, 2009. SAINT '09. Ninth Annual International Symposium on”, 20-24 juli 2009

2. “Analyzing UDP usage in Internet traffic”, Caida, september 2013 [Online] Tillgänglig: ://http www . caida . org / research / traffic - analysis / tcpudpratio / [Hämtad 10 mars, 2014]

3. Ernesto, “BitTorrent still dominates global Internet traffic”, Torrentfreak.com, oktober 2010 [Online] Tillgänglig: https :// torrentfreak . com / bittorrent - still -dominates - global - internet - traffic -101026/ [Hämtad 10 mars, 2014]

4. Johan Furberg, Johan Ölund, “Generella P2P plattformar” unpublished 5. Charles M. Kozierok, “TCP/IP Overview and History”, The TCP/IP Guide,

september 20 2005 [Online], Tillgänglig:

http

:// www . tcpipguide . com / free / t _ TCPIPOverviewandHistory . htm [Hämtad: 10 mars, 2014]

6. Epic Games, Inc., “Client Server Model”, Epic Games [Online] Tillgänglig:

http

:// udn . epicgames . com / Three / ClientServerModel . html [Hämtad: 17 mars, 2014]

7. Microsoft, “ Client / Server Topology ”, Microsoft [ Online ] Tillgänglig : http

:// msdn . microsoft . com / en -us

/ library / windows / desktop / bb 153244%28 v = vs .85%29. aspx [Hämtad 17 mars, 2014]

8. Microsoft , “ Peer - to - Peer Topology ”, Microsoft [ Online ] Tillgänglig : http

:// msdn . microsoft . com / en -us

/ library / windows / desktop / bb 153250%28 v = vs .85%29. aspx [Hämtad 17 mars, 2014]

9. Glenn Fiedler, “What every programmer needs to know about game networking”, gafferongames.com, januari 2010 [Online] Tillgänglig:

http

:// gafferongames . com / networking - for - game - programmers / what - every -programmer - needs - to - know - about - game - networking / [Hämtad: 17 mars, 2014] 10. Wikipedia, “Peer-to-Peer”, Wikipedia, http :// en . wikipedia . org / wiki / Peer - to

-peer [Hämtad: 31 mars, 2014]

11. Gorry Fairhurst, “Unicast, Broadcast, and Multicast”, University of Aberdeen,

http

:// www . erg . abdn . ac . uk /~ gorry / course / intro - pages / uni - b - mcast . html

[Hämtad: 25 mars, 2014]

12. Christoph Neumann, Nicolas Prigent, Matteo Varvello och Kyoungwon Suh. “Challenges in peer-to-peer gaming”, SIGCOMM Comput. Commun. vol 37, nr 1, s. 79-82, januari 2007

13. J.A. Pouwelse, P. Garbacki med flera, “The BitTorrent P2P file-sharing system: measurments and analysis”, Delft University of Technology, the Netherlands, 2005

14. Oracle, “java.io”, Java Platform SE 7 [Online] Tillgänglig:

http

:// docs . oracle . com / javase /7/ docs / api / java / io / package - summary . html

[Hämtad: 7 maj, 2014]

15. Oracle, “java.io”, Java Platform SE 7 [Online] Tillgänglig:

http

(37)

16. Stefan, “UDP Multicast over the internet?”, Stack Overflow [Online] Tillgänglig: ://http stackoverflow . com / questions /3068497/ udp - multicast - over -the

- internet [Hämtad: 27 april, 2014]

17. Wikipedia, “User Datagram Protocol”, Wikipedia [Online] Tillgänglig:

http

:// en . wikipedia . org / wiki / User _ Datagram _ Protocol [Hämtad: 5 maj, 2014] 18. Marcos Rates Crippa, Fabio Reis Cecin med flera, “Peer-to-peer support for

instance-based massively multiplayer games”, Federal University of Rio Grande do Sul Porto Alegre, RS, Brazil, 2006

19. SungJin Choi, “Group-based Dynamic Computational Replication

(38)

Appendix A - Åsikter på Internet om Klient-Server vs P2P

http

:// www . techrepublic . com / article / understanding - the - differences - between - client -server - and - peer - to - peer - networks /

Författaren till artikeln, som är från 2000, beskriver skillnaderna mellan klient-server och P2P arkitekturen. Han sammanfattar sina åsikter i sista meningen där han säger “If you can afford it and if you have a qualified person to manage it, a client/server network is going to be your best bet.”

http

:// www . tomshardware . com / reviews / local - area - network - wi - fi - wireless ,3020-2. html

Även denna serie av artiklar som handlar om nätverksarkitekturers tekniska detaljer verkar dra samma slutsats som föregående, att den enda nackdelen med en klient-server arkitektur är kostnaderna förknippade med att hantera servern; “Client/server LANs offer enhanced security for shared resources, greater performance, increased backup efficiency for network-based data, and the potential for the use of redundant power supplies and RAID drive arrays. Client/server LANs also are more expensive to purchase and maintain.”

http

:// www . enterprise - technology . net / network 2. htm

Denna artikel som också är från början av 2000-talet, har liknande meningar som tidigare artiklar, men skiljer sig genom att påstå att P2P är enkelt att

installera och konfigurera “On balance, however, a Client-server configuration is preferable to peer-to-peer, especially in a small business environment where there is an expectation of growth. The upside of the Peer-to-peer is that it is relatively inexpensive and fairly simple to set up and manage. The flip side is that it is limited in extensibility, tends to overburden user workstations by having them play the role of server to other users, is largely unsecured...”

http

:// www . americanbar . org / newsletter / publications / gp _ solo _ magazine _ home / gp _ solo _ magazine _ index / tsp 97 jure 1. html

Denna sida listar för och neckdelar med klient-server och P2P arktekturer på ett väldigt generiskt sätt utan någon som helst förklaring eller källa. Däremot verkar det som att den i det stora hela delar vy med tidigare åsikter.

http

:// devmaster . net / posts /16869/ networking - p 2 p - vs - server - based - online - multiplayer -games

I denna långa forumtråd finns det lika många åsikter som deltagare.

Forumstartaren är av meningen att det finns en P2P arkitektur som är överlägsen klient-server arkitekturer för nätverkspel. Den generella meningen är dock att detta påstående helt saknar grund och att det är raka motsatsen till verkligheten.

http

:// gafferongames . com / networking - for - game - programmers / what - every - programmer -needs - to - know - about - game - networking /

(39)

(40)

Appendix B - Specifikationer för datorer använda i test och switch

Dator Nätverkskort CPU OS RAM

1 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

AMD Phenom(tm) II X6 1090T Processor Linux Mint Debian (201403) 8GB

2 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)

Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz Debian Wheezy 4GB

3 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

AMD

Phenom(tm) II X4 955 Processor

Windows 7

SP1 4GB

Intel(R)

Core(TM) i7 CPU 920 @ 2.67GHz

Windows 7

SP1 8GB

Intel(R)

Atom(TM) CPU 330 @ 1.60GHz

Ubuntu

14.04 2GB

Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz Ubuntu 14.04 8GB Switch Netgear GS108

Hastighet 10/100/1000Mbps Gigibit Ethernet Jumbo Frame Support Ja

(41)

Appendix C - Källkod

(42)

Fakulteten för teknik