Analyse und Implementierung eines oenen Streaming-Protokolls auf P2P-Basis

Größe: px
Ab Seite anzeigen:

Download "Analyse und Implementierung eines oenen Streaming-Protokolls auf P2P-Basis"

Transkript

1 Analyse und Implementierung eines oenen Streaming-Protokolls auf P2P-Basis Katrin Gustat September 2010

2 FernUniversität in Hagen Fakultät für Mathematik und Informatik Lehrgebiet Kommunikationsnetze Bachelor-Studiengang Informatik Erstgutachter: Prof. Dr.-Ing. habil. Herwig Unger Zweitgutachter: Prof. Dr. Jörg Keller Betreuer: Dipl.-Inf. Daniel Berg Eidesstattliche Erklärung Hiermit erkläre ich, dass ich die von mir dem Prüfungsausschuss der Fakultät für Mathematik und Informatik eingereichte Bachelorarbeit zum Thema Analyse und Implementierung eines oenen Streaming-Protokolls auf P2P-Basis vollkommen selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe. Granada, den Katrin Gustat 2

3 Kurzfassung Seit dem Jahr 2000 wurden eine Vielzahl von wissenschaftlichen Arbeiten zum Thema P2P-Streaming veröentlicht. Aufgrund der groÿen Menge an vorhandenen Abhandlungen, dem Fehlen einer allgemein gültigen Terminologie und der Tatsache, dass sich einige Arbeiten sogar widersprechen, ist es sehr schwierig, einen verlässlichen Überblick zu erhalten. Das Ziel dieser Arbeit ist daher, eine systematische Übersicht über den Bereich P2P- Streaming zu liefern und die komplexe Funktionsweise von P2P-Streaming-Systemen durch Analyse und Implementierung eines ausgewählten Protokolls, dem CoolStreaming- Protokoll [ZL+05], vorzustellen. Zunächst werden die Streaming-Technik, die Eigenschaften von Streaming auf P2P- Basis und die Unterscheidungsmerkmale von P2P-Live-Streaming-Protokollen erläutert. Ein Vergleich stellt die Charakteristiken von 21 der bekanntesten P2P-Live-Streaming- Protokolle gegenüber und ist damit nach meinem Wissen der gröÿte Vergleich dieser Art. Es folgen die Analyse und die Beschreibung der Implementierung des CoolStreaming- Protokolls. Mögliche Erweiterungen dieses Protokolls werden diskutiert und ausgewertet. Abstract Since the year 2000 a vast number of papers on p2p sreaming has been published. The large volume of existing information coupled with the lack of a generally accepted terminology and the existence of some dissenting papers make it rather dicult to obtain a satisfactory overview of p2p streaming technology. Therefore the goal of this work is to present a systematic survey of p2p streaming and to describe the complex functionality of p2p streaming systems by analyzing and implementing one particular p2p streaming protocol called CoolStreaming [ZL+05]. First the work explains streaming technology and the characteristics of p2p streaming and p2p live streaming protocols. It compares the features of 21 of the most discussed p2p live streaming protocols which, to my knowledge, represents the largest comparison of this kind. This is followed by an analysis and a description of the implementation of the CoolStreaming protocol itself. Possible enhancements to this protocol are then discussed and evaluated. 3

4 Inhaltsverzeichnis 1 Einführung Erfolgsgeschichte Motivation CoolStreaming Aufgabenstellung Gliederung der Arbeit Streaming Audio-/Videokomprimierung Digitalisierung analoger Daten Codecs, Datei- und Containerformate Der MPEG-Standard MPEG-Videocodecs MPEG-Audiocodecs Zusammenfassung Streaming-Anwendungen Streaming-Methoden Verbindungsarten Streaming-Architekturen Klassische Architekturen Client/Server CDN Multicast über Internet IP-Multicast Application-Level-Multicast Zusammenfassung P2P-Streaming P2P Begrisklärung Klassizierung von P2P-Systemen Zusammenhang Grundlegende Konzepte Video-On-Demand Live-Streaming Analyse Allgemeines Prozessmodell für P2P-Live-Streaming

5 4.2 Protokollcharakteristiken Join Topologie der Streamverteilung Art der Streamverteilung Push Pull Hybrides Push-Pull Gruppenverwaltung Vater-Sohn-Beziehungen/Partnerschaften Verwaltung der Gruppenmitglieder Fehlerkorrekturmechanismen und Kodierungen MDC (Multiple-Description-Coding) FEC (Forward-Error-Correction/Vorwärtsfehlerkorrektur) NC (Network-Coding/Netzwerkkodierung) Transportprotokolle RTP UDP TCP Wahl des Transportprotokolls Überblick Mesh-Pull-Komponenten Scheduler Bearbeitung von Datenrequests Performance-Vergleich Protokolleigenschaften P2P-Streaming-Metriken Graph-Analyse Zusammenfassung Implementierung P2PNetSim SimBench Vorgehensmodell Module Überblick Datentransport Die Klasse StreamingMessage Die Klasse StreamingPeer Hauptmodule eines Streamingpeers Das Paket datenmanager Die Klasse DatenManager Die Klasse P2PStream Die Klasse StreamSegment Die Klasse SegmentID Die Klasse Puer Die Klasse Scheduler

6 Die Klasse FirstOset Die Klasse Player Das Paket partnershipmanager Die Klasse Partner Die Klasse PartnerListe Das Paket membershipmanager Die Klasse MembershipCache Die Klasse MembershipManager Das Paket util Die Klasse MyLogger Die Klasse Bandbreitenregulator Die Klasse Zeit Die Klasse StreamingAddress Test Bedeutung des Testens Modultests JUnit in der Praxis Exemplarischer Testfall Verikation Auswertung Simulationsaufbau Evaluierung und Optimierung Zusammenfassung Abschluss Feedback zu P2PNetSim Fazit Ausblick Literaturverzeichnis 104 Abbildungsverzeichnis 105 Tabellenverzeichnis 106 Glossar 109 6

7 1 Einführung Seit dem Jahre 2000 wurden sehr viele P2P-Streaming-Protokolle entwickelt, darunter eine nicht unerhebliche Zahl in China oder Hongkong. Gleichzeitig kommen aus China die kommerziell erfolgreichsten P2P-Streaming-Lösungen. Zu Beginn dieser Arbeit analysiere ich den Erfolg von P2P-Streaming in China, um die Faktoren herauszunden, unter denen ein für P2P-Streaming-Entwicklungen günstiges Klima entsteht. Es wird dann die Motivation für diese Arbeit dargelegt und aufgezeigt, worin sich diese Arbeit von den vorhandenen P2P-Streaming-Arbeiten unterscheidet und nach welchen Kriterien das zu implementierende Protokoll ausgewählt wurde. Es folgen Denitionen, die erforderlich sind, um die Aufgabenstellung zu erfassen und abzugrenzen. Das Kapitel schlieÿt mit der Gliederung dieser Arbeit. 1.1 Erfolgsgeschichte P2P-Streaming Nicht wenige Arbeiten über P2P-Streaming beginnen mit der Aussage, dass sich P2P- Streaming immer gröÿerer Beliebtheit erfreut, sich immer mehr verbreitet u.ä. Wie sieht dieser Erfolg konkret aus? Die beeindruckendsten Zahlen dazu kommen aus China, wo sich die Anzahl der User, die gleichzeitig die Übertragung eines Live-Ereignisses über einen P2P-Streaming-Anbieter verfolgten, innerhalb weniger Jahre mehr als verzehnfacht hat: 2005: PPLive [ppl] misst gleichzeitige User bei Chinas Gesangscastingshow Super Girl. [Hua07] 2007: Knapp 1,5 Millionen User beim NBA 1 -Entscheidungsspiel mit Houston Rocket (PPLive). [Hua07] 2008: 4-5 Millionen User bei den Olympischen Sommerspielen in Peking (UUSee [uus]). [Zha10] 2009: PPStream [pps] verzeichnet 6 Millionen gleichzeitige User zu den Übertragungen anlässlich des 60.Nationalfeiertags Chinas, PPLive weitere 2 Millionen und UUSee 2-3 Millionen. [Zha10] Zum Vergleich: Die Amtseinführung von US-Präsident Obama am war das meist beachtete Medienereignis in den USA der letzten Jahre. Bei CNN verfolgten nur gleichzeitige P2P-Streaming-User die Übertragungen zur Amtseinführung, obwohl CNN gemessen an den anderen Sendern noch die meisten Online-Zuschauer erreichen konnte [new09]. Vergleicht man beide Medienereignisse aus dem Jahre 2009 miteinander (60.Nationalfeiertag in China, Obamas Amtseinführung in den USA) und setzt die 1 Amerikanische Basketball-Liga 7

8 1.1. ERFOLGSGESCHICHTE KAPITEL 1. EINFÜHRUNG Userzahlen in Relation zur jeweiligen Bevölkerung mit Internetanbindung, kommt man zu folgendem Ergebnis: Während in den USA nur 0,3% die P2P-Streaming-Übertragung nutzten, betrug der Anteil in China 3,1% (bei PPStream, PPLive, UUSee). Mit PPLive, PPStream, SopCast [sop], TVAnts [tva] und UUSee kommen die kommerziell erfolgreichsten P2P-Streaming-Anbieter aus China. Auÿerhalb Chinas sind in erster Linie TVUnetworks (Sitz: Mountain View) mit dem TVUPlayer und Zattoo (Schweiz) bekannt, wobei Zattoo derzeit 2 nur in 6 europäischen Ländern 3 empfangen werden kann. Neben den Anbietern stammt auch ein Groÿteil der Konsumenten aus China (bei PPLive 70-80% [Zha10]), auf die das Streamingangebot zugeschnitten ist. Viele der aktuellen wissenschaftlichen P2P-Streaming-Arbeiten wurden an Universitäten in China oder Hongkong verfasst, an denen u.a. auch kommerzielle Systeme entstanden wie PPLive 4, Sop- Cast 5, TVAnts 6 oder CoolStreaming 7. China ist führend, sowohl was Nachfrage und Angebot als auch die Weiterentwicklung betrit. Wie lässt sich dieser Erfolg Chinas im Bereich P2P-Streaming erklären? Moderate Urheberrechtsbestimmungen Auf meine Nachfrage bei den Autoren von P2P-Streaming-Protokollen Xinyan Zhang (CoolStreaming [ZL+05]) und Sanjay G. Rao (Narada [CRZ00, CR+02]) gaben beide als Hauptgrund für die führende Rolle Chinas die moderaten Urheberrechtsbestimmungen des Landes an. Laut Zhang begünstigen diese das Klima für P2P-Streaming-Entwicklungen in China. In der westlichen Welt dagegen haftet P2P und P2P-Streaming anscheinend der Nimbus des Illegalen an, vor allem nachdem Unternehmen wie Napster [nap], Kazaa oder Cyber***-TV schlieÿen mussten. Beispielhaft für den schlechten Ruf von P2P-Streaming sind die negativen Reaktionen in den USA auf den P2P-Live-Stream von CNN, mit dem Benutzer die Übertragung der Amtseinführung Obamas verfolgen konnten. Die Benutzer mussten dazu ein Plugin herunterladen. CNN hatte vorab zwar mehrfach bekannt gegeben, dass die Übertragung per P2P erfolgt. Beim Download des Plugins selbst wies der Sender aber nicht ausdrücklich auf diese Tatsache hin. Aus dem Grund wurde CNN von mehreren Seiten vorgeworfen, seine Benutzer getäuscht zu haben. Microsoft beschuldigte CNN, die Uploadbandbreite der Benutzer entführt zu haben, andere sprachen sogar davon, dass CNN die Rechner seiner Benutzer gestohlen habe [new09]. Staatliche Förderung Die chinesische Regierung investiert einerseits in den Ausbau der Internetinfrastruktur. Im Jahre 2009 waren es 277,34 Milliarden Dollar, was einen Anstieg um 28,5% im Vergleich zum Vorjahr bedeutet [cnn10]. Die Regierung fördert andererseits den Einsatz von IPTV und damit indirekt von alternativen Übertragungstechnologien wie 2 Stand 08/ Deutschland, Frankreich, Schweiz, Groÿbritannien, Spanien, Dänemark 4 Huazhong University of Science and Technology 5 Fudan University 6 Zhejiang University 7 HKUST (Hong Kong University of Science and Technology), The Chinese University of Hong Kong, Simon Fraser University in Vancouver 8

9 1.1. ERFOLGSGESCHICHTE KAPITEL 1. EINFÜHRUNG P2P. Parteimitglieder in ländlichen Gegenden erhalten Fernunterricht mittels IPTV und das Ministerium für Informationsindustrie veranstaltet Forschungsrunden zusammen mit Herstellern und Telekommunikationsanbietern zur Entwicklung eigener IPTV-Standards [Ksh08]. Hohe Nachfrage nach Live-Übertragung von Groÿ- und Sportereignissen Die Übertragung von Groÿereignissen - wie Olympia 2008 in Peking, Chinas 60.Nationalfeiertag 2009 und die Weltausstellung in Schanghai wirken sich gewiss fördernd auf die Nachfrage nach Live-Streams aus. Darüber hinaus kann in China ein hohes Interesse an Sport-Übertragungen per P2P-Live-Stream verzeichnet werden. Das betrit in erster Linie Cricket (Indian Premier League), Fuÿball (English Premier League, Bundesliga, Spaniens La Liga, Italiens Serie A) und Basketball (NBA), letzteres vor allem seitdem chinesische Basketballer in der amerikanischen NBA spielen. Die Begegnung zwischen Dallas Mavericks und Houston Rocket, bei der Yao Ming aus China mitspielte, wurde im Dezember 2007 von seiner Landsleute live gestreamt (bei SopCast). Problematischerweise erfolgen viele Übertragungen unautorisiert. Je nach Sportart werden ca. 30% (Cricket), 75% (Basketball) bzw. 88% (Fuÿball) dieser unautorisierten Übertragungen über P2P-Netze gestreamt. Tabelle 1.1 listet unautorisierte Fuÿball-Streams aus der Saison 2007/2008 auf und gibt Aufschluss darüber, inwieweit die Streams P2Pbasiert erfolgten. Während hauptsächlich SopCast und TVAnts zum unautorisierten Streamen von Live-Sportereignissen genutzt werden (der Upload eigener Streams ist bei beiden möglich) schlossen PPLive und PPStream mit der amerikanischen NBA Partnerschaften ab, um autorisierte Live-Streams anbieten zu können [env08, oec09]. Liga Sites P2P-basiert Unicast User aus China User auÿerhalb Chinas Premier League % 37% 49% 51% Bundesliga 85 96% 4% 73% 27% La Liga 49 98% 2% 55% 45% Serie A 53 96% 4% 57% 43% Durchschnitt 91 88% 12% 57% 43% Tabelle 1.1: Websites mit unautorisierten Fuÿball-Streams (Saison 2007/2008) [env08] Konsumentenstruktur Chinesische Konsumenten gelten als technikan und adaptieren neue Techniken schnell. Bereits Mitte der 80er Jahre waren in China Konsumgebrauchsgüter so stark verbreitet wie in Japan oder Südkorea [Ksh08]. Internetuserstruktur Was das Internet betrit, bendet sich China immer noch in der Wachstumsphase. Die Anzahl der Internetuser ist 2009 im Vergleich zum Vorjahr um 28,9% auf insgesamt 384 Millionen gestiegen (siehe Abbildung 1.1). Trotz des stetigen Wachstums besaÿen 2009 weniger als ein Drittel (28,9%) der Bevölkerung in China einen Internetzugang, im Gegensatz zu rund 75% in den USA oder Japan. Dadurch ergibt sich auch eine andere Userstruktur. Gut 60% der User sind jünger als 30 Jahre, haben ein 9

10 1.2. MOTIVATION KAPITEL 1. EINFÜHRUNG Abbildung 1.1: Anstieg der Internetuser in China in Millionen und prozentual zum Vorjahr (nach [cnn10]) geringes Einkommen, 29% sind Studenten. Dies kann die Nachfrage nach kostenlosen Downloads und P2P-Streams erklären. Die zu Beginn dieses Abschnitts zitierten hohen Userbeteiligungen wurden beim Streaming von Live-Ereignissen erreicht. Dabei kann es zu sogenannten Flash-Crowds kommen, d.h. die Anzahl der User, die einen Kanal streamen möchten, steigt sprunghaft an und fällt nach kurzer Zeit wieder sehr schnell ab. Der Erfolg von P2P-Live-Streaming stellt durch diese kurzzeitig sehr hohe Nachfrage damit gleichzeitig eine groÿe technische Herausforderung dar. 1.2 Motivation Zum Thema P2P-Streaming wurde eine sehr groÿe Anzahl wissenschaftlicher Abhandlungen veröentlicht. In vielen Abhandlungen wird jeweils ein einzelnes P2P-Streaming- Protokoll behandelt. Die wenigen vergleichenden Arbeiten widersprechen sich teilweise, wenn es um die Kategorisierung der Protokolle geht. Zudem wurden Begriichkeiten bisher nicht einheitlich deniert. Dies macht es sehr schwierig, einen Überblick über diesen Forschungsbereich zu erhalten. Viele wissenschaftlich untersuchte Protokolle sind kommerziell zudem nicht von Interesse. Einige werden nur im Rahmen einer Abschlussarbeit entwickelt und nden in sonstigen 10

11 1.3. COOLSTREAMING KAPITEL 1. EINFÜHRUNG Abhandlungen keine Erwähnung. Kommerziell erfolgreiche Systeme wie z.b. PPLive, PPStream und SopCast sind im Realbetrieb erprobt, aber deren Protokolleigenschaften werden nicht veröentlicht. Das Ziel dieser Arbeit ist daher, einen systematischen Überblick über die wesentlichen Charakteristiken von P2P-Streaming zu liefern und aufzuzeigen, worin sich P2P- Streaming-Protokolle unterscheiden. Es folgt die Veranschaulichung der Arbeitsweise eines ausgewählten P2P-Streaming-Protokolls mittels Analyse und Implementierung. Da der Schwerpunkt der aktuellen P2P-Streaming-Forschungen auf Protokollen liegt, mit denen Inhalte live gestreamt werden können, sollte das ausgewählte Protokoll für Live- Streaming-Anwendungen konzipiert sein. Aufgrund der groÿen Anzahl von Protokollen aus China bot es sich zudem an, ein Protokoll aus diesem Land zu berücksichtigen. Das Protokoll sollte auÿerdem von kommerzieller und wissenschaftlicher Bedeutung sein sowie klar und übersichtlich strukturiert, um den komplexen Streamingablauf verdeutlichen und erweitern zu können. CoolStreaming erfüllt alle diese Anforderungen. 1.3 CoolStreaming Die Autoren um Xinyan Zhang beschreiben in [ZL+05] DONet, ein Data-driven Overlay Network. So wie bei den meisten im Realbetrieb eingesetzten P2P-Streaming-Systemen üblich, arbeitet es datengesteuert (data-driven), d.h. der Empfänger fordert fehlende Daten beim Sender an. Damit unterschied es sich von seinen Vorgängern und wird daher mitunter als das erste echte P2P-Streaming-System bezeichnet. Bereits im Mai 2004 wurde eine Internet-basierte DONet-Implementierung unter dem Namen CoolStreaming in der Version 0.9 veröentlicht. Da CoolStreaming nicht nur gut klang, sondern auch eine technische Konnotation hatte (Cooperative Overlay Streaming), wurde das System unter dieser Bezeichnung eingesetzt und bekannt. Bis zum Sommer 2005 gab es Millionen Downloads und bis zu gleichzeitige User aus 24 Ländern bei einer durchschnittlichen Streamingrate von 400 kbps. CoolStreaming war auch die erste Software, die Live-TV-Übertragungen über das Internet anbot. Die CoolStreaming-Autoren gaben in [ZL+05] Protokoll-Details bekannt, im Unterschied zu den danach entwickelten Systemen wie PPLive, SopCast, TVAnts und PPStream, welche sehr schnell an Bekanntheitsgrad gewannen (siehe Abbildung 1.2) wurde eine komplett überarbeitete Version von CoolStreaming vorgestellt ([LX+08, XL+07]) die jedoch in wissenschaftlichen Abhandlungen kaum Erwähnung ndet. CoolStreaming ist die Basistechnologie des Unternehmens Roxbeam Media Network Corporation, das 2006 in Zusammenarbeit mit Yahoo Live-IPTV-Programme anbot [Zha07]. Urheberrechtsstreitigkeiten führten u.a. dazu, dass unter der gleich lautenden Adresse nicht das in dieser Arbeit besprochene System zu nden ist. 11

12 1.4. AUFGABENSTELLUNG KAPITEL 1. EINFÜHRUNG Abbildung 1.2: Nachfrage nach kommerziellen P2P-Streaming-Systemen (Stand Mai 2010) [goo10] 1.4 Aufgabenstellung und Begrisklärung Die Annäherung an das Thema der Arbeit Analyse und Implementierung eines oenen Streaming-Protokolls auf P2P-Basis erfolgt durch Klärung und Abgrenzung der Begrie Protokoll, oen, P2P und Streaming sowie weiterer Begrie, die auf diesen Wörtern aufbauen. Protokoll Ein Protokoll ist ganz allgemein eine Folge von Regeln, d.h. eine Folge von mehreren fest vorgegebenen Schritten, mit denen die Rahmenbedingungen einer Kommunikation festgelegt werden [Bra05, FH07, Sch07]. Für den Aufbau und Betrieb eines P2P-Streaming-Systems sind mehrere Protokolle (z.b. für Partnerverwaltung, Gruppenverwaltung) und auch kommunikationsübergreifende Komponenten erforderlich (wie der Scheduler, siehe Abschnitt 4.3.1). Für diese Arbeit deniere ich ein P2P-Streaming-Protokoll als Einheit aus verschiedenen Protokollen und Algorithmen, die zum Aufbau und Test eines P2P-Streaming-Systems (in diesem Fall CoolStreaming) benötigt werden. Oenes Protokoll Damit ein Protokoll als oen bezeichnet werden kann, muss der Quellcode nicht zwingend oen gelegt werden. Wesentliche Protokolleigenschaften wurden aber von den Entwicklern veröentlicht und sind bekannt. Dies trit für das Protokoll CoolStreaming zu. Im Gegensatz dazu stehen z.b. PPLive und SopCast, deren Charakteristiken nur über Reverse-Engineering zu ermitteln sind. P2P In einem P2P-System kommunizieren die Rechnerknoten (die Peers) gleichberechtigt ohne zentrale Koordination, teilen sich die Ressourcen (vor allem Bandbreite) und stellen gemeinsam eine Anwendung zur Verfügung [MS07]. Siehe auch Abschnitt 3.1. Streaming Streaming ist von Stream (engl. für Strom) abgeleitet und bezeichnete zunächst die von Holzfällern angewandte Methode, Baumstämme hintereinander über Ströme und Flüsse zu transportieren [Pia07]. 12

13 1.4. AUFGABENSTELLUNG KAPITEL 1. EINFÜHRUNG In der Informatik ist ein Stream ein im weitesten Sinn gleichförmiger Fluss digitaler Daten. Beim Streaming - genauer Multimedia-Streaming/Media-Streaming - werden Audiound/oder Videodaten über ein IP-Netzwerk übertragen und kontinuierlich verwertet [FH07]. Zum Verständnis der dahinter liegenden Konzepte wird in Kapitel 2 erörtert, welche Daten in welchem Format gestreamt werden können sowie wo, wie und wofür Streaming eingesetzt wird (siehe Abbildung 2.1). P2P-Streaming-System/-Lösung Die Begrie P2P-Streaming-Lösung und P2P-Streaming-System werden in der Fachliteratur meist analog verwendet. Um die Begrie P2P- Streaming-System und P2P-Streaming-Protokoll voneinander abzugrenzen, deniere ich ein P2P-Streaming-System wie folgt: Die praktische Umsetzung betreend kann ein P2P-Streaming-System als Implementierung eines P2P-Streaming-Protokolls bezeichnet werden. Die Architektur betreend ist ein P2P-Streaming-System eine Einheit bestehend aus Software- und Hardwarekomponenten, die eine Architektur für P2P-Streaming zur Verfügung stellen. P2P-Streaming-Applikation/-Anwendung/-Software Ist ein System mit einer Benutzerschnittstelle ausgestattet und direkt lauähig, spricht man von einer Applikation [FH07]. Eine P2P-Streaming-Applikation stellt einem Peer eine Schnittstelle zur Verfügung, wodurch dieser in einem dedizierten P2P-Streaming-Netz Mitglied werden und Daten streamen kann. Die Applikation umfasst eine Schnittstelle zu einem oder mehreren gängigen Medienplayern (bei kommerziellen Produkten in erster Linie Windows Media Player). P2P-Streaming-Netzwerk/-Netz/-Overlay Die Menge der Peers in einem P2P-Streaming-System lässt sich formal als endliche, nicht leere Knotenmenge V beschreiben, bestehend aus n Peers P i : V = {P i 1 i n, n N} Die Peers P i sind miteinander in einem Netzwerk verbunden. Die Netzwerk- oder Verbindungsstruktur kann dabei durch das Protokoll bestimmt werden. Ist ein Peer P i mit einem Peer P j verbunden, dann wird P j als Nachbar oder Partner (bei CoolStreaming) von P i bezeichnet. Die Menge der Partnerschaftsbeziehungen in einem P2P-Streaming-Netzwerk lässt sich formal als Menge E aus Kanten beschreiben, wobei E eine Teilmenge der Menge aller möglichen Partnerschaftsbeziehungen zwischen zwei Peers P i und P j darstellt: E {(P i, P j ) P i, P j V i j} 13

