Distributing usage of bandwidth for on-demand streaming
Specialeforsvar, 15. jan 2007
Jacob de Fine Skibsted &
Stephan Lynge Herlev Larsen
Datalogisk Institut ved Københavns Universitet
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
Baggrund
• 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
Begreber
Baggrund
DIKU - Specialeforsvar 15. jan 2007 4 / 22
Problemstilling
s
K2K1
K3
K4
K5
• Server sender data til een klient.
• Serveren sender en datastrøm til flere klienter.
• I stedet for dette kan klienterne sende data videre til hinanden.
• Dette giver dog det problem, at hvis klient K4 interagerer med filmen, hvem skal da sende data til K5?
• Den grundlæggende problemstilling er derfor at sørge for, at klienterne videresender data, man at de ikke er indbyrdes afhængige.
Baggrund
• 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
Krav
Protokolspecifikation
DIKU - Specialeforsvar 15. jan 2007 6 / 22
Arkitektur
Protokolspecifikation
DIKU - Specialeforsvar 15. jan 2007 7 / 22
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...
Protokolspecifikation
DIKU - Specialeforsvar 15. jan 2007 8 / 22
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’.
Protokolspecifikation
DIKU - Specialeforsvar 15. jan 2007 9 / 22
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.
Protokolspecifikation
DIKU - Specialeforsvar 15. jan 2007 10 / 22
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.
Protokolspecifikation
DIKU - Specialeforsvar 15. jan 2007 11 / 22
Buffering
Idet serveren er nødt til at kende indholdet af hver klients buffer må der være en fælles opfattelse af bufferen.
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?
Protokolspecifikation
DIKU - Specialeforsvar 15. jan 2007 12 / 22
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.
Protokolspecifikation
DIKU - Specialeforsvar 15. jan 2007 13 / 22
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.
Protokolspecifikation
DIKU - Specialeforsvar 15. jan 2007 14 / 22
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.
Protokolspecifikation
DIKU - Specialeforsvar 15. jan 2007 15 / 22
Pakketyper
Alle pakketyper bærer den samme header, både DCP samt CCP pakker:
Headeren indeholder derfor informationer som er delt mellem alle pakketyper.
Protokolspecifikation
DIKU - Specialeforsvar 15. jan 2007 16 / 22
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.
Protokolspecifikation
DIKU - Specialeforsvar 15. jan 2007 17 / 22
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.
Implementation
DIKU - Specialeforsvar 15. jan 2007 18 / 22
ProtokolFor 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 tilWindows. Al koden blev dog konverteret til C++ under Windows.
Resultat
DIKU - Specialeforsvar 15. jan 2007 19 / 22
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:1. Normal streaming: Først vises en komplet streaming af filmen fra serveren til en klient, uden
nogen former for afbrydelser.
2. Brugerinteraktion: Serveren streamer data til en klient som foretager 2 skip i filmen.
3. 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.
4. 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.
5. 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.
Resultat
DIKU - Specialeforsvar 15. jan 2007 20 / 21
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.
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
Top Related