Analyse und Implementierung eines offenen Streaming ... · Mit PPLive, PPStream, SopCast [sop], TVAnts [tva] und UUSee kommen die kommerziell erfolgreichsten P2P-Streaming-Anbieter

Analyse und Implementierung eines

o�enen Streaming-Protokolls auf

P2P-Basis

Katrin Gustat

September 2010

FernUniversität in HagenFakultät für Mathematik und InformatikLehrgebiet KommunikationsnetzeBachelor-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 Ma-thematik und Informatik eingereichte Bachelorarbeit zum Thema

Analyse und Implementierung eines o�enen Streaming-Protokolls auf P2P-Basis

vollkommen selbständig verfasst und keine anderen als die angegebenen Quellen undHilfsmittel benutzt sowie Zitate kenntlich gemacht habe.

Granada, den 06.09.2010

Katrin Gustat

2

Kurzfassung

Seit dem Jahr 2000 wurden eine Vielzahl von wissenschaftlichen Arbeiten zum ThemaP2P-Streaming verö�entlicht. Aufgrund der groÿen Menge an vorhandenen Abhandlun-gen, dem Fehlen einer allgemein gültigen Terminologie und der Tatsache, dass sich einigeArbeiten sogar widersprechen, ist es sehr schwierig, einen verlässlichen Überblick zu er-halten.

Das Ziel dieser Arbeit ist daher, eine systematische Übersicht über den Bereich P2P-Streaming zu liefern und die komplexe Funktionsweise von P2P-Streaming-Systemendurch 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. Thelarge volume of existing information coupled with the lack of a generally accepted ter-minology and the existence of some dissenting papers make it rather di�cult to obtaina satisfactory overview of p2p streaming technology.

Therefore the goal of this work is to present a systematic survey of p2p streaming andto describe the complex functionality of p2p streaming systems by analyzing and imple-menting one particular p2p streaming protocol called CoolStreaming [ZL+05].

First the work explains streaming technology and the characteristics of p2p streamingand p2p live streaming protocols. It compares the features of 21 of the most discussed p2plive streaming protocols which, to my knowledge, represents the largest comparison ofthis kind. This is followed by an analysis and a description of the implementation of theCoolStreaming protocol itself. Possible enhancements to this protocol are then discussedand evaluated.

3

Inhaltsverzeichnis

1 Einführung 71.1 Erfolgsgeschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3 CoolStreaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.4 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.5 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 Streaming 152.1 Audio-/Videokomprimierung . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1 Digitalisierung analoger Daten . . . . . . . . . . . . . . . . . . . . 162.1.2 Codecs, Datei- und Containerformate . . . . . . . . . . . . . . . . . 172.1.3 Der MPEG-Standard . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.1.3.1 MPEG-Videocodecs . . . . . . . . . . . . . . . . . . . . . 182.1.3.2 MPEG-Audiocodecs . . . . . . . . . . . . . . . . . . . . . 18

2.1.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2 Streaming-Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3 Streaming-Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4 Verbindungsarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5 Streaming-Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.5.1 Klassische Architekturen . . . . . . . . . . . . . . . . . . . . . . . . 232.5.1.1 Client/Server . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.1.2 CDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.5.2 Multicast über Internet . . . . . . . . . . . . . . . . . . . . . . . . 242.5.2.1 IP-Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 242.5.2.2 Application-Level-Multicast . . . . . . . . . . . . . . . . . 25

2.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 P2P-Streaming 283.1 P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.1 Begri�sklärung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.1.2 Klassi�zierung von P2P-Systemen . . . . . . . . . . . . . . . . . . 29

3.2 Zusammenhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3 Grundlegende Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3.1 Video-On-Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.2 Live-Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Analyse 354.1 Allgemeines Prozessmodell für P2P-Live-Streaming . . . . . . . . . . . . . 35

4

4.2 Protokollcharakteristiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2.1 Join . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2.2 Topologie der Streamverteilung . . . . . . . . . . . . . . . . . . . . 374.2.3 Art der Streamverteilung . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.3.1 Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.3.2 Pull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.3.3 Hybrides Push-Pull . . . . . . . . . . . . . . . . . . . . . 40

4.2.4 Gruppenverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.4.1 Vater-Sohn-Beziehungen/Partnerschaften . . . . . . . . . 414.2.4.2 Verwaltung der Gruppenmitglieder . . . . . . . . . . . . . 42

4.2.5 Fehlerkorrekturmechanismen und Kodierungen . . . . . . . . . . . 444.2.5.1 MDC (Multiple-Description-Coding) . . . . . . . . . . . . 454.2.5.2 FEC (Forward-Error-Correction/Vorwärtsfehlerkorrektur) 454.2.5.3 NC (Network-Coding/Netzwerkkodierung) . . . . . . . . 46

4.2.6 Transportprotokolle . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2.6.1 RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2.6.2 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2.6.3 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2.6.4 Wahl des Transportprotokolls . . . . . . . . . . . . . . . . 48

4.2.7 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.3 Mesh-Pull-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3.1 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.3.2 Bearbeitung von Datenrequests . . . . . . . . . . . . . . . . . . . . 52

4.4 Performance-Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.4.1 Protokolleigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . 534.4.2 P2P-Streaming-Metriken . . . . . . . . . . . . . . . . . . . . . . . . 53

4.5 Graph-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5 Implementierung 605.1 P2PNetSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.2 SimBench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.3 Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.4 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.4.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.4.2 Datentransport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.4.3 Die Klasse StreamingMessage . . . . . . . . . . . . . . . . . . . . . 685.4.4 Die Klasse StreamingPeer . . . . . . . . . . . . . . . . . . . . . . . 685.4.5 Hauptmodule eines Streamingpeers . . . . . . . . . . . . . . . . . . 695.4.6 Das Paket datenmanager . . . . . . . . . . . . . . . . . . . . . . . 70

5.4.6.1 Die Klasse DatenManager . . . . . . . . . . . . . . . . . . 715.4.6.2 Die Klasse P2PStream . . . . . . . . . . . . . . . . . . . . 715.4.6.3 Die Klasse StreamSegment . . . . . . . . . . . . . . . . . 715.4.6.4 Die Klasse SegmentID . . . . . . . . . . . . . . . . . . . . 715.4.6.5 Die Klasse Pu�er . . . . . . . . . . . . . . . . . . . . . . . 725.4.6.6 Die Klasse Scheduler . . . . . . . . . . . . . . . . . . . . . 73

5

5.4.6.7 Die Klasse FirstO�set . . . . . . . . . . . . . . . . . . . . 735.4.6.8 Die Klasse Player . . . . . . . . . . . . . . . . . . . . . . 74

5.4.7 Das Paket partnershipmanager . . . . . . . . . . . . . . . . . . . . 745.4.7.1 Die Klasse Partner . . . . . . . . . . . . . . . . . . . . . 745.4.7.2 Die Klasse PartnerListe . . . . . . . . . . . . . . . . . . . 75

5.4.8 Das Paket membershipmanager . . . . . . . . . . . . . . . . . . . . 755.4.8.1 Die Klasse MembershipCache . . . . . . . . . . . . . . . . 765.4.8.2 Die Klasse MembershipManager . . . . . . . . . . . . . . 76

5.4.9 Das Paket util . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.4.9.1 Die Klasse MyLogger . . . . . . . . . . . . . . . . . . . . 775.4.9.2 Die Klasse Bandbreitenregulator . . . . . . . . . . . . . . 785.4.9.3 Die Klasse Zeit . . . . . . . . . . . . . . . . . . . . . . . . 795.4.9.4 Die Klasse StreamingAddress . . . . . . . . . . . . . . . . 80

5.5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.5.1 Bedeutung des Testens . . . . . . . . . . . . . . . . . . . . . . . . . 805.5.2 Modultests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.5.2.1 JUnit in der Praxis . . . . . . . . . . . . . . . . . . . . . 815.5.2.2 Exemplarischer Testfall . . . . . . . . . . . . . . . . . . . 82

5.6 Veri�kation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6 Auswertung 876.1 Simulationsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.2 Evaluierung und Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . 886.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

7 Abschluss 937.1 Feedback zu P2PNetSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937.2 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Literaturverzeichnis 104

Abbildungsverzeichnis 105

Tabellenverzeichnis 106

Glossar 109

6

1 Einführung

Seit dem Jahre 2000 wurden sehr viele P2P-Streaming-Protokolle entwickelt, daruntereine nicht unerhebliche Zahl in China oder Hongkong. Gleichzeitig kommen aus China diekommerziell erfolgreichsten P2P-Streaming-Lösungen. Zu Beginn dieser Arbeit analysiereich den Erfolg von P2P-Streaming in China, um die Faktoren herauszu�nden, unter denenein für P2P-Streaming-Entwicklungen günstiges Klima entsteht.

Es wird dann die Motivation für diese Arbeit dargelegt und aufgezeigt, worin sich dieseArbeit von den vorhandenen P2P-Streaming-Arbeiten unterscheidet und nach welchenKriterien das zu implementierende Protokoll ausgewählt wurde. Es folgen De�nitionen,die erforderlich sind, um die Aufgabenstellung zu erfassen und abzugrenzen. Das Kapitelschlieÿ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 siehtdieser Erfolg konkret aus?

Die beeindruckendsten Zahlen dazu kommen aus China, wo sich die Anzahl der User, diegleichzeitig die Übertragung eines Live-Ereignisses über einen P2P-Streaming-Anbieterverfolgten, innerhalb weniger Jahre mehr als verzehnfacht hat:

� 2005: PPLive [ppl] misst 250.000 gleichzeitige User bei Chinas Gesangscastingshow�Super Girl�. [Hua07]

� 2007: Knapp 1,5 Millionen User beim NBA1-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 Übertra-gungen anlässlich des 60.Nationalfeiertags Chinas, PPLive weitere 2 Millionen undUUSee 2-3 Millionen. [Zha10]

Zum Vergleich: Die Amtseinführung von US-Präsident Obama am 20.01.2009 war dasmeist beachtete Medienereignis in den USA der letzten Jahre. Bei CNN verfolgten nur650.000 gleichzeitige P2P-Streaming-User die Übertragungen zur Amtseinführung, ob-wohl CNN gemessen an den anderen Sendern noch die meisten Online-Zuschauer errei-chen konnte [new09]. Vergleicht man beide Medienereignisse aus dem Jahre 2009 mitein-ander (60.Nationalfeiertag in China, Obamas Amtseinführung in den USA) und setzt die

1Amerikanische Basketball-Liga

7

1.1. ERFOLGSGESCHICHTE KAPITEL 1. EINFÜHRUNG

Userzahlen in Relation zur jeweiligen Bevölkerung mit Internetanbindung, kommt manzu folgendem Ergebnis: Während in den USA nur 0,3% die P2P-Streaming-Übertragungnutzten, betrug der Anteil in China 3,1% (bei PPStream, PPLive, UUSee).

Mit PPLive, PPStream, SopCast [sop], TVAnts [tva] und UUSee kommen die kommerziellerfolgreichsten P2P-Streaming-Anbieter aus China. Auÿerhalb Chinas sind in erster LinieTVUnetworks (Sitz: Mountain View) mit dem TVUPlayer und Zattoo (Schweiz) bekannt,wobei Zattoo derzeit2 nur in 6 europäischen Ländern3 empfangen werden kann.

Neben den Anbietern stammt auch ein Groÿteil der Konsumenten aus China (bei PPLive70-80% [Zha10]), auf die das Streamingangebot zugeschnitten ist. Viele der aktuellen wis-senschaftlichen P2P-Streaming-Arbeiten wurden an Universitäten in China oder Hong-kong verfasst, an denen u.a. auch kommerzielle Systeme entstanden wie PPLive4, Sop-Cast5, TVAnts6 oder CoolStreaming7. China ist führend, sowohl was Nachfrage undAngebot als auch die Weiterentwicklung betri�t.

Wie lässt sich dieser Erfolg Chinas im Bereich P2P-Streaming erklären?

Moderate Urheberrechtsbestimmungen Auf meine Nachfrage bei den Autoren vonP2P-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 Chinasdie moderaten Urheberrechtsbestimmungen des Landes an. Laut Zhang begünstigen diesedas Klima für P2P-Streaming-Entwicklungen in China.

In der westlichen Welt dagegen haftet �P2P� und �P2P-Streaming� anscheinend der Nim-bus des Illegalen an, vor allem nachdem Unternehmen wie Napster [nap], Kazaa oderCyber***-TV schlieÿen mussten. Beispielhaft für den schlechten Ruf von P2P-Streamingsind die negativen Reaktionen in den USA auf den P2P-Live-Stream von CNN, mit demBenutzer die Übertragung der Amtseinführung Obamas verfolgen konnten. Die Benutzermussten dazu ein Plugin herunterladen. CNN hatte vorab zwar mehrfach bekannt gege-ben, dass die Übertragung per P2P erfolgt. Beim Download des Plugins selbst wies derSender aber nicht ausdrücklich auf diese Tatsache hin. Aus dem Grund wurde CNN vonmehreren Seiten vorgeworfen, seine Benutzer getäuscht zu haben. Microsoft beschuldigteCNN, �die Uploadbandbreite der Benutzer entführt zu haben�, andere sprachen sogardavon, dass �CNN die Rechner seiner Benutzer gestohlen habe� [new09].

Staatliche Förderung Die chinesische Regierung investiert einerseits in den Ausbau derInternetinfrastruktur. Im Jahre 2009 waren es 277,34 Milliarden Dollar, was einen Anstiegum 28,5% im Vergleich zum Vorjahr bedeutet [cnn10]. Die Regierung fördert andererseitsden Einsatz von IPTV und damit indirekt von alternativen Übertragungstechnologien wie

2Stand 08/20103Deutschland, Frankreich, Schweiz, Groÿbritannien, Spanien, Dänemark4Huazhong University of Science and Technology5Fudan University6Zhejiang University7HKUST (Hong Kong University of Science and Technology), The Chinese University of Hong Kong,Simon Fraser University in Vancouver

8

1.1. ERFOLGSGESCHICHTE KAPITEL 1. EINFÜHRUNG

P2P. Parteimitglieder in ländlichen Gegenden erhalten Fernunterricht mittels IPTV unddas Ministerium für Informationsindustrie veranstaltet Forschungsrunden zusammen mitHerstellern und Telekommunikationsanbietern zur Entwicklung eigener IPTV-Standards[Ksh08].

Hohe Nachfrage nach Live-Übertragung von Groÿ- und Sportereignissen Die Über-tragung von Groÿereignissen - wie Olympia 2008 in Peking, Chinas 60.Nationalfeiertag2009 und die Weltausstellung in Schanghai 2010 - wirken sich gewiss fördernd auf dieNachfrage nach Live-Streams aus. Darüber hinaus kann in China ein hohes Interessean Sport-Übertragungen per P2P-Live-Stream verzeichnet werden. Das betri�t in ersterLinie Cricket (Indian Premier League), Fuÿball (English Premier League, Bundesliga,Spaniens La Liga, Italiens Serie A) und Basketball (NBA), letzteres vor allem seitdemchinesische Basketballer in der amerikanischen NBA spielen. Die Begegnung zwischenDallas Mavericks und Houston Rocket, bei der Yao Ming aus China mitspielte, wurde imDezember 2007 von 936.000 seiner Landsleute live gestreamt (bei SopCast).

Problematischerweise erfolgen viele Übertragungen unautorisiert. Je nach Sportart wer-den ca. 30% (Cricket), 75% (Basketball) bzw. 88% (Fuÿball) dieser unautorisierten Über-tragungen über P2P-Netze gestreamt. Tabelle 1.1 listet unautorisierte Fuÿball-Streamsaus der Saison 2007/2008 auf und gibt Aufschluss darüber, inwieweit die Streams P2P-basiert erfolgten. Während hauptsächlich SopCast und TVAnts zum unautorisiertenStreamen von Live-Sportereignissen genutzt werden (der Upload eigener Streams ist beibeiden möglich) schlossen PPLive und PPStream mit der amerikanischen NBA Partner-schaften 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 177 63% 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 technika�n und adaptierenneue Techniken schnell. Bereits Mitte der 80er Jahre waren in China Konsumgebrauchs-güter so stark verbreitet wie in Japan oder Südkorea [Ksh08].

Internetuserstruktur Was das Internet betri�t, be�ndet sich China immer noch in derWachstumsphase. Die Anzahl der Internetuser ist 2009 im Vergleich zum Vorjahr um28,9% auf insgesamt 384 Millionen gestiegen (siehe Abbildung 1.1). Trotz des stetigenWachstums besaÿen 2009 weniger als ein Drittel (28,9%) der Bevölkerung in China einenInternetzugang, im Gegensatz zu rund 75% in den USA oder Japan. Dadurch ergibt sichauch eine andere Userstruktur. Gut 60% der User sind jünger als 30 Jahre, haben ein

9

1.2. MOTIVATION KAPITEL 1. EINFÜHRUNG

Abbildung 1.1: Anstieg der Internetuser in China in Millionen und prozentual zum Vor-jahr (nach [cnn10])

geringes Einkommen, 29% sind Studenten. Dies kann die Nachfrage nach kostenlosenDownloads und P2P-Streams erklären.

Die zu Beginn dieses Abschnitts zitierten hohen Userbeteiligungen wurden beim Strea-ming von Live-Ereignissen erreicht. Dabei kann es zu sogenannten Flash-Crowds kom-men, d.h. die Anzahl der User, die einen Kanal streamen möchten, steigt sprunghaft anund fällt nach kurzer Zeit wieder sehr schnell ab. Der Erfolg von P2P-Live-Streamingstellt durch diese kurzzeitig sehr hohe Nachfrage damit gleichzeitig eine groÿe technischeHerausforderung dar.

1.2 Motivation

Zum Thema P2P-Streaming wurde eine sehr groÿe Anzahl wissenschaftlicher Abhand-lungen 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 Begri�ichkeiten bis-her nicht einheitlich de�niert. Dies macht es sehr schwierig, einen Überblick über diesenForschungsbereich 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

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 Protokolleigenschaftenwerden nicht verö�entlicht.

Das Ziel dieser Arbeit ist daher, einen systematischen Überblick über die wesentli-chen Charakteristiken von P2P-Streaming zu liefern und aufzuzeigen, worin sich P2P-Streaming-Protokolle unterscheiden. Es folgt die Veranschaulichung der Arbeitsweise ei-nes ausgewählten P2P-Streaming-Protokolls mittels Analyse und Implementierung. Dader Schwerpunkt der aktuellen P2P-Streaming-Forschungen auf Protokollen liegt, mitdenen Inhalte live gestreamt werden können, sollte das ausgewählte Protokoll für Live-Streaming-Anwendungen konzipiert sein. Aufgrund der groÿen Anzahl von Protokollenaus China bot es sich zudem an, ein Protokoll aus diesem Land zu berücksichtigen. DasProtokoll sollte auÿerdem von kommerzieller und wissenschaftlicher Bedeutung sein so-wie klar und übersichtlich strukturiert, um den komplexen Streamingablauf verdeutlichenund 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 OverlayNetwork�. So wie bei den meisten im Realbetrieb eingesetzten P2P-Streaming-Systemenüblich, arbeitet es datengesteuert (�data-driven�), d.h. der Empfänger fordert fehlendeDaten beim Sender an. Damit unterschied es sich von seinen Vorgängern und wird dahermitunter als das erste echte P2P-Streaming-System bezeichnet.

Bereits im Mai 2004 wurde eine Internet-basierte DONet-Implementierung unter demNamen �CoolStreaming� in der Version 0.9 verö�entlicht. Da �CoolStreaming� nicht nurgut klang, sondern auch eine technische Konnotation hatte (�Cooperative Overlay Stre-aming�), wurde das System unter dieser Bezeichnung eingesetzt und bekannt. Bis zumSommer 2005 gab es Millionen Downloads und bis zu 80.000 gleichzeitige User aus 24Ländern bei einer durchschnittlichen Streamingrate von 400 kbps. CoolStreaming warauch die erste Software, die Live-TV-Übertragungen über das Internet anbot.

Die CoolStreaming-Autoren gaben in [ZL+05] Protokoll-Details bekannt, im Unterschiedzu den danach entwickelten Systemen wie PPLive, SopCast, TVAnts und PPStream,welche sehr schnell an Bekanntheitsgrad gewannen (siehe Abbildung 1.2).

2007 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 Cor-poration, das 2006 in Zusammenarbeit mit Yahoo Live-IPTV-Programme anbot [Zha07].Urheberrechtsstreitigkeiten führten u.a. dazu, dass unter der gleich lautenden Adressehttp://www.coolstreaming.us nicht das in dieser Arbeit besprochene System zu �ndenist.

11

1.4. AUFGABENSTELLUNG KAPITEL 1. EINFÜHRUNG

Abbildung 1.2: Nachfrage nach kommerziellen P2P-Streaming-Systemen (Stand Mai2010) [goo10]

1.4 Aufgabenstellung und Begri�sklärung

Die Annäherung an das Thema der Arbeit �Analyse und Implementierung eines o�enenStreaming-Protokolls auf P2P-Basis� erfolgt durch Klärung und Abgrenzung der Begri�eProtokoll, o�en, P2P und Streaming sowie weiterer Begri�e, die auf diesen Wörternaufbauen.

Protokoll Ein Protokoll ist ganz allgemein eine Folge von Regeln, d.h. eine Folge vonmehreren fest vorgegebenen Schritten, mit denen die Rahmenbedingungen einer Kom-munikation festgelegt werden [Bra05, FH07, Sch07]. Für den Aufbau und Betrieb einesP2P-Streaming-Systems sind mehrere Protokolle (z.B. für Partnerverwaltung, Gruppen-verwaltung) und auch kommunikationsübergreifende Komponenten erforderlich (wie derScheduler, siehe Abschnitt 4.3.1). Für diese Arbeit de�niere ich ein P2P-Streaming-Pro-tokoll als Einheit aus verschiedenen Protokollen und Algorithmen, die zum Aufbau undTest eines P2P-Streaming-Systems (in diesem Fall CoolStreaming) benötigt werden.

O�enes Protokoll Damit ein Protokoll als o�en bezeichnet werden kann, muss derQuellcode nicht zwingend o�en gelegt werden. Wesentliche Protokolleigenschaften wur-den aber von den Entwicklern verö�entlicht und sind bekannt. Dies tri�t für das ProtokollCoolStreaming zu. Im Gegensatz dazu stehen z.B. PPLive und SopCast, deren Charak-teristiken nur über Reverse-Engineering zu ermitteln sind.

P2P In einem P2P-System kommunizieren die Rechnerknoten (die Peers) gleichbe-rechtigt 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 bezeichnetezunächst die von Holzfällern angewandte Methode, Baumstämme hintereinander überStröme und Flüsse zu transportieren [Pia07].

12

1.4. AUFGABENSTELLUNG KAPITEL 1. EINFÜHRUNG

In der Informatik ist ein Stream ein im weitesten Sinn gleichförmiger Fluss digitaler Da-ten. Beim Streaming - genauer Multimedia-Streaming/Media-Streaming - werden Audio-und/oder Videodaten über ein IP-Netzwerk übertragen und kontinuierlich verwertet[FH07].

Zum Verständnis der dahinter liegenden Konzepte wird in Kapitel 2 erörtert, welcheDaten in welchem Format gestreamt werden können sowie wo, wie und wofür Streamingeingesetzt wird (siehe Abbildung 2.1).

P2P-Streaming-System/-Lösung Die Begri�e P2P-Streaming-Lösung und P2P-Strea-ming-System werden in der Fachliteratur meist analog verwendet. Um die Begri�e P2P-Streaming-System und P2P-Streaming-Protokoll voneinander abzugrenzen, de�niere ichein P2P-Streaming-System wie folgt:

� Die praktische Umsetzung betre�end kann ein P2P-Streaming-System als Imple-mentierung eines P2P-Streaming-Protokolls bezeichnet werden.

� Die Architektur betre�end ist ein P2P-Streaming-System eine Einheit bestehendaus Software- und Hardwarekomponenten, die eine Architektur für P2P-Streamingzur Verfügung stellen.

P2P-Streaming-Applikation/-Anwendung/-Software Ist ein System mit einer Benut-zerschnittstelle ausgestattet und direkt lau�ähig, spricht man von einer Applikation[FH07]. Eine P2P-Streaming-Applikation stellt einem Peer eine Schnittstelle zur Ver-fügung, wodurch dieser in einem dedizierten P2P-Streaming-Netz Mitglied werden undDaten streamen kann. Die Applikation umfasst eine Schnittstelle zu einem oder mehrerengängigen Medienplayern (bei kommerziellen Produkten in erster Linie Windows MediaPlayer).

P2P-Streaming-Netzwerk/-Netz/-Overlay Die Menge der Peers in einem P2P-Strea-ming-System lässt sich formal als endliche, nicht leere Knotenmenge V beschreiben, be-stehend aus n Peers Pi:

V = {Pi | 1 ≤ i ≤ n, n ∈ N}

Die Peers Pi sind miteinander in einem Netzwerk verbunden. Die Netzwerk- oder Ver-bindungsstruktur kann dabei durch das Protokoll bestimmt werden. Ist ein Peer Pi miteinem Peer Pj verbunden, dann wird Pj als Nachbar oder Partner (bei CoolStreaming)von Pi bezeichnet.

Die Menge der Partnerschaftsbeziehungen in einem P2P-Streaming-Netzwerk lässt sichformal als Menge E aus Kanten beschreiben, wobei E eine Teilmenge der Menge allermöglichen Partnerschaftsbeziehungen zwischen zwei Peers Pi und Pj darstellt:

E ⊆ {(Pi, Pj) | Pi, Pj ∈ V ∧ i 6= j}

13

1.5. GLIEDERUNG DER ARBEIT KAPITEL 1. EINFÜHRUNG

Ein P2P-Streaming-Netzwerk kann somit als ein gerichteter Graph G de�niert werden, alsTupel 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 Da-tenstruktur 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 ins-besondere erläutert, welche Daten gestreamt werden können, welche Anwendungen undMethoden zu unterscheiden sind und über welche Architekturen Streaming realisiert wer-den kann. In Kapitel 3 wird dargelegt, was P2P bedeutet, sowie eine Einführung in denBereich P2P-Streaming gegeben, wobei die grundlegenden Konzepte gezeigt werden.

Aufbauend auf den beiden genannten Kapiteln erfolgt in Kapitel 4 die Analyse desCoolStreaming-Protokolls, indem CoolStreaming anhand seiner Protokollcharakteristi-ken sowie seiner Performance mit anderen P2P-Live-Streaming-Protokollen verglichenwird. In diesem Kapitel werden auÿerdem 21 P2P-Live-Streaming-Protokolle in einemtabellarischen Vergleich gegenübergestellt (siehe Tabelle 4.1).

In Kapitel 5 wird die Implementierung des CoolStreaming-Protokolls beschrieben und imdarauf folgenden Kapitel 6 evaluiert. Im abschlieÿenden Kapitel 7 werden die Erfahrungenbei der Implementierung mit dem Simulator P2PNetSim geschildert und ein Ausblick aufzukünftige Entwicklungen in den Bereichen Streaming und P2P-Streaming gegeben.

14

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 we-sentliche Perspektiven bzw. Fragestellungen eingegangen, die in Abbildung 2.1 dargestelltsind.

Audio-/Videodatenkomprimiert

LAN/WAN Anwendungen?Methoden?

Verbindungsarten?Architekturen?

Streaming