14 1.5. GLIEDERUNG DER ARBEIT KAPITEL 1. EINFÜHRUNG Ein P2P-Streaming-Netzwerk kann somit als ein gerichteter Graph G deniert werden, als Tupel bestehend aus der Peermenge V und der Menge E aus Partnerschaftsbeziehungen: G = (V, E) Im P2P-Bereich tragen Netzwerke, die auf einer bestimmten Datenstruktur (z.b. CAN [RF+00]) oder einem Protokoll (z.b. Gnutella [Cli01]) aufbauen, den Namen dieser Datenstruktur oder des Protokolls. So spricht man vom CAN-Netzwerk oder Gnutella- Netzwerk. 1.5 Gliederung der Arbeit In Kapitel 2 werden zunächst die Grundlagen des Streamings erklärt. Dabei wird insbesondere erläutert, welche Daten gestreamt werden können, welche Anwendungen und Methoden zu unterscheiden sind und über welche Architekturen Streaming realisiert werden kann. In Kapitel 3 wird dargelegt, was P2P bedeutet, sowie eine Einführung in den Bereich P2P-Streaming gegeben, wobei die grundlegenden Konzepte gezeigt werden. Aufbauend auf den beiden genannten Kapiteln erfolgt in Kapitel 4 die Analyse des CoolStreaming-Protokolls, indem CoolStreaming anhand seiner Protokollcharakteristiken sowie seiner Performance mit anderen P2P-Live-Streaming-Protokollen verglichen wird. In diesem Kapitel werden auÿerdem 21 P2P-Live-Streaming-Protokolle in einem tabellarischen Vergleich gegenübergestellt (siehe Tabelle 4.1). In Kapitel 5 wird die Implementierung des CoolStreaming-Protokolls beschrieben und im darauf folgenden Kapitel 6 evaluiert. Im abschlieÿenden Kapitel 7 werden die Erfahrungen bei der Implementierung mit dem Simulator P2PNetSim geschildert und ein Ausblick auf zukünftige Entwicklungen in den Bereichen Streaming und P2P-Streaming gegeben. 14

15 2 Theoretische Grundlagen - Streaming Ziel dieses Kapitels ist, als Grundlage für die späteren Kapitel den Begri Streaming vollständig abzuklären. Dazu wird die Top-Down-Methodik angewandt und auf vier wesentliche Perspektiven bzw. Fragestellungen eingegangen, die in Abbildung 2.1 dargestellt sind. Streaming Was? Wo? Wofür? Wie? Audio-/Videodaten komprimiert LAN/WAN Anwendungen? Methoden? Verbindungsarten? Architekturen? Abbildung 2.1: Perspektivische Annäherung Beim Streaming werden Audio- und/oder Videodaten über ein IP-Netzwerk (LAN, WAN) übertragen, wobei der Schwerpunkt dieser Arbeit auf der Übertragung im Internet liegt. Die Daten müssen zuerst kodiert und komprimiert werden. Zunächst werden die grundlegenden Schritte dieses Prozesses erklärt. Es folgt eine Übersicht über Standards und Verfahren, wobei der Unterschied zwischen Codecs (z.b. MPEG-4 Part 10), Containerformaten (z.b. MP4) und kodierten Dateiformaten (z.b..mp4) am Beispiel des MPEG- Standards beleuchtet wird. Anschlieÿend wird erläutert, für welche Anwendungen, nach welchen Methoden und über welche Verbindungsarten bzw. Architekturen Streaming realisiert werden kann. 2.1 Audio-/Videokomprimierung Die ersten bekannten Versuche, Multimediadaten zu digitalisieren, stammen aus den frühen 90er Jahren. Sun Microsystems entwickelte Audiodateien mit der Dateiendung.au. Diese enthielten einfachste Audiodaten, die auf dem Rechner wiedergegeben werden konnten. Später konnte Apples QuickTime bereits Videodaten abspielen, die allerdings für den Transport über das Internet zu groÿ waren. Der Durchbruch beim Streaming gelang RealNetworks, indem es die Daten in ein ausreichend kleines Format brachte. RealNetworks war mit seinem RealPlayer lange Marktführer, wurde aber aufgrund schlechter Preispolitik und mangelnder Bedienerfreundlichkeit inzwischen von 15

16 2.1. AUDIO-/VIDEOKOMPRIMIERUNG KAPITEL 2. STREAMING Apple QuickTime, Microsoft Windows Media Player und Adobe Flash Player zurückgedrängt Digitalisierung analoger Daten Damit das menschliche Auge einzelne Bilder als fortlaufenden Film wahrnimmt, müssen ca. 15 bis 25 einzelne Bilder pro Sekunde abgespielt werden. Man spricht in diesem Zusammenhang von Bildrate/Framerate oder fps (frames per second). Die beiden verbreiteten Videoformate PAL 1 und NTSC 2 unterscheiden sich bzgl. der Framerate. PAL arbeitet mit 25fps, d.h. jedes Bild wird für eine Dauer von 40ms gezeigt. Im Gegensatz dazu beträgt die Framerate bei NTSC 29.97fps, so dass aller 33ms das Bild wechselt. Ziel der Digitalisierung von Videosignalen für den WAN-Transport ist es, eine möglichst geringe Datenmenge zu erhalten. Zu diesem Zweck digitalisiert und komprimiert ein MPEG-Encoder die Videosignale redundanzfrei, d.h. es werden nicht jeder Frame einzeln abgespeichert, sondern nur die Bilddierenzen. Nach dem MPEG-Standard unterscheidet man drei Arten von komprimierten Frames: I-Frame (Intra-Frame/Key-Frame) Das komplette Bild wird kodiert ohne Berücksichtigung vorheriger oder nachfolgender Frames. Ein I-Frame dient sozusagen als Referenzbild und wird z.b. bei einem Szenewechsel erstellt. P-Frame (Predicted-Frame) Ein P-Frame enthält die Dierenz zwischen dem aktuellen Bild und dem letzten vorangegangen I-Frame/P-Frame. B-Frame (Bidirectional-Frame) Ein B-Frame wird mit Hilfe von bidirektionaler Kompression kodiert. Dabei wird die Dierenz zwischen dem aktuellen Bild und dem letzten vorangegangen I-Frame/P-Frame kodiert sowie die Dierenz zwischen dem aktuellen Bild und dem nachfolgenden I-Frame/P-Frame. Frames werden in sogenannten GOPs gruppiert, wobei GOP die Kurzform von group of pictures ist. Am Anfang einer jeden GOP steht ein I-Frame, gefolgt von mehreren P-Frames oder B-Frames. Muss ein neuer I-Frame erstellt werden, beginnt ein neuer GOP. Dies ist beispielsweise bei einem kompletten Szenewechsel der Fall. Jeder Frame wird zudem in Makroblöcke von jeweils 16x16 Pixel zerlegt. Zu jedem Makroblock gibt es einen Bewegungsvektor (motion vector), der die Bewegung des Makroblocks zwischen zwei aufeinander folgenden Bildern beschreibt. Die Bewegung wird durch die Angabe der Richtung und der Entfernung beschrieben. Zur Digitalisierung analoger Audiodaten werden pro Sekunde Tausende Muster (engl. samples) des analogen Signals erfasst. Die Abtastrate (engl. sample rate/sampling rate) gibt die Frequenz an, mit der die analogen Signale abgegrien werden. Folgende Abtastraten sind gebräuchlich: 1 in Europa 2 in Nord-/Südamerika, Japan, Korea, Taiwan 16

17 2.1. AUDIO-/VIDEOKOMPRIMIERUNG KAPITEL 2. STREAMING 32kHz: Für FM-Radio und andere Audio-Broadcasts werden meist Muster pro Sekunde abgegrien. 44,1kHz ist die übliche Abtastrate für Audio-CDs. 48kHz wird bei professionellen Anwendungen, u.a. für das Fernsehen, verwendet. 96kHz wird von neueren professionellen Anwendungen eingesetzt. Für Stereoaufnahmen verdoppelt sich zudem die Abtastrate. Statt einem Sample werden jeweils zwei Muster abgegrien für den linken und den rechten Audiokanal. Digitale Audiosignale liegen komprimiert oder unkomprimiert vor. Durch sogenanntes Perceptual-Encoding können Audiosignale ezient komprimiert werden. Hierbei werden nur die vom menschlichen Gehör wahrnehmbaren Töne gespeichert. Ausgeltert werden beispielsweise zu hohe Frequenzen sowie Töne, die weniger als eine Millisekunde dauern oder aufgrund einer hohen Umgebungslautstärke zu leise sind Codecs, Datei- und Containerformate Ein Codec (Kunstwort aus coder/decoder) deniert, wie analoge Audio- oder Videosignale in digitale Daten umgewandelt werden und umgekehrt. Codecs unterscheiden sich bzgl. mehrerer Faktoren, u.a. der Kompressionsart (verlustfrei oder verlustbehaftet) und der erzeugten Bitrate/Datenrate. Verlustbehaftete Kompressionen wenden in der Regel die im vorherigen Abschnitt geschilderten Verfahren an. Die Kodierung erzeugt für Audio- und Videodaten zwei einzelne Streams, das Audiound das Videoformat. Ein Muxer (oder Multiplexer) multiplext und synchronisiert beide Streams und legt sie in ein Containerformat ab, zusammen mit den für die synchrone Ausgabe erforderlichen Metainformationen, gegebenenfalls Untertiteln und weiteren Tonspuren. Das Containerformat speziziert, welche Daten miteinander in dem Format abgelegt werden können. Das Containerformat kann auch als Datei abgespeichert werden, deren Dateiendung sich nach der Bezeichnung des Containerformats richtet. Hier folgen einige Beispiele für bekannte Containerformate: AVI/Audio-Video Interleave (Dateiendung.avi): 1992 von Microsoft vorgestellt, wurde das Format von Microsoft nicht weiter gepegt, aber von anderen erweitert. AVI stellt ein vergleichsweise einfaches Format dar. Es unterstützt inhärent weder Untertitel noch B-Frames. In AVI können verschiedenste Audio- und Videoformate miteinander kombiniert werden. Häug ndet sich MP3 zusammen mit älteren Videoformaten. Das neuere Videoformat H.264 kann mangels B-Frame-Unterstützung nicht problemlos verwendet werden. PS/Programmstream (.ps) ist ein Format, das für nicht störungsanfällige Übertragungen eingesetzt wird, z.b. DVD. TS/Transportstream (.ts) stellt ein Containerformat dar, das für den Einsatz bei störungsanfälligen Übertragungen geeignet ist, z.b. Übertragungen per Satellit, Antenne, Kabel/CATV. VOB/Video Object + IFO (.vob,.ifo), ein Containerformat für DVDs, enthält meist mit MPEG-1 Part 2/MPEG-2 Part 2 kodierte Videodaten und mit dem AC3-Audiocodec erstellte Audiodaten. 17

18 2.1. AUDIO-/VIDEOKOMPRIMIERUNG KAPITEL 2. STREAMING Der MPEG-Standard Die Moving Pictures Experts Group hat ab 1991 unter dem Namen MPEG diverse Standards zur Kompression von Audio- und Videodaten veröentlicht MPEG-Videocodecs Die Videostandards wurden jeweils zu Paketen zusammengefasst und sind unter dem Namen MPEG-1, MPEG-2 und MPEG-4 bekannt. Einen MPEG-3-Video-Standard gibt es nicht. Dieser wurde zwar geplant, aber die Entwicklungen zu MPEG-3 waren noch vor der Fertigstellung von MPEG-2 abgeschlossen. Daher wurden die MPEG-3-Erweiterungen in MPEG-2 integriert und MPEG-3 übersprungen. Der erste Standard MPEG-1 sollte ermöglichen, Video-CDs zu erstellen folgte MPEG-2, der u.a. das Multiplexen verschiedener Video- und Audiostreams ermöglicht. MPEG-2 wird für Standard-DVDs verwendet und ndet sich in vielen Geräten, z.b. in Set-Top-Boxen, digitalen Satellitenreceivern und DVD-Playern. MPEG-4 (ab 2000) umfasst insbesondere zwei Standards für Videoformate: MPEG-4 Part 2 und MPEG-4 Part 10 (auch bekannt als H.264 oder MPEG-4 AVC). Mit H.264 können Videos im Unterschied zu MPEG-2 bei gleich bleibender Qualität bis zu 50% ezienter komprimiert werden. Dadurch wird die Übertragung von High-Denition-Videos (kurz HD-Videos) über IP-Netze möglich. H.264 wird für Blu-ray-Disks und HD-DVDs eingesetzt. Codecs werden nach diesen Standards erstellt. Für jeden Standard gibt es mehrere Pro- le und Level. Die Prole spezizieren Merkmale, z.b. ob Bilder zu B-Frames kodiert werden können. Die Level geben maximale Auösungen (bei MPEG-2) bzw. Bitraten an (bei MPEG-4). Für MPEG-2/MPEG-4-Codecs ergeben sich damit verschiedenste Kombinationen aus Prol und Level, wobei nicht alle Kombinationen von Herstellerseite unterstützt werden. Mit höherem Prol steigt die Komplexität und damit die Rechenlast beim Kodieren. Das einfachste Prol von H.264 (Baseline-Prol) unterstützt beispielsweise keine B-Frames, wodurch die Komplexität und die Verzögerung bei der Kodierung verringert werden. Aufgrund der geringeren Verzögerung ist das Baseline-Prol für Videokonferenzen und mobile TV-Applikationen geeignet MPEG-Audiocodecs Gebräuchliche MPEG-Audiocodecs sind MPEG Layer 1, MPEG Layer 2, MPEG Layer 3 (bekannt als MP3) sowie MPEG Advanced Audio Coding (AAC). Nahezu alle Containerformate unterstützen MP3, das meist mit älteren Videoformaten (d.h. älter als H.264) gemuxt wird. AAC wird nur in Verbindung mit MPEG-2/4-Video verwendet (vorzugsweise mit H.264) und unterstützt Abtastraten von bis zu 96kHz Zusammenfassung Ein Containerformat enthält nach spezizierten Codecs erzeugte Audio- und Videoformate. Der Transport und die Steuerung des gemuxten Streams ist je nach Containerformat 18

19 2.2. STREAMING-ANWENDUNGEN KAPITEL 2. STREAMING und Anwendung mit verschiedenen Protokollen möglich. RTP (Real-Time Transport Protocol [SC+96]) und RTSP (Real Time Streaming Protocol [SRL98]) beispielsweise sind oene Protokolle für den Transport und die Steuerung. RTP transportiert meist PS-/TS- Pakete (Programm-/Transportstream). RTSP startet z.b. eine Streamingsession. Adobe, Apple Computer, RealNetworks und Microsoft bieten jeweils ein komplettes Framework zum Streamen von Multimediadaten an, das sich aus Codecs, eigenen Containerformaten, kostenfreien Playern auf Clientseite, kostenpichtigen Streamingservern 3 und Protokollen für Datentransport und -steuerung zusammensetzt. In Tabelle 2.1 sind einige Standardkombinationen (aus Containerformaten, Videocodecs, Audiocodecs und Protokollen) und deren Anwendungen aufgelistet. Weitere Kombinationen sind möglich. Beim Streamingprozess müssen der Server und die Clientplayer die gleichen Kodierungen einsetzen. Klassische Push-Streaming-Server unterstützen meist mehrere Playerformate und bieten zudem Kompressionen für jede Kombination aus Playerformat und Verbindungsgeschwindigkeit (Dial-Up, Medium, High) an. [cha07, cha09, Sim08] 2.2 Streaming-Anwendungen Das Streaming von Audio- und Videodaten ermöglicht eine Reihe von Anwendungen, z.b. IP-Telefonie, Videokonferenzen 4, Internet-Radio oder Internet-TV. In Bezug auf Internet- TV muss zwischen Web-TV (auch Internet-Video genannt) und IPTV unterschieden werden. Web-TV kann über P2P-Streaming-Netze realisiert werden, IPTV dagegen nicht. Anhand folgender Denitionen können die Begrie Web-TV und IPTV voneinander abgegrenzt werden: Web-TV (Internet-Video) Verschiedenste Beiträge werden über Overlaynetze im öffentlichen Internet gestreamt. Dabei kommen unterschiedliche Formate und Protokolle zur Verwendung (siehe dazu Tabelle 2.1). Der Empfang erfolgt auf dem Rechner mittels spezieller Software, auf Consumer-Fernsehern mittels Netzwerkadapter oder auf portablen Videoplayern. IPTV Analog zum Kabelfernsehen stellen IPTV-Anbieter (z.b. Telekom, Alice) professionell erstellte TV-Inhalte in hoher Qualität zur Verfügung. Die Inhalte werden über eigene Netzwerke übertragen, die unabhängig vom Internet sind. Die IPTV-Konsumenten schlieÿen ein kostenpichtiges Abonnement ab und empfangen die Inhalte auf ihrem Consumer-Fernseher mittels einer Set-Top-Box. Mitunter wird in der Fachliteratur Web- TV fälschlicherweise als IPTV bezeichnet (siehe [HLR08, SF+08]). [Sim08, tuc10] 2.3 Streaming-Methoden Während man gemeinhin beim Streaming davon ausgeht, dass die Daten, die kontinuierlich übertragen und verwertet werden, nicht lokal gespeichert werden müssen, hat sich 3 zum Push von Daten 4 mit Videocodecs H.262/MPEG-2 und H

20 2.3. STREAMING-METHODEN KAPITEL 2. STREAMING Beschreibung Containerformat (Dateiendung) Videocodec/-format Audiocodec/-format Datentransport-/steuerung Adobe Flashplayer Flash Video/FLV (.v) Apple QuickTime (Standard-Container für QuickTime) QuickTime (.mov,.qt) H.264 (früher: Sorenson MPEG-4 Part 3 (AAC) RTMP (proprietär) Spark, On2 VP6) H.264 MPEG-4 Part 3 (AAC) RTP/RTSP DivX/XviD-Streaming DivX (.divx) MPEG-4 Part 2 MP3 HTTP (Download and Play) DVB (Digitales Fernsehen), z.b. DVB-T MPEG-2 MPEG-2 MPEG-Audio Layer II RTP/RTSP Transportstrom (.ts) MP4-Standard-Container MPEG-4 Part H.264 MPEG-4 Part 3 (AAC) HTTP (Download and Play) 12/MP4 (.mp4) Ogg-Standard-Container (Container für freie Xiph.org-Codecs) RealPlayer (Standard-Container für RealMedia) WebM-Container von Google (freier Container für HTML5) Windows Media Player (Standard-Container für Windows Media) Ogg (.ogg) Ogg Theora (basiert auf On2 VP3.2) Ogg Vorbis HTTP (Download and Play), Wiedergabe mittels <audio>/<video> in HTML5 ohne Browserplugin (derzeit unterstützt durch Opera, Mozilla Firefox und Google Chrome) RMVB (.rm,.rmvb) RealVideo RealAudio RTP/RTSP WebM (.webm) basiert auf Matroska-Container (MKV) Advanced Systems Format/ASF (.asf) On2 VP8 (seit dem Aufkauf von On2 im Februar 2010 im Besitz von Google) Windows Media Video WMV9/VC1 Ogg Vorbis HTTP (Download and Play), Wiedergabe mittels <audio>/<video> in HTML5 ohne Browserplugin (derzeit unterstützt durch Opera, Mozilla Firefox und Google Chrome) WindowsMedia Audio MMS (proprietär)/rtsp Tabelle 2.1: Gängige Kombinationen aus Container, Codecs und Protokollen [Sim08, tuc10] 20

21 2.4. VERBINDUNGSARTEN KAPITEL 2. STREAMING eine weitere Methode entwickelt, die ebenfalls als Streaming bezeichnet wird und bei der die gestreamten Daten lokal abgespeichert werden. Die letztere Methode wird in der Fachliteratur Pseudo-Streaming genannt im Gegensatz zu True-Streaming (echtem Streaming): Pseudo-Streaming Man spricht hier auch vom Open-after-downloading-Modus. Die Wiedergabe erfolgt erst nach dem Download der Daten. Die Daten werden mit HTTP oder FTP übertragen. Da in erster Linie HTTP eingesetzt wird, ist auch die Bezeichnung HTTP-Streaming gebräuchlich. Man unterscheidet hier: Download & Play: Der Stream wird in einer Datei gespeichert. Erst nach vollständigem Download dieser Datei können die Daten auf dem Clientrechner wiedergegeben werden. Die Wiedergabe ist damit unabhängig von der Bandbreite, aber die Verzögerung bis zum Beginn der Wiedergabe höher als bei True-Streaming. Progressive Download & Play (siehe YouTube): Der Stream wird in Stücke zerlegt, die einzeln heruntergeladen und wiedergegeben werden. Dadurch ist eine sukzessive Wiedergabe auch dann möglich, wenn die verfügbare Bandbreite geringer als die Streamingrate sein sollte. True-Streaming/Echtes Streaming Die Wiedergabe (das Playback) der Daten ist so gut wie gleichzeitig mit dem Datenempfang möglich. Man spricht daher auch vom Playwhile-downloading-Modus [WLQ06, XH+02]. Gestreamt werden kann nur, falls die Downloadbandbreite mindestens so hoch ist wie die Streamingrate (im Internet meist ca. 400 kbps). Man unterscheidet hier: Live-Streaming: Es erfolgt die Übertragung von Live-Inhalten (z.b. von Sportereignissen wie Bundesliga-Spielen). Video-On-Demand/VoD: Die Inhalte (z.b. Spiellme) werden bei Bedarf angefordert und gestreamt. Der Schwerpunkt dieser Arbeit liegt auf Protokollen für echtes Streaming (also True- Streaming), insbesondere für Live-Streaming. [cha09, Sim08, tuc10] 2.4 Verbindungsarten Beim echten Streaming (True-Streaming) kann der Nachrichtenversand per Unicast, Broadcast, Narrowcast oder Multicast (engl. cast = werfen) erfolgen, abhängig davon, wie Sender und Empfänger verbunden sind. Unicast (1:1) Ein Sender schickt Daten an einen Empfänger. Internetübertragungen basieren konzeptionell auf Unicast aufgrund von Punkt-zu-Punkt-Verbindungen bzw. Endsystem-zu-Endsystem-Verbindungen (IP). Beispiele: Klassisches Streaming, bei dem 21

22 2.5. STREAMING-ARCHITEKTUREN KAPITEL 2. STREAMING sich jeder Client mit dem Streamingserver verbindet. Klassische Internetanwendungen wie -Versand, FTP-Download, HTTP-Download. Broadcast (1:alle) Ein Sender schickt an alle Empfänger. Beispiele: Broadcastnachrichten im LAN, Empfang von Radio-/TV-Sendungen mittels Antenne/Satellit/Kabel 5, mobiles TV über DVB-H(andheld). Narrowcast (1:k) Ein Sender schickt an einige wenige Empfänger. Beispiele: Versand von Newslettern, Übertragung von Vorstandsreden an Mitarbeiter, Übertragung der Aufnahmen von Überwachungskameras an den Sicherheitsdienst. Multicast (1:n, m:n) Ein oder mehrere Sender schicken an mehrere Empfänger. Beispiele: Audio-/Videokonferenzen, IP-Telefonie. Theoretisch kann jede der vier vorgestellten Verbindungsarten zum Streamen von Multimediadaten verwendet werden. Broadcast über das Internet ist allerdings nicht praktikabel. Broadcast über das LAN ist zwar möglich, aber aufgrund des hohen Datenaufkommens beim Streamen und der Kollisionsgefahr im LAN nicht ratsam. Für Live-Streaming bieten sich Multicast-Verbindungen mit der Möglichkeit des Versands an eine Empfängergruppe an. Bei der Implementierung von Multicast als IP-Multicast (siehe Abschnitt ) verschickt die Quelle - im Unterschied zu Unicast - an mehrere Empfänger nur einen einzigen Stream, der erst an den Verzweigungen vervielfältigt wird (siehe Abbildung 2.2). Die Aufgabe der Vervielfältigung übernehmen hier die Router, mit denen die Endhosts (Hosts 1,2 in Abbildung 2.2) verbunden sind. Die mit den Endhosts verbundenen Router müssen dazu Multicast-fähig sein (siehe auch Abschnitt ). [Sim08] 1 1 S Router S Router IP-Multicast 2 Unicast 2 Abbildung 2.2: Unicast und IP-Multicast (nach [Sim08]) 2.5 Streaming-Architekturen Echtes Streaming (True-Streaming) im Internet ist über verschiedene Architekturen möglich, d.h. über Client/Server, Content-Delivery-Netzwerke (CDNs), IP-Multicast oder Application-Level-Multicast (ALM). Abbildung 2.3 zeigt diese Streaming-Architekturen in Abhängigkeit voneinander. 5 Hybrid-Fiber-Coax-Kabelnetzwerk 22

23 2.5. STREAMING-ARCHITEKTUREN KAPITEL 2. STREAMING Streaming-System zentralisiert (Client-Server) dezentralisiert Router-basiert (IP-Multicast) nicht Router-basiert Infrastruktur-basiert (CDN) Application-Level-Multicast Endsysteme mit Infrastruktur-Support (AnySee) Endsysteme ohne Infrastruktur-Support Abbildung 2.3: Streaming-Architekturen (nach [LR+08, Vil09]) Die in dieser Arbeit behandelten Protokolle (wie CoolStreaming) setzen Application- Level-Multicast (ALM) ein. Die Endsysteme verteilen dabei selbst den Stream. Zusätzlicher Infrastruktur-Support (z.b. durch Content-Delivery-Server) ist nicht erforderlich Klassische Architekturen Client/Server Bei klassischen Client/Server-basierten Streaming-Systemen verbinden sich die Clients mit dem Quellserver und der Content wird direkt vom Server zum Client gestreamt. Im Unterschied zu P2P-basierten Systemen leiten die Knoten die empfangenen Daten nicht an andere Knoten weiter. Solch zentralisierte Systeme sind einfach und leicht zu implementieren [E08, LR+08]. Prozessorleistung, Speicherkapazität, I/O-Durchsatz sowie die begrenzte Netzwerkbandbreite werden aber zum Flaschenhals des Systems [WLQ06]. Da die Bandbreite der Clients ungenutzt bleibt, ist hier mit hohen Kosten für die Bandbreitenlieferung zu rechnen [LGL08] sowie für Start und Betrieb des Streaming-Servers [WLQ06]. Client/Server- Systeme sind nur beschränkt skalierbar und stellen durch den zentralen Server einen Single-Point-Of-Failure dar, weshalb sie leichter angegrien werden können und zudem weniger zuverlässig sind im Hinblick auf die Ausfallsicherheit CDN CDN-/Content-Delivery-Network-basiertes Streaming ist eine Variation des Client/Server-Modus. Dienstanbieter wie Akamai oder Limelight positionieren Proxys an strategisch wichtigen Standorten im Internet (network edges). Die zu streamenden Daten liegen 23

