Distributing usage of bandwidth for on-demand streaming Specialeforsvar, 15. jan 2007 Datalogisk Institut ved Københavns Universitet Distributing usage of bandwidth for on-demand streaming Jacob de Fine Skibsted & Stephan Lynge Herlev Larsen

Agenda Baggrund: Begreber, problemstillinger og krav. Protokolspecifikation: Arkitektur, video data, topologi og pakketyper. Implementering: Protokol implementering og testprogrammer. Resultat: Demonstration og opnået besparelse. Opsummering DIKU - Specialeforsvar 15. jan 2007 2 / 22

“Distributing usage of bandwidth for on-demand streaming” Baggrund Begreber Streaming: Afsendelse af data med samme hastighed som modtageren konsumerer dette. On-Demand: Grundlæggende findes der 2 former for streaming: On-demand streaming og Live streaming: Live Streaming, kan bedst sammenlignes med en direkte fodboldkamp. On-demand streaming, kan bedst sammenlignes med afspilning af en DVD. Båndbredde: Et lidt misbrugt udtryk som betegner en linies kapacitet - udtryk for hvor meget data der kan sendes fra A til B. Distribuering: Omfordeling af en resurse mellem flere enheder. Deraf specialets overskrift: “Distributing usage of bandwidth for on-demand streaming” DIKU - Specialeforsvar 15. jan 2007 3 / 22

Baggrund s K2 K3 K1 K4 K5 Problemstilling Server sender data til een klient. Serveren sender en datastrøm til flere klienter. K2 K3 I stedet for dette kan klienterne sende data videre til hinanden. K1 Dette giver dog det problem, at hvis klient K4 interagerer med filmen, hvem skal da sende data til K5? K4 Den grundlæggende problemstilling er derfor at sørge for, at klienterne videresender data, man at de ikke er indbyrdes afhængige. K5 DIKU - Specialeforsvar 15. jan 2007 4 / 22

Baggrund Krav Serverens båndbredde forbrug skal begrænses: Båndbreddeforbruget for serveren må ikke ’skalere lineært’ i forhold til antallet af klienter der ser filmen. Bruger-interaktion: En klients interaktion må ikke forårsage uregelmæssigheder for andre brugere. Det skal være muligt for en klient at “springe” i filmen. Det skal være muligt for en klient at pause en film. Hurtig opstart. Datastrøm: Klienter der ikke er i stand til, at aflevere en komplet upstream skal ikke udelukkes fra at kunne være med. Data skal derfor kunne leveres fra flere klienter. Serveren skal have mulighed for at styre dataflowet mellem de enkelte klienter. Sikkerhed: Serveren skal autorisere alle brugere der ønsker at se en film. En klient må ikke have mulighed for, uopdaget at ændre på data inden det sendes videre til andre klienter. Det skal i et vist omfang sikres at en klient ikke kan kopiere data. DIKU - Specialeforsvar 15. jan 2007 5 / 22

Protokolspecifikation Arkitektur DIKU - Specialeforsvar 15. jan 2007 6 / 22

Dette fordrer brugen af to forskellige datastrømme, nemlig... Protokolspecifikation Topologi Central server: Opbevarer som den eneste den fulde videofil. Varetager klienternes adfærd. Opbygger den topologi som er tilsigtet af implementeringen. Bestemmer hvilke klienter der sender hvad til andre. Topologien er således ikke fastlagt af specifikationen. Klient: Udfører serverens ordrer. Videresender data til andre klienter. Skal kunne sende data til flere andre klienter. Dette fordrer brugen af to forskellige datastrømme, nemlig... DIKU - Specialeforsvar 15. jan 2007 7 / 22

Protokolspecifikation Topologi Kontrolkanal (CCP): Benyttes af klienten til at underrette serveren om dens status. Underretter klienter om datastrømmens karakteristika. Benyttes af serveren til at give ordrer til klienterne. Indkapsles ved hjælp af TCP. Datakanal (DCP): Distribuerer videodata mellem klienter. Synkronisering mellem klienter. Indkapsles ved hjælp af UDP. Kan sende med højere/lavere hastighed end strømmen reelt har behov for. Gensender data ved behov, dog skal undgås ’late retransmissions’. DIKU - Specialeforsvar 15. jan 2007 8 / 22