Was? Wo? Wofür? Wie?

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 grund-legenden Schritte dieses Prozesses erklärt. Es folgt eine Übersicht über Standards undVerfahren, wobei der Unterschied zwischen Codecs (z.B. MPEG-4 Part 10), Container-formaten (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, nachwelchen Methoden und über welche Verbindungsarten bzw. Architekturen Streamingrealisiert werden kann.

2.1 Audio-/Videokomprimierung

Die ersten bekannten Versuche, Multimediadaten zu digitalisieren, stammen aus denfrühen 90er Jahren. Sun Microsystems entwickelte Audiodateien mit der Dateiendung�.au�. Diese enthielten einfachste Audiodaten, die auf dem Rechner wiedergegeben wer-den konnten. Später konnte Apples QuickTime bereits Videodaten abspielen, die al-lerdings für den Transport über das Internet zu groÿ waren. Der Durchbruch beimStreaming gelang RealNetworks, indem es die Daten in ein ausreichend kleines For-mat brachte. RealNetworks war mit seinem RealPlayer lange Marktführer, wurde aberaufgrund schlechter Preispolitik und mangelnder Bedienerfreundlichkeit inzwischen von

15

2.1. AUDIO-/VIDEOKOMPRIMIERUNG KAPITEL 2. STREAMING

Apple QuickTime, Microsoft Windows Media Player und Adobe Flash Player zurückge-drängt.

2.1.1 Digitalisierung analoger Daten

Damit das menschliche Auge einzelne Bilder als fortlaufenden Film wahrnimmt, müs-sen ca. 15 bis 25 einzelne Bilder pro Sekunde abgespielt werden. Man spricht in diesemZusammenhang von Bildrate/Framerate oder fps (frames per second). Die beiden ver-breiteten Videoformate PAL1 und NTSC2 unterscheiden sich bzgl. der Framerate. PALarbeitet mit 25fps, d.h. jedes Bild wird für eine Dauer von 40ms gezeigt. Im Gegensatzdazu 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öglichstgeringe Datenmenge zu erhalten. Zu diesem Zweck digitalisiert und komprimiert einMPEG-Encoder die Videosignale redundanzfrei, d.h. es werden nicht jeder Frame einzelnabgespeichert, sondern nur die Bilddi�erenzen. Nach dem MPEG-Standard unterscheidetman drei Arten von komprimierten Frames:

I-Frame (Intra-Frame/Key-Frame) Das komplette Bild wird kodiert ohne Berücksich-tigung vorheriger oder nachfolgender Frames. Ein I-Frame dient sozusagen als Referenz-bild und wird z.B. bei einem Szenewechsel erstellt.

P-Frame (Predicted-Frame) Ein P-Frame enthält die Di�erenz zwischen dem aktuellenBild und dem letzten vorangegangen I-Frame/P-Frame.

B-Frame (Bidirectional-Frame) Ein B-Frame wird mit Hilfe von bidirektionaler Kom-pression kodiert. Dabei wird die Di�erenz zwischen dem aktuellen Bild und dem letztenvorangegangen I-Frame/P-Frame kodiert sowie die Di�erenz zwischen dem aktuellen Bildund dem nachfolgenden I-Frame/P-Frame.

Frames werden in sogenannten GOPs gruppiert, wobei GOP die Kurzform von �groupof pictures� ist. Am Anfang einer jeden GOP steht ein I-Frame, gefolgt von mehrerenP-Frames oder B-Frames. Muss ein neuer I-Frame erstellt werden, beginnt ein neuerGOP. Dies ist beispielsweise bei einem kompletten Szenewechsel der Fall.

Jeder Frame wird zudem in Makroblöcke von jeweils 16x16 Pixel zerlegt. Zu jedemMakro-block gibt es einen Bewegungsvektor (motion vector), der die Bewegung des Makroblockszwischen zwei aufeinander folgenden Bildern beschreibt. Die Bewegung wird durch dieAngabe 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 abgegri�en werden. Folgende Abtast-raten sind gebräuchlich:

1in Europa2in Nord-/Südamerika, Japan, Korea, Taiwan

16


� 32kHz: Für FM-Radio und andere Audio-Broadcasts werden meist 32.000 Musterpro Sekunde abgegri�en.

� 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 werdenjeweils zwei Muster abgegri�en für den linken und den rechten Audiokanal.

Digitale Audiosignale liegen komprimiert oder unkomprimiert vor. Durch sogenanntesPerceptual-Encoding können Audiosignale e�zient komprimiert werden. Hierbei werdennur die vom menschlichen Gehör wahrnehmbaren Töne gespeichert. Ausge�ltert werdenbeispielsweise zu hohe Frequenzen sowie Töne, die weniger als eine Millisekunde dauernoder aufgrund einer hohen Umgebungslautstärke zu leise sind.

2.1.2 Codecs, Datei- und Containerformate

Ein Codec (Kunstwort aus coder/decoder) de�niert, wie analoge Audio- oder Videosi-gnale in digitale Daten umgewandelt werden und umgekehrt. Codecs unterscheiden sichbzgl. mehrerer Faktoren, u.a. der Kompressionsart (verlustfrei oder verlustbehaftet) undder erzeugten Bitrate/Datenrate. Verlustbehaftete Kompressionen wenden in der Regeldie im vorherigen Abschnitt geschilderten Verfahren an.

Die Kodierung erzeugt für Audio- und Videodaten zwei einzelne Streams, das Audio-und das Videoformat. Ein Muxer (oder Multiplexer) multiplext und synchronisiert beideStreams und legt sie in ein Containerformat ab, zusammen mit den für die synchro-ne Ausgabe erforderlichen Metainformationen, gegebenenfalls Untertiteln und weiterenTonspuren. Das Containerformat spezi�ziert, welche Daten miteinander in dem Formatabgelegt werden können. Das Containerformat kann auch als Datei abgespeichert werden,deren Dateiendung sich nach der Bezeichnung des Containerformats richtet. Hier folgeneinige Beispiele für bekannte Containerformate:

� AVI/Audio-Video Interleave (Dateiendung .avi): 1992 von Microsoft vorgestellt,wurde das Format von Microsoft nicht weiter gep�egt, aber von anderen erweitert.AVI stellt ein vergleichsweise einfaches Format dar. Es unterstützt inhärent wederUntertitel noch B-Frames. In AVI können verschiedenste Audio- und Videoformatemiteinander kombiniert werden. Häu�g �ndet sich MP3 zusammen mit älteren Vi-deoformaten. Das neuere Videoformat H.264 kann mangels B-Frame-Unterstützungnicht problemlos verwendet werden.

� PS/Programmstream (.ps) ist ein Format, das für nicht störungsanfällige Übertra-gungen eingesetzt wird, z.B. DVD.

� TS/Transportstream (.ts) stellt ein Containerformat dar, das für den Einsatz beistörungsanfälligen Übertragungen geeignet ist, z.B. Übertragungen per Satellit, An-tenne, Kabel/CATV.

� VOB/Video Object + IFO (.vob, .ifo), ein Containerformat für DVDs, enthältmeist mit MPEG-1 Part 2/MPEG-2 Part 2 kodierte Videodaten und mit demAC3-Audiocodec erstellte Audiodaten.

17


2.1.3 Der MPEG-Standard

Die Moving Pictures Experts Group hat ab 1991 unter dem Namen MPEG diverse Stan-dards zur Kompression von Audio- und Videodaten verö�entlicht.

2.1.3.1 MPEG-Videocodecs

Die Videostandards wurden jeweils zu Paketen zusammengefasst und sind unter dem Na-men MPEG-1, MPEG-2 und MPEG-4 bekannt. Einen MPEG-3-Video-Standard gibt esnicht. Dieser wurde zwar geplant, aber die Entwicklungen zu MPEG-3 waren noch vor derFertigstellung von MPEG-2 abgeschlossen. Daher wurden die MPEG-3-Erweiterungen inMPEG-2 integriert und MPEG-3 übersprungen.

Der erste Standard MPEG-1 sollte ermöglichen, Video-CDs zu erstellen. 1996 folgteMPEG-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. inSet-Top-Boxen, digitalen Satellitenreceivern und DVD-Playern.

MPEG-4 (ab 2000) umfasst insbesondere zwei Standards für Videoformate: MPEG-4Part 2 und MPEG-4 Part 10 (auch bekannt als H.264 oder MPEG-4 AVC). Mit H.264können Videos im Unterschied zu MPEG-2 bei gleich bleibender Qualität bis zu 50% e�-zienter komprimiert werden. Dadurch wird die Übertragung von High-De�nition-Videos(kurz HD-Videos) über IP-Netze möglich. H.264 wird für Blu-ray-Disks und HD-DVDseingesetzt.

Codecs werden nach diesen Standards erstellt. Für jeden Standard gibt es mehrere Pro-�le und Level. Die Pro�le spezi�zieren Merkmale, z.B. ob Bilder zu B-Frames kodiertwerden 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 Kom-binationen aus Pro�l und Level, wobei nicht alle Kombinationen von Herstellerseite un-terstützt werden. Mit höherem Pro�l steigt die Komplexität und damit die Rechenlastbeim Kodieren. Das einfachste Pro�l von H.264 (Baseline-Pro�l) unterstützt beispiels-weise keine B-Frames, wodurch die Komplexität und die Verzögerung bei der Kodierungverringert werden. Aufgrund der geringeren Verzögerung ist das Baseline-Pro�l für Vi-deokonferenzen und mobile TV-Applikationen geeignet.

2.1.3.2 MPEG-Audiocodecs

Gebräuchliche MPEG-Audiocodecs sind MPEG Layer 1, MPEG Layer 2, MPEG Layer3 (bekannt als MP3) sowie MPEG Advanced Audio Coding (AAC). Nahezu alle Contai-nerformate 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 (vorzugs-weise mit H.264) und unterstützt Abtastraten von bis zu 96kHz.

2.1.4 Zusammenfassung

Ein Containerformat enthält nach spezi�zierten Codecs erzeugte Audio- und Videoforma-te. Der Transport und die Steuerung des gemuxten Streams ist je nach Containerformat

18

2.2. STREAMING-ANWENDUNGEN KAPITEL 2. STREAMING

und Anwendung mit verschiedenen Protokollen möglich. RTP (Real-Time Transport Pro-tocol [SC+96]) und RTSP (Real Time Streaming Protocol [SRL98]) beispielsweise sindo�ene 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 Fra-mework zum Streamen von Multimediadaten an, das sich aus Codecs, eigenen Contai-nerformaten, kostenfreien Playern auf Clientseite, kostenp�ichtigen Streamingservern3

und Protokollen für Datentransport und -steuerung zusammensetzt. In Tabelle 2.1 sindeinige Standardkombinationen (aus Containerformaten, Videocodecs, Audiocodecs undProtokollen) und deren Anwendungen aufgelistet. Weitere Kombinationen sind möglich.

Beim Streamingprozess müssen der Server und die Clientplayer die gleichen Kodierungeneinsetzen. Klassische Push-Streaming-Server unterstützen meist mehrere Playerformateund bieten zudem Kompressionen für jede Kombination aus Playerformat und Verbin-dungsgeschwindigkeit (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, Videokonferenzen4, Internet-Radio oder Internet-TV. In Bezug auf Internet-TV muss zwischen Web-TV (auch Internet-Video genannt) und IPTV unterschieden wer-den. Web-TV kann über P2P-Streaming-Netze realisiert werden, IPTV dagegen nicht.Anhand folgender De�nitionen können die Begri�e Web-TV und IPTV voneinander ab-gegrenzt werden:

Web-TV (Internet-Video) Verschiedenste Beiträge werden über Overlaynetze im öf-fentlichen Internet gestreamt. Dabei kommen unterschiedliche Formate und Protokollezur Verwendung (siehe dazu Tabelle 2.1). Der Empfang erfolgt auf dem Rechner mittelsspezieller Software, auf Consumer-Fernsehern mittels Netzwerkadapter oder auf porta-blen Videoplayern.

IPTV Analog zum Kabelfernsehen stellen IPTV-Anbieter (z.B. Telekom, Alice) profes-sionell erstellte TV-Inhalte in hoher Qualität zur Verfügung. Die Inhalte werden übereigene Netzwerke übertragen, die unabhängig vom Internet sind. Die IPTV-Konsumen-ten schlieÿen ein kostenp�ichtiges Abonnement ab und empfangen die Inhalte auf ihremConsumer-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 kontinu-ierlich übertragen und verwertet werden, nicht lokal gespeichert werden müssen, hat sich3zum Push von Daten4mit Videocodecs H.262/MPEG-2 und H.263

19

2.3. STREAMING-METHODEN KAPITEL 2. STREAMING

Beschreibung

Containerform

at

(Dateiendung)

Videocodec/-form

at

Audiocodec/-form

at

Datentransport-/steuerung

Adobe

Flashplayer

Flash

Video/FLV

(.�v)

H.264(früher:Sorenson

Spark,On2VP6)

MPEG-4

Part3(A

AC)

RTMP(proprietär)

AppleQuickT

ime

(Standard-Container

für

QuickT

ime)

QuickT

ime

(.mov,.qt)

H.264

MPEG-4

Part3(A

AC)

RTP/RTSP

DivX/XviD-Streaming

DivX(.divx)

MPEG-4

Part2

MP3

HTTP(D

ownloadandPlay)

DVB(D

igitalesFernsehen),

z.B.DVB-T

MPEG-2

Transportstrom

(.ts)

MPEG-2

MPEG-Audio

LayerII

RTP/RTSP

MP4-Standard-Container

MPEG-4

Part

12/MP4(.mp4)

H.264

MPEG-4

Part3(A

AC)

HTTP(D

ownloadandPlay)

Ogg-Standard-Container

(Container

fürfreie

Xiph.org-Codecs)

Ogg

(.ogg)

Ogg

Theora

(basiertauf

On2VP3.2)

Ogg

Vorbis

HTTP(D

ownloadandPlay),

Wiedergabe

mittels

<audio>/<video>in

HTML5

ohneBrowserplugin(derzeit

unterstütztdurchOpera,Mozilla

FirefoxundGoogleChrome)

RealPlayer

(Standard-Container

für

RealM

edia)

RMVB(.rm

,.rmvb)

RealVideo

RealAudio

RTP/RTSP

WebM-Container

von

Google(freierContainer

für

HTML5)

WebM

(.webm)

basiertauf

Matroska-Container

(MKV)

On2VP8(seitdem

Aufkauf

vonOn2im

Februar2010

imBesitzvonGoogle)

Ogg

Vorbis

HTTP(D

ownloadandPlay),

Wiedergabe

mittels

<audio>/<video>in

HTML5

ohneBrowserplugin(derzeit

unterstütztdurchOpera,Mozilla

FirefoxundGoogleChrome)

WindowsMedia

Player

(Standard-Container

für

WindowsMedia)

AdvancedSystems

Form

at/ASF(.asf)

WindowsMedia

Video

WMV9/VC1

WindowsM

edia

Audio

MMS(proprietär)/RTSP

Tabelle2.1:Gängige

Kom

binationen

ausContainer,CodecsundProtokollen[Sim08,tuc10]

20

2.4. VERBINDUNGSARTEN KAPITEL 2. STREAMING

eine weitere Methode entwickelt, die ebenfalls als Streaming bezeichnet wird und beider die gestreamten Daten lokal abgespeichert werden. Die letztere Methode wird inder Fachliteratur Pseudo-Streaming genannt im Gegensatz zu True-Streaming (echtemStreaming):

Pseudo-Streaming Man spricht hier auch vom �Open-after-downloading�-Modus. DieWiedergabe erfolgt erst nach dem Download der Daten. Die Daten werden mit HTTPoder FTP übertragen. Da in erster Linie HTTP eingesetzt wird, ist auch die BezeichnungHTTP-Streaming gebräuchlich.

Man unterscheidet hier:

� Download & Play: Der Stream wird in einer Datei gespeichert. Erst nach vollständi-gem Download dieser Datei können die Daten auf dem Clientrechner wiedergegebenwerden. Die Wiedergabe ist damit unabhängig von der Bandbreite, aber die Ver-zö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 sukzessiveWiedergabe auch dann möglich, wenn die verfügbare Bandbreite geringer als dieStreamingrate sein sollte.

True-Streaming/Echtes Streaming Die Wiedergabe (das Playback) der Daten ist sogut wie gleichzeitig mit dem Datenempfang möglich. Man spricht daher auch vom �Play-while-downloading�-Modus [WLQ06, XH+02]. Gestreamt werden kann nur, falls die Down-loadbandbreite mindestens so hoch ist wie die Streamingrate (im Internet meist ca. 400kbps).

Man unterscheidet hier:

� Live-Streaming: Es erfolgt die Übertragung von Live-Inhalten (z.B. von Sporter-eignissen wie Bundesliga-Spielen).

� Video-On-Demand/VoD: Die Inhalte (z.B. Spiel�lme) werden bei Bedarf angefor-dert 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übertragun-gen basieren konzeptionell auf Unicast aufgrund von Punkt-zu-Punkt-Verbindungen bzw.Endsystem-zu-Endsystem-Verbindungen (IP). Beispiele: Klassisches Streaming, bei dem

21

2.5. STREAMING-ARCHITEKTUREN KAPITEL 2. STREAMING

sich jeder Client mit dem Streamingserver verbindet. Klassische Internetanwendungenwie E-Mail-Versand, FTP-Download, HTTP-Download.

Broadcast (1:alle) Ein Sender schickt an alle Empfänger. Beispiele: Broadcastnach-richten 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: Ver-sand von Newslettern, Übertragung von Vorstandsreden an Mitarbeiter, Übertragungder Aufnahmen von Überwachungskameras an den Sicherheitsdienst.

Multicast (1:n, m:n) Ein oder mehrere Sender schicken an mehrere Empfänger. Bei-spiele: Audio-/Videokonferenzen, IP-Telefonie.

Theoretisch kann jede der vier vorgestellten Verbindungsarten zum Streamen von Mul-timediadaten verwendet werden. Broadcast über das Internet ist allerdings nicht prak-tikabel. Broadcast über das LAN ist zwar möglich, aber aufgrund des hohen Datenauf-kommens beim Streamen und der Kollisionsgefahr im LAN nicht ratsam.

Für Live-Streaming bieten sich Multicast-Verbindungen mit der Möglichkeit des Versandsan eine Empfängergruppe an. Bei der Implementierung von Multicast als IP-Multicast(siehe Abschnitt 2.5.2.1) verschickt die Quelle - im Unterschied zu Unicast - an mehrereEmpfä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, mitdenen die Endhosts (Hosts 1,2 in Abbildung 2.2) verbunden sind. Die mit den Endhostsverbundenen Router müssen dazu Multicast-fähig sein (siehe auch Abschnitt 2.5.2.1).[Sim08]

RouterS

2

1

Unicast

RouterS

1

2IP-Multicast

Abbildung 2.2: Unicast und IP-Multicast (nach [Sim08])

2.5 Streaming-Architekturen

Echtes Streaming (True-Streaming) im Internet ist über verschiedene Architekturen mög-lich, d.h. über Client/Server, Content-Delivery-Netzwerke (CDNs), IP-Multicast oderApplication-Level-Multicast (ALM). Abbildung 2.3 zeigt diese Streaming-Architekturenin Abhängigkeit voneinander.

5Hybrid-Fiber-Coax-Kabelnetzwerk

22


Streaming-System

zentralisiert (Client-Server) dezentralisiert

Router-basiert (IP-Multicast) nicht Router-basiert

Infrastruktur-basiert (CDN) Application-Level-Multicast

Endsysteme mitInfrastruktur-Support (AnySee)

Endsysteme ohneInfrastruktur-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ätz-licher Infrastruktur-Support (z.B. durch Content-Delivery-Server) ist nicht erforderlich.

2.5.1 Klassische Architekturen

2.5.1.1 Client/Server

Bei klassischen Client/Server-basierten Streaming-Systemen verbinden sich die Clientsmit dem Quellserver und der Content wird direkt vom Server zum Client gestreamt. ImUnterschied zu P2P-basierten Systemen leiten die Knoten die empfangenen Daten nichtan andere Knoten weiter.

Solch zentralisierte Systeme sind einfach und leicht zu implementieren [E�08, LR+08].Prozessorleistung, Speicherkapazität, I/O-Durchsatz sowie die begrenzte Netzwerkband-breite werden aber zum Flaschenhals des Systems [WLQ06]. Da die Bandbreite der Cli-ents 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 einenSingle-Point-Of-Failure dar, weshalb sie leichter angegri�en werden können und zudemweniger zuverlässig sind im Hinblick auf die Ausfallsicherheit.

2.5.1.2 CDN

CDN-/Content-Delivery-Network-basiertes Streaming ist eine Variation des Client/Ser-ver-Modus. Dienstanbieter wie Akamai oder Limelight positionieren Proxys an strategischwichtigen Standorten im Internet (�network edges�). Die zu streamenden Daten liegen

23


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ür-zer, der Netzwerkverkehr geringer und es können mehr Endnutzer bedient werden. EinBroadcaster kann bei Bedarf Content-Delivery-Server anmieten.

Für einen �ächendeckenden Einsatz müssen allerdings in der Nähe jedes möglichen Emp-fängers Content-Delivery-Server eingesetzt werden, was sehr hohe Infrastrukturkostenverursacht. Die Dienstanbieter stoÿen auÿerdem bei stark nachgefragten Broadcasts andie Grenzen der möglichen Bandbreitenlieferung. 2009 zu Obamas Amtseinführung ver-lieÿ sich CNN daher nicht nur auf Dienstanbieter Akamai, sondern verteilte den Live-Stream auch per P2P. Von 1,3 Millionen gleichzeitigen Usern wurden jeweils 650.000 Userper CDN bzw. per P2P bedient [new09]. Akamai allein hätte die akkumulierte Bandbrei-te von ca. 495 Gbps (bei einer veranschlagten Streamingrate von 400 kbps) nicht zurVerfügung stellen können. Dazu kommen hohe Kosten, die Anbieter von CDNs für dieAnmietung der Server verlangen. [LGL08, LR+08, WLQ06]

2.5.2 Multicast über Internet

2.5.2.1 IP-Multicast

1990 schlug Deering vor, Multicast auf der IP-Schicht (Schicht 3 im ISO/OSI-Refe-renzmodell) zu implementieren [DC90]. Daraus entwickelte sich IP-Multicast (Native-IP-Multicast/Native-Multicast). Der Dienst von IP-Multicast besteht darin, Daten andie Teilnehmer einer Gruppe zu senden. Die Teilnehmer können sich mittels IGMP-Nachrichten (Internet Group Management Protocol [Fen97]) zu einer Gruppe an- undabmelden. Das setzt voraus, dass der erste Router, mit dem sich der Teilnehmer verbin-det, 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 Nachrichtenwerden zwischen den Router-Knoten wie bei Unicast weitergereicht. An den Blättern desRouterbaumes kopieren die Router die Nachrichten und verteilen sie an alle angemelde-ten Endknoten. Für die Errichtung des Multicast-Baumes gibt es verschiedene Routing-Protokolle, z.B. DVMRP (Distance-Vector-Multicast-Routing-Protocol [WPD88]) oderPIM-SM (Protocol Independent Multicast - Sparse Mode [EF+98]).

Trotz vieler Entwicklungen seit den 90er-Jahren ist IP-Multicast im Internet nicht weitverbreitet. Der Prozentsatz der IP-Multicast-fähigen autonomen Systeme im Internetstagniert seit Jahren unter 5% [MS07].

Die Gründe dafür sind technischer und wirtschaftlicher Natur. IP-Multicast-fähige Rou-ter müssen alle Zustände der Multicast-Gruppe speichern, was zu hoher Komplexitätund damit zu eingeschränkter Skalierung führt. Für IP-Multicast wird das Transport-protokoll UDP verwendet. Bei IP-Multicast handelt es sich also um einen Best-E�ort-Service. Dienste wie Fehlerkontrolle, Flusskontrolle oder Congestion-Control (Stauver-meidungsmechanismen) sind bei IP-Multicast im Gegensatz zu Unicast sehr schwierig

24


umzusetzen. Um IP-Multicast im Internet �ächendeckend einzusetzen, müssten auÿer-dem IP-Multicast-fähige Router bei allen Verbindungen zu den Endknoten installiertwerden. Die Nachfrage nach IP-Multicast durch Endkunden ist zudem gering. Daherist es für die Internet-Service-Provider wirtschaftlich nicht interessant, IP-Multicast zurVerfügung zu stellen und die hohen Kosten für Wartung und Kon�guration in Kauf zunehmen. [CRZ00, LR+08, MS07]

2.5.2.2 Application-Level-Multicast

Im Fokus dieser Arbeit stehen Systeme, die das Streamen über das Internet, also überPunkt-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 aufder 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 zwi-schen den Endsystemen aufgebaut werden.. Im Gegensatz zu IP-Multicast sind bei ALMdie Endsysteme für Multicast-Funktionalitäten zuständig. Sie kopieren Nachrichten, lei-ten Nachrichten weiter und übernehmen Aufgaben der Gruppenverwaltung.

Abbildung 2.4 stellt den Versand von Nachrichten bei IP-Multicast und ALM dar. DerSender S und die Empfänger (Hosts 1,2,3) sind jeweils über ein physisches Netzwerk mit-einander verbunden (siehe blaue Linie). Bei ALM existiert neben der physischen Verbin-dung ein Overlaynetzwerk (blau-gestrichelte Linie), das sich aufgrund von Partnerschafts-beziehungen zwischen den Hosts zusammensetzt. Bei ALM leitet Host 2 die Nachrichtdes Senders an Host 3 weiter. Auf einer unteren Protokollebene muss diese Nachrichtnatürlich auch über die physische Verbindung (über Router 2) verschickt werden.

IP-Multicast

Router 1 Router 2

S

1

2

3ALM

Router 1 Router 2

S

1

2

3

Abbildung 2.4: IP-Multicast und ALM (nach [BBK02])

Frühe Streaming-Systeme (ab 2000) auf Basis von ALM sind sogenannte Tree-basierteSysteme. 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) odererrichtet zuerst ein separates Overlaynetzwerk, über dem der eigentliche ALM-Baumliegt (Mesh-�rst-Ansatz). Bei diesem Overlaynetzwerk kann es sich um ein strukturiertesP2P-Substrat (z.B. CAN [RF+00], Pastry [RD01] oder Tapestry [ZKJ01]) handeln oderum ein unstrukturiertes P2P-Netzwerk mit einer zufälligen Verbindungsstruktur. Da sich

25

2.6. ZUSAMMENFASSUNG KAPITEL 2. STREAMING

die Peers in dem P2P-Netzwerk untereinander verbinden und dabei - im Unterschied zumBaum - 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 physischenInternet miteinander verbunden. Die Verteilung des Streams erfolgt hier nicht über einenfest aufgebauten ALM-Baum, sondern über dynamische Routen, die je nach Datenver-fügbarkeit wechseln können. Dadurch werden implizit Multicast-Bäume erstellt, die sichständig verändern können. Eine weitere Besprechung von Tree- und Mesh-basierten Sys-temen folgt in Abschnitt 4.2.2.

Im Gegensatz zu IP-Multicast ist der Einsatz von ALM an keine Infrastrukturanpassun-gen gebunden und diesbezüglich kostengünstiger. Protokollmodi�kationen können einfachin der Anwendungsschicht vorgenommen werden. Allerdings zeichnet sich IP-Multicastdurch höhere E�zienz aus. Bei ALM übernehmen die Endhosts die Funktion der Router,wissen aber nichts oder nur wenig über die physische Netzwerktopologie und verschickenNachrichten daher weniger e�zient, d.h. mit gröÿeren Ende-zu-Ende-Verzögerungen. Dabei ALM die Endhosts auch Aufgaben der Gruppenverwaltung übernehmen, führt dieszu höherem Overhead und höherer Komplexität auf den Endhosts. [HA+06]

Abschlieÿend sollen die Begri�e ALM und P2P-Streaming voneinander abgegrenzt wer-den. Beim P2P-Streaming laden Endsysteme den Stream herunter und leiten ihn weiter.P2P-Streaming kann über eine ALM-Architektur realisiert werden, d.h. durch Implemen-tierung von Multicast auf der Anwendungsschicht. P2P-Streaming-Systeme, die Live-oder Video-On-Demand-Inhalte vielen Empfängern zur Verfügung stellen, basieren inder 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 keinMulticast einsetzen, siehe IP-Telefonie zwischen zwei Hosts mit Skype. Hier werden zwarAudiodaten über ein P2P-Netzwerk gestreamt und weitergeleitet, konzeptionell handeltes sich aber um eine Unicast-Verbindung zwischen zwei Teilnehmern.

In der P2P-Literatur werden folgende Begri�e 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-Verbindun-gen handelt (siehe Abschnitt 2.4). Dennoch ist die Bezeichnung Broadcast in diesem Zu-sammenhang gebräuchlich. Wenn ein Einsatzzweck von ALM im Vordergrund steht, wirdstatt 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 verschiedenenPerspektiven heraus erläutert. Dabei wurden zunächst die gestreamten Daten und ih-re Kodierungen betrachtet. Dann wurden der Unterschied zwischen echtem Streaming

26

2.6. ZUSAMMENFASSUNG KAPITEL 2. STREAMING

(True-Streaming) und Pseudo-Streaming herausgestellt und mögliche Anwendungen, Ver-bindungsarten und Architekturen behandelt.

Der Schwerpunkt dieser Arbeit liegt auf Live-Streaming (also echtem Streaming) überP2P für Web-TV-Anwendungen. Sobald Daten empfangen werden, erfolgt beim Live-Streaming deren Wiedergabe. Der Sender und die Empfänger verbinden sich per Multi-cast. Dabei wird Multicast auf der Anwendungsebene (als ALM) implementiert. Es kön-nen verschieden kodierte Audio- und Videodaten gestreamt werden. Deren Kodierungund 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 Systemenam häu�gsten unterstützten Formate sind Windows Media von Microsoft sowie - beiälteren Systemen - RealMedia von RealNetworks. [cha07, cha09, Sim08]

27

3 P2P-Streaming

Im vorherigen Kapitel habe ich die Grundlagen des Streamings erläutert. Für das Kernthe-ma 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 o�ensicht-lichen Zusammenhang, dass sich die Peers in beiden Systemen Ressourcen teilen, hatder Bereich P2P-Streaming einige Algorithmen und Protokolle aus P2P adaptiert. Einchronologischer Überblick wird in Abschnitt 3.2 gegeben.

Streaming in P2P-Netzen erfolgt nach den Methoden Live und Video-On-Demand. Derengrundlegende Konzepte werden am Ende dieses Kapitels vorgestellt.

3.1 P2P

3.1.1 Begri�sklärung

P2P ist die Kurzform von Peer-to-Peer und abgeleitet vom englischen Wort �peer�, daseinen �Gleichrangigen� oder �Ebenbürtigen� bezeichnet.

In der P2P-Forschung gibt es keine klare, einheitlich verwendete De�nition von einemP2P-System bzw. einem P2P-Netzwerk. Nach Mahlmann et al. hat man sich in etwadarauf geeinigt, dass ein �P2P-Netzwerk ein Overlay-Netzwerk des Internets ist, bei demdie Rechner ebenbürtig ohne zentrale Koordination kommunizieren und gemeinsam eineAnwendung zur Verfügung stellen� [MS07]. In diesem Satz werden alle wichtigen Eigen-schaften von P2P angeschnitten: Dezentralisierung, Kooperation, Ressourcenverteilungsowie autonome und gleichberechtigte Peers. Die Peers agieren als �Servents� (Kunstwortaus �Server� und �Clients�). Sie fordern nicht nur Daten an, sondern liefern im Unterschiedzum 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 nichtzu dem Problem des Server-Flaschenhalses und das System skaliert besser. Durch dasFehlen einer Serverstruktur minimieren sich die Anforderungen an die Infrastruktur unddamit 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. Allerdingsarbeiten nicht alle P2P-Systeme gleichermaÿen dezentralisiert und weisen somit nichtalle 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 verteil-te 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

3.1. P2P KAPITEL 3. P2P-STREAMING

3.1.2 Klassi�zierung von P2P-Systemen

P2P-Systeme kann man klassi�zieren, indem man prüft, wie stark die Inhalte und In-haltsbeschreibungen (z.B. Dateinamen, Meta-Informationen) strukturiert sind und wiesehr die Peers voneinander abhängen.

In strukturierten oder stra� strukturierten P2P-Systemen stehen die Inhalte in Relationzu den Knoten, die für diese Inhalte zuständig sind. Eine wohlde�nierte Hash-Funktionbildet z.B. den Dateinamen auf die P2P-Netzwerkadresse des für die Datei zuständigenKnotens ab. Daher spricht man hier von Systemen, die auf DHTs (Distributed-Hash-Tables) basieren. Diese Systeme werden in der P2P-Literatur auch als Content-orientiertbzw. Content-adressierbar bezeichnet oder als Systeme mit Content-basiertem Routingbzw. mit Content-adressierbarer Datenhaltung. Da die Topologie ständig aufrechterhal-ten werden muss, entstehen hohe Wartungskosten bei hohem Peer-Churn, d.h. wenn oftneue Peers ins Netz kommen und verbundene Peers das Netz wieder verlassen.

Unstrukturierte oder locker strukturierte P2P-Systeme sehen keine Relation zwischenInhalten und Knoten vor. Die Suche nach den Dateien erfolgt zentralisiert oder überFlooding, d.h. durch Broadcast an alle Peers im P2P-Netzwerk bis zum Ablauf einerTime-To-Live (TTL). Die Protokolle erzeugen einen zufälligen Verbindungsgraph, des-sen 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-Churnbeeinträchtigt das Gesamtsystem hier kaum.

Hierarchische oder hybride P2P-Systeme zeichnen sich dadurch aus, dass bestimmtenKnoten mehr Verantwortung zufällt als anderen. Diese Knoten übernehmen entwederalle Aufgaben (wie die statischen Server bei Napster), wobei man hier von zentrali-siert indexierenden Systemen spricht. Oder dynamische Einheiten (Super-Nodes/Super-Peers/Ultra-Peers) übernehmen einen gröÿeren Teil der Aufgaben. Diese Systeme werdenals verteilt indexierend bezeichnet. [E�08, MS07, PBV05, SW05]

Die Tabelle 3.1 stellt die möglichen Klassi�zierungen von P2P-Systemen und deren Vor-und Nachteile dar. Die P2P-Systeme werden dabei nach den oben genannten Aspektender Strukturierung (strukturiert oder unstrukturiert) und Hierarchie (rein dezentrali-siert oder hybrid) in vier Gruppen eingeteilt und anhand ihrer Eigenschaften verglichen.Insbesondere werden die Skalierbarkeit1, Robustheit2 und Flexibilität der Systeme be-trachtet. Flexibilität bedeutet hier, dass die Peers sich vollständig autonom verhaltenkönnen, sich nach Belieben mit dem Netz verbinden sowie dieses wieder verlassen kön-nen. In strukturierten P2P-Netzwerken werden den Peers IDs und die Verantwortung fürInhalte zugeteilt, wodurch nach dem Peer-Abgang eine Umorganisation notwendig unddie Flexibilität somit eingeschränkt ist.

1Skalierbarkeit bezeichnet die Fähigkeit eines P2P-Netzwerks, sich an eine quantitativ wachsende An-zahl von Peers und/oder Daten anzupassen [Wol10] (siehe auch Abschnitt 4.4.1).

2Robustheit beschreibt die Eigenschaft eines Netzwerks, auch unter hoher Last und bei Fehlern (z.B.Ausfällen der Netzwerkstruktur) ein spezi�ziertes Leistungsniveau zu erhalten [Wol10] (siehe auchAbschnitt 4.4.1).

29

3.1. P2P KAPITEL 3. P2P-STREAMING

unstrukturiertundrein

dezentralisiert

strukturiertundrein

dezentralisiert

unstrukturiertundhybrid

(zentralisiertindexierend)

unstrukturiertundhybrid

(verteiltindexierend)

Skalierbar

nichtgutskalierbar

aufgrunddes

Nachrichten-

Overheads

janichtskalierbarwegen

Server-Flaschenhals

ja

Robust

jaja

nein,daServer

Single-Point-of-Failure

ja,fallsSuper-

Nodes/-Peers

redundant

Flexibel

jaweniger

�exibel,danach

Peer-Abgang

Umorganisationder

Daten

erforderlich

ist

nein

ja

Eigenschaften

der

Suche

-Sucheweniger

e�zient,

vorallem

beiseltenen

Dateien

-False-NegativesbeiSuche

möglich

-e�

ziente

Suchemitmeist

logarithmischer

Suchkomplexität

-Fuzzy-Queries(ungenaue

Suche)

nichtmöglich

-e�

ziente

Suchemit

konstanterSuchkomplexität,

daAnfragendirektan

Servergerichtetwerden

-Fuzzy-Queriesmöglich

Suchee�

zienteralsbeirein

unstrukturierten

P2P-Systemen

Sonstiges

Durchdiegleichmäÿige

Verteilungder

Aufgabenauf

allePeers

wirdderen

Heterogenität(z.B.bzgl.

Bandbreite)nicht

berücksichtigt.

Durchdiegleichmäÿige

Verteilungder

Aufgabenauf

allePeers

wirdderen

Heterogenität(z.B.bzgl.

Bandbreite)nicht

berücksichtigt.

Beispielsystem

Gnutella0.4

CAN,Chord,Pastry

Napster

Gnutella0.6,FastTrack

Tabelle3.1:Klassi�zierungvonP2P

-Systemen

undVergleich

ihrerEigenschaften

[PBV05,SW

05]

30

3.2. ZUSAMMENHANG KAPITEL 3. P2P-STREAMING

3.2 Chronologischer Zusammenhang zwischen P2P undP2P-Streaming

Beim Streaming werden Audio- und/oder Videodaten über ein IP-Netzwerk kontinuier-lich übertragen und verwertet. Beim Streaming auf P2P-Basis agieren die Endsystemezudem 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 Abschnitt2.5.2.2).