24 2.5. STREAMING-ARCHITEKTUREN KAPITEL 2. STREAMING auf Content-Delivery-Servern. Die User werden zum nächstgelegenen Content-Delivery- Server weitergeleitet und holen sich von dort die Daten per Unicast. Im Unterschied zu reinen Client/Server-Lösungen sind die Anfangsverzögerungen kürzer, der Netzwerkverkehr geringer und es können mehr Endnutzer bedient werden. Ein Broadcaster kann bei Bedarf Content-Delivery-Server anmieten. Für einen ächendeckenden Einsatz müssen allerdings in der Nähe jedes möglichen Empfängers Content-Delivery-Server eingesetzt werden, was sehr hohe Infrastrukturkosten verursacht. Die Dienstanbieter stoÿen auÿerdem bei stark nachgefragten Broadcasts an die Grenzen der möglichen Bandbreitenlieferung zu Obamas Amtseinführung verlieÿ sich CNN daher nicht nur auf Dienstanbieter Akamai, sondern verteilte den Live- Stream auch per P2P. Von 1,3 Millionen gleichzeitigen Usern wurden jeweils User per CDN bzw. per P2P bedient [new09]. Akamai allein hätte die akkumulierte Bandbreite von ca. 495 Gbps (bei einer veranschlagten Streamingrate von 400 kbps) nicht zur Verfügung stellen können. Dazu kommen hohe Kosten, die Anbieter von CDNs für die Anmietung der Server verlangen. [LGL08, LR+08, WLQ06] Multicast über Internet IP-Multicast 1990 schlug Deering vor, Multicast auf der IP-Schicht (Schicht 3 im ISO/OSI-Referenzmodell) zu implementieren [DC90]. Daraus entwickelte sich IP-Multicast (Native- IP-Multicast/Native-Multicast). Der Dienst von IP-Multicast besteht darin, Daten an die Teilnehmer einer Gruppe zu senden. Die Teilnehmer können sich mittels IGMP- Nachrichten (Internet Group Management Protocol [Fen97]) zu einer Gruppe an- und abmelden. Das setzt voraus, dass der erste Router, mit dem sich der Teilnehmer verbindet, IP-Multicast-fähig ist und die Gruppenverwaltung vornehmen kann. Die Verteilung der Nachrichten erfolgt über eine baumförmige Struktur, den Multicast- Baum, der von den IP-Routern im Netzwerk gebildet wird [LC+05]. Die Nachrichten werden zwischen den Router-Knoten wie bei Unicast weitergereicht. An den Blättern des Routerbaumes kopieren die Router die Nachrichten und verteilen sie an alle angemeldeten Endknoten. Für die Errichtung des Multicast-Baumes gibt es verschiedene Routing- Protokolle, z.b. DVMRP (Distance-Vector-Multicast-Routing-Protocol [WPD88]) oder PIM-SM (Protocol Independent Multicast - Sparse Mode [EF+98]). Trotz vieler Entwicklungen seit den 90er-Jahren ist IP-Multicast im Internet nicht weit verbreitet. Der Prozentsatz der IP-Multicast-fähigen autonomen Systeme im Internet stagniert seit Jahren unter 5% [MS07]. Die Gründe dafür sind technischer und wirtschaftlicher Natur. IP-Multicast-fähige Router müssen alle Zustände der Multicast-Gruppe speichern, was zu hoher Komplexität und damit zu eingeschränkter Skalierung führt. Für IP-Multicast wird das Transportprotokoll UDP verwendet. Bei IP-Multicast handelt es sich also um einen Best-Eort- Service. Dienste wie Fehlerkontrolle, Flusskontrolle oder Congestion-Control (Stauvermeidungsmechanismen) sind bei IP-Multicast im Gegensatz zu Unicast sehr schwierig 24

25 2.5. STREAMING-ARCHITEKTUREN KAPITEL 2. STREAMING umzusetzen. Um IP-Multicast im Internet ächendeckend einzusetzen, müssten auÿerdem IP-Multicast-fähige Router bei allen Verbindungen zu den Endknoten installiert werden. Die Nachfrage nach IP-Multicast durch Endkunden ist zudem gering. Daher ist es für die Internet-Service-Provider wirtschaftlich nicht interessant, IP-Multicast zur Verfügung zu stellen und die hohen Kosten für Wartung und Konguration in Kauf zu nehmen. [CRZ00, LR+08, MS07] Application-Level-Multicast Im Fokus dieser Arbeit stehen Systeme, die das Streamen über das Internet, also über Punkt-zu-Punkt-Verbindungen, ermöglichen und zu diesem Zweck Application-Level- Multicast (ALM) einsetzen. Wegen der Nachteile von IP-Multicast wurde ALM entwickelt. Multicast wird hier auf der Anwendungsschicht (Schicht 7 im ISO/OSI-Referenzmodell) nachgebildet. Der Quell- Server und die Endsysteme bilden ein sogenanntes Application-Level-Overlaynetzwerk [LGL08] über dem physischen Internet. Dadurch können Multicast-Bäume direkt zwischen den Endsystemen aufgebaut werden.. Im Gegensatz zu IP-Multicast sind bei ALM die Endsysteme für Multicast-Funktionalitäten zuständig. Sie kopieren Nachrichten, leiten Nachrichten weiter und übernehmen Aufgaben der Gruppenverwaltung. Abbildung 2.4 stellt den Versand von Nachrichten bei IP-Multicast und ALM dar. Der Sender S und die Empfänger (Hosts 1,2,3) sind jeweils über ein physisches Netzwerk miteinander verbunden (siehe blaue Linie). Bei ALM existiert neben der physischen Verbindung ein Overlaynetzwerk (blau-gestrichelte Linie), das sich aufgrund von Partnerschaftsbeziehungen zwischen den Hosts zusammensetzt. Bei ALM leitet Host 2 die Nachricht des Senders an Host 3 weiter. Auf einer unteren Protokollebene muss diese Nachricht natürlich auch über die physische Verbindung (über Router 2) verschickt werden. S 2 S 2 Router 1 Router 2 Router 1 Router 2 1 IP-Multicast 3 1 ALM 3 Abbildung 2.4: IP-Multicast und ALM (nach [BBK02]) Frühe Streaming-Systeme (ab 2000) auf Basis von ALM sind sogenannte Tree-basierte Systeme. Tree-basierte Systeme erstellen explizit einen Multicast-Baum (ALM-Baum), über den der Stream von der Quelle bis zu den Endsystemen verteilt wird [LGL08, Liu07]. Entweder baut das System zuerst den ALM-Baum auf (Tree-rst-Ansatz) oder errichtet zuerst ein separates Overlaynetzwerk, über dem der eigentliche ALM-Baum liegt (Mesh-rst-Ansatz). Bei diesem Overlaynetzwerk kann es sich um ein strukturiertes P2P-Substrat (z.b. CAN [RF+00], Pastry [RD01] oder Tapestry [ZKJ01]) handeln oder um ein unstrukturiertes P2P-Netzwerk mit einer zufälligen Verbindungsstruktur. Da sich 25

26 2.6. ZUSAMMENFASSUNG KAPITEL 2. STREAMING die Peers in dem P2P-Netzwerk untereinander verbinden und dabei - im Unterschied zum Baum - Maschen bilden, bezeichnet man so ein Netz als Mesh (engl. für Masche). Ab 2004 wurden sogenannte Mesh-basierte ALM-Systeme entwickelt. Analog zum Mesh- rst-ansatz sind die Peers in einem separaten Overlaynetzwerk über dem physischen Internet miteinander verbunden. Die Verteilung des Streams erfolgt hier nicht über einen fest aufgebauten ALM-Baum, sondern über dynamische Routen, die je nach Datenverfügbarkeit wechseln können. Dadurch werden implizit Multicast-Bäume erstellt, die sich ständig verändern können. Eine weitere Besprechung von Tree- und Mesh-basierten Systemen folgt in Abschnitt Im Gegensatz zu IP-Multicast ist der Einsatz von ALM an keine Infrastrukturanpassungen gebunden und diesbezüglich kostengünstiger. Protokollmodikationen können einfach in der Anwendungsschicht vorgenommen werden. Allerdings zeichnet sich IP-Multicast durch höhere Ezienz aus. Bei ALM übernehmen die Endhosts die Funktion der Router, wissen aber nichts oder nur wenig über die physische Netzwerktopologie und verschicken Nachrichten daher weniger ezient, d.h. mit gröÿeren Ende-zu-Ende-Verzögerungen. Da bei ALM die Endhosts auch Aufgaben der Gruppenverwaltung übernehmen, führt dies zu höherem Overhead und höherer Komplexität auf den Endhosts. [HA+06] Abschlieÿend sollen die Begrie ALM und P2P-Streaming voneinander abgegrenzt werden. Beim P2P-Streaming laden Endsysteme den Stream herunter und leiten ihn weiter. P2P-Streaming kann über eine ALM-Architektur realisiert werden, d.h. durch Implementierung von Multicast auf der Anwendungsschicht. P2P-Streaming-Systeme, die Liveoder Video-On-Demand-Inhalte vielen Empfängern zur Verfügung stellen, basieren in der Regel auf ALM. Für die Verteilung des Streams müssen ein oder mehrere Multicast- Bäume errichtet werden, sei es explizit (wie bei Tree-basierten Systemen) oder implizit (wie bei Mesh-basierten Systemen). Es gibt aber auch P2P-Streaming-Systeme, die kein Multicast einsetzen, siehe IP-Telefonie zwischen zwei Hosts mit Skype. Hier werden zwar Audiodaten über ein P2P-Netzwerk gestreamt und weitergeleitet, konzeptionell handelt es sich aber um eine Unicast-Verbindung zwischen zwei Teilnehmern. In der P2P-Literatur werden folgende Begrie synonym zu ALM gebraucht: End-System-Multicast (kurz: ESM), End-System-Overlay-Multicast, Overlay-Multicast, P2P-Multicast, P2P-Broadcast, P2P-Internet-Broadcast, P2P-Internet-Video-Broadcast. [LR+08, Zha07] Broadcast ist hier semantisch nicht korrekt, da es sich bei ALM um Multicast-Verbindungen handelt (siehe Abschnitt 2.4). Dennoch ist die Bezeichnung Broadcast in diesem Zusammenhang gebräuchlich. Wenn ein Einsatzzweck von ALM im Vordergrund steht, wird statt von ALM mitunter auch von P2P-Internet-Video-Streaming gesprochen [Zha07]. 2.6 Zusammenfassung In diesem Kapitel wurde das Streamen von Audio- und Videodaten aus verschiedenen Perspektiven heraus erläutert. Dabei wurden zunächst die gestreamten Daten und ihre Kodierungen betrachtet. Dann wurden der Unterschied zwischen echtem Streaming 26

27 2.6. ZUSAMMENFASSUNG KAPITEL 2. STREAMING (True-Streaming) und Pseudo-Streaming herausgestellt und mögliche Anwendungen, Verbindungsarten und Architekturen behandelt. Der Schwerpunkt dieser Arbeit liegt auf Live-Streaming (also echtem Streaming) über P2P für Web-TV-Anwendungen. Sobald Daten empfangen werden, erfolgt beim Live- Streaming deren Wiedergabe. Der Sender und die Empfänger verbinden sich per Multicast. Dabei wird Multicast auf der Anwendungsebene (als ALM) implementiert. Es können verschieden kodierte Audio- und Videodaten gestreamt werden. Deren Kodierung und Format hängen vom Medienplayer des Clients ab, zu dem das P2P-Live-Streaming- System eine Anbindung liefert (siehe auch Tabelle 2.1). Die bei kommerziellen Systemen am häugsten unterstützten Formate sind Windows Media von Microsoft sowie - bei älteren Systemen - RealMedia von RealNetworks. [cha07, cha09, Sim08] 27

28 3 P2P-Streaming Im vorherigen Kapitel habe ich die Grundlagen des Streamings erläutert. Für das Kernthema dieser Arbeit (P2P-Streaming) sind jetzt folgende Fragen zu klären: Was ist P2P? Wo liegt der Zusammenhang zwischen P2P und P2P-Streaming? Neben dem oensichtlichen Zusammenhang, dass sich die Peers in beiden Systemen Ressourcen teilen, hat der Bereich P2P-Streaming einige Algorithmen und Protokolle aus P2P adaptiert. Ein chronologischer Überblick wird in Abschnitt 3.2 gegeben. Streaming in P2P-Netzen erfolgt nach den Methoden Live und Video-On-Demand. Deren grundlegende Konzepte werden am Ende dieses Kapitels vorgestellt. 3.1 P2P Begrisklärung P2P ist die Kurzform von Peer-to-Peer und abgeleitet vom englischen Wort peer, das einen Gleichrangigen oder Ebenbürtigen bezeichnet. In der P2P-Forschung gibt es keine klare, einheitlich verwendete Denition von einem P2P-System bzw. einem P2P-Netzwerk. Nach Mahlmann et al. hat man sich in etwa darauf geeinigt, dass ein P2P-Netzwerk ein Overlay-Netzwerk des Internets ist, bei dem die Rechner ebenbürtig ohne zentrale Koordination kommunizieren und gemeinsam eine Anwendung zur Verfügung stellen [MS07]. In diesem Satz werden alle wichtigen Eigenschaften von P2P angeschnitten: Dezentralisierung, Kooperation, Ressourcenverteilung sowie autonome und gleichberechtigte Peers. Die Peers agieren als Servents (Kunstwort aus Server und Clients). Sie fordern nicht nur Daten an, sondern liefern im Unterschied zum klassischen Client/Server-System die Daten auch selbst aus. Aufgrund der genannten Eigenschaften bieten P2P-Systeme gegenüber Client/Server- Systemen mehrere Vorteile. Da sich die Peers die Ressourcen teilen, kommt es nicht zu dem Problem des Server-Flaschenhalses und das System skaliert besser. Durch das Fehlen einer Serverstruktur minimieren sich die Anforderungen an die Infrastruktur und damit die Kosten. Dezentralisiert arbeitende Peers bieten zudem keinen Single-Point- Of-Failure, wodurch der mögliche Schaden bei Distributed-Denial-Of-Service-Attacken (DDoS-Attacken) gemindert und die Robustheit des Systems erhöht wird. Allerdings arbeiten nicht alle P2P-Systeme gleichermaÿen dezentralisiert und weisen somit nicht alle Vorteile gleich stark auf (siehe Napster [nap] und Gnutella 0.6 [gnu] in Tabelle 3.1). In einem dezentralisierten P2P-System laufen die Anwendungen verteilt, weshalb verteilte Algorithmen benötigt werden (z.b. CAN [RF+00], Chord [SM+01], Pastry [RD01], Algorithmen im Gnutella-Protokoll [Cli01] oder bei Freenet [CS+01]). 28

29 3.1. P2P KAPITEL 3. P2P-STREAMING Klassizierung von P2P-Systemen P2P-Systeme kann man klassizieren, indem man prüft, wie stark die Inhalte und Inhaltsbeschreibungen (z.b. Dateinamen, Meta-Informationen) strukturiert sind und wie sehr die Peers voneinander abhängen. In strukturierten oder stra strukturierten P2P-Systemen stehen die Inhalte in Relation zu den Knoten, die für diese Inhalte zuständig sind. Eine wohldenierte Hash-Funktion bildet z.b. den Dateinamen auf die P2P-Netzwerkadresse des für die Datei zuständigen Knotens ab. Daher spricht man hier von Systemen, die auf DHTs (Distributed-Hash- Tables) basieren. Diese Systeme werden in der P2P-Literatur auch als Content-orientiert bzw. Content-adressierbar bezeichnet oder als Systeme mit Content-basiertem Routing bzw. mit Content-adressierbarer Datenhaltung. Da die Topologie ständig aufrechterhalten werden muss, entstehen hohe Wartungskosten bei hohem Peer-Churn, d.h. wenn oft neue Peers ins Netz kommen und verbundene Peers das Netz wieder verlassen. Unstrukturierte oder locker strukturierte P2P-Systeme sehen keine Relation zwischen Inhalten und Knoten vor. Die Suche nach den Dateien erfolgt zentralisiert oder über Flooding, d.h. durch Broadcast an alle Peers im P2P-Netzwerk bis zum Ablauf einer Time-To-Live (TTL). Die Protokolle erzeugen einen zufälligen Verbindungsgraph, dessen Struktur gewissen Gesetzmäÿigkeiten folgt (z.b. Pareto-Verteilung des Small-World- Netzwerks bei Gnutella). In achen, reinen oder rein dezentralisierten P2P-Systemen, wie z.b. Chord und Freenet, haben alle Peers die gleiche Funktionalität und die gleiche Verantwortung. Peer-Churn beeinträchtigt das Gesamtsystem hier kaum. Hierarchische oder hybride P2P-Systeme zeichnen sich dadurch aus, dass bestimmten Knoten mehr Verantwortung zufällt als anderen. Diese Knoten übernehmen entweder alle Aufgaben (wie die statischen Server bei Napster), wobei man hier von zentralisiert indexierenden Systemen spricht. Oder dynamische Einheiten (Super-Nodes/Super- Peers/Ultra-Peers) übernehmen einen gröÿeren Teil der Aufgaben. Diese Systeme werden als verteilt indexierend bezeichnet. [E08, MS07, PBV05, SW05] Die Tabelle 3.1 stellt die möglichen Klassizierungen von P2P-Systemen und deren Vorund Nachteile dar. Die P2P-Systeme werden dabei nach den oben genannten Aspekten der Strukturierung (strukturiert oder unstrukturiert) und Hierarchie (rein dezentralisiert oder hybrid) in vier Gruppen eingeteilt und anhand ihrer Eigenschaften verglichen. Insbesondere werden die Skalierbarkeit 1, Robustheit 2 und Flexibilität der Systeme betrachtet. Flexibilität bedeutet hier, dass die Peers sich vollständig autonom verhalten können, sich nach Belieben mit dem Netz verbinden sowie dieses wieder verlassen können. In strukturierten P2P-Netzwerken werden den Peers IDs und die Verantwortung für Inhalte zugeteilt, wodurch nach dem Peer-Abgang eine Umorganisation notwendig und die Flexibilität somit eingeschränkt ist. 1 Skalierbarkeit bezeichnet die Fähigkeit eines P2P-Netzwerks, sich an eine quantitativ wachsende Anzahl von Peers und/oder Daten anzupassen [Wol10] (siehe auch Abschnitt 4.4.1). 2 Robustheit beschreibt die Eigenschaft eines Netzwerks, auch unter hoher Last und bei Fehlern (z.b. Ausfällen der Netzwerkstruktur) ein speziziertes Leistungsniveau zu erhalten [Wol10] (siehe auch Abschnitt 4.4.1). 29

30 3.1. P2P KAPITEL 3. P2P-STREAMING unstrukturiert und rein dezentralisiert strukturiert und rein dezentralisiert unstrukturiert und hybrid (zentralisiert indexierend) unstrukturiert und hybrid (verteilt indexierend) Skalierbar nicht gut skalierbar aufgrund des Nachrichten- Overheads ja nicht skalierbar wegen Server-Flaschenhals Robust ja ja nein, da Server Flexibel ja weniger exibel, da nach Eigenschaften der Suche - Suche weniger ezient, vor allem bei seltenen Dateien - False-Negatives bei Suche möglich Sonstiges Durch die gleichmäÿige Verteilung der Aufgaben auf alle Peers wird deren Heterogenität (z.b. bzgl. Bandbreite) nicht berücksichtigt. Peer-Abgang Umorganisation der Daten erforderlich ist - eziente Suche mit meist logarithmischer Suchkomplexität - Fuzzy-Queries (ungenaue Suche) nicht möglich Durch die gleichmäÿige Verteilung der Aufgaben auf alle Peers wird deren Heterogenität (z.b. bzgl. Bandbreite) nicht berücksichtigt. Single-Point-of-Failure ja nein ja - eziente Suche mit konstanter Suchkomplexität, da Anfragen direkt an Server gerichtet werden - Fuzzy-Queries möglich ja, falls Super- Nodes/-Peers redundant Suche ezienter als bei rein unstrukturierten P2P-Systemen Beispielsystem Gnutella 0.4 CAN, Chord, Pastry Napster Gnutella 0.6, FastTrack Tabelle 3.1: Klassizierung von P2P-Systemen und Vergleich ihrer Eigenschaften [PBV05, SW05] 30

31 3.2. ZUSAMMENHANG KAPITEL 3. P2P-STREAMING 3.2 Chronologischer Zusammenhang zwischen P2P und P2P-Streaming Beim Streaming werden Audio- und/oder Videodaten über ein IP-Netzwerk kontinuierlich übertragen und verwertet. Beim Streaming auf P2P-Basis agieren die Endsysteme zudem als Peers, d.h. sie empfangen den Stream und leiten ihn weiter. Die Architektur, über die P2P-Streaming realisiert werden kann, wird ALM genannt (siehe auch Abschnitt ). Die ersten P2P-Streaming-Protokolle wurden im Jahr 2000 veröentlicht. Diese Protokolle (z.b. Overcast [JG+00]) errichten einen statischen Multicast-Baum mit der Quelle als Wurzel. Der Stream wird über den Baum von der Quelle zu den Blattknoten verteilt, wobei nur die inneren Knoten Daten weiterleiten und demnach als Peers agieren. Ebenfalls im Jahr 2000 werden P2P-Streaming-Protokolle entwickelt, die diese Struktur erweitern, indem sie zusätzlich zum Multicast-Baum ein eigenes P2P-Netzwerk aufbauen. Das zusätzliche Overlay sorgt für gröÿere Stabilität des Systems. Beim Ausfall des Vaterknotens wird ein Peer z.b. nicht gänzlich vom System getrennt, sondern ist immer noch mit den anderen Nachbarn im P2P-Overlay verbunden. Das vereinfacht die Suche nach einem neuen Vaterknoten für den Peer und somit allgemein die Reparaturmaÿnahmen des Systems bei Peer-Churn. Je nach P2P-Streaming-Protokoll werden über das P2P-Netzwerk unterschiedliche Arten von Daten übertragen. In der Regel dient das P2P-Netzwerk jedoch zum Austausch von Kontrollnachrichten (z.b. Nachrichten zum Gruppenstatus oder zur Datenverfügbarkeit) und der Multicast-Baum zur Verteilung der eigentlichen Streamdaten (Video-/Audiodaten). Es lässt sich sehr gut beobachten, wie sich ab dem Jahr 2000 die Entwicklungen im P2P-Bereich jeweils auf die Erforschung neuer P2P-Streaming-Systeme ausgewirkt haben. Wurde ein neues P2P-Netzwerk entworfen, entstand meist kurze Zeit später ein neues P2P-Streaming-Protokoll, welches dieses P2P- Netzwerk als Substrat (oder Unterbau) benutzte. Dies zeigt die folgende chronologische Auistung einiger ausgewählter P2P-Streaming-Protokolle für Live-Streaming: 2000 P2P-Streaming-Protokolle implementieren neben einem Multicast-Baum (Single- Tree) ein unstrukturiertes P2P-Netzwerk. Dieses sogenannte Mesh kann entweder vor (Mesh-rst) oder nach (Tree-rst) dem Baumaufbau errichtet werden: Single-Tree-Protokoll (Mesh-rst): Narada [CRZ00] Single-Tree-Protokoll (Tree-rst): YOID [Fra00] 2001 Die ab dem Jahre 2000 entwickelten DHT-basierten P2P-Netzwerke (insbesondere CAN [RF+00], Pastry [RD01], Tapestry [ZKJ01]) regen das Design von P2P-Streaming-Systemen an, die über einem DHT-Substrat einen Multicast-Baum (Single- Tree) aufbauen: Single-Tree-Protokoll CAN Multicast [RH+01] über CAN Single-Tree-Protokoll Bayeux [ZZ+01] über Tapestry 2002 Single-Tree-Protokoll Scribe [CD+02] über Pastry 2003 Das Multi-Tree-Protokoll SplitStream [CD+03] baut mehrere Multicast-Bäume über dem DHT-Substrat Pastry auf. 31