Protokolspecifikation Topologi Karakteristika for udvælgelsesalgoritmen: Udvælger een eller flere klienter som skal sende data til en anden klient. Udføres hver gang topologiændringer sker: Når klienter indtræder eller forlader netværket. Når klienter omflyttes pga. brugerinteraktion eller udfald. Kan baseres på følgende parametre: Klienternes båndbredde. Bufferkapacitet. Netværksstabilitet. Brugerinteraktion / adfærd. Hvor sociale klienterne er. DIKU - Specialeforsvar 15. jan 2007 9 / 22

Protokolspecifikation Datafragmentering Buffer blok (BB): Benyttes til at skippe mellem dele af filmen. Modtages een af gangen fra en eller flere afsendere. På hinanden følgende blokke afsendes efter samme mønster givet af serveren. Består af et antal data blokke. Data blok (DB): Mindste entitet filmen neddeles i. Hver DB afsendes i een UDP pakke. Maksimale størrelse er 65536 byte. DIKU - Specialeforsvar 15. jan 2007 10 / 22

Protokolspecifikation Buffering Bufferens formål er: Skjule netværksudsving for klientapplikationen. Videresende data til andre klienter. Absorbere udfald, når serveren ændrer datastrømmens karakteristika. Dette rejser spørgsmålet, hvorfor skal bufferen være en del af specifikationen? Idet serveren er nødt til at kende indholdet af hver klients buffer må der være en fælles opfattelse af bufferen. DIKU - Specialeforsvar 15. jan 2007 11 / 22

Protokolspecifikation Buffering Klientens buffer: Opfattes som en cirkulær buffer. Punkter hvor handlinger finder sted: Play pointer (PP) Receive pointer (RP) Stream pointer (SP) Opdeles i flere områder: Send area (SA) Connect area (CA) Reserved area (RA) Absorption area (AA) Størrelser på disse områder fastlægges af klienten. DIKU - Specialeforsvar 15. jan 2007 12 / 22

Protokolspecifikation Brugerinteraktion Start: Skal opfattes som ’instant’ start-up. Uhensigtsmæssigt at vente til AA er fyldt. Skip: Skip inden for bufferen. Skip uden for bufferen. Pause: Bør man ændre topologi straks eller bør man vente? Hensigtsmæssigt at vente: Muliggør korte pauser. Klienter kan fungere som ’proxy’ Når bufferen løber fuld vil topologiændringen være nødvendig. DIKU - Specialeforsvar 15. jan 2007 13 / 22

Protokolspecifikation Protokoltilstande Det er ikke muligt at snakke om protokoller uden at snakke om tilstande. Det er dog vigtigt at skelne mellem hvem der opfatter tilstanden. I vores protokol er det dog altid serverens opfattelse der regnes for den gældende. Serverens egen tilstand er simpel – faktisk kun en. Vil kun kort gennemgå de enkelte tilstande blot: Not connected. Connect pending. Connected, initializing. Buffering. Playing. Paused. Skipping. Stopping. Det er således altid serverens opfattelse der bestemmer, om en pakke afsendt fra en klient er gyldig. DIKU - Specialeforsvar 15. jan 2007 14 / 22

Protokolspecifikation Pakketyper Alle pakketyper bærer den samme header, både DCP samt CCP pakker: Headeren indeholder derfor informationer som er delt mellem alle pakketyper. DIKU - Specialeforsvar 15. jan 2007 15 / 22

Protokolspecifikation Pakketyper Pakker inddeles grundlæggende i: Connection: Etableringsfase for en klient. Configuration: Konfiguration af den datastrøm som afsendes/modtages af en klient. Herunder hvilke blokke der afsendes fra hver klient. Streaming: Udveksling af videodata samt justering af den hastighed hvormed data sendes mellem forbundne klienter. Interaction: Udveksling af kommandoer for brugerinteraktion. Status: Forespørgsel samt svar på status. RTT calculation: Beregning af round-trip tid mellem klienter. Security: Afsendelse af sikkerhedsrelateret information fra server til klient. DIKU - Specialeforsvar 15. jan 2007 16 / 22

Protokolspecifikation Sikkerhed Autenticitet: Løses ved hjælp af udveksling af nøglepar som ses ved eks. kerberos. Autorisering: Udføres af serverapplikation. Data integritet og sikkerhed for tyveri af data: Udføres ikke, men designets fleksibilitet åbner for muligheden for det. Sikring af data er nærmest umuligt idet en sådan altid kan omgås. Ideen er at gøre det så vanskeligt at det ikke er attraktivt. Derfor er dette er skilt ud fra protokollen idet der kan benyttes mange forskellige typer af sikkerhed. DIKU - Specialeforsvar 15. jan 2007 17 / 22

Implementation Protokol For at godtgøre protokolspecifikationens grundlæggende funktionalitet er foretaget en implementering af de centrale dele af specifikationen. Implementeringen er tosidet (klient/server) og er karakteriseret ved: Modulær opbygning. Genbrug af moduler mellem de to sider. Opbygget med en klar grænseflade. Benytter flertrådet funktionalitet. Servergrænseflade: Data afleveres til protokollen af serverapplikation for at åbne for at serverapplikationen kan benytte avancerede algoritmer til disk tilgang. Dette giver desuden den fordel at kopiering af hukommelse undgås. Protokollen benytter en kø af opgaver som betjenes af serverapplikationen til at autorisere klienter, forespørge data etc. Klientgrænseflade: Kald der returnerer videodata og sikkerhedsdata. Transporterer kald til brugerinteraktion. Oprindelig intention var en implementering under Linux som derved nemt kunne portes til Windows. Al koden blev dog konverteret til C++ under Windows. DIKU - Specialeforsvar 15. jan 2007 18 / 22

Resultat Demonstration I stedet for en live demonstration viser vi en optagelse der er lavet ved hjælp af de udviklede testapplikationer. Optagelsen viser følgende scenarier: Normal streaming: Først vises en komplet streaming af filmen fra serveren til en klient, uden nogen former for afbrydelser. Brugerinteraktion: Serveren streamer data til en klient som foretager 2 skip i filmen. Videresendelse af data: En klient startes som derefter modtager data fra serveren. Endnu en klient startes op, men denne modtager data fra klient 1. Begge klienter stoppes. Omflytning af klient: En klient startes op herefter startes klient 2 som modtager data fra klient 1. Klient 1 stoppes hvilket medfører at klient 2 får data fra serveren. Endelig foretager klient 2 et skip i filmen hvorefter den stoppes. Data fra flere kilder: En klient startes op som modtager data fra serveren. Herefter startes klient 2 som modtager data fra klient 1, endelig startes klient 3 som modtager data fra klient 1 og klient 2. Klient 2 stoppes og klient 3 modtager nu data fra serveren og fra klient 1 og klient 1 stopper med at sende til klient 2. DIKU - Specialeforsvar 15. jan 2007 19 / 22

Resultat Båndbreddebesparelse Vi kan godtgøre at protokollen opnår en båndbreddebesparelse i et setup under bestemte forudsætninger: Klienterne kan bidrage med tilpas stor upload Klienterne har en tilpas stor buffer til rådighed Et tilpas stort antal klienter Ydermere kan vi konstatere at en række andre faktorer har stor indflydelse på protokollens effektivitet: Netværkets stabilitet. Mængden af brugerinteraktion hos klienterne. I værste tilfælde: Der opnås ingen besparelse idet ingen klienter har muligheden for at sende data videre til andre. Dette vil resultere i unicasting tilmed med mindre effektivitet end traditionelle systemer. I bedste tilfælde: ...? Bemærk dog, at der aldrig opnås en lineær skalering idet CCP optager en konstant stigende mængde båndbredde. DIKU - Specialeforsvar 15. jan 2007 20 / 21

Opsummering Til slut vil vi kort opsummere de områder vi har dækket i denne præsentation: Baggrunden for specialet, herunder de forskellige begreber, problemer og krav. De vigtigste elementer af den udarbejde protokolspecifikation, såsom topologien, brugen af buffer, transport og inddeling af data, pakketyper, tilstande samt de problemer som opstår i forbindelse med sikring af ophavsrettigheder ved denne type netværk. Implementering af den udarbejdede protokolspecifikation samt de testapplikationer som illustrerer protokolimplementeringens funktionalitet. Beskrevet de opnåede resultater herunder vist en kort video der viser brugen af testapplikationerne samt godtgjort at der under normale forudsætninger opnås en båndbreddebesparelse. DIKU - Specialeforsvar 15. jan 2007 21 / 22

Slut Til sidst vil vi bare have lov til at sige tak for jeres tid og for at i gad lytte på os. DIKU - Specialeforsvar 15. jan 2007 22 / 22