Die ersten P2P-Streaming-Protokolle wurden im Jahr 2000 verö�entlicht. Diese Proto-kolle (z.B. Overcast [JG+00]) errichten einen statischen Multicast-Baum mit der Quelleals 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 Strukturerweitern, indem sie zusätzlich zum Multicast-Baum ein eigenes P2P-Netzwerk aufbau-en. Das zusätzliche Overlay sorgt für gröÿere Stabilität des Systems. Beim Ausfall desVaterknotens wird ein Peer z.B. nicht gänzlich vom System getrennt, sondern ist im-mer noch mit den anderen Nachbarn im P2P-Overlay verbunden. Das vereinfacht dieSuche nach einem neuen Vaterknoten für den Peer und somit allgemein die Repara-turmaÿnahmen des Systems bei Peer-Churn. Je nach P2P-Streaming-Protokoll werdenüber das P2P-Netzwerk unterschiedliche Arten von Daten übertragen. In der Regel dientdas P2P-Netzwerk jedoch zum Austausch von Kontrollnachrichten (z.B. Nachrichten zumGruppenstatus oder zur Datenverfügbarkeit) und der Multicast-Baum zur Verteilung dereigentlichen Streamdaten (Video-/Audiodaten). Es lässt sich sehr gut beobachten, wiesich ab dem Jahr 2000 die Entwicklungen im P2P-Bereich jeweils auf die Erforschung neu-er 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 chronologischeAu�istung 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 entwedervor (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 (insbesondereCAN [RF+00], Pastry [RD01], Tapestry [ZKJ01]) regen das Design von P2P-Strea-ming-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

3.3. GRUNDLEGENDE KONZEPTE KAPITEL 3. P2P-STREAMING

2004 Sogenannte Mesh-basierte P2P-Streaming-Systeme verzichten ganz auf den expli-ziten Aufbau von Multicast-Bäumen. Die Peers sind in einem zufällig erzeugtenP2P-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 Strea-ming (True-Streaming), das im vorherigen Kapitel vorgestellt wurde (siehe Abschnitt2.3). Dabei werden die Daten unmittelbar nach dem Empfang wiedergegeben. Manunterscheidet hier zwei wesentliche Methoden, Live-Streaming und Video-On-Demand-Streaming. Beim Live-Streaming werden analog zum klassischen TV-Broadcast die In-halte zu einem festen Zeitpunkt gesendet. Alle Benutzer empfangen den gleichen Streammehr oder weniger zum gleichen Zeitpunkt. Beim Video-On-Demand-Streaming hinge-gen bestimmt der Benutzer selbst den Zeitpunkt der Wiedergabe. Die grundlegendenKonzepte dieser beiden Methoden werden im Folgenden vorgestellt.

3.3.1 Video-On-Demand-Streaming

Ein Video-On-Demand-Benutzer sucht sich zuerst ein Video des Streaminganbieters ausund fordert es an. Er empfängt den Videostream dann asynchron, also nicht gleichzei-tig mit den anderen Empfängern des Videos. D.h. die Empfänger schauen sich jeweilsverschiedene Teile des Videos an. Der Benutzer kann den Video-On-Demand-Stream an-halten 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 realisiertwerden kann:

Tree-basiert

Beim Tree-basierten P2P-Video-On-Demand (wie bei P2Cast [GS+03]) werden die Usernach dem Zeitpunkt ihres Eintre�ens in Sitzungen eingeteilt. Der Quellserver und dieBenutzer einer Sitzung bilden zusammen einen ALM-Baum, über den der gesamte Streamverteilt wird.

Cache-And-Relay

Cache-And-Relay beruht darauf, dass ein Peer den Stream herunterlädt und dabei denjeweiligen Datenbereich (Moving-Window genannt) cacht. Er bedient aus seinem Cacheandere Empfänger, die Videodaten aus seinem Moving-Window anfordern. DirectStream[GS+07] wendet z.B. diese Technik an.

32


Mesh-basiert

In einem Mesh-basierten P2P-Video-On-Demand-System (wie BiToS [VIF06]) wird dasVideo zuerst in kleine Datenblöcke zerlegt und dann vom Server an mehrere User ver-teilt. Die Benutzer laden immer die Blöcke von ihren Nachbarn herunter, die sie nichthaben. Diese Technik wurde zuerst für die Verteilung groÿer Dateien entwickelt (sieheBitTorrent) und dann erfolgreich für Video-On-Demand-Streaming und vor allem fürLive-Streaming übernommen. [E�08, LGL08]

3.3.2 Live-Streaming

Beim Live-Streaming wählen die Benutzer zunächst einen Kanal des Streaming-Anbie-ters aus. Nach einer anfänglichen Verzögerung empfangen sie zusammen mit allen anderenBenutzern, die diesen Kanal gewählt haben, die gleichen Daten zum mehr oder wenigergleichen 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 bisfünf Minuten betragen [OJ08].

Seit dem Jahre 2000 wurde ein sehr groÿe Anzahl von P2P-Live-Streaming-Protokollenentwickelt, die sich in vielen Details unterscheiden (siehe dazu auch Kapitel 4). DerLive-Stream wird in diesen Protokollen entweder über einen oder mehrere explizit auf-gebaute Bäume verteilt. Diese Protokolle nennt man daher Tree-basiert (je nach Anzahlder Bäume Single-Tree oder Multi-Tree). Oder die Verteilung des Streams erfolgt überdynamische Routen innerhalb des P2P-Netzwerkes (dem Mesh).

Mesh-basierte Systeme sind in der Regel einfacher zu implementieren und aufgrundder dynamischen Datenverteilungswege robust bei Peer-Churn. So gut wie alle kommerzi-ellen P2P-Streaming-Systeme sind Mesh-basiert. Auch das im Mittelpunkt dieser Arbeitstehende 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 einzelneTeile, die Segmente, Blöcke oder Chunks genannt werden. Diese Segmente werden einzelnverschickt und können über unterschiedliche Pfade im Netzwerk transportiert werden.Die empfangenen Segmente setzt der Peer in seinem Pu�er zusammen und übergibtsie sortiert an den Player zur Wiedergabe. Der Inhalt des Pu�ers kann in Form einersogenannten Bu�ermap dargestellt werden (siehe Abbildung 3.1).

ID des 1.Puffersegments (Offset)=35

Buffermap mit Offset=35

Puffer35 36 37 39

01 1 1 01 0 0 0

Abbildung 3.1: Pu�er und dazugehörige Bu�ermap

33


In Abbildung 3.1 hat der Peer bereits die Segmente mit der ID 35,36,37,39,41 erhaltenund in seinem Pu�er sortiert gespeichert. In der Bu�ermap werden diese vorhandenenSegmente durch eine �1� repräsentiert, alle noch nicht erhaltenen Segmente durch eine�0�. Die ID des ersten Segments im Pu�er (im obigen Beispiel 35) wird O�set genannt.Anhand der Bu�ermap eines Pu�ers und des dazugehörigen O�sets kann man leichtermitteln, welche Segmente in diesem Pu�er vorliegen.

In Mesh-basierten Systemen tauschen die Peers regelmäÿig Bu�ermaps mit ihren Nach-barn im Netzwerk aus. Dadurch erfahren sie, welche Segmente der Nachbar hat undkönnen diese explizit bei ihm anfordern. Der Peer mit dem Pu�er aus Abbildung 3.1benö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-Strea-ming vorgestellt, vor allem auch im Hinblick auf das CoolStreaming-Protokoll. Die Ana-lyse des CoolStreaming-Protokolls folgt im Kapitel 4.

34

4 Analyse

In den vorangegangenen Kapiteln wurden Streaming, P2P-Streaming und die Beson-derheiten beim P2P-Live-Streaming erläutert. In diesem Kapitel wird das P2P-Live-Streaming-Protokoll CoolStreaming analysiert. Die Analyse von Protokollen kann theo-retisch 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 Analyseangewandt.

Es werden zunächst die Gemeinsamkeiten von P2P-Live-Streaming-Protokollen anhandeines allgemeinen Prozessmodells hervorgehoben. Aus diesem Prozessmodell lassen sichdie Unterscheidungsmerkmale von P2P-Live-Streaming-Protokollen ableiten, so dass dar-auf aufbauend die Analyse des CoolStreaming-Protokolls erfolgen kann. Die Protokoll-charakteristiken von CoolStreaming werden denen anderer Protokolle gegenübergestelltund daraufhin bewertet. Dabei weise ich auch auf die verschiedenen Terminologien hin,um so zugleich einen systematischen Überblick über P2P-Live-Streaming-Protokolle dar-zulegen. Dann werden die Ergebnisse von Performance-Messungen des CoolStreaming-Protokolls aus diversen P2P-Streaming-Arbeiten vorgestellt. Es folgt eine Analyse desCoolStreaming-Verbindungsgraphen. Das Kapitel endet mit einer Zusammenfassung derErgebnisse.

4.1 Allgemeines Prozessmodell für P2P-Live-Streaming

Die Schwierigkeit beim P2P-Live-Streamingprozess besteht darin, dass sich neue Knotenmit den Peers im P2P-Streaming-Netz so verbinden, dass sie die gewünschten Inhaltemit geringstmöglicher Verzögerung beziehen können.

In [GZ+09] wurde dazu ein allgemeines Prozessmodell für P2P-Live-Streaming-Systemevorgestellt. In jedem Schritt des Prozessmodells werden jeweils die Streamverteilungin Tree-basierten und in Mesh-basierten Systemen berücksichtigt. Aus den einzelnenSchritten 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 eineListe mit potentiellen Vaterknoten (Tree), die ihm den gewünschten Stream wei-terleiten können, bzw. eine Liste mit Peers (Mesh), mit denen er die Streamdatenaustauschen kann.

2. Der Peer schickt eine Anfrage an alle potentiellen Vaterknoten, um als Sohnknotenangenommen zu werden (Tree). Im Mesh verbindet sich der Peer mit anderen Peers,

35

4.2. PROTOKOLLCHARAKTERISTIKEN KAPITEL 4. ANALYSE

um Informationen über die Datenverfügbarkeit auszutauschen. Dies geschieht in derRegel in Form von sogenannten Bu�ermaps, bei denen der lokale Pu�erinhalt alsBit-String oder Bitmap dargestellt wird. In einer Bu�ermap werden vorhandeneSegmente durch eine �1� repräsentiert, nicht vorhandene durch eine �0�.

3. Der Peer hat einen Vaterknoten gefunden (Tree) bzw. ermittelt anhand der Bu�er-maps 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 seinenNachbarn aktiv an (Mesh).

Die oben genannten Punkte geben die wesentlichen Charakteristiken vor, nach denensich Live-Streaming-Protokolle unterscheiden: in Bezug auf den Join-Vorgang (1), dieGruppenverwaltung inklusive dem Aufbau von Partnerschaften (2,3) und die Art derStreamverteilung (4). Im folgenden Abschnitt gehe ich näher auf diese Charakteristikenein.

4.2 Charakteristiken eines P2P-Live-Streaming-Protokolls

In diesem Abschnitt werden die wesentlichen Charakteristiken von CoolStreaming mitdenen anderer P2P-Live-Streaming-Protokolle verglichen. Viele P2P-Streaming-Abhand-lungen unterscheiden die Protokolle hauptsächlich aufgrund der errichteten Topologie(siehe 4.2.2). Dieses Kriterium allein reicht nicht aus, um die Funktionsweise der komple-xen Protokolle analysieren zu können. Deshalb werden weitere Unterscheidungsmerkmalevorgestellt wie der Join-Vorgang, die Art der Streamverteilung, die Gruppenverwaltung,Fehlerkorrekturmechanismen und die verwendeten Transportprotokolle.

4.2.1 Join

Ein neuer Benutzer hat einen Kanal des P2P-Streaming-Anbieters ausgewählt und wen-det sich an den entsprechenden Einstiegsknoten im Netz. Dies kann direkt die Quelle(der Broadcaster) sein, ein de�nierter Bootstrap-Node oder die DHT-Struktur. In starkfrequentierten Netzen wendet sich der Knoten an einen Tracker, der ihn wiederum anSuper-Nodes weiterleitet.

Der neue Peer erhält vom Einstiegsknoten eine Liste mit möglichen Partnern oder Vater-knoten, wobei in Tree-basierten Systemen in der Regel darauf geachtet wird, dass es sichbei den Vaterknoten um Blattknoten oder innere Knoten mit ausreichenden Uploadka-pazitäten handelt.

Bei Mesh-basierten Protokollen werden die Partnerkandidaten entweder zufällig ausge-wählt (wodurch das Overlay-Netz ebenfalls zufällig aufgebaut wird) oder es wird diegeographische Nähe im Netz berücksichtigt (sogenannte Location-Aware-Ansätze). Hy-bride Ansätze kombinieren die zufällige Auswahl von Partnerkandidaten mit Location-Awareness. Je nach Ansatz variiert die Verbindungsstruktur der Peers. Abbildung 4.1zeigt die Topologien, die je nach Wahl der Partnerkandidaten entstehen, und zwar fürein Netz mit 20 Peers und 4 Partnern pro Peer.

36


Abbildung 4.1: Verbindungsstruktur bei zufälliger Partnerwahl (links), bei Wahl mit Be-rücksichtigung der Location-Awareness (Mitte) und bei dem hybridenAnsatz (rechts) [CL+10]

CoolStreaming sieht in [ZL+05] zwar vor, dass jeder Peer im Netz durch regelmäÿigeNachrichten seine Partneranzahl bekannt gibt, so dass die Quelle auf diese Informationzugreifen könnte, aber laut Spezi�kation werden die Partnerkandidaten für einen neuenPeer rein zufällig ausgewählt.

Über die Anzahl der vorgeschlagenen Partnerkandidaten liefern die Protokolle keine In-formationen. [ZL+05] gibt für CoolStreaming allerdings vor, dass ein neuer Peer allevorgeschlagenen Partnerkandidaten kontaktiert, um Partnerschaften aufzubauen. Daherreicht es hier aus, dem neuen Peer zunächst die Adressen von so vielen Partnerkandi-daten zu schicken, zu denen er gemäÿ der empfohlenen maximalen Partneranzahl (4-6bei CoolStreaming) auch eine Verbindung aufnehmen kann. Werden seine Partneranfra-gen abgelehnt, so kann er später im Rahmen der regelmäÿigen Overlaywartung weiterepotentielle 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 eineStartkon�guration implementiert werden.

4.2.2 Topologie der Streamverteilung

CoolStreaming ist ein Mesh-basiertes Protokoll, d.h. der Stream wird über dynamischeRouten im Mesh verteilt. Tree-basierte Protokolle verteilen den Stream dagegen übereinen oder mehrere explizit aufgebaute Multicast-Bäume. Man spricht in diesem Zu-sammenhang von Single-Tree- bzw. Multi-Tree-Protokollen. Im Folgenden werden dieEigenschaften 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 ver-teilten. Die Bandbreite der Blätter blieb bei diesen Systemen ungenutzt. Zusätzlich zumBaum konnte ein Mesh-Netz aufgebaut werden, über das z.B. Nachrichten zur Grup-penverwaltung verschickt wurden. Sanjay G. Rao und Hui Zhang bezeichneten dieseArchitektur (Multicast-Baum über einem P2P-Overlay) als ESM (Kurzform von End-System-Multicast). Sie entwickelten Narada als eines der ersten Protokolle, das ESMrealisierte [CR+02, CRZ00].

37


Multi-Tree (Multiple-Tree, Forest-based) Um die Bandbreite in Tree-basierten Syste-men besser nutzen zu können, wurden Multi-Tree-Systeme entwickelt, auch Multiple-Treeoder Forest-based [WLQ06] genannt. Hier werden mehrere, sich überlagernde Bäume zurDatenverteilung aufgebaut. Ein Peer, der in einem Baum ein Blatt ist, kann in den an-deren Bäumen ein innerer Knoten sein und somit seine Uploadbandbreite zur Verfügungstellen.

Bei Multiple-Tree-Systemen verbinden sich die Peers in der Regel zuerst in einem struk-turierten oder unstrukturierten Netzwerk, über dem dann die Bäume errichtet werden.Die Quelle kodiert den Stream in einzelne Teilstreams (Substreams) und versendet je-den Substream über einen anderen Baum. Fällt ein Vaterknoten aus, erhalten alle seineNachfahren in diesem Baum keine Daten, können aber aus den bereits erhaltenen Sub-streams den Originalstream rekonstruieren. Die Kodierung erfolgt auf Basis von Multiple-Description-Coding (siehe Abschnitt 4.2.5.1), ein sehr komplexes Verfahren, dass von dengängigen Mainstream-Playern bisher nicht unterstützt wird [LR+08].

Mesh (Unstrukturiert, Data-driven/Datengesteuert, Swarming-based) Bei Mesh-ba-sierten 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 verbun-den (siehe Overlay-Layer in Abbildung 4.2) und fordern von ihren Partnern die fehlen-den Streamsegmente an. Dadurch werden die Streamsegmente über dynamische Rou-ten im Mesh übertragen und implizit dynamische Multicast-Bäume aufgebaut (sieheDistribution-Layer in Abbildung 4.2).

Abbildung 4.2: Mesh-Overlay-Schicht (Overlay Layer) und Datenverteilungsschicht (Dis-tribution Layer) in einem P2P-Streaming-Netzwerk [CLB07]

In Mesh-basierten Systemen müssen die Partner regelmäÿig Bu�ermaps austauschen,um ihren Pu�erinhalt zu kommunizieren. Durch den Versand von Bu�ermaps und vonDatenanforderungen ist der Kontrolloverhead (d.h. der Anteil der Kontrolldaten an denVideodaten, siehe Abschnitt 4.4.2) höher als in Tree-basierten Systemen. Auch dauert esim Unterschied zu Tree-basierten Systemen länger, bis die Daten empfangen und abge-spielt werden können, d.h. die Verzögerungen sind gröÿer (siehe Abschnitt 4.4.2). Dafürsind Mesh-basierte Systeme sehr robust bei Peer-Churn.

38


Mischformen Bullet [KR+03] implementiert einen hybriden Mesh-/Tree-Ansatz. DasProtokoll baut zuerst einen Verteilungsbaum auf und darüber ein zufällig verbundenesMesh. Über den Baum werden zunächst die Daten übertragen (Stream, Kontrollnach-richten). Fehlende Streamdaten können die Knoten über das Mesh anfordern. Nach demBaumaufbau wählt die Quelle eine zufällige Menge von Söhnen aus, zerlegt den Streamin mehrere Blöcke und verschickt disjunkte Untermengen des Streams an die Söhne. DieSöhne reichen wiederum disjunkte Untermengen durch den Baum weiter. Jeder Sohn-knoten kann als die Wurzel eines Unterbaums betrachtet werden, weshalb Bullet mit-unter auch als Multi-Tree klassi�ziert wird (siehe [LGL08, Liu07]). In [VFC06] sprechenVenkataraman 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 vonzwei benachbarten Knoten jeweils einer der Sender und einer der Empfänger ist. Analogzu Multi-Tree-Systemen kodiert die Quelle den Stream in Substreams. In der erstenPhase (Di�usion-Phase) werden die Peers anhand der Verbindungsstruktur im Netzwerkin 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.

4.2.3 Art der Streamverteilung

Bei CoolStreaming fordern die Peers die benötigten Streamdaten explizit an, d.h. dieDaten werden per Pull verteilt. In anderen Systemen können die Daten auch per Pushverbreitet werden. Im Folgenden erkläre ich die Unterschiede zwischen diesen beidenMechanismen der Streamverteilung:

Push/Sender-driven Der Sender schickt die Daten an den Empfänger, ohne dass derEmpfänger diese Daten vorab anfragt. Der Sender weiÿ hier nicht, welche Segmente derEmpfänger braucht.

Pull/Receiver-driven Der Empfänger holt sich die benötigten Daten, indem er die Da-ten beim Sender anfordert und der Sender diese ihm schickt (wie bei CoolStreaming). Dassetzt voraus, dass der Empfänger weiÿ, welche Daten der Sender im Pu�er hat. Vorabmuss der Sender seinen Pu�erinhalt in Form von Bu�ermaps kommunizieren.

In Push-basierten Systemen gibt der Sender nur so viele Daten weiter, wie es ihm dieBandbreite erlaubt. In Pull-Systemen können von einem Sender mehr Daten angefordertwerden, als dieser hochladen kann. Das Protokoll muss also in Pull-basierten SystemenBeschränkungen vorsehen, um eine Überlastung der Senderkapazität zu verhindern.

Nachfolgend gehe ich auf die Besonderheiten von Push-basierten und Pull-basierten Sys-temen ein und stelle Systeme vor, die beide Mechanismen implementieren.

39


4.2.3.1 Push

In Single-Tree-basierten Systemen (siehe 4.2.2) verteilen die Vaterknoten den Stream perPush an die Söhne. Eine niedrige Uploadbandbreite eines Vaterknotens verringert dieStreamingrate für alle seine Nachfahren.

In Multi-Tree-Systemen (siehe 4.2.2) werden die Daten ebenfalls per Push von den Vater-knoten 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 Kno-ten seine Uploadbandbreite beitragen. Die Peers erhalten in einem Multi-Tree-Systemnicht den gesamten Stream, sondern nur eine Teilmenge, aus der sie den Originalstreamrekonstruieren können. Dazu kodiert die Quelle den Originalstream in einzelne Substre-ams mittels Multiple-Description-Coding (siehe Abschnitt 4.2.5.1). Jeder Substream wirdper Push über einen anderen Baum verteilt. Die Empfänger dekodieren die erhaltenenDaten, um den Originalstream wiederherzustellen.

4.2.3.2 Pull

In der P2P-Streaming-Literatur �nden sich bezüglich dieses Begri�es Abweichungen undWidersprüchlichkeiten, auf die ich hinweisen möchte:

Nach [CRC08] kennt ein Empfänger beim reinen Pull den Pu�erinhalt des Senders nicht.Es ist also möglich, dass er die benötigten Daten genau bei den Sendern anfordert, die sienicht liefern können, wodurch der Empfänger �verhungern� kann. Erst bei der in [CRC08]Status-basiert genannten Verteilung tauschen Sender und Empfänger Informationen überihren Pu�erinhalt aus. Im Gegensatz dazu beinhaltet für die meisten Autoren die Pull-Verteilung jedoch bereits den regelmäÿigen Austausch der Verfügbarkeitsinformationenmittels Bu�ermaps.

In [MRG07] wird das Protokoll PRIME vorgestellt, bei dem der Empfänger Daten perPull bezieht. Magharei et al. sprechen von einem Push-Pull-Ansatz, da die Verfügbar-keitsinformationen von den potentiellen Sendern gepusht werden und die benötigten Seg-mente per Pull angefordert werden. Auch dies weicht von der allgemeinen De�nition für�Pull� ab und hat leider dazu geführt, dass PRIME in einigen vergleichenden Arbeitenfälschlicherweise als Push-Pull-Protokoll eingeordnet wurde.

Sehr viele kommerzielle P2P-Live-Streaming-Systeme wie CoolStreaming, PPLive undUUSee basieren auf einer Mesh-Pull-Architektur, was u.a. darauf zurückzuführen ist, dasses sich um ein einfaches, gut strukturiertes Verfahren handelt, das sich mit den gängi-gen Client-Playern einsetzen lässt. Zu den bekannten Vertretern der nicht-kommerziellenMesh-Pull-Protokolle gehört Chainsaw [PK+05].

4.2.3.3 Hybrides Push-Pull

Um die Nachteile von reinen Push-Protokollen (Anfälligkeit bei Peer-Churn aufgrundder explizit aufgebauten Multicast-Bäume) und reinen Pull-Protokollen (hoher Kontrol-loverhead und lange Abspielverzögerungen) abzuschwächen, sehen neuere Ansätze dieKombination von Push und Pull vor.

40


In [RC08] schlagen Russo et al. vor, die aktuellsten Datensegmente per Push an einezufä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 sieper 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 Peerfragt zunächst explizit nach Bu�ermaps. Nach erfolgreichem Pull eines Pakets abonniertder 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 gepushtwerden, fordert er keine Bu�ermaps an. Stehen mehr als 5% der Push-Pakete aus, gehtder Peer wieder zum Pull über, fordert Bu�ermaps an und zieht die Daten.

4.2.4 Gruppenverwaltung

Bei IP-Multicast (siehe Abschnitt 2.5.2.1) übernehmen die Multicast-fähigen Router Auf-gaben der Gruppenverwaltung. Die Router bilden einen Multicast-Baum, verwalten dieMitglieder der Gruppe und verteilen den Stream an die Mitglieder. Bei ALM (siehe Ab-schnittt 2.5.2.2) erfolgt dies auf der Anwendungsschicht. Die Quelle und die Peers bildenden Multicast-Baum. Die P2P-Streaming-Protokolle geben dabei vor, wie der Multicast-Baum errichtet wird (implizit oder explizit), wie die Struktur bei Peer-Churn aufrechter-halten 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 entwe-der zentral verwaltet wurde (wie bei CoopNet [PW+02]), durch hierarchische Cluster-Strukturen (NICE [BBK02], ZIGZAG [THD03]) oder mittels verteilter Algorithmen(DHT oder Mesh).

4.2.4.1 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 mitihnen regelmäÿig Bu�ermaps aus. Diese Sender werden Partner (wie bei CoolStreaming)oder Nachbarn (wie bei den meisten anderen Systemen) genannt. Die Anzahl der Partnervariiert je nach System. CoolStreaming erzielt laut [ZL+05] optimale Ergebnisse bei 4bis 6 Partnern. Nach [MR06] kann die Partneranzahl in Mesh-basierten Systemen zwi-schen 6 und 14 liegen, um eine hohe und aktuelle Lieferqualität zu gewährleisten. BeiChainsaw [PK+05] hält der Peer eine minimale Partneranzahl aufrecht, lehnt aber einge-hende Partneranfragen nie ab. Da mit steigender Partneranzahl die Uploadkapazität proPartner sinkt, könnte meiner Meinung nach der Peer seine maximale Partneranzahl vonseiner verfügbaren Uploadbandbreite abhängig machen, was in den hier besprochenenSystemen nicht realisiert wurde.

41


Peers können zu ihren Partnern Informationen wie das von ihnen erhaltene Datenvolumenspeichern (siehe CoolStreaming, PRIME [MRG07]), woraus sich deren Uploadbandbreiteschätzen lässt.

4.2.4.2 Verwaltung der Gruppenmitglieder

Fällt der Datenlieferant eines Peers aus (d.h. der Vaterknoten im Tree-basierten Sys-tem oder der Partner im Mesh-basierten System), sollte der Peer möglichst schnell einenErsatzsender �nden. Daher muss er andere Knoten im Netzwerk kennen, mit denen ersich verbinden kann. Dies kann entweder zentralisiert, implizit durch die Struktur oderdurch gezieltes Membership-Management (auch Knowledge-Management [Pia07]) erfol-gen. Die Ansätze, nach denen die Gruppenmitglieder verwaltet werden, können wie folgtunterschieden werden:

Zentralisiert Beim Ausfall des Vaterknotens wendet sich der Peer an die Quelle undmuss den ganzen Baum nochmals durchlaufen, bis er einen neuen Vaterknoten �ndet(Overcast [JG+00]). In einem zentralisierten System wie CoopNet ermittelt der Zen-tralserver einen neuen Vater. Der zentralisierte Ansatz ist bei hohem Peer-Churn nichtskalierbar.

Implizit In Tree-basierten Systemen merken sich die Peers andere Knoten auf ihremWegdurch 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 undZIGZAG kennen die Peers die Knoten in ihrem jeweiligen Cluster. Der Cluster organisiertsich bei Peer-Leave, d.h. wenn Peers das Netz verlassen, selbst.

Strukturiertes Membership-Management Die P2P-Streaming-Protokolle Scribe undSplitStream setzen auf dem DHT-Substrat Pastry auf, das die Verbindungen zwischenden 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-Namensraumliegt. Der Peer mit der numerisch nächsten ID wird zum Einstiegspunkt für diese Gruppeund zum Wurzelknoten des Multicast-Baums. Der Multicast-Baum wird durch die Pfadeim Pastry-Netzwerk gebildet, die die Gruppenmitglieder mit dem Wurzelknoten verbin-den. 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 diePastry-DHT für die Reparaturmaÿnahmen zuständig. [CD+02, MS07]

Bei SplitStream wird der Stream in Substreams (hier Stripes genannt) zerlegt. JederStripe wird über einen anderen Baum verteilt. Für jeden einzelnen Baum wird dabeiScribe verwendet und eine eigene Gruppen-ID angelegt.

42


Unstrukturiertes Membership-Management In unstrukturierten Netzen sollen Peerseine 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 alleMitglieder kennen. Dazu p�egt jeder Peer lokal eine Mitgliederliste und erstellt regelmä-ÿig sogenannte Refresh-Nachrichten, mit denen er sich im Netzwerk bekannt macht. Erschickt die Refresh-Nachricht an seine Nachbarn, die danach ihre Mitgliederliste aktuali-sieren. Das Wissen über die Mitglieder wird im Netzwerk propagiert, indem die Nachbarnihre Mitgliederlisten zum Abgleich austauschen.

Dieses Verfahren lässt sich in gröÿeren Netzwerken so nicht umsetzen. Lokal kann einPeer zwar gröÿere Mitgliederlisten mit mehreren Hundert Einträgen verwalten. BeimAustausch der Listen im Netzwerk würde es aber zu einem regelmäÿigen Overhead vonmehreren Kilobytes kommen. Vor allem in datenzentrierten Pull-Systemen sollte derOverhead durch Kontrollnachrichten möglichst gering gehalten werden. In groÿen Net-zen kennen Peers daher nicht alle Knoten, sondern nur einen Teil. Der Peer erhält so-zusagen eine partielle Sicht auf das Netzwerk. Damit die Peers im Netzwerk mit einergroÿen Wahrscheinlichkeit von den Gruppenereignissen erfahren, sollte sich die Gröÿeder partiellen Sicht logarithmisch zur Knotenanzahl verhalten. Die Informationen überGruppenereignisse (Join, Leave) werden per Gossiping verbreitet, indem die Nachrich-ten an eine aus der partiellen Sicht zufällig ausgewählte Teilmenge von Peers verschicktwerden.

SCAMP (Scalable Membership Protocol [GKM03]) wurde nach dieser Idee entworfenund skaliert somit logarithmisch. Bei SCAMP macht sich ein neuer Peer bekannt, indemer eine Subskription an einen Kontaktknoten schickt. Dieser leitet die Subskription analle 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 leitetsie 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 Hopan-zahl begrenzt und CoolStreaming dafür eine Gültigkeitsdauer (Time-To-Live oder TTL)der Nachricht vorsieht. Die CoolStreaming-Autoren de�nieren die Time-To-Live als Zeit-spanne, die z.B. in Sekunden angegeben wird. Analog zur Hopanzahl wird die TTL vonden Empfängern der Nachricht jeweils nach unten korrigiert. Sobald die TTL kleineroder gleich 0 ist, wird die Nachricht nicht mehr weitergeleitet, sondern verworfen. EineZeitsynchronisation zwischen den Peers ist somit nicht erforderlich.

Nach [ZL+05] werden bei CoolStreaming die Gruppennachrichten Membership-Messagesgenannt. Sie werden regelmäÿig erstellt, verschickt sowie weitergeleitet. Die Weiterlei-tung einer Nachricht erfolgt nur, solange die Time-To-Live nicht abgelaufen ist. Über

43


die Membership-Messages erfahren die Peers von Joins, Leaves oder Fails (Ausfall einesKnotens) der anderen Gruppenmitglieder.

Die Autoren haben in [ZL+05] nicht beschrieben, wie sie Gossiping per SCAMP in dasCoolStreaming-Protokoll implementiert haben. Daher wurden im Rahmen dieser Arbeitfolgende 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 leitetder Einstiegspunkt die Membership-Message an alle Knoten sowie an weitere kzufällig ausgewählte Knoten aus der partiellen Sicht weiter. Der Empfänger derMembership-Message fügt sie mit der in SCAMP de�nierten WahrscheinlichkeitP (insert) = 1/(1 + partialviewsize) in die lokale partielle Sicht ein und leitetsie an einen zufällig gewählten Knoten weiter. Solange die TTL gültig ist, wirddie Nachricht weitergeleitet. Erst nach Ablauf der TTL erstellt der Peer eine neueMembership-Message, die wiederum nach dem SCAMP-Algorithmus verteilt wird.

2. Ein neuer Knoten trägt die vom Einstiegspunkt erhaltenen Partnerkandidaten inseine partielle Sicht ein. Regelmäÿig (z.B. aller 20 Sekunden) erzeugt der Peer eineMembership-Message, die er an einen zufälligen Knoten aus der partiellen Sichtschickt. Empfängt ein Knoten eine Membership-Message, aktualisiert er anhand derDaten aus der Membership-Message seine partielle Sicht und leitet die Membership-Message an einen zufälligen Knoten weiter. Die Membership-Message wird solangeweitergeleitet, bis die TTL abgelaufen ist.

Da die Implementierung des CoolStreaming-Protokolls und somit des SCAMP-Algorith-mus in CoolStreaming möglichst nah am Original erfolgen sollte, kontaktierte ich XinyanZhang, den Entwickler von CoolStreaming, und stellte ihm die zwei oben genanntenImplementierungsmöglichkeiten vor. Laut Xinyan Zhang wurde SCAMP ähnlich zu deroben genannten zweiten Variante umgesetzt. Zusätzlich tauschen die Partner nach demPartnerschaftsaufbau einmalig ihre partiellen Sichten auf das Netzwerk aus. [AYC04,Liu04, Pia07, SZ+08]

4.2.5 Fehlerkorrekturmechanismen und Kodierungen

In einem P2P-Streaming-Netzwerk müssen die Peers den Stream rechtzeitig zur geplantenWiedergabe erhalten, um die Daten ohne Aussetzer abspielen zu können. Tre�en nichtalle Daten rechtzeitig ein (z.B. nach dem Ausfall des Vaterknotens in Tree-basiertenSystemen), ist es wünschenswert, dass die Peers den Originalstream dennoch rekonstru-ieren können. P2P-Streaming-Systeme können zu diesem Ziel Fehlerkorrekturmechanis-men oder Kodierungen implementieren und so die Robustheit im Netzwerk zu erhöhen.Es werden redundante Daten erzeugt und versandt, damit auch bei fehlenden Daten derOriginalstream wiederhergestellt werden kann.

Die in diesem Abschnitt vorgestellten Verfahren unterscheiden sich darin, durch wenim 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 dieQuelle die Kodierung anwenden oder die Peers im Netzwerk. Die Netzwerkkodierung

44


(Network-Coding/NC) sieht vor, dass alle Peers im Netzwerk die Daten kodieren unddekodieren.

4.2.5.1 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 Descrip-tions, Substreams oder Slices). Im einfachsten Fall teilt man dabei die Frames nach ihrerNummerierung auf und erhält eine Description mit den Frames mit geraden Nummernund eine zweite Description mit allen Frames mit ungeraden Nummern [LR+08].

Jede Description wird über einen anderen Baum verteilt. Aus jeder Untermenge vonempfangenen Descriptions kann ein Peer den Originalstream rekonstruieren, wobei dieQualität des Streams mit der Anzahl der empfangenen Descriptions steigt. Für die Re-konstruktion benötigt der Peer allerdings zusätzliche Rechenzeit. Um eine gute Quali-tät gewährleisten zu können, muss jede Description genügend Informationen über denOriginalstream enthalten, was sich wiederum negativ auf die E�zienz der Kompressionauswirken kann. [Liu04, LR+08]

Das Mesh-basierte System PRIME setzt ebenfalls MDC ein. Der Peer fordert so vieleDescriptions an, wie es ihm seine Download-Kapazität ermöglicht und kann mit einerwachsenden Zahl von erhaltenen Descriptions seine Abspielqualität verbessern [MR07].

4.2.5.2 FEC (Forward-Error-Correction/Vorwärtsfehlerkorrektur)

Bei FEC werden aus den Originaldaten Redunzdaten berechnet, die zusammen mit denOriginaldaten versandt werden. Mit Hilfe der Redundanzdaten können bei Übertragungs-fehlern die verlorenen Daten wiederhergestellt werden. Um die erforderliche Redundanzzu ermitteln, muss vorab abgeschätzt werden, wie groÿ der auftretende Fehler sein kann.

FEC wird gewöhnlich auf der Bitübertragungsschicht angewandt, indem mittels einerXOR-Operation ein Fehlercode aus den zu übertragenden Bits berechnet und übertragenwird.

FEC in P2P-Netzwerken kann z.B. durch eine Reed-Solomon-Kodierung [RS60] reali-siert werden (wie in dem Live-Streaming-System PULSE [Pia07]). Im PULSE-Systemwird die Kodierung nur durch die Quelle ausgeführt. Der Stream wird dabei in einzelneBlö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 kodiertenBlöcke erzeugt. Die Quelle verschickt die Originalblöcke und die kodierten Redundanz-blöcke. Fehlende Originaldaten können mit Hilfe einer inversen Matrix wiederhergestelltwerden. Matrixmultiplikation und Invertierung erfordern allerdings einen relativ hohenRechenaufwand.

Falls FEC von Netzwerkknoten angewandt wird, erhöhen die Berechnungen (Kodierungund Dekodierung) auf den Knoten die Verzögerungen im Netzwerk. [LR+08, MF09,MS07]

1z.B. Vandermonde-Matrix

45


4.2.5.3 NC (Network-Coding/Netzwerkkodierung)

Im Unterschied zur Vorwärtsfehlerkorrektur muss bei der Netzwerkkodierung vorab nichtder mögliche Paketverlust abgeschätzt werden. Hier erstellen alle Knoten im Netzwerkeine Kodierung der erhaltenen Daten und geben sie weiter. Abbildung 4.3 stellt dasPrinzip 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 Rkann entweder a oder b weiterleiten. Indem R die Summe, a XOR b, berechnet und an Xund Y weiterleitet, können die Empfänger die Originaldaten errechnen und gleichzeitigwerden weniger Übertragungen benötigt.