32 3.3. GRUNDLEGENDE KONZEPTE KAPITEL 3. P2P-STREAMING 2004 Sogenannte Mesh-basierte P2P-Streaming-Systeme verzichten ganz auf den expliziten Aufbau von Multicast-Bäumen. Die Peers sind in einem zufällig erzeugten P2P-Netz miteinander verbunden, über das die Daten dynamisch verteilt werden. Mesh-basiert sind z.b. die folgenden Protokolle: CoolStreaming [ZL+05] Chainsaw [PK+05] 3.3 Grundlegende Konzepte Werden Daten über P2P-Netze gestreamt, handelt es sich um sogenanntes echtes Streaming (True-Streaming), das im vorherigen Kapitel vorgestellt wurde (siehe Abschnitt 2.3). Dabei werden die Daten unmittelbar nach dem Empfang wiedergegeben. Man unterscheidet hier zwei wesentliche Methoden, Live-Streaming und Video-On-Demand- Streaming. Beim Live-Streaming werden analog zum klassischen TV-Broadcast die Inhalte zu einem festen Zeitpunkt gesendet. Alle Benutzer empfangen den gleichen Stream mehr oder weniger zum gleichen Zeitpunkt. Beim Video-On-Demand-Streaming hingegen bestimmt der Benutzer selbst den Zeitpunkt der Wiedergabe. Die grundlegenden Konzepte dieser beiden Methoden werden im Folgenden vorgestellt Video-On-Demand-Streaming Ein Video-On-Demand-Benutzer sucht sich zuerst ein Video des Streaminganbieters aus und fordert es an. Er empfängt den Videostream dann asynchron, also nicht gleichzeitig mit den anderen Empfängern des Videos. D.h. die Empfänger schauen sich jeweils verschiedene Teile des Videos an. Der Benutzer kann den Video-On-Demand-Stream anhalten sowie vor- und zurückspulen, weswegen die Daten gecacht werden müssen. Liu et al. [LGL08] unterscheiden drei Ansätze, über die P2P-Video-On-Demand realisiert werden kann: Tree-basiert Beim Tree-basierten P2P-Video-On-Demand (wie bei P2Cast [GS+03]) werden die User nach dem Zeitpunkt ihres Eintreens in Sitzungen eingeteilt. Der Quellserver und die Benutzer einer Sitzung bilden zusammen einen ALM-Baum, über den der gesamte Stream verteilt wird. Cache-And-Relay Cache-And-Relay beruht darauf, dass ein Peer den Stream herunterlädt und dabei den jeweiligen Datenbereich (Moving-Window genannt) cacht. Er bedient aus seinem Cache andere Empfänger, die Videodaten aus seinem Moving-Window anfordern. DirectStream [GS+07] wendet z.b. diese Technik an. 32

33 3.3. GRUNDLEGENDE KONZEPTE KAPITEL 3. P2P-STREAMING Mesh-basiert In einem Mesh-basierten P2P-Video-On-Demand-System (wie BiToS [VIF06]) wird das Video zuerst in kleine Datenblöcke zerlegt und dann vom Server an mehrere User verteilt. Die Benutzer laden immer die Blöcke von ihren Nachbarn herunter, die sie nicht haben. Diese Technik wurde zuerst für die Verteilung groÿer Dateien entwickelt (siehe BitTorrent) und dann erfolgreich für Video-On-Demand-Streaming und vor allem für Live-Streaming übernommen. [E08, LGL08] Live-Streaming Beim Live-Streaming wählen die Benutzer zunächst einen Kanal des Streaming-Anbieters aus. Nach einer anfänglichen Verzögerung empfangen sie zusammen mit allen anderen Benutzern, die diesen Kanal gewählt haben, die gleichen Daten zum mehr oder weniger gleichen Zeitpunkt. Die Verzögerung, mit der die Peers während der Sitzung die Live- Daten erhalten, sollte zwar möglichst gering sein, kann aber in der Praxis auch ein bis fünf Minuten betragen [OJ08]. Seit dem Jahre 2000 wurde ein sehr groÿe Anzahl von P2P-Live-Streaming-Protokollen entwickelt, die sich in vielen Details unterscheiden (siehe dazu auch Kapitel 4). Der Live-Stream wird in diesen Protokollen entweder über einen oder mehrere explizit aufgebaute Bäume verteilt. Diese Protokolle nennt man daher Tree-basiert (je nach Anzahl der Bäume Single-Tree oder Multi-Tree). Oder die Verteilung des Streams erfolgt über dynamische Routen innerhalb des P2P-Netzwerkes (dem Mesh). Mesh-basierte Systeme sind in der Regel einfacher zu implementieren und aufgrund der dynamischen Datenverteilungswege robust bei Peer-Churn. So gut wie alle kommerziellen P2P-Streaming-Systeme sind Mesh-basiert. Auch das im Mittelpunkt dieser Arbeit stehende CoolStreaming-Protokoll ist Mesh-basiert und stellte zum Zeitpunkt seiner Veröentlichung das erste seiner Art dar. In Mesh-basierten Systemen wie CoolStreaming zerlegt die Quelle den Stream in einzelne Teile, die Segmente, Blöcke oder Chunks genannt werden. Diese Segmente werden einzeln verschickt und können über unterschiedliche Pfade im Netzwerk transportiert werden. Die empfangenen Segmente setzt der Peer in seinem Puer zusammen und übergibt sie sortiert an den Player zur Wiedergabe. Der Inhalt des Puers kann in Form einer sogenannten Buermap dargestellt werden (siehe Abbildung 3.1) Puffer Buffermap mit Offset=35 ID des 1.Puffersegments (Offset)=35 Abbildung 3.1: Puer und dazugehörige Buermap 33

34 3.3. GRUNDLEGENDE KONZEPTE KAPITEL 3. P2P-STREAMING In Abbildung 3.1 hat der Peer bereits die Segmente mit der ID 35,36,37,39,41 erhalten und in seinem Puer sortiert gespeichert. In der Buermap werden diese vorhandenen Segmente durch eine 1 repräsentiert, alle noch nicht erhaltenen Segmente durch eine 0. Die ID des ersten Segments im Puer (im obigen Beispiel 35) wird Oset genannt. Anhand der Buermap eines Puers und des dazugehörigen Osets kann man leicht ermitteln, welche Segmente in diesem Puer vorliegen. In Mesh-basierten Systemen tauschen die Peers regelmäÿig Buermaps mit ihren Nachbarn im Netzwerk aus. Dadurch erfahren sie, welche Segmente der Nachbar hat und können diese explizit bei ihm anfordern. Der Peer mit dem Puer aus Abbildung 3.1 benötigt z.b. die Segmente 38,40,42,43,44 und muss diese anfordern. In den letzten beiden Abschnitten wurden die grundlegenden Konzepte von P2P-Streaming vorgestellt, vor allem auch im Hinblick auf das CoolStreaming-Protokoll. Die Analyse des CoolStreaming-Protokolls folgt im Kapitel 4. 34

35 4 Analyse In den vorangegangenen Kapiteln wurden Streaming, P2P-Streaming und die Besonderheiten beim P2P-Live-Streaming erläutert. In diesem Kapitel wird das P2P-Live- Streaming-Protokoll CoolStreaming analysiert. Die Analyse von Protokollen kann theoretisch erfolgen durch den Vergleich von Protokollcharakteristiken, durch eine Graph- Analyse oder durch den Vergleich von veröentlichten Messergebnissen aus Performance- Messungen. In dieser Arbeit werden alle drei der genannten Möglichkeiten der Analyse angewandt. Es werden zunächst die Gemeinsamkeiten von P2P-Live-Streaming-Protokollen anhand eines allgemeinen Prozessmodells hervorgehoben. Aus diesem Prozessmodell lassen sich die Unterscheidungsmerkmale von P2P-Live-Streaming-Protokollen ableiten, so dass darauf aufbauend die Analyse des CoolStreaming-Protokolls erfolgen kann. Die Protokollcharakteristiken von CoolStreaming werden denen anderer Protokolle gegenübergestellt und daraufhin bewertet. Dabei weise ich auch auf die verschiedenen Terminologien hin, um so zugleich einen systematischen Überblick über P2P-Live-Streaming-Protokolle darzulegen. Dann werden die Ergebnisse von Performance-Messungen des CoolStreaming- Protokolls aus diversen P2P-Streaming-Arbeiten vorgestellt. Es folgt eine Analyse des CoolStreaming-Verbindungsgraphen. Das Kapitel endet mit einer Zusammenfassung der Ergebnisse. 4.1 Allgemeines Prozessmodell für P2P-Live-Streaming Die Schwierigkeit beim P2P-Live-Streamingprozess besteht darin, dass sich neue Knoten mit den Peers im P2P-Streaming-Netz so verbinden, dass sie die gewünschten Inhalte mit geringstmöglicher Verzögerung beziehen können. In [GZ+09] wurde dazu ein allgemeines Prozessmodell für P2P-Live-Streaming-Systeme vorgestellt. In jedem Schritt des Prozessmodells werden jeweils die Streamverteilung in Tree-basierten und in Mesh-basierten Systemen berücksichtigt. Aus den einzelnen Schritten lassen sich anschlieÿend die Unterscheidungsmerkmale für P2P-Live-Streaming- Protokolle ableiten. 1. Ein neuer Peer kontaktiert einen Einstiegspunkt (Rendezvous-Point, Bootstrap- Node, Tracker) über HTTP/HTTPS. Er erhält von diesem Einstiegspunkt eine Liste mit potentiellen Vaterknoten (Tree), die ihm den gewünschten Stream weiterleiten können, bzw. eine Liste mit Peers (Mesh), mit denen er die Streamdaten austauschen kann. 2. Der Peer schickt eine Anfrage an alle potentiellen Vaterknoten, um als Sohnknoten angenommen zu werden (Tree). Im Mesh verbindet sich der Peer mit anderen Peers, 35

36 4.2. PROTOKOLLCHARAKTERISTIKEN KAPITEL 4. ANALYSE um Informationen über die Datenverfügbarkeit auszutauschen. Dies geschieht in der Regel in Form von sogenannten Buermaps, bei denen der lokale Puerinhalt als Bit-String oder Bitmap dargestellt wird. In einer Buermap werden vorhandene Segmente durch eine 1 repräsentiert, nicht vorhandene durch eine Der Peer hat einen Vaterknoten gefunden (Tree) bzw. ermittelt anhand der Buermaps die Knoten, die ihm die fehlenden Daten liefern können (Mesh). 4. Der Peer erhält die Daten vom Vaterknoten (Tree) bzw. fordert die Daten bei seinen Nachbarn aktiv an (Mesh). Die oben genannten Punkte geben die wesentlichen Charakteristiken vor, nach denen sich Live-Streaming-Protokolle unterscheiden: in Bezug auf den Join-Vorgang (1), die Gruppenverwaltung inklusive dem Aufbau von Partnerschaften (2,3) und die Art der Streamverteilung (4). Im folgenden Abschnitt gehe ich näher auf diese Charakteristiken ein. 4.2 Charakteristiken eines P2P-Live-Streaming-Protokolls In diesem Abschnitt werden die wesentlichen Charakteristiken von CoolStreaming mit denen anderer P2P-Live-Streaming-Protokolle verglichen. Viele P2P-Streaming-Abhandlungen unterscheiden die Protokolle hauptsächlich aufgrund der errichteten Topologie (siehe 4.2.2). Dieses Kriterium allein reicht nicht aus, um die Funktionsweise der komplexen Protokolle analysieren zu können. Deshalb werden weitere Unterscheidungsmerkmale vorgestellt wie der Join-Vorgang, die Art der Streamverteilung, die Gruppenverwaltung, Fehlerkorrekturmechanismen und die verwendeten Transportprotokolle Join Ein neuer Benutzer hat einen Kanal des P2P-Streaming-Anbieters ausgewählt und wendet sich an den entsprechenden Einstiegsknoten im Netz. Dies kann direkt die Quelle (der Broadcaster) sein, ein denierter Bootstrap-Node oder die DHT-Struktur. In stark frequentierten Netzen wendet sich der Knoten an einen Tracker, der ihn wiederum an Super-Nodes weiterleitet. Der neue Peer erhält vom Einstiegsknoten eine Liste mit möglichen Partnern oder Vaterknoten, wobei in Tree-basierten Systemen in der Regel darauf geachtet wird, dass es sich bei den Vaterknoten um Blattknoten oder innere Knoten mit ausreichenden Uploadkapazitäten handelt. Bei Mesh-basierten Protokollen werden die Partnerkandidaten entweder zufällig ausgewählt (wodurch das Overlay-Netz ebenfalls zufällig aufgebaut wird) oder es wird die geographische Nähe im Netz berücksichtigt (sogenannte Location-Aware-Ansätze). Hybride Ansätze kombinieren die zufällige Auswahl von Partnerkandidaten mit Location- Awareness. Je nach Ansatz variiert die Verbindungsstruktur der Peers. Abbildung 4.1 zeigt die Topologien, die je nach Wahl der Partnerkandidaten entstehen, und zwar für ein Netz mit 20 Peers und 4 Partnern pro Peer. 36

37 4.2. PROTOKOLLCHARAKTERISTIKEN KAPITEL 4. ANALYSE Abbildung 4.1: Verbindungsstruktur bei zufälliger Partnerwahl (links), bei Wahl mit Berücksichtigung der Location-Awareness (Mitte) und bei dem hybriden Ansatz (rechts) [CL+10] CoolStreaming sieht in [ZL+05] zwar vor, dass jeder Peer im Netz durch regelmäÿige Nachrichten seine Partneranzahl bekannt gibt, so dass die Quelle auf diese Information zugreifen könnte, aber laut Spezikation werden die Partnerkandidaten für einen neuen Peer rein zufällig ausgewählt. Über die Anzahl der vorgeschlagenen Partnerkandidaten liefern die Protokolle keine Informationen. [ZL+05] gibt für CoolStreaming allerdings vor, dass ein neuer Peer alle vorgeschlagenen Partnerkandidaten kontaktiert, um Partnerschaften aufzubauen. Daher reicht es hier aus, dem neuen Peer zunächst die Adressen von so vielen Partnerkandidaten zu schicken, zu denen er gemäÿ der empfohlenen maximalen Partneranzahl (4-6 bei CoolStreaming) auch eine Verbindung aufnehmen kann. Werden seine Partneranfragen abgelehnt, so kann er später im Rahmen der regelmäÿigen Overlaywartung weitere potentielle Partner kontaktieren. Die Protokolle geben ebenfalls keine Informationen über den initialen Aufbau des P2P- Streaming-Netzes bekannt. Die Implementierung muss hier somit Prozeduren vorsehen, nach der ein Netz entweder komplett neu aufgebaut werden kann, oder es muss eine Startkonguration implementiert werden Topologie der Streamverteilung CoolStreaming ist ein Mesh-basiertes Protokoll, d.h. der Stream wird über dynamische Routen im Mesh verteilt. Tree-basierte Protokolle verteilen den Stream dagegen über einen oder mehrere explizit aufgebaute Multicast-Bäume. Man spricht in diesem Zusammenhang von Single-Tree- bzw. Multi-Tree-Protokollen. Im Folgenden werden die Eigenschaften sowie die Vor- und Nachteile dieser Topologien beschrieben. Single-Tree Die ersten P2P-Live-Streaming-Protokolle waren sogenannte Single-Tree- Protokolle, die den Stream über einen einzigen explizit errichteten Multicast-Baum verteilten. Die Bandbreite der Blätter blieb bei diesen Systemen ungenutzt. Zusätzlich zum Baum konnte ein Mesh-Netz aufgebaut werden, über das z.b. Nachrichten zur Gruppenverwaltung verschickt wurden. Sanjay G. Rao und Hui Zhang bezeichneten diese Architektur (Multicast-Baum über einem P2P-Overlay) als ESM (Kurzform von End- System-Multicast). Sie entwickelten Narada als eines der ersten Protokolle, das ESM realisierte [CR+02, CRZ00]. 37

38 4.2. PROTOKOLLCHARAKTERISTIKEN KAPITEL 4. ANALYSE Multi-Tree (Multiple-Tree, Forest-based) Um die Bandbreite in Tree-basierten Systemen besser nutzen zu können, wurden Multi-Tree-Systeme entwickelt, auch Multiple-Tree oder Forest-based [WLQ06] genannt. Hier werden mehrere, sich überlagernde Bäume zur Datenverteilung aufgebaut. Ein Peer, der in einem Baum ein Blatt ist, kann in den anderen Bäumen ein innerer Knoten sein und somit seine Uploadbandbreite zur Verfügung stellen. Bei Multiple-Tree-Systemen verbinden sich die Peers in der Regel zuerst in einem strukturierten oder unstrukturierten Netzwerk, über dem dann die Bäume errichtet werden. Die Quelle kodiert den Stream in einzelne Teilstreams (Substreams) und versendet jeden Substream über einen anderen Baum. Fällt ein Vaterknoten aus, erhalten alle seine Nachfahren in diesem Baum keine Daten, können aber aus den bereits erhaltenen Substreams den Originalstream rekonstruieren. Die Kodierung erfolgt auf Basis von Multiple- Description-Coding (siehe Abschnitt ), ein sehr komplexes Verfahren, dass von den gängigen Mainstream-Playern bisher nicht unterstützt wird [LR+08]. Mesh (Unstrukturiert, Data-driven/Datengesteuert, Swarming-based) Bei Mesh-basierten Systemen zerlegt die Quelle den Stream in mehrere gleich groÿe Stücke (Chunks, Segmente, Blöcke). Die Peers sind im Mesh in der Regel zufällig miteinander verbunden (siehe Overlay-Layer in Abbildung 4.2) und fordern von ihren Partnern die fehlenden Streamsegmente an. Dadurch werden die Streamsegmente über dynamische Routen im Mesh übertragen und implizit dynamische Multicast-Bäume aufgebaut (siehe Distribution-Layer in Abbildung 4.2). Abbildung 4.2: Mesh-Overlay-Schicht (Overlay Layer) und Datenverteilungsschicht (Distribution Layer) in einem P2P-Streaming-Netzwerk [CLB07] In Mesh-basierten Systemen müssen die Partner regelmäÿig Buermaps austauschen, um ihren Puerinhalt zu kommunizieren. Durch den Versand von Buermaps und von Datenanforderungen ist der Kontrolloverhead (d.h. der Anteil der Kontrolldaten an den Videodaten, siehe Abschnitt 4.4.2) höher als in Tree-basierten Systemen. Auch dauert es im Unterschied zu Tree-basierten Systemen länger, bis die Daten empfangen und abgespielt werden können, d.h. die Verzögerungen sind gröÿer (siehe Abschnitt 4.4.2). Dafür sind Mesh-basierte Systeme sehr robust bei Peer-Churn. 38

39 4.2. PROTOKOLLCHARAKTERISTIKEN KAPITEL 4. ANALYSE Mischformen Bullet [KR+03] implementiert einen hybriden Mesh-/Tree-Ansatz. Das Protokoll baut zuerst einen Verteilungsbaum auf und darüber ein zufällig verbundenes Mesh. Über den Baum werden zunächst die Daten übertragen (Stream, Kontrollnachrichten). Fehlende Streamdaten können die Knoten über das Mesh anfordern. Nach dem Baumaufbau wählt die Quelle eine zufällige Menge von Söhnen aus, zerlegt den Stream in mehrere Blöcke und verschickt disjunkte Untermengen des Streams an die Söhne. Die Söhne reichen wiederum disjunkte Untermengen durch den Baum weiter. Jeder Sohnknoten kann als die Wurzel eines Unterbaums betrachtet werden, weshalb Bullet mitunter auch als Multi-Tree klassiziert wird (siehe [LGL08, Liu07]). In [VFC06] sprechen Venkataraman et al. von einem Multi-Path-Ansatz, da jeder Knoten Teile des Streams über verschiedene Routen erhält. PRIME [MR07, MRG07] baut ein strukturiertes unidirektionales Mesh auf, bei dem von zwei benachbarten Knoten jeweils einer der Sender und einer der Empfänger ist. Analog zu Multi-Tree-Systemen kodiert die Quelle den Stream in Substreams. In der ersten Phase (Diusion-Phase) werden die Peers anhand der Verbindungsstruktur im Netzwerk in disjunkte Bäume aufgeteilt. Jeder Substream wird über einen anderen Baum verbreitet. In der zweiten Phase (Swarming) werden die fehlenden Daten von den Blattknoten aus über die Mesh-Verbindungsstruktur verbreitet Art der Streamverteilung Bei CoolStreaming fordern die Peers die benötigten Streamdaten explizit an, d.h. die Daten werden per Pull verteilt. In anderen Systemen können die Daten auch per Push verbreitet werden. Im Folgenden erkläre ich die Unterschiede zwischen diesen beiden Mechanismen der Streamverteilung: Push/Sender-driven Der Sender schickt die Daten an den Empfänger, ohne dass der Empfänger diese Daten vorab anfragt. Der Sender weiÿ hier nicht, welche Segmente der Empfänger braucht. Pull/Receiver-driven Der Empfänger holt sich die benötigten Daten, indem er die Daten beim Sender anfordert und der Sender diese ihm schickt (wie bei CoolStreaming). Das setzt voraus, dass der Empfänger weiÿ, welche Daten der Sender im Puer hat. Vorab muss der Sender seinen Puerinhalt in Form von Buermaps kommunizieren. In Push-basierten Systemen gibt der Sender nur so viele Daten weiter, wie es ihm die Bandbreite erlaubt. In Pull-Systemen können von einem Sender mehr Daten angefordert werden, als dieser hochladen kann. Das Protokoll muss also in Pull-basierten Systemen Beschränkungen vorsehen, um eine Überlastung der Senderkapazität zu verhindern. Nachfolgend gehe ich auf die Besonderheiten von Push-basierten und Pull-basierten Systemen ein und stelle Systeme vor, die beide Mechanismen implementieren. 39

40 4.2. PROTOKOLLCHARAKTERISTIKEN KAPITEL 4. ANALYSE Push In Single-Tree-basierten Systemen (siehe 4.2.2) verteilen die Vaterknoten den Stream per Push an die Söhne. Eine niedrige Uploadbandbreite eines Vaterknotens verringert die Streamingrate für alle seine Nachfahren. In Multi-Tree-Systemen (siehe 4.2.2) werden die Daten ebenfalls per Push von den Vaterknoten zu den Söhnen übertragen. Da hier die Verteilung über mehrere Bäume erfolgt, kann ein Peer in einem Baum ein Blatt sein und in einem anderen Baum als innerer Knoten seine Uploadbandbreite beitragen. Die Peers erhalten in einem Multi-Tree-System nicht den gesamten Stream, sondern nur eine Teilmenge, aus der sie den Originalstream rekonstruieren können. Dazu kodiert die Quelle den Originalstream in einzelne Substreams mittels Multiple-Description-Coding (siehe Abschnitt ). Jeder Substream wird per Push über einen anderen Baum verteilt. Die Empfänger dekodieren die erhaltenen Daten, um den Originalstream wiederherzustellen Pull In der P2P-Streaming-Literatur nden sich bezüglich dieses Begries Abweichungen und Widersprüchlichkeiten, auf die ich hinweisen möchte: Nach [CRC08] kennt ein Empfänger beim reinen Pull den Puerinhalt des Senders nicht. Es ist also möglich, dass er die benötigten Daten genau bei den Sendern anfordert, die sie nicht liefern können, wodurch der Empfänger verhungern kann. Erst bei der in [CRC08] Status-basiert genannten Verteilung tauschen Sender und Empfänger Informationen über ihren Puerinhalt aus. Im Gegensatz dazu beinhaltet für die meisten Autoren die Pull- Verteilung jedoch bereits den regelmäÿigen Austausch der Verfügbarkeitsinformationen mittels Buermaps. In [MRG07] wird das Protokoll PRIME vorgestellt, bei dem der Empfänger Daten per Pull bezieht. Magharei et al. sprechen von einem Push-Pull-Ansatz, da die Verfügbarkeitsinformationen von den potentiellen Sendern gepusht werden und die benötigten Segmente per Pull angefordert werden. Auch dies weicht von der allgemeinen Denition für Pull ab und hat leider dazu geführt, dass PRIME in einigen vergleichenden Arbeiten fälschlicherweise als Push-Pull-Protokoll eingeordnet wurde. Sehr viele kommerzielle P2P-Live-Streaming-Systeme wie CoolStreaming, PPLive und UUSee basieren auf einer Mesh-Pull-Architektur, was u.a. darauf zurückzuführen ist, dass es sich um ein einfaches, gut strukturiertes Verfahren handelt, das sich mit den gängigen Client-Playern einsetzen lässt. Zu den bekannten Vertretern der nicht-kommerziellen Mesh-Pull-Protokolle gehört Chainsaw [PK+05] Hybrides Push-Pull Um die Nachteile von reinen Push-Protokollen (Anfälligkeit bei Peer-Churn aufgrund der explizit aufgebauten Multicast-Bäume) und reinen Pull-Protokollen (hoher Kontrolloverhead und lange Abspielverzögerungen) abzuschwächen, sehen neuere Ansätze die Kombination von Push und Pull vor. 40

41 4.2. PROTOKOLLCHARAKTERISTIKEN KAPITEL 4. ANALYSE In [RC08] schlagen Russo et al. vor, die aktuellsten Datensegmente per Push an eine zufällige Untermenge der Partner zu verteilen und nur die fehlenden per Pull anzufordern. Bei PULSE [Pia07, PKB06] pusht die Quelle die Daten und alle anderen Peers holen sie per Pull. Das verringert die Anfangsverzögerung der direkten Nachbarn der Quelle. GridMedia [ZT+05, ZZ+07] wendet einen Pull-Push-Pull-Ansatz an. Ein neuer Peer fragt zunächst explizit nach Buermaps. Nach erfolgreichem Pull eines Pakets abonniert der Peer bei dessen Sender einen Substream und erhält die Daten per Push. Die Pull- Lieferung dient als Fallback-Verfahren. Wenn über 95% der Pakete erfolgreich gepusht werden, fordert er keine Buermaps an. Stehen mehr als 5% der Push-Pakete aus, geht der Peer wieder zum Pull über, fordert Buermaps an und zieht die Daten Gruppenverwaltung Bei IP-Multicast (siehe Abschnitt ) übernehmen die Multicast-fähigen Router Aufgaben der Gruppenverwaltung. Die Router bilden einen Multicast-Baum, verwalten die Mitglieder der Gruppe und verteilen den Stream an die Mitglieder. Bei ALM (siehe Abschnittt ) erfolgt dies auf der Anwendungsschicht. Die Quelle und die Peers bilden den Multicast-Baum. Die P2P-Streaming-Protokolle geben dabei vor, wie der Multicast- Baum errichtet wird (implizit oder explizit), wie die Struktur bei Peer-Churn aufrechterhalten werden kann und wie die Peers der Gruppe beitreten und Daten beziehen können. Die ersten P2P-ALM-Protokolle errichteten explizit einen Multicast-Baum, der entweder zentral verwaltet wurde (wie bei CoopNet [PW+02]), durch hierarchische Cluster- Strukturen (NICE [BBK02], ZIGZAG [THD03]) oder mittels verteilter Algorithmen (DHT oder Mesh) Vater-Sohn-Beziehungen/Partnerschaften In Tree-basierten Systemen baut der Peer eine Verbindung zu einem Vaterknoten auf, damit dieser ihm die Streamdaten weiterleitet. Einige Tree-basierte Systeme sehen darüber hinaus Standby-Väter vor, die im Falle des Ausfalls des aktiven Vaters dessen Rolle übernehmen können [CLB07]. Wird der Multicast-Baum über einem Mesh aufgebaut, können die Nachbarn im Mesh die Rolle der Standby-Väter übernehmen. In Mesh-basierten Systemen kennt jeder Peer mehrere potentielle Sender und tauscht mit ihnen regelmäÿig Buermaps aus. Diese Sender werden Partner (wie bei CoolStreaming) oder Nachbarn (wie bei den meisten anderen Systemen) genannt. Die Anzahl der Partner variiert je nach System. CoolStreaming erzielt laut [ZL+05] optimale Ergebnisse bei 4 bis 6 Partnern. Nach [MR06] kann die Partneranzahl in Mesh-basierten Systemen zwischen 6 und 14 liegen, um eine hohe und aktuelle Lieferqualität zu gewährleisten. Bei Chainsaw [PK+05] hält der Peer eine minimale Partneranzahl aufrecht, lehnt aber eingehende Partneranfragen nie ab. Da mit steigender Partneranzahl die Uploadkapazität pro Partner sinkt, könnte meiner Meinung nach der Peer seine maximale Partneranzahl von seiner verfügbaren Uploadbandbreite abhängig machen, was in den hier besprochenen Systemen nicht realisiert wurde. 41

42 4.2. PROTOKOLLCHARAKTERISTIKEN KAPITEL 4. ANALYSE Peers können zu ihren Partnern Informationen wie das von ihnen erhaltene Datenvolumen speichern (siehe CoolStreaming, PRIME [MRG07]), woraus sich deren Uploadbandbreite schätzen lässt Verwaltung der Gruppenmitglieder Fällt der Datenlieferant eines Peers aus (d.h. der Vaterknoten im Tree-basierten System oder der Partner im Mesh-basierten System), sollte der Peer möglichst schnell einen Ersatzsender nden. Daher muss er andere Knoten im Netzwerk kennen, mit denen er sich verbinden kann. Dies kann entweder zentralisiert, implizit durch die Struktur oder durch gezieltes Membership-Management (auch Knowledge-Management [Pia07]) erfolgen. Die Ansätze, nach denen die Gruppenmitglieder verwaltet werden, können wie folgt unterschieden werden: Zentralisiert Beim Ausfall des Vaterknotens wendet sich der Peer an die Quelle und muss den ganzen Baum nochmals durchlaufen, bis er einen neuen Vaterknoten ndet (Overcast [JG+00]). In einem zentralisierten System wie CoopNet ermittelt der Zentralserver einen neuen Vater. Der zentralisierte Ansatz ist bei hohem Peer-Churn nicht skalierbar. Implizit In Tree-basierten Systemen merken sich die Peers andere Knoten auf ihrem Weg durch den Baum, z.b. bei PeerCast die Groÿväter [DB+02] und bei HostCast [LM03] Groÿväter und Onkel [AYC04]. In den hierarchisch strukturierten Systemen NICE und ZIGZAG kennen die Peers die Knoten in ihrem jeweiligen Cluster. Der Cluster organisiert sich bei Peer-Leave, d.h. wenn Peers das Netz verlassen, selbst. Strukturiertes Membership-Management Die P2P-Streaming-Protokolle Scribe und SplitStream setzen auf dem DHT-Substrat Pastry auf, das die Verbindungen zwischen den Peers verwaltet. Scribe verteilt die Daten nur über einen Multicast-Baum (Single- Tree), während SplitStream mehrere Bäume verwendet (Multi-Tree). Scribe vergibt für die Multicast-Gruppe eine Gruppen-ID, welche im Pastry-Namensraum liegt. Der Peer mit der numerisch nächsten ID wird zum Einstiegspunkt für diese Gruppe und zum Wurzelknoten des Multicast-Baums. Der Multicast-Baum wird durch die Pfade im Pastry-Netzwerk gebildet, die die Gruppenmitglieder mit dem Wurzelknoten verbinden. Auf diesen Pfaden können dabei auch Knoten liegen, die nicht zu der Multicast- Gruppe gehören und die Nachrichten nur weiterleiten. Beim Ausfall eines Knotens ist die Pastry-DHT für die Reparaturmaÿnahmen zuständig. [CD+02, MS07] Bei SplitStream wird der Stream in Substreams (hier Stripes genannt) zerlegt. Jeder Stripe wird über einen anderen Baum verteilt. Für jeden einzelnen Baum wird dabei Scribe verwendet und eine eigene Gruppen-ID angelegt. 42

43 4.2. PROTOKOLLCHARAKTERISTIKEN KAPITEL 4. ANALYSE Unstrukturiertes Membership-Management In unstrukturierten Netzen sollen Peers eine möglichst groÿe Sicht auf das Netzwerk und die Gruppenmitglieder erhalten. In dem kleinen Narada-Netzwerk mit weniger als ungefähr 50 Peers soll jeder Peer alle Mitglieder kennen. Dazu pegt jeder Peer lokal eine Mitgliederliste und erstellt regelmäÿig sogenannte Refresh-Nachrichten, mit denen er sich im Netzwerk bekannt macht. Er schickt die Refresh-Nachricht an seine Nachbarn, die danach ihre Mitgliederliste aktualisieren. Das Wissen über die Mitglieder wird im Netzwerk propagiert, indem die Nachbarn ihre Mitgliederlisten zum Abgleich austauschen. Dieses Verfahren lässt sich in gröÿeren Netzwerken so nicht umsetzen. Lokal kann ein Peer zwar gröÿere Mitgliederlisten mit mehreren Hundert Einträgen verwalten. Beim Austausch der Listen im Netzwerk würde es aber zu einem regelmäÿigen Overhead von mehreren Kilobytes kommen. Vor allem in datenzentrierten Pull-Systemen sollte der Overhead durch Kontrollnachrichten möglichst gering gehalten werden. In groÿen Netzen kennen Peers daher nicht alle Knoten, sondern nur einen Teil. Der Peer erhält sozusagen eine partielle Sicht auf das Netzwerk. Damit die Peers im Netzwerk mit einer groÿen Wahrscheinlichkeit von den Gruppenereignissen erfahren, sollte sich die Gröÿe der partiellen Sicht logarithmisch zur Knotenanzahl verhalten. Die Informationen über Gruppenereignisse (Join, Leave) werden per Gossiping verbreitet, indem die Nachrichten an eine aus der partiellen Sicht zufällig ausgewählte Teilmenge von Peers verschickt werden. SCAMP (Scalable Membership Protocol [GKM03]) wurde nach dieser Idee entworfen und skaliert somit logarithmisch. Bei SCAMP macht sich ein neuer Peer bekannt, indem er eine Subskription an einen Kontaktknoten schickt. Dieser leitet die Subskription an alle Knoten aus der partiellen Sicht weiter sowie an weitere k zufällig gewählte Knoten. k ist hier ein konstanter Wert. Jeder Knoten, der die weitergeleitete Subskription erhält, fügt sie mit einer Wahrscheinlichkeit P (insert) in die lokale partielle Sicht ein und leitet sie dann an einen aus der partiellen Sicht zufällig ausgewählten Knoten weiter. P (insert) wird wie folgt anhand der Gröÿe der partiellen Sicht partialviewsize berechnet: P (insert) = 1/(1 + partialviewsize) Zudem werden regelmäÿig sogenannte Heartbeat-Nachrichten an die Nachbarn verschickt, um gegebenenfalls Isolationen im Netzwerk festzustellen. CoolStreaming und PULSE verbreiten die Gruppennachrichten mit SCAMP [GKM03], wobei PULSE die Weiterleitung der Gruppennachrichten durch eine maximale Hopanzahl begrenzt und CoolStreaming dafür eine Gültigkeitsdauer (Time-To-Live oder TTL) der Nachricht vorsieht. Die CoolStreaming-Autoren denieren die Time-To-Live als Zeitspanne, die z.b. in Sekunden angegeben wird. Analog zur Hopanzahl wird die TTL von den Empfängern der Nachricht jeweils nach unten korrigiert. Sobald die TTL kleiner oder gleich 0 ist, wird die Nachricht nicht mehr weitergeleitet, sondern verworfen. Eine Zeitsynchronisation zwischen den Peers ist somit nicht erforderlich. Nach [ZL+05] werden bei CoolStreaming die Gruppennachrichten Membership-Messages genannt. Sie werden regelmäÿig erstellt, verschickt sowie weitergeleitet. Die Weiterleitung einer Nachricht erfolgt nur, solange die Time-To-Live nicht abgelaufen ist. Über 43

44 4.2. PROTOKOLLCHARAKTERISTIKEN KAPITEL 4. ANALYSE die Membership-Messages erfahren die Peers von Joins, Leaves oder Fails (Ausfall eines Knotens) der anderen Gruppenmitglieder. Die Autoren haben in [ZL+05] nicht beschrieben, wie sie Gossiping per SCAMP in das CoolStreaming-Protokoll implementiert haben. Daher wurden im Rahmen dieser Arbeit folgende zwei Möglichkeiten entwickelt: 1. Ein neuer Peer macht sich im Netzwerk bekannt, indem er eine Membership- Message an den Einstiegspunkt schickt. Analog zum SCAMP-Algorithmus leitet der Einstiegspunkt die Membership-Message an alle Knoten sowie an weitere k zufällig ausgewählte Knoten aus der partiellen Sicht weiter. Der Empfänger der Membership-Message fügt sie mit der in SCAMP denierten Wahrscheinlichkeit P (insert) = 1/(1 + partialviewsize) in die lokale partielle Sicht ein und leitet sie an einen zufällig gewählten Knoten weiter. Solange die TTL gültig ist, wird die Nachricht weitergeleitet. Erst nach Ablauf der TTL erstellt der Peer eine neue Membership-Message, die wiederum nach dem SCAMP-Algorithmus verteilt wird. 2. Ein neuer Knoten trägt die vom Einstiegspunkt erhaltenen Partnerkandidaten in seine partielle Sicht ein. Regelmäÿig (z.b. aller 20 Sekunden) erzeugt der Peer eine Membership-Message, die er an einen zufälligen Knoten aus der partiellen Sicht schickt. Empfängt ein Knoten eine Membership-Message, aktualisiert er anhand der Daten aus der Membership-Message seine partielle Sicht und leitet die Membership- Message an einen zufälligen Knoten weiter. Die Membership-Message wird solange weitergeleitet, bis die TTL abgelaufen ist. Da die Implementierung des CoolStreaming-Protokolls und somit des SCAMP-Algorithmus in CoolStreaming möglichst nah am Original erfolgen sollte, kontaktierte ich Xinyan Zhang, den Entwickler von CoolStreaming, und stellte ihm die zwei oben genannten Implementierungsmöglichkeiten vor. Laut Xinyan Zhang wurde SCAMP ähnlich zu der oben genannten zweiten Variante umgesetzt. Zusätzlich tauschen die Partner nach dem Partnerschaftsaufbau einmalig ihre partiellen Sichten auf das Netzwerk aus. [AYC04, Liu04, Pia07, SZ+08] Fehlerkorrekturmechanismen und Kodierungen In einem P2P-Streaming-Netzwerk müssen die Peers den Stream rechtzeitig zur geplanten Wiedergabe erhalten, um die Daten ohne Aussetzer abspielen zu können. Treen nicht alle Daten rechtzeitig ein (z.b. nach dem Ausfall des Vaterknotens in Tree-basierten Systemen), ist es wünschenswert, dass die Peers den Originalstream dennoch rekonstruieren können. P2P-Streaming-Systeme können zu diesem Ziel Fehlerkorrekturmechanismen oder Kodierungen implementieren und so die Robustheit im Netzwerk zu erhöhen. Es werden redundante Daten erzeugt und versandt, damit auch bei fehlenden Daten der Originalstream wiederhergestellt werden kann. Die in diesem Abschnitt vorgestellten Verfahren unterscheiden sich darin, durch wen im Netzwerk die Kodierung ausgeführt wird. Bei Multiple-Description-Coding (MDC) kodiert nur die Quelle den Stream und die empfangenden Peers dekodieren ihn lediglich. Bei der Vorwärtsfehlerkorrektur (Forward-Error-Correction/FEC) kann entweder nur die Quelle die Kodierung anwenden oder die Peers im Netzwerk. Die Netzwerkkodierung 44

45 4.2. PROTOKOLLCHARAKTERISTIKEN KAPITEL 4. ANALYSE (Network-Coding/NC) sieht vor, dass alle Peers im Netzwerk die Daten kodieren und dekodieren MDC (Multiple-Description-Coding) Multiple-Description-Coding wird in Multi-Tree-Systemen (z.b. CoopNet, SplitStream) angewandt. Der Originalstream wird in mehrere Teilstreams kodiert (sogenannte Descriptions, Substreams oder Slices). Im einfachsten Fall teilt man dabei die Frames nach ihrer Nummerierung auf und erhält eine Description mit den Frames mit geraden Nummern und eine zweite Description mit allen Frames mit ungeraden Nummern [LR+08]. Jede Description wird über einen anderen Baum verteilt. Aus jeder Untermenge von empfangenen Descriptions kann ein Peer den Originalstream rekonstruieren, wobei die Qualität des Streams mit der Anzahl der empfangenen Descriptions steigt. Für die Rekonstruktion benötigt der Peer allerdings zusätzliche Rechenzeit. Um eine gute Qualität gewährleisten zu können, muss jede Description genügend Informationen über den Originalstream enthalten, was sich wiederum negativ auf die Ezienz der Kompression auswirken kann. [Liu04, LR+08] Das Mesh-basierte System PRIME setzt ebenfalls MDC ein. Der Peer fordert so viele Descriptions an, wie es ihm seine Download-Kapazität ermöglicht und kann mit einer wachsenden Zahl von erhaltenen Descriptions seine Abspielqualität verbessern [MR07] FEC (Forward-Error-Correction/Vorwärtsfehlerkorrektur) Bei FEC werden aus den Originaldaten Redunzdaten berechnet, die zusammen mit den Originaldaten versandt werden. Mit Hilfe der Redundanzdaten können bei Übertragungsfehlern die verlorenen Daten wiederhergestellt werden. Um die erforderliche Redundanz zu ermitteln, muss vorab abgeschätzt werden, wie groÿ der auftretende Fehler sein kann. FEC wird gewöhnlich auf der Bitübertragungsschicht angewandt, indem mittels einer XOR-Operation ein Fehlercode aus den zu übertragenden Bits berechnet und übertragen wird. FEC in P2P-Netzwerken kann z.b. durch eine Reed-Solomon-Kodierung [RS60] realisiert werden (wie in dem Live-Streaming-System PULSE [Pia07]). Im PULSE-System wird die Kodierung nur durch die Quelle ausgeführt. Der Stream wird dabei in einzelne Blöcke zerlegt, die als Vektoren über einem endlichen Körper betrachtet werden können. Durch Matrixmultiplikation mit einer sorgfältig gewählten Matrix 1 werden die kodierten Blöcke erzeugt. Die Quelle verschickt die Originalblöcke und die kodierten Redundanzblöcke. Fehlende Originaldaten können mit Hilfe einer inversen Matrix wiederhergestellt werden. Matrixmultiplikation und Invertierung erfordern allerdings einen relativ hohen Rechenaufwand. Falls FEC von Netzwerkknoten angewandt wird, erhöhen die Berechnungen (Kodierung und Dekodierung) auf den Knoten die Verzögerungen im Netzwerk. [LR+08, MF09, MS07] 1 z.b. Vandermonde-Matrix 45

46 4.2. PROTOKOLLCHARAKTERISTIKEN KAPITEL 4. ANALYSE NC (Network-Coding/Netzwerkkodierung) Im Unterschied zur Vorwärtsfehlerkorrektur muss bei der Netzwerkkodierung vorab nicht der mögliche Paketverlust abgeschätzt werden. Hier erstellen alle Knoten im Netzwerk eine Kodierung der erhaltenen Daten und geben sie weiter. Abbildung 4.3 stellt das Prinzip der Netzwerkkodierung vereinfacht dar. Abbildung 4.3: Prinzip der Netzwerkkodierung (NC) [MF09] In der Abbildung 4.3 sind S1 und S2 Sender, die die binären Pakete a und b an X und Y übertragen sollen. Jede Kante kann nur ein Paket transportieren. Der innere Knoten R kann entweder a oder b weiterleiten. Indem R die Summe, a XOR b, berechnet und an X und Y weiterleitet, können die Empfänger die Originaldaten errechnen und gleichzeitig werden weniger Übertragungen benötigt. Die Netzwerkkodierung in P2P-Streaming-Netzwerken erfolgt allerdings nicht mittels XOR-Operationen, sondern durch Multiplikation der erhaltenen Daten mit einer Variablenmatrix. Der Stream wird von der Quelle in einzelne Blöcke zerlegt. Jeder Block kann hier als Eintrag eines Vektors über einem endlichen Körper betrachtet werden. Die inneren Netzwerkknoten berechnen aus den erhaltenen Blöcken eine Linearkombination, indem sie den (aus den Blöcken bestehenden) Vektor mit einer Variablenmatrix multiplizieren. Linearkombination und Variablenmatrix werden versendet. Die Empfängerpeers können die ursprünglichen Blöcke durch Multiplikation der inversen Matrix mit der Linearkombination ermitteln. In der Regel erhält ein Knoten nicht die Originalnachricht, sondern bereits eine Paketkombination. Daher enthält meist jedes Paket Informationen über alle Pakete. Auf diese Weise kann NC nicht nur die Robustheit erhöhen, sondern auch die Datenverfügbarkeit und den Durchsatz im Netzwerk. Problematisch ist der Berechnungsaufwand und die Beobachtung, dass NC die Gesamtverzögerung im Netzwerk erhöht. Wang et al. argumentieren in [WL07] zwar, dass aufgrund der ohnehin hohen Verzögerung beim Streaming die zusätzliche Verzögerung durch NC nicht weiter ins Gewicht fallen würde und dass der Berechnungsaufwand auf einem Standardrechner kein Problem sei. Es ist aber anzunehmen, dass auf weniger leistungsstarken Rechnern (wie z.b. mobilen Geräten) der zusätzliche Berechnungsaufwand ein Problem darstellt. Bei NC in P2P-Streaming handelt es sich um ein sehr neues Forschungsgebiet, auf dem in nächster Zeit sicher mit weiteren Ergebnissen zu rechnen ist. Es wird z.b. vorgeschla- 46

47 4.2. PROTOKOLLCHARAKTERISTIKEN KAPITEL 4. ANALYSE gen, zwischen wichtigen und unwichtigen Multimedia-Daten zu unterscheiden und die aufwändige Dekodierung nur bei wichtigen Daten durchzuführen. [LR+08, MF09, MS07] Transportprotokolle Um den Videostream und die Kontrollnachrichten über das Internet zu versenden, werden Transportprotokolle des Internets benutzt. Das Containerformat wird dabei nicht als kompletter Stream verschickt, sondern zunächst mit einem sogenannten Packetizer in gleich groÿe Pakete des entsprechenden Transportprotokolls zerlegt. Die Pakete werden entweder direkt über die Transportprotokolle der Transportschicht TCP und UDP verschickt. Oder man verwendet je nach Anwendung und Containerformat speziellere Übertragungsprotokolle wie z.b. RTP, das proprietäre RTMP oder GBTP (GoalBit Transport Protocol [BV+09]), welche wiederum auf TCP oder UDP aufbauen. Aus der Sicht des OSI-Schichtenmodells handelt es sich bei RTP, RTMP oder GBTP nicht um tatsächliche Transportprotokolle, da sie in einer Schicht oberhalb der Transportschicht anzusiedeln sind. Dennoch werden sie in der Literatur oft als Transportprotokolle bezeichnet, weil sie für den Datentransport konzipiert wurden (siehe auch [Sch08]) RTP RTP wird oft zum Transport von kontinuierlichen Echtzeitdaten verwendet. Es kann nach Spezikation mit TCP oder UDP zusammenarbeiten. In der Regel setzt RTP aber auf UDP auf und bietet dabei Anpassungen für Echtzeitanwendungen. RTP versieht die Pakete mit einer Kennung für den Payload, einer fortlaufenden Nummer und einem Zeitstempel. Durch die Nummerierung kann der Empfänger feststellen, ob die RTP-Pakete in der richtigen Reihenfolge gesandt wurden. Der Zeitstempel ermöglicht die Synchronisation unterschiedlicher Datenströme (z.b. Audio, Video) [Sim08]. In frühen Versionen konnten RTP-Pakete entweder Audioformate oder Videoformate transportieren, aber nicht beides zusammen. Auf Empfängerseite mussten die Audio- und Videodaten zu einem Stream gemuxt werden. Mittlerweile sieht RTP auch den Transport von Containerformaten nach MPEG-2 oder MPEG-4 vor. Nur wenige P2P-Streaming-Protokolle geben an, ob sie den Transport über RTP vorsehen, ausgenommen CoolStreaming [ZL+05], GridMedia [ZZ+07] und PeerCast [DB+02]. Die meisten P2P-Streaming-Protokolle erwähnen RTP möglicherweise deshalb nicht, da der Fokus dieser Protokolle auf dem Aufbau des P2P-Streaming-Overlays und dem Datenaustausch liegt. Die Verwendung von RTP spielt hierbei nur eine untergeordnete Rolle und hat keinen Einuss auf die sonstigen Protokollcharakteristiken. Beim Transport mit RTP wird durch den 12-Byte-RTP-Header zusätzlicher Overhead erzeugt [Sim08]. Zudem versieht oft das P2P-Streaming-Protokoll die Chunks mit Sequenznummer und Zeitstempel und nimmt die Sortierung auf Empfängerseite vor, so dass der Einsatz von RTP nicht notwendig erscheint und lediglich zu redundanten Daten führt. 47

48 4.2. PROTOKOLLCHARAKTERISTIKEN KAPITEL 4. ANALYSE UDP UDP, ein Protokoll der Transportschicht im OSI-Schichtenmodell, ist ein verbindungsloses Protokoll mit eingeschränkter Zuverlässigkeit [Kle05]. Die Datensegmente werden versandt ohne Garantie, dass sie vollständig oder in korrekter Reihenfolge ankommen. Da UDP so viele Daten verschickt, wie es die Bandbreite erlaubt, und zudem kein Verbindungsaufbau zwischen Sender und Empfänger stattndet, bietet UDP einen schnellen Datentransport ohne garantierte Qualität. Daher eignet sich UDP für Echtzeitanwendungen im Internet, für die ein kontinuierlicher Datenuss in minderer Qualität eher akzeptabel ist als ein Datenuss in hoher Qualität, der stockt oder ausfällt. Gegen den groÿächigen Einsatz von UDP im Internet sprach lange, dass das Internet unter der UDP-Last zusammenbrechen könnte, was sich bisher nicht bewahrheiten konnte [Zha10]. Allerdings wird UDP oft von Firewalls blockiert. P2P-Streaming-Protokolle verwenden UDP oft zum Versand der Kontrollnachrichten (z.b. PULSE, PPLive, PPStream, SopCast, TVAnts [Pia07, SF+08]). Die kommerziellen Anbieter PPLive, PPStream und SopCast setzen UDP auch für den Datenversand ein [Zha10] TCP TCP, neben UDP das zweite echte Transportprotokoll, ist verbindungsorientiert und realisiert einen zuverlässigen bidirektionalen Datenübertragungsdienst mit Flusskontrolle [Kle05]. Die Einhaltung der Bytereihenfolge wird garantiert, nicht empfangene Pakete werden nochmals versandt und durch die Flusskontrolle kann die Senderate verringert werden. TCP sieht zudem mehrere gleichzeitige Verbindungen vor. All diese Eigenschaften verlangsamen den tatsächlichen Transport, was TCP zunächst für Echtzeitanwendungen uninteressant macht. Andererseits lässt sich die Verbindungsorientiertheit von TCP in P2P-Streaming-Sitzungen gut integrieren. Beim Datenaustausch werden in Tree-basierten Systemen Verbindungen zwischen Vater und Sohn erstellt, in Mesh-basierten zwischen Partnern. Wird dazu eine TCP-Verbindung errichtet, erhält der Peer bei Ausfall des Partners ein FIN-Segment. Um den Partnerausfall festzustellen, müssen somit auf der Anwendungsschicht keine weiteren Mechanismen implementiert werden, welche wiederum Overhead verursachen könnten (wie der Versand von Heartbeat- Nachrichten bei Narada). Daher verwenden einige Protokolle TCP (siehe PULSE [Pia07]) oder eine leichtgewichtigere Variante von TCP (siehe R 2 [WL07]). Narada [CR+02] verwendet als leichtgewichtigere Variante von TCP das Protokoll TFRC (TCP Friendly Rate Control [HF+03]). Bullet [KR+03] implementiert TFRC, ohne verloren gegangene Segmente nochmals zu übertragen mit der Begründung, dass nicht erhaltene Segmente wesentlich schneller von anderen Peers bezogen werden können als durch den nochmaligen Versand mit TFRC Wahl des Transportprotokolls Bei der Wahl des Transportprotokolls ist es wichtig zwischen den Kontrollnachrichten an beliebige Peers und den Nachrichten an die Partner zu unterscheiden. Für den 48

49 4.3. MESH-PULL-KOMPONENTEN KAPITEL 4. ANALYSE Versand von Kontrollnachrichten zu anderen Peers im Overlay (z.b. von Membership- Nachrichten) bietet sich UDP an. Da der eigentliche Datenaustausch und der Versand der dazugehörigen Kontrollnachrichten 2 nur zwischen Partnern bzw. Vätern und Söhnen stattndet, halte ich hier den Einsatz einer leichtgewichtigen TCP-Variante für sinnvoll. Die Partnerschaft kann hier errichtet werden, indem die TCP-Verbindung aufgebaut wird. Wird die Partnerschaft beendet (bei Leave oder Fail) wird auch die TCP-Verbindung beendet. Um den Overhead durch Kontrollnachrichten zu minimieren, schlagen einige P2P-Streaming-Protokolle vor, die Kontrollnachrichten an die Partner mit den Streamdaten im Payload zu versenden. Man bezeichnet diesen Versand als piggyback (engl. für Huckepack). CoolStreaming verwendet als Transportprotokoll für die Streamdaten RTP in Verbindung mit UDP, TCP oder TFRC. In der Implementierung verwende ich aus oben genannten Gründen UDP für den Versand von Membership-Nachrichten und TFRC für den Nachrichtenaustausch zwischen Partnern, allerdings ohne nochmalige Übertragung oder Flusskontrolle Überblick In diesem Abschnitt wurden die wesentlichen Charakteristiken von CoolStreaming mit denen anderer P2P-Live-Streaming-Protokolle verglichen. Für eine umfassende Übersicht fasst Tabelle 4.1 die Eigenschaften der bekanntesten P2P-Live-Streaming-Protokolle zusammen. Bei dieser tabellarischen Übersicht gehe ich insbesondere auf den Aspekt der Datenverteilung und auf die Gruppenverwaltung durch Membership-Management ein. Mittels Membership-Management können Peers weitere Peers im Netzwerk kennenlernen und so im Falle von Leave oder Fail eines Partners schnell neue Partnerschaften aufbauen. 4.3 Komponenten von Mesh-Pull-Protokollen In Mesh-Pull-Systemen wie CoolStreaming werden die Streamdaten über dynamische Routen im Mesh verteilt, wobei die Peers die Streamdaten explizit bei ihren Partnern anfordern (Pull). Die Datenverteilungswege werden in Mesh-Pull-Systemen durch den Scheduler bestimmt, der anhand der Partner-Buermaps ermittelt, bei welchen Partnern welche Segmente angefragt werden Scheduler Die zentrale Komponente bei Mesh-Pull-Mechanismen ist der Scheduler, auch Scheduling-Algorithmus, Packet-Scheduling-Algorithmus/PSA oder Request-Scheduling-Algorithmus [Pia07] genannt. Der Scheduler wird regelmäÿig aufgerufen und berechnet, bei welchen Partnern welche Segmente angefragt werden. 2 (Buermaps und Requests in Mesh-basierten Systemen) 49

50 4.3. MESH-PULL-KOMPONENTEN KAPITEL 4. ANALYSE Protokoll Jahr Membership-Management Topologie der Streamverteilung Art der Streamverteilung ALMI [PS+01] 2001 Zentralisiert: Session-Controller (auch Rendezvous-Point genannt) Single-Tree Mesh-rst [AYC04, SW05]/ Push Single-Tree Tree-rst [HA+06] Bullet [KR+03] 2003 Mesh (RanSub) Erst Tree, darüber Mesh (für fehlende Push-Pull Chunks) Chainsaw [PK+05] 2005 Mesh Mesh Pull Chunkyspread [VFC06] 2006 Gossiping im Mesh (Swaplinks) Multiple-Tree Push CoolStreaming [ZL+05] 2004 Gossiping im Mesh (SCAMP) Mesh Pull CoopNet [PW+02] 2002 Zentraler Server Multiple-Tree Tree-rst Push GridMedia [ZT+05] 2005 Gossiping Unstrukturiertes Overlay Pull-Push-Pull HostCast [LM03] 2003 Implizit (Onkel+Groÿväter bekannt) Single-Tree Tree-rst Push Narada [CRZ00] 2000 Mesh Single-Tree Mesh-rst Push NICE [BBK02] 2002 Cluster Single-Tree Mesh-rst Push Overcast [JG+00] 2000 Zentralisiert: Quelle Single-Tree Tree-rst Push PeerCast [DB+02] 2002 Implizit (Groÿväter bekannt) Single-Tree Tree-rst Push PPLive [ppl] 2004 Gossiping im Mesh Mesh Pull PRIME [MR07] 2007 Bootstrap-Node/Gossiping Strukturiertes, unidirektionales Mesh Pull PULSE [PKB06] 2006 Gossiping im Mesh (SCAMP) Mesh Push (Quelle), Pull (Peers) R 2 [WL07] 2007 Gossiping im Mesh Mesh Random-Push mit Random-Network-Coding Scribe [CD+02] 2002 DHT (Pastry) Single-Tree über Pastry Push SopCast [sop] 2005 Gossiping im Mesh Mesh Pull SplitStream [CD+03] 2003 DHT (Pastry) Multiple-Tree über Pastry Push YOID [Fra00] 2000 Rendezvous-Point Single-Tree Tree-rst Push ZIGZAG [THD03] 2003 Cluster Single-Tree Mesh-rst Push Tabelle 4.1: Vergleich der Charakteristiken von P2P-Live-Streaming-Protokollen [AYC04, HA+06, Liu04, MR07, Pia07, SW05, SZ+08, VFC06, VY07, Wan08, ZZ+07] 50

51 4.3. MESH-PULL-KOMPONENTEN KAPITEL 4. ANALYSE Die Scheduler in den untersuchten Protokollen unterscheiden sich bzgl. der Wahl der angeforderten Segmente (Chunk-Selection) und der Wahl des potentiellen Senders (Peer- Selection). Chunk-Selection PRIME fordert zuerst die aktuellsten Segmente an. Eine ähnliche Strategie empfehlen die Autoren in [YDL07]. Hier werden zunächst die aktuellsten Segmente angefordert. Wenn diese nicht verfügbar sind, werden die älteren Segmente angefragt, die als nächstes abgespielt werden sollen. Die Anfangsverzögerung bei dieser Strategie ist gröÿer, als wenn nur die demnächst abzuspielenden Segmente angefordert werden. CoolStreaming fordert die fehlenden Segmente nach der Verfügbarkeit bei den Partnern an, so dass Segmente, die nur einmal verfügbar sind, zuerst angefragt werden. Man bezeichnet dieses Verfahren als Rarest-First. Bei diesem Verfahren kann es passieren, dass die Peers mit den seltensten Segmenten im Netzwerk von Anfragen überschwemmt werden. Um dies zu verhindern, sollte jeder Peer nur so viele Anfragen an einen Partner schicken, wie dieser voraussichtlich bearbeiten kann. Zu diesem Zweck kann z.b. eine Obergrenze für Anfragen pro Partner deniert werden. Oder man wendet heuristische Verfahren an, um die verfügbare Uploadbandbreite des Partners zu ermitteln. Dieses Verfahren wird im folgenden Abschnitt besprochen. Einige Protokolle sehen darüber hinaus vor, dass die Anzahl der anzufordernden Segmente je Scheduling-Lauf beschränkt wird. CoolStreaming sieht laut [ZL+05] keine derartige Begrenzung vor, was theoretisch dazu führen kann, dass ein neuer Peer, der eine laufende Streaming-Sitzung betritt, versucht, seinen gesamten Puer zu befüllen und dabei die Partner mit Anfragen überschwemmt. Peer-Selection Es bieten sich folgende Mechanismen an, um die Segmentanfragen auf die Partner, die die Segmente liefern können, zu verteilen: Random: Fehlende Segmente werden zufällig bei den Partnern angefordert (siehe z.b. Chainsaw [ZX+09]). Ohne die Implementierung eines Zufallsgenerators könnte dies zu einer ungleichen Verteilung der Pull-Requests und somit der Bandbreitenanforderungen führen. Denn werden n fehlende Segmente bei n Partnern angefragt, wird bei einem Partner mit einer Wahrscheinlichkeit von 1/e (d.h. 36,79%) kein Segment angefordert. Round-Robin: Die Anfragen werden gleichmäÿig auf die Partner verteilt. Die Bandbreitenkapazitäten der Partner werden nicht berücksichtigt. Partner mit hoher Bandbreite können bei der Methode möglicherweise zu wenig angefragt werden und Partner mit einer niedrigen Bandbreite durch Pull-Requests überlastet. Heuristische Bandbreitenschätzung: CoolStreaming und PRIME weisen ihren Partnern die Pull-Requests gemäÿ ihrer geschätzten Uploadbandbreite zu. Die Qualität dieses Verfahrens hängt von der Qualität der Bandbreitenschätzung ab (siehe auch ). Bei einer zuverlässig funktionierenden Bandbreitenschätzung stellt dieses Verfahren die fairste Variante dar, ist aber komplexer und damit auch fehleranfälliger. 51

52 4.4. PERFORMANCE-VERGLEICH KAPITEL 4. ANALYSE Um Überlastungen des Partners zu vermeiden, kann die Anzahl der Pull-Requests pro Partner begrenzt werden. Auch bei einer zuverlässigen Bandbreitenschätzung würde dies zumindest als Fallback-Mechanismus dienen. So wie einige andere Protokolle sieht CoolStreaming diese Begrenzung nicht vor Bearbeitung von Datenrequests Für den Partner, der Datenanfragen erhält, stellt sich die Frage, in welcher Reihenfolge er diese bearbeitet. Verschickt er die Daten so, wie sie angefragt werden (FIFO), kann es passieren, dass ein Partner, der mehrere Segmente auf einmal anfordert, die gesamte Uploadkapazität des Senders in Anspruch nimmt. Bei PULSE verwaltet der Peer für jeden Partner eine Request-Queue und zu jedem Segment einen Zähler replica count, der festhält, wie oft der Peer das Segment bereits an Partner verschickt hat. Erhält der Peer mehrere Anfragen auf einmal, verschickt er zuerst die Segmente, die bisher am seltensten versandt wurden, damit diese schneller im Netz verteilt werden. Die anderen verschickt er in zufälliger Reihenfolge. GridMedia verwendet einen anderen sehr interessanten Ansatz. Systemweit wird ein Requestintervall t deniert. Die Sender verschicken Segmente nur während des Requestintervalls t. Nach Ablauf von t verwirft der Sender alle nicht bearbeiteten Anfragen. Fordert ein Peer ein Segment an und erhält es nicht nach Ablauf von t+round-trip-time, weiÿ er, dass er das Segment nochmals anfordern muss und lässt den Scheduler erneut den potentiellen Sender ermitteln [ZZ+07]. Da der Sender nicht alle Anfragen bearbeitet, muss er dafür sorgen, dass die anfragenden Peers fair bedient werden. Eine faire Methode wäre ein Zähler, der für jeden Partner den Anteil der bearbeiteten Requests speichert und aktualisiert. Diese Methode ist einfacher zu implementieren und weniger speicherintensiv, als beispielsweise für jeden Partner eine eigene Request-Queue vorzusehen. GridMedia bietet somit eine Lösung, wie im Falle von nicht erhaltenen Segmenten vorzugehen ist. Um zu verhindern, dass nicht erhaltene Segmente die Wiedergabe massiv beeinträchtigen, könnte also ein Segment nach Ablauf eines Zeitintervalls nochmals angefordert werden (in der Honung, dass es rechtzeitig eintrit) oder das fehlende Segment wird mit Hilfe eines Fehlerkorrekturmechanismus wie FEC rekonstruiert (siehe Abschnitt ). Die CoolStreaming-Autoren geben in [ZL+05] lediglich an, dass angeforderte Segmente durch RTP verschickt werden. 4.4 Performance-Vergleich Die Qualität von P2P-Streaming-Protokollen lässt sich entweder durch die sogenannte Quality of Experience (QoE) ausdrücken oder anhand messbarer Eigenschaften. Quality of Experience stellt nach Huang von PPLive zwar die wichtigste Metrik dar, spiegelt aber nur die subjektive Dienstgüte beim Empfänger wieder. Die Benutzer können z.b. Auskunft darüber geben, wie gut sie die Bildqualität oder wie störend sie Verzögerungen empfunden haben. Die QoE lässt sich in der Regel nicht automatisiert erfassen oder vergleichen. [Hua07, tuc10] 52

53 4.4. PERFORMANCE-VERGLEICH KAPITEL 4. ANALYSE Daher wendet man die Mittel der Performance-Evaluierung an. Analog zur Performance- Evaluierung im P2P-Bereich gilt es auch bei den P2P-Streaming-Protokollen herauszunden, ob das Protokoll die Eigenschaften Skalierbarkeit, Robustheit und Ezienz aufweist Protokolleigenschaften Jede der Eigenschaften Skalierbarkeit, Robustheit und Ezienz wird durch Metriken ausgedrückt, die sich wiederum aus einem oder mehreren Messwerten zusammensetzen [Wol10]. Skalierbarkeit bezeichnet die Fähigkeit eines P2P-/P2P-Streaming-Netzwerks, sich an eine quantitativ wachsende Anzahl von Peers und/oder Daten anzupassen [Wol10]. Die Skalierbarkeit wird in Bezug auf eine messbare Kenngröÿe ausgedrückt, z.b. in Bezug auf den Kontrolloverhead (auch Protokolloverhead), der durch das Verhältnis des Kontrolldatenvolumens zum Videodatenvolumen ermittelt wird. Ist das Wachstum des Kontrolloverheads bei wachsender Peeranzahl logarithmisch begrenzt durch O(logN), kann man sagen, dass das System in Bezug auf den Kontrolloverhead skaliert [MS07]. Robustheit beschreibt die Eigenschaft eines Netzwerks, auch unter hoher Last und bei Fehlern (z.b. Ausfällen der Netzwerkstruktur) ein speziziertes Leistungsniveau zu erhalten [Wol10]. Die Robustheit bezieht sich ebenfalls auf eine Kenngröÿe, die in P2P- Streaming-Netzwerken meist unter starkem Churn gemessen wird. Ezienz wird in [FH07] ganz allgemein als Wirkungsgrad von Aktivitäten deniert. In einem P2P-Streaming-Netzwerk kann Ezienz dadurch ausgedrückt werden, wie gut beim Streamingprozess vorhandene Ressourcen (insbesondere die Netzwerkbandbreite) genutzt werden. In einem System mit einer hohen Bandbreitenezienz wird z.b. die Uploadbandbreite aller Peers bestmöglich verwendet P2P-Streaming-Metriken Die ersten ALM-Systeme wurden als Alternative zu IP-Multicast entwickelt, weshalb bei diesen Tree-basierten ALM-Systemen zur Evaluierung Metriken wie Path-Stretch und Link-Stress ausschlaggebend waren. Path-Stretch misst das Verhältnis der Pfadlängen in der Topologie im Vergleich zum kürzesten Pfad (dem direkten Unicast-Weg bzw. der Ende-zu-Ende-Verzögerung/EED). Link-Stress misst die Anzahl von identischen Paketen auf einzelnen Teilstrecken, also den Overhead durch redundante Daten. Durch Path- Stretch und Link-Stress lässt sich bestimmen, wie ezient ein ALM-System im Vergleich zu IP-Multicast die Daten verschickt. [SWS07] Die Herausforderung für Tree-basierte Protokolle im Streamingprozess besteht aber eigentlich darin, einen Baum mit geringer Höhe zu errichten und bei Peer-Churn diesen Baum auszubalancieren. Daher müssen in Tree-basierten Systemen Nachrichten mit Routingtabellen [CRZ00], Membership-Nachrichten und weitere Kontrollnachrichten ausgetauscht werden, die in die Bezierung der Metrik Kontrolloverhead einieÿen: 53

54 4.4. PERFORMANCE-VERGLEICH KAPITEL 4. ANALYSE Kontrolloverhead ist das Verhältnis aller Kontrollnachrichten in Bytes zu den reinen Videostreamdaten in Bytes. Der Kontrolloverhead kann entweder als Wert zwischen 0 und 1 oder in Prozent angegeben werden. In Mesh-basierten Systemen ist der Kontrolloverhead sowohl bei Peer-Churn als auch bei Anstieg der Peeranzahl so gut wie konstant. Das liegt an der dynamischen Wahl von Sendern (also temporären Vätern) sowie an der konstanten Anzahl von Partnern, an die jeder Peer den Groÿteil der Kontrollnachrichten verschickt. Beim Test eines Protokolls kann der Kontrolloverhead als Funktion anderer Gröÿen wie z.b. der Partneranzahl gemessen werden, um optimale Parameterwerte zu ermitteln. In Tree-basierten Systemen hängt der Kontrolloverhead vom Wachstum des Netzwerks ab (siehe Tabelle 4.2). Der geringe Kontrolloverhead von ZIGZAG erklärt sich hier dadurch, dass die Peers hierarchisch in Clustern strukturiert werden und nur innerhalb dieses Clusters Gruppennachrichten austauschen. Protokoll ALMI CoopNet Narada NICE Overcast Kontrolloverhead O(N) O(logN) O(N)[CRZ00] bzw. O(N 2 )[HA+06] O(logN) O(logN) Scribe O(log b 2N) SplitStream YOID ZIGZAG O(NlogN) bis O(N 2 ) worst-case O(logN) O(k) bis O(logN) mit k=konstanter Knotengrad Tabelle 4.2: Kontrolloverhead von Tree-basierten ALM-Protokollen in Relation zur Knotenanzahl N [AYC04, CRZ00, HA+06] Beim Live-Streaming sind insbesondere die Verzögerungen bei der Wiedergabe ausschlaggebend. Diese sollten so gering wie möglich sein. Nach Auswahl des Kanals sollte der Benutzer nicht lange auf den Beginn der Übertragung warten müssen und die Daten auch nicht wesentlich später als seine Nachbarn erhalten. Während im Tree-basierten Netzwerk die Abspielverzögerung eines Peers durch seine Position im Baum bestimmt wird und somit konstant ist, schwanken die Verzögerungen in Mesh-basierten Systemen stark und stellen daher wichtige Metriken dar. Startup-Delay/Anfangsverzögerung beziert die Zeitdierenz zwischen der Kanalauswahl und dem Beginn der Wiedergabe des Live-Streams. Die Anfangsverzögerung wird in der P2P-Streaming-Literatur auch als Initial-Startup-Latency [HLR08], Click-to-play- Delay/C2P [Pia07] oder SETUP-Delay [MP+08] bezeichnet. Playback-Delay/Abspielverzögerung beziert die Zeitdierenz zwischen der Ausgabe eines Streamsegments durch die Quelle und dessen Wiedergabe durch den Peer. Synonym zu Playback-Delay werden die Begrie Playout-Delay [MR07], Display-Lag [HLR08], Average-Reception-Delay [Pia07] verwendet. 54

55 4.4. PERFORMANCE-VERGLEICH KAPITEL 4. ANALYSE Eine weitere wichtige Metrik für Mesh-basiertes P2P-Streaming stellt der Continuity- Index dar: Continuity-Index (Playback-Continuity-Index, Playback-Continuity) gibt an, wie kontinuierlich die Wiedergabe des Streams erfolgt. Damit ein Stream kontinuierlich und ohne Aussetzer abgespielt werden kann, müssen die Streamsegmente rechtzeitig (d.h. vor ihrem jeweiligen Abspielzeitpunkt) eintreen. Der Continuity-Index wird ermittelt, indem man die Anzahl der rechtzeitig erhaltenen Segmente durch die Anzahl aller Segmente teilt, die hätten abgespielt werden sollen. Der Continuity-Index kann entweder als Wert zwischen 0 und 1 oder in Prozent angegeben werden. Die Streamingqualität drückt sich dadurch aus, dass der Peer den Stream möglichst ohne Aussetzer empfängt, weshalb ein gröÿtmöglicher Teil der Segmente vor der Playback- Deadline beim Peer eintreen sollte. Der Continuity-Index kann als Funktion in Relation zur Partneranzahl, zur Streamingrate oder zu anderen Parametern ermittelt werden. Tabelle 4.3 vergleicht einige bekannte ALM-Protokolle anhand der besprochenen Metriken (Startup-Delay, Playback-Delay, Continuity-Index, Kontrolloverhead). Die Protokolle sind entweder rein Mesh-basiert (CoolStreaming, GridMedia, PPLive, SopCast) oder benutzen einen Mesh-/Tree-Ansatz (Bullet, PRIME). Protokoll Startup-Delay Playback-Delay Continuity-Index bei Streamingraten von kbps / 380 kbps Kontrolloverhead Bullet % CoolStreaming mind. 1min mind. 1min 99,5% / 99,3% [ZL+05] 90% / 85% [LJ+06] GridMedia - 2,2-7s % / - 3% PPLive 20s - 2min 1min - 5% PRIME 30-48s SopCast 37s - 5min 1min 88% / % 5% Tabelle 4.3: Vergleich von Metriken bei Mesh-basierten und Mesh-/Tree-basierten ALM- Protokollen [Kos08, KR+03, LJ+06, OJ08, ZL+05, ZZ+07] In Tabelle 4.3 fällt auf, dass unterschiedliche Werte für den Continuity-Index des Cool- Streaming-Protokolls gemessen wurden. Bei einer Streamingrate von 380 kbps messen die CoolStreaming-Autoren z.b. einen Continuity-Index von 99,3% [ZL+05], während Liao et al. in [LJ+06] lediglich auf einen Continuity-Index von 85% kommen. D.h. nach Liao et al. erhält ein CoolStreaming-Benutzer durchschnittlich 15% des Streams nicht rechtzeitig. In [ZL+05] wurde der Continuity-Index in einer Simulation mit 200 Peers gemessen, in [LJ+06] dagegen mit 400 Peers. In [ZL+05] hat ein Peer durchschnittlich 5 Partner, in [LJ+06] mindestens 5 Partner. Skalierbarkeit und Robustheit eines P2P-Streaming-Protokolls lassen sich durch die Metriken Startup-Delay, Playback-Delay und Continuity-Index ausdrücken. Der Kontrolloverhead ist insbesondere dann interessant, wenn man ein bestehendes Protokoll strukturell verändert und die Auswirkungen testen will. 2% 55

56 4.5. GRAPH-ANALYSE KAPITEL 4. ANALYSE In [ZL+05] ermittelten die Autoren die Skalierbarkeit von CoolStreaming unter Berücksichtigung von Kontrolloverhead und Continuity-Index. Da der Kontrolloverhead unabhängig von der Overlaygröÿe ist und der Continuity-Index auch beim Wachstum des Netzes von 10 auf 200 Knoten nicht unter 95% fällt, kann man folgern, dass CoolStreaming skaliert. Bei starkem Churn, wenn jeder Peer z.b. aller 100 Sekunden das Netz betritt und wieder verlässt, sinkt der Continuity-Index nicht unter 91%, wodurch sich die relative Robustheit des Systems zeigt. 4.5 Graph-Analyse CoolStreaming wendet Gossiping an, um Gruppennachrichten über Joins, den aktuellen Status (Partneranzahl etc.) oder Leaves der Peers zu verteilen. Jeder Peer kennt daher eine zufällige Teilmenge aller Knoten im Netzwerk, die er in einer partiellen Sicht speichert. Da sowohl Partnerkandidaten für neue Knoten als auch Partner als Ersatz für ausgefallene Knoten zudem zufällig aus der partiellen Sicht ausgewählt werden, erzeugt CoolStreaming einen zufälligen Verbindungsgraph (siehe Abbildung 4.4). Der Grad jedes Knotens in diesem Verbindungsgraph liegt aufgrund der Partneranzahl in einem bestimmten Bereich, optimalerweise zwischen 4 und 6 [ZL+05] Abbildung 4.4: Zufälliger Verbindungsgraph des CoolStreaming-Netzwerks (10 Peers, maximale Partneranzahl=5) Die Graph-Analyse in P2P-Streaming-Netzen unterscheidet sich von der Graph-Analyse in klassischen P2P-Netzen. In P2P-Netzen werden Dateien gesucht, die irgendwo im Netzwerk liegen können. Für eine eziente Suche ist daher der Durchmesser entscheidend, d.h. die Länge der längsten aller kürzesten Pfade im Netzwerk. In P2P-Streaming-Netzen geht es darum, dass die Peers die von der Quelle gestreamten Daten auch bei wachsendem Netzwerk schnellstmöglich erhalten. Aus diesem Grund wird der Abstand zwischen Quelle und Peer betrachtet. Man spricht in diesem Zusammenhang von Overlay-Radius oder Tiefe bzw. Höhe des Multicast-Baumes. In [ZL+05] haben die Autoren eine logarithmische Relation zwischen Overlay-Radius und 56

57 4.6. ZUSAMMENFASSUNG KAPITEL 4. ANALYSE Netzwerkgröÿe gezeigt. Die durchschnittliche Distanz von der Quelle zu einem Peer wird durch O(logN) begrenzt, mit N = Anzahl der Knoten im Netz. Das CoolStreaming- System skaliert demnach in Bezug auf die Ende-zu-Ende-Verzögerung. 4.6 Zusammenfassung CoolStreaming CoolStreaming verteilt die Daten über ein zufällig erzeugtes Mesh. Die Datenverteilung erfolgt über Pull, d.h. die Peers fordern fehlende Daten bei ihren Partner an. Die Mesh-Pull-Struktur ist einfach strukturiert und lässt sich somit gut implementieren, weshalb sie von allen gröÿeren kommerziellen Systemen (wie PPLive, PPStream, SopCast, TVAnts) eingesetzt wird. Zudem bietet die Mesh-Pull-Struktur im Vergleich zu den Tree-basierten Strukturen den Vorteil, dass sie die Bandbreitenkapazitäten der Peers gleichmäÿiger nutzt und ein robustes Netz erzeugt, das wenig anfällig bei Peer-Churn ist. Beim P2P-Live-Streaming ist vor allem die Robustheit bei Peer-Churn eine wichtige Anforderung, da es in diesem Anwendungsbereich zu Flash-Crowds und somit zu starkem Churn kommen kann. Problematisch in Mesh-Pull-Systemen sind die Verzögerungen und der Overhead durch Kontrollnachrichten. Die Verzögerungen bei CoolStreaming können von einer Minute bis zu mehreren Minuten (nach Userberichten) betragen. Der Kontrolloverhead ist mit 2% im Vergleich zu anderen Mesh-Pull-Protokollen dagegen relativ niedrig (siehe auch Tabelle 4.3). Abbildung 4.5 zeigt den Aufbau des CoolStreaming-Systems nach [ZL+05]. Die Autoren unterscheiden zwischen den Kernkomponenten Membershipmanager (für die Verwaltung der partiellen Sicht), Partnershipmanager (für die Verwaltung von Partnerschaften) und Scheduler. In vielen P2P-Streaming-Arbeiten wird vor allem der besondere Scheduling-Algorithmus von CoolStreaming hervorgehoben, der die Segmente gemäÿ ihrer Verfügbarkeit bei den Partnern in Buermap-ähnlicher Art anfordert. Ist ein Segment nur bei einem Partner lieferbar, wird es immer bei diesem angefragt. Segmente, die mehrmals verfügbar sind, werden nach der geschätzten Uploadbandbreite der Partner angefordert. Hat ein Partner keine Bandbreitenkapazitäten übrig, erhält er keine Datenrequests. Eingehende Datenrequests werden sortiert über RTP verschickt. Mit Sicherheit stellte der CoolStreaming-Scheduler zu der Zeit seiner Veröentlichung eine groÿe Neuerung dar, dennoch ergeben sich bei genauerer Prüfung des in [ZL+05] veröentlichten Algorithmus folgende mögliche Probleme: 1. Die Qualität des Algorithmus hängt von der Korrektheit der heuristischen Bandbreitenschätzung ab. 2. CoolStreaming deniert keine generellen Obergrenzen für die Anzahl der insgesamt angefragten Segmente. Ein neuer Peer, der seinen kompletten Puer füllen möchte, kann seine Partner mit Anfragen überschwemmen. 3. Da CoolStreaming auch keine Obergrenze für die Anzahl der angefragten Segmente pro Partner deniert und alle nur einmal verfügbaren Segmente bei dem entsprechenden Partner ordert, ist folgendes Szenario möglich: Ein Partner, der neuere 57

58 4.6. ZUSAMMENFASSUNG KAPITEL 4. ANALYSE Player Puffer Buffermap Membershipmanager Partnershipmanager Scheduler Netzwerk-Interface Partner Partner Partner Abbildung 4.5: Systemdiagramm eines CoolStreaming-Peers (nach [ZL+05]) Daten hat als die anderen, erhält alle Datenrequests, da er als einziger die neuesten Segmente liefern kann. 4. Da in [ZL+05] nicht deniert wurde, dass ein Peer eingehende Datenrequests in einer bestimmten Reihenfolge abarbeitet oder bei Überlastung Datenrequests ablehnen kann, kann man daraus schlieÿen, dass Requests so bearbeitet werden, wie sie eintreen. Erhält ein Partner mehr Requests als er bearbeiten kann, kommt es zu einer Überbeanspruchung seiner Bandbreitenkapazität. Dadurch kann der Peer schlieÿlich vollständig überlastet werden. Die Verzögerungen auf Seiten der wartenden Empfänger würden sich immer mehr kumulieren. 5. Auch wenn in [ZL+05] und in anderer P2P-Streaming-Literatur betont wird, dass die seltensten Segmente zuerst angefragt werden, ist dies nicht immer gewährleistet. Die Peers fordern die fehlenden Segmente in Buermap-ähnlicher Art an. Beispielsweise erstellt ein Peer P1 für jeden Partner einen Bit-String von der Gröÿe des Puers. Jedes Bit steht für ein Segment. Benötigte Bits werden mit einer 1 markiert, nicht benötigte mit 0. Der Oset dieses Strings entspricht der ID des ersten Puerelements, so dass die IDs der zu liefernden Segmente leicht ermittelt werden können. Wenn P1 bei einem Partner mehrere Segmente anfordert, so werden die Segmente aufgrund des Bit-Strings aufsteigend nach ihrer ID angefordert, d.h. die ältesten Puersegmente zuerst. Das Ziel, dass die seltensten Segmente immer zuerst angefordert werden, wird durch die Buermap-ähnliche Anfrage kolportiert. Abschlieÿend möchte ich betonen, dass es durchaus möglich ist, dass die oben geschil- 58

59 4.6. ZUSAMMENFASSUNG KAPITEL 4. ANALYSE derten Probleme in der tatsächlichen CoolStreaming-Implementierung gelöst wurden, da die Autoren in [ZL+05] nicht alle Protokollcharakteristiken dokumentiert haben. Auf eine Nachfrage meinerseits hin hat mir aber der CoolStreaming-Entwickler Xinyan Zhang die zuletzt erwähnte Unstimmigkeit bestätigt, nach der die seltensten Segmente nicht immer zuerst angefragt werden. Sollte dies bei der Implementierung zu Problemen, z.b. Aussetzern, führen, lieÿe sich das einfach dadurch lösen, dass die Segmente in einer Liste angefragt werden. Zu bedenken ist hier, dass dies die Gröÿe der Kontrollnachrichten erhöht. 59

60 5 Implementierung Dieses Kapitel behandelt die wesentlichen Aspekte der Implementierung des CoolStreaming-Protokolls. Zunächst wird die Auswahl eines geeigneten Vorgehensmodell für Softwareprojekte besprochen. Dann wird auf die Besonderheiten hingewiesen, die es bei der Implementierung in den P2P-Simulator P2PNetSim und der Integration des Benchmarksystems SimBench [Wol10] zu beachten gilt. Darüber hinaus werden die wesentlichen Komponenten des implementierten Protokolls besprochen sowie deren Interaktion. Am Ende des Kapitels werden die angewandten Test- und Verikationsmethoden vorgestellt. 5.1 Implementierung in P2PNetSim P2PNetSim ist ein parallel arbeitender Netzwerksimulator, der im Unterschied zu vielen anderen Simulatoren mehr als eine Million Knoten im Netzwerk simulieren kann. P2PNetSim wurde komplett in Java entwickelt und ist somit plattformunabhängig einsetzbar. Der Simulator stellt ein einfaches Netzwerkmodell zur Verfügung, wobei zu Gunsten eines geringstmöglichen Overheads auf die Modellierung von IP-Routing oder der TCP-Funktionalität verzichtet wurde. [Roj07] Die Simulation der Peers erfolgt sequentiell in jedem Simulationsschritt. Die zentrale Komponente dazu ist die abstrakte Klasse Peer 1. Das Peer-Objekt kennt den aktuellen Simulationsschritt (Variable simtime), kann Nachrichten senden und empfangen und hat Zugri auf das Logger-Objekt der Klasse P2PNetSimLogger. Für die Initialisierung der Peers benötigt P2PNetSim eine XML-Kongurationsdatei. In dieser Datei kann man zu jedem Peer auch selbst denierte Parameter hinzufügen, welche im Programm mit getparam(string key) ausgelesen werden können. Selbst denierte Parameter erscheinen in der P2PNetSim-GUI unter Properties (siehe Abbildung 5.1). In der P2PNetSim-GUI werden oberhalb von Properties Key-Value-Paare der Grundkonguration (Basic conguration) aufgelistet, z.b. die Netzwerkadresse (Address) oder der Klassenname (Class ID). Alle Peers, die im Laufe einer Simulation online gehen sollen, müssen in der XML- Kongurationsdatei deniert werden. Durch den P2PNetSim-Befehl Connect werden vor Simulationsbeginn alle Peers aus der Kongurationsdatei initialisiert. P2PNetSim unterscheidet nicht zwischen einem online-peer und einem oine-peer. Dies muss zusammen mit den Join- und Leave-Mechanismen in der jeweiligen Protokoll-Implementierung umgesetzt werden. Es empehlt sich hier die Integration von SimBench [Wol10], da 1 Peer ist hervorgehoben, da es sich um die konkrete Klasse Peer handelt und nicht um einen Peer im Netzwerk. Beim Bezug auf Klassen, Pakete, Bibliotheken, Variablen, Konstanten, Methoden, Datentypen oder Modikatoren erscheinen diese in der Schrift Courier New. 60

61 5.1. P2PNETSIM KAPITEL 5. IMPLEMENTIERUNG Abbildung 5.1: P2PNetSim-GUI mit Anzeige der Grundkonguration (Basic conguration) und selbst denierter Parameter (Properties) von Peer10 SimBench hierfür fertige Methoden anbietet, z.b. für Join, Leave und für die Online- Statusabfrage (siehe Abschnitt 5.2). P2PNetSim sieht das Speichern von Logmeldungen in Logdateien sowie die Ausgabe von Logmeldungen in der GUI vor. Debugmeldungen zur Fehlersuche können in der GUI als Logmeldungen oder auf der Kommandozeile ausgegeben werden. Die Peers kommunizieren in P2PNetSim über Nachrichten, d.h. über Objekte der abstrakten Klasse Message. Per Default wird jede Nachricht in einem Simulationsschritt zugestellt. Falls Protokolle der Transport- oder IP-Schicht implementiert werden müssen, empehlt es sich, das zu versendende Segment oder Paket als Message-Objekt zu implementieren. Während eines Simulationsschrittes fallen beim P2P-Streaming viele Aktionen mit hoher Komplexität an, z.b. die Reparatur des Overlaynetzwerks, der Nachrichtenempfang, die Ausführung des Scheduling-Algorithmus und der Nachrichtenversand (z.b. von Buffermaps, Datenrequests). Zur übersichtlichen Implementierung in P2PNetSim und zur ezienten Fehlersuche habe ich daher folgende Kriterien festgelegt: Implementierung eines schlanken Peers mit möglichst wenig Kontrollstrukturen. Regelmäÿiger Test der einzelnen Funktionalitäten auÿerhalb von P2PNetSim. P2PNetSim implementiert IP, jedoch keine Portnummern und somit keine Dienste der Transportschicht. Im Rahmen der vorliegenden Implementierung wurden daher TCPund UDP-Funktionalitäten integriert (siehe Abschnitt 5.4.2). Auf der Anwendungsschicht ist die Implementierung eines echten Medienplayers im Simulator nicht erforderlich, da der Medienplayer kein Bestandteil des P2P-Streaming- Protokolls ist. Es wurde dennoch eine rudimentäre Playerkomponente integriert, um die 61

Videostreaming. Josko Hrvatin DMT. Prof. Dr. Robert Strzebkowski. TFH-Berlin WS 05/06

Videostreaming. Josko Hrvatin DMT. Prof. Dr. Robert Strzebkowski. TFH-Berlin WS 05/06 Josko Hrvatin DMT Prof. Dr. Robert Strzebkowski TFH-Berlin WS 05/06 Streaming Media Streaming Media ist der Oberbegriff von Streaming Audio und Streaming Video und bezeichnet die aus einem Computernetzwerk

Mehr

Digitales Video I Wie wird Video am Computer codiert?

Digitales Video I Wie wird Video am Computer codiert? Digitales Video I Wie wird Video am Computer codiert? Bilder Auflösung Speicherung am Computer Bewegte Bilder Interlacing Kompression / Codec Ton Audioformate / Codecs Videoformate Bilder Auflösung: z.b.:

Mehr

Multimediatechnik / Video

Multimediatechnik / Video Multimediatechnik / Video Video-Streaming http://www.nanocosmos.de/lietz/mtv Streaming: Anwendungen TV und Internet IP-TV: Video on Demand, Live Streaming Zugesicherte Qualität (QoS, Quality of Service)

Mehr

Video over IP / Videostreaming

Video over IP / Videostreaming Video over IP / Videostreaming - einige wenige Aspekte - Prof. Dr. Robert Strzebkowski Beuth Hochschule für Technik Berlin Unterscheidung: 'Echter Streaming' mit Streaming-Server HTTP-Download als 'Pseudostreaming'

Mehr

Streaming Protokolle Jonas Hartmann

Streaming Protokolle Jonas Hartmann Streaming Protokolle Jonas Hartmann 1 Streaming Protokolle Inhaltsverzeichnis 1. Definition / Anwendungsfälle 2. Offizielle RFC Streaming Protokolle 3. Ein wichtiges proprietäres Protokoll 4. Konkreter

Mehr

Streaming Media - MPEG-4 mit Linux

Streaming Media - MPEG-4 mit Linux Streaming Media - MPEG-4 mit Linux Überblick Streaming Media Streaming Anbieter Benötigte Software Vorführung Videostreaming Streaming Was ist Streaming? Sender Daten Empfänger Kontinuierlicher Datenstrom

Mehr

Streaming Techniken zur Übertragung multimedialer Daten im Web Universität Paderborn

Streaming Techniken zur Übertragung multimedialer Daten im Web Universität Paderborn Streaming Techniken zur Übertragung multimedialer Daten im Web Universität Paderborn Vortrag im Seminar 3D-Grafik im Web Raphael Gräbener Übersicht Was ist Streaming Anwendungsbeispiele Broadcasting Audio-/

Mehr

Von der Kamera zur DVD Klaus Wünschel LUG-LD

Von der Kamera zur DVD Klaus Wünschel LUG-LD Von der Kamera zur DVD Klaus Wünschel LUG-LD Inhalt Allgemeine Grundlagen Codecs / Container Vom Camcorder zum PC / Module - Devices Linuxsoftware zur Videomanipulation Vom PC zur DVD DVD-Authoring praktische

Mehr

aft irtsch Der Vorfilm... er W er d artn etp tern In

aft irtsch Der Vorfilm... er W er d artn etp tern In Vitamine für Ihr Business Unser Thema heute: Der Vorfilm... Was wir für unsere Kunden tun... tun wir seit 1996. Wir betreiben Ihre Services. DC Berlin 1 DC Berlin 2 auf eigener Technik. Es sollte schon

Mehr

F A C H H O C H S C H U L E W E D E L S T U D I E N A R B E I T

F A C H H O C H S C H U L E W E D E L S T U D I E N A R B E I T F A C H H O C H S C H U L E W E D E L S T U D I E N A R B E I T in der Fachrichtung Medieninformatik Thema: Streaming-Lösungen in Unternehmen zur Produktpräsentation und zur internen Mitarbeiterschulung...

Mehr

Videokonferenzen & multimediale Kommunikation

Videokonferenzen & multimediale Kommunikation Videokonferenzen & multimediale Kommunikation Falko Dreßler, Regionales Rechenzentrum falko.dressler@rrze.uni-erlangen.de 1 Überblick Einteilung Videokommunikation Meeting vs. Broadcast Transportnetze

Mehr

Videostreaming-Erfahrungen an der Leibniz Universität Hannover. Dipl.-Ing. Uwe Oltmann

Videostreaming-Erfahrungen an der Leibniz Universität Hannover. Dipl.-Ing. Uwe Oltmann Videostreaming-Erfahrungen an der Leibniz Universität Hannover Dipl.-Ing. Uwe Oltmann Leibniz Universität Hannover in Zahlen Gründungsjahr 1831 23000 Studierende ca. 4400 Beschäftigte ca. 90 Studienfächer

Mehr

Internet Protokolle für Multimedia - Anwendungen

Internet Protokolle für Multimedia - Anwendungen Internet Protokolle für Multimedia - Anwendungen Kapitel 5.7 Streaming im Web (RTSP) 1 Streaming Media (1) Streaming Media Strom ist kontinuierlich wird unmittelbar während des Empfangs wiedergegeben wird

Mehr

EDV-Anwendungen im Archivwesen II

EDV-Anwendungen im Archivwesen II EDV-Anwendungen im Archivwesen II 070472 UE WS08/09 Digitale Formate (Beispiele) Überblick Kurzer Überblick über derzeit übliche Formate Bild Ton Video Archivierungsformate Ist Komprimierung immer zu vermeiden?

Mehr

Anleitung zu STREAMDAY Hosting Pakete (Stand Februar 2005) INHALTSVERZEICHNIS

Anleitung zu STREAMDAY Hosting Pakete (Stand Februar 2005) INHALTSVERZEICHNIS Anleitung zu STREAMDAY Hosting Pakete (Stand Februar 2005) INHALTSVERZEICHNIS 1. EINPFLEGEN VON MEDIA-DATEIEN IN DAS STREAMDAY HOSTING-ACCOUNT 2 A. STANDARD (FTP) 2 B. INTERNET EXPLORER AB 5.0 FÜR WINDOWS

Mehr

Das richtige Signal (1): IPTV für jeden Anspruch

Das richtige Signal (1): IPTV für jeden Anspruch Das richtige Signal (1): IPTV für jeden Anspruch Herzlich Willkommen. Fernand Suter, Projektleiter NGN www.wisi.ch 1 Inhalt Was versteht man unter IPTV? Arten von Streaming IP-TV Lösungen Hilfsmittel Chancen

Mehr

Erfahrungen mit QuickTime Streaming. Bernhard Barz Uwe Pirr Humboldt-Universität zu Berlin Rechenzentrum

Erfahrungen mit QuickTime Streaming. Bernhard Barz Uwe Pirr Humboldt-Universität zu Berlin Rechenzentrum Erfahrungen mit QuickTime Streaming Bernhard Barz Uwe Pirr Humboldt-Universität zu Berlin Rechenzentrum Die großen Drei: Real Networks: RealAudio, RealVideo 12,1 % Apple Computer: QuickTime 7,4 % Microsoft:

Mehr

Alles über Videoformate

Alles über Videoformate MKV AVI MPEG H.6 WMV OGG Alles über Eine Videodatei ist mehr als nur die digitale Kopie eines Films: Neue Formate wie Matroska führen Video, Audio, Untertitel, Kapitel, Menüs und Cover in einer einzigen

Mehr

Videostreaming-Erfahrungen an der Leibniz Universität Hannover. Dipl.-Ing. Uwe Oltmann

Videostreaming-Erfahrungen an der Leibniz Universität Hannover. Dipl.-Ing. Uwe Oltmann Videostreaming-Erfahrungen an der Leibniz Universität Hannover Dipl.-Ing. Uwe Oltmann Leibniz Universität Hannover in Zahlen Gründungsjahr 1831 23000 Studierende ca. 4400 Beschäftigte ca. 90 Studienfächer

Mehr

... relevante Ports für Streaming bzw. Remote Control!

... relevante Ports für Streaming bzw. Remote Control! ... relevante Ports für Streaming bzw. Remote Control! Wenn Sie mit der Installation des IO [io] 8000 / 8001 beginnen, ist es am sinnvollsten mit einem minilan zu beginnen, da dies mögliche Fehlrequellen

Mehr

30. Okt. 2014. Codec, Wrapper und ihre Rolle in der. Langzeitarchivierung: Eine Übersicht. Peter Bubestinger

30. Okt. 2014. Codec, Wrapper und ihre Rolle in der. Langzeitarchivierung: Eine Übersicht. Peter Bubestinger 1 / 36 30. Okt. 2014 2 / 36 Choose your destiny Die Dreifaltigkeit von digitalem Video 3 / 36 Choose your destiny Die Dreifaltigkeit von digitalem Video Dateiendung = Aussagen wie Die Videos sind im Flash/AVI/Quicktime

Mehr

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten Prof. Dr. P. Tran-Gia Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten 4. Würzburger Workshop IP Netzmanagement, IP Netzplanung und Optimierung Robert Henjes, Dr. Kurt Tutschku

Mehr

How to: Unterstützung von Audio und Video

How to: Unterstützung von Audio und Video How to: Unterstützung von Audio und Video Dieses Dokument dient der Erläuterung von Optionen zur Unterstützung von Audio-und Videodateien in EXMARaLDA und gibt Empfehlungen für Medienformate. Inhalte A.

Mehr

1 2 3 4 5 Ergebnis der. Einspielen in. Bearbeitung im Belichtung Aufnahme. Wandlung des Datenstroms in Dateien durch Codec, 2. Kompression der Daten

1 2 3 4 5 Ergebnis der. Einspielen in. Bearbeitung im Belichtung Aufnahme. Wandlung des Datenstroms in Dateien durch Codec, 2. Kompression der Daten Tom Krug 31.03.15 1 2 3 4 5 Ergebnis der Einspielen in Bearbeitung im Belichtung Aufnahme PC, Casablanca Schnittprogramm Export nach Bearbeitung Mini-DV SD (720 x 576 50i) HDV2 (1440 x1080 50i) Speicherkarte,

Mehr

Ein Besuch auf der Seite lohnt sich. Man findet dort auch zu andern Themen viel Wissenswertes.

Ein Besuch auf der Seite lohnt sich. Man findet dort auch zu andern Themen viel Wissenswertes. www.computeria-olten.ch Monatstreff für Menschen ab 50 Merkblatt 71 Video- und Audioformate Quelle Videoformate: http://lehrerfortbildung-bw.de/werkstatt/video/formate/ Ein Besuch auf der Seite lohnt sich.

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern

Mehr

Videokodierung MPEG. Dirk Theisen

Videokodierung MPEG. Dirk Theisen MPEG Dirk Theisen Proseminar Multimediadatenbanken und Retrieval Institute for Web Science and Technologies FB4 Computer Science Universität Koblenz-Landau, 56070 Koblenz, Germany dirktheisen@uni-koblenz.de

Mehr

Videodateien aufbereiten

Videodateien aufbereiten Autorin: Anita Holdener M: anita.holdener@hslu.ch T: 041-228 40 18 Videodateien aufbereiten 3.0 - März 13 Videodateien aufbereiten Video Aufbereitung 2.1 - März 13 Seite 2 Inhaltsverzeichnis 1 Einleitung...

Mehr

Musik, Hörbücher oder Videos aus dem Internet

Musik, Hörbücher oder Videos aus dem Internet Musik, Hörbücher oder Videos aus dem Internet Peter Simon Es gibt sehr viele Quellen für Audio oder Video Dateien im Internet. Welche sind legal? Wie lädt man sie herunter? Was ist eine Mediathek? Wie

Mehr

Internet Routing am 14. 11. 2006 mit Lösungen

Internet Routing am 14. 11. 2006 mit Lösungen Wissenstandsprüfung zur Vorlesung Internet Routing am 14. 11. 2006 mit Lösungen Beachten Sie bitte folgende Hinweise! Dieser Test ist freiwillig und geht in keiner Weise in die Prüfungsnote ein!!! Dieser

Mehr

Video on Demand. Zurfluh Pirmin Nguyen Thanh Abgottspon Andy. Dozenten Fredy Schwyter Reto Käser

Video on Demand. Zurfluh Pirmin Nguyen Thanh Abgottspon Andy. Dozenten Fredy Schwyter Reto Käser Video on Demand Zurfluh Pirmin Nguyen Thanh Abgottspon Andy Dozenten Fredy Schwyter Reto Käser Horw, 30. September 2008 Änderungsgeschichte Rev Datum Autor, Bemerkung 1.0 24.11.08 Zurfluh Pirmin, Nguyen

Mehr

Pre-Roll. Vorgeschalteter Spot mit maximal 30 Sekunden Länge

Pre-Roll. Vorgeschalteter Spot mit maximal 30 Sekunden Länge Pre-Roll Vorgeschalteter Spot mit maximal 30 Sekunden Länge Beim PreRoll Ad wird Ihre Werbebotschaft vor den redaktionellen Video-Content geschaltet oder als Sponsoring-Opener geschaltet. Sobald der User

Mehr

Videos die Videokamera

Videos die Videokamera Videos die Videokamera Steffen Schwientek Kurzvortrag zum Videokurs Themen heute Kurze Einführung in die Videotechnik Drehen eines kurzen Dokumentarfilmes Fernsehtechnik Kameratechnik (Kleine) Kaufberatung

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

QuickTime für das Internet. Uwe Pirr Humboldt-Universität zu Berlin Rechenzentrum

QuickTime für das Internet. Uwe Pirr Humboldt-Universität zu Berlin Rechenzentrum QuickTime für das Internet Uwe Pirr Humboldt-Universität zu Berlin Rechenzentrum QuickTime für das Internet Grundlagen der Einbindung Verbesserte Einbindung Poster Movies Alternate Movies Streaming Movies

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

«Technik & Knowhow» Videoübertragungen im Web. Frank Schefter Projektmanager solutionpark streaming gmbh Zürich

«Technik & Knowhow» Videoübertragungen im Web. Frank Schefter Projektmanager solutionpark streaming gmbh Zürich «Technik & Knowhow» Videoübertragungen im Web Frank Schefter Projektmanager solutionpark streaming gmbh Zürich 1 Vorstellung 2 Solutionpark - Kurzprofil Zusammenschluss von IT Firmen seit 1999 17 Mitarbeiter

Mehr

UnterrichtsMitschau 2.0 - Vorlesungsaufzeichnungen im sozialen Kontext. Folie 1

UnterrichtsMitschau 2.0 - Vorlesungsaufzeichnungen im sozialen Kontext. Folie 1 UnterrichtsMitschau 2.0 - Vorlesungsaufzeichnungen im sozialen Kontext Folie 1 I. UnterrichtsMitschau der LMU II. Gemäßigt konstruktivistische Lerntheorie III. UnterrichtsMitschau 2.0 IV. Technische Realisierung

Mehr

Content Management Systeme

Content Management Systeme Content Management Systeme Ein Vergleich unter besonderer Berücksichtigung von CoreMedia und TYPO3 Bachelorthesis im Kooperativen Bachelor Studiengang Informatik (KoSI) der Fachhochschule Darmstadt University

Mehr

Übersicht Darstellung

Übersicht Darstellung Übersicht Darstellung Classic Darstellung direkt durch 3rd-party Anzeigekomponenten und Windows-Systembestandteile (DirectShow) easescreen verwaltet den Bildschirmplatz, Z-Order, Anzeige-Zeiten Deshalb

Mehr

TCP/UDP. Transport Layer

TCP/UDP. Transport Layer TCP/UDP Transport Layer Lernziele 1. Wozu dient die Transportschicht? 2. Was passiert in der Transportschicht? 3. Was sind die wichtigsten Protkolle der Transportschicht? 4. Wofür wird TCP eingesetzt?

Mehr

Microsoft PowerPoint 2013 YouTube-Video einfügen

Microsoft PowerPoint 2013 YouTube-Video einfügen Hochschulrechenzentrum Justus-Liebig-Universität Gießen Microsoft PowerPoint 2013 YouTube-Video einfügen YouTube-Video einfügen in PowerPoint 2013 Seite 1 von 6 Inhaltsverzeichnis Einleitung... 2 Vorbereitungen...

Mehr

Web TV Solutions Online Video Portal der MEDIA BROADCAST

Web TV Solutions Online Video Portal der MEDIA BROADCAST Web TV Solutions Online Video Portal der MEDIA BROADCAST 2013 Media Broadcast - Unternehmensinformationen Europas größter Full-Service-Provider der Rundfunk- und Medienbranche MEDIA BROADCAST betreut rund

Mehr

Bitte benennen Sie Ihre Dateien folgendermaßen:

Bitte benennen Sie Ihre Dateien folgendermaßen: Videodateien, die an IMD geliefert werden, müssen folgendem technischen Layout entsprechen (am Beispiel eines 30 Spots): Timecode 09:59:50:00 7 technischer Vorspann* 09:59:57:00 3 Schwarzbild + Stille

Mehr

1. Der erste Video-Rip in 15 Minuten

1. Der erste Video-Rip in 15 Minuten 1. Der erste Video-Rip in 15 Minuten DER ERSTE VIDEO-RIP IN 15 MINUTEN 1.1 Das brauchen Sie zum Rippen... 11 DVDx herunterladen und installieren... 13 DVDx auf Deutsch umstellen... 15 DivX herunterladen

Mehr

Fenster: Klicken Sie mit links im linken Menü auf Downloads und es öffnet sich folgendes Fenster:

Fenster: Klicken Sie mit links im linken Menü auf Downloads und es öffnet sich folgendes Fenster: Videos mit VDownloader downloaden: Manchmal möchte man aus dem Internet sich Videos herunterladen, und zwar von beliebigen Downloadportalen. Gemeint sind hier nicht illegale Downloads, als vielmehr irgendwelche

Mehr

TV-Sendungen über einen Online-Videorecorder aufnehmen mit OTR

TV-Sendungen über einen Online-Videorecorder aufnehmen mit OTR ICT-Beratung Online-Videorecorder (OTR) 1 TV-Sendungen über einen Online-Videorecorder aufnehmen mit OTR Problem / Einsatzbereich Man entdeckt eine interessante TV-Sendung oder einen guten Film im TV-Programm.

Mehr

BITMOVIN. LIVE 24/7 OTT Broadcast TRANSCODING & STREAMING AS-A-SERVICE

BITMOVIN. LIVE 24/7 OTT Broadcast TRANSCODING & STREAMING AS-A-SERVICE LIVE 24/7 OTT Broadcast TRANSCODING & STREAMING AS-A-SERVICE bitmovin GmbH Medienanbieter egal ob TV-Sender, News Portale, Printmedien oder Telekommunikationsunternehmen - erweitern derzeit Ihre Angebote

Mehr

Hauptseminararbeit Sommersemester 2004. Thema:

Hauptseminararbeit Sommersemester 2004. Thema: Hauptseminararbeit Sommersemester 2004 Thema: Live-Streaming-Lösungen Recherche und Analyse existierender Live-Streaming-Lösungen (Infrastruktur, organisatorischer Aufbau) aus technischer Sicht Bearbeiter:

Mehr

Collaborative Virtual Environments

Collaborative Virtual Environments Collaborative Virtual Environments Stefan Lücking Projektgruppe Kreativität und Technik AG Domik WS 02/03 09.01.2003 1/35 Was sind CVE? Versuch einer Definition : Ein CVE ist ein Programm, das eine virtuelle

Mehr

Audio und Video einbinden

Audio und Video einbinden Kapitel 15 Audio und Video einbinden In diesem Kapitel: Was bringt HTML5 bei Audio und Video Neues? 295 Multimedia-Grundlagen von HTML 296 Videoclips einbetten 300 Audiodateien auf einer Webseite integrieren

Mehr

Group and Session Management for Collaborative Applications

Group and Session Management for Collaborative Applications Diss. ETH No. 12075 Group and Session Management for Collaborative Applications A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZÜRICH for the degree of Doctor of Technical Seiences

Mehr

BUSINESS TV. Die Komplettlösung für Unternehmensvideos

BUSINESS TV. Die Komplettlösung für Unternehmensvideos Die Komplettlösung für Unternehmensvideos Möchten Sie die Vorteile der Videotechnologie im Internet für Ihr Unternehmen nutzen? Möchten Sie Ihre Produkte und Dienstleistungen überzeugender präsentieren?

Mehr

InfiniBand Low Level Protocol

InfiniBand Low Level Protocol InfiniBand Low Level Protocol Seminar Ausgewählte Themen in Hardwareentwurf und Optik HWS 08 17.12.2008 Andreas Walter Universität Mannheim Inhalt Motivation InfiniBand Basics Physical Layer IB Verbs IB

Mehr

Multimediatechnik / Video

Multimediatechnik / Video Multimediatechnik / Video Video-Verarbeitung Verarbeitung / Codecs / Formate Decodierung, Encodierung http://www.nanocosmos.de/lietz/mtv 1 Inhalt Video-Verarbeitung: Verarbeitung: Wiedergabe, Aufnahme

Mehr

3 Das verbindungslose Vermittlungsprotokoll IP

3 Das verbindungslose Vermittlungsprotokoll IP Das verbindungslose Vermittlungsprotokoll IP 27 3 Das verbindungslose Vermittlungsprotokoll IP In diesem Kapitel lernen Sie das verbindungslose Vermittlungsprotokoll IP näher kennen. Nach dem Durcharbeiten

Mehr

Multimediatechnik / Video

Multimediatechnik / Video Multimediatechnik / Video Video-Verarbeitung Verarbeitung / Codecs / Formate http://www.nanocosmos.de/lietz/mtv Videoverarbeitung / Wiedergabe Einlesen von Videodaten von einer Quelle Disk/Internet/WLAN,

Mehr

Kontextbezogene Verbindungstypanalyse für webbasierte Videokonferenzen in HTML5. 11.05.2015 Dennis Pieper Hochschule Osnabrück 1

Kontextbezogene Verbindungstypanalyse für webbasierte Videokonferenzen in HTML5. 11.05.2015 Dennis Pieper Hochschule Osnabrück 1 Kontextbezogene Verbindungstypanalyse für webbasierte Videokonferenzen in HTML5 11.05.2015 Dennis Pieper Hochschule Osnabrück 1 Inhalt OVICO-System Echtzeit-Konferenzen Dienstgüte (QoS) Anforderungen Anpassung

Mehr

IT- und Medientechnik

IT- und Medientechnik IT- und Medientechnik Vorlesung 5: 7.11.2014 Wintersemester 2014/2015 h_da, Lehrbeauftragter Themenübersicht der Vorlesung Hard- und Software Hardware: CPU, Speicher, Bus, I/O,... Software: System-, Unterstützungs-,

Mehr

Die Specs beinhalten alle relevanten Informationen rund um die verfügbaren Xaxis Werbeformate.

Die Specs beinhalten alle relevanten Informationen rund um die verfügbaren Xaxis Werbeformate. Stand: 22.07.2014 Xaxis Specs Die Specs beinhalten alle relevanten Informationen rund um die verfügbaren Xaxis Werbeformate. Bitte beachten: Anlieferungszeit an das GroupM Admanagement beachten: Nur wenn

Mehr

Einbindung von Videos im ZMS

Einbindung von Videos im ZMS Einbindung von Videos im ZMS Videos können auf Ihrer ZMS-Website auf vier verschiedene Arten eingebunden werden: - Video-Link (z.b. You Tube) - Real Media Stream - Video-Datei - Flash-Datei Um ein Video

Mehr

Inhalt. 1 Einleitung 1. Theoretische Grundlagen. 2 Übersicht IP-Multicast 7

Inhalt. 1 Einleitung 1. Theoretische Grundlagen. 2 Übersicht IP-Multicast 7 ix Inhalt 1 Einleitung 1 Teil I Theoretische Grundlagen 2 Übersicht IP-Multicast 7 3 IP-Multicast-Grundlagen 11 3.1 IP-Multicast-Adressen.............................. 12 3.2 IP-Multicast- und Hardware-Adressen..................

Mehr

Montage- und Bedienungsanleitung Desktop Streaming

Montage- und Bedienungsanleitung Desktop Streaming Montage- und Bedienungsanleitung Desktop Streaming D Desk Inhaltsverzeichnis 1 Allgemeines... 3 1.1 Beschreibung..... 3 1.2 Systemvoraussetzungen des PCs oder Laptops... 3 2 Software auf dem PC oder Laptop

Mehr

Multimediaschnittstelle. Microsoft DirectShow

Multimediaschnittstelle. Microsoft DirectShow Multimediaschnittstelle Microsoft DirectShow Gliederung 1. Grundlagen 1.1 VFW 1.2 WDM, KS, WMF 1.3 DirectShow - DirectX 1.4 Aufgaben von DirectShow 2. Architektur 2.1 COM - kurze Einführung 2.2 Filter

Mehr

Erklärung und Unterschiede der Video-Formate

Erklärung und Unterschiede der Video-Formate Erklärung und Unterschiede der Video-Formate Also dann mal los: Alles was mit Avi enden soll wird mit VirtualDub bearbeitet Alles was als mpg enden soll in TMPGEnc Formate: DivX (derzeit 5.03, komp. mit

Mehr

VSH-Playout. VSH-tapelessProduction. Immer einen Schritt voraus! VSH-Acquisition. VSH-Produktionsserver. VSH-Playout

VSH-Playout. VSH-tapelessProduction. Immer einen Schritt voraus! VSH-Acquisition. VSH-Produktionsserver. VSH-Playout VSH-Playout Immer einen Schritt voraus! VSH-tapelessProduction VSH-Acquisition VSH-Produktionsserver VSH-Playout VSH-Playout Immer einen Schritt voraus System N System 1 LAN VSH CG Videotitler Erstellt

Mehr

Universität Freiburg. Thema: IP-Multicast Marcel Tschöpe. IP-Multicast

Universität Freiburg. Thema: IP-Multicast Marcel Tschöpe. IP-Multicast IP-Multicast Netzwerkgrundlagen Unicast Daten werden von einem PC an einen anderen geschickt (Punkt-zu-Punkt-Verbindung) Broadcast Daten werden von einem Computer, an alle anderen des selben Netzwerkes

Mehr

MEDIA GROUP ONE TECHNISCHE SPEZIFIKATIONEN 2015 FÜR IN-STREAM VIDEO ADS

MEDIA GROUP ONE TECHNISCHE SPEZIFIKATIONEN 2015 FÜR IN-STREAM VIDEO ADS MEDIA GROUP ONE TECHNISCHE SPEZIFIKATIONEN 2015 FÜR IN-STREAM VIDEO ADS Stand April 10, 2015, MEDIA GROUP ONE Digital GmbH 1 ALLGEMEINE INFORMATIONEN INHALT EINLEITUNG 3 FACT SHEET 4 ANLIEFERUNG 5 SOUND

Mehr

Zusammenfassung Graphik - Formate. Vektorgraphik - PS, EPS, WMF geometrische Figuren, exakte Berechnung auf beliebige Größe

Zusammenfassung Graphik - Formate. Vektorgraphik - PS, EPS, WMF geometrische Figuren, exakte Berechnung auf beliebige Größe Zusammenfassung Graphik - Formate Vektorgraphik - PS, EPS, WMF geometrische Figuren, exakte Berechnung auf beliebige Größe Rastergraphik - BMP, GIF, JPEG, PNG feste Anzahl von Bildpunkten (ppi) Wiedergabe

Mehr

Digitale Videoformate

Digitale Videoformate Was ist Video? Begriffsklärung: Videotechnik: allgemeine Verfahren und Ausstattung zur elektronischen Aufzeichnung, Speicherung und Wiedergabe von Bewegtbildinformationen und Toninformationen Video: jegliche

Mehr

Web Datei Formate GIF JPEG PNG SVG. Einleitung. GIF Graphic Interchange Format. JPEG Joint Photographic Expert Group. PNG Portable Network Graphic

Web Datei Formate GIF JPEG PNG SVG. Einleitung. GIF Graphic Interchange Format. JPEG Joint Photographic Expert Group. PNG Portable Network Graphic Einleitung Graphic Interchange Format Joint Photographic Expert Group Portable Network Graphic scalabel Vector Graphic Fazit Übungsaufgabe Speichern Einleitung Das Web ist eines der wichtigsten Medien

Mehr

Hochgeschwindigkeits-Ethernet-WAN: Bremst Verschlüsselung Ihr Netzwerk aus?

Hochgeschwindigkeits-Ethernet-WAN: Bremst Verschlüsselung Ihr Netzwerk aus? Hochgeschwindigkeits-Ethernet-WAN: Bremst Verschlüsselung Ihr Netzwerk aus? 2010 SafeNet, Inc. Alle Rechte vorbehalten. SafeNet und das SafeNet-Logo sind eingetragene Warenzeichen von SafeNet. Alle anderen

Mehr

Audiokommunikation im Computer. Andreas Jäger

Audiokommunikation im Computer. Andreas Jäger Audiokommunikation im Computer Wie kommunizieren die Teile einer DAW miteinander? Host Hardware Host Was gibt es in der Praxis zu beachten? Wo liegen Gefahren? Konkreter: Warum ist ASIO besser als MME?

Mehr

2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-D-VoD.fm, 2006-11-22 08.08] http://www-vs.informatik.uni-ulm.

2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-D-VoD.fm, 2006-11-22 08.08] http://www-vs.informatik.uni-ulm. D Video on Demand D.1 1 RTSP Real-Time Streaming Protocol (RTSP) IETF Standard definiert in RFC 2326 (1998) Zielsetzung Signalisierung und Kontrolle von multimedialen Datenströmen Aufbau, Abbruch von Sitzungen

Mehr

Preliminary spec sheet

Preliminary spec sheet ARNOVA steht für gute Performance zum attraktiven Preis. ARNOVA designed by ARCHOS. Das ARNOVA 7 Tablet ermöglicht ständigen Zugriff auf das Internet, läßt sich durch Android Apps individuell anpassen

Mehr

(Aufbau einer Video DVD)

(Aufbau einer Video DVD) DVD-Authoring (Aufbau einer Video DVD) Was ist DVD-Authoring? Wie ist eine Video DVD aufgebaut? Welche Möglichkeiten gibt es um, bei einer Video-DVD ein Menü zu gestalten? Welche Programme unterstützen

Mehr

Sharedien. Medien schnell finden und einfach teilen. sharedien.com. Einfach gut finden

Sharedien. Medien schnell finden und einfach teilen. sharedien.com. Einfach gut finden Sharedien. Medien schnell finden und einfach teilen. sharedien.com Einfach gut finden Sharedien. Finden. Nicht suchen. Überall. - Alle, die täglich viele Bilder, Dokumente, Audio- und Videodateien streamen,

Mehr

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung Use-Cases Bruno Blumenthal und Roger Meyer 17. Juli 2003 Zusammenfassung Dieses Dokument beschreibt Netzwerk-Szenarios für den Einsatz von NetWACS. Es soll als Grundlage bei der Definition des NetWACS

Mehr

Erfahrungsbericht Live Streaming Peter Bagschik, VfL Oker (www.vfloker.de)

Erfahrungsbericht Live Streaming Peter Bagschik, VfL Oker (www.vfloker.de) Erfahrungsbericht Live Streaming Peter Bagschik, VfL Oker (www.vfloker.de) Für eine Sportveranstaltung im Kunstturnen sollte für interessierte Zuschauer ein Live Video im Internet übertragen werden. Da

Mehr

Web-Performance-Optimierung - Websites auf Speed SEO Barbecue - DIWISH - Kiel - 01. August 2012. Timo Heinrich t.heinrich@online-werbung.

Web-Performance-Optimierung - Websites auf Speed SEO Barbecue - DIWISH - Kiel - 01. August 2012. Timo Heinrich t.heinrich@online-werbung. SEO Barbecue Web-Performance-Optimierung - DIWISH - Kiel - 01. August 2012 - Websites auf Speed 1 2 Kinder 1 Frau 41 Jahre jung Seit 1996 autodidaktischer Onliner Schwerpunkte: Suchmaschinenoptimierung

Mehr

Seminar: Innovative Netztechnologien

Seminar: Innovative Netztechnologien Seminar: Innovative Netztechnologien Content Distribution Networks Andreas Siemer 06/2002 1 Inhalt 1. Content Networking 2. 3. Akamai 2 Begriffe: Content Networking Inhalt (Content) im Internet verfügbare

Mehr

Videos importieren und bearbeiten

Videos importieren und bearbeiten Videos importieren und bearbeiten Macromedia Flash MX 2004 und Macromedia Flash MX Professional 2004 enthalten einen Videoimportassistenten mit Bearbeitungsfunktionen. Der Assistent ermöglicht die Steuerung

Mehr

3827260108 Private Homepage vermarkten So laden Sie Ihre Website auf den Server Das lernen Sie in diesem Kapitel: n So funktioniert FTP n Diese FTP-Programme gibt es n So laden Sie Ihre Website mit WS-FTP

Mehr

DivX Recording Tutorial / M.Dreese / TerraTec Electronic GmbH Seite 2

DivX Recording Tutorial / M.Dreese / TerraTec Electronic GmbH Seite 2 Kurzeinstieg in die Aufnahme in DivX (c) 2003 Terratec Electronic GmbH, M.Dreese Vorwort In dieser Kurzanleitung wollen wir Ihnen die Zusammenarbeit der Terratec-TV Software mit dem bekannten DivX-Codec

Mehr

Einführung in TCP/IP. das Internetprotokoll

Einführung in TCP/IP. das Internetprotokoll Schwarz Einführung in TCP/IP das Internetprotokoll Was ist ein Protokoll? Mensch A Mensch B Englisch Deutsch Spanisch Französisch Englisch Japanisch Was sind die Aufgaben eines Protokolls? Informationen

Mehr

Over-The-Top TV Sind Fernsehen und Internet inkompatibel?

Over-The-Top TV Sind Fernsehen und Internet inkompatibel? Lehrstuhl Nachrichtentechnik Universität des Saarlandes Over-The-Top TV Sind Fernsehen und Internet inkompatibel? Thorsten Herfet Lehrstuhl Nachrichtentechnik Universität des Saarlandes herfet@cs.uni-saarland.de

Mehr

BitTorrent. Ein Peer-to-Peer Datenübertragungsprotokoll. Mattias Schäffersmann 2005-11-15. Universität Bielefeld - Technische Fakultät

BitTorrent. Ein Peer-to-Peer Datenübertragungsprotokoll. Mattias Schäffersmann 2005-11-15. Universität Bielefeld - Technische Fakultät im Detail Ein Peer-to-Peer Datenübertragungsprotokoll Universität Bielefeld - Technische Fakultät 2005-11-15 im Detail Übersicht das Problem der Datenverteilung drei P2P-Systeme kurz Vorgestellt im Detail

Mehr

Router 1 Router 2 Router 3

Router 1 Router 2 Router 3 Network Layer Netz 1 Netz 2 Netz 3 Router 1 Router 2 Router 3 Router 1 Router 2 Router 3 Netz 1, Router 1, 1 Netz 1, Router 1, 2 Netz 1, Router 2, 3 Netz 2, Router 2, 2 Netz 2, Router 2, 1 Netz 2, Router

Mehr

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08 Security Patterns Benny Clauss Sicherheit in der Softwareentwicklung WS 07/08 Gliederung Pattern Was ist das? Warum Security Pattern? Security Pattern Aufbau Security Pattern Alternative Beispiel Patternsysteme

Mehr

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer Kommunikation I 1 Klausur Kommunikation I Sommersemester 2003 Dipl.-Ing. T. Kloepfer Bearbeitungsinformationen Aufbau der Klausur Die Klausur ist wie folgt aufgebaut: Die Klausur ist in 18 Aufgaben unterteilt.

Mehr

Übersicht. Was ist FTP? Übertragungsmodi. Sicherheit. Öffentliche FTP-Server. FTP-Software

Übersicht. Was ist FTP? Übertragungsmodi. Sicherheit. Öffentliche FTP-Server. FTP-Software FTP Übersicht Was ist FTP? Übertragungsmodi Sicherheit Öffentliche FTP-Server FTP-Software Was ist FTP? Protokoll zur Dateiübertragung Auf Schicht 7 Verwendet TCP, meist Port 21, 20 1972 spezifiziert Übertragungsmodi

Mehr

1. Technische Einstellungen für die Videoaufnahme

1. Technische Einstellungen für die Videoaufnahme 1 Videoaufnahme mit Camtasia (v1.1) In diesem Guide vermitteln wir dir erprobte Camtasia Einstellungen fuer Bild- und Tonaufnahme und erklären dir die Grundlagen der Aufnahme mit Camtasia. Unter http://www.techsmith.com/camtasia.asp

Mehr

WW AV Communication. F. Sokat Eleonorenstraße 11 65474 Bischofsheim

WW AV Communication. F. Sokat Eleonorenstraße 11 65474 Bischofsheim F. Sokat Eleonorenstraße 11 65474 Bischofsheim Inhale: Ganzheitliche Betrachtung von Systemen zur weltweiten Kommunikation für z.b.konferenzen oder Distance-Learning. Darstellung der Wirkzusammenhänge

Mehr

Broadcast Your Ad! Werbung auf den Videoportalen YouTube, Clipfish, MyVideo

Broadcast Your Ad! Werbung auf den Videoportalen YouTube, Clipfish, MyVideo Melanie Specht Elke Theobald Broadcast Your Ad! Werbung auf den Videoportalen YouTube, Clipfish, MyVideo Layout und Umschlaggestaltung: Achim Gehrig, Heilbronn. E-Mail: ag@e-p-s.de Die Deutsche Nationalbibliothek

Mehr

Streaming-Lösungen im Test am VCC

Streaming-Lösungen im Test am VCC Kompetenzzentrum für Videokonferenzdienste (VCC) Streaming-Lösungen im Test am VCC Cisco TelePresence Content Server, LifeSize UVC Video Center Zellescher Weg 12 Willers-Bau A217 Tel. +49 351-463 - 35653

Mehr

Robert Fehrmann Proseminar Technische Informatik Institut für Informatik, Betreuer: Matthias Wählisch. You are Skyping - But How Does it Work!?

Robert Fehrmann Proseminar Technische Informatik Institut für Informatik, Betreuer: Matthias Wählisch. You are Skyping - But How Does it Work!? Robert Fehrmann Proseminar Technische Informatik Institut für Informatik, Betreuer: Matthias Wählisch You are Skyping - But How Does it Work!? 1 Gliederung You are Skyping - But How Does it Work!? Probleme

Mehr

Das ARCHOS 70b Internet Tablet passt dank schlankem Formfaktor und leichtem Gewicht in

Das ARCHOS 70b Internet Tablet passt dank schlankem Formfaktor und leichtem Gewicht in Honeycomb TM auf einem 7 Zoll Tablet! Das ARCHOS 70b Internet Tablet passt dank schlankem Formfaktor und leichtem Gewicht in jede Tasche. So haben Sie stets Zugriff auf Apps, das Internet, Ihre Fotos,

Mehr

Chapter 7 Distanzvektorprotokolle. CCNA 2 version 3.0 Wolfgang Riggert, FH Flensburg auf der Grundlage von

Chapter 7 Distanzvektorprotokolle. CCNA 2 version 3.0 Wolfgang Riggert, FH Flensburg auf der Grundlage von Chapter 7 Distanzvektorprotokolle CCNA 2 version 3.0 Wolfgang Riggert, FH Flensburg auf der Grundlage von Rick Graziani Cabrillo College Vorbemerkung Die englische Originalversion finden Sie unter : http://www.cabrillo.cc.ca.us/~rgraziani/

Mehr

Videoserver und Encoder

Videoserver und Encoder Systems GmbH Produktübersicht und Encoder Zunkunftsweisend. Nutzvoll. Simply Easier. Plus / Hybrid Serie Modell CONVISION V400 Serie CONVISION V400 19" Serie CONVISION V600 Serie 4 +4-Kanal zur Videofernübertragung

Mehr

Kurzanleitung - XVA Provider unter Mac OSX 10

Kurzanleitung - XVA Provider unter Mac OSX 10 Kurzanleitung - XVA Provider unter Mac OSX 10 Installation und Bedienung- Inhalt Allgemeine Hinweise:... 1 Kapitel 1 Installation und Konfiguration... 2 Schritt 1: Java SE Development Kit 6 installieren:...

Mehr