Presentatie over Peer to Peer in virtuele werelden en spelletjes.Opdracht communicatievaardigheden, 1e bachlor informatica.
Presentatie door Cedric Van Bockhaven en Arya Ghodsi
More than Just Lines on a Map: Best Practices for U.S Bike Routes
Peer to Peer - Streaming of the Future
1. Beveiligde 3D streams via peer-to-peer Presentatie door Arya Ghodsi en Cedric Van Bockhaven
2.
3. Scène-streaming Status-uitwisseling: hebben de gebruikers de inhoud die ik zoek, zijn ze fysiek dichtbij, etc.? Transmissie: het downloaden van objecten naargelang de prioriteit Prioritisatie: belangrijkheidsgraad van objecten wordt bepaald Determinatie: de gebruiker krijgt informatie over nabije objecten Bronnen zoeken: welke andere gebruikers hebben de data die ik wil? Arya Ghodsi en Cedric Van Bockhaven Streamen vanaf server Streamen via P2P Determinatie Determinatie Prioritisatie Bronnen zoeken Status-uitwisseling Transmissie Transmissie
6. Waarom beveiligen? Data beveiligen met digitale handtekening Arya Ghodsi en Cedric Van Bockhaven
7. Werking van digitale handtekening Ondertekenen Hash-functie Data Encryptie met private key Toevoegen ______ ________________________________________ Arya Ghodsi en Cedric Van Bockhaven 101100110100010 Hash Data met digitale handtekening ______ ________________________________________ 001011101101001 Digitale handtekening
8. Werking van digitale handtekening Verifiëren Hash-functie Decryptie met public key 101100 001 100010 Arya Ghodsi en Cedric Van Bockhaven Data ______ ________________________________________ Data ______ __________ X _________________ X ___________ 101100110100010 Hash Data met digitale handtekening ______ ________________________________________ 001011101101001 Digitale handtekening 101100110100010 Hash
9.
10.
11.
12.
13.
14.
Editor's Notes
Voorbeelden: WoW, Google earth , second life,…
Voor te vertellen: FLOD is een framework dat virtuele omgevingen opsplitst in grids.
De gebruiker krijgt informatie over de nabije objecten Belangrijkheidsgraad van objecten het downloaden van objecten naargelang hun prioriteit Voor te vertellen: FLOD
RUIMTE
Voorbeelden= meerdere malen inloggen Misbruik van het systeem= advertenties e.d. Verschillende versies= de ene gebruiker zit misschien met versie 1.5 terwijl de andere op versie 2 werkt incompatibiliteit
De “whole –model” : Is basisvorm, hierbij moet de content geheel gedownload worden vooraleer het kan worden geladen. standaard digitale handtekening met private en public key Het “linear/progressive” model : Hierbij wordt het hele pakken in stukken gekapt(cfr. Grid) en de gebruiker kan aan de hand van een ruwe voorstelling beslissen waar hij naar toe wil gaan en zo de juiste “stuk” binnenhalen. het probleem hier is dat voor elk deel een aparte handtekening zou moeten toegevoegd worden, de uitgever handtekent daarom het eerste deel, waarna de verificatie van de volgende delen steunt op het vorige. Het eerste object wordt gehandtekend wanneer deze wordt geverifieerd, dan genereert deze een output. Op basis van die output wordt het tweede deeltje geverifieerd, deze heeft ook een output en op basis daarvan wordt het derde deeltje geverifieerd enz. De “independant stream” model:hierbij wordt het geheel ook in stukken verdeeld, maar de stukken staan los van mekaar. De deeltjes kunnen ook geheel naar keuzen van de gebruiker worden binnegehaald. Omdat de deeltjes onafhankelijk opereren kan geen Hash chain worde gebruikt, zoals bij linear model. Dus moet het snelste verificiate algoritme gezocht worden. De rabin wijze is een goede oplossing. Het voordeel is dat de verificatie snel kan worden geverifieerd, maar het nadeel is wel dat het lang duurt om zo’n digitale handtekening te genereren, maar sinds dit vooraf kan gebeuren door de server, is dit geen probleem. De “Partially linear stream” model: Daarmee wordt bedoeld dat de deeltjes onderling een complexe relatiestructuur hebben. Deze leunt sterk aan bij de het lineair model, alleen bepaalt de structuur welke deeltjes een hogere prioriteit hebben en dus vlugger worden moeten gedownload worden. |||| ?????? wapens worden apart gedownload (granaat, geweer, mes) daarna kleding (hemd, broek) daarna lichaamseigenschappen (huidskleur, snor, man/vrouw) etc etc.. ????? Hier wordt er gebruik gemaakt van Hash DAG, dit is een soort van Hash chain, alleen zijn er ook onafhankelijke delen. Dus eigenlijk is er een combinatie van independant stream en linear stream. Verificatie van een deeltje steunt op het andere, maar niet altijd. Bijvoorbeeld stuk 45 kan steunen op 5, maar je kan hem stuk 45 wel binnenhalen,zonder dat de overige stukken zijn geverifieerd(stuk 5 moet WEL geverifieerd zijn). Bij linear... moet stuk 1 tot 44 eerst geverifieerd worden vooraleer het kan binnengehaald.
De “whole –model” : Is basisvorm, hierbij moet de content geheel gedownload worden vooraleer het kan worden geladen. standaard digitale handtekening met private en public key Het “linear/progressive” model : Hierbij wordt het hele pakken in stukken gekapt(cfr. Grid) en de gebruiker kan aan de hand van een ruwe voorstelling beslissen waar hij naar toe wil gaan en zo de juiste “stuk” binnenhalen. het probleem hier is dat voor elk deel een aparte handtekening zou moeten toegevoegd worden, de uitgever handtekent daarom het eerste deel, waarna de verificatie van de volgende delen steunt op het vorige. Het eerste object wordt gehandtekend wanneer deze wordt geverifieerd, dan genereert deze een output. Op basis van die output wordt het tweede deeltje geverifieerd, deze heeft ook een output en op basis daarvan wordt het derde deeltje geverifieerd enz. De “independant stream” model:hierbij wordt het geheel ook in stukken verdeeld, maar de stukken staan los van mekaar. De deeltjes kunnen ook geheel naar keuzen van de gebruiker worden binnegehaald. Omdat de deeltjes onafhankelijk opereren kan geen Hash chain worde gebruikt, zoals bij linear model. Dus moet het snelste verificiate algoritme gezocht worden. De rabin wijze is een goede oplossing. Het voordeel is dat de verificatie snel kan worden geverifieerd, maar het nadeel is wel dat het lang duurt om zo’n digitale handtekening te genereren, maar sinds dit vooraf kan gebeuren door de server, is dit geen probleem. De “Partially linear stream” model: Daarmee wordt bedoeld dat de deeltjes onderling een complexe relatiestructuur hebben. Deze leunt sterk aan bij de het lineair model, alleen bepaalt de structuur welke deeltjes een hogere prioriteit hebben en dus vlugger worden moeten gedownload worden. |||| ?????? wapens worden apart gedownload (granaat, geweer, mes) daarna kleding (hemd, broek) daarna lichaamseigenschappen (huidskleur, snor, man/vrouw) etc etc.. ????? Hier wordt er gebruik gemaakt van Hash DAG, dit is een soort van Hash chain, alleen zijn er ook onafhankelijke delen. Dus eigenlijk is er een combinatie van independant stream en linear stream. Verificatie van een deeltje steunt op het andere, maar niet altijd. Bijvoorbeeld stuk 45 kan steunen op 5, maar je kan hem stuk 45 wel binnenhalen,zonder dat de overige stukken zijn geverifieerd(stuk 5 moet WEL geverifieerd zijn). Bij linear... moet stuk 1 tot 44 eerst geverifieerd worden vooraleer het kan binnengehaald.
De “whole –model” : Is basisvorm, hierbij moet de content geheel gedownload worden vooraleer het kan worden geladen. standaard digitale handtekening met private en public key Het “linear/progressive” model : Hierbij wordt het hele pakken in stukken gekapt(cfr. Grid) en de gebruiker kan aan de hand van een ruwe voorstelling beslissen waar hij naar toe wil gaan en zo het juiste “stuk” binnenhalen. het probleem hier is dat voor elk deel een aparte handtekening zou moeten toegevoegd worden, de uitgever handtekent daarom het eerste deel, waarna de verificatie van de volgende delen steunt op het vorige. Het eerste object wordt gehandtekend wanneer deze wordt geverifieerd, dan genereert deze een output. Op basis van die output wordt het tweede deeltje geverifieerd, deze heeft ook een output en op basis daarvan wordt het derde deeltje geverifieerd enz. De “independant stream” model:hierbij wordt het geheel ook in stukken verdeeld, maar de stukken staan los van mekaar. De deeltjes kunnen ook geheel naar keuzen van de gebruiker worden binnegehaald. Omdat de deeltjes onafhankelijk opereren kan geen Hash chain worde gebruikt, zoals bij linear model. Dus moet het snelste verificiate algoritme gezocht worden. De rabin wijze is een goede oplossing. Het voordeel is dat de verificatie snel kan worden geverifieerd, maar het nadeel is wel dat het lang duurt om zo’n digitale handtekening te genereren, maar sinds dit vooraf kan gebeuren door de server, is dit geen probleem. De “Partially linear stream” model: Daarmee wordt bedoeld dat de deeltjes onderling een complexe relatiestructuur hebben. Deze leunt sterk aan bij de het lineair model, alleen bepaalt de structuur welke deeltjes een hogere prioriteit hebben en dus vlugger worden moeten gedownload worden. |||| ?????? wapens worden apart gedownload (granaat, geweer, mes) daarna kleding (hemd, broek) daarna lichaamseigenschappen (huidskleur, snor, man/vrouw) etc etc.. ????? Hier wordt er gebruik gemaakt van Hash DAG, dit is een soort van Hash chain, alleen zijn er ook onafhankelijke delen. Dus eigenlijk is er een combinatie van independant stream en linear stream. Verificatie van een deeltje steunt op het andere, maar niet altijd. Bijvoorbeeld stuk 45 kan steunen op 5, maar je kan hem stuk 45 wel binnenhalen,zonder dat de overige stukken zijn geverifieerd(stuk 5 moet WEL geverifieerd zijn). Bij linear... moet stuk 1 tot 44 eerst geverifieerd worden vooraleer het kan binnengehaald.
De “whole –model” : Is basisvorm, hierbij moet de content geheel gedownload worden vooraleer het kan worden geladen. standaard digitale handtekening met private en public key Het “linear/progressive” model : Hierbij wordt het hele pakken in stukken gekapt(cfr. Grid) en de gebruiker kan aan de hand van een ruwe voorstelling beslissen waar hij naar toe wil gaan en zo de juiste “stuk” binnenhalen. het probleem hier is dat voor elk deel een aparte handtekening zou moeten toegevoegd worden, de uitgever handtekent daarom het eerste deel, waarna de verificatie van de volgende delen steunt op het vorige. Het eerste object wordt gehandtekend wanneer deze wordt geverifieerd, dan genereert deze een output. Op basis van die output wordt het tweede deeltje geverifieerd, deze heeft ook een output en op basis daarvan wordt het derde deeltje geverifieerd enz. De “independant stream” model:hierbij wordt het geheel ook in stukken verdeeld, maar de stukken staan los van mekaar. De deeltjes kunnen ook geheel naar keuzen van de gebruiker worden binnegehaald. Omdat de deeltjes onafhankelijk opereren kan geen Hash chain worde gebruikt, zoals bij linear model. Dus moet het snelste verificiate algoritme gezocht worden. De rabin wijze is een goede oplossing. Het voordeel is dat de verificatie snel kan worden geverifieerd, maar het nadeel is wel dat het lang duurt om zo’n digitale handtekening te genereren, maar sinds dit vooraf kan gebeuren door de server, is dit geen probleem. De “Partially linear stream” model: Daarmee wordt bedoeld dat de deeltjes onderling een complexe relatiestructuur hebben. Deze leunt sterk aan bij de het lineair model, alleen bepaalt de structuur welke deeltjes een hogere prioriteit hebben en dus vlugger worden moeten gedownload worden. |||| ?????? wapens worden apart gedownload (granaat, geweer, mes) daarna kleding (hemd, broek) daarna lichaamseigenschappen (huidskleur, snor, man/vrouw) etc etc.. ????? Hier wordt er gebruik gemaakt van Hash DAG, dit is een soort van Hash chain, alleen zijn er ook onafhankelijke delen. Dus eigenlijk is er een combinatie van independant stream en linear stream. Verificatie van een deeltje steunt op het andere, maar niet altijd. Bijvoorbeeld stuk 45 kan steunen op 5, maar je kan hem stuk 45 wel binnenhalen,zonder dat de overige stukken zijn geverifieerd(stuk 5 moet WEL geverifieerd zijn). Bij linear... moet stuk 1 tot 44 eerst geverifieerd worden vooraleer het kan binnengehaald.