Die Netzwerkkodierung in P2P-Streaming-Netzwerken erfolgt allerdings nicht mittelsXOR-Operationen, sondern durch Multiplikation der erhaltenen Daten mit einer Va-riablenmatrix. Der Stream wird von der Quelle in einzelne Blöcke zerlegt. Jeder Blockkann hier als Eintrag eines Vektors über einem endlichen Körper betrachtet werden. Dieinneren Netzwerkknoten berechnen aus den erhaltenen Blöcken eine Linearkombination,indem sie den (aus den Blöcken bestehenden) Vektor mit einer Variablenmatrix multipli-zieren. Linearkombination und Variablenmatrix werden versendet. Die Empfängerpeerskönnen die ursprünglichen Blöcke durch Multiplikation der inversen Matrix mit der Li-nearkombination ermitteln.

In der Regel erhält ein Knoten nicht die Originalnachricht, sondern bereits eine Paket-kombination. Daher enthält meist jedes Paket Informationen über alle Pakete. Auf dieseWeise kann NC nicht nur die Robustheit erhöhen, sondern auch die Datenverfügbarkeitund den Durchsatz im Netzwerk.

Problematisch ist der Berechnungsaufwand und die Beobachtung, dass NC die Gesamt-verzögerung im Netzwerk erhöht. Wang et al. argumentieren in [WL07] zwar, dass auf-grund der ohnehin hohen Verzögerung beim Streaming die zusätzliche Verzögerung durchNC nicht weiter ins Gewicht fallen würde und dass der Berechnungsaufwand auf einemStandardrechner kein Problem sei. Es ist aber anzunehmen, dass auf weniger leistungs-starken Rechnern (wie z.B. mobilen Geräten) der zusätzliche Berechnungsaufwand einProblem darstellt.

Bei NC in P2P-Streaming handelt es sich um ein sehr neues Forschungsgebiet, auf demin nächster Zeit sicher mit weiteren Ergebnissen zu rechnen ist. Es wird z.B. vorgeschla-

46


gen, zwischen wichtigen und unwichtigen Multimedia-Daten zu unterscheiden und dieaufwändige Dekodierung nur bei wichtigen Daten durchzuführen. [LR+08, MF09, MS07]

4.2.6 Transportprotokolle

Um den Videostream und die Kontrollnachrichten über das Internet zu versenden, wer-den Transportprotokolle des Internets benutzt. Das Containerformat wird dabei nichtals kompletter Stream verschickt, sondern zunächst mit einem sogenannten Packetizer ingleich groÿe Pakete des entsprechenden Transportprotokolls zerlegt. Die Pakete werdenentweder direkt über die Transportprotokolle der Transportschicht TCP und UDP ver-schickt. Oder man verwendet je nach Anwendung und Containerformat speziellere Über-tragungsprotokolle wie z.B. RTP, das proprietäre RTMP oder GBTP (GoalBit TransportProtocol [BV+09]), welche wiederum auf TCP oder UDP aufbauen. Aus der Sicht desOSI-Schichtenmodells handelt es sich bei RTP, RTMP oder GBTP nicht um tatsächlicheTransportprotokolle, da sie in einer Schicht oberhalb der Transportschicht anzusiedelnsind. Dennoch werden sie in der Literatur oft als Transportprotokolle bezeichnet, weil siefür den Datentransport konzipiert wurden (siehe auch [Sch08]).

4.2.6.1 RTP

RTP wird oft zum Transport von kontinuierlichen Echtzeitdaten verwendet. Es kann nachSpezi�kation mit TCP oder UDP zusammenarbeiten. In der Regel setzt RTP aber aufUDP auf und bietet dabei Anpassungen für Echtzeitanwendungen.

RTP versieht die Pakete mit einer Kennung für den Payload, einer fortlaufenden Num-mer und einem Zeitstempel. Durch die Nummerierung kann der Empfänger feststellen,ob die RTP-Pakete in der richtigen Reihenfolge gesandt wurden. Der Zeitstempel ermög-licht die Synchronisation unterschiedlicher Datenströme (z.B. Audio, Video) [Sim08]. Infrühen Versionen konnten RTP-Pakete entweder Audioformate oder Videoformate trans-portieren, aber nicht beides zusammen. Auf Empfängerseite mussten die Audio- und Vi-deodaten zu einem Stream gemuxt werden. Mittlerweile sieht RTP auch den Transportvon Containerformaten nach MPEG-2 oder MPEG-4 vor.

Nur wenige P2P-Streaming-Protokolle geben an, ob sie den Transport über RTP vorse-hen, ausgenommen CoolStreaming [ZL+05], GridMedia [ZZ+07] und PeerCast [DB+02].Die meisten P2P-Streaming-Protokolle erwähnen RTP möglicherweise deshalb nicht, dader Fokus dieser Protokolle auf dem Aufbau des P2P-Streaming-Overlays und dem Da-tenaustausch liegt. Die Verwendung von RTP spielt hierbei nur eine untergeordnete Rolleund hat keinen Ein�uss auf die sonstigen Protokollcharakteristiken.

Beim Transport mit RTP wird durch den 12-Byte-RTP-Header zusätzlicher Overheaderzeugt [Sim08]. Zudem versieht oft das P2P-Streaming-Protokoll die Chunks mit Se-quenznummer und Zeitstempel und nimmt die Sortierung auf Empfängerseite vor, sodass der Einsatz von RTP nicht notwendig erscheint und lediglich zu redundanten Datenführt.

47


4.2.6.2 UDP

UDP, ein Protokoll der Transportschicht im OSI-Schichtenmodell, ist ein verbindungs-loses Protokoll mit eingeschränkter Zuverlässigkeit [Kle05]. Die Datensegmente werdenversandt 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 Ver-bindungsaufbau zwischen Sender und Empfänger statt�ndet, bietet UDP einen schnellenDatentransport ohne garantierte Qualität. Daher eignet sich UDP für Echtzeitanwen-dungen im Internet, für die ein kontinuierlicher Daten�uss in minderer Qualität eherakzeptabel ist als ein Daten�uss in hoher Qualität, der stockt oder ausfällt.

Gegen den groÿ�ächigen Einsatz von UDP im Internet sprach lange, dass das Internetunter 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 kommerziellenAnbieter PPLive, PPStream und SopCast setzen UDP auch für den Datenversand ein[Zha10].

4.2.6.3 TCP

TCP, neben UDP das zweite �echte� Transportprotokoll, ist verbindungsorientiert undrealisiert einen zuverlässigen bidirektionalen Datenübertragungsdienst mit Flusskontrolle[Kle05]. Die Einhaltung der Bytereihenfolge wird garantiert, nicht empfangene Paketewerden nochmals versandt und durch die Flusskontrolle kann die Senderate verringertwerden. TCP sieht zudem mehrere gleichzeitige Verbindungen vor.

All diese Eigenschaften verlangsamen den tatsächlichen Transport, was TCP zunächst fürEchtzeitanwendungen uninteressant macht. Andererseits lässt sich die Verbindungsorien-tiertheit von TCP in P2P-Streaming-Sitzungen gut integrieren. Beim Datenaustauschwerden in Tree-basierten Systemen Verbindungen zwischen Vater und Sohn erstellt, inMesh-basierten zwischen Partnern. Wird dazu eine TCP-Verbindung errichtet, erhält derPeer bei Ausfall des Partners ein FIN-Segment. Um den Partnerausfall festzustellen, müs-sen somit auf der Anwendungsschicht keine weiteren Mechanismen implementiert wer-den, 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 R2 [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 ver-loren gegangene Segmente nochmals zu übertragen mit der Begründung, dass nicht erhal-tene Segmente wesentlich schneller von anderen Peers bezogen werden können als durchden nochmaligen Versand mit TFRC.

4.2.6.4 Wahl des Transportprotokolls

Bei der Wahl des Transportprotokolls ist es wichtig zwischen den Kontrollnachrich-ten an beliebige Peers und den Nachrichten an die Partner zu unterscheiden. Für den

48

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 Versandder dazugehörigen Kontrollnachrichten2 nur zwischen Partnern bzw. Vätern und Söhnenstatt�ndet, 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 be-endet.

Um den Overhead durch Kontrollnachrichten zu minimieren, schlagen einige P2P-Strea-ming-Protokolle vor, die Kontrollnachrichten an die Partner mit den Streamdaten imPayload zu versenden. Man bezeichnet diesen Versand als �piggyback� (engl. für Hucke-pack).

CoolStreaming verwendet als Transportprotokoll für die Streamdaten RTP in Verbin-dung mit UDP, TCP oder TFRC. In der Implementierung verwende ich aus oben ge-nannten Gründen UDP für den Versand von Membership-Nachrichten und TFRC fürden Nachrichtenaustausch zwischen Partnern, allerdings ohne nochmalige Übertragungoder Flusskontrolle.

4.2.7 Überblick

In diesem Abschnitt wurden die wesentlichen Charakteristiken von CoolStreaming mitdenen anderer P2P-Live-Streaming-Protokolle verglichen. Für eine umfassende Übersichtfasst Tabelle 4.1 die Eigenschaften der bekanntesten P2P-Live-Streaming-Protokolle zu-sammen. Bei dieser tabellarischen Übersicht gehe ich insbesondere auf den Aspekt derDatenverteilung und auf die Gruppenverwaltung durch Membership-Management ein.Mittels Membership-Management können Peers weitere Peers im Netzwerk kennenlernenund 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 dynamischeRouten im Mesh verteilt, wobei die Peers die Streamdaten explizit bei ihren Partnernanfordern (Pull). Die Datenverteilungswege werden in Mesh-Pull-Systemen durch denScheduler bestimmt, der anhand der Partner-Bu�ermaps ermittelt, bei welchen Partnernwelche Segmente angefragt werden.

4.3.1 Scheduler

Die zentrale Komponente bei Mesh-Pull-Mechanismen ist der Scheduler, auch Schedu-ling-Algorithmus, Packet-Scheduling-Algorithmus/PSA oder Request-Scheduling-Algo-rithmus [Pia07] genannt. Der Scheduler wird regelmäÿig aufgerufen und berechnet, beiwelchen Partnern welche Segmente angefragt werden.

2(Bu�ermaps und Requests in Mesh-basierten Systemen)

49


Protokoll

Jahr

Mem

bership-M

anagement

Topologieder

Streamverteilung

Artder

Streamverteilung

ALMI[PS+01]

2001

Zentralisiert:Session-Controller

(auch

Rendezvous-Pointgenannt)

Single-TreeMesh-�rst[AYC04,SW05]/

Single-TreeTree-�rst[HA+06]

Push

Bullet

[KR+03]

2003

Mesh(RanSub)

ErstTree,darüberMesh(fürfehlende

Chunks)

Push-Pull

Chainsaw[PK+05]

2005

Mesh

Mesh

Pull

Chunkyspread[VFC06]

2006

Gossipingim

Mesh(Swaplinks)

Multiple-Tree

Push

CoolStreaming[ZL+05]

2004

Gossipingim

Mesh(SCAMP)

Mesh

Pull

CoopNet

[PW+02]

2002

ZentralerServer

Multiple-TreeTree-�rst

Push

GridMedia

[ZT+05]

2005

Gossiping

UnstrukturiertesOverlay

Pull-Push-Pull

HostCast[LM03]

2003

Implizit(O

nkel+Groÿväterbekannt)

Single-TreeTree-�rst

Push

Narada[CRZ00]

2000

Mesh

Single-TreeMesh-�rst

Push

NICE[BBK02]

2002

Cluster


Push

Overcast[JG+00]

2000

Zentralisiert:Quelle


Push

PeerC

ast[DB+02]

2002

Implizit(G

roÿväterbekannt)


Push

PPLive[ppl]

2004

Gossipingim

Mesh

Mesh

Pull

PRIM

E[M

R07]

2007

Bootstrap-Node/Gossiping

Strukturiertes,unidirektionalesMesh

Pull

PULSE[PKB06]

2006

Gossipingim

Mesh(SCAMP)

Mesh

Push

(Quelle),Pull(Peers)

R2[W

L07]

2007

Gossipingim

Mesh

Mesh

Random-Push

mit

Random-Network-Coding

Scribe[CD+02]

2002

DHT(Pastry)

Single-TreeüberPastry

Push

SopCast[sop]

2005

Gossipingim

Mesh

Mesh

Pull

SplitStream

[CD+03]

2003

DHT(Pastry)

Multiple-TreeüberPastry

Push

YOID

[Fra00]

2000

Rendezvous-Point


Push

ZIG

ZAG

[THD03]

2003

Cluster


Push

Tabelle4.1:Vergleich

derCharakteristikenvonP2P

-Live-Stream

ing-Protokollen[AYC04,H

A+06,L

iu04,M

R07,P

ia07,SW05,SZ+08,

VFC06,VY07,Wan08,ZZ+07]

50


Die Scheduler in den untersuchten Protokollen unterscheiden sich bzgl. der Wahl derangeforderten Segmente (Chunk-Selection) und der Wahl des potentiellen Senders (Peer-Selection).

Chunk-Selection PRIME fordert zuerst die aktuellsten Segmente an. Eine ähnlicheStrategie empfehlen die Autoren in [YDL07]. Hier werden zunächst die aktuellsten Seg-mente angefordert. Wenn diese nicht verfügbar sind, werden die älteren Segmente an-gefragt, die als nächstes abgespielt werden sollen. Die Anfangsverzögerung bei dieserStrategie ist gröÿer, als wenn nur die demnächst abzuspielenden Segmente angefordertwerden.

CoolStreaming fordert die fehlenden Segmente nach der Verfügbarkeit bei den Partnernan, so dass Segmente, die nur einmal verfügbar sind, zuerst angefragt werden. Man be-zeichnet dieses Verfahren als Rarest-First. Bei diesem Verfahren kann es passieren, dassdie Peers mit den seltensten Segmenten im Netzwerk von Anfragen überschwemmt wer-den. Um dies zu verhindern, sollte jeder Peer nur so viele Anfragen an einen Partnerschicken, wie dieser voraussichtlich bearbeiten kann. Zu diesem Zweck kann z.B. eineObergrenze für Anfragen pro Partner de�niert werden. Oder man wendet heuristischeVerfahren an, um die verfügbare Uploadbandbreite des Partners zu ermitteln. DiesesVerfahren wird im folgenden Abschnitt besprochen.

Einige Protokolle sehen darüber hinaus vor, dass die Anzahl der anzufordernden Segmen-te je Scheduling-Lauf beschränkt wird. CoolStreaming sieht laut [ZL+05] keine derartigeBegrenzung vor, was theoretisch dazu führen kann, dass ein neuer Peer, der eine laufendeStreaming-Sitzung betritt, versucht, seinen gesamten Pu�er zu befüllen und dabei diePartner mit Anfragen überschwemmt.

Peer-Selection Es bieten sich folgende Mechanismen an, um die Segmentanfragen aufdie Partner, die die Segmente liefern können, zu verteilen:

� Random: Fehlende Segmente werden zufällig bei den Partnern angefordert (siehez.B. Chainsaw [ZX+09]). Ohne die Implementierung eines Zufallsgenerators könntedies zu einer ungleichen Verteilung der Pull-Requests und somit der Bandbreitenan-forderungen 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%) keinSegment angefordert.

� Round-Robin: Die Anfragen werden gleichmäÿig auf die Partner verteilt. Die Band-breitenkapazitäten der Partner werden nicht berücksichtigt. Partner mit hoherBandbreite können bei der Methode möglicherweise zu wenig angefragt werdenund Partner mit einer niedrigen Bandbreite durch Pull-Requests überlastet.

� Heuristische Bandbreitenschätzung: CoolStreaming und PRIME weisen ihren Part-nern die Pull-Requests gemäÿ ihrer geschätzten Uploadbandbreite zu. Die Qualitätdieses Verfahrens hängt von der Qualität der Bandbreitenschätzung ab (siehe auch5.4.7.1). Bei einer zuverlässig funktionierenden Bandbreitenschätzung stellt diesesVerfahren die fairste Variante dar, ist aber komplexer und damit auch fehleranfäl-liger.

51

4.4. PERFORMANCE-VERGLEICH KAPITEL 4. ANALYSE

Um Überlastungen des Partners zu vermeiden, kann die Anzahl der Pull-Requests proPartner begrenzt werden. Auch bei einer zuverlässigen Bandbreitenschätzung würdedies zumindest als Fallback-Mechanismus dienen. So wie einige andere Protokolle siehtCoolStreaming diese Begrenzung nicht vor.

4.3.2 Bearbeitung von Datenrequests

Für den Partner, der Datenanfragen erhält, stellt sich die Frage, in welcher Reihenfolgeer diese bearbeitet. Verschickt er die Daten so, wie sie angefragt werden (FIFO), kannes passieren, dass ein Partner, der mehrere Segmente auf einmal anfordert, die gesamteUploadkapazität des Senders in Anspruch nimmt.

Bei PULSE verwaltet der Peer für jeden Partner eine Request-Queue und zu jedemSegment einen Zähler �replica count�, der festhält, wie oft der Peer das Segment bereitsan Partner verschickt hat. Erhält der Peer mehrere Anfragen auf einmal, verschickt erzuerst die Segmente, die bisher am seltensten versandt wurden, damit diese schneller imNetz verteilt werden. Die anderen verschickt er in zufälliger Reihenfolge.

GridMedia verwendet einen anderen sehr interessanten Ansatz. Systemweit wird ein Re-questintervall t de�niert. Die Sender verschicken Segmente nur während des Requestin-tervalls t. Nach Ablauf von t verwirft der Sender alle nicht bearbeiteten Anfragen. Fordertein 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 po-tentiellen Sender ermitteln [ZZ+07]. Da der Sender nicht alle Anfragen bearbeitet, musser dafür sorgen, dass die anfragenden Peers fair bedient werden. Eine faire Methode wäreein Zähler, der für jeden Partner den Anteil der bearbeiteten Requests speichert und ak-tualisiert. 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 vor-zugehen ist. Um zu verhindern, dass nicht erhaltene Segmente die Wiedergabe massivbeeinträchtigen, könnte also ein Segment nach Ablauf eines Zeitintervalls nochmals ange-fordert werden (in der Ho�nung, dass es rechtzeitig eintri�t) oder das fehlende Segmentwird mit Hilfe eines Fehlerkorrekturmechanismus wie FEC rekonstruiert (siehe Abschnitt4.2.5.2).

Die CoolStreaming-Autoren geben in [ZL+05] lediglich an, dass angeforderte Segmentedurch 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. �Qua-lity of Experience� stellt nach Huang von PPLive zwar die wichtigste Metrik dar, spiegeltaber 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ögerun-gen empfunden haben. Die QoE lässt sich in der Regel nicht automatisiert erfassen odervergleichen. [Hua07, tuc10]

52


Daher wendet man die Mittel der Performance-Evaluierung an. Analog zur Performance-Evaluierung im P2P-Bereich gilt es auch bei den P2P-Streaming-Protokollen herauszu�n-den, ob das Protokoll die Eigenschaften Skalierbarkeit, Robustheit und E�zienz aufweist.

4.4.1 Protokolleigenschaften

Jede der Eigenschaften Skalierbarkeit, Robustheit und E�zienz wird durch Metrikenausgedrückt, die sich wiederum aus einem oder mehreren Messwerten zusammensetzen[Wol10].

Skalierbarkeit bezeichnet die Fähigkeit eines P2P-/P2P-Streaming-Netzwerks, sich aneine quantitativ wachsende Anzahl von Peers und/oder Daten anzupassen [Wol10]. DieSkalierbarkeit wird in Bezug auf eine messbare Kenngröÿe ausgedrückt, z.B. in Bezug aufden Kontrolloverhead (auch Protokolloverhead), der durch das Verhältnis des Kontroll-datenvolumens zum Videodatenvolumen ermittelt wird. Ist das Wachstum des Kontroll-overheads bei wachsender Peeranzahl logarithmisch begrenzt durch O(logN), kann mansagen, dass das System in Bezug auf den Kontrolloverhead skaliert [MS07].

Robustheit beschreibt die Eigenschaft eines Netzwerks, auch unter hoher Last undbei Fehlern (z.B. Ausfällen der Netzwerkstruktur) ein spezi�ziertes Leistungsniveau zuerhalten [Wol10]. Die Robustheit bezieht sich ebenfalls auf eine Kenngröÿe, die in P2P-Streaming-Netzwerken meist unter starkem Churn gemessen wird.

E�zienz wird in [FH07] ganz allgemein als Wirkungsgrad von Aktivitäten de�niert.In einem P2P-Streaming-Netzwerk kann E�zienz dadurch ausgedrückt werden, wie gutbeim Streamingprozess vorhandene Ressourcen (insbesondere die Netzwerkbandbreite)genutzt werden. In einem System mit einer hohen Bandbreitene�zienz wird z.B. dieUploadbandbreite aller Peers bestmöglich verwendet.

4.4.2 P2P-Streaming-Metriken

Die ersten ALM-Systeme wurden als Alternative zu IP-Multicast entwickelt, weshalb beidiesen Tree-basierten ALM-Systemen zur Evaluierung Metriken wie Path-Stretch undLink-Stress ausschlaggebend waren. Path-Stretch misst das Verhältnis der Pfadlängenin der Topologie im Vergleich zum kürzesten Pfad (dem direkten Unicast-Weg bzw. derEnde-zu-Ende-Verzögerung/EED). Link-Stress misst die Anzahl von identischen Paketenauf einzelnen Teilstrecken, also den Overhead durch redundante Daten. Durch Path-Stretch und Link-Stress lässt sich bestimmen, wie e�zient ein ALM-System im Vergleichzu IP-Multicast die Daten verschickt. [SWS07]

Die Herausforderung für Tree-basierte Protokolle im Streamingprozess besteht aber ei-gentlich darin, einen Baum mit geringer Höhe zu errichten und bei Peer-Churn diesenBaum auszubalancieren. Daher müssen in Tree-basierten Systemen Nachrichten mit Rou-tingtabellen [CRZ00], Membership-Nachrichten und weitere Kontrollnachrichten ausge-tauscht werden, die in die Bezi�erung der Metrik Kontrolloverhead ein�ieÿen:

53


Kontrolloverhead ist das Verhältnis aller Kontrollnachrichten in Bytes zu den reinenVideostreamdaten in Bytes. Der Kontrolloverhead kann entweder als Wert zwischen �0�und �1� oder in Prozent angegeben werden. In Mesh-basierten Systemen ist der Kontroll-overhead 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 derkonstanten Anzahl von Partnern, an die jeder Peer den Groÿteil der Kontrollnachrichtenverschickt. Beim Test eines Protokolls kann der Kontrolloverhead als Funktion andererGröÿen wie z.B. der Partneranzahl gemessen werden, um optimale Parameterwerte zuermitteln.

In Tree-basierten Systemen hängt der Kontrolloverhead vomWachstum 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 diesesClusters Gruppennachrichten austauschen.

Protokoll Kontrolloverhead

ALMI O(N)

CoopNet O(logN)

Narada O(N)[CRZ00] bzw. O(N2)[HA+06]

NICE O(logN)

Overcast O(logN)

Scribe O(logb2N)

SplitStream O(NlogN) bis O(N2) worst-case

YOID O(logN)

ZIGZAG O(k) bis O(logN) mit k=konstanter Knotengrad

Tabelle 4.2: Kontrolloverhead von Tree-basierten ALM-Protokollen in Relation zur Kno-tenanzahl N [AYC04, CRZ00, HA+06]

Beim Live-Streaming sind insbesondere die Verzögerungen bei der Wiedergabe ausschlag-gebend. Diese sollten so gering wie möglich sein. Nach Auswahl des Kanals sollte derBenutzer nicht lange auf den Beginn der Übertragung warten müssen und die Datenauch nicht wesentlich später als seine Nachbarn erhalten. Während im Tree-basiertenNetzwerk die Abspielverzögerung eines Peers durch seine Position im Baum bestimmtwird und somit konstant ist, schwanken die Verzögerungen in Mesh-basierten Systemenstark und stellen daher wichtige Metriken dar.

Startup-Delay/Anfangsverzögerung bezi�ert die Zeitdi�erenz zwischen der Kanalaus-wahl und dem Beginn der Wiedergabe des Live-Streams. Die Anfangsverzögerung wirdin 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 bezi�ert die Zeitdi�erenz zwischen der Ausgabeeines Streamsegments durch die Quelle und dessen Wiedergabe durch den Peer. Synonymzu Playback-Delay werden die Begri�e Playout-Delay [MR07], Display-Lag [HLR08],Average-Reception-Delay [Pia07] verwendet.

54


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 kon-tinuierlich die Wiedergabe des Streams erfolgt. Damit ein Stream kontinuierlich und ohneAussetzer abgespielt werden kann, müssen die Streamsegmente rechtzeitig (d.h. vor ih-rem jeweiligen Abspielzeitpunkt) eintre�en. Der Continuity-Index wird ermittelt, indemman die Anzahl der rechtzeitig erhaltenen Segmente durch die Anzahl aller Segmenteteilt, die hätten abgespielt werden sollen. Der Continuity-Index kann entweder als Wertzwischen �0� und �1� oder in Prozent angegeben werden.

Die Streamingqualität drückt sich dadurch aus, dass der Peer den Stream möglichst ohneAussetzer empfängt, weshalb ein gröÿtmöglicher Teil der Segmente vor der Playback-Deadline beim Peer eintre�en sollte. Der Continuity-Index kann als Funktion in Relationzur Partneranzahl, zur Streamingrate oder zu anderen Parametern ermittelt werden.

Tabelle 4.3 vergleicht einige bekannte ALM-Protokolle anhand der besprochenen Metri-ken (Startup-Delay, Playback-Delay, Continuity-Index, Kontrolloverhead). Die Protokol-le sind entweder rein Mesh-basiert (CoolStreaming, GridMedia, PPLive, SopCast) oderbenutzen einen Mesh-/Tree-Ansatz (Bullet, PRIME).

Protokoll Startup-Delay Playback-Delay Continuity-Index bei

Streamingraten von

309-330 kbps / 380 kbps

Kontrolloverhead

Bullet - - - 3-5%

CoolStreaming mind. 1min mind. 1min 99,5% / 99,3% [ZL+05]

90% / 85% [LJ+06]

2%

GridMedia - 2,2-7s 99-100% / - 3%

PPLive 20s - 2min 1min - 5%

PRIME 30-48s - - -

SopCast 37s - 5min 1min 88% / 99-100% 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 messendie CoolStreaming-Autoren z.B. einen Continuity-Index von 99,3% [ZL+05], währendLiao et al. in [LJ+06] lediglich auf einen Continuity-Index von 85% kommen. D.h. nachLiao et al. erhält ein CoolStreaming-Benutzer durchschnittlich 15% des Streams nichtrechtzeitig. In [ZL+05] wurde der Continuity-Index in einer Simulation mit 200 Peersgemessen, in [LJ+06] dagegen mit 400 Peers. In [ZL+05] hat ein Peer durchschnittlich 5Partner, in [LJ+06] mindestens 5 Partner.

Skalierbarkeit und Robustheit eines P2P-Streaming-Protokolls lassen sich durch die Me-triken Startup-Delay, Playback-Delay und Continuity-Index ausdrücken. Der Kontroll-overhead ist insbesondere dann interessant, wenn man ein bestehendes Protokoll struk-turell verändert und die Auswirkungen testen will.

55

4.5. GRAPH-ANALYSE KAPITEL 4. ANALYSE

In [ZL+05] ermittelten die Autoren die Skalierbarkeit von CoolStreaming unter Berück-sichtigung von Kontrolloverhead und Continuity-Index. Da der Kontrolloverhead unab-hängig von der Overlaygröÿe ist und der Continuity-Index auch beim Wachstum des Net-zes von 10 auf 200 Knoten nicht unter 95% fällt, kann man folgern, dass CoolStreamingskaliert. Bei starkem Churn, wenn jeder Peer z.B. aller 100 Sekunden das Netz betrittund wieder verlässt, sinkt der Continuity-Index nicht unter 91%, wodurch sich die relativeRobustheit des Systems zeigt.

4.5 Graph-Analyse

CoolStreaming wendet Gossiping an, um Gruppennachrichten über Joins, den aktuellenStatus (Partneranzahl etc.) oder Leaves der Peers zu verteilen. Jeder Peer kennt dahereine zufällige Teilmenge aller Knoten im Netzwerk, die er in einer partiellen Sicht spei-chert. Da sowohl Partnerkandidaten für neue Knoten als auch Partner als Ersatz fürausgefallene Knoten zudem zufällig aus der partiellen Sicht ausgewählt werden, erzeugtCoolStreaming einen zufälligen Verbindungsgraph (siehe Abbildung 4.4). Der Grad je-des Knotens in diesem Verbindungsgraph liegt aufgrund der Partneranzahl in einembestimmten Bereich, optimalerweise zwischen 4 und 6 [ZL+05].

1.0.0.1

1.0.0.2

1.0.0.3

1.0.0.4

1.0.0.5

1.0.0.6

1.0.0.9 1.0.0.10

1.0.0.8

1.0.0.7

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-Analysein klassischen P2P-Netzen. In P2P-Netzen werden Dateien gesucht, die irgendwo imNetzwerk liegen können. Für eine e�ziente Suche ist daher der Durchmesser entscheidend,d.h. die Länge der längsten aller kürzesten Pfade im Netzwerk. In P2P-Streaming-Netzengeht es darum, dass die Peers die von der Quelle gestreamten Daten auch bei wachsendemNetzwerk schnellstmöglich erhalten. Aus diesem Grund wird der Abstand zwischen Quelleund Peer betrachtet. Man spricht in diesem Zusammenhang von Overlay-Radius oderTiefe bzw. Höhe des Multicast-Baumes.

In [ZL+05] haben die Autoren eine logarithmische Relation zwischen Overlay-Radius und

56

4.6. ZUSAMMENFASSUNG KAPITEL 4. ANALYSE

Netzwerkgröÿe gezeigt. Die durchschnittliche Distanz von der Quelle zu einem Peer wirddurch 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 Datenverteilungerfolgt ü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 implementie-ren, weshalb sie von allen gröÿeren kommerziellen Systemen (wie PPLive, PPStream,SopCast, TVAnts) eingesetzt wird. Zudem bietet die Mesh-Pull-Struktur im Vergleich zuden Tree-basierten Strukturen den Vorteil, dass sie die Bandbreitenkapazitäten der Peersgleichmäÿ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 An-forderung, da es in diesem Anwendungsbereich zu Flash-Crowds und somit zu starkemChurn kommen kann. Problematisch in Mesh-Pull-Systemen sind die Verzögerungen undder Overhead durch Kontrollnachrichten. Die Verzögerungen bei CoolStreaming könnenvon einer Minute bis zu mehreren Minuten (nach Userberichten) betragen. Der Kon-trolloverhead ist mit 2% im Vergleich zu anderen Mesh-Pull-Protokollen dagegen relativniedrig (siehe auch Tabelle 4.3).

Abbildung 4.5 zeigt den Aufbau des CoolStreaming-Systems nach [ZL+05]. Die Autorenunterscheiden zwischen den Kernkomponenten Membershipmanager (für die Verwaltungder partiellen Sicht), Partnershipmanager (für die Verwaltung von Partnerschaften) undScheduler.

In vielen P2P-Streaming-Arbeiten wird vor allem der besondere Scheduling-Algorithmusvon CoolStreaming hervorgehoben, der die Segmente gemäÿ ihrer Verfügbarkeit bei denPartnern in Bu�ermap-ähnlicher Art anfordert. Ist ein Segment nur bei einem Partnerlieferbar, wird es immer bei diesem angefragt. Segmente, die mehrmals verfügbar sind,werden nach der geschätzten Uploadbandbreite der Partner angefordert. Hat ein Partnerkeine Bandbreitenkapazitäten übrig, erhält er keine Datenrequests. Eingehende Daten-requests werden sortiert über RTP verschickt.

Mit Sicherheit stellte der CoolStreaming-Scheduler zu der Zeit seiner Verö�entlichungeine 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 Band-breitenschätzung ab.

2. CoolStreaming de�niert keine generellen Obergrenzen für die Anzahl der insgesamtangefragten Segmente. Ein neuer Peer, der seinen kompletten Pu�er füllen möchte,kann seine Partner mit Anfragen überschwemmen.

3. Da CoolStreaming auch keine Obergrenze für die Anzahl der angefragten Segmentepro Partner de�niert und alle nur einmal verfügbaren Segmente bei dem entspre-chenden Partner ordert, ist folgendes Szenario möglich: Ein Partner, der neuere

57


Scheduler

Netzwerk-Interface

Puffer Buffermap

Membership-manager

Partnership-manager

Player

PartnerPartner 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 neuestenSegmente liefern kann.

4. Da in [ZL+05] nicht de�niert wurde, dass ein Peer eingehende Datenrequests ineiner bestimmten Reihenfolge abarbeitet oder bei Überlastung Datenrequests ab-lehnen kann, kann man daraus schlieÿen, dass Requests so bearbeitet werden, wiesie eintre�en. Erhält ein Partner mehr Requests als er bearbeiten kann, kommt eszu einer Überbeanspruchung seiner Bandbreitenkapazität. Dadurch kann der Peerschlieÿlich vollständig überlastet werden. Die Verzögerungen auf Seiten der warten-den Empfänger würden sich immer mehr kumulieren.

5. Auch wenn in [ZL+05] und in anderer P2P-Streaming-Literatur betont wird, dassdie seltensten Segmente zuerst angefragt werden, ist dies nicht immer gewährleis-tet. Die Peers fordern die fehlenden Segmente in Bu�ermap-ähnlicher Art an. Bei-spielsweise erstellt ein Peer P1 für jeden Partner einen Bit-String von der Gröÿedes Pu�ers. Jedes Bit steht für ein Segment. Benötigte Bits werden mit einer �1�markiert, nicht benötigte mit �0�. Der O�set dieses Strings entspricht der ID desersten Pu�erelements, so dass die IDs der zu liefernden Segmente leicht ermitteltwerden können. Wenn P1 bei einem Partner mehrere Segmente anfordert, so werdendie Segmente aufgrund des Bit-Strings aufsteigend nach ihrer ID angefordert, d.h.die ältesten Pu�ersegmente zuerst. Das Ziel, dass die seltensten Segmente immerzuerst angefordert werden, wird durch die Bu�ermap-ähnliche Anfrage kolportiert.

Abschlieÿend möchte ich betonen, dass es durchaus möglich ist, dass die oben geschil-

58


derten Probleme in der tatsächlichen CoolStreaming-Implementierung gelöst wurden, dadie Autoren in [ZL+05] nicht alle Protokollcharakteristiken dokumentiert haben. Auf ei-ne Nachfrage meinerseits hin hat mir aber der CoolStreaming-Entwickler Xinyan Zhangdie zuletzt erwähnte Unstimmigkeit bestätigt, nach der die seltensten Segmente nichtimmer 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 Lis-te angefragt werden. Zu bedenken ist hier, dass dies die Gröÿe der Kontrollnachrichtenerhöht.

59

5 Implementierung

Dieses Kapitel behandelt die wesentlichen Aspekte der Implementierung des CoolStrea-ming-Protokolls. Zunächst wird die Auswahl eines geeigneten Vorgehensmodell für Soft-wareprojekte besprochen. Dann wird auf die Besonderheiten hingewiesen, die es bei derImplementierung in den P2P-Simulator P2PNetSim und der Integration des Benchmark-systems SimBench [Wol10] zu beachten gilt. Darüber hinaus werden die wesentlichenKomponenten des implementierten Protokolls besprochen sowie deren Interaktion. AmEnde des Kapitels werden die angewandten Test- und Veri�kationsmethoden vorgestellt.

5.1 Implementierung in P2PNetSim

P2PNetSim ist ein parallel arbeitender Netzwerksimulator, der im Unterschied zu vie-len anderen Simulatoren mehr als eine Million Knoten im Netzwerk simulieren kann.P2PNetSim wurde komplett in Java entwickelt und ist somit plattformunabhängig ein-setzbar. Der Simulator stellt ein einfaches Netzwerkmodell zur Verfügung, wobei zu Guns-ten eines geringstmöglichen Overheads auf die Modellierung von IP-Routing oder derTCP-Funktionalität verzichtet wurde. [Roj07]

Die Simulation der Peers erfolgt sequentiell in jedem Simulationsschritt. Die zentraleKomponente dazu ist die abstrakte Klasse Peer1. Das Peer-Objekt kennt den aktuellenSimulationsschritt (Variable simtime), kann Nachrichten senden und empfangen und hatZugri� auf das Logger-Objekt der Klasse P2PNetSimLogger.

Für die Initialisierung der Peers benötigt P2PNetSim eine XML-Kon�gurationsdatei. Indieser Datei kann man zu jedem Peer auch selbst de�nierte Parameter hinzufügen, welcheim Programm mit getParam(String key) ausgelesen werden können. Selbst de�nierteParameter erscheinen in der P2PNetSim-GUI unter �Properties� (siehe Abbildung 5.1).In der P2PNetSim-GUI werden oberhalb von �Properties� Key-Value-Paare der Grund-kon�guration (�Basic con�guration�) 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-Kon�gurationsdatei de�niert werden. Durch den P2PNetSim-Befehl �Connect� werdenvor Simulationsbeginn alle Peers aus der Kon�gurationsdatei initialisiert. P2PNetSimunterscheidet nicht zwischen einem online-Peer und einem o�ine-Peer. Dies muss zusam-men mit den Join- und Leave-Mechanismen in der jeweiligen Protokoll-Implementierungumgesetzt werden. Es emp�ehlt sich hier die Integration von SimBench [Wol10], da

1Peer ist hervorgehoben, da es sich um die konkrete Klasse Peer handelt und nicht um einen Peerim Netzwerk. Beim Bezug auf Klassen, Pakete, Bibliotheken, Variablen, Konstanten, Methoden,Datentypen oder Modi�katoren erscheinen diese in der Schrift Courier New.

60

5.1. P2PNETSIM KAPITEL 5. IMPLEMENTIERUNG

Abbildung 5.1: P2PNetSim-GUI mit Anzeige der Grundkon�guration (�Basic con�gura-tion�) und selbst de�nierter 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 vonLogmeldungen in der GUI vor. Debugmeldungen zur Fehlersuche können in der GUI alsLogmeldungen oder auf der Kommandozeile ausgegeben werden.

Die Peers kommunizieren in P2PNetSim über Nachrichten, d.h. über Objekte der ab-strakten Klasse Message. Per Default wird jede Nachricht in einem Simulationsschrittzugestellt. Falls Protokolle der Transport- oder IP-Schicht implementiert werden müs-sen, emp�ehlt es sich, das zu versendende Segment oder Paket als Message-Objekt zuimplementieren.

Während eines Simulationsschrittes fallen beim P2P-Streaming viele Aktionen mit ho-her Komplexität an, z.B. die Reparatur des Overlaynetzwerks, der Nachrichtenempfang,die Ausführung des Scheduling-Algorithmus und der Nachrichtenversand (z.B. von Buf-fermaps, Datenrequests). Zur übersichtlichen Implementierung in P2PNetSim und zure�zienten 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 derTransportschicht. Im Rahmen der vorliegenden Implementierung wurden daher TCP-und UDP-Funktionalitäten integriert (siehe Abschnitt 5.4.2).

Auf der Anwendungsschicht ist die Implementierung eines echten Medienplayers im Si-mulator nicht erforderlich, da der Medienplayer kein Bestandteil des P2P-Streaming-Protokolls ist. Es wurde dennoch eine rudimentäre Playerkomponente integriert, um die

61

5.2. SIMBENCH KAPITEL 5. IMPLEMENTIERUNG

Implementierung anhand besonderer Metriken testen zu können, z.B. mittels der MetrikAnfangsverzögerung (siehe Abschnitt 4.4.2) oder indem gemessen wird, inwieweit dieStreamsegmente rechtzeitig vor der Deadline eintre�en (siehe Metrik Continuity-Indexin Abschnitt 4.4.2).

5.2 Integration von SimBench

SimBench ist ein Benchmarksystem, das von Alexander Wolf im Rahmen einer Abschluss-arbeit für P2PNetSim entwickelt wurde [Wol10]. Es handelt sich um ein eigenes Systemmit Nachrichtenklassen, Befehlsklassen, einem Observer-Konzept und einem Frontendzur Generierung der XML-Kon�gurationsdatei.

Das Benchmarksystem ist auf die Evaluierung von P2P-Protokollen für den Dateiaus-tausch optimiert. Ein Dateisystem ermöglicht dabei die Verteilung von Dateien auf Peersmit Gleich- oder Normalverteilung. Über eine Befehlszentrale erhält jeder Peer Standard-P2P-Befehle (z.B. zum Join, Leave, Fail) sowie Datei-spezi�sche Befehle wie Delete, Look-up und Store.

SimBench ist konzipiert, um als Library (jar-Datei) ohne weitere Anpassungen eingebun-den zu werden. Zur Evaluierung des P2P-Streaming-Protokolls war dies aus folgendenGründen nicht möglich: Erstens werden beim P2P-Streaming keine Dateien gesucht, aus-getauscht oder dauerhaft gespeichert. Die Datei-spezi�schen Befehle Delete, Lookup undStore werden somit nicht benötigt und die Befehlszentrale kann nicht wie vorgesehenverwendet werden. Zweitens wurde der SimBench-XML-Generator in Anpassung an dasGnutella-Protokoll entworfen. Für den Einsatz beim P2P-Streaming hätte er eigens an-gepasst werden müssen. Und drittens sind die vorhandenen SimBench-Metriken nicht zurEvaluierung von P2P-Streaming-Protokollen geeignet.

Zur Evaluierung des P2P-Streaming-Protokolls CoolStreaming wurde daher auf folgendeTeilfunktionalitäten von SimBench zurückgegri�en:

� De�nition der Messwerte in der XML

� Ermittlung der Daten auf den Peers

� Aggregation der Daten in den EventHandlern

� graphische Ausgabe (Verbindungsgraph)

Für die Integration von SimBench werden die Pakete common (mit AbstractStatistik),simbench (mit den EventHandler-Klassen), stats (mit Statistikklassen) und util be-nötigt.

Neue Messwerte werden in der Klasse stats.Messwert als Enum-Werte de�niert. DieVerarbeitung der Messwerte erfolgt in einer eigenen Statistikklasse StreamingStatistik(extends AbstractStatistik) innerhalb des p2pstreaming-Pakets. Die StatistikklasseStreamingStatistik stellt auch die Methoden zur Verfügung, mit denen Peers onlineund o�ine gehen können. Die Instanz von StreamingPeer hat ein StreamingStatistik-Objekt, übergibt anderen Klassen - falls Messungen erforderlich - eine Referenz auf diesesObjekt und gibt am Ende jedes Simulationsschrittes die gemessenen Werte als PeerEvent

62

5.3. VORGEHENSMODELL KAPITEL 5. IMPLEMENTIERUNG

zurück. Die Messwerte sammelt die Klasse simbench.SimBenchGlobalEventHandler einund gibt sie aus. Auÿerdem speichert diese Klasse die Verbindungsstruktur als gerichtetenGraph ab.

Da SimBench ein nützliches Tool zur Evaluierung von P2P-Protokollen darstellt, solltees zum Test von zukünftigen Implementierungen möglichst problemlos eingesetzt werdenkönnen. Für eine direkte Einbindung als Library gilt es, zukünftig Folgendes zu berück-sichtigen:

� Es sollte ein P2P-Protokoll implementiert und getestet werden, das auf die vorhan-dene SimBench-Funktionalität (insbesondere Dateiverteilung) zurückgreift.

� SimBench wird von Entwicklungsbeginn an eingebunden, so dass die Struktur derProtokoll- Implementierung an SimBench leicht angepasst werden kann. Eine späte-re Integration des Benchmarkssystems emp�ehlt sich aufgrund seiner Komplexitätnicht.

5.3 Wahl des Vorgehensmodells für Softwareprojekte

Ein Softwareprojekt dient der Entwicklung von Software und zeichnet sich - gemäÿ derDe�nition von Projekten - durch hohe Komplexität aus sowie dadurch, dass ein de�nier-tes Ziel innerhalb einer de�nierten Zeitspanne mit begrenzten Mitteln erreicht werdensoll. Zur Realisierung von Softwareprojekten gibt es verschiedene Vorgehensmodelle. Vor-gehensmodelle sollen dabei die komplexen Prozesse strukturieren, mit dem Ziel, Zeit undKosten zu sparen sowie die Qualität zu verbessern. [pta07]

Bei den klassischen Vorgehensmodellen lassen sich folgende unterscheiden:

Wasserfallmodell Das Wasserfallmodell trennt die Phasen Analyse, Design, Implemen-

tierung, Test und Einsatz zeitlich strikt voneinander. Erst nachdem alle Komponenten�auf dem Papier� entwickelt wurden, können sie implementiert werden. Und erst nachFertigstellung der Implementierung folgt der Test derselbigen. Dies ist nur bei sehr ein-fachen Projekten praktikabel.

Spiralmodell Hier handelt es sich um eine weniger starre Weiterentwicklung des Was-serfallmodells. Die Phasen können sich wiederholen. Vor der Implementierung müssendennoch ein Grob- und ein Feinentwurf erfolgen, die als Vorgabe für die Implementie-rung gelten.

V-Modell Statt einer zeitlich strikten Abfolge werden Aktivitäten und Ergebnisse (z.B.Modultest) de�niert. Das V-Modell ist teilweise sehr bürokratisch und wird in Projektender ö�entlichen Hand verwendet.

63

5.3. VORGEHENSMODELL KAPITEL 5. IMPLEMENTIERUNG

RUP (Rational Uni�ed Process) Bei RUP handelt es sich um ein objektorientiertesVorgehensmodell für groÿe Projekte, bei dem der Aufwand für die vorgeschriebene Do-kumentation sehr groÿ ist.

Die oben genannten Vorgehensmodelle haben den Nachteil, dass sie strenge Vorgabenmachen und in der Praxis recht un�exibel sind. Es wird nicht berücksichtigt, dass sichAnforderungen und Prioritäten während des Projektverlaufs meist ändern und ein voll-ständiger und korrekter Entwurf des Systems vorab nicht machbar ist. Dazu ist deradministrative Aufwand sehr hoch, was wiederum die Projektdauer verlängert.

Diese Probleme lösen sogenannte agile Vorgehensmodelle. Sie sollen den bürokratischenAufwand verringern und die Projektdurchlaufzeiten verkürzen. Sie sehen nur wenige Re-geln vor, die �exibel angewandt werden können. Es wird nur soviel Dokumentation erstelltwie unbedingt nötig.

Man unterscheidet folgende agile Vorgehensmodelle:

XP (Extreme Programming) Bei XP ist der Auftraggeber von Beginn an in den Ent-wicklungsprozess eingebunden und liefert die zu erwartenden Ergebnisse für Tests. Paareaus Programmierern arbeiten beim Erstellen des Codes zusammen und überprüfen re-gelmäÿig den Code anderer Programmierer (Rapid Code-Reviews).

TDD (Testgetriebene Entwicklung) TDD betont die Wichtigkeit von Tests noch stär-ker als XP. Man führt automatisierte Modultests durch sogenannte Unit-Tests durch.Zuerst wird der Testfall erstellt und dann die dazugehörige Komponente entwickelt.

Für die Implementierung eines P2P-Streaming-Protokolls in P2PNetSim wurde in Ab-schnitt 5.1 festgelegt, dass regelmäÿige Tests auÿerhalb des Simulators unverzichtbarsind. P2P-Streaming-Protokolle zeichnen sich darüber hinaus durch hohe Komplexitätaus. Trotz der Vorstellung des CoolStreaming-Protokolls in [ZL+05] sind viele Aspek-te nicht beschrieben, so dass ein vollständiger Entwurf vor der Implementierung nichtmöglich war. Daher wurde für die vorliegende Implementierung kein klassisches Vor-gehensmodell der Softwareentwicklung gewählt, sondern auf Prinzipien der agilen Soft-wareentwicklung zurückgegri�en. Kundenorientierung und Paarprogrammierung wurdenverständlicherweise nicht angewandt.

Die Softwareentwicklung erfolgte nach folgenden agilen Methoden:

� Minimale Implementierung

� Ständige Modultests (Unit-Tests)

� Permanente Integration der Änderungen in das Gesamtsystem P2PNetSim undDurchführung von Integrationstests

� Ständige Refaktorisierung von Codeteilen

Insbesondere eine minimale Implementierung zusammen mit der ständigen Überarbei-tung des Codes verhindern, dass mehr Funktionen implementiert werden als womöglichbenötigt werden. D.h. im ersten Schritt wird nur soviel umgesetzt wie für den Simula-tionsablauf nötig und durch die CoolStreaming-Autoren vorgegeben. Andernfalls besteht

64

5.4. MODULE KAPITEL 5. IMPLEMENTIERUNG

das Risiko, dass durch die Implementierung zu vieler Eventualitäten das Verhalten desProtokolls zu stark vom Original abweicht. [pta07]

5.4 Implementierung der Module

Die Implementierung des CoolStreaming-Protokolls in den Simulator P2PNetSim erfolgtein Java. Das Protokoll wurde dazu in zentrale Klassen und Module zerlegt.

Die zentrale Komponente ist der Streamingpeer, der Nachrichten des abstrakten TypsStreamingMessage mit Partnern und sonstigen Peers im Overlay austauscht, siehe Ab-bildung 5.2.

Partner

Partner

Partner

CoolStreaming-Overlaynetzwerk

Partnershipmanager Membershipmanager

Scheduler Puffer Player

Partner

Peer

Request Streamsegmente Buffermap Membership-Message

Streamingpeer

Partnerliste mCacheDatenmanager

PeerPeer

Peer

Peer

Peer

Abbildung 5.2: Implementierung des CoolStreaming-Peers

5.4.1 Überblick

Jeder neue Peer muss zuerst Partnerschaften zu anderen Peers aufbauen, um Streamdatenaustauschen zu können.

Ein neuer Peer kennt zunächst nur die IP-Adresse der Quelle. Nach dem Join kontaktierter die Quelle mit einer Hello-Nachricht. Die Quelle schickt ihm in einer HelloReply-Nachricht eine Liste mit IP-Adressen möglicher Partnerkandidaten. Um eine Partner-schaft aufzubauen, muss der Peer eine TCP-Verbindung zu einem Partnerkandidat er-stellen. Er schickt ein TCPSYN an den Kandidaten, der die TCP-Verbindungsanfrage

65


annimmt (mit TCPACK) oder ablehnt (mit TCPNAK). In der Konstante MAX_PARTNERkann die maximale Partneranzahl pro Simulationslauf de�niert werden. In [ZL+05] emp-fehlen die CoolStreaming-Autoren 4 bis 6 Partner.

Der Peer speichert seine Partner in der Partnerliste. Die Partner tauschen regelmäÿigdrei Arten von Nachrichten aus: Bu�ermaps, Datenrequests und die eigentlichen Daten(die Streamsegmente).

Ein Partner, der Daten in seinem Pu�er vorliegen hat, kommuniziert den Pu�erinhaltmit einer Bu�ermap. Die Bu�ermap repräsentiert den Pu�er in Form eines Bit-Strings.Jedes vorhandene Segment wird mit einer �1� dargestellt, nicht vorhandene mit einer�0�. Auÿerdem enthält die Bu�ermap einen O�set, d.h. die ID (Variable segment_id)des ersten Pu�ersegments. Daraus lassen sich die IDs aller weiteren Segmente im Pu�erermitteln.

Nachdem ein neuer Peer Bu�ermaps seiner Partner erhalten hat, ermittelt sein Scheduler,bei welchem Partner der Peer welche Segmente anfordern soll. Dabei werden die seltenenSegmente, die nur bei einem Partner vorhanden sind, zuerst berücksichtigt. Der Peerschickt dann einen Request an die Partner. Die angeforderten Segmente werden vomSupplier-Peer über die TCP-Verbindung einzeln verschickt und beim Empfänger-Peersortiert in den Pu�er eingefügt. 10 Sekunden nach Erhalt des ersten Segments beginntdie Datenwiedergabe durch den Player. Nach [ZL+05] wird pro Sekunde ein Segmentabgespielt. Tri�t ein Segment nicht rechtzeitig ein, kann es nicht abgespielt werden.

Neben den Nachrichten, die nur Partner untereinander austauschen, werden noch soge-nannte Membership-Messages versandt. Jeder Peer erstellt regelmäÿig eine Membership-Message mit einer TTL in Sekunden. Diese Nachricht wird per Gossiping an einen zufälligausgewählten Peer aus der partiellen Sicht (hier mCache genannt) verschickt. Solange dieTTL einer Membership-Message gültig ist, wird die Nachricht per Gossiping im Netzwerkweitergeleitet. Dadurch lernen die Peers neben ihren Partnern weitere Peers im Netzwerkkennen.

Verlässt ein Peer das Netzwerk kann er sich �gracefully� verabschieden. Er erstellt eineDeparture-Message, die per Gossiping im Netz verbreitet wird. Die Empfänger dieserDeparture-Message wissen, dass der Erzeuger der Nachricht das Netz verlassen hat undlöschen ihn aus der partiellen Sicht, ihrem mCache.

Bei P2PNetSim wird jeder Peer zu Simulationsbeginn durch den Aufruf der configure()-Methode einmal initialisiert. Während einer Simulation kann der Peer sich somit mehr-mals mit dem Netzwerk verbinden und sich wieder abmelden, ohne dass seine Mem-bervariablen reinitialisiert werden. Daher muss in der Implementierung der Peer beimLeave alle temporären Daten dieser Sitzung löschen. Beim Verlassen beendet der Peerdie TCP-Verbindungen zu den Partnern durch Versand einer TCPFIN-Nachricht undlöscht danach die Partner aus der Partnerliste. Er löscht die Inhalte der Nachrichten-queues, der partiellen Netzwerksicht (mCache), des Pu�ers und des Players.

Ist ein Peer o�ine, werden alle Nachrichten, die an seine Adresse gesandt werden, miteiner �HostUnreachable�-Nachricht beantwortet.

66


5.4.2 Datentransport

P2PNetSim simuliert IP, aber keine Protokolle der Transportschicht. Da es sich meinerMeinung nach emp�ehlt, Daten an die Partner mit einer leichtgewichtigen TCP-Variantezu verschicken und Daten an alle anderen Peers mit UDP (siehe 4.2.6.4), müssen in derCoolStreaming-Implementierung die wichtigsten Funktionalitäten von TCP und UDPintegriert werden. Insbesondere werden der TCP-Handshake zum Aufbau von Partner-schaften benötigt und die Möglichkeit, parallele Verbindungen zu simulieren.

Die Partner verbinden sich per TCP. Der Austausch der Daten sowie der Kontrollnach-richten erfolgt über diese Verbindung. Dazu wird ein TCP-Handshake mit den Nachrich-ten TCPSYN und TCPACK simuliert. TCPFIN beendet die Verbindung. Eine Bestäti-gung von TCPACK oder TCPFIN muss nicht implementiert werden, da in der Simula-tionsumgebung im Unterschied zum realen Internet keine Pakete verloren gehen können.Der Sender eines TCPACK- oder TCPFIN-Segments kann davon ausgehen, dass derEmpfänger das Segment erhält.

Da P2PNetSim die Nachrichten aus der Eingangs- bzw. Ausgangsqueue sequentiell aus-liest und bearbeitet, könnten groÿe Nachrichten (mit Streamsegmenten) die Queue ver-stopfen und den Versand bzw. Empfang kurzer Kontrollnachrichten verzögern. Um diesesProblem zu umgehen, werden Kontrollnachrichten bis zu einer vorde�nierbaren Gröÿe vorden Datennachrichten versandt bzw. empfangen.

CoolStreaming verschickt angeforderte Datensegmente in korrekter Reihenfolge mittelsRTP über ein Transportprotokoll [ZL+05]. Die RTP-Funktionalität wird wie folgt im-plementiert:

� Jedes StreamSegment-Objekt hat eine eindeutige segment_id.

� Werden mehrere Segmente bei einem Peer angefordert, so verschickt der Sender dieSegmente nach ihrer segment_id in aufsteigender Reihenfolge.

� Sollten die Segmente beim Empfänger nicht in der angeforderten Reihenfolge an-kommen, werden sie sortiert in den Pu�er eingefügt.

Alle der oben genannten Funktionalitäten werden durch den Datenmanager implemen-tiert, da sie den Datenversand und -erhalt betre�en.

Der Datenversand kann aufgrund von geringen Uploadbandbreiten der Sender-Peers ver-zögert werden. Dies wurde durch die Klasse Bandbreitenregulator realisiert (siehe Ab-schnitt 5.4.9.2). Falls beim sendenden Peer die Uploadbegrenzung greift und beim emp-fangenden Peer die Downloadbegrenzung, wird der Empfang einer Nachricht doppeltverzögert (erst beim Upload, dann beim Download). Theoretisch müssten hier die Seg-mente fragmentiert verschickt werden. Eine Implementierung der Fragmentierung waraus folgendem Grund dennoch nicht erforderlich: Eine doppelte Verzögerung aufgrundder Bandbreite kann nur dann eintreten, wenn die Downloadbandbreite des Empfän-gers kleiner ist als die Streamingrate und der Peer weniger als ein Segment pro Sekundeempfangen kann. Um am Streamingprozess teilnehmen zu können, muss die Download-bandbreite eines Peers aber mindestens so groÿ wie die Streamingrate sein. Daher mussdieser Sonderfall nicht bei der Implementierung berücksichtigt werden.

67


5.4.3 Die Klasse StreamingMessage

Alle Nachrichten beim P2P-Streaming sind vom abstrakten Typ StreamingMessage. Je-de StreamingMessage-Instanz wird durch die Variable identifier (vom Typ String)charakterisiert. Der identifier-String enthält den Nachrichtentyp, die Sendezeit in Si-mulationsschritten, den Absender und den Empfänger. Der identifier-String bietetfolgende Vorteile:

� Die Kennung ist menschenlesbar und eignet sich für die Ausgabe in Logmeldungen.

� Bei der Weiterleitung eines StreamingMessage-Objekts werden zwar der Sender(getSender()) und der Empfänger (getRecipient()) neu gesetzt, aber der ur-sprünglich zugewiesene Wert der Variable identifier bleibt unverändert. Da-durch kann der ursprüngliche Sender und der Zeitpunkt der Erzeugung der Strea-mingmessage jederzeit ausgelesen werden, z.B. beim Empfang einer weitergeleitetenGruppennachricht (Membership-Message, Departure-Message).

Beim Erhalt eines StreamingMessage-Objekts setzt der Peer in dem StreamingMessage-Objekt die Empfangszeit in Simulationsschritten und die Latenz in Simulationsschritten,die sich aus der Di�erenz zwischen Empfangszeit und Sendezeit berechnet.

5.4.4 Die Klasse StreamingPeer

CoolStreaming unterscheidet nicht zwischen gewöhnlichen Peers (Supplier und Receiver)und der Quelle (reiner Supplier). Die Quelle ist ein Peer mit folgenden Besonderheiten:

� Pu�ergröÿe: Der Quellpu�er ist halb so groÿ. In der Standardkon�guration umfasster 30 statt 60 Segmente und damit Videodaten für 30 Sekunden Abspielzeit.

� Pu�erinhalt: Abgesehen von den ersten 29 Sekunden der Simulation, während dererder Pu�er erst befüllt werden muss, ist der Quellpu�er immer voll. Jede Sekundewird ein Segment ans Ende des Pu�ers angehängt und das älteste Segment gelöscht.

� Datenaustausch: Weder fordert die Quelle Daten an noch erhält sie Daten. DieQuelle ist ein reiner Supplier.

Bei der Implementierung des CoolStreaming-Peers wurde aus Gründen der Übersicht-lichkeit und späteren Erweiterbarkeit zwischen der abstrakten Klasse StreamingPeer

unterschieden, die Grundfunktionalitäten zur Verfügung stellt, und der konkreten Imple-mentierung als Klasse PullStreamingPeer.

StreamingPeer ist abgeleitet von der abstrakten P2PNetSim-Klasse Peer. Bei der KlasseStreamingPeer handelt es sich um eine generische Klasse, die den Peer samt Member-variablen initialisiert und Prozeduren für Join und Leave implementiert. Die wieder-kehrenden Aufgaben (Nachrichtenempfang, Nachrichtenversand und Overlay-Wartung)erscheinen als abstrakte Methoden empfangeNachrichten(), sendeNachrichten() undrepariereOverlay() in der doSim()-Methode.

PullStreamingPeer, abgeleitet von StreamingPeer, implementiert die abstrakten Me-thoden empfangeNachrichten(), sendeNachrichten() und repariereOverlay() nachden Vorgaben des Protokolls.

68


5.4.5 Hauptmodule eines Streamingpeers

Für die CoolStreaming-Implementierung im Rahmen dieser Arbeit war es wichtig, dieLogik vom Peer in die Module zu verlagern, um so einen übersichtlichen Peer zu erhal-ten und die komplexen Teile auÿerhalb von P2PNetSim testen zu können. Neben denCoolStreaming-Modulen Membershipmanager und Partnershipmanager wurde als weite-res Modul der Datenmanager konzipiert (siehe auch Abbildung 5.2).

Während der Streamingpeer Nachrichten versendet und empfängt, erfolgt die Verarbei-tung der Nachrichten in den Modulen Datenmanager, Partnershipmanager oder Member-shipmanager. Die Module übernehmen damit die Hauptaufgaben jedes CoolStreaming-Peers, d.h. die Datenwiedergabe (Playback), den Datenaustausch und die Wartung desOverlays, siehe Abbildung 5.3.

Aufgaben des CoolStreaming-Peers

Hauptmodule im StreamingpeerDatenwiedergabe

Datenmanager

Datenaustausch

Overlaywartung

Membershipmanager

Partnershipmanager

Abbildung 5.3: Zuordnung von Aufgaben zu Hauptmodulen beim CoolStreaming-Peer

Die Datenwiedergabe und der Datenaustausch werden durch den Datenmanager geregelt.Für die Wartung des P2P-Streaming-Overlays sind sowohl der Membershipmanager alsauch der Partnershipmanager zuständig. Der Membershipmanager speichert die partielleSicht auf das Overlay, d.h. er kennt Peers im Netzwerk. Über den Partnershipmanagerwerden TCP-Verbindungen zu einigen dieser Peers aufgebaut.

Membershipmanager Jeder Peer Pi kennt andere Peers im Netzwerk, die jeweils ein-deutige Bezeichner haben und bei CoolStreaming Members genannt werden. Der Peer Pi

speichert und verwaltet seine Kontakte zusammen mit deren eindeutigen Bezeichnern ineiner eigenen Datenstruktur, dem mCache (Kurzform von Membership-Cache):

MCACHEPi ⊂ V

Da der Peer Pi sich selbst nicht in seinem MCACHEPi speichert, stellt der mCachestets eine echte Teilmenge der Peers im Netzwerk dar. Der mCache bietet dem Peer einepartielle Sicht auf das P2P-Overlay. Für den Aufbau und Erhalt dieser partiellen Sichtist der Membershipmanager zuständig.

69


Partnershipmanager Der Partnershipmanager baut Partnerschaften auf und verwaltetdiese. Die Menge der Partner des Peers Pi kann de�niert werden als:

PARTNERPi ⊆MCACHEPi ⊂ V

Die Menge der Partnerschaftsbeziehungen EPi des Peers Pi stellen eine Teilmenge allerPartnerschaftsbeziehungen im Netzwerk dar:

EPi ⊆ E

Datenmanager Der Datenmanager regelt die Datengenerierung, den Datenaustausch,die Speicherung der Datensegmente im Pu�er sowie die Datenwiedergabe. Nur der Da-tenmanager kann direkt auf Pu�er, Player und Scheduler zugreifen.

Von den zentralen koordinierenden Klassen AbstractDatenManager (im Datenmanager-Modul) und AbstractPartnershipManager (im Partnershipmanager-Modul) ist jeweilseine Klasse für die Quelle und eine für gewöhnliche Peers abgeleitet (siehe Abbildung5.4).

Abbildung 5.4: Klassendiagramm der Hauptmodule

Jedes der drei Hauptmodule Datenmanager, Partnershipmanager und Membershipmana-ger liegt in einem eigenen gleichnamigen Paket zusammen mit den dazugehörigen Klassen.Die drei Pakete werden im Folgenden vorgestellt.

5.4.6 Das Paket datenmanager

Im Paket datenmanager liegen alle Klassen, die die Datengenerierung, den Datenaus-tausch und die Wiedergabe betre�en.

70


5.4.6.1 Die Klasse DatenManager

Die Klasse DatenManager dient als Verbindungsglied zwischen dem Streamingpeer undPu�er, Player, Scheduler. Sie kontrolliert die Zugri�e auf den Pu�er, die Übergabe derSegmente an den Player und die Ausführung des Schedulers. Bei Aufruf des Schedulersübergibt das DatenManager-Objekt die IDs von den fehlenden Segmenten. Dabei werdennur die fehlenden Segmente berücksichtigt, die bisher noch nicht angefordert wurden, umso doppelte Datenrequests zu vermeiden.

5.4.6.2 Die Klasse P2PStream

Ein Stream ist eine ununterbrochene Folge von Segmenten. In der vorliegenden Imple-mentierung wurde der Stream in der Klasse P2PStream implementiert, die eine Folgegleich groÿer Segmente vom Typ StreamSegment mit eindeutiger fortlaufender Nummerverwaltet.

Zu Simulationsbeginn initialisiert die Quelle den Stream. Da nach [ZL+05] jedes Segmenteine Sekunde Video umfasst, lässt das DatenManager-Objekt der Quelle pro Sekunde einneues Segment erzeugen.

In einem Single-Source-P2P-Streaming-System kann die Quelle beim Zugri� auf dasnächste Streamsegment dieses direkt löschen. Für ein zu implementierendes Multi-Source-System, bei dem mehrere Quellen denselben Stream verteilen, müssten der Stream anzentraler Stelle verwaltet werden und die Quellen jeweils eine Kopie erhalten.

5.4.6.3 Die Klasse StreamSegment

Ein Stream besteht aus einer ununterbrochenen Folge gleich groÿer Segmente. Nach[ZL+05] umfasst jedes Segment eine Sekunde Video. Die Gröÿe der Segmente in Bytesist variabel und richtet sich nach der Streamingrate.

In der vorliegenden Implementierung wurde das Segment in der Klasse StreamSegment

umgesetzt. Jedes StreamSegment-Objekt hat eine eindeutige fortlaufende Nummer (intsegment_id), kennt die ID des Streams (int stream_id) und den Zeitpunkt seinerErstellung in Sekunden (double creation_time). Aufgrund der im Internet üblichenStreamingrate von ca. 400 kbps [LGL08, PM08] wurde die Gröÿe des einsekündigenStreamsegments in der Simulation auf 50 kB festgelegt. Dieser Wert kann geändert wer-den (siehe Konstante SEGMENT_SIZE).

5.4.6.4 Die Klasse SegmentID

Jedes StreamSegment-Objekt hat eine fortlaufende eindeutige Nummer vom Typ int.Da beim Live-Streaming im Gegensatz zu Video-On-Demand Endlosstreams übertragenwerden, muss die Nummerierung zyklisch erfolgen. Die Protokolle geben in der Regeleinen maximalen Integer-Wert an, nach dem es zu einem Rollback kommt, d.h. dieNummerierung beginnt wieder bei 0. Ein CoolStreaming-Segment umfasst eine SekundeVideo und eine segment_id kann maximal 2 Byte belegen, also höchstens den Wert

71


65535 annehmen. Nach 18 Stunden, 12 Minuten und 15 Sekunden kommt es also zueinem Rollback, wobei die Autoren in der Protokollbeschreibung grob aufgerundet voneinem Rollback nach 24 Stunden sprechen [ZL+05].

Bei anderen Protokollen variiert die höchstmögliche Segmentnummer je nach Segment-gröÿe. GoalBit lässt z.B. eine Nummerierung von 0 bis 231 zu [BV+09]. Die Verwaltungder zyklischen Nummerierung wurde der Übersichtlichkeit halber in die separate KlasseSegmentID ausgelagert, auf die nur die P2PStream-Instanz zugreift.

5.4.6.5 Die Klasse Pu�er

Die CoolStreaming-Autoren haben zum Pu�er nur bekanntgegeben, dass er in Form einesSliding-Windows organisiert ist und in Simulationen 60 bzw. 120 Segmente zu je einerSekunde Video umfasste [ZL+05].

Für die Implementierung des Pu�ers in einem P2P-Live-Streaming-System emp�ehlt essich, einen Ringpu�er zu verwenden, da die Videodaten nur für einen kurzen Zeitraum imPu�er gespeichert werden müssen und ein Ringpu�er e�zient implementiert werden kann.Der Ringpu�er wurde durch ein Array aus standardmäÿig 60 StreamSegment-Objektenrealisiert, wobei die Pu�ergröÿe verändert werden kann (siehe Konstante PUFFER_SIZE).Zwei Variablen (int firstindex, int firstsegment_id) speichern jeweils den aktuellenIndex und die segment_id des ersten Ringpu�er-Elements.

Ein P2P-Live-Streaming-Pu�er muss auch ältere bereits abgespielte Videosegmente spei-chern, so dass diese älteren Segmente auf Anfrage noch ausgeliefert werden können. InAnlehnung an [BM+09] habe ich mich entschieden, den Pu�er wie folgt zu organisieren(siehe Abbildung 5.5):

PLAYBACK_POS = aktuelle Abspielposition

Quellpuffer 20 21 494822 47...... ......

Peerpuffer 35 36 37 39 416 7 8 3433...... ......

8

41

veraltetes, bereits abgespieltes Segment

neues, noch abzuspielendes Segment

Abbildung 5.5: Peerpu�er und Pu�er der Quelle (PUFFER_SIZE=60)

Die Konstante PLAYBACK_POS gibt an, an welcher Stelle im Pu�er das aktuell abzuspie-lende Segment liegt.

PLAYBACK_POS wird de�niert als: PLAYBACK_POS=PUFFER_SIZE/2 - 1

Bei gewöhnlichen Peers liegt das nächste abzuspielende Segment immer in der Pu�ermit-te. Bei der Quelle liegt das aktuelle Segment am Ende des Pu�ers, da der Quellpu�er nur

72


halb so groÿ ist wie der Peerpu�er. PLAYBACK_POS wird auch verwendet, um das allerersteSegment an der richtigen Stelle im Pu�er zu speichern, d.h. bei den Peers in der Pu�er-mitte und bei der Quelle am Pu�erende. Beim Speichern des allerersten Segments werdenauch die Variablen firstindex und firstsegment_id gesetzt. Alle Segmente, die spätereintre�en, werden dann anhand dieser Variablen sortiert in den Pu�er eingefügt.

Der Zugri� auf den Pu�er erfolgt über den Datenmanager, der neue Segmente einfügtoder jeweils das älteste Segment aus dem Pu�er löscht, indem er den Ringpu�er um einSegment nach links verschiebt.

5.4.6.6 Die Klasse Scheduler

Der Scheduler errechnet, von welchen Partnern und in welcher Reihenfolge fehlende Datenangefordert werden. Dabei berücksichtigt er auch die Uploadkapazitäten der Partner.

Das DatenManager-Objekt teilt dem Scheduler zunächst mit, welche Segmente ange-fordert werden müssen. Dann ruft das DatenManager-Objekt die Scheduler-MethodeScheduler.berechneSupplier() auf und übergibt eine Kopie der PartnerListe, dieneben den Bu�ermaps auch die geschätzten Uploadbandbreiten der Partner enthält.Scheduler.berechneSupplier() liefert ein Objekt des Typs Supplier zurück. Supplierverwaltet eine Hashtabelle, in der jeweils die Netzwerkadresse eines Partners auf die beiihm anzufordernden Segmente zeigt. Der Supplier für die fehlenden Segmente mit seg-ment_id 29 und 30 wird in der toString()-Ausgabe z.B. wie folgt angezeigt:

10.0.0.1/32:29:30

Bei einem neuen Peer, dessen Pu�er noch leer ist, muss der Scheduler zunächst ermitteln,ab welcher Abspielposition, d.h. ab welcher segment_id, er Daten anfordern soll. DieKlasse FirstOffset bietet dazu verschiedene Methoden an.

5.4.6.7 Die Klasse FirstO�set

Ein neuer Knoten mit leerem Pu�er fordert anhand der Partner-Bu�ermaps Daten an.Dabei muss zunächst ein O�set gewählt werden, die segment_id des ersten Segmentsder anzufordernden Datensequenz. CoolStreaming spezi�ziert die Wahl nicht. Nach demStudium anderer Protokolle (z.B. [BM+09]) wurden folgende Möglichkeiten implemen-tiert:

� getMostFrequently(): Wähle den O�set, der bei den Partnern am häu�gsten vor-kommt. Falls mehrere O�sets gleich oft vorkommen, wähle den niedrigeren Wert(d.h. die segment_id des älteren Segments).

� getSmallest(): Wähle immer den niedrigsten O�set.

Die Implementierung weiterer Verfahren ist hier aufgrund der Kapselung möglich. DieWahl eines O�sets per Zufall erachte ich in der Simulation nicht für sinnvoll, da dies dieNachvollziehbarkeit und die Veri�zierbarkeit durch Modultests behindert.

Da die Abspielposition des nächsten abzuspielenden Segments (PLAYBACK_POS) in derMitte des Pu�ers liegt, muss der O�set (Variable offset) ab dieser Position zurückge-geben werden (offset + PLAYBACK_POS).

73


5.4.6.8 Die Klasse Player

Die Klasse Player dient dazu, die Wiedergabe eines Segments zu simulieren. NachProtokollspezi�kation wurde der Start der Wiedergabe zunächst auf 10 Sekunden nachErhalt des ersten Segments gesetzt. Dieser Wert wurde später aus Optimierungsgründenerhöht (siehe Abschnitt 6.2).

Player wurde so einfach wie möglich gehalten und von den restlichen Klassen gekapseltimplementiert. Die Klasse kennt lediglich die segment_id (Variable int playback_point)und den Abspielzeitpunkt in Sekunden (Variable double playback_time) des nächs-ten abzuspielenden Segments. Beide Werte (playback_point, playback_time) kann diePlayer-Instanz zurück liefern.

Der Zugri� auf Player erfolgt nur über die Klasse DatenManager und dessen doPlay()-Methode. Zur Wiedergabe eines Segments liest das DatenManager-Objekt die Variableplayback_point aus, holt das entsprechende Segment aus dem Pu�er und übergibt esdem Player durch Aufruf von Player.play(StreamSegment segment). Ist das abzu-spielende Segment nicht im Pu�er und kann nicht wiedergegeben werden, gibt Player

eine Fehlermeldung aus. Dann inkrementiert Player die Variablen playback_point undplayback_time jeweils um �1�, da pro Sekunde ein Segment abgespielt wird.

Auch der Datenmanager der Quelle (Klasse DatenManagerQuelle) hat einen Player, wo-bei hier in jeder Sekunde ein neues Segment erzeugt wird, so dass der Zeitpunkt derErzeugung dem Abspielzeitpunkt (playback_time) entspricht.

Nach der Wiedergabe eines Segments verschieben das DatenManager-Objekt und dasDatenManagerQuelle-Objekt den Ringpu�er um ein Segment nach links.

5.4.7 Das Paket partnershipmanager

Der Partnershipmanager baut Partnerschaften zu anderen Peers im Netzwerk auf, indemer TCP-Verbindungen zu diesen Peers erstellt. Er verwaltet die Partner in einem Objektder Klasse PartnerListe.

5.4.7.1 Die Klasse Partner

Zu jedem Partner werden folgende Werte gespeichert: die Netzwerkadresse, die aktuelleBu�ermap, die geschätzte Uploadbandbreite, die Anzahl der gelieferten Segmente undder Zeitpunkt, seitdem der Partner aktiv ist.

Die geschätzte Uploadbandbreite stellt hier einen sehr wichtigen Aspekt dar, da der Sche-duler auf die Bandbreitenschätzung zurückgreift. Wird die Bandbreite eines Partners un-terschätzt, fordert der Scheduler bei diesem zu wenig Segmente an und die zur Verfügungstehende Bandbreite wird schlecht genutzt. Bei einer zu hoch veranlagten Bandbreite,kann ein Partner mit Segmentanforderungen überschwemmt werden. Obwohl die Quali-tät des Schedulers auf der Korrektheit der heuristischen Bandbreitenschätzung basiert,haben die CoolStreaming-Autoren über die Bandbreitenschätzung in [ZL+05] nichts ver-ö�entlicht. Lediglich auf Nachfrage bei dem CoolStreaming-Entwickler Xinyan Zhang

74


wurde mir mitgeteilt, dass die Bandbreite anhand der Übertragungsrate der Datenseg-mente ermittelt wird.

Bandbreitenschätzung Ich habe daher drei mögliche Verfahren erkundet, um aufgrunddieser Aussage die Uploadbandbreite zu schätzen:

� Das erhaltene Datenvolumen des Partners wird in Relation zu der Zeit gesetzt,seit der die Partnerschaft besteht. Diese Methode benachteiligt allerdings all jenePartner, bei denen weniger Segmente angefordert werden und die daher wenigerSegmente schicken. Auch wenn sie die angeforderten Segmente in kürzestmöglicherZeit senden, erhöht dies nicht merklich ihre geschätzte Uploadbandbreite, da immerder Gesamtzeitraum betrachtet wird.

� Es wird nicht der gesamte Zeitraum der Partnerschaft betrachtet, sondern lediglichdie Zeit zwischen Anforderung und Eingang der Segmente. Das erhaltene Daten-volumen wird so in Relation zur realen Lieferzeit gesetzt.

� Jedes Segment wird in einem Objekt der Klasse DatenReplyStreamingMessage

versandt, in dem bei Empfang des Segments dessen Latenz (also dessen Liefer-zeit) gesetzt wird. Schickt ein Partner ein Segment, so kann anhand der Latenzund der Segmentgröÿe die aktuelle Bandbreite des Partners als neuebandbreiteberechnet werden. Unter Berücksichtigung eines Gewichtungsfaktors G wird ausder soeben ermittelten Bandbreite (neuebandbreite) und der vorherigen Bandbrei-te (altebandbreite) die tatsächliche Bandbreite nach folgender Formel geschätzt:(neuebandbreite ∗ (1 − G)) + (altebandbreite ∗ G). Der Gewichtungsfaktor Gkann zwischen 0 und 1 liegen. Je niedriger G ist, desto stärker wird die neue Band-breite bei der Schätzung berücksichtigt.

Das letzte Verfahren bietet vor allem den Vorteil, dass sich Änderungen bei der Upload-kapazität eines Partners (wenn z.B. neue Partner hinzukommen oder Partner entfallen)schnell in der ermittelten Uploadbandbreite widerspiegeln. Daher habe ich dieses Verfah-ren implementiert.

5.4.7.2 Die Klasse PartnerListe

Der Partnershipmanager trägt neue Partner in ein Objekt der Klasse PartnerListe

ein, welche die Partner in einer ArrayList verwaltet. Beendet ein Partner die TCP-Verbindung durch Versand von TCPFIN, wird er aus dem PartnerListe-Objekt gelöscht.Alle Segmente, die bei diesem Partner angefordert wurden und noch nicht eingetro�ensind, werden beim nächsten Scheduler-Aufruf bei einem der verbleibenden Partner ange-fordert.

5.4.8 Das Paket membershipmanager

Die zentrale Aufgabe des Membershipmanagers ist die Verwaltung einer partiellen Sichtauf das P2P-Streaming-Netzwerk, d.h. auf den mCache. Informationen über aktive Peerswerden dazu im mCache gespeichert.

75


Die Peers erstellen regelmäÿig eine sogenannte Membership-Message, die eine fortlaufen-de Sequenznummer enthält sowie die Netzwerkadresse, die aktuelle Partneranzahl und dieTTL dieser Nachricht. Die TTL gibt an, wie lange die Informationen der Nachricht gül-tig sind. Die Peers schicken die erstellte Membership-Message an einen zufällig aus demmCache ausgewählten Knoten. Erhält ein Peer eine Membership-Message eines anderenKnotens, leitet er sie auch an einen zufälligen mCache-Knoten weiter.

Verlässt ein Peer das Netz, erstellt er eine Departure-Message. Diese unterscheidet sichvon der Membership-Message nur dadurch, dass die Partneranzahl auf �-1� gesetzt ist.Der Versand und die Weiterleitung erfolgt wiederum an einen zufälligen mCache-Knoten.

Die zentralen Klassen sind hier die Klasse MembershipCache mit der partiellen Sicht aufdas Overlay (dem mCache) und die Klasse MembershipManager, die die Zugri�e des Peersauf den mCache verwaltet.

5.4.8.1 Die Klasse MembershipCache

Der mCache speichert zu jedem Knoten maximal einen Eintrag. Zusätzlich zu den Infor-mationen aus der Membership-Message (Sequenznummer, Netzwerkadresse, Partneran-zahl, TTL) werden die Zeit des letzten Zugri�s (long lastupdatetime) und die Infor-mation, ob es sich bei diesem Knoten um einen Partner handelt, gespeichert.

Erhält ein Peer die Membership-Message eines anderen Knotens, fügt er dessen Daten inden mCache ein, sofern die Netzwerkadresse des Knotens noch nicht gespeichert wurde.Ist der Knoten im mCache vorhanden, wird geprüft, ob die Daten aus der Nachricht dieaktuelleren und zudem noch gültig sind. Dazu muss die Sequenznummer in der Nachrichtgröÿer als die gespeicherte sein und die TTL der Nachricht gröÿer als 0. Nur in diesemFall wird der Eintrag im mCache aktualisiert. Alle Werte aus der Nachricht werdenübernommen und zusätzlich die aktuelle Zeit als lastupdatetime gespeichert. Erhält derPeer eine Departure-Message, löscht er den dazugehörigen Eintrag aus seinem mCache.

Die Quelle trägt auÿerdem in ihren mCache neue Peers ein, die ihr eine Hello-Nachrichtschicken. Dadurch kann die Quelle zu Simulationsbeginn ihren mCache schnellstmöglichmit Partnerkandidaten befüllen. Gewöhnliche Peers speichern die erhaltenen Partnerkan-didaten in ihrem mCache. Zudem tragen Quelle und Peers die Absender von eingehendenTCPSYN-Nachrichten in den mCache ein, sofern sie die Partnerschaftsanfrage annehmenund auf das erhaltene TCPSYN mit TCPACK antworten. Es ist nicht ratsam, bei je-der eingehenden TCPSYN-Nachricht deren Absender zu speichern, da dies unnötigenOverhead verursachen würde.

5.4.8.2 Die Klasse MembershipManager

MembershipManager erstellt Membership-Messages oder Departure-Messages und suchteinen zufälligen Empfänger aus dem mCache aus. Darüber hinaus bearbeitet er eingehen-de Gruppennachrichten, leitet sie weiter und liefert dem Peer eine Liste von möglichenneuen Partnern aus dem mCache.

76


Eine Membership-Message wird nur weitergeleitet, falls die Informationen in der Nach-richt noch gültig sind, d.h. falls die TTL gröÿer 0 ist. Möchte ein Knoten eine erhalte-ne Membership-Message weiterleiten, aktualisiert er zuerst die TTL des dazugehörigenEintrags im mCache. Dazu berechnet er die Zeit, die seit dem letzten Zugri� auf denmCache-Eintrag vergangen ist, und zieht diese von der gespeicherten TTL ab. Darausergibt sich die verbleibende Gültigkeitsdauer für die Knoteninformation. Bei einer TTLkleiner oder gleich 0 wird dieser Eintrag aus dem mCache gelöscht und die Nachrichtwird nicht weitergeleitet.

Der Empfänger einer Departure-Message löscht den mCache-Eintrag des abgegangenenKnotens und leitet die Nachricht weiter, sofern er diese DepartureMessage zum erstenMal erhalten hat. Falls der Empfänger zu einer empfangenen Departure-Message keinenmCache-Eintrag �ndet, hat er entweder die gleiche Nachricht schon in einem früherenSimulationsschritt erhalten (und den Eintrag gelöscht) oder er hatte nie einen mCache-Eintrag zu diesem Knoten. In beiden Fällen (DepartureMessage nicht im mCache) leitetder Empfänger die Nachricht nicht weiter. So kann verhindert werden, dass Nachrichtenin Loops im Netzwerk weitergeleitet werden.

5.4.9 Das Paket util

Die Klassen im Paket util sind nicht an die vorliegende CoolStreaming-Implementierunggebunden. Sie können unabhängig von dieser verwendet werden und stellen grundlegendeFunktionalitätserweiterungen für P2PNetSim dar.

Die Klasse Bandbreitenregulator ermöglicht den verzögerten Versand von Nachrich-ten gemäÿ der Upload- und Downloadbandbreite der Peers. Die Logger-Klasse MyLoggererweitert den P2PNetSimLogger um die Möglichkeit des Loggens in fünf verschiedenenLogleveln mit vereinheitlichten Logmeldungen. Die Klasse Zeit ermöglicht die Umrech-nung von Simulationsschritten in Sekunden und umgekehrt.

5.4.9.1 Die Klasse MyLogger

MyLogger verwendet die Syslog-Loglevel DEBUG, INFO, WARN, ERROR und FATAL, welchedurch ihre numerische Entsprechung (0-4) gesetzt werden.

Eine Klasse, die Logmeldungen ausgeben und ihren eigenen Loglevel verwalten soll, be-nötigt ein eigenes MyLogger-Objekt. Bei der Entwicklung neuer Klassen hat sich dies alssehr hilfreich erwiesen. Während der Entwicklung einer Klasse werden beispielsweise alleMeldungen einschlieÿlich DEBUG ausgegeben, bei der fertiggestellten Klasse dagegen nurnoch Meldungen gröÿerer Wichtigkeit (z.B. ab ERROR).

Der MyLogger-Konstruktor erhält eine Referenz auf ein Objekt der P2PNetSim-KlasseP2PNetSimLogger, den Loglevel als int-Wert, die Peeradresse als String sowie den Na-me der loggenden Klasse als String. Zu Beginn jedes Simulationsschrittes setzt dieStreamingPeer-Instanz den Wert der statischen Variable MyLogger.logsimtime auf dieaktuelle Simulationszeit, so dass diese zusammen mit den vergangenen Sekunden in allenLogmeldungen ausgegeben werden kann. Eine MyLogger-Logmeldung folgt einem festenAufbau:

77


<LOGLEVEL> <Simulationszeit als simtime/in Sekunden>: <Peer-Adresse> <Logmeldung> (<log-gende Klasse>)

Die Klasse Player gibt z.B. immer eine ERROR-Logmeldung aus, falls ein Segment nichtvor dem Abspielzeitpunkt eintri�t und es daher zu einem Aussetzer kommt. Falls bei-spielsweise der Peer mit Netzwerkadresse �1.0.0.2/32� das Segment mit segment_id=41(=playback_point) nicht abspielen kann, erscheint folgende Logmeldung:

ERROR︸︷︷︸Loglevel

200/20.0sec :︸︷︷︸Simulationszeit

1.0.0.2/32︸︷︷︸Peer−Adresse

AUSSETZER bei playbackpoint = 41︸︷︷︸Logmeldung

(Player)︸︷︷︸LoggendeKlasse

5.4.9.2 Die Klasse Bandbreitenregulator

CoolStreaming berücksichtigt die Partnerbandbreite bei der Anforderung fehlender Seg-mente. Ein Peer fordert nur so viele Segmente von seinem Partner an, wie dieser gemäÿseiner Bandbreite liefern kann.

Ohne Bandbreitenbegrenzung werden in P2PNetSim Nachrichten immer nach einem Si-mulationsschritt zugestellt und pro Simulationsschritt kann ein Peer beliebig viele Nach-richten empfangen. In Version 3.0 ist theoretisch eine Bandbreitenbegrenzung vorgesehen,indem man die maximale Uploadbandbreite als Parameter OutgoingBandwidth bzw. diemaximale Downloadbandbreite als IncomingBandwidth in der XML-Kon�gurationsdateisetzt und die Nachrichtengröÿe implizit durch Aufruf von Message.setContent(String

groesse) übergibt. Als Problem erwies sich, dass bei der Bandbreitenbegrenzung vonP2PNetSim die Lieferzeit von Nachrichten nicht nachvollziehbar variiert. Auch erwies sichdie Abbildung der Nachrichtengröÿe auf den Message.content-String als nicht praktika-bel. Die Bandbreitenbegrenzung wurde daher durch die Klasse Bandbreitenregulator

realisiert.

Der Bandbreitenregulator wirkt zwischen dem Empfang bzw. Versand einer Nachrichtmit den P2PNetSim-eigenen Methoden receive() bzw. send() und dem tatsächlichenZugri� auf die Nachrichten durch die StreamingPeer-Instanz (siehe Abbildung 5.6).

Die StreamingPeer-Instanz initialisiert je ein Bandbreitenregulator-Objekt für Down-load und Upload. Dadurch werden eine Eingangsqueue und eine Ausgangsqueue für Nach-richten angelegt. Die Werte für die Bandbreitenbegrenzungen können mittels der Para-meter upload_bandbreite und download_bandbreite in der XML-Kon�gurationsdateide�niert werden unter Verwendung der Einheit Bytes pro Sekunde.

Zum Versenden einer Nachricht ruft der Peer die Methode mysend() auf, die alle aus-gehenden Nachrichten in der Ausgangsqueue speichert. Am Ende eines jeden Simula-tionsschrittes wird die Methode doSend() ausgeführt, die so viele Nachrichten aus derAusgangsqueue verschickt, wie es die Uploadbandbreite des Peers erlaubt. Alle Nachrich-ten, die in einem Simulationsschritt nicht verschickt werden konnten, verbleiben in derQueue zum Versand in späteren Simulationsschritten.

Zu Beginn jedes Simulationsschrittes werden alle eingegangenen Nachrichten durch Auf-ruf der Methode doReceive() in der Eingangsqueue gespeichert. myreceive() liefert

78


Bandbreitenregulatorverwaltet Messages in Queue

StreamingPeer.doSend():Tatsächlicher Message-Versand mit send()

am Ende des Simulationsschritts

StreamingPeer.myreceive():

StreamingPeer empfängt Message

StreamingPeer.mysend():

StreamingPeer sendet Message

StreamingPeer.doReceive(): Empfang aller Messages mit receive()

zu Beginn des Simulationsschritts

Abbildung 5.6: Zusammenspiel zwischen Bandbreitenregulator und StreamingPeer

dem Peer jeweils eine Nachricht aus der Eingangsqueue zurück, sofern noch genügendDownloadbandbreite zur Verfügung steht. Analog zum Versand bleiben nicht empfang-bare Nachrichten in der Queue.

Zum Empfang und Versand von Nachrichten ruft der Peer also anstatt der P2PNetSim-Methoden receive() bzw. send() die Methoden myreceive() bzw. mysend() auf. DieMethoden myreceive() und mysend() haben die gleiche Signatur wie die P2PNetSim-Methoden receive() und send().

5.4.9.3 Die Klasse Zeit

Die Methoden der Klasse Zeit dienen der Umrechnung von Simulationsschritten in Se-kunden und umgekehrt. Die Anzahl von Simulationsschritten pro Sekunde wird in derKonstante SIMSCHRITTE_PRO_SEC de�niert. Eine Sekunde sollte nach meiner Erfahrungmöglichst aus 10 Simulationsschritten bestehen.

Die Methode getSimtime(double sec) bildet alle Zeitangaben in Sekunden aus derKon�guration auf Simulationsschritte ab. Intern wird die Zeit in Simulationsschrittenübergeben. Für die Ausgabe werden Simulationsschritte wieder in Sekunden umgerech-net.

Die Umrechnungen bieten folgende Vorteile:

� Die Zeitangaben sind menschenlesbar. Das gilt für Logmeldungen als auch für dieAngaben in der Kon�guration (z.B. Bandbreitenbegrenzung für Upload und Down-load in Bytes pro Sekunden).

� Die in der Protokollspezi�kation de�nierten Zeitangaben in Sekunden können direktimplementiert werden (z.B. die Wiedergabe eines Segments pro Sekunde).

� Indem die Peers ihre Aktionen in Intervallen aus Sekunden durchführen (und nichtin Intervallen aus Simulationsschritten), werden die Aktionen zeitlich voneinan-der entzerrt. Dies gestaltet die Logmeldungen übersichtlicher und vereinfacht dieFehlersuche.

79

5.5. TEST KAPITEL 5. IMPLEMENTIERUNG

� Beim Nachrichtenversand können Verzögerungen simuliert werden, die kürzer sindals eine Sekunde. Dies ist insbesondere für die Implementierung des TCP-Hand-shakes wichtig und den Versand der nur wenige Bytes groÿen TCPSYN- undTCPACK-Segmente.

5.4.9.4 Die Klasse StreamingAddress

Für die Implementierung wurde mehrfach ein Set aus Netzwerkadressen benötigt. Bei Ver-wendung eines Sets aus Objekten des Typs Address (com.jnc.p2pnetsim.api.Address)werden fehlerhafterweise gleich lautende Netzwerkadressen mehrmals im Set gespeichert.Zur Problemlösung wurde die Klasse StreamingAddress von Address abgeleitet, dieequals()-Methode überschrieben, wobei der Vergleich zweier Adressen mit Hilfe derDarstellung als long-Wert erfolgt (Address.getAddressAsLong()). Die Netzwerkadres-sen �10.0.0.1/32� und �10.0.0.1� werden danach als identisch erkannt.

StreamingPeer.getAdresse() liefert das StreamingAddress-Objekt zurück, auf das inallen anderen Klassen der Implementierung zugegri�en wird.

5.5 Test der Implementierung

5.5.1 Bedeutung des Testens

Das Testen hat den Ruf, zu den von Entwicklern ungeliebten Aufgaben zu gehören.Ausführliche Tests kosten Zeit. Tests und darauf folgende Fehlersuche und -korrekturenführen dazu, dass ein Projekt auch nach scheinbarer Fertigstellung nicht abgeschlossenwerden kann. Nicht selten benutzen Entwickler Tests nur dazu, die Fehlerfreiheit ihresCodes zu demonstrieren. Man ho�t, dass der Test erfolgreich durchläuft und die mühsameFehlersuche entfällt.

Tatsächlich ist der Sinn von Tests ein anderer. Myers fasst in [Mye04] die Bedeutung desTestens folgendermaÿen zusammen:

�Testing is the process of executing a program with the intent of �ndingerrors.�

Ungetestete Programme sind mit an Sicherheit grenzender Wahrscheinlichkeit fehlerhaft.Je eher diese unentdeckten Fehler gefunden werden, desto schneller und einfacher lassensie sich beheben. Darüber hinaus erhöhen regelmäÿige Test das Vertrauen des Entwicklersin die Richtigkeit seines Codes und damit seine Bereitschaft, Anpassungen und Erweite-rung im Code vorzunehmen.

Die Entwicklung eines Systems sollte mit dem Test einzelner Modul (Modultests/Unit-Tests) beginnen und im späteren Verlauf weitere Tests vorsehen, z.B. den Test der Inte-gration der Komponenten in das Gesamtsystem und Performancetests. [Mye04]

80


5.5.2 Modultests

Bereits in 5.1 wurde die Wichtigkeit von regelmäÿigen Modultests betont, die auÿer-halb von P2PNetSim durchgeführt werden. Für jede kritische Funktion sollten Testfällede�niert werden, um Folgendes zu prüfen:

� Die Funktion soll das ausführen, was von ihr erwartet wird. [Mye04]

� Die Funktion soll nichts ausführen, was nicht von ihr erwartet wird. [Mye04]

Dazu müssen in den Testfällen korrekte und inkorrekte Eingaben oder Szenarien de�niertwerden. Zu Beginn kann das Erstellen von derartigen Testfällen aufwändig erscheinen.In der Tat kann der Testcode so lang wie der Programmcode werden. Sobald das Systemaber eine gewisse Gröÿe hat und aufgrund neuer Informationen refaktorisiert werdenmuss, ermöglichen Unit-Tests e�ziente Anpassungen. Nach jeder Änderung kann manUnit-Tests für das komplette System durchführen und damit erkennen, ob aufgrund dieserÄnderung das System an irgendeiner Stelle bricht oder weiterhin korrekt arbeitet. DieZeitersparnis durch Unit-Tests wächst dabei mit der Gröÿe des Programms.

Gute Unit-Testprogramme sollten nach [Mar09] folgende Eigenschaften haben:

Unabhängigkeit Die Testprogramme sollten unabhängig voneinander auszuführen sein.

Wiederholbarkeit Die Modultests sollten in unterschiedlichen Umgebungen laufen.

Selbstvalidierbarkeit Die Modultests sollten auf boolean-Werte prüfen. So müssen kei-ne Logmeldungen gelesen werden, um herauszu�nden, ob der Test erfolgreich verlief.

5.5.2.1 JUnit in der Praxis

JUnit ist ein komfortables Java-Framework für Modultests. JUnit wurde von Kent Beckund Eric Gamma während eines gemeinsamen Flugs nach Atlanta entwickelt. Beck wollteJava lernen und Gamma interessierte sich für Becks Testframework in Smalltalk. Sie nutz-ten den dreistündigen Flug, um zusammen die Grundzüge von JUnit zu implementieren.[Mar09]

Mit dem JUnit-Plugin für NetBeans kann man automatisiert den Testklassenrumpf zueiner zu testenden Klasse erstellen. Wie in 5.5.2 gefordert, kann die Testklasse unabhängigvon anderen Testklassen ausgeführt werden. Zudem testet die Testklasse auf boolean-Werte, so dass die Eigenschaft der Selbstvalidierbarkeit erfüllt ist.

JUnit-Testklassen können Methoden testen, auf die von auÿerhalb der zu testenden Klas-se zugegri�en werden kann, d.h. Methoden mit den Modi�katoren protected, defaultoder public.

Die Methoden assertEquals() und assertTrue() bzw. assertFalse() ermöglichenTests auf boolean-Rückgabewerte. Es emp�ehlt sich hier, stets assertEquals() zu ver-wenden, da diese Methode die Möglichkeit bietet, Ausgaben zu de�nieren für den Fall,

81


dass ein Test fehlschlägt. Hier ein Beispiel für eine Methode, die die Klasse Puffer testetund prüft, ob der Pu�er nach dem Löschen aller Pu�ersegmente leer ist:

assertEquals(�Alle Segmente aus Puffer gelöscht�, true, instance.istPufferLeer() );

Die Verwendung von assertEquals() in Verbindung mit true/false kann zudem dieÜbersichtlichkeit und die Lesbarkeit des Testcodes erhöhen [Mar09].

In NetBeans können Klassen sehr bequem refaktorisiert werden. Die dabei durchgeführ-ten Änderungen (Umbenennung von Variablen oder Methoden) erfolgen auch in denTestklassen. Die Namen der Testmethoden verändern sich nicht. Beim Verschieben vonDateien muss die Paketstruktur in dem Testpaket manuell angepasst werden.

Unter Umständen sind Stubs zu erstellen, d.h. Klassen, die vom Testobjekt anstelle deseigentlichen Objekts aufgerufen werden. Dies ist in der vorliegenden Implementierungbei den Klassen erforderlich, die separat loggen und ein MyLogger-Objekt im Konstruk-toraufruf instanziieren. Hier habe ich als Ersatz für die MyLogger-Klasse eine KlasseTestLogger innerhalb des Testpakets angelegt, die das Interface P2PNetSimLogger im-plementiert. Logmeldungen werden beim Testdurchlauf auf der Standardausgabe ausge-geben.

5.5.2.2 Exemplarischer Testfall

Der Scheduler ist eine zentrale, sehr komplexe Komponente, die man nur mit Hilfe vonModultests gründlich testen kann. Daher erstellte ich folgenden Testfall, der als Vorlagefür die Implementierung der Testmethoden diente.

Der Scheduler ermittelt vorab, bei welchen Partnern fehlende Segmente angefordert wer-den. Partner, die ein gesuchtes Segment liefern können, sind potentielle Supplier für diesesSegment.

Zu Beginn werden folgende Eingaben benötigt:

� IDs der fehlenden Segmente (seg_id): hier 0-9

� IDs der Partner (part_id): hier 0-4

Zuerst wird ermittelt, welches Segment von welchen Partnern geliefert werden kann. ImRealfall werden die Partner-Bu�ermaps ausgewertet. Im Testfall wurde die Segmentver-fügbarkeit generisch auf die Partner verteilt: Partner 0 hat alle Segmente, Partner 1 hatjedes zweite Segment, Partner 2 jedes dritte, Partner 3 jedes vierte und Partner 4 jedesfünfte Segment verfügbar. In Abbildung 5.7 ist die Segmentverfügbarkeit tabellarischdargestellt.

Im nächsten Schritt sortiert man die fehlenden Segmente nach der Häu�gkeit ihrer Verfüg-barkeit (Rarest-First). Die am seltensten verfügbaren Segmente sollen zuerst erscheinenund damit zuerst vom Scheduler bearbeitet und angefordert werden.

In meinem Testfall erhält man damit folgende sortierte Liste mit IDs fehlender Segmen-te: �0,6,1,2,4,8,3,5,7,9� (siehe 1.Spalte seg_id in der mittleren Scheduling-Tabelle inAbbildung 5.8)

Neben dieser Liste benötigt der Scheduler weitere Eingaben:

82


Abbildung 5.7: Verfügbarkeit von Segmenten (seg_id 0-9) bei Partnern (part_id 0-4)

� sec_segment[part_id] (Übertragungszeit für ein Segment in Sekunden): Anhandder Bandbreite in kB/sec errechnet der Scheduler, wie viele Sekunden ein poten-tieller Supplier benötigt, um ein einzelnes Segment zu verschicken (siehe Spaltesec_segment[part_id] in der obersten Tabelle in Abbildung 5.8).

� deadline (Deadline jedes Segments aus Liste �0,6,1,2,4,8,3,5,7,9�): In diesem Test-beispiel habe ich vorgegeben, dass Segment 0 in max. 2 Sekunden geliefert werdenmuss, damit es rechtzeitig abgespielt werden kann. Segment 0 hat also eine Deadlinevon 2, Segment 1 eine Deadline von 3 usw. (siehe Spalte deadline in der mittlerenScheduling-Tabelle in Abbildung 5.8)

� restzeit[part_id][seg_id] (Restliche Zeit, die einem Partner part_id zur Lie-ferung von Segment seg_id verbleibt): Initial entspricht die Restzeit von Segmentseg_id der Deadline dieses Segments. Wird ermittelt, dass Partner part_id dasSegment 0 liefern soll, so hat Partner part_id weniger Bandbreite für die Liefe-rung der übrigen 9 Segmente. Die Restzeit von Partner part_id für alle folgendenSegmente wird dekrementiert, und zwar um die Zeit, die er zur Lieferung vonSegment 0 benötigt (siehe Spalten restzeit[part_id][seg_id] in der mittlerenScheduling-Tabelle in Abbildung 5.8).

Im letzten Schritt ermittelt der Scheduler aus der Menge der potentiellen Supplier dentatsächlichen Supplier. In der mittleren Scheduling-Tabelle aus Abbildung 5.8 sind dazualle potentiellen Supplier gelb markiert.

Für jedes fehlende Segment aus der Liste �0,6,1,2,4,8,3,5,7,9� geht der Scheduler nachfolgendem Algorithmus vor:

� Gibt es nur einen potentiellen Supplier part_id für das fehlende Segment seg_id,dann fordere Segment seg_id bei part_id an. Dekrementiere die Restzeit vonpart_id für alle verbleibenden fehlenden Segmente.

� Gibt es mehrere Supplier für Segment seg_id, dann fordere seg_id bei dem Part-ner part_id an, dessen verbleibende Bandbreite (restzeit[part_id][seg_id])gröÿer ist als zur Lieferung von Segment seg_id benötigt (sec_segment[part_id]).Kommen mehrere Partner in Frage, wähle den mit der höchsten Bandbreite. De-krementiere die Restzeit von part_id für alle verbleibenden fehlenden Segmente.

In der mittleren Scheduling-Tabelle aus 5.8 ist der so ermittelte Supplier in grünerSchriftfarbe auf gelber Markierung ersichtlich. Der Algorithmus �ndet in meinem Test-fall für jedes Segment einen Supplier (siehe auch letzte Spalte supplier in der mittlerenScheduling-Tabelle aus 5.8).

83


Abbildung5.8:Testdaten

fürScheduling-Algorithm

us

84

5.6. VERIFIKATION KAPITEL 5. IMPLEMENTIERUNG

Der Scheduler gibt eine Liste von Suppliern mit den bei ihnen anzufordernden Segmentenzurück. Die Liste ist so sortiert, dass zuerst bei den Suppliern angefragt wird, die dieseltensten Segmente haben (siehe unterste Tabelle in 5.8).

5.6 Validierung und Veri�kation

Ein wichtiger Schritt zum Abschluss von Softwareprojekten ist die Validierung bzw. dieVeri�kation des entwickelten Systems. Dabei ist zwischen den Begri�en Validierung undVeri�kation zu di�erenzieren.

Validierung Die zentrale Frage heiÿt: Wurde das richtige System entwickelt? Hier wer-den die fachliche Vollständigkeit und die Korrektheit überprüft. Im geschäftlichen Umfeldwird getestet, ob das entwickelte Produkt den Anforderungen und Wünschen des Kundenentspricht. Es wird sozusagen gegen die Erwartungen des Kunden validiert. Der Kundeist auch am Validierungsprozess beteiligt. Validierungen werden dann durchgeführt, wennkeine konkrete Spezi�kation oder kein Prototyp vorliegt.

Veri�kation Die zentrale Frage lautet: Wurde das System richtig entwickelt? Hier wirddas Ergebnis der Entwicklung gegen die Spezi�kation geprüft. Dies ist machbar, falls einekonkrete Spezi�kation oder ein Prototyp vorliegen. Analytiker, Entwickler und Testerführen die Veri�kation durch.

Für das CoolStreaming-Protokoll liegt eine Spezi�kation vor. Die Angaben der Autorenaus [ZL+05] können zur Veri�kation der Implementierung verwendet werden.

Formale Veri�kationen prüfen die Korrektheit mit Hilfe eines Veri�kationskalküls. Diesist sehr aufwändig und nicht realisierbar für ein Programm dieser Gröÿe. Die Veri�ka-tion erfolgt daher anhand der Angaben der CoolStreaming-Autoren und wird in denImplementierungsprozess eingebunden.

Abbildung 5.9 zeigt, wie die Veri�kation in den Entwicklungsprozess integriert ist. Eineneue Komponente wird durch einen eigenen Modultest (JUnit-Komponententest) über-prüft. Die Komponente wird solange getestet und überarbeitet, bis sie sich gemäÿ derSpezi�kation und gemäÿ eigener Designentscheidungen korrekt verhält.

Ist die Entwicklung dieses einzelnen Moduls so weit abgeschlossen, dass es in die Simu-lationsumgebung integriert werden kann, erfolgt ein Integrationstest durch Aufruf vonP2PNetSim und Abgleich der Ergebnisse anhand der Logmeldungen. Dafür sind aussa-gekräftige Logmeldungen notwendig.

Schlieÿlich kann man die Korrektheit der Implementierung mit Hilfe des Benchmarksys-tem SimBench überprüfen. Der von SimBench generierte Verbindungsgraph kann zumeinen Aufschluss über die Qualität der Partnerschaftsbeziehungen geben. Wird ein Peeranhand der Logmeldungen mit Anfragen überschwemmt, so lässt sich beispielsweise ausdem Graph erkennen, ob er für seine Partner jeweils der mit den aktuellsten Daten ist,weil er der Quelle am nächsten liegt. Der Partner mit den aktuellsten Daten erhält alleAnfragen, da nach [ZL+05] die Segmente, die nur bei einem Partner vorliegen, sofort

85

5.6. VERIFIKATION KAPITEL 5. IMPLEMENTIERUNG

Programmcode erstellen

JUnit-Komponententests

Refaktorisierung

P2PNetSim-Integration

Integrationstest

Verifikation abgeschlossen

Verifikation mit SimBench

Abbildung 5.9: Veri�kation der Implementierung

(und ohne Berücksichtigung der Bandbreite) angefragt werden. Zum anderen kann mandie Funktionsweise des gesamten Systems testen, indemman Performancetests durchführtund die erhaltenen Ergebnisse mit den dokumentierten Testresultaten der Originalimple-mentierung vergleicht. Die Veri�kation erfolgt hier mittels statistischer Auswertungen(siehe Abschnitt 6.2 im folgenden Kapitel). Die entsprechenden Metriken (Kontrollover-head, Continuity-Index, Startup-Delay und Playback-Delay) wurden bereits im Abschnitt4.4.2 vorgestellt.

86

6 Auswertung

In den vorangegangenen Kapiteln wurde CoolStreaming, ein P2P-Live-Streaming-Proto-koll auf Mesh-Pull-Basis, vorgestellt und analysiert. Im Rahmen der Analyse habe ichCoolStreaming mit anderen P2P-Live-Streaming-Protokollen verglichen und möglicheVerbesserungen des CoolStreaming-Protokolls vorgeschlagen (siehe Abschnitt 4.6). InKapitel 5 folgte die Beschreibung meiner CoolStreaming-Implementierung.

Das CoolStreaming-Protokoll konnte im Rahmen dieser Arbeit so implementiert werden,dass es vergleichbar gute Ergebnisse liefert wie die Original-Implementierung. In diesemKapitel wird zunächst der Simulationsaufbau zur Durchführung der Benchmarktests be-schrieben. Anschlieÿend werden die durchgeführten Optimierungen vorgestellt. Zum Ab-schluss werden aufgrund der Erfahrungen aus der CoolStreaming-Implementierung Rück-schlüsse auf die Implementierung von Mesh-basierten Protokollen allgemein gezogen.

6.1 Simulationsaufbau

In den in [ZL+05] beschriebenen Testläufen verbinden sich die Peers während einer In-itialisierungsphase mit dem Netzwerk und bleiben für eine Dauer von 120 Minuten online.Die Initialisierungsphase dauert höchstens eine Minute. Diese Angaben verwende ich fürmeinen Simulationsaufbau, in dem pro Simulationsschritt ein Peer das Netzwerk betrittund alle Peers mit dem Netzwerk verbunden bleiben. Für die Auswertung ist es nichtnötig, eine Streamdauer von 120 Minuten zu simulieren, da sich das System bereits nachrelativ kurzer Zeit stabilisiert. Daher lasse ich meine Simulationen über einen simuliertenZeitraum von 1800 Sekunden (30 Minuten) laufen.

Für die Simulationsläufe sind folgende Parameter wichtig, die - soweit möglich - aus denAngaben aus [ZL+05] abgeleitet wurden:

� Peeranzahl: 200. Laut [ZL+05] nehmen maximal 200 Peers an einer Streamingsit-zung teil.

� Partneranzahl je Peer: 5. Bei einer Partneranzahl von 4 bis 6 Partnern pro Peerwurde ein relativ hoher Continuity-Index (>0.983) gemessen. Daher begrenze ichdie maximale Partneranzahl auf 5 Partner pro Peer.

� Uploadbandbreite je Peer: 100 kB/sec (abgeleitet aus ADSL-Upstream von 1Mbps [FH07]).

� Downloadbandbreite je Peer: 1 MB/sec (entspricht ADSL-Downstream vonmindestens 8 Mbps).

87

6.2. EVALUIERUNG UND OPTIMIERUNG KAPITEL 6. AUSWERTUNG

� Streamingrate: 50 kB/sec bzw. 400 kbps. 400 kbps ist die im Internet üblicheStreamingrate ([LGL08, PM08]), mit der auch das CoolStreaming-System betrie-ben wurde ([LX+08]). Die Streamingrate kann in meiner Implementierung ge-ändert werden, indem das per De�nition einsekündige Datensegment (KonstanteSEGMENT_SIZE) mehr bzw. weniger Bytes umfasst.

� Pu�ergröÿe: 60 Segmente (entspricht 60 Sekunden Video) [ZL+05]. Der Pu�erder Quelle ist mit 30 Segmenten halb so groÿ (siehe auch Abschnitt 5.4.4)

� Gewichtungsfaktor für die Bandbreitenschätzung: 0,5. Der Scheduler fordertanhand der geschätzten Partnerbandbreite bei den Partnern Segmente an, sieheAbschnitt 5.4.7.1. Ich berücksichtige bei dieser Schätzung einen Gewichtungsfaktorzwischen 0 und 1. Je näher der Gewichtungsfaktor an 0 liegt, desto schneller werdenlängere bzw. kürzere Lieferzeiten bei der geschätzten Bandbreite berücksichtigt. DerGewichtungsfaktor von 0,5 hat sich in der Simulation bewährt, da sich einerseitsdie Bandbreitenschätzung schnell genug dem tatsächlichen Wert annähert, aberandererseits einzelne Ausreiÿer (d.h. einzelne Segmente, die sofort oder mit groÿerVerzögerung geliefert werden) die Schätzung nicht völlig verfälschen können.

6.2 Evaluierung und Optimierung

Die CoolStreaming-Autoren haben ihre Implementierung auf PlanetLab getestet, die Me-triken Continuity-Index (siehe Abschnitt 4.4.2) und Kontrolloverhead (siehe Abschnitt4.4.2) gemessen und die Ergebnisse in [ZL+05] verö�entlicht. Meine CoolStreaming-Implementierung wird durch Messung der genannten Metriken mit dem Original ver-glichen und liefert dabei vergleichbar gute Ergebnisse. Da die Protokollspezi�kation in[ZL+05] weder ganz vollständig noch immer eindeutig ist, konnten diese guten Ergebnis-se erst nach zwei hauptsächlichen Optimierungen erzielt werden, die in diesem Abschnittbeschrieben werden.

Berücksichtigung der Bandbreite In Abschnitt 4.6 wies ich darauf hin, dass Cool-Streaming die Partnerbandbreite beim Anfordern von Segmenten nicht immer berück-sichtigt. Ist ein Segment nur bei einem Partner verfügbar, wird es bei diesem Partnerangefordert, auch falls er gemäÿ der Bandbreitenschätzung keine Uploadbandbreite mehrzur Verfügung hat. Da die Protokollspezi�kation nicht vorsieht, dass ein Partner einge-hende Anfragen verwirft, kann es zu einer Überlastung dieses Partners durch Anfragenkommen. Das kann schlieÿlich dazu führen, dass ein Partner kein einziges angefordertesSegment mehr rechtzeitig verschickt, da er weiterhin versucht, trotz fehlender Bandbreitedie eingehenden Anfragen nacheinander abzuarbeiten.

In der Simulation meiner Implementierung ist genau dieses beschriebene Szenarium auf-getreten. Abhängig von der zufälligen Verbindungsstruktur im Mesh gab es in den Simu-lationsläufen eine schwankende Anzahl von Partnern, die Segmente jeweils eher als anderein ihrem Pu�er hatten und daher mehr Anfragen erhielten, als sie bearbeiten konnten.Im Verlauf der einzelnen Simulationen konnten diese Partner schlieÿlich gar nicht mehrzur Lieferung von Segmenten beitragen, was sich sehr negativ auf den Continuity-Index

88


auswirkte. Der Anteil der nicht rechtzeitig erhaltenen Segmente (im Verhältnis zu den fürdie Wiedergabe benötigten Segmenten) ist unverhältnismäÿig groÿ (siehe Abbildung 6.1).Wird die Bandbreite des Partners beim Anfordern der Segmente gegebenenfalls ignoriert(d.h. nicht immer berücksichtigt), sinkt der Continuity-Index auf unter 0,5. D.h. mehrals die Hälfte des Streams wird nicht rechtzeitig empfangen und kann nicht abgespieltwerden.

Im Rahmen der ersten Optimierung des Systems habe ich also die Bandbreite der Partnerimmer berücksichtigt. Auch Segmente, die lediglich bei einem Partner erhältlich sind, wer-den bei diesem nur angefordert, falls seine geschätzte Uploadbandbreite ausreicht. DieseOptimierung brachte sofort sichtbare Verbesserungen. Der Continuity-Index verbessertesich auf 0,91 und kommt dem Continuity-Index der Original-Implementierung von 0,992relativ nahe. Abbildung 6.1 zeigt den in zwei repräsentativen Simulationen gemessenenContinuity-Index vor und nach dieser Optimierung.

Abbildung 6.1: Continuity-Index in Abhängigkeit von der Berücksichtigung der Partner-bandbreite

Die Tatsache, dass Peers überlastet werden können, wenn bei ihnen Segmente unabhängigvon der zur Verfügung stehenden Bandbreite angefordert werden, liegt auf der Hand undwird durch die Messungen in der Simulation bestätigt. Da der Pseudocode des Scheduler-Algorithmus in der Protokollspezi�kation an einigen Stellen Ungenauigkeiten aufweist,haben die Autoren möglicherweise nicht die tatsächlich umgesetzte Version des Scheduler-Algorithmus in [ZL+05] verö�entlicht.

Beginn der Wiedergabe Um den Continuity-Index und damit den Anteil der rechtzeitigempfangenen Segmente weiter zu erhöhen, betrachtete ich bei der zweiten Optimierungdie Anfangsverzögerung (siehe auch Abschnitt 4.4.2). Von den CoolStreaming-Autoren

89


Abbildung 6.2: Continuity-Index in Abhängigkeit vom Beginn der Wiedergabe

selbst ist nicht bekannt, welche durchschnittliche Anfangsverzögerung (zwischen demBetreten des Netzes und dem Beginn der Wiedergabe) gemessen wurde. Andere Quel-len berichten von einer Anfangsverzögerung bei CoolStreaming von ca. 60 Sekunden[LJ+06, OJ08]. Da nach der ersten Optimierung die gemessene durchschnittliche An-fangsverzögerung im Gegensatz dazu lediglich bei 20,2 Sekunden lag, lieÿ ich in meinerImplementierung die Wiedergabe später beginnen. D.h. das Playback startet nicht 10Sekunden nach Erhalt des ersten Segments, sondern 15 bzw. 20 Sekunden später (sieheAbbildung 6.2).

Abbildung 6.2 zeigt den in repräsentativen Simulationen gemessenen Continuity-Indexin Abhängigkeit vom Beginn der Wiedergabe. Der Continuity-Index ist umso höher, jespäter die Wiedergabe beginnt. Startet die Wiedergabe 20 Sekunden nach Erhalt desersten Segments, liegt der Continuity-Index durchschnittlich bei 0,9989. D.h. lediglich in0,11% der Fälle werden Segmente nicht rechtzeitig empfangen und es kommt zu Ausset-zern bei der Wiedergabe. Diese Verbesserung erklärt sich dadurch, dass den Peers mehrZeit zur Verfügung steht, um ihren Pu�er vor Wiedergabe-Beginn zu befüllen und umdie Bandbreite ihrer Partner anhand der erhaltenen Segmente realistischer einschätzenzu können.

Bandbreitenschätzung In Abbildung 6.2 erkennt man, dass der Continuity-Index in denersten 200 bis 400 Sekunden schwankt und spätestens ab 600 Sekunden recht konstantist. Die dafür verantwortliche Bandbreitenschätzung arbeitet mit Verzögerung (abhängigvom Gewichtungsfaktor), um unabhängig von Ausreiÿern eine realistische Bandbreite zuschätzen. Am Anfang werden daher von Partnern mehr bzw. weniger Segmente ange-fordert, als diese liefern könnten. Erst nach einigen Minuten pendelt sich die geschätzte

90

6.3. ZUSAMMENFASSUNG KAPITEL 6. AUSWERTUNG

Bandbreite auf den tatsächlichen Wert ein. Die Segmente werden dann so angefordert,wie sie auch geliefert werden können. Der Zusammenhang zwischen der Bandbreiten-schätzung und dem Continuity-Index ist aus den Logdateien ersichtlich.

Ergebnisse nach den Optimierungen Meine Implementierung wurde dadurch opti-miert, dass einmal verfügbare Segmente nur bei ausreichender Partnerbandbreite angefor-dert werden und die Wiedergabe 20 Sekunden nach Erhalt des ersten Segments beginnt.Mit diesen beiden Optimierungen konnte ich den Continuity-Index meiner Implementie-rung auf durchschnittlich 0,9989 erhöhen, wodurch er höher ist als der entsprechendeContinuity-Index der Original-Implementierung (0,992).

Die durchschnittliche Anfangsverzögerung (zwischen Join und Wiedergabebeginn) liegtbei 30,6 Sekunden und die durchschnittliche Abspielverzögerung (zwischen Ausgabe desSegments durch die Quelle und Wiedergabe) bei 28,7 Sekunden. Damit liegen sowohlAnfangsverzögerung als auch Abspielverzögerung unter den in [OJ08] dokumentierten 60Sekunden.

Der Kontrolloverhead ist mit 2,76% höher als in der Original-Implementierung (ca. 1,5%).Die Di�erenz lässt sich zum einen dadurch erklären, dass ich möglicherweise die Gröÿeder Kontrollnachrichten in meiner Implementierung höher als notwendig veranschlagt ha-be. Zum anderen haben die CoolStreaming-Autoren vorgeschlagen, Kontrollnachrichtenan die Partner mit den Streamdaten im Payload zu verschicken, was das Volumen derKontrollnachrichten in der Original-Implementierung ebenfalls verringert [ZL+05].

6.3 Zusammenfassung

Mit CoolStreaming habe ich ein im Realbetrieb erprobtes P2P-Live-Streaming-Protokollauf Mesh-Pull-Basis umgesetzt. Meine Implementierung liefert Ergebnisse, die gemes-sen an der Original-Implementierung vergleichbar gut sind. Die Klasse Zeit hat sich beider Implementierung als sehr hilfreich erwiesen, da sich durch die Umrechnung von Si-mulationsschritten in Sekunden die Ergebnisse meiner Implementierung mit denen derOriginal-Implementierung direkt vergleichen lassen. Die Klasse Bandbreitenregulator

war relativ aufwändig zu implementieren, ohne sie wäre die Evaluierung des Protokollsjedoch nicht möglich gewesen. Der Scheduler-Algorithmus von CoolStreaming basierthauptsächlich darauf, dass die Bandbreite korrekt eingeschätzt wird. Über die Bandbrei-tenschätzung ist leider nichts verö�entlicht und die Autoren hielten sich bei Nachfrageauch bedeckt. Die von mir implementierte Bandbreitenschätzung liefert nach einer relativkurzen Anlaufphase zuverlässig realistische Schätzungen, wie sich aus den Ergebnissenaus der Simulation ersehen lässt.

Bewertung der Optimierung In meiner Implementierung des CoolStreaming-Protokollswerden Segmente immer nur dann angefordert, wenn die geschätzte Bandbreite des Sen-ders ausreicht. Dadurch kann es zwar passieren, dass ein Peer vereinzelte Segmente man-gels Partnerbandbreite überhaupt nicht anfragen kann und es daher an einzelnen Stellenzu Aussetzern bei der Wiedergabe kommt. Im Gegenzug erhalten Peers aber nur so viele

91

6.3. ZUSAMMENFASSUNG KAPITEL 6. AUSWERTUNG

Segmentanforderungen, wie sie auch in angemessener Zeit abarbeiten können. Durch die-se Optimierung wird implizit die Anzahl der ausgehenden Anfragen pro Partner begrenzt.Es mussten keine expliziten Obergrenzen für ausgehende Anfragen de�niert werden, wo-durch die Implementierung so nah wie möglich an der Protokollspezi�kation erfolgte.

Bewertung der Metriken Das CoolStreaming-Protokoll dient dem Live-Streaming vonWeb-TV-Inhalten. Die wichtigste Metrik in diesem Anwendungsbereich ist der Continuity-Index, da es hier darauf ankommt, dass der Stream mit möglichst wenig Aussetzern über-tragen wird. Verzögerungen sind beim Web-TV-Streaming zwar unangenehm, aber nichtso kritisch zu bewerten wie z.B. bei Videokonferenzanwendungen. Bei der Implementie-rung hat sich zudem gezeigt, dass der Continuity-Index eine Metrik ist, die von vielenverschiedenen Faktoren abhängt (z.B. von den tatsächlichen und den geschätzten Upload-bandbreiten der Peers, von der Partneranzahl pro Peer und der Verbindungsstruktur imNetzwerk). Auÿerdem konnte ein Trade-O� zwischen der Anfangsverzögerung und demContinuity-Index festgestellt werden. Je später die Wiedergabe beginnt, desto höher istder Continuity-Index.

Fazit für Mesh-Pull-Systeme Aus den Erfahrungen bei der Implementierung von Cool-Streaming kann ein Fazit für die Implementierung von Mesh-Pull-Protokollen allgemeingezogen werden. In Mesh-Pull-Systemen fordern die Empfänger-Peers die Segmente unddamit die Senderbandbreite aktiv an. Damit die Senderbandbreite nicht überbeanspruchtwird, muss der Zugri� auf die Senderbandbreite gesteuert werden, z.B. durch Schätzungder Bandbreite.

Das Mesh-Pull-Konzept basiert darauf, dass alle Peers möglichst gleichmäÿig mit ihrerBandbreite zum Übertragungsvolumen beitragen, d.h. die Anfragen sollten gleichmäÿigzwischen den Partnern verteilt werden. Dazu dürfen die Partner in Bezug auf die Abspiel-verzögerung nicht zu weit auseinander liegen, d.h. ihre Entfernung von der Quelle solltenicht zu stark variieren. Da ein Mesh zufällig aufgebaut wird, kann die Verbindungs-struktur im Netzwerk zu diesem Zweck nur dynamisch während des Streamingprozessesangepasst werden. Als mögliche Erweiterung wird daher in [ZL+05] ein Partnerscorevorgeschlagen. Da die gemessenen Werte meiner Implementierung schon vergleichbar gutmit der Original-Implementierung sind und zudem nicht bekannt ist, ob im Originalder Partnerscore tatsächlich integriert ist, wurde auf die Umsetzung des Partnerscoresverzichtet.

Um schlieÿlich die Abspielverzögerungen in Mesh-Pull-Systemen niedrig zu halten, gibtes die Möglichkeit, dass Statusnachrichten (Bu�ermaps, Segmentanforderungen) nichtin festen Intervallen versandt werden (wie bei CoolStreaming), sondern immer dann,wenn sich Änderungen ergeben. Partner verschicken z.B. ihre Bu�ermap, sobald sie neueSegmente im Pu�er gespeichert haben und diese zur Verfügung stellen können. Undbei Eingang einer Partner-Bu�ermap wird der Scheduler gestartet und gegebenenfallsdas fehlende Segment angefordert. Dadurch könnten die Abspielverzögerungen verrin-gert werden, unter Umständen würde dies aber den Overhead durch Kontrollnachrichtenerhöhen.

92

7 Abschluss

In dem letzten Kapitel dieser Arbeit werden die Erfahrungen bei der Entwicklung mit demNetzwerksimulator P2PNetSim wiedergegeben. Die Arbeit schlieÿt mit einem Fazit undeinem Ausblick. Im Ausblick werden dabei verschiedene in dieser Arbeit angesprocheneAspekte aus den Bereichen Streaming und P2P-Streaming betrachtet.

7.1 Feedback zu P2PNetSim

In dieser Arbeit wurde das P2P-Live-Streaming-Protokoll CoolStreaming auf Basis desNetzwerksimulators P2PNetSim Version 3.0 entwickelt. Bei P2PNetSim handelt es sichum einen verteilt arbeitenden Simulator, wodurch Simulationen auf mehreren Clusternlaufen können, was vor allem bei gröÿeren Simulationen die Laufzeit erheblich verringert.P2PNetSim ist übersichtlich strukturiert und zudem leicht zu bedienen. Derzeit wirdP2PNetSim komplett überarbeitet. Der Funktionsumfang der neuen Version ist mir nichtbekannt. Aufgrund meiner Erfahrungen mit P2PNetSim schlage ich vor, folgende Ideenbei der Realisierung der neuen Version zu berücksichtigen.

Das neue P2PNetSim sollte das Benchmarksystem SimBench fest integrieren, so dasszukünftige Entwicklungen von Beginn an auf SimBench aufbauen können und die Be-fehlszentrale (mit Join, Leave und Fail) sowie die XML-Generierung zur Kon�gurationder Peers nutzen können.

Wünschenswert wäre ebenfalls, dass bereits implementierte Protokolle ebenfalls zur Ver-fügung gestellt werden, so dass die Verfasser späterer Abschlussarbeiten im LehrgebietKommunikationsnetze auf den vorhandenen Implementierungen aufbauen können.

Es emp�ehlt sich auÿerdem, wenn die im Rahmen dieser Arbeit realisierten Erweiterun-gen und Korrekturen implementiert werden, insbesondere die Klassen StreamingAddress,Zeit und Bandbreitenregulator. Für die Benutzung der Klasse Bandbreitenregulatormüssen in der XML-Kon�guration Parameter für die maximalen Upload- und Down-loadbandbreiten jedes Peers gesetzt werden. P2PNetSim sieht dafür zwar die ParameterOutgoingBandwidth für Upload und IncomingBandwidth für Download vor, bietet aberkeine Möglichkeit an, diese aus der Basiskon�guration auszulesen. Da IncomingBandwidthund OutgoingBandwidth auch über den SimBench-XML-Kon�gurator gesetzt werdenkönnen, sollte die Bandbreitenregulierung in der neuen P2PNetSim-Version diese Pa-rameter benutzen und zudem eine Getter-Methode zum Auslesen der gesetzten Werteimplementieren.

P2PNetSim verschickt die Nachrichten per Zufallsprinzip, d.h. die Nachrichten kommennicht in der Reihenfolge an, in der sie abgeschickt wurden. Das Zufallsprinzip erscheintzwar theoretisch für die Simulation des realen Internets sinnvoll, ist für die Entwicklung

93

7.2. FAZIT KAPITEL 7. ABSCHLUSS

eines Protokolls aber manchmal hinderlich. Für die Entwicklung und den Test von Pro-tokollen ist es wichtig, dass die Schritte beim Aufbau des Netzes nachvollziehbar sind.Daher empfehle ich, neben dem Zufallsprinzip auch den deterministischen Versand zuimplementieren.

Bisher werden Exceptions aus den implementierten Protokollen so behandelt, dass dieSimulation weiter läuft und die P2PNetSim-GUI nur die Meldung der Exception ausgibt.Um gravierende Fehler festzustellen, müssen Logmeldungen mit Logleveln wie ERROR oderFATAL ausgegeben und auf Verdacht hin alle Logmeldungen nach diesen Logleveln durch-sucht werden, was wenig e�zient ist. P2PNetSim sollte daher die Möglichkeit vorsehen,dass zumindest RuntimeExceptions gefangen und behandelt werden können, so dass dieSimulation bei einem schweren Fehler anhält.

Abschlieÿend ist zu sagen, dass ich die Implementierung von Protokollen in P2PNetSimzusammen mit dem gleichzeitigen Einsatz von externen Modultest wie JUnit und Per-formancetests mit SimBench sehr empfehlen kann.

7.2 Fazit

In dieser Arbeit wurde zunächst am Beispiel von China gezeigt, unter welchen Rahmen-bedingungen ein für die P2P-Streaming-Forschung förderliches Klima entsteht. Dannwurde die Streaming-Technik aus verschiedenen Aspekten betrachtet, um den Begri�Streaming so präzise wie möglich abzuklären und auch auf Grenzfälle hinzuweisen (z.B.Pseudo-Streaming per HTTP).

Um den komplexen Aufbau von P2P-Streaming-Protokollen möglichst anschaulich dar-stellen zu können, wurde aus der groÿen Anzahl in Frage kommender Protokolle Cool-Streaming ausgewählt. CoolStreaming, ein P2P-Live-Streaming-Protokoll auf Mesh-Pull-Basis, ist einfach und übersichtlich strukturiert, �ndet in vielen wissenschaftlichen Ab-handlungen Erwähnung und ist zudem als kommerzielles System im Realbetrieb erprobt.

Die Analyse von CoolStreaming erfolgte durch Vergleich der Protokollcharakteristikenmit denen anderer P2P-Live-Streaming-Protokolle. Dabei wurden die Protokollcharak-teristiken in einer mir bisher nicht bekannten Tiefe betrachtet und zugleich ein unge-wöhnlich breiter Überblick über vorhandene P2P-Live-Streaming-Protokolle gegeben. ImRahmen der Analyse wurde auch auf die verschiedenen Begri�ichkeiten, die sich in derP2P-Streaming-Literatur �nden, hingewiesen, um so den systematischen Überblick zuvervollständigen.

Eine Herausforderung bei der Implementierung von CoolStreaming stellte die heuris-tische Schätzung der Partnerbandbreite dar, auf welcher die Qualität des Scheduler-Algorithmus basiert. Diese zentrale Komponente wird in der Protokollspezi�kation nichtbeschrieben, konnte aber dennoch so implementiert werden, dass sie nach einer relativkurzen Anlaufphase zuverlässig realistische Schätzungen liefert. Die Implementierung desCoolStreaming-Protokolls wurde schlieÿlich mit Hilfe von Benchmarkmessungen ausge-wertet und optimiert. Dabei wurde auch auf weitere mögliche Verbesserungen hingewie-sen.

94

7.3 Ausblick

Welche Entwicklungen können in Zukunft beim Streaming und insbesondere beim Strea-ming auf P2P-Basis erwartet werden?

Streaming über HTTP wird im Rahmen von HTML5 standardisiert werden. Die da-bei gestreamten Videoformate bauen entweder auf dem lizenzp�ichtigen H.264-Standardvon MPEG oder auf freien Standards (Ogg Theora, VP8) auf. Der zukünftige Einsatzvon H.264 wird hier davon abhängen, inwieweit die MPEG-Lizenzpolitik den Nutzernentgegenkommt.

Beim Streaming auf P2P-Basis ist eine Standardisierung dagegen noch nicht absehbar.Im Februar 2010 wurde zwar ein Internet-Draft [GB+10] verö�entlicht, der die Kommu-nikation zwischen Peers und Tracker regelt. Es bleibt aber abzuwarten, ob sich daraus einRFC entwickeln wird und ob kommerzielle P2P-Streaming-Systeme auf diesen Standardaufsetzen werden. Dies ist insbesondere fraglich, da kommerzielle Systeme eher proprie-täre und besser zu kontrollierende Lösungen bevorzugen (siehe am Beispiel von Skype).

Des weiteren sollte man bei P2P-Streaming zwischen den Forschungen im akademi-schen Bereich und den Entwicklungen im kommerziellen Umfeld unterscheiden. Im aka-demischen Bereich wird vermehrt mit Forschungsarbeiten über den Einsatz von P2P-Streaming auf mobilen Geräten zu rechnen sein. Was kommerzielle Lösungen betri�t,so basieren diese nach wie vor auf der einfach strukturierten Mesh-Topologie. Multi-Tree-basierte Systeme werden sich meines Erachtens im kommerziellen Umfeld erst danndurchsetzen können, wenn die dabei angewandte Kodierung (MDC) auch von gängigenPlayern unterstützt wird, was bisher nicht absehbar ist. In den westlichen Industriena-tionen könnte zudem das Interesse an kommerziellen P2P-Streaming-Lösungen bei einerstärkeren Verbreitung von IPTV steigen. Derzeit bedienen IPTV-Anbieter nur eine klei-ne Klientel, so dass über Serverfarmen und CDN-Server Videodaten in HD-Qualität zu16 Mbps gestreamt werden können. Bei einem massiven Anstieg der Abonnenten werdendiese Architekturen an ihre Grenzen stoÿen und eine Integration von P2P-Streaming-Strukturen in die IPTV-Netze wäre denkbar.

Schlussendlich soll betont werden, dass Entwicklungen auch noch von anderen Fakto-ren beein�usst werden. Während z.B. ein groÿer Anteil der P2P-Streaming-Arbeitenaus China kommt, sind die Beiträge westlicher Forscher hauptsächlich in Teilbereichen(z.B. Netzwerkkodierung) zu beobachten. Wie ich zu Beginn der Arbeit dargelegt habe,scha�en u.a. politische und rechtliche Entscheidungen in China ein günstiges Umfeld fürForschungen. In den westlichen Industrienationen ist der Druck von Seiten der Rechtein-haber jedoch groÿ. Zukünftige politische Entscheidungen können im Westen von diesemDruck geprägt sein und dabei ein P2P-Streaming-feindliches Klima fördern, was wie-derum hinderlich für Entwicklungen wäre. Es bleibt zu ho�en, dass sich Rechteinhaberzukünftig nicht mehr von P2P-Streaming bedroht fühlen und so wieder vermehrt mitVerö�entlichungen westlicher P2P-Streaming-Forscher zu rechnen ist.

95

Literaturverzeichnis

[AYC04] C. Abad, W. Yurcik, R.H. Campbell; A Survey and Comparison of End-SystemOverlay Multicast Solutions Suitable for Network Centric Warfare; Proceedingsof SPIE, 2004; 2004

[BBK02] S. Banerjee, B. Bhattacharjee, C. Kommareddy; Scalable application layer mul-ticast; Proc. ACM SIGCOMM'02, Pittsburgh, PA, Aug. 2002; 2002

[BM+08] T. Bonald, L. Massoulié, F. Mathieu, D. Perino, A. Twigg; Epidemic LiveStreaming: Optimal Performance Trade-O�s; SIGMETRICS '08: Proceedingsof the 2008 ACM SIGMETRICS international conference on Measurement andmodeling of computer systems; 2008

[BM+09] A. Bakker, J.J.D. Mol, J. Yang, L. d'Acunto, J.A. Pouwelse, J. Wang, P. Gar-backi, A. Iosup, J. Doumen, J. Roozenburg, M. ten Brinke, F. Zindel, M. Meul-polder, J. Taal, B. Schoon; P2P-Next, Next-Share Platform M8�Speci�cationPart; http://p2p-next.org; 2009

[Bra05] R. Brause; Kompendium der Informationstechnologie; Springer; 2005

[BV+09] M.E. Bertinat, D. De Vera, D. Padula, F.R. Amoza, P. Rodríguez-Bocca, P.Romero, G. Rubino; GoalBit: The First Free and Open Source Peer-to-PeerStreaming Network; LANC'09 September 24-25, 2009. Pelotas, Brazil; 2009

[CD+02] M. Castro, P. Druschel, A. Kermarrec, A. Nandi, A. Rowstron; SCRIBE: Alarge-scale and decentralized application-level multicast infrastructure; IEEEJournal on Selected Areas in Communication (JSAC), 20(8), 2002, pp. 1489-1499; 2002

[CD+03] M. Castro, P. Druschel, A. Kermarrec, A. Nandi, A. Rowstron, A. Singh; Split-Stream: high-bandwidth multicast in a cooperative environment, Proc. ACM19th SOSP Symp., Oct. 2003; 2003

[cha07] T. Pritlove, M. Feiri; Medienformate und Codecs, Podcast v. 26.12.2007;http://chaosradio.ccc.de; 2007

[cha09] T. Pritlove, N. Longolius; AV Streaming, Podcast v. 16.11.2009;http://chaosradio.ccc.de; 2009

[CLB07] D. Carra, R. Lo Cigno, E.W. Biersack; Graph Based Analysis of Mesh OverlayStreaming Systems; IEEE Journal on Selected Areas in Communications 25(9):1667-1677 (2007); 2007

[CL+10] A.P. Couto da Silva, E. Leonardi, M. Mellia, M. Meo; Chunk distributionin Mesh-Based Large Scale P2P Streaming Systems: A �uid approach; IEEETransactions on Parallel and Distributed Systems; 2010

96

[Cli01] Clip2; The Gnutella protocol speci�cation v0.4;http://www9.limewire.com/developer/gnutella_protocol_0.4.pdf (2001);http://www9.limewire.com; 2001

[cnn09] China Internet Network Information Center; Statistical Survey Report on In-ternet Development in China (July 2009); http://www.cnnic.cn; 2009

[cnn10] China Internet Network Information Center; Statistical Survey Report on In-ternet Development in China (January 2010); http://www.cnnic.cn; 2010

[CRC08] D. Carra, R. Lo Cigno, A. Russo; On Some Fundamental Properties of P2PPush/Pull Protocols; ICCE 2008. Second International Conference on Commu-nications and Electronics; 2008

[CRZ00] Y. Chu, S.G. Rao, H. Zhang; A case for end system multicast; In Proceedingsof ACM SIGMETRICS; 2000

[CR+02] Y. Chu, S.G. Rao, S. Seshan H. Zhang; A Case for End System Multicast;IEEE Journal on Selected Areas in Communication (JSAC), Special Issue onNetworking Support for Multicast, Vol. 20, No. 8, 2002; 2002

[CS+01] I. Clarke, O. Sandberg, B. Wiley, T.W. Hong; Freenet: A distributed anonymousinformation storage and retrieval system; Lecture Notes in Computer Science,2009:46+, 2001; 2001

[Dar05] V. Darlagiannis; Hybrid Peer-to-Peer-Systems; Peer-to-Peer Systems and App-lications 2005; 2005

[DB+02] H. Deshpande, M. Bawa, H. Garcia-Molina; Streaming Live Media over Peers;Stanford InfoLab Technical Report 2002-21; 2002

[DC90] S. Deering, D. Cheriton; Multicast routing in datagram internetworks and ex-tended LANs; ACM Transaction on Computer Systems, Vol. 8, No. 2; 1990

[E�08] W. E�elsberg; Peer-to-Peer Networks; Vorlesung an der Universität Mannheim;2008

[EF+98] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacob-son, C. Liu, P. Sharma, L. Wei; Protocol Independent Multicast-Sparse Mode(PIM-SM) � Protocol Speci�cation; http://www.rfc-editor.org/rfc/rfc2362.txt;1998

[env08] Envisional Ltd; Background Report on Digital Piracy of Sporting Events; En-visional Ltd and NetResult Ltd; 2008

[ES05] J. Eberspächer, R. Schollmeier; First and Second Generation of Peer-to-Peer-Systems; Peer-to-Peer Systems and Applications 2005; 2005

[Fen97] W. Fenner; Internet Group Management Protocol, Version 2; http://www.rfc-editor.org/rfc/rfc2236.txt; 1997

[FH07] P. Fischer, P. Hofer; Lexikon der Informatik; Springer; 2007

[Fra00] P. Francis; Yoid: Your Own Internet Distribution; http://www.aciri.org/yoid/.April 2000; 2000

97

[Fri04] S. Frick; Testgetriebene Entwicklung - ein Leitfaden; empros gmbh; 2004

[GB+10] Y. Gu, D.A. Bryan, Y. Zhang, H. Liao; Tracker Protocol/ draft-gu-ppsp-tracker-protocol-00; http://tools.ietf.org; 2010

[GKM03] A.J. Ganesh, A.-M. Kermarrec, L. Massoulie; Peer-to-peer membership ma-nagement for gossip-based protocols; IEEE Transactions on Computers, 52(2),Feb. 2003; 2003

[gnu] Gnutella2, http://www.gnutella2.com

[goo10] http://www. google.de/trends

[GS+03] Y. Guo, K. Suh, J. Kurose, D. Towsley; P2cast: peer-to-peer patching schemefor vod service; In: Proceedings of the 12th world wide web conference (WWW-03), May 2003; 2003

[GS+07] Y. Guo, K. Suh, J. Kurose, D. Towsley; Directstream: a directory-based peer-to-peer video streaming service; Tech. rep., UMass CMPSCI Technical ReportTR 07-30; 2007

[GZ+09] Y. Gu, N. Zong, H. Zhang, Y. Zhang, G. Camarillo, Y. Liu; PPSPInternet-Draft: Survey of P2P Streaming Applications/ draft-gu-ppsp-survey-01; http://tools.ietf.org; 2009

[HA+06] M. Hosseini, D.T. Ahmed, S. Shirmohammadi, N. D. Georganas; A Surveyof Application-Layer Multicast Protocols; IEEE Communications Surveys &Tutorials 9(3),58�74, 2007; 2007

[hei06] http://www.heise.de/newsticker/meldung/79870; Studie: P2P-Datenvolumennimmt in Deutschland weiter zu; http://www.heise.de; 2006

[hei10] http://www.heise.de; MPEG LA: Keine Lizenzkosten für H.264-kodierte Inter-netvideos bis Ende 2016; http://www.heise.de/newsticker/meldung/MPEG-LA-Keine-Lizenzkosten-fuer-H-264-kodierte-Internetvideos-bis-Ende-2016-Update-921885.html, Artikel v. 04.02.2010; 2010

[HF+03] M. Handley, S. Floyd, J. Pahdye, J. Widmer; TCP Friendly Rate Control(TFRC): Protocol Speci�cation; RFC 3448, January 2003; 2003

[HH+03] M. Hefeeda, A. Habib, B. Botev, D. Xu, B. Bhargava; PROMISE: Peer-to-PeerMedia Streaming Using CollectCast; In Proc. of the 11th ACM internationalconference on Multimedia, Berkeley, CA, USA, November, 2003; 2003

[HLR08] X. Hei, Y. Liu, K.W. Ross; IPTV over P2P Streaming Networks: the Mesh-pullApproach; Communications Magazine, IEEE, Vol. 46, No. 2; 2008

[Hua07] G. Huang; PPLive - A Practical P2P Live System with Huge Amount of Users;SigComm P2P Streaming and IPTV Workshop; 2007

[JG+00] J. Jannotti, D.K. Gi�ord, K.L. Johnson, M.F. Kaashoek, J.W. O'Toole, Jr.;Overcast: Reliable Multicasting with an Overlay Network; In: Proceedings ofoperating systems design and implementation, pp 197�212; 2000

[Jov01] M.A. Jovanovic; Modeling Large-scale Peer-to-Peer Networks and a Case Studyof Gnutella; University of Cincinnati/Ohio; 2001

98

[Kle05] R. Klein; Betriebssysteme und Rechnernetze; FernUniversität in Hagen, Kursim Fachbereich Informatik; 2005

[Kos08] R. Kostadinova; Peer-to-Peer Video Streaming; Royal Institute of Technologies� KTH Stockholm, Masters' Degree Project, Sweden; 2008

[KR+03] D. Kostic, A. Rodriguez, J. Albrecht, A. Vahdat; Bullet: High Bandwidth DataDissemination Using an Overlay Mesh; Proceedings of the 19th ACM symposi-um on Operating systems principles (SOSP'03); 2003

[Ksh08] N. Kshetri; Looking at the Facts: What we Know (and Don't Know) about theChinese Internet Protocol TV Market; Paci�c Telecommunications Council's(PTC); 2008

[LC+05] E.K. Lua, J. Crowcroft, M. Pias, R. Sharma, S. Lim; A Survey and Comparisonof Peer-to-Peer Overlay Network Schemes; IEEE Communications Surveys &Tutorials, 2005; 2005

[LGL08] Y. Liu, Y. Guo, C. Liang; A Survey on peer-to-peer video streaming systems;Springer Science + Business Media, LLC 2008; 2008

[Liu04] X. Liu; A Survey of Peer-to-Peer Media Streaming Systems; CPSC538 - Com-puter Systems course project report, April 2004; 2004

[Liu07] Y. Liu; Reducing or minimizing delays in peer-to-peer communications; Patentsby Straub & Pokotylo; 2007

[Liu10] Z. Liu; Measurements on Large-scale Peer-assisted Live Streaming: A SurvivalAnalysis Approach; Master Thesis, University of Toronto; 2010

[LJ+06] X. Liao, H. Jin, Y. Liu, L.M. Ni, D. Deng; AnySee: Scalable live streamingservice based on inter-overlay optimization; In Proc. IEEE INFOCOM'06; 2006

[LM03] Z. Li, P. Mohapatra; Hostcast: A new overlay multicasting protocol; In Proc.IEEE 2003 International Conference on Communications (ICC 2003), May 2003;2003

[LR+08] J. Liu, S.G. Rao, B. Li, H. Zhang; Opportunities and Challenges of Peer-to-Peer Internet Video Broadcast; Special Issue on Recent Advances in DistributedMultimedia Communications, Vol. 96, No. 1; 2008

[LX+08] B. Li, S. Xie, Y. Qu, G.Y. Keung, C. Lin, J. Liu, X. Zhang; Inside the NewCoolstreaming: Principles, Measurements and Performance Implications; IN-FOCOM 2008; 2008

[Mar09] R.C. Martin; Clean Code: A Handbook of Agile Software Craftsmanship; Pear-son Education; 2009

[MF09] E. Magli, P. Frossard; An Overview of Network Coding for Multimedia Strea-ming; IEEE International Conference on Multimedia & Expo; 2009

[MK+02] D.S. Milojicic, V. Kalogeraki, R. Lukosei, K. Nagaraja, J. Pruyne, B. Richard,S. Rollins, Z. Xu; Peer-to-Peer Computing; HP Technical Report, HPL-2002-57;2002

99

[mpe10] MPEG LA; Corrected Version of February 2, 2010 News Release Titled �MPEGLA's AVC License Will Continue Not to Charge Royalties for Internet Videothat is Free to End Users�; http://www.mpegla.com; 2010

[MP+08] G. Mar�a, G. Pau, P. Di Rico, M. Gerla; P2P Streaming Systems: A Surveyand Experiments; STreaming Day 2007; 2008

[MR06] N. Magharei, R. Rejaie; Understanding mesh based peer-to-peer streaming; InACM NOSSDAV 2006, Newport, Rhode Island, USA; 2006

[MR07] N. Magharei, R. Rejaie; PRIME: Peer-to-Peer receiver-driven mesh-based strea-ming, Proc. IEEE INFOCOM Conf., May 2007; 2007

[MRG07] N. Magharei, R. Rejaie, Y. Guo; Mesh or Multiple-Tree: A Comparative Studyof Live P2P Streaming Approaches; IEEE INFOCOM 2007; 2007

[MS07] P. Mahlmann, C. Schindelhauer; Peer-to-Peer-Netzwerke; Springer; 2007

[Mye04] G.J. Myers; The Art of Software Testing; John Wiley & Sons, Inc., Hoboken,New Jersey; 2004

[nap] http://www.napster.com

[new09] http://newteevee.com; CNN: Inauguration P2P Stream a Success, Despi-te Backlash; http://newteevee.com/2009/02/07/cnn-inauguration-p2p-stream-a-success-despite-backlash/; 2009

[oec09] OECD/Organisation For Economic Co-operation And Development; Piracy OfDigital Content; OECD 2009; 2009

[OJ08] J. Ott, D. Jegadish; Peer-to-Peer Media Streaming; Helsinki University of Tech-nology, Department of Communication and Networking; 2008

[PBV05] B. Pourebrahimi, K. Bertels, S. Vassiliadis; A Survey of Peer-to-Peer Networks;Proceedings of the 16th Annual Workshop on Circuits, Systems and SignalProcessing, ProRisc 2005; 2005

[Pia07] F. Pianese; PULSE An Adaptive Practical Live Streaming System; PhD Thesis,Université de Nice�Sophia Antipolis; 2007

[PKB06] F. Pianese, J. Keller, E.W. Biersack; PULSE, a Flexible P2P Live StreamingSystem; INFOCOM 2006; 2006

[PK+05] V. Pai, K. Kumar, K. Tamilmani, V. Sambamurthy, A. Mohr; Chainsaw: eli-minating trees from overlay multicast; Proc. IPTPS Workshop, Feb 2005; 2005

[PM08] F. Picconi, L. Massoulié; Is there a future for mesh-based live video streaming;P2P'08; 2008

[ppl] http://www.pplive.com/en/index.html

[pps] http://www.ppstream.com

[PS+01] D. Pendarakis, S. Shi, D. Verma, M. Waldvogel; ALMI: An Application levelMulticast Infrastructure; Proceedings of 3rd Usenix Symposium on InternetTechnologies and Systems, March 2001, pp. 49-60; 2001

100

[pta07] PTA GmbH; Agile Vorgehensmodelle in der Softwareentwicklung; PTA GmbH;2007

[PW+02] V. Padmanabhan, H. Wang, P. Chou, K. Sripanidkulchai; Distributing stre-aming media content using cooperative networking; Proc. ACM NOSSDAVWorkshop, May 2002; 2002

[RC08] A. Russo, R. Lo Cigno; Push/Pull Protocols for Streaming in P2P Systems;http://napa-wine.eu; 2008

[RD01] A. Rowstron, P. Druschel; Pastry: Scalable, decentralized object location, androuting for large-scale peer-to-peer systems. In IFIP/ACM International Con-ference on Distributed Systems Platforms (Middleware), pages 329-350, 2001;2001

[RF+00] S. Ratnasamy, P. Francis, M. Handley, R. Karp, S. Shenker; A scalable contentaddressable network; In Computer Communication Review, Vol. 31; 2000

[RG+01] A. Rodriguez, J. Gatrell, J. Karas, R. Peschke; TCP/IP Tutorial and Techni-cal Overview; IBM Corporation, International Technical Support Organization;2001

[RH+01] S. Ratnasamy, M. Handley, R. Karp, S. Shenker; Application-level Multicastusing Content-Addressable Networks; Proceedings of 2001 International Work-shop on Networked Group Communication, pp. 14-29; 2001

[Roj07] J.B. Rojas; P2PNetSim :: P2P Network Simulation Environment; FernUniver-sität in Hagen; 2007

[RS60] I.S. Reed, G. Solomon; Polynomial Codecs over certain �nite �elds; Journal ofthe Society for the Industrial and Applied Mathematics 8 (1960) 300-304; 1960

[Sch07] R. Schreiner; Computernetzwerke - Von den Grundlagen zur Funktion und An-wendung; Carl Hanser Verlag München; 2007

[Sch08] H. Schulzrinne; Some Frequently Asked Questions about RTP;http://www.cs.columbia.edu/~hgs/rtp/faq.html, Last updated 11/14/2008 ;2008

[SC+96] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson; RTP: A Transport Proto-col for Real-Time Applications, RFC 1889; http://tools.ietf.org/html/rfc1889;1996

[SF+08] T. Silverston, O. Fourmaux, A. Botta, A. Dainotti, A. Pescapé, G. Ventre, K.Salamatian; Tra�c analysis of peer-to-peer IPTV communities; Comput. Netw.(2008), doi:10.1016/j.comnet.2008.09.024; 2008

[Sim08] W. Simpson; Video Over IP, Second Edition; Focal Press, Elsevier Inc.; 2008

[SM+01] I. Stoica, R. Morris, D. Karger, F. Kaashoek, H. Balakrishnan; Chord: A sca-lable Peer-To-Peer lookup service for internet applications; In Proceedings ofthe 2001 ACM SIGCOMM Conference, pages 149-160, 2001; 2001

[sop] http://www.sopcast.org

101

[SRL98] H. Schulzrinne, A. Rao, R. Lanphier; Real Time Streaming Protocol (RTSP),RFC 2326; http://www.rfc-editor.org/rfc/rfc2326.txt; 1998

[SRP08] P. Shah, J. Rasheed, J.-F. Pâris; Performance Study of Unstructured P2P Over-lay Streaming Systems; ICCCN '08. Proceedings of 17th International Confe-rence on Computer Communications and Networks; 2008

[SW05] R. Steinmetz, K. Wehrle; Peer-to-Peer Systems and Applications; Springer; 2005

[SWS07] T. Strufe, J. Wildhagen, G. Schäfer; Netzwerke�zienz stabiler Overlay-Streaming-Topologien; Kommunikation in Verteilten Systemen (KiVS), 15.Fachtagung Kommunikation in Verteilten Systemen (KiVS 2007) Bern, Schweiz,26. Februar � 2. März 2007; 2007

[SZ+08] J. Seibert, D. Zage, S. Fahmy, C. Nita-Rotaru; Experimental Comparison ofPeer-to-Peer Streaming Overlays: An Application Perspective; In Proceedingsof IEEE LCN 2008; 2008

[THD03] D.A. Tran, K.A. Hua, T.T. Do; ZIGZAG: An e�cient peer- to-peer scheme formedia streaming; In: Proceedings of IEEE INFOCOM; 2003

[tuc10] Technische Universität Chemnitz; Vorlesung Medienapplikationen 04/01/2010�Medienverteilung (Teil 2)�; Technische Universität Chemnitz; 2010

[tva] http://tvants.en.softonic.com/

[uus] http://www.uusee.com

[VFC06] V. Venkataraman, P. Francis, J. Calandrino; Chunkyspread: Multi-tree Un-structured Peer-to-Peer Multicast; In: Proceedings of 5th international work-shop on peer-to-peer systems; 2006

[VIF06] A. Vlavianos, M. Iliofotou, M. Faloutsos; Bitos: enhancing bittorrent for sup-porting streaming applications; In 9th IEEE global internet symposium 2006,April 2006; 2006

[Vil09] D. Villa; Multimedia Streaming Using P2P Technologies;http://dev.emcelettronica.com; 2009

[VY07] S. Vénot, L. Yan; Peer-to-peer media streaming application survey; Internatio-nal Conference on Mobile Ubiquitous Computing, Systems, Services and Tech-nologies UBICOMM.2007.18; 2007

[Wan08] M. Wang; A quest for high-performance peer-to-peer live multimedia streaming;PhD Thesis, University of Toronto/Department of Electrical and ComputerEngineering; 2008

[WL07] M. Wang, B. Li; R2: Random Push with Random Network Coding in LivePeer-to-Peer Streaming; IEEE Journal on Selected Areas in Communications,Special Issue on Advances in Peer-to-Peer Streaming Systems, vol. 25, no. 9(Best Paper Award, the Multimedia Communications Technical Committee ofthe IEEE Communications Society, 2009); 2007

[WLQ06] G. Wen, H. Longshe, F. Qiang; Recent Advances in Peer-to-Peer Media Strea-ming Systems; China Communications October 2006; 2006

102

[Wol10] A. Wolf; SimBench: Ein Benchmark für den P2P-Simulator P2PNetSim; Ab-schlussarbeit FernUniversität in Hagen; 2010

[WPD88] D. Waitzmann, C. Patridge, S. Deering; Distance Vector Multicast RoutingProtocol; http://www.rfc-editor.org/rfc/rfc1075.txt; 1988

[XH+02] D. Xu, M. Hefeeda, S. Hambrusch, B. Bhargava; On Peer-to-Peer Media Strea-ming; Department of Computer Sciences, Purdue University, West Lafayette,IN 47907; 2002

[XL+07] S. Xie, B. Li, G.Y. Keung, X. Zhang; Coolstreaming: Design, Theory, andPractice; Transactions on Multimedia, Vol. 9, No. 8, December 2007; 2007

[YDL07] Y. Zhou; D.M. Chiu; J.C.S. Lui; A Simple Model for Analyzing P2P StreamingProtocols; The Chinese University of Hong Kong; 2007

[Zha07] Q. Zhang; Understanding the Power of Pull-based P2P Streaming Protocol: WeCan Do Even Better; SigComm P2PTV Workshop August 2007; 2007

[Zha10] Y. Zhang; Challenges of P2P Streaming and PPSP; IETF March 2010; 2010

[ZKJ01] B. Zhao, J. Kubiatowicz, A. Joseph; Tapestry: An Infrastructure for Fault-Tolerant Wide-area Location and Routing. Computer Science Division, Univer-sity of California, Berkeley Tech. Report no UCB/CSD-01-1141, April 2001;2001

[ZL+05] X. Zhang, J. Liu, B. Li, T.-S.P. Yum; CoolStreaming/DONet: A data-drivenoverlay network for live media streaming; Proc. IEEE INFOCOM'05; 2005

[Zon08] N. Zong; Survey and Problem Statement of P2P Streaming; IETF PPSP bof,November 2008; 2008

[Zon09] N. Zong; Chunk Discovery for P2P Streaming; PPSP Internet-Draft; 2009

[Zot10] V. Zota; Video-Poker: Google will neuen Web-Videostandard etablieren; c't13/10; 2010

[ZT+05] M. Zhang, Y. Tang, L. Zhao, J.-G. Luo, S. Yang; GRIDMEDIA: A Multi-SenderBased Peer-to-Peer Multicast System for Video Streaming; IEEE InternationalConference on Multimedia and Expo (ICME) 2005: 614-617; 2005

[ZX+09] M. Zhang, Y. Xiong, Q. Zhang, L. Sun, S. Yang; Optimizing the Throughputof Data-Driven Peer-to-Peer Streaming; In IEEE Transactions on Parallel andDistributed Systems, Vol. 20, Issue 1, Jan. 2009; 2009

[ZZ+01] S.Q. Zhuang, B.Y. Zhao, A.D. Joseph, R.H. Katz, J.D. Kubiatowicz; Bayeux:An Architecture for Scalable and Fault-tolerant Wide-area Data Dissemination;Proceedings of 2001 ACM International Workshop on Network and OperatingSystem Support for Digital Audio and Video (NOSSDAV'01), pp. 11-20; 2001

[ZZ+07] M. Zhang, Q. Zhang, L. Sun, S. Yang; Understanding the Power of Pull-basedStreaming Protocol: Can We Do Better?; In IEEE Journal on Selected Areas inCommunications, special issue on Advances in Peer-to-Peer Streaming Systems,Vol. 25, No. 8, Dec. 2007; 2007

103

[ZZ+09] Y. Zhang, N. Zong, G. Camarillo, J. Seng, R. Yang; Problem Statementof P2P Streaming Protocol (PPSP)/ draft-zhang-ppsp-problem-statement-05;http://tools.ietf.org; 2009

104

Abbildungsverzeichnis

1.1 Anstieg der Internetuser in China in Millionen und prozentual zum Vorjahr(nach [cnn10]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2 Nachfrage nach kommerziellen P2P-Streaming-Systemen (Stand Mai 2010)[goo10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Perspektivische Annäherung . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Unicast und IP-Multicast (nach [Sim08]) . . . . . . . . . . . . . . . . . . . 222.3 Streaming-Architekturen (nach [LR+08, Vil09]) . . . . . . . . . . . . . . 232.4 IP-Multicast und ALM (nach [BBK02]) . . . . . . . . . . . . . . . . . . . 25

3.1 Pu�er und dazugehörige Bu�ermap . . . . . . . . . . . . . . . . . . . . . . 33

4.1 Verbindungsstruktur bei zufälliger Partnerwahl (links), bei Wahl mit Be-rücksichtigung der Location-Awareness (Mitte) und bei dem hybriden An-satz (rechts) [CL+10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Mesh-Overlay-Schicht (Overlay Layer) und Datenverteilungsschicht (Dis-tribution Layer) in einem P2P-Streaming-Netzwerk [CLB07] . . . . . . . . 38

4.3 Prinzip der Netzwerkkodierung (NC) [MF09] . . . . . . . . . . . . . . . . 464.4 Zufälliger Verbindungsgraph des CoolStreaming-Netzwerks (10 Peers, ma-

ximale Partneranzahl=5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.5 Systemdiagramm eines CoolStreaming-Peers (nach [ZL+05]) . . . . . . . . 58

5.1 P2PNetSim-GUI mit Anzeige der Grundkon�guration (�Basic con�gurati-on�) und selbst de�nierter Parameter (�Properties�) von Peer10 . . . . . . 61

5.2 Implementierung des CoolStreaming-Peers . . . . . . . . . . . . . . . . . . 655.3 Zuordnung von Aufgaben zu Hauptmodulen beim CoolStreaming-Peer . . 695.4 Klassendiagramm der Hauptmodule . . . . . . . . . . . . . . . . . . . . . 705.5 Peerpu�er und Pu�er der Quelle (PUFFER_SIZE=60) . . . . . . . . . . . . . 725.6 Zusammenspiel zwischen Bandbreitenregulator und StreamingPeer . . 795.7 Verfügbarkeit von Segmenten (seg_id 0-9) bei Partnern (part_id 0-4) . . 835.8 Testdaten für Scheduling-Algorithmus . . . . . . . . . . . . . . . . . . . . 845.9 Veri�kation der Implementierung . . . . . . . . . . . . . . . . . . . . . . . 86

6.1 Continuity-Index in Abhängigkeit von der Berücksichtigung der Partner-bandbreite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.2 Continuity-Index in Abhängigkeit vom Beginn der Wiedergabe . . . . . . 90

105

Tabellenverzeichnis

1.1 Websites mit unautorisierten Fuÿball-Streams (Saison 2007/2008) [env08] 9

2.1 Gängige Kombinationen aus Container, Codecs und Protokollen [Sim08,tuc10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Klassi�zierung von P2P-Systemen und Vergleich ihrer Eigenschaften [PBV05,SW05] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

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

4.2 Kontrolloverhead von Tree-basierten ALM-Protokollen in Relation zur Kno-tenanzahl N [AYC04, CRZ00, HA+06] . . . . . . . . . . . . . . . . . . . . 54

4.3 Vergleich von Metriken bei Mesh-basierten und Mesh-/Tree-basierten ALM-Protokollen [Kos08, KR+03, LJ+06, OJ08, ZL+05, ZZ+07] . . . . . . . . 55

106

Glossar

Abtastrate (engl. sample rate/sampling rate) Frequenz, mit der analoge Audiosignalebeim Digitalisierungsprozess abgegri�en werden (gewöhnlich zwischen 32kHz und96kHz)

ALM (Application-Level-Multicast/Application-Layer-Multicast) Implementierung vonMulticast auf der Anwendungsebene.Synonyme: End-System-Multicast/ESM, End-System-Overlay-Multicast, Overlay-Multicast, Peer-to-Peer-Multicast, Peer-to-Peer-Broadcast, P2P-Internet-Video-Broadcast, P2P-Internet-Video-Streaming

Bu�ermap Darstellung des lokalen Pu�erinhalts als Bit-String oder Bitmap. Vorhan-dene Segmente werden durch �1� repräsentiert, nicht vorhandene durch �0�. Beider Pull-basierten Datenverteilung müssen die Peers regelmäÿig Bu�ermaps aus-tauschen.

Churn Hohe Fluktuation im Netzwerk, die dadurch entsteht, dass oft neue Peers insNetz kommen und verbundene Peers das Netz wieder verlassen.

Containerformat Enthält Audio- und Videoformate, eventuell Untertitel sowie Meta-informationen, die die synchronisierte Ausgabe ermöglichen.Synonym: Wrapperformat

Continuity-Index P2P-Streaming-Metrik. Gibt an, wie kontinuierlich die Wiedergabedes Streams erfolgt, und wird ermittelt durch die Relation von den rechtzeitigerhaltenen Segmente zu allen abzuspielenden Segmenten.Synonyme: Playback-Continuity-Index, Playback-Continuity

DDoS Distributed Denial-Of-Service

DHT (Distributed Hash Table) Verteilte Hash-Tabelle

DVB (Digital Video Broadcasting/Digitales Fernsehen) Europäische Organisation, dieStandards de�niert zum Broadcast von digitalen TV-Signalen. Die Verteilungder digitalen TV-Signale erfolgt per Kabel (DVB-C), Satellit (DVB-S), Anten-ne (DVB-T) oder mobil (DVB-H über Rundfunknetze).

ESM (End-System-Multicast) bezeichnet nach Sanjay G. Rao ganz allgemein die Ar-chitektur, in der ein Multicast-Baum über einem unstrukturierten/strukturiertenP2P-Overlay aufgebaut wird. Protokolle wie z.B. Narada realisieren ESM.

Fail Ausfall eines Knotens im Netzwerk.

107

Flash-Crowd (beim P2P-Streaming) Sprunghafter Anstieg der Useranzahl, die nachkurzer Zeit wieder sehr schnell fällt.

Flooding (Flutsuche) Broadcast an alle Peers im P2P-Netzwerk bis zum Ablauf einerTime-To-Live/TTL.

fps (frames per second) Die Bild-/Framerate gibt an, wie viele Bilder pro Sekundeangezeigt werden.

H.264 Standard zur Videokomprimierung aus dem MPEG-4-Paket des MPEG-Kon-sortiums. Ermöglicht eine e�zientere Komprimierung bei gleichbleibender Video-qualität und wird für Blu-ray-Disks oder HD-DVD eingesetzt.Synonyme: MPEG-4 Part 10, MPEG-4 AVC

Hybrides P2P-System 1. P2P-System mit statischen oder dynamischen zentralen Ein-heiten (z.B. Napster, FastTrack, Gnutella 0.6).2. P2P-System mit heterogenen Eigenschaften, das z.B. ein strukturiertes Sys-tem mit einem unstrukturiertem System verbindet (z.B. Gnutella-Netzwerk mitCAN-Routing-Algorithmus).

Join Ein Peer verbindet sich zum Netzwerk.

Kontrolloverhead P2P-Streaming-Metrik. Misst das Verhältnis von Kontrolldaten (inBytes) zu Videodaten (in Bytes).

Leave Ein Peer verlässt das Netzwerk.

Mesh-basiertes P2P-Streaming Die Verteilung der Streamdaten erfolgt über dyna-mische Routen innerhalb des Mesh.

Mesh (engl. für Masche) Unstrukturiertes/Strukturiertes Netzwerk, über das die Peersbeim P2P-Streaming verbunden sind.

MPEG (Moving Pictures Experts Group) Konsortium, das seit 1991 o�ene, patentierteStandards zur Kompression von Video- oder Audiodaten verö�entlicht.

Overlay Logisches Netzwerk oberhalb einer physischen Netzwerkstruktur, in denen zweiApplikationen über einen anderen Pfad kommunizieren als durch die Netzwerk-schicht gegeben. Nicht alle P2P-Netzwerke sind Overlay-Netzwerke (siehe MobileAd-hoc-Netzwerke) und nicht alle Overlay-Netzwerke sind P2P-Netzwerke (sieheVirtual-Private-Networks).Synonym: Overlay-Netzwerk

P2P-Streaming Streaming über ein P2P-Netzwerk. Beim P2P-Streaming laden End-systeme den Stream herunter und leiten ihn weiter.

Perceptual-Encoding Kompressionsverfahren für Audiosignale, das nur die durch dasmenschliche Gehör wahrnehmbaren Töne speichert.

108

Playback-Delay (Abspielverzögerung) P2P-Streaming-Metrik. Misst die Zeitdi�erenzzwischen der Ausgabe eines Streamsegments durch die Quelle und dessen Wie-dergabe durch den Peer.Synonyme: Playout-Delay, Display-Lag, Average-Reception-Delay

Startup-Delay (Anfangsverzögerung) P2P-Streaming-Metrik. Misst die Zeitdi�erenzzwischen der Kanalauswahl und dem Beginn des Live-Streams.Synonyme: Initial-Startup-Latency, SETUP-Delay, Click-to-play-Delay/C2P

Streamingrate Datenrate, mit der ein Stream übertragen wird. Bei True-Streamingmuss die verfügbare Downloadbandbreite mindestens so groÿ wie die Streaming-rate sein (im Internet üblich: ca. 400 kbps).Synonyme: Bitrate/Datenrate des Streams

Streaming Kontinuierliche Übertragung und Verwertung von Audio- und/oder Video-daten über ein IP-Netzwerk.Synonyme: Multimedia-Streaming, Media-Streaming

Strukturiertes P2P-System System, in dem Inhalte und Inhaltsbeschreibungen (z.B.Dateinamen, Metainformationen) in Relation zu den Knoten stehen, die für dieseInhalte zuständig sind. Dies kann durch eine wohlde�nierte Hash-Funktion reali-siert werden.Synonyme: stra� strukturiertes P2P-System, Content-orientiertes P2P-System,Content-addressierbares P2P-System, System mit Content-basiertem Routing undSystem mit Content-adressierbarer Datenhaltung

Tree-basiertes P2P-Streaming Die Verteilung der Streamdaten erfolgt über einenoder mehrere explizit aufgebaute Multicast-Bäume.

Unstrukturiertes P2P-System P2P-System, in dem die Daten zufällig ohne Relationzu den Knoten abgelegt werden.

109

Documents

Analyse und Implementierung eines offenen Streaming ... · Mit PPLive, PPStream, SopCast [sop], TVAnts [tva] und UUSee kommen die kommerziell erfolgreichsten P2P-Streaming-Anbieter