Analyse und Implementierung eines offenen Streaming

Analyse und Implementierung eines
oenen Streaming-Protokolls auf
P2P-Basis
Katrin Gustat
September 2010
FernUniversität in Hagen
Fakultät für Mathematik und Informatik
Lehrgebiet Kommunikationsnetze
Bachelor-Studiengang Informatik
Erstgutachter:
Prof. Dr.-Ing. habil. Herwig Unger
Zweitgutachter:
Prof. Dr. Jörg Keller
Betreuer:
Dipl.-Inf. Daniel Berg
Eidesstattliche Erklärung
Hiermit erkläre ich, dass ich die von mir dem Prüfungsausschuss der Fakultät für Mathematik und Informatik eingereichte Bachelorarbeit zum Thema
Analyse und Implementierung eines oenen Streaming-Protokolls auf P2P-Basis
vollkommen selbständig verfasst und keine anderen als die angegebenen Quellen und
Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe.
Granada, den 06.09.2010
Katrin Gustat
2
Kurzfassung
Seit dem Jahr 2000 wurden eine Vielzahl von wissenschaftlichen Arbeiten zum Thema
P2P-Streaming veröentlicht. Aufgrund der groÿen Menge an vorhandenen Abhandlungen, dem Fehlen einer allgemein gültigen Terminologie und der Tatsache, dass sich einige
Arbeiten sogar widersprechen, ist es sehr schwierig, einen verlässlichen Überblick zu erhalten.
Das Ziel dieser Arbeit ist daher, eine systematische Übersicht über den Bereich P2PStreaming zu liefern und die komplexe Funktionsweise von P2P-Streaming-Systemen
durch Analyse und Implementierung eines ausgewählten Protokolls, dem CoolStreamingProtokoll [ZL+05], vorzustellen.
Zunächst werden die Streaming-Technik, die Eigenschaften von Streaming auf P2PBasis und die Unterscheidungsmerkmale von P2P-Live-Streaming-Protokollen erläutert.
Ein Vergleich stellt die Charakteristiken von 21 der bekanntesten P2P-Live-StreamingProtokolle gegenüber und ist damit nach meinem Wissen der gröÿte Vergleich dieser Art.
Es folgen die Analyse und die Beschreibung der Implementierung des CoolStreamingProtokolls. Mögliche Erweiterungen dieses Protokolls werden diskutiert und ausgewertet.
Abstract
Since the year 2000 a vast number of papers on p2p sreaming has been published. The
large volume of existing information coupled with the lack of a generally accepted terminology and the existence of some dissenting papers make it rather dicult to obtain
a satisfactory overview of p2p streaming technology.
Therefore the goal of this work is to present a systematic survey of p2p streaming and
to describe the complex functionality of p2p streaming systems by analyzing and implementing one particular p2p streaming protocol called CoolStreaming [ZL+05].
First the work explains streaming technology and the characteristics of p2p streaming
and p2p live streaming protocols. It compares the features of 21 of the most discussed p2p
live streaming protocols which, to my knowledge, represents the largest comparison of
this kind. This is followed by an analysis and a description of the implementation of the
CoolStreaming protocol itself. Possible enhancements to this protocol are then discussed
and evaluated.
3
Inhaltsverzeichnis
1 Einführung
7
1.1
Erfolgsgeschichte
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.2
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.3
CoolStreaming
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
1.4
Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.5
Gliederung der Arbeit
14
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Streaming
2.1
15
Audio-/Videokomprimierung
. . . . . . . . . . . . . . . . . . . . . . . . .
15
2.1.1
Digitalisierung analoger Daten
. . . . . . . . . . . . . . . . . . . .
16
2.1.2
Codecs, Datei- und Containerformate . . . . . . . . . . . . . . . . .
17
Der MPEG-Standard . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.1.3
2.1.4
2.1.3.1
MPEG-Videocodecs
. . . . . . . . . . . . . . . . . . . . .
18
2.1.3.2
MPEG-Audiocodecs . . . . . . . . . . . . . . . . . . . . .
18
. . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.2
Streaming-Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.3
Streaming-Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.4
Verbindungsarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.5
Streaming-Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.5.1
2.5.2
2.6
Zusammenfassung
Klassische Architekturen . . . . . . . . . . . . . . . . . . . . . . . .
23
2.5.1.1
Client/Server . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.5.1.2
CDN
23
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multicast über Internet
. . . . . . . . . . . . . . . . . . . . . . . .
24
. . . . . . . . . . . . . . . . . . . . . . . . .
24
2.5.2.1
IP-Multicast
2.5.2.2
Application-Level-Multicast . . . . . . . . . . . . . . . . .
Zusammenfassung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 P2P-Streaming
3.1
P2P
25
26
28
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1
Begrisklärung
3.1.2
Klassizierung von P2P-Systemen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
28
. . . . . . . . . . . . . . . . . .
29
3.2
Zusammenhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.3
Grundlegende Konzepte
32
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1
Video-On-Demand
. . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.3.2
Live-Streaming
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4 Analyse
4.1
35
Allgemeines Prozessmodell für P2P-Live-Streaming . . . . . . . . . . . . .
4
35
4.2
Protokollcharakteristiken . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1
Join
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.2.2
Topologie der Streamverteilung . . . . . . . . . . . . . . . . . . . .
37
Art der Streamverteilung
39
4.2.3
4.2.4
4.2.5
4.2.6
4.2.7
4.3
4.4
36
. . . . . . . . . . . . . . . . . . . . . . .
4.2.3.1
Push
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.2.3.2
Pull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.2.3.3
Hybrides Push-Pull
. . . . . . . . . . . . . . . . . . . . .
40
. . . . . . . . . . . . . . . . . . . . . . . . . .
41
Gruppenverwaltung
4.2.4.1
Vater-Sohn-Beziehungen/Partnerschaften
4.2.4.2
Verwaltung der Gruppenmitglieder . . . . . . . . . . . . .
Fehlerkorrekturmechanismen und Kodierungen
. . . . . . . . .
41
42
. . . . . . . . . . .
44
4.2.5.1
MDC (Multiple-Description-Coding) . . . . . . . . . . . .
45
4.2.5.2
FEC (Forward-Error-Correction/Vorwärtsfehlerkorrektur)
45
4.2.5.3
NC (Network-Coding/Netzwerkkodierung)
. . . . . . . .
46
. . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.2.6.1
RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.2.6.2
UDP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.2.6.3
TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.2.6.4
Wahl des Transportprotokolls . . . . . . . . . . . . . . . .
48
Transportprotokolle
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
Mesh-Pull-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Überblick
49
4.3.1
Scheduler
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.3.2
Bearbeitung von Datenrequests . . . . . . . . . . . . . . . . . . . .
52
Performance-Vergleich
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.4.1
Protokolleigenschaften . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.4.2
P2P-Streaming-Metriken . . . . . . . . . . . . . . . . . . . . . . . .
53
4.5
Graph-Analyse
4.6
Zusammenfassung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Implementierung
56
57
60
5.1
P2PNetSim
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2
SimBench
5.3
Vorgehensmodell
5.4
Module
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
62
63
65
5.4.1
Überblick
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
5.4.2
Datentransport . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
5.4.3
Die Klasse StreamingMessage . . . . . . . . . . . . . . . . . . . . .
68
5.4.4
Die Klasse StreamingPeer
. . . . . . . . . . . . . . . . . . . . . . .
68
5.4.5
Hauptmodule eines Streamingpeers . . . . . . . . . . . . . . . . . .
69
5.4.6
Das Paket datenmanager
. . . . . . . . . . . . . . . . . . . . . . .
70
5.4.6.1
Die Klasse DatenManager . . . . . . . . . . . . . . . . . .
71
5.4.6.2
Die Klasse P2PStream . . . . . . . . . . . . . . . . . . . .
71
5.4.6.3
Die Klasse StreamSegment
. . . . . . . . . . . . . . . . .
71
5.4.6.4
Die Klasse SegmentID . . . . . . . . . . . . . . . . . . . .
71
5.4.6.5
Die Klasse Puer . . . . . . . . . . . . . . . . . . . . . . .
72
5.4.6.6
Die Klasse Scheduler . . . . . . . . . . . . . . . . . . . . .
73
5
5.4.7
5.4.9
5.6
Die Klasse FirstOset . . . . . . . . . . . . . . . . . . . .
73
5.4.6.8
Die Klasse Player
74
. . . . . . . . . . . . . . . . . . . . . .
Das Paket partnershipmanager
5.4.8
5.5
5.4.6.7
. . . . . . . . . . . . . . . . . . . .
74
5.4.7.1
Die Klasse Partner
. . . . . . . . . . . . . . . . . . . . .
74
5.4.7.2
Die Klasse PartnerListe . . . . . . . . . . . . . . . . . . .
75
Das Paket membershipmanager . . . . . . . . . . . . . . . . . . . .
75
5.4.8.1
Die Klasse MembershipCache . . . . . . . . . . . . . . . .
76
5.4.8.2
Die Klasse MembershipManager
76
Das Paket util
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
5.4.9.1
Die Klasse MyLogger
. . . . . . . . . . . . . . . . . . . .
77
5.4.9.2
Die Klasse Bandbreitenregulator . . . . . . . . . . . . . .
78
5.4.9.3
Die Klasse Zeit . . . . . . . . . . . . . . . . . . . . . . . .
79
5.4.9.4
Die Klasse StreamingAddress . . . . . . . . . . . . . . . .
80
Test
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.5.1
Bedeutung des Testens . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.5.2
Modultests
81
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.2.1
JUnit in der Praxis
5.5.2.2
Exemplarischer Testfall
Verikation
. . . . . . . . . . . . . . . . . . . . .
81
. . . . . . . . . . . . . . . . . . .
82
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
6 Auswertung
87
6.1
Simulationsaufbau
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
6.2
Evaluierung und Optimierung . . . . . . . . . . . . . . . . . . . . . . . . .
88
6.3
Zusammenfassung
91
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Abschluss
93
7.1
Feedback zu P2PNetSim . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
7.2
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
7.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, darunter
eine nicht unerhebliche Zahl in China oder Hongkong. Gleichzeitig kommen aus China die
kommerziell erfolgreichsten P2P-Streaming-Lösungen. Zu Beginn dieser Arbeit analysiere
ich den Erfolg von P2P-Streaming in China, um die Faktoren herauszunden, unter denen
ein für P2P-Streaming-Entwicklungen günstiges Klima entsteht.
Es wird dann die Motivation für diese Arbeit dargelegt und aufgezeigt, worin sich diese
Arbeit von den vorhandenen P2P-Streaming-Arbeiten unterscheidet und nach welchen
Kriterien das zu implementierende Protokoll ausgewählt wurde. Es folgen Denitionen,
die erforderlich sind, um die Aufgabenstellung zu erfassen und abzugrenzen. Das Kapitel
schlieÿt mit der Gliederung dieser Arbeit.
1.1 Erfolgsgeschichte P2P-Streaming
Nicht wenige Arbeiten über P2P-Streaming beginnen mit der Aussage, dass sich P2PStreaming immer gröÿerer Beliebtheit erfreut, sich immer mehr verbreitet u.ä. Wie sieht
dieser Erfolg konkret aus?
Die beeindruckendsten Zahlen dazu kommen aus China, wo sich die Anzahl der User, die
gleichzeitig die Übertragung eines Live-Ereignisses über einen P2P-Streaming-Anbieter
verfolgten, innerhalb weniger Jahre mehr als verzehnfacht hat:
2005: PPLive [ppl] misst 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 Übertragungen anlässlich des 60.Nationalfeiertags Chinas, PPLive weitere 2 Millionen und
UUSee 2-3 Millionen. [Zha10]
Zum Vergleich: Die Amtseinführung von US-Präsident Obama am 20.01.2009 war das
meist beachtete Medienereignis in den USA der letzten Jahre. Bei CNN verfolgten nur
650.000 gleichzeitige P2P-Streaming-User die Übertragungen zur Amtseinführung, obwohl CNN gemessen an den anderen Sendern noch die meisten Online-Zuschauer erreichen konnte [new09]. Vergleicht man beide Medienereignisse aus dem Jahre 2009 miteinander (60.Nationalfeiertag in China, Obamas Amtseinführung in den USA) und setzt die
1
Amerikanische Basketball-Liga
7
1.1. ERFOLGSGESCHICHTE
KAPITEL 1. EINFÜHRUNG
Userzahlen in Relation zur jeweiligen Bevölkerung mit Internetanbindung, kommt man
zu folgendem Ergebnis: Während in den USA nur 0,3% die P2P-Streaming-Übertragung
nutzten, betrug der Anteil in China 3,1% (bei PPStream, PPLive, UUSee).
Mit PPLive, PPStream, SopCast [sop], TVAnts [tva] und UUSee kommen die kommerziell
erfolgreichsten P2P-Streaming-Anbieter aus China. Auÿerhalb Chinas sind in erster Linie
TVUnetworks (Sitz: Mountain View) mit dem TVUPlayer und Zattoo (Schweiz) bekannt,
2 nur in 6 europäischen Ländern3 empfangen werden kann.
wobei Zattoo derzeit
Neben den Anbietern stammt auch ein Groÿteil der Konsumenten aus China (bei PPLive
70-80% [Zha10]), auf die das Streamingangebot zugeschnitten ist. Viele der aktuellen wissenschaftlichen P2P-Streaming-Arbeiten wurden an Universitäten in China oder Hong-
4
kong verfasst, an denen u.a. auch kommerzielle Systeme entstanden wie PPLive , Sop-
5
6 oder CoolStreaming7 . China ist führend, sowohl was Nachfrage und
Cast , TVAnts
Angebot als auch die Weiterentwicklung betrit.
Wie lässt sich dieser Erfolg Chinas im Bereich P2P-Streaming erklären?
Moderate Urheberrechtsbestimmungen
Auf meine Nachfrage bei den Autoren von
P2P-Streaming-Protokollen Xinyan Zhang (CoolStreaming [ZL+05]) und Sanjay G. Rao
(Narada [CRZ00, CR+02]) gaben beide als Hauptgrund für die führende Rolle Chinas
die moderaten Urheberrechtsbestimmungen des Landes an. Laut Zhang begünstigen diese
das Klima für P2P-Streaming-Entwicklungen in China.
In der westlichen Welt dagegen haftet P2P und P2P-Streaming anscheinend der Nimbus des Illegalen an, vor allem nachdem Unternehmen wie Napster [nap], Kazaa oder
Cyber***-TV schlieÿen mussten. Beispielhaft für den schlechten Ruf von P2P-Streaming
sind die negativen Reaktionen in den USA auf den P2P-Live-Stream von CNN, mit dem
Benutzer die Übertragung der Amtseinführung Obamas verfolgen konnten. Die Benutzer
mussten dazu ein Plugin herunterladen. CNN hatte vorab zwar mehrfach bekannt gegeben, dass die Übertragung per P2P erfolgt. Beim Download des Plugins selbst wies der
Sender aber nicht ausdrücklich auf diese Tatsache hin. Aus dem Grund wurde CNN von
mehreren Seiten vorgeworfen, seine Benutzer getäuscht zu haben. Microsoft beschuldigte
CNN, die Uploadbandbreite der Benutzer entführt zu haben, andere sprachen sogar
davon, dass CNN die Rechner seiner Benutzer gestohlen habe [new09].
Staatliche Förderung
Die chinesische Regierung investiert einerseits in den Ausbau der
Internetinfrastruktur. Im Jahre 2009 waren es 277,34 Milliarden Dollar, was einen Anstieg
um 28,5% im Vergleich zum Vorjahr bedeutet [cnn10]. Die Regierung fördert andererseits
den Einsatz von IPTV und damit indirekt von alternativen Übertragungstechnologien wie
2
Stand 08/2010
Deutschland, Frankreich, Schweiz, Groÿbritannien, Spanien, Dänemark
4
Huazhong University of Science and Technology
5
Fudan University
6
Zhejiang University
7
HKUST (Hong Kong University of Science and Technology), The Chinese University of Hong Kong,
Simon Fraser University in Vancouver
3
8
1.1. ERFOLGSGESCHICHTE
KAPITEL 1. EINFÜHRUNG
P2P. Parteimitglieder in ländlichen Gegenden erhalten Fernunterricht mittels IPTV und
das Ministerium für Informationsindustrie veranstaltet Forschungsrunden zusammen mit
Herstellern und Telekommunikationsanbietern zur Entwicklung eigener IPTV-Standards
[Ksh08].
Hohe Nachfrage nach Live-Übertragung von Groÿ- und Sportereignissen
Die Über-
tragung von Groÿereignissen - wie Olympia 2008 in Peking, Chinas 60.Nationalfeiertag
2009 und die Weltausstellung in Schanghai 2010 - wirken sich gewiss fördernd auf die
Nachfrage nach Live-Streams aus. Darüber hinaus kann in China ein hohes Interesse
an Sport-Übertragungen per P2P-Live-Stream verzeichnet werden. Das betrit in erster
Linie Cricket (Indian Premier League), Fuÿball (English Premier League, Bundesliga,
Spaniens La Liga, Italiens Serie A) und Basketball (NBA), letzteres vor allem seitdem
chinesische Basketballer in der amerikanischen NBA spielen. Die Begegnung zwischen
Dallas Mavericks und Houston Rocket, bei der Yao Ming aus China mitspielte, wurde im
Dezember 2007 von 936.000 seiner Landsleute live gestreamt (bei SopCast).
Problematischerweise erfolgen viele Übertragungen unautorisiert. Je nach Sportart werden ca. 30% (Cricket), 75% (Basketball) bzw. 88% (Fuÿball) dieser unautorisierten Übertragungen über P2P-Netze gestreamt. Tabelle 1.1 listet unautorisierte Fuÿball-Streams
aus der Saison 2007/2008 auf und gibt Aufschluss darüber, inwieweit die Streams P2Pbasiert erfolgten. Während hauptsächlich SopCast und TVAnts zum unautorisierten
Streamen von Live-Sportereignissen genutzt werden (der Upload eigener Streams ist bei
beiden möglich) schlossen PPLive und PPStream mit der amerikanischen NBA Partnerschaften ab, um autorisierte Live-Streams anbieten zu können [env08, oec09].
Liga
Sites
P2P-basiert
Unicast
User aus China
User auÿerhalb Chinas
Premier League
Bundesliga
La Liga
Serie A
Durchschnitt
177
85
49
53
91
63%
96%
98%
96%
88%
37%
4%
2%
4%
12%
49%
73%
55%
57%
57%
51%
27%
45%
43%
43%
Tabelle 1.1: Websites mit unautorisierten Fuÿball-Streams (Saison 2007/2008) [env08]
Konsumentenstruktur
Chinesische Konsumenten gelten als technikan und adaptieren
neue Techniken schnell. Bereits Mitte der 80er Jahre waren in China Konsumgebrauchsgüter so stark verbreitet wie in Japan oder Südkorea [Ksh08].
Internetuserstruktur
Was das Internet betrit, bendet sich China immer noch in der
Wachstumsphase. Die Anzahl der Internetuser ist 2009 im Vergleich zum Vorjahr um
28,9% auf insgesamt 384 Millionen gestiegen (siehe Abbildung 1.1). Trotz des stetigen
Wachstums besaÿen 2009 weniger als ein Drittel (28,9%) der Bevölkerung in China einen
Internetzugang, im Gegensatz zu rund 75% in den USA oder Japan. Dadurch ergibt sich
auch eine andere Userstruktur. Gut 60% der User sind jünger als 30 Jahre, haben ein
9
1.2. MOTIVATION
KAPITEL 1.
EINFÜHRUNG
Abbildung 1.1: Anstieg der Internetuser in China in Millionen und prozentual zum Vorjahr (nach [cnn10])
geringes Einkommen, 29% sind Studenten. Dies kann die Nachfrage nach kostenlosen
Downloads und P2P-Streams erklären.
Die zu Beginn dieses Abschnitts zitierten hohen Userbeteiligungen wurden beim Streaming von Live-Ereignissen erreicht. Dabei kann es zu sogenannten Flash-Crowds kommen, d.h. die Anzahl der User, die einen Kanal streamen möchten, steigt sprunghaft an
und fällt nach kurzer Zeit wieder sehr schnell ab. Der Erfolg von P2P-Live-Streaming
stellt durch diese kurzzeitig sehr hohe Nachfrage damit gleichzeitig eine groÿe technische
Herausforderung dar.
1.2 Motivation
Zum Thema P2P-Streaming wurde eine sehr groÿe Anzahl wissenschaftlicher Abhandlungen veröentlicht. In vielen Abhandlungen wird jeweils ein einzelnes P2P-StreamingProtokoll behandelt. Die wenigen vergleichenden Arbeiten widersprechen sich teilweise,
wenn es um die Kategorisierung der Protokolle geht. Zudem wurden Begriichkeiten bisher nicht einheitlich deniert. Dies macht es sehr schwierig, einen Überblick über diesen
Forschungsbereich zu erhalten.
Viele wissenschaftlich untersuchte Protokolle sind kommerziell zudem nicht von Interesse.
Einige werden nur im Rahmen einer Abschlussarbeit entwickelt und nden in sonstigen
10
1.3. COOLSTREAMING
KAPITEL 1. EINFÜHRUNG
Abhandlungen keine Erwähnung. Kommerziell erfolgreiche Systeme wie z.B. PPLive,
PPStream und SopCast sind im Realbetrieb erprobt, aber deren Protokolleigenschaften
werden nicht veröentlicht.
Das Ziel dieser Arbeit ist daher, einen systematischen Überblick über die wesentlichen Charakteristiken von P2P-Streaming zu liefern und aufzuzeigen, worin sich P2PStreaming-Protokolle unterscheiden. Es folgt die Veranschaulichung der Arbeitsweise eines ausgewählten P2P-Streaming-Protokolls mittels Analyse und Implementierung. Da
der Schwerpunkt der aktuellen P2P-Streaming-Forschungen auf Protokollen liegt, mit
denen Inhalte live gestreamt werden können, sollte das ausgewählte Protokoll für LiveStreaming-Anwendungen konzipiert sein. Aufgrund der groÿen Anzahl von Protokollen
aus China bot es sich zudem an, ein Protokoll aus diesem Land zu berücksichtigen. Das
Protokoll sollte auÿerdem von kommerzieller und wissenschaftlicher Bedeutung sein sowie klar und übersichtlich strukturiert, um den komplexen Streamingablauf verdeutlichen
und erweitern zu können. CoolStreaming erfüllt alle diese Anforderungen.
1.3 CoolStreaming
Die Autoren um Xinyan Zhang beschreiben in [ZL+05] DONet, ein Data-driven Overlay
Network. So wie bei den meisten im Realbetrieb eingesetzten P2P-Streaming-Systemen
üblich, arbeitet es datengesteuert (data-driven), d.h. der Empfänger fordert fehlende
Daten beim Sender an. Damit unterschied es sich von seinen Vorgängern und wird daher
mitunter als das erste echte P2P-Streaming-System bezeichnet.
Bereits im Mai 2004 wurde eine Internet-basierte DONet-Implementierung unter dem
Namen CoolStreaming in der Version 0.9 veröentlicht. Da CoolStreaming nicht nur
gut klang, sondern auch eine technische Konnotation hatte (Cooperative Overlay Streaming), wurde das System unter dieser Bezeichnung eingesetzt und bekannt. Bis zum
Sommer 2005 gab es Millionen Downloads und bis zu 80.000 gleichzeitige User aus 24
Ländern bei einer durchschnittlichen Streamingrate von 400 kbps. CoolStreaming war
auch die erste Software, die Live-TV-Übertragungen über das Internet anbot.
Die CoolStreaming-Autoren gaben in [ZL+05] Protokoll-Details bekannt, im Unterschied
zu den danach entwickelten Systemen wie PPLive, SopCast, TVAnts und PPStream,
welche sehr schnell an Bekanntheitsgrad gewannen (siehe Abbildung 1.2).
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 Corporation, das 2006 in Zusammenarbeit mit Yahoo Live-IPTV-Programme anbot [Zha07].
Urheberrechtsstreitigkeiten führten u.a. dazu, dass unter der gleich lautenden Adresse
http://www.coolstreaming.us nicht das in dieser Arbeit besprochene System zu nden
ist.
11
1.4. AUFGABENSTELLUNG
KAPITEL 1. EINFÜHRUNG
Abbildung 1.2: Nachfrage nach kommerziellen P2P-Streaming-Systemen (Stand Mai
2010) [goo10]
1.4 Aufgabenstellung und Begrisklärung
Die Annäherung an das Thema der Arbeit Analyse und Implementierung eines oenen
Streaming-Protokolls auf P2P-Basis erfolgt durch Klärung und Abgrenzung der Begrie
Protokoll, oen, P2P und Streaming sowie weiterer Begrie, die auf diesen Wörtern
aufbauen.
Protokoll
Ein Protokoll ist ganz allgemein eine Folge von Regeln, d.h. eine Folge von
mehreren fest vorgegebenen Schritten, mit denen die Rahmenbedingungen einer Kommunikation festgelegt werden [Bra05, FH07, Sch07]. Für den Aufbau und Betrieb eines
P2P-Streaming-Systems sind mehrere Protokolle (z.B. für Partnerverwaltung, Gruppenverwaltung) und auch kommunikationsübergreifende Komponenten erforderlich (wie der
Scheduler, siehe Abschnitt 4.3.1). Für diese Arbeit deniere ich ein P2P-Streaming-Protokoll als Einheit aus verschiedenen Protokollen und Algorithmen, die zum Aufbau und
Test eines P2P-Streaming-Systems (in diesem Fall CoolStreaming) benötigt werden.
Oenes Protokoll
Damit ein Protokoll als oen bezeichnet werden kann, muss der
Quellcode nicht zwingend oen gelegt werden. Wesentliche Protokolleigenschaften wurden aber von den Entwicklern veröentlicht und sind bekannt. Dies trit für das Protokoll
CoolStreaming zu. Im Gegensatz dazu stehen z.B. PPLive und SopCast, deren Charakteristiken nur über Reverse-Engineering zu ermitteln sind.
P2P
In einem P2P-System kommunizieren die Rechnerknoten (die Peers) 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 bezeichnete
zunächst die von Holzfällern angewandte Methode, Baumstämme hintereinander über
Strö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 Daten. Beim Streaming - genauer Multimedia-Streaming/Media-Streaming - werden Audiound/oder Videodaten über ein IP-Netzwerk übertragen und kontinuierlich verwertet
[FH07].
Zum Verständnis der dahinter liegenden Konzepte wird in Kapitel 2 erörtert, welche
Daten in welchem Format gestreamt werden können sowie wo, wie und wofür Streaming
eingesetzt wird (siehe Abbildung 2.1).
P2P-Streaming-System/-Lösung
Die Begrie P2P-Streaming-Lösung und P2P-Strea-
ming-System werden in der Fachliteratur meist analog verwendet. Um die Begrie P2PStreaming-System und P2P-Streaming-Protokoll voneinander abzugrenzen, deniere ich
ein P2P-Streaming-System wie folgt:
Die praktische Umsetzung betreend kann ein P2P-Streaming-System als Implementierung eines P2P-Streaming-Protokolls bezeichnet werden.
Die Architektur betreend ist ein P2P-Streaming-System eine Einheit bestehend
aus Software- und Hardwarekomponenten, die eine Architektur für P2P-Streaming
zur Verfügung stellen.
P2P-Streaming-Applikation/-Anwendung/-Software
Ist ein System mit einer Benut-
zerschnittstelle ausgestattet und direkt lauähig, spricht man von einer Applikation
[FH07]. Eine P2P-Streaming-Applikation stellt einem Peer eine Schnittstelle zur Verfügung, wodurch dieser in einem dedizierten P2P-Streaming-Netz Mitglied werden und
Daten streamen kann. Die Applikation umfasst eine Schnittstelle zu einem oder mehreren
gängigen Medienplayern (bei kommerziellen Produkten in erster Linie Windows Media
Player).
P2P-Streaming-Netzwerk/-Netz/-Overlay
Die Menge der Peers in einem P2P-Strea-
ming-System lässt sich formal als endliche, nicht leere Knotenmenge V beschreiben, bestehend 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
einem Peer
von
Pi
Pj
verbunden, dann wird
Pj
Pi
mit
als Nachbar oder Partner (bei CoolStreaming)
bezeichnet.
Die Menge der Partnerschaftsbeziehungen in einem P2P-Streaming-Netzwerk lässt sich
formal als Menge E aus Kanten beschreiben, wobei E eine Teilmenge der Menge aller
möglichen Partnerschaftsbeziehungen zwischen zwei Peers
Pi
E ⊆ {(Pi , Pj ) | Pi , Pj ∈ V ∧ i 6= j}
13
und
Pj
darstellt:
1.5. GLIEDERUNG DER ARBEIT
KAPITEL 1. EINFÜHRUNG
Ein P2P-Streaming-Netzwerk kann somit als ein gerichteter Graph G deniert werden, als
Tupel bestehend aus der Peermenge V und der Menge E aus Partnerschaftsbeziehungen:
G = (V, E)
Im P2P-Bereich tragen Netzwerke, die auf einer bestimmten Datenstruktur (z.B. CAN
[RF+00]) oder einem Protokoll (z.B. Gnutella [Cli01]) aufbauen, den Namen dieser Datenstruktur oder des Protokolls. So spricht man vom CAN-Netzwerk oder GnutellaNetzwerk.
1.5 Gliederung der Arbeit
In Kapitel 2 werden zunächst die Grundlagen des Streamings erklärt. Dabei wird insbesondere erläutert, welche Daten gestreamt werden können, welche Anwendungen und
Methoden zu unterscheiden sind und über welche Architekturen Streaming realisiert werden kann. In Kapitel 3 wird dargelegt, was P2P bedeutet, sowie eine Einführung in den
Bereich P2P-Streaming gegeben, wobei die grundlegenden Konzepte gezeigt werden.
Aufbauend auf den beiden genannten Kapiteln erfolgt in Kapitel 4 die Analyse des
CoolStreaming-Protokolls, indem CoolStreaming anhand seiner Protokollcharakteristiken sowie seiner Performance mit anderen P2P-Live-Streaming-Protokollen verglichen
wird. In diesem Kapitel werden auÿerdem 21 P2P-Live-Streaming-Protokolle in einem
tabellarischen Vergleich gegenübergestellt (siehe Tabelle 4.1).
In Kapitel 5 wird die Implementierung des CoolStreaming-Protokolls beschrieben und im
darauf folgenden Kapitel 6 evaluiert. Im abschlieÿenden Kapitel 7 werden die Erfahrungen
bei der Implementierung mit dem Simulator P2PNetSim geschildert und ein Ausblick auf
zukünftige Entwicklungen in den Bereichen Streaming und P2P-Streaming gegeben.
14
2 Theoretische Grundlagen - Streaming
Ziel dieses Kapitels ist, als Grundlage für die späteren Kapitel den Begri Streaming
vollständig abzuklären. Dazu wird die Top-Down-Methodik angewandt und auf vier wesentliche Perspektiven bzw. Fragestellungen eingegangen, die in Abbildung 2.1 dargestellt
sind.
Streaming
Was?
Audio-/Videodaten
komprimiert
Wo?
LAN/WAN
Wofür?
Wie?
Anwendungen?
Methoden?
Verbindungsarten?
Architekturen?
Abbildung 2.1: Perspektivische Annäherung
Beim Streaming werden Audio- und/oder Videodaten über ein IP-Netzwerk (LAN, WAN)
übertragen, wobei der Schwerpunkt dieser Arbeit auf der Übertragung im Internet liegt.
Die Daten müssen zuerst kodiert und komprimiert werden. Zunächst werden die grundlegenden Schritte dieses Prozesses erklärt. Es folgt eine Übersicht über Standards und
Verfahren, wobei der Unterschied zwischen Codecs (z.B. MPEG-4 Part 10), Containerformaten (z.B. MP4) und kodierten Dateiformaten (z.B. .mp4) am Beispiel des MPEGStandards beleuchtet wird. Anschlieÿend wird erläutert, für welche Anwendungen, nach
welchen Methoden und über welche Verbindungsarten bzw. Architekturen Streaming
realisiert werden kann.
2.1 Audio-/Videokomprimierung
Die ersten bekannten Versuche, Multimediadaten zu digitalisieren, stammen aus den
frühen 90er Jahren. Sun Microsystems entwickelte Audiodateien mit der Dateiendung
.au. Diese enthielten einfachste Audiodaten, die auf dem Rechner wiedergegeben werden konnten. Später konnte Apples QuickTime bereits Videodaten abspielen, die allerdings für den Transport über das Internet zu groÿ waren. Der Durchbruch beim
Streaming gelang RealNetworks, indem es die Daten in ein ausreichend kleines Format brachte. RealNetworks war mit seinem RealPlayer lange Marktführer, wurde aber
aufgrund schlechter Preispolitik und mangelnder Bedienerfreundlichkeit inzwischen von
15
2.1. AUDIO-/VIDEOKOMPRIMIERUNG
KAPITEL 2.
STREAMING
Apple QuickTime, Microsoft Windows Media Player und Adobe Flash Player zurückgedrängt.
2.1.1 Digitalisierung analoger Daten
Damit das menschliche Auge einzelne Bilder als fortlaufenden Film wahrnimmt, müssen ca. 15 bis 25 einzelne Bilder pro Sekunde abgespielt werden. Man spricht in diesem
Zusammenhang von Bildrate/Framerate oder fps (frames per second). Die beiden verbreiteten Videoformate PAL
1 und NTSC2 unterscheiden sich bzgl. der Framerate. PAL
arbeitet mit 25fps, d.h. jedes Bild wird für eine Dauer von 40ms gezeigt. Im Gegensatz
dazu beträgt die Framerate bei NTSC 29.97fps, so dass aller 33ms das Bild wechselt.
Ziel der Digitalisierung von Videosignalen für den WAN-Transport ist es, eine möglichst
geringe Datenmenge zu erhalten. Zu diesem Zweck digitalisiert und komprimiert ein
MPEG-Encoder die Videosignale redundanzfrei, d.h. es werden nicht jeder Frame einzeln
abgespeichert, sondern nur die Bilddierenzen. Nach dem MPEG-Standard unterscheidet
man drei Arten von komprimierten Frames:
I-Frame (Intra-Frame/Key-Frame)
Das komplette Bild wird kodiert ohne Berücksich-
tigung vorheriger oder nachfolgender Frames. Ein I-Frame dient sozusagen als Referenzbild und wird z.B. bei einem Szenewechsel erstellt.
P-Frame (Predicted-Frame)
Ein P-Frame enthält die Dierenz zwischen dem aktuellen
Bild und dem letzten vorangegangen I-Frame/P-Frame.
B-Frame (Bidirectional-Frame)
Ein B-Frame wird mit Hilfe von bidirektionaler Kom-
pression kodiert. Dabei wird die Dierenz zwischen dem aktuellen Bild und dem letzten
vorangegangen I-Frame/P-Frame kodiert sowie die Dierenz zwischen dem aktuellen Bild
und dem nachfolgenden I-Frame/P-Frame.
Frames werden in sogenannten GOPs gruppiert, wobei GOP die Kurzform von group
of pictures ist. Am Anfang einer jeden GOP steht ein I-Frame, gefolgt von mehreren
P-Frames oder B-Frames. Muss ein neuer I-Frame erstellt werden, beginnt ein neuer
GOP. Dies ist beispielsweise bei einem kompletten Szenewechsel der Fall.
Jeder Frame wird zudem in Makroblöcke von jeweils 16x16 Pixel zerlegt. Zu jedem Makroblock gibt es einen Bewegungsvektor (motion vector), der die Bewegung des Makroblocks
zwischen zwei aufeinander folgenden Bildern beschreibt. Die Bewegung wird durch die
Angabe der Richtung und der Entfernung beschrieben.
Zur Digitalisierung analoger Audiodaten werden pro Sekunde Tausende Muster (engl.
samples) des analogen Signals erfasst. Die Abtastrate (engl. sample rate/sampling rate)
gibt die Frequenz an, mit der die analogen Signale abgegrien werden. Folgende Abtastraten sind gebräuchlich:
1
2
in Europa
in Nord-/Südamerika, Japan, Korea, Taiwan
16
2.1. AUDIO-/VIDEOKOMPRIMIERUNG
KAPITEL 2.
STREAMING
32kHz: Für FM-Radio und andere Audio-Broadcasts werden meist 32.000 Muster
pro Sekunde abgegrien.
44,1kHz ist die übliche Abtastrate für Audio-CDs.
48kHz wird bei professionellen Anwendungen, u.a. für das Fernsehen, verwendet.
96kHz wird von neueren professionellen Anwendungen eingesetzt.
Für Stereoaufnahmen verdoppelt sich zudem die Abtastrate. Statt einem Sample werden
jeweils zwei Muster abgegrien für den linken und den rechten Audiokanal.
Digitale Audiosignale liegen komprimiert oder unkomprimiert vor. Durch sogenanntes
Perceptual-Encoding können Audiosignale ezient komprimiert werden. Hierbei werden
nur die vom menschlichen Gehör wahrnehmbaren Töne gespeichert. Ausgeltert werden
beispielsweise zu hohe Frequenzen sowie Töne, die weniger als eine Millisekunde dauern
oder aufgrund einer hohen Umgebungslautstärke zu leise sind.
2.1.2 Codecs, Datei- und Containerformate
Ein Codec (Kunstwort aus coder/decoder) deniert, wie analoge Audio- oder Videosignale in digitale Daten umgewandelt werden und umgekehrt. Codecs unterscheiden sich
bzgl. mehrerer Faktoren, u.a. der Kompressionsart (verlustfrei oder verlustbehaftet) und
der erzeugten Bitrate/Datenrate. Verlustbehaftete Kompressionen wenden in der Regel
die im vorherigen Abschnitt geschilderten Verfahren an.
Die Kodierung erzeugt für Audio- und Videodaten zwei einzelne Streams, das Audiound das Videoformat. Ein Muxer (oder Multiplexer) multiplext und synchronisiert beide
Streams und legt sie in ein Containerformat ab, zusammen mit den für die synchrone Ausgabe erforderlichen Metainformationen, gegebenenfalls Untertiteln und weiteren
Tonspuren. Das Containerformat speziziert, welche Daten miteinander in dem Format
abgelegt werden können. Das Containerformat kann auch als Datei abgespeichert werden,
deren Dateiendung sich nach der Bezeichnung des Containerformats richtet. Hier folgen
einige Beispiele für bekannte Containerformate:
AVI/Audio-Video Interleave (Dateiendung .avi): 1992 von Microsoft vorgestellt,
wurde das Format von Microsoft nicht weiter gepegt, aber von anderen erweitert.
AVI stellt ein vergleichsweise einfaches Format dar. Es unterstützt inhärent weder
Untertitel noch B-Frames. In AVI können verschiedenste Audio- und Videoformate
miteinander kombiniert werden. Häug ndet sich MP3 zusammen mit älteren Videoformaten. Das neuere Videoformat H.264 kann mangels B-Frame-Unterstützung
nicht problemlos verwendet werden.
PS/Programmstream (.ps) ist ein Format, das für nicht störungsanfällige Übertragungen eingesetzt wird, z.B. DVD.
TS/Transportstream (.ts) stellt ein Containerformat dar, das für den Einsatz bei
störungsanfälligen Übertragungen geeignet ist, z.B. Übertragungen per Satellit, Antenne, Kabel/CATV.
VOB/Video Object + IFO (.vob, .ifo), ein Containerformat für DVDs, enthält
meist mit MPEG-1 Part 2/MPEG-2 Part 2 kodierte Videodaten und mit dem
AC3-Audiocodec erstellte Audiodaten.
17
2.1. AUDIO-/VIDEOKOMPRIMIERUNG
KAPITEL 2.
STREAMING
2.1.3 Der MPEG-Standard
Die Moving Pictures Experts Group hat ab 1991 unter dem Namen MPEG diverse Standards zur Kompression von Audio- und Videodaten veröentlicht.
2.1.3.1 MPEG-Videocodecs
Die Videostandards wurden jeweils zu Paketen zusammengefasst und sind unter dem Namen MPEG-1, MPEG-2 und MPEG-4 bekannt. Einen MPEG-3-Video-Standard gibt es
nicht. Dieser wurde zwar geplant, aber die Entwicklungen zu MPEG-3 waren noch vor der
Fertigstellung von MPEG-2 abgeschlossen. Daher wurden die MPEG-3-Erweiterungen in
MPEG-2 integriert und MPEG-3 übersprungen.
Der erste Standard MPEG-1 sollte ermöglichen, Video-CDs zu erstellen. 1996 folgte
MPEG-2, der u.a. das Multiplexen verschiedener Video- und Audiostreams ermöglicht.
MPEG-2 wird für Standard-DVDs verwendet und ndet sich in vielen Geräten, z.B. in
Set-Top-Boxen, digitalen Satellitenreceivern und DVD-Playern.
MPEG-4 (ab 2000) umfasst insbesondere zwei Standards für Videoformate: MPEG-4
Part 2 und MPEG-4 Part 10 (auch bekannt als H.264 oder MPEG-4 AVC). Mit H.264
können Videos im Unterschied zu MPEG-2 bei gleich bleibender Qualität bis zu 50% ezienter komprimiert werden. Dadurch wird die Übertragung von High-Denition-Videos
(kurz HD-Videos) über IP-Netze möglich. H.264 wird für Blu-ray-Disks und HD-DVDs
eingesetzt.
Codecs werden nach diesen Standards erstellt. Für jeden Standard gibt es mehrere Prole und Level. Die Prole spezizieren Merkmale, z.B. ob Bilder zu B-Frames kodiert
werden können. Die Level geben maximale Auösungen (bei MPEG-2) bzw. Bitraten an
(bei MPEG-4). Für MPEG-2/MPEG-4-Codecs ergeben sich damit verschiedenste Kombinationen aus Prol und Level, wobei nicht alle Kombinationen von Herstellerseite unterstützt werden. Mit höherem Prol steigt die Komplexität und damit die Rechenlast
beim Kodieren. Das einfachste Prol von H.264 (Baseline-Prol) unterstützt beispielsweise keine B-Frames, wodurch die Komplexität und die Verzögerung bei der Kodierung
verringert werden. Aufgrund der geringeren Verzögerung ist das Baseline-Prol für Videokonferenzen und mobile TV-Applikationen geeignet.
2.1.3.2 MPEG-Audiocodecs
Gebräuchliche MPEG-Audiocodecs sind MPEG Layer 1, MPEG Layer 2, MPEG Layer
3 (bekannt als MP3) sowie MPEG Advanced Audio Coding (AAC). Nahezu alle Containerformate unterstützen MP3, das meist mit älteren Videoformaten (d.h. älter als H.264)
gemuxt wird. AAC wird nur in Verbindung mit MPEG-2/4-Video verwendet (vorzugsweise mit H.264) und unterstützt Abtastraten von bis zu 96kHz.
2.1.4 Zusammenfassung
Ein Containerformat enthält nach spezizierten Codecs erzeugte Audio- und Videoformate. Der Transport und die Steuerung des gemuxten Streams ist je nach Containerformat
18
2.2. STREAMING-ANWENDUNGEN
KAPITEL 2. STREAMING
und Anwendung mit verschiedenen Protokollen möglich. RTP (Real-Time Transport Protocol [SC+96]) und RTSP (Real Time Streaming Protocol [SRL98]) beispielsweise sind
oene Protokolle für den Transport und die Steuerung. RTP transportiert meist PS-/TSPakete (Programm-/Transportstream). RTSP startet z.B. eine Streamingsession.
Adobe, Apple Computer, RealNetworks und Microsoft bieten jeweils ein komplettes Framework zum Streamen von Multimediadaten an, das sich aus Codecs, eigenen Containerformaten, kostenfreien Playern auf Clientseite, kostenpichtigen Streamingservern
3
und Protokollen für Datentransport und -steuerung zusammensetzt. In Tabelle 2.1 sind
einige Standardkombinationen (aus Containerformaten, Videocodecs, Audiocodecs und
Protokollen) und deren Anwendungen aufgelistet. Weitere Kombinationen sind möglich.
Beim Streamingprozess müssen der Server und die Clientplayer die gleichen Kodierungen
einsetzen. Klassische Push-Streaming-Server unterstützen meist mehrere Playerformate
und bieten zudem Kompressionen für jede Kombination aus Playerformat und Verbindungsgeschwindigkeit (Dial-Up, Medium, High) an. [cha07, cha09, Sim08]
2.2 Streaming-Anwendungen
Das Streaming von Audio- und Videodaten ermöglicht eine Reihe von Anwendungen, z.B.
4
IP-Telefonie, Videokonferenzen , Internet-Radio oder Internet-TV. In Bezug auf InternetTV muss zwischen Web-TV (auch Internet-Video genannt) und IPTV unterschieden werden. Web-TV kann über P2P-Streaming-Netze realisiert werden, IPTV dagegen nicht.
Anhand folgender Denitionen können die Begrie Web-TV und IPTV voneinander abgegrenzt werden:
Web-TV (Internet-Video)
Verschiedenste Beiträge werden über Overlaynetze im öf-
fentlichen Internet gestreamt. Dabei kommen unterschiedliche Formate und Protokolle
zur Verwendung (siehe dazu Tabelle 2.1). Der Empfang erfolgt auf dem Rechner mittels
spezieller Software, auf Consumer-Fernsehern mittels Netzwerkadapter oder auf portablen Videoplayern.
IPTV
Analog zum Kabelfernsehen stellen IPTV-Anbieter (z.B. Telekom, Alice) profes-
sionell erstellte TV-Inhalte in hoher Qualität zur Verfügung. Die Inhalte werden über
eigene Netzwerke übertragen, die unabhängig vom Internet sind. Die IPTV-Konsumenten schlieÿen ein kostenpichtiges Abonnement ab und empfangen die Inhalte auf ihrem
Consumer-Fernseher mittels einer Set-Top-Box. Mitunter wird in der Fachliteratur WebTV fälschlicherweise als IPTV bezeichnet (siehe [HLR08, SF+08]). [Sim08, tuc10]
2.3 Streaming-Methoden
Während man gemeinhin beim Streaming davon ausgeht, dass die Daten, die kontinuierlich übertragen und verwertet werden, nicht lokal gespeichert werden müssen, hat sich
3
4
zum Push von Daten
mit Videocodecs H.262/MPEG-2 und H.263
19
MPEG-4 Part 3 (AAC)
H.264
20
WindowsMedia Audio
Ogg Vorbis
RealAudio
HTTP (Download and Play),
Wiedergabe mittels
<audio>/<video> in HTML5
ohne Browserplugin (derzeit
unterstützt durch Opera, Mozilla
Firefox und Google Chrome)
MMS (proprietär)/RTSP
HTTP (Download and Play),
Wiedergabe mittels
<audio>/<video> in HTML5
ohne Browserplugin (derzeit
unterstützt durch Opera, Mozilla
Firefox und Google Chrome)
RTP/RTSP
HTTP (Download and Play)
HTTP (Download and Play)
RTP/RTSP
RTP/RTSP
Tabelle 2.1: Gängige Kombinationen aus Container, Codecs und Protokollen [Sim08, tuc10]
Windows Media Video
WMV9/VC1
On2 VP8 (seit dem Aufkauf
von On2 im Februar 2010
im Besitz von Google)
WebM (.webm)
basiert auf
Matroska-Container
(MKV)
Advanced Systems
Format/ASF (.asf)
RealVideo
RMVB (.rm, .rmvb)
Ogg Vorbis
MPEG-4 Part 3 (AAC)
RTMP (proprietär)
Datentransport-/steuerung
KAPITEL 2.
Windows Media Player
(Standard-Container für
Windows Media)
RealPlayer
(Standard-Container für
RealMedia)
WebM-Container von
Google (freier Container für
HTML5)
Ogg-Standard-Container
(Container für freie
Xiph.org-Codecs)
Ogg Theora (basiert auf
On2 VP3.2)
MP3
MPEG-Audio Layer II
MPEG-4 Part 2
MPEG-2
DivX (.divx)
MPEG-2
Transportstrom (.ts)
MPEG-4 Part
12/MP4 (.mp4)
Ogg (.ogg)
Apple QuickTime
(Standard-Container für
QuickTime)
DivX/XviD-Streaming
DVB (Digitales Fernsehen),
z.B. DVB-T
MP4-Standard-Container
MPEG-4 Part 3 (AAC)
H.264 (früher: Sorenson
Spark, On2 VP6)
H.264
Flash Video/FLV
(.v)
QuickTime
(.mov,.qt)
Audiocodec/-format
Adobe Flashplayer
Videocodec/-format
Containerformat
(Dateiendung)
Beschreibung
2.3. STREAMING-METHODEN
STREAMING
2.4. VERBINDUNGSARTEN
KAPITEL 2. STREAMING
eine weitere Methode entwickelt, die ebenfalls als Streaming bezeichnet wird und bei
der die gestreamten Daten lokal abgespeichert werden. Die letztere Methode wird in
der Fachliteratur Pseudo-Streaming genannt im Gegensatz zu True-Streaming (echtem
Streaming):
Pseudo-Streaming
Man spricht hier auch vom Open-after-downloading-Modus. Die
Wiedergabe erfolgt erst nach dem Download der Daten. Die Daten werden mit HTTP
oder FTP übertragen. Da in erster Linie HTTP eingesetzt wird, ist auch die Bezeichnung
HTTP-Streaming gebräuchlich.
Man unterscheidet hier:
Download & Play: Der Stream wird in einer Datei gespeichert. Erst nach vollständigem Download dieser Datei können die Daten auf dem Clientrechner wiedergegeben
werden. Die Wiedergabe ist damit unabhängig von der Bandbreite, aber die Verzögerung bis zum Beginn der Wiedergabe höher als bei True-Streaming.
Progressive Download & Play (siehe YouTube): Der Stream wird in Stücke zerlegt,
die einzeln heruntergeladen und wiedergegeben werden. Dadurch ist eine sukzessive
Wiedergabe auch dann möglich, wenn die verfügbare Bandbreite geringer als die
Streamingrate sein sollte.
True-Streaming/Echtes Streaming
Die Wiedergabe (das Playback) der Daten ist so
gut wie gleichzeitig mit dem Datenempfang möglich. Man spricht daher auch vom Playwhile-downloading-Modus [WLQ06, XH+02]. Gestreamt werden kann nur, falls die Downloadbandbreite mindestens so hoch ist wie die Streamingrate (im Internet meist ca. 400
kbps).
Man unterscheidet hier:
Live-Streaming: Es erfolgt die Übertragung von Live-Inhalten (z.B. von Sportereignissen wie Bundesliga-Spielen).
Video-On-Demand/VoD: Die Inhalte (z.B. Spiellme) werden bei Bedarf angefordert und gestreamt.
Der Schwerpunkt dieser Arbeit liegt auf Protokollen für echtes Streaming (also TrueStreaming), 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 Internetanwendungen
wie 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, Übertragung
der 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 Multimediadaten verwendet werden. Broadcast über das Internet ist allerdings nicht praktikabel. Broadcast über das LAN ist zwar möglich, aber aufgrund des hohen Datenaufkommens beim Streamen und der Kollisionsgefahr im LAN nicht ratsam.
Für Live-Streaming bieten sich Multicast-Verbindungen mit der Möglichkeit des Versands
an eine Empfängergruppe an. Bei der Implementierung von Multicast als IP-Multicast
(siehe Abschnitt 2.5.2.1) verschickt die Quelle - im Unterschied zu Unicast - an mehrere
Empfänger nur einen einzigen Stream, der erst an den Verzweigungen vervielfältigt wird
(siehe Abbildung 2.2). Die Aufgabe der Vervielfältigung übernehmen hier die Router, mit
denen die Endhosts (Hosts 1,2 in Abbildung 2.2) verbunden sind. Die mit den Endhosts
verbundenen Router müssen dazu Multicast-fähig sein (siehe auch Abschnitt 2.5.2.1).
[Sim08]
1
1
S
S
Router
IP-Multicast
2
Unicast
Router
2
Abbildung 2.2: Unicast und IP-Multicast (nach [Sim08])
2.5 Streaming-Architekturen
Echtes Streaming (True-Streaming) im Internet ist über verschiedene Architekturen möglich, d.h. über Client/Server, Content-Delivery-Netzwerke (CDNs), IP-Multicast oder
Application-Level-Multicast (ALM). Abbildung 2.3 zeigt diese Streaming-Architekturen
in Abhängigkeit voneinander.
5
Hybrid-Fiber-Coax-Kabelnetzwerk
22
2.5. STREAMING-ARCHITEKTUREN
KAPITEL 2. STREAMING
Streaming-System
zentralisiert (Client-Server)
dezentralisiert
Router-basiert (IP-Multicast)
nicht Router-basiert
Infrastruktur-basiert (CDN)
Application-Level-Multicast
Endsysteme mit
Infrastruktur-Support (AnySee)
Endsysteme ohne
Infrastruktur-Support
Abbildung 2.3: Streaming-Architekturen (nach [LR+08, Vil09])
Die in dieser Arbeit behandelten Protokolle (wie CoolStreaming) setzen ApplicationLevel-Multicast (ALM) ein. Die Endsysteme verteilen dabei selbst den Stream. Zusätzlicher 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 Clients
mit dem Quellserver und der Content wird direkt vom Server zum Client gestreamt. Im
Unterschied zu P2P-basierten Systemen leiten die Knoten die empfangenen Daten nicht
an andere Knoten weiter.
Solch zentralisierte Systeme sind einfach und leicht zu implementieren [E08, LR+08].
Prozessorleistung, Speicherkapazität, I/O-Durchsatz sowie die begrenzte Netzwerkbandbreite werden aber zum Flaschenhals des Systems [WLQ06]. Da die Bandbreite der Clients ungenutzt bleibt, ist hier mit hohen Kosten für die Bandbreitenlieferung zu rechnen
[LGL08] sowie für Start und Betrieb des Streaming-Servers [WLQ06]. Client/ServerSysteme sind nur beschränkt skalierbar und stellen durch den zentralen Server einen
Single-Point-Of-Failure dar, weshalb sie leichter angegrien werden können und zudem
weniger zuverlässig sind im Hinblick auf die Ausfallsicherheit.
2.5.1.2 CDN
CDN-/Content-Delivery-Network-basiertes Streaming ist eine Variation des Client/Server-Modus. Dienstanbieter wie Akamai oder Limelight positionieren Proxys an strategisch
wichtigen Standorten im Internet (network edges). Die zu streamenden Daten liegen
23
2.5. STREAMING-ARCHITEKTUREN
KAPITEL 2. STREAMING
auf Content-Delivery-Servern. Die User werden zum nächstgelegenen Content-DeliveryServer weitergeleitet und holen sich von dort die Daten per Unicast.
Im Unterschied zu reinen Client/Server-Lösungen sind die Anfangsverzögerungen kürzer, der Netzwerkverkehr geringer und es können mehr Endnutzer bedient werden. Ein
Broadcaster kann bei Bedarf Content-Delivery-Server anmieten.
Für einen ächendeckenden Einsatz müssen allerdings in der Nähe jedes möglichen Empfängers Content-Delivery-Server eingesetzt werden, was sehr hohe Infrastrukturkosten
verursacht. Die Dienstanbieter stoÿen auÿerdem bei stark nachgefragten Broadcasts an
die Grenzen der möglichen Bandbreitenlieferung. 2009 zu Obamas Amtseinführung verlieÿ sich CNN daher nicht nur auf Dienstanbieter Akamai, sondern verteilte den LiveStream auch per P2P. Von 1,3 Millionen gleichzeitigen Usern wurden jeweils 650.000 User
per CDN bzw. per P2P bedient [new09]. Akamai allein hätte die akkumulierte Bandbreite von ca. 495 Gbps (bei einer veranschlagten Streamingrate von 400 kbps) nicht zur
Verfügung stellen können. Dazu kommen hohe Kosten, die Anbieter von CDNs für die
Anmietung der Server verlangen. [LGL08, LR+08, WLQ06]
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-Referenzmodell) zu implementieren [DC90]. Daraus entwickelte sich IP-Multicast (NativeIP-Multicast/Native-Multicast). Der Dienst von IP-Multicast besteht darin, Daten an
die Teilnehmer einer Gruppe zu senden. Die Teilnehmer können sich mittels IGMPNachrichten (Internet Group Management Protocol [Fen97]) zu einer Gruppe an- und
abmelden. Das setzt voraus, dass der erste Router, mit dem sich der Teilnehmer verbindet, IP-Multicast-fähig ist und die Gruppenverwaltung vornehmen kann.
Die Verteilung der Nachrichten erfolgt über eine baumförmige Struktur, den MulticastBaum, der von den IP-Routern im Netzwerk gebildet wird [LC+05]. Die Nachrichten
werden zwischen den Router-Knoten wie bei Unicast weitergereicht. An den Blättern des
Routerbaumes kopieren die Router die Nachrichten und verteilen sie an alle angemeldeten Endknoten. Für die Errichtung des Multicast-Baumes gibt es verschiedene RoutingProtokolle, z.B. DVMRP (Distance-Vector-Multicast-Routing-Protocol [WPD88]) oder
PIM-SM (Protocol Independent Multicast - Sparse Mode [EF+98]).
Trotz vieler Entwicklungen seit den 90er-Jahren ist IP-Multicast im Internet nicht weit
verbreitet. Der Prozentsatz der IP-Multicast-fähigen autonomen Systeme im Internet
stagniert seit Jahren unter 5% [MS07].
Die Gründe dafür sind technischer und wirtschaftlicher Natur. IP-Multicast-fähige Router müssen alle Zustände der Multicast-Gruppe speichern, was zu hoher Komplexität
und damit zu eingeschränkter Skalierung führt. Für IP-Multicast wird das Transportprotokoll UDP verwendet. Bei IP-Multicast handelt es sich also um einen Best-EortService. Dienste wie Fehlerkontrolle, Flusskontrolle oder Congestion-Control (Stauvermeidungsmechanismen) sind bei IP-Multicast im Gegensatz zu Unicast sehr schwierig
24
2.5. STREAMING-ARCHITEKTUREN
KAPITEL 2. STREAMING
umzusetzen. Um IP-Multicast im Internet ächendeckend einzusetzen, müssten auÿerdem IP-Multicast-fähige Router bei allen Verbindungen zu den Endknoten installiert
werden. Die Nachfrage nach IP-Multicast durch Endkunden ist zudem gering. Daher
ist es für die Internet-Service-Provider wirtschaftlich nicht interessant, IP-Multicast zur
Verfügung zu stellen und die hohen Kosten für Wartung und Konguration in Kauf zu
nehmen. [CRZ00, LR+08, MS07]
2.5.2.2 Application-Level-Multicast
Im Fokus dieser Arbeit stehen Systeme, die das Streamen über das Internet, also über
Punkt-zu-Punkt-Verbindungen, ermöglichen und zu diesem Zweck Application-LevelMulticast (ALM) einsetzen.
Wegen der Nachteile von IP-Multicast wurde ALM entwickelt. Multicast wird hier auf
der Anwendungsschicht (Schicht 7 im ISO/OSI-Referenzmodell) nachgebildet. Der QuellServer und die Endsysteme bilden ein sogenanntes Application-Level-Overlaynetzwerk
[LGL08] über dem physischen Internet. Dadurch können Multicast-Bäume direkt zwischen den Endsystemen aufgebaut werden.. Im Gegensatz zu IP-Multicast sind bei ALM
die Endsysteme für Multicast-Funktionalitäten zuständig. Sie kopieren Nachrichten, leiten Nachrichten weiter und übernehmen Aufgaben der Gruppenverwaltung.
Abbildung 2.4 stellt den Versand von Nachrichten bei IP-Multicast und ALM dar. Der
Sender S und die Empfänger (Hosts 1,2,3) sind jeweils über ein physisches Netzwerk miteinander verbunden (siehe blaue Linie). Bei ALM existiert neben der physischen Verbindung ein Overlaynetzwerk (blau-gestrichelte Linie), das sich aufgrund von Partnerschaftsbeziehungen zwischen den Hosts zusammensetzt. Bei ALM leitet Host 2 die Nachricht
des Senders an Host 3 weiter. Auf einer unteren Protokollebene muss diese Nachricht
natürlich auch über die physische Verbindung (über Router 2) verschickt werden.
S
Router 1
1
S
2
Router 1
Router 2
IP-Multicast
2
3
1
Router 2
ALM
3
Abbildung 2.4: IP-Multicast und ALM (nach [BBK02])
Frühe Streaming-Systeme (ab 2000) auf Basis von ALM sind sogenannte Tree-basierte
Systeme. Tree-basierte Systeme erstellen explizit einen Multicast-Baum (ALM-Baum),
über den der Stream von der Quelle bis zu den Endsystemen verteilt wird [LGL08,
Liu07]. Entweder baut das System zuerst den ALM-Baum auf (Tree-rst-Ansatz) oder
errichtet zuerst ein separates Overlaynetzwerk, über dem der eigentliche ALM-Baum
liegt (Mesh-rst-Ansatz). Bei diesem Overlaynetzwerk kann es sich um ein strukturiertes
P2P-Substrat (z.B. CAN [RF+00], Pastry [RD01] oder Tapestry [ZKJ01]) handeln oder
um ein unstrukturiertes P2P-Netzwerk mit einer zufälligen Verbindungsstruktur. Da sich
25
2.6. ZUSAMMENFASSUNG
KAPITEL 2. STREAMING
die Peers in dem P2P-Netzwerk untereinander verbinden und dabei - im Unterschied zum
Baum - Maschen bilden, bezeichnet man so ein Netz als Mesh (engl. für Masche).
Ab 2004 wurden sogenannte Mesh-basierte ALM-Systeme entwickelt. Analog zum Meshrst-Ansatz sind die Peers in einem separaten Overlaynetzwerk über dem physischen
Internet miteinander verbunden. Die Verteilung des Streams erfolgt hier nicht über einen
fest aufgebauten ALM-Baum, sondern über dynamische Routen, die je nach Datenverfügbarkeit wechseln können. Dadurch werden implizit Multicast-Bäume erstellt, die sich
ständig verändern können. Eine weitere Besprechung von Tree- und Mesh-basierten Systemen folgt in Abschnitt 4.2.2.
Im Gegensatz zu IP-Multicast ist der Einsatz von ALM an keine Infrastrukturanpassungen gebunden und diesbezüglich kostengünstiger. Protokollmodikationen können einfach
in der Anwendungsschicht vorgenommen werden. Allerdings zeichnet sich IP-Multicast
durch höhere Ezienz aus. Bei ALM übernehmen die Endhosts die Funktion der Router,
wissen aber nichts oder nur wenig über die physische Netzwerktopologie und verschicken
Nachrichten daher weniger ezient, d.h. mit gröÿeren Ende-zu-Ende-Verzögerungen. Da
bei ALM die Endhosts auch Aufgaben der Gruppenverwaltung übernehmen, führt dies
zu höherem Overhead und höherer Komplexität auf den Endhosts. [HA+06]
Abschlieÿend sollen die Begrie
ALM
und
P2P-Streaming
voneinander abgegrenzt 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 Implementierung von Multicast auf der Anwendungsschicht. P2P-Streaming-Systeme, die Liveoder Video-On-Demand-Inhalte vielen Empfängern zur Verfügung stellen, basieren in
der Regel auf ALM. Für die Verteilung des Streams müssen ein oder mehrere MulticastBäume errichtet werden, sei es explizit (wie bei Tree-basierten Systemen) oder implizit
(wie bei Mesh-basierten Systemen). Es gibt aber auch P2P-Streaming-Systeme, die kein
Multicast einsetzen, siehe IP-Telefonie zwischen zwei Hosts mit Skype. Hier werden zwar
Audiodaten über ein P2P-Netzwerk gestreamt und weitergeleitet, konzeptionell handelt
es sich aber um eine Unicast-Verbindung zwischen zwei Teilnehmern.
ALM gebraucht:
End-System-Multicast (kurz: ESM), End-System-Overlay-Multicast, Overlay-Multicast,
P2P-Multicast, P2P-Broadcast, P2P-Internet-Broadcast, P2P-Internet-Video-Broadcast.
In der P2P-Literatur werden folgende Begrie synonym zu
[LR+08, Zha07]
Broadcast ist hier semantisch nicht korrekt, da es sich bei ALM um Multicast-Verbindungen handelt (siehe Abschnitt 2.4). Dennoch ist die Bezeichnung Broadcast in diesem Zusammenhang gebräuchlich. Wenn ein Einsatzzweck von ALM im Vordergrund steht, wird
statt von
ALM
mitunter auch von
P2P-Internet-Video-Streaming
gesprochen [Zha07].
2.6 Zusammenfassung
In diesem Kapitel wurde das Streamen von Audio- und Videodaten aus verschiedenen
Perspektiven heraus erläutert. Dabei wurden zunächst die gestreamten Daten und ihre Kodierungen betrachtet. Dann wurden der Unterschied zwischen echtem Streaming
26
2.6. ZUSAMMENFASSUNG
KAPITEL 2. STREAMING
(True-Streaming) und Pseudo-Streaming herausgestellt und mögliche Anwendungen, Verbindungsarten und Architekturen behandelt.
Der Schwerpunkt dieser Arbeit liegt auf Live-Streaming (also echtem Streaming) über
P2P für Web-TV-Anwendungen. Sobald Daten empfangen werden, erfolgt beim LiveStreaming deren Wiedergabe. Der Sender und die Empfänger verbinden sich per Multicast. Dabei wird Multicast auf der Anwendungsebene (als ALM) implementiert. Es können verschieden kodierte Audio- und Videodaten gestreamt werden. Deren Kodierung
und Format hängen vom Medienplayer des Clients ab, zu dem das P2P-Live-StreamingSystem eine Anbindung liefert (siehe auch Tabelle 2.1). Die bei kommerziellen Systemen
am häugsten unterstützten Formate sind Windows Media von Microsoft sowie - bei
älteren Systemen - RealMedia von RealNetworks. [cha07, cha09, Sim08]
27
3 P2P-Streaming
Im vorherigen Kapitel habe ich die Grundlagen des Streamings erläutert. Für das Kernthema dieser Arbeit (P2P-Streaming) sind jetzt folgende Fragen zu klären: Was ist P2P?
Wo liegt der Zusammenhang zwischen P2P und P2P-Streaming? Neben dem oensichtlichen Zusammenhang, dass sich die Peers in beiden Systemen Ressourcen teilen, hat
der Bereich P2P-Streaming einige Algorithmen und Protokolle aus P2P adaptiert. Ein
chronologischer Überblick wird in Abschnitt 3.2 gegeben.
Streaming in P2P-Netzen erfolgt nach den Methoden Live und Video-On-Demand. Deren
grundlegende Konzepte werden am Ende dieses Kapitels vorgestellt.
3.1 P2P
3.1.1 Begrisklärung
P2P ist die Kurzform von Peer-to-Peer und abgeleitet vom englischen Wort peer, das
einen Gleichrangigen oder Ebenbürtigen bezeichnet.
In der P2P-Forschung gibt es keine klare, einheitlich verwendete Denition von einem
P2P-System bzw. einem P2P-Netzwerk. Nach Mahlmann et al. hat man sich in etwa
darauf geeinigt, dass ein P2P-Netzwerk ein Overlay-Netzwerk des Internets ist, bei dem
die Rechner ebenbürtig ohne zentrale Koordination kommunizieren und gemeinsam eine
Anwendung zur Verfügung stellen [MS07]. In diesem Satz werden alle wichtigen Eigen-
Dezentralisierung, Kooperation, Ressourcenverteilung
sowie autonome und gleichberechtigte Peers. Die Peers agieren als Servents (Kunstwort
schaften von P2P angeschnitten:
aus Server und Clients). Sie fordern nicht nur Daten an, sondern liefern im Unterschied
zum klassischen Client/Server-System die Daten auch selbst aus.
Aufgrund der genannten Eigenschaften bieten P2P-Systeme gegenüber Client/ServerSystemen mehrere Vorteile. Da sich die Peers die Ressourcen teilen, kommt es nicht
zu dem Problem des Server-Flaschenhalses und das System skaliert besser. Durch das
Fehlen einer Serverstruktur minimieren sich die Anforderungen an die Infrastruktur und
damit die Kosten. Dezentralisiert arbeitende Peers bieten zudem keinen Single-PointOf-Failure, wodurch der mögliche Schaden bei Distributed-Denial-Of-Service-Attacken
(DDoS-Attacken) gemindert und die Robustheit des Systems erhöht wird. Allerdings
arbeiten nicht alle P2P-Systeme gleichermaÿen dezentralisiert und weisen somit nicht
alle Vorteile gleich stark auf (siehe Napster [nap] und Gnutella 0.6 [gnu] in Tabelle 3.1).
In einem dezentralisierten P2P-System laufen die Anwendungen verteilt, weshalb verteilte Algorithmen benötigt werden (z.B. CAN [RF+00], Chord [SM+01], Pastry [RD01],
Algorithmen im Gnutella-Protokoll [Cli01] oder bei Freenet [CS+01]).
28
3.1. P2P
KAPITEL 3. P2P-STREAMING
3.1.2 Klassizierung von P2P-Systemen
P2P-Systeme kann man klassizieren, indem man prüft, wie stark die Inhalte und Inhaltsbeschreibungen (z.B. Dateinamen, Meta-Informationen) strukturiert sind und wie
sehr die Peers voneinander abhängen.
In strukturierten oder stra strukturierten P2P-Systemen stehen die Inhalte in Relation
zu den Knoten, die für diese Inhalte zuständig sind. Eine wohldenierte Hash-Funktion
bildet z.B. den Dateinamen auf die P2P-Netzwerkadresse des für die Datei zuständigen
Knotens ab. Daher spricht man hier von Systemen, die auf DHTs (Distributed-HashTables) basieren. Diese Systeme werden in der P2P-Literatur auch als Content-orientiert
bzw. Content-adressierbar bezeichnet oder als Systeme mit Content-basiertem Routing
bzw. mit Content-adressierbarer Datenhaltung. Da die Topologie ständig aufrechterhalten werden muss, entstehen hohe Wartungskosten bei hohem Peer-Churn, d.h. wenn oft
neue Peers ins Netz kommen und verbundene Peers das Netz wieder verlassen.
Unstrukturierte oder locker strukturierte P2P-Systeme sehen keine Relation zwischen
Inhalten und Knoten vor. Die Suche nach den Dateien erfolgt zentralisiert oder über
Flooding, d.h. durch Broadcast an alle Peers im P2P-Netzwerk bis zum Ablauf einer
Time-To-Live (TTL). Die Protokolle erzeugen einen zufälligen Verbindungsgraph, dessen Struktur gewissen Gesetzmäÿigkeiten folgt (z.B. Pareto-Verteilung des Small-WorldNetzwerks bei Gnutella).
In achen, reinen oder rein dezentralisierten P2P-Systemen, wie z.B. Chord und Freenet,
haben alle Peers die gleiche Funktionalität und die gleiche Verantwortung. Peer-Churn
beeinträchtigt das Gesamtsystem hier kaum.
Hierarchische oder hybride P2P-Systeme zeichnen sich dadurch aus, dass bestimmten
Knoten mehr Verantwortung zufällt als anderen. Diese Knoten übernehmen entweder
alle Aufgaben (wie die statischen Server bei Napster), wobei man hier von zentralisiert indexierenden Systemen spricht. Oder dynamische Einheiten (Super-Nodes/SuperPeers/Ultra-Peers) übernehmen einen gröÿeren Teil der Aufgaben. Diese Systeme werden
als verteilt indexierend bezeichnet. [E08, MS07, PBV05, SW05]
Die Tabelle 3.1 stellt die möglichen Klassizierungen von P2P-Systemen und deren Vorund Nachteile dar. Die P2P-Systeme werden dabei nach den oben genannten Aspekten
der Strukturierung (strukturiert oder unstrukturiert) und Hierarchie (rein dezentralisiert oder hybrid) in vier Gruppen eingeteilt und anhand ihrer Eigenschaften verglichen.
1
Insbesondere werden die Skalierbarkeit , Robustheit
2 und Flexibilität der Systeme be-
trachtet. Flexibilität bedeutet hier, dass die Peers sich vollständig autonom verhalten
können, sich nach Belieben mit dem Netz verbinden sowie dieses wieder verlassen können. In strukturierten P2P-Netzwerken werden den Peers IDs und die Verantwortung für
Inhalte zugeteilt, wodurch nach dem Peer-Abgang eine Umorganisation notwendig und
die Flexibilität somit eingeschränkt ist.
1
Skalierbarkeit bezeichnet die Fähigkeit eines P2P-Netzwerks, sich an eine quantitativ wachsende Anzahl von Peers und/oder Daten anzupassen [Wol10] (siehe auch Abschnitt 4.4.1).
2
Robustheit beschreibt die Eigenschaft eines Netzwerks, auch unter hoher Last und bei Fehlern (z.B.
Ausfällen der Netzwerkstruktur) ein speziziertes Leistungsniveau zu erhalten [Wol10] (siehe auch
Abschnitt 4.4.1).
29
30
- Suche weniger ezient,
vor allem bei seltenen
Dateien
- False-Negatives bei Suche
möglich
Durch die gleichmäÿige
Verteilung der Aufgaben auf
alle Peers wird deren
Heterogenität (z.B. bzgl.
Bandbreite) nicht
berücksichtigt.
Gnutella 0.4
Eigenschaften der
Suche
Beispielsystem
Sonstiges
weniger exibel, da nach
Peer-Abgang
Umorganisation der Daten
erforderlich ist
- eziente Suche mit meist
logarithmischer
Suchkomplexität
- Fuzzy-Queries (ungenaue
Suche) nicht möglich
Durch die gleichmäÿige
Verteilung der Aufgaben auf
alle Peers wird deren
Heterogenität (z.B. bzgl.
Bandbreite) nicht
berücksichtigt.
CAN, Chord, Pastry
ja
ja
strukturiert und rein
dezentralisiert
Napster
- eziente Suche mit
konstanter Suchkomplexität,
da Anfragen direkt an
Server gerichtet werden
- Fuzzy-Queries möglich
nein, da Server
Single-Point-of-Failure
nein
nicht skalierbar wegen
Server-Flaschenhals
unstrukturiert und hybrid
(zentralisiert indexierend)
Gnutella 0.6, FastTrack
Suche ezienter als bei rein
unstrukturierten
P2P-Systemen
ja, falls SuperNodes/-Peers redundant
ja
ja
unstrukturiert und hybrid
(verteilt indexierend)
Tabelle 3.1: Klassizierung von P2P-Systemen und Vergleich ihrer Eigenschaften [PBV05, SW05]
ja
Flexibel
Robust
nicht gut skalierbar
aufgrund des NachrichtenOverheads
ja
Skalierbar
unstrukturiert und rein
dezentralisiert
3.1. P2P
KAPITEL 3. P2P-STREAMING
3.2. ZUSAMMENHANG
KAPITEL 3. P2P-STREAMING
3.2 Chronologischer Zusammenhang zwischen P2P und
P2P-Streaming
Beim Streaming werden Audio- und/oder Videodaten über ein IP-Netzwerk kontinuierlich übertragen und verwertet. Beim Streaming auf P2P-Basis agieren die Endsysteme
zudem als Peers, d.h. sie empfangen den Stream und leiten ihn weiter. Die Architektur,
über die P2P-Streaming realisiert werden kann, wird ALM genannt (siehe auch Abschnitt
2.5.2.2).
Die ersten P2P-Streaming-Protokolle wurden im Jahr 2000 veröentlicht. Diese Protokolle (z.B. Overcast [JG+00]) errichten einen statischen Multicast-Baum mit der Quelle
als Wurzel. Der Stream wird über den Baum von der Quelle zu den Blattknoten verteilt,
wobei nur die inneren Knoten Daten weiterleiten und demnach als Peers agieren.
Ebenfalls im Jahr 2000 werden P2P-Streaming-Protokolle entwickelt, die diese Struktur
erweitern, indem sie zusätzlich zum Multicast-Baum ein eigenes P2P-Netzwerk aufbauen. Das zusätzliche Overlay sorgt für gröÿere Stabilität des Systems. Beim Ausfall des
Vaterknotens wird ein Peer z.B. nicht gänzlich vom System getrennt, sondern ist immer noch mit den anderen Nachbarn im P2P-Overlay verbunden. Das vereinfacht die
Suche nach einem neuen Vaterknoten für den Peer und somit allgemein die Reparaturmaÿnahmen des Systems bei Peer-Churn. Je nach P2P-Streaming-Protokoll werden
über das P2P-Netzwerk unterschiedliche Arten von Daten übertragen. In der Regel dient
das P2P-Netzwerk jedoch zum Austausch von Kontrollnachrichten (z.B. Nachrichten zum
Gruppenstatus oder zur Datenverfügbarkeit) und der Multicast-Baum zur Verteilung der
eigentlichen Streamdaten (Video-/Audiodaten). Es lässt sich sehr gut beobachten, wie
sich ab dem Jahr 2000 die Entwicklungen im P2P-Bereich jeweils auf die Erforschung neuer P2P-Streaming-Systeme ausgewirkt haben. Wurde ein neues P2P-Netzwerk entworfen,
entstand meist kurze Zeit später ein neues P2P-Streaming-Protokoll, welches dieses P2PNetzwerk als Substrat (oder Unterbau) benutzte. Dies zeigt die folgende chronologische
Auistung einiger ausgewählter P2P-Streaming-Protokolle für Live-Streaming:
2000
P2P-Streaming-Protokolle implementieren neben einem Multicast-Baum (SingleTree) ein unstrukturiertes P2P-Netzwerk. Dieses sogenannte Mesh kann entweder
vor (Mesh-rst) oder nach (Tree-rst) dem Baumaufbau errichtet werden:
Single-Tree-Protokoll (Mesh-rst): Narada [CRZ00]
Single-Tree-Protokoll (Tree-rst): YOID [Fra00]
2001
Die ab dem Jahre 2000 entwickelten DHT-basierten P2P-Netzwerke (insbesondere
CAN [RF+00], Pastry [RD01], Tapestry [ZKJ01]) regen das Design von P2P-Streaming-Systemen an, die über einem DHT-Substrat einen Multicast-Baum (SingleTree) aufbauen:
Single-Tree-Protokoll CAN Multicast [RH+01] über CAN
Single-Tree-Protokoll Bayeux [ZZ+01] über Tapestry
2002
2003
Single-Tree-Protokoll Scribe [CD+02] über Pastry
Das Multi-Tree-Protokoll SplitStream [CD+03] baut mehrere Multicast-Bäume
über dem DHT-Substrat Pastry auf.
31
3.3. GRUNDLEGENDE KONZEPTE
2004
KAPITEL 3. P2P-STREAMING
Sogenannte Mesh-basierte P2P-Streaming-Systeme verzichten ganz auf den expliziten Aufbau von Multicast-Bäumen. Die Peers sind in einem zufällig erzeugten
P2P-Netz miteinander verbunden, über das die Daten dynamisch verteilt werden.
Mesh-basiert sind z.B. die folgenden Protokolle:
CoolStreaming [ZL+05]
Chainsaw [PK+05]
3.3 Grundlegende Konzepte
Werden Daten über P2P-Netze gestreamt, handelt es sich um sogenanntes echtes Streaming (True-Streaming), das im vorherigen Kapitel vorgestellt wurde (siehe Abschnitt
2.3). Dabei werden die Daten unmittelbar nach dem Empfang wiedergegeben. Man
unterscheidet hier zwei wesentliche Methoden, Live-Streaming und Video-On-DemandStreaming. Beim Live-Streaming werden analog zum klassischen TV-Broadcast die Inhalte zu einem festen Zeitpunkt gesendet. Alle Benutzer empfangen den gleichen Stream
mehr oder weniger zum gleichen Zeitpunkt. Beim Video-On-Demand-Streaming hingegen bestimmt der Benutzer selbst den Zeitpunkt der Wiedergabe. Die grundlegenden
Konzepte dieser beiden Methoden werden im Folgenden vorgestellt.
3.3.1 Video-On-Demand-Streaming
Ein Video-On-Demand-Benutzer sucht sich zuerst ein Video des Streaminganbieters aus
und fordert es an. Er empfängt den Videostream dann asynchron, also nicht gleichzeitig mit den anderen Empfängern des Videos. D.h. die Empfänger schauen sich jeweils
verschiedene Teile des Videos an. Der Benutzer kann den Video-On-Demand-Stream anhalten sowie vor- und zurückspulen, weswegen die Daten gecacht werden müssen.
Liu et al. [LGL08] unterscheiden drei Ansätze, über die P2P-Video-On-Demand realisiert
werden kann:
Tree-basiert
Beim Tree-basierten P2P-Video-On-Demand (wie bei P2Cast [GS+03]) werden die User
nach dem Zeitpunkt ihres Eintreens in Sitzungen eingeteilt. Der Quellserver und die
Benutzer einer Sitzung bilden zusammen einen ALM-Baum, über den der gesamte Stream
verteilt wird.
Cache-And-Relay
Cache-And-Relay beruht darauf, dass ein Peer den Stream herunterlädt und dabei den
jeweiligen Datenbereich (Moving-Window genannt) cacht. Er bedient aus seinem Cache
andere Empfänger, die Videodaten aus seinem Moving-Window anfordern. DirectStream
[GS+07] wendet z.B. diese Technik an.
32
3.3. GRUNDLEGENDE KONZEPTE
KAPITEL 3. P2P-STREAMING
Mesh-basiert
In einem Mesh-basierten P2P-Video-On-Demand-System (wie BiToS [VIF06]) wird das
Video zuerst in kleine Datenblöcke zerlegt und dann vom Server an mehrere User verteilt. Die Benutzer laden immer die Blöcke von ihren Nachbarn herunter, die sie nicht
haben. Diese Technik wurde zuerst für die Verteilung groÿer Dateien entwickelt (siehe
BitTorrent) und dann erfolgreich für Video-On-Demand-Streaming und vor allem für
Live-Streaming übernommen. [E08, LGL08]
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 anderen
Benutzern, die diesen Kanal gewählt haben, die gleichen Daten zum mehr oder weniger
gleichen Zeitpunkt. Die Verzögerung, mit der die Peers während der Sitzung die LiveDaten erhalten, sollte zwar möglichst gering sein, kann aber in der Praxis auch ein bis
fünf Minuten betragen [OJ08].
Seit dem Jahre 2000 wurde ein sehr groÿe Anzahl von P2P-Live-Streaming-Protokollen
entwickelt, die sich in vielen Details unterscheiden (siehe dazu auch Kapitel 4). Der
Live-Stream wird in diesen Protokollen entweder über einen oder mehrere explizit aufgebaute Bäume verteilt. Diese Protokolle nennt man daher Tree-basiert (je nach Anzahl
der Bäume Single-Tree oder Multi-Tree). Oder die Verteilung des Streams erfolgt über
dynamische Routen innerhalb des P2P-Netzwerkes (dem Mesh).
Mesh-basierte Systeme
sind in der Regel einfacher zu implementieren und aufgrund
der dynamischen Datenverteilungswege robust bei Peer-Churn. So gut wie alle kommerziellen P2P-Streaming-Systeme sind Mesh-basiert. Auch das im Mittelpunkt dieser Arbeit
stehende CoolStreaming-Protokoll ist Mesh-basiert und stellte zum Zeitpunkt seiner Veröentlichung das erste seiner Art dar.
In Mesh-basierten Systemen wie CoolStreaming zerlegt die Quelle den Stream in einzelne
Teile, die Segmente, Blöcke oder Chunks genannt werden. Diese Segmente werden einzeln
verschickt und können über unterschiedliche Pfade im Netzwerk transportiert werden.
Die empfangenen Segmente setzt der Peer in seinem Puer zusammen und übergibt
sie sortiert an den Player zur Wiedergabe. Der Inhalt des Puers kann in Form einer
sogenannten Buermap dargestellt werden (siehe Abbildung 3.1).
35 36 37
1
1
1
39
0
1
Puffer
0
0
0
0
Buffermap mit Offset=35
ID des 1.Puffersegments (Offset)=35
Abbildung 3.1: Puer und dazugehörige Buermap
33
3.3. GRUNDLEGENDE KONZEPTE
KAPITEL 3. P2P-STREAMING
In Abbildung 3.1 hat der Peer bereits die Segmente mit der ID 35,36,37,39,41 erhalten
und in seinem Puer sortiert gespeichert. In der Buermap werden diese vorhandenen
Segmente durch eine 1 repräsentiert, alle noch nicht erhaltenen Segmente durch eine
0. Die ID des ersten Segments im Puer (im obigen Beispiel 35) wird Oset genannt.
Anhand der Buermap eines Puers und des dazugehörigen Osets kann man leicht
ermitteln, welche Segmente in diesem Puer vorliegen.
In Mesh-basierten Systemen tauschen die Peers regelmäÿig Buermaps mit ihren Nachbarn im Netzwerk aus. Dadurch erfahren sie, welche Segmente der Nachbar hat und
können diese explizit bei ihm anfordern. Der Peer mit dem Puer aus Abbildung 3.1
benötigt z.B. die Segmente 38,40,42,43,44 und muss diese anfordern.
In den letzten beiden Abschnitten wurden die grundlegenden Konzepte von P2P-Streaming vorgestellt, vor allem auch im Hinblick auf das CoolStreaming-Protokoll. Die Analyse des CoolStreaming-Protokolls folgt im Kapitel 4.
34
4 Analyse
In den vorangegangenen Kapiteln wurden Streaming, P2P-Streaming und die Besonderheiten beim P2P-Live-Streaming erläutert. In diesem Kapitel wird das P2P-LiveStreaming-Protokoll CoolStreaming analysiert. Die Analyse von Protokollen kann theoretisch erfolgen durch den Vergleich von Protokollcharakteristiken, durch eine GraphAnalyse oder durch den Vergleich von veröentlichten Messergebnissen aus PerformanceMessungen. In dieser Arbeit werden alle drei der genannten Möglichkeiten der Analyse
angewandt.
Es werden zunächst die Gemeinsamkeiten von P2P-Live-Streaming-Protokollen anhand
eines allgemeinen Prozessmodells hervorgehoben. Aus diesem Prozessmodell lassen sich
die Unterscheidungsmerkmale von P2P-Live-Streaming-Protokollen ableiten, so dass darauf aufbauend die Analyse des CoolStreaming-Protokolls erfolgen kann. Die Protokollcharakteristiken von CoolStreaming werden denen anderer Protokolle gegenübergestellt
und daraufhin bewertet. Dabei weise ich auch auf die verschiedenen Terminologien hin,
um so zugleich einen systematischen Überblick über P2P-Live-Streaming-Protokolle darzulegen. Dann werden die Ergebnisse von Performance-Messungen des CoolStreamingProtokolls aus diversen P2P-Streaming-Arbeiten vorgestellt. Es folgt eine Analyse des
CoolStreaming-Verbindungsgraphen. Das Kapitel endet mit einer Zusammenfassung der
Ergebnisse.
4.1 Allgemeines Prozessmodell für P2P-Live-Streaming
Die Schwierigkeit beim P2P-Live-Streamingprozess besteht darin, dass sich neue Knoten
mit den Peers im P2P-Streaming-Netz so verbinden, dass sie die gewünschten Inhalte
mit geringstmöglicher Verzögerung beziehen können.
In [GZ+09] wurde dazu ein allgemeines Prozessmodell für P2P-Live-Streaming-Systeme
vorgestellt. In jedem Schritt des Prozessmodells werden jeweils die Streamverteilung
in Tree-basierten und in Mesh-basierten Systemen berücksichtigt. Aus den einzelnen
Schritten lassen sich anschlieÿend die Unterscheidungsmerkmale für P2P-Live-StreamingProtokolle ableiten.
1. Ein neuer Peer kontaktiert einen Einstiegspunkt (Rendezvous-Point, BootstrapNode, Tracker) über HTTP/HTTPS. Er erhält von diesem Einstiegspunkt eine
Liste mit potentiellen Vaterknoten (Tree), die ihm den gewünschten Stream weiterleiten können, bzw. eine Liste mit Peers (Mesh), mit denen er die Streamdaten
austauschen kann.
2. Der Peer schickt eine Anfrage an alle potentiellen Vaterknoten, um als Sohnknoten
angenommen zu werden (Tree). Im Mesh verbindet sich der Peer mit anderen Peers,
35
4.2. PROTOKOLLCHARAKTERISTIKEN
KAPITEL 4. ANALYSE
um Informationen über die Datenverfügbarkeit auszutauschen. Dies geschieht in der
Regel in Form von sogenannten Buermaps, bei denen der lokale Puerinhalt als
Bit-String oder Bitmap dargestellt wird. In einer Buermap werden vorhandene
Segmente durch eine 1 repräsentiert, nicht vorhandene durch eine 0.
3. Der Peer hat einen Vaterknoten gefunden (Tree) bzw. ermittelt anhand der Buermaps die Knoten, die ihm die fehlenden Daten liefern können (Mesh).
4. Der Peer erhält die Daten vom Vaterknoten (Tree) bzw. fordert die Daten bei seinen
Nachbarn aktiv an (Mesh).
Die oben genannten Punkte geben die wesentlichen Charakteristiken vor, nach denen
sich Live-Streaming-Protokolle unterscheiden: in Bezug auf den Join-Vorgang (1), die
Gruppenverwaltung inklusive dem Aufbau von Partnerschaften (2,3) und die Art der
Streamverteilung (4). Im folgenden Abschnitt gehe ich näher auf diese Charakteristiken
ein.
4.2 Charakteristiken eines P2P-Live-Streaming-Protokolls
In diesem Abschnitt werden die wesentlichen Charakteristiken von CoolStreaming mit
denen anderer P2P-Live-Streaming-Protokolle verglichen. Viele P2P-Streaming-Abhandlungen unterscheiden die Protokolle hauptsächlich aufgrund der errichteten Topologie
(siehe 4.2.2). Dieses Kriterium allein reicht nicht aus, um die Funktionsweise der komplexen Protokolle analysieren zu können. Deshalb werden weitere Unterscheidungsmerkmale
vorgestellt wie der Join-Vorgang, die Art der Streamverteilung, die Gruppenverwaltung,
Fehlerkorrekturmechanismen und die verwendeten Transportprotokolle.
4.2.1 Join
Ein neuer Benutzer hat einen Kanal des P2P-Streaming-Anbieters ausgewählt und wendet sich an den entsprechenden Einstiegsknoten im Netz. Dies kann direkt die Quelle
(der Broadcaster) sein, ein denierter Bootstrap-Node oder die DHT-Struktur. In stark
frequentierten Netzen wendet sich der Knoten an einen Tracker, der ihn wiederum an
Super-Nodes weiterleitet.
Der neue Peer erhält vom Einstiegsknoten eine Liste mit möglichen Partnern oder Vaterknoten, wobei in Tree-basierten Systemen in der Regel darauf geachtet wird, dass es sich
bei den Vaterknoten um Blattknoten oder innere Knoten mit ausreichenden Uploadkapazitäten handelt.
Bei Mesh-basierten Protokollen werden die Partnerkandidaten entweder zufällig ausgewählt (wodurch das Overlay-Netz ebenfalls zufällig aufgebaut wird) oder es wird die
geographische Nähe im Netz berücksichtigt (sogenannte Location-Aware-Ansätze). Hybride Ansätze kombinieren die zufällige Auswahl von Partnerkandidaten mit LocationAwareness. Je nach Ansatz variiert die Verbindungsstruktur der Peers. Abbildung 4.1
zeigt die Topologien, die je nach Wahl der Partnerkandidaten entstehen, und zwar für
ein Netz mit 20 Peers und 4 Partnern pro Peer.
36
4.2. PROTOKOLLCHARAKTERISTIKEN
KAPITEL 4. ANALYSE
Abbildung 4.1: Verbindungsstruktur bei zufälliger Partnerwahl (links), bei Wahl mit Berücksichtigung der Location-Awareness (Mitte) und bei dem hybriden
Ansatz (rechts) [CL+10]
CoolStreaming sieht in [ZL+05] zwar vor, dass jeder Peer im Netz durch regelmäÿige
Nachrichten seine Partneranzahl bekannt gibt, so dass die Quelle auf diese Information
zugreifen könnte, aber laut Spezikation werden die Partnerkandidaten für einen neuen
Peer rein zufällig ausgewählt.
Über die Anzahl der vorgeschlagenen Partnerkandidaten liefern die Protokolle keine Informationen. [ZL+05] gibt für CoolStreaming allerdings vor, dass ein neuer Peer alle
vorgeschlagenen Partnerkandidaten kontaktiert, um Partnerschaften aufzubauen. Daher
reicht es hier aus, dem neuen Peer zunächst die Adressen von so vielen Partnerkandidaten zu schicken, zu denen er gemäÿ der empfohlenen maximalen Partneranzahl (4-6
bei CoolStreaming) auch eine Verbindung aufnehmen kann. Werden seine Partneranfragen abgelehnt, so kann er später im Rahmen der regelmäÿigen Overlaywartung weitere
potentielle Partner kontaktieren.
Die Protokolle geben ebenfalls keine Informationen über den initialen Aufbau des P2PStreaming-Netzes bekannt. Die Implementierung muss hier somit Prozeduren vorsehen,
nach der ein Netz entweder komplett neu aufgebaut werden kann, oder es muss eine
Startkonguration implementiert werden.
4.2.2 Topologie der Streamverteilung
CoolStreaming ist ein Mesh-basiertes Protokoll, d.h. der Stream wird über dynamische
Routen im Mesh verteilt. Tree-basierte Protokolle verteilen den Stream dagegen über
einen oder mehrere explizit aufgebaute Multicast-Bäume. Man spricht in diesem Zusammenhang von Single-Tree- bzw. Multi-Tree-Protokollen. Im Folgenden werden die
Eigenschaften sowie die Vor- und Nachteile dieser Topologien beschrieben.
Single-Tree
Die ersten P2P-Live-Streaming-Protokolle waren sogenannte Single-Tree-
Protokolle, die den Stream über einen einzigen explizit errichteten Multicast-Baum verteilten. Die Bandbreite der Blätter blieb bei diesen Systemen ungenutzt. Zusätzlich zum
Baum konnte ein Mesh-Netz aufgebaut werden, über das z.B. Nachrichten zur Gruppenverwaltung verschickt wurden. Sanjay G. Rao und Hui Zhang bezeichneten diese
Architektur (Multicast-Baum über einem P2P-Overlay) als ESM (Kurzform von EndSystem-Multicast). Sie entwickelten Narada als eines der ersten Protokolle, das ESM
realisierte [CR+02, CRZ00].
37
4.2. PROTOKOLLCHARAKTERISTIKEN
Multi-Tree (Multiple-Tree, Forest-based)
KAPITEL 4. ANALYSE
Um die Bandbreite in Tree-basierten Syste-
men besser nutzen zu können, wurden Multi-Tree-Systeme entwickelt, auch Multiple-Tree
oder Forest-based [WLQ06] genannt. Hier werden mehrere, sich überlagernde Bäume zur
Datenverteilung aufgebaut. Ein Peer, der in einem Baum ein Blatt ist, kann in den anderen Bäumen ein innerer Knoten sein und somit seine Uploadbandbreite zur Verfügung
stellen.
Bei Multiple-Tree-Systemen verbinden sich die Peers in der Regel zuerst in einem strukturierten oder unstrukturierten Netzwerk, über dem dann die Bäume errichtet werden.
Die Quelle kodiert den Stream in einzelne Teilstreams (Substreams) und versendet jeden Substream über einen anderen Baum. Fällt ein Vaterknoten aus, erhalten alle seine
Nachfahren in diesem Baum keine Daten, können aber aus den bereits erhaltenen Substreams den Originalstream rekonstruieren. Die Kodierung erfolgt auf Basis von MultipleDescription-Coding (siehe Abschnitt 4.2.5.1), ein sehr komplexes Verfahren, dass von den
gängigen Mainstream-Playern bisher nicht unterstützt wird [LR+08].
Mesh (Unstrukturiert, Data-driven/Datengesteuert, Swarming-based)
Bei Mesh-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 verbunden (siehe Overlay-Layer in Abbildung 4.2) und fordern von ihren Partnern die fehlenden Streamsegmente an. Dadurch werden die Streamsegmente über dynamische Routen im Mesh übertragen und implizit dynamische Multicast-Bäume aufgebaut (siehe
Distribution-Layer in Abbildung 4.2).
Abbildung 4.2: Mesh-Overlay-Schicht (Overlay Layer) und Datenverteilungsschicht (Distribution Layer) in einem P2P-Streaming-Netzwerk [CLB07]
In Mesh-basierten Systemen müssen die Partner regelmäÿig Buermaps austauschen,
um ihren Puerinhalt zu kommunizieren. Durch den Versand von Buermaps und von
Datenanforderungen ist der Kontrolloverhead (d.h. der Anteil der Kontrolldaten an den
Videodaten, siehe Abschnitt 4.4.2) höher als in Tree-basierten Systemen. Auch dauert es
im Unterschied zu Tree-basierten Systemen länger, bis die Daten empfangen und abgespielt werden können, d.h. die Verzögerungen sind gröÿer (siehe Abschnitt 4.4.2). Dafür
sind Mesh-basierte Systeme sehr robust bei Peer-Churn.
38
4.2. PROTOKOLLCHARAKTERISTIKEN
Mischformen
KAPITEL 4. ANALYSE
Bullet [KR+03] implementiert einen hybriden Mesh-/Tree-Ansatz. Das
Protokoll baut zuerst einen Verteilungsbaum auf und darüber ein zufällig verbundenes
Mesh. Über den Baum werden zunächst die Daten übertragen (Stream, Kontrollnachrichten). Fehlende Streamdaten können die Knoten über das Mesh anfordern. Nach dem
Baumaufbau wählt die Quelle eine zufällige Menge von Söhnen aus, zerlegt den Stream
in mehrere Blöcke und verschickt disjunkte Untermengen des Streams an die Söhne. Die
Söhne reichen wiederum disjunkte Untermengen durch den Baum weiter. Jeder Sohnknoten kann als die Wurzel eines Unterbaums betrachtet werden, weshalb Bullet mitunter auch als Multi-Tree klassiziert wird (siehe [LGL08, Liu07]). In [VFC06] sprechen
Venkataraman et al. von einem Multi-Path-Ansatz, da jeder Knoten Teile des Streams
über verschiedene Routen erhält.
PRIME [MR07, MRG07] baut ein strukturiertes unidirektionales Mesh auf, bei dem von
zwei benachbarten Knoten jeweils einer der Sender und einer der Empfänger ist. Analog
zu Multi-Tree-Systemen kodiert die Quelle den Stream in Substreams. In der ersten
Phase (Diusion-Phase) werden die Peers anhand der Verbindungsstruktur im Netzwerk
in disjunkte Bäume aufgeteilt. Jeder Substream wird über einen anderen Baum verbreitet.
In der zweiten Phase (Swarming) werden die fehlenden Daten von den Blattknoten aus
über die Mesh-Verbindungsstruktur verbreitet.
4.2.3 Art der Streamverteilung
Bei CoolStreaming fordern die Peers die benötigten Streamdaten explizit an, d.h. die
Daten werden per Pull verteilt. In anderen Systemen können die Daten auch per Push
verbreitet werden. Im Folgenden erkläre ich die Unterschiede zwischen diesen beiden
Mechanismen der Streamverteilung:
Push/Sender-driven
Der Sender schickt die Daten an den Empfänger, ohne dass der
Empfänger diese Daten vorab anfragt. Der Sender weiÿ hier nicht, welche Segmente der
Empfänger braucht.
Pull/Receiver-driven
Der Empfänger holt sich die benötigten Daten, indem er die Da-
ten beim Sender anfordert und der Sender diese ihm schickt (wie bei CoolStreaming). Das
setzt voraus, dass der Empfänger weiÿ, welche Daten der Sender im Puer hat. Vorab
muss der Sender seinen Puerinhalt in Form von Buermaps kommunizieren.
In Push-basierten Systemen gibt der Sender nur so viele Daten weiter, wie es ihm die
Bandbreite erlaubt. In Pull-Systemen können von einem Sender mehr Daten angefordert
werden, als dieser hochladen kann. Das Protokoll muss also in Pull-basierten Systemen
Beschränkungen vorsehen, um eine Überlastung der Senderkapazität zu verhindern.
Nachfolgend gehe ich auf die Besonderheiten von Push-basierten und Pull-basierten Systemen ein und stelle Systeme vor, die beide Mechanismen implementieren.
39
4.2. PROTOKOLLCHARAKTERISTIKEN
KAPITEL 4. ANALYSE
4.2.3.1 Push
In Single-Tree-basierten Systemen (siehe 4.2.2) verteilen die Vaterknoten den Stream per
Push an die Söhne. Eine niedrige Uploadbandbreite eines Vaterknotens verringert die
Streamingrate für alle seine Nachfahren.
In Multi-Tree-Systemen (siehe 4.2.2) werden die Daten ebenfalls per Push von den Vaterknoten zu den Söhnen übertragen. Da hier die Verteilung über mehrere Bäume erfolgt,
kann ein Peer in einem Baum ein Blatt sein und in einem anderen Baum als innerer Knoten seine Uploadbandbreite beitragen. Die Peers erhalten in einem Multi-Tree-System
nicht den gesamten Stream, sondern nur eine Teilmenge, aus der sie den Originalstream
rekonstruieren können. Dazu kodiert die Quelle den Originalstream in einzelne Substreams mittels Multiple-Description-Coding (siehe Abschnitt 4.2.5.1). Jeder Substream wird
per Push über einen anderen Baum verteilt. Die Empfänger dekodieren die erhaltenen
Daten, um den Originalstream wiederherzustellen.
4.2.3.2 Pull
In der P2P-Streaming-Literatur nden sich bezüglich dieses Begries Abweichungen und
Widersprüchlichkeiten, auf die ich hinweisen möchte:
Nach [CRC08] kennt ein Empfänger beim reinen Pull den Puerinhalt des Senders nicht.
Es ist also möglich, dass er die benötigten Daten genau bei den Sendern anfordert, die sie
nicht liefern können, wodurch der Empfänger verhungern kann. Erst bei der in [CRC08]
Status-basiert genannten Verteilung tauschen Sender und Empfänger Informationen über
ihren Puerinhalt aus. Im Gegensatz dazu beinhaltet für die meisten Autoren die PullVerteilung jedoch bereits den regelmäÿigen Austausch der Verfügbarkeitsinformationen
mittels Buermaps.
In [MRG07] wird das Protokoll PRIME vorgestellt, bei dem der Empfänger Daten per
Pull bezieht. Magharei et al. sprechen von einem Push-Pull-Ansatz, da die Verfügbarkeitsinformationen von den potentiellen Sendern gepusht werden und die benötigten Segmente per Pull angefordert werden. Auch dies weicht von der allgemeinen Denition für
Pull ab und hat leider dazu geführt, dass PRIME in einigen vergleichenden Arbeiten
fälschlicherweise als Push-Pull-Protokoll eingeordnet wurde.
Sehr viele kommerzielle P2P-Live-Streaming-Systeme wie CoolStreaming, PPLive und
UUSee basieren auf einer Mesh-Pull-Architektur, was u.a. darauf zurückzuführen ist, dass
es sich um ein einfaches, gut strukturiertes Verfahren handelt, das sich mit den gängigen Client-Playern einsetzen lässt. Zu den bekannten Vertretern der nicht-kommerziellen
Mesh-Pull-Protokolle gehört Chainsaw [PK+05].
4.2.3.3 Hybrides Push-Pull
Um die Nachteile von reinen Push-Protokollen (Anfälligkeit bei Peer-Churn aufgrund
der explizit aufgebauten Multicast-Bäume) und reinen Pull-Protokollen (hoher Kontrolloverhead und lange Abspielverzögerungen) abzuschwächen, sehen neuere Ansätze die
Kombination von Push und Pull vor.
40
4.2. PROTOKOLLCHARAKTERISTIKEN
KAPITEL 4. ANALYSE
In [RC08] schlagen Russo et al. vor, die aktuellsten Datensegmente per Push an eine
zufällige Untermenge der Partner zu verteilen und nur die fehlenden per Pull anzufordern.
Bei PULSE [Pia07, PKB06] pusht die Quelle die Daten und alle anderen Peers holen sie
per Pull. Das verringert die Anfangsverzögerung der direkten Nachbarn der Quelle.
GridMedia [ZT+05, ZZ+07] wendet einen Pull-Push-Pull-Ansatz an. Ein neuer Peer
fragt zunächst explizit nach Buermaps. Nach erfolgreichem Pull eines Pakets abonniert
der Peer bei dessen Sender einen Substream und erhält die Daten per Push. Die PullLieferung dient als Fallback-Verfahren. Wenn über 95% der Pakete erfolgreich gepusht
werden, fordert er keine Buermaps an. Stehen mehr als 5% der Push-Pakete aus, geht
der Peer wieder zum Pull über, fordert Buermaps an und zieht die Daten.
4.2.4 Gruppenverwaltung
Bei IP-Multicast (siehe Abschnitt 2.5.2.1) übernehmen die Multicast-fähigen Router Aufgaben der Gruppenverwaltung. Die Router bilden einen Multicast-Baum, verwalten die
Mitglieder der Gruppe und verteilen den Stream an die Mitglieder. Bei ALM (siehe Abschnittt 2.5.2.2) erfolgt dies auf der Anwendungsschicht. Die Quelle und die Peers bilden
den Multicast-Baum. Die P2P-Streaming-Protokolle geben dabei vor, wie der MulticastBaum errichtet wird (implizit oder explizit), wie die Struktur bei Peer-Churn aufrechterhalten werden kann und wie die Peers der Gruppe beitreten und Daten beziehen können.
Die ersten P2P-ALM-Protokolle errichteten explizit einen Multicast-Baum, der entweder zentral verwaltet wurde (wie bei CoopNet [PW+02]), durch hierarchische ClusterStrukturen (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 mit
ihnen regelmäÿig Buermaps aus. Diese Sender werden Partner (wie bei CoolStreaming)
oder Nachbarn (wie bei den meisten anderen Systemen) genannt. Die Anzahl der Partner
variiert je nach System. CoolStreaming erzielt laut [ZL+05] optimale Ergebnisse bei 4
bis 6 Partnern. Nach [MR06] kann die Partneranzahl in Mesh-basierten Systemen zwischen 6 und 14 liegen, um eine hohe und aktuelle Lieferqualität zu gewährleisten. Bei
Chainsaw [PK+05] hält der Peer eine minimale Partneranzahl aufrecht, lehnt aber eingehende Partneranfragen nie ab. Da mit steigender Partneranzahl die Uploadkapazität pro
Partner sinkt, könnte meiner Meinung nach der Peer seine maximale Partneranzahl von
seiner verfügbaren Uploadbandbreite abhängig machen, was in den hier besprochenen
Systemen nicht realisiert wurde.
41
4.2. PROTOKOLLCHARAKTERISTIKEN
KAPITEL 4. ANALYSE
Peers können zu ihren Partnern Informationen wie das von ihnen erhaltene Datenvolumen
speichern (siehe CoolStreaming, PRIME [MRG07]), woraus sich deren Uploadbandbreite
schätzen lässt.
4.2.4.2 Verwaltung der Gruppenmitglieder
Fällt der Datenlieferant eines Peers aus (d.h. der Vaterknoten im Tree-basierten System oder der Partner im Mesh-basierten System), sollte der Peer möglichst schnell einen
Ersatzsender nden. Daher muss er andere Knoten im Netzwerk kennen, mit denen er
sich verbinden kann. Dies kann entweder zentralisiert, implizit durch die Struktur oder
durch gezieltes Membership-Management (auch Knowledge-Management [Pia07]) erfolgen. Die Ansätze, nach denen die Gruppenmitglieder verwaltet werden, können wie folgt
unterschieden werden:
Zentralisiert
Beim Ausfall des Vaterknotens wendet sich der Peer an die Quelle und
muss den ganzen Baum nochmals durchlaufen, bis er einen neuen Vaterknoten ndet
(Overcast [JG+00]). In einem zentralisierten System wie CoopNet ermittelt der Zentralserver einen neuen Vater. Der zentralisierte Ansatz ist bei hohem Peer-Churn nicht
skalierbar.
Implizit
In Tree-basierten Systemen merken sich die Peers andere Knoten auf ihrem Weg
durch den Baum, z.B. bei PeerCast die Groÿväter [DB+02] und bei HostCast [LM03]
Groÿväter und Onkel [AYC04]. In den hierarchisch strukturierten Systemen NICE und
ZIGZAG kennen die Peers die Knoten in ihrem jeweiligen Cluster. Der Cluster organisiert
sich bei Peer-Leave, d.h. wenn Peers das Netz verlassen, selbst.
Strukturiertes Membership-Management
Die P2P-Streaming-Protokolle Scribe und
SplitStream setzen auf dem DHT-Substrat Pastry auf, das die Verbindungen zwischen
den Peers verwaltet. Scribe verteilt die Daten nur über einen Multicast-Baum (SingleTree), während SplitStream mehrere Bäume verwendet (Multi-Tree).
Scribe vergibt für die Multicast-Gruppe eine Gruppen-ID, welche im Pastry-Namensraum
liegt. Der Peer mit der numerisch nächsten ID wird zum Einstiegspunkt für diese Gruppe
und zum Wurzelknoten des Multicast-Baums. Der Multicast-Baum wird durch die Pfade
im Pastry-Netzwerk gebildet, die die Gruppenmitglieder mit dem Wurzelknoten verbinden. Auf diesen Pfaden können dabei auch Knoten liegen, die nicht zu der MulticastGruppe gehören und die Nachrichten nur weiterleiten. Beim Ausfall eines Knotens ist die
Pastry-DHT für die Reparaturmaÿnahmen zuständig. [CD+02, MS07]
Bei SplitStream wird der Stream in Substreams (hier Stripes genannt) zerlegt. Jeder
Stripe wird über einen anderen Baum verteilt. Für jeden einzelnen Baum wird dabei
Scribe verwendet und eine eigene Gruppen-ID angelegt.
42
4.2. PROTOKOLLCHARAKTERISTIKEN
Unstrukturiertes Membership-Management
KAPITEL 4. ANALYSE
In unstrukturierten Netzen sollen Peers
eine möglichst groÿe Sicht auf das Netzwerk und die Gruppenmitglieder erhalten.
In dem kleinen Narada-Netzwerk mit weniger als ungefähr 50 Peers soll jeder Peer alle
Mitglieder kennen. Dazu pegt jeder Peer lokal eine Mitgliederliste und erstellt regelmäÿig sogenannte Refresh-Nachrichten, mit denen er sich im Netzwerk bekannt macht. Er
schickt die Refresh-Nachricht an seine Nachbarn, die danach ihre Mitgliederliste aktualisieren. Das Wissen über die Mitglieder wird im Netzwerk propagiert, indem die Nachbarn
ihre Mitgliederlisten zum Abgleich austauschen.
Dieses Verfahren lässt sich in gröÿeren Netzwerken so nicht umsetzen. Lokal kann ein
Peer zwar gröÿere Mitgliederlisten mit mehreren Hundert Einträgen verwalten. Beim
Austausch der Listen im Netzwerk würde es aber zu einem regelmäÿigen Overhead von
mehreren Kilobytes kommen. Vor allem in datenzentrierten Pull-Systemen sollte der
Overhead durch Kontrollnachrichten möglichst gering gehalten werden. In groÿen Netzen kennen Peers daher nicht alle Knoten, sondern nur einen Teil. Der Peer erhält sozusagen eine partielle Sicht auf das Netzwerk. Damit die Peers im Netzwerk mit einer
groÿen Wahrscheinlichkeit von den Gruppenereignissen erfahren, sollte sich die Gröÿe
der partiellen Sicht logarithmisch zur Knotenanzahl verhalten. Die Informationen über
Gruppenereignisse (Join, Leave) werden per Gossiping verbreitet, indem die Nachrichten an eine aus der partiellen Sicht zufällig ausgewählte Teilmenge von Peers verschickt
werden.
SCAMP (Scalable Membership Protocol [GKM03]) wurde nach dieser Idee entworfen
und skaliert somit logarithmisch. Bei SCAMP macht sich ein neuer Peer bekannt, indem
er eine Subskription an einen Kontaktknoten schickt. Dieser leitet die Subskription an
alle Knoten aus der partiellen Sicht weiter sowie an weitere
k
k
zufällig gewählte Knoten.
ist hier ein konstanter Wert. Jeder Knoten, der die weitergeleitete Subskription erhält,
fügt sie mit einer Wahrscheinlichkeit
P (insert)
in die lokale partielle Sicht ein und leitet
sie dann an einen aus der partiellen Sicht zufällig ausgewählten Knoten weiter.
wird wie folgt anhand der Gröÿe der partiellen Sicht
partialviewsize
P (insert)
berechnet:
P (insert) = 1/(1 + partialviewsize)
Zudem werden regelmäÿig sogenannte Heartbeat-Nachrichten an die Nachbarn verschickt,
um gegebenenfalls Isolationen im Netzwerk festzustellen.
CoolStreaming und PULSE verbreiten die Gruppennachrichten mit SCAMP [GKM03],
wobei PULSE die Weiterleitung der Gruppennachrichten durch eine maximale Hopanzahl begrenzt und CoolStreaming dafür eine Gültigkeitsdauer (Time-To-Live oder TTL)
der Nachricht vorsieht. Die CoolStreaming-Autoren denieren die Time-To-Live als Zeitspanne, die z.B. in Sekunden angegeben wird. Analog zur Hopanzahl wird die TTL von
den Empfängern der Nachricht jeweils nach unten korrigiert. Sobald die TTL kleiner
oder gleich 0 ist, wird die Nachricht nicht mehr weitergeleitet, sondern verworfen. Eine
Zeitsynchronisation zwischen den Peers ist somit nicht erforderlich.
Nach [ZL+05] werden bei CoolStreaming die Gruppennachrichten Membership-Messages
genannt. Sie werden regelmäÿig erstellt, verschickt sowie weitergeleitet. Die Weiterleitung einer Nachricht erfolgt nur, solange die Time-To-Live nicht abgelaufen ist. Über
43
4.2. PROTOKOLLCHARAKTERISTIKEN
KAPITEL 4. ANALYSE
die Membership-Messages erfahren die Peers von Joins, Leaves oder Fails (Ausfall eines
Knotens) der anderen Gruppenmitglieder.
Die Autoren haben in [ZL+05] nicht beschrieben, wie sie Gossiping per SCAMP in das
CoolStreaming-Protokoll implementiert haben. Daher wurden im Rahmen dieser Arbeit
folgende zwei Möglichkeiten entwickelt:
1. Ein neuer Peer macht sich im Netzwerk bekannt, indem er eine MembershipMessage an den Einstiegspunkt schickt. Analog zum SCAMP-Algorithmus leitet
der Einstiegspunkt die Membership-Message an alle Knoten sowie an weitere
k
zufällig ausgewählte Knoten aus der partiellen Sicht weiter. Der Empfänger der
Membership-Message fügt sie mit der in SCAMP denierten Wahrscheinlichkeit
P (insert) = 1/(1 + partialviewsize)
in die lokale partielle Sicht ein und leitet
sie an einen zufällig gewählten Knoten weiter. Solange die TTL gültig ist, wird
die Nachricht weitergeleitet. Erst nach Ablauf der TTL erstellt der Peer eine neue
Membership-Message, die wiederum nach dem SCAMP-Algorithmus verteilt wird.
2. Ein neuer Knoten trägt die vom Einstiegspunkt erhaltenen Partnerkandidaten in
seine partielle Sicht ein. Regelmäÿig (z.B. aller 20 Sekunden) erzeugt der Peer eine
Membership-Message, die er an einen zufälligen Knoten aus der partiellen Sicht
schickt. Empfängt ein Knoten eine Membership-Message, aktualisiert er anhand der
Daten aus der Membership-Message seine partielle Sicht und leitet die MembershipMessage an einen zufälligen Knoten weiter. Die Membership-Message wird solange
weitergeleitet, bis die TTL abgelaufen ist.
Da die Implementierung des CoolStreaming-Protokolls und somit des SCAMP-Algorithmus in CoolStreaming möglichst nah am Original erfolgen sollte, kontaktierte ich Xinyan
Zhang, den Entwickler von CoolStreaming, und stellte ihm die zwei oben genannten
Implementierungsmöglichkeiten vor. Laut Xinyan Zhang wurde SCAMP ähnlich zu der
oben genannten zweiten Variante umgesetzt. Zusätzlich tauschen die Partner nach dem
Partnerschaftsaufbau einmalig ihre partiellen Sichten auf das Netzwerk aus. [AYC04,
Liu04, Pia07, SZ+08]
4.2.5 Fehlerkorrekturmechanismen und Kodierungen
In einem P2P-Streaming-Netzwerk müssen die Peers den Stream rechtzeitig zur geplanten
Wiedergabe erhalten, um die Daten ohne Aussetzer abspielen zu können. Treen nicht
alle Daten rechtzeitig ein (z.B. nach dem Ausfall des Vaterknotens in Tree-basierten
Systemen), ist es wünschenswert, dass die Peers den Originalstream dennoch rekonstruieren können. P2P-Streaming-Systeme können zu diesem Ziel Fehlerkorrekturmechanismen oder Kodierungen implementieren und so die Robustheit im Netzwerk zu erhöhen.
Es werden redundante Daten erzeugt und versandt, damit auch bei fehlenden Daten der
Originalstream wiederhergestellt werden kann.
Die in diesem Abschnitt vorgestellten Verfahren unterscheiden sich darin, durch wen
im Netzwerk die Kodierung ausgeführt wird. Bei Multiple-Description-Coding (MDC)
kodiert nur die Quelle den Stream und die empfangenden Peers dekodieren ihn lediglich.
Bei der Vorwärtsfehlerkorrektur (Forward-Error-Correction/FEC) kann entweder nur die
Quelle die Kodierung anwenden oder die Peers im Netzwerk. Die Netzwerkkodierung
44
4.2. PROTOKOLLCHARAKTERISTIKEN
KAPITEL 4. ANALYSE
(Network-Coding/NC) sieht vor, dass alle Peers im Netzwerk die Daten kodieren und
dekodieren.
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 Descriptions, Substreams oder Slices). Im einfachsten Fall teilt man dabei die Frames nach ihrer
Nummerierung auf und erhält eine Description mit den Frames mit geraden Nummern
und eine zweite Description mit allen Frames mit ungeraden Nummern [LR+08].
Jede Description wird über einen anderen Baum verteilt. Aus jeder Untermenge von
empfangenen Descriptions kann ein Peer den Originalstream rekonstruieren, wobei die
Qualität des Streams mit der Anzahl der empfangenen Descriptions steigt. Für die Rekonstruktion benötigt der Peer allerdings zusätzliche Rechenzeit. Um eine gute Qualität gewährleisten zu können, muss jede Description genügend Informationen über den
Originalstream enthalten, was sich wiederum negativ auf die Ezienz der Kompression
auswirken kann. [Liu04, LR+08]
Das Mesh-basierte System PRIME setzt ebenfalls MDC ein. Der Peer fordert so viele
Descriptions an, wie es ihm seine Download-Kapazität ermöglicht und kann mit einer
wachsenden Zahl von erhaltenen Descriptions seine Abspielqualität verbessern [MR07].
4.2.5.2 FEC (Forward-Error-Correction/Vorwärtsfehlerkorrektur)
Bei FEC werden aus den Originaldaten Redunzdaten berechnet, die zusammen mit den
Originaldaten versandt werden. Mit Hilfe der Redundanzdaten können bei Übertragungsfehlern die verlorenen Daten wiederhergestellt werden. Um die erforderliche Redundanz
zu ermitteln, muss vorab abgeschätzt werden, wie groÿ der auftretende Fehler sein kann.
FEC wird gewöhnlich auf der Bitübertragungsschicht angewandt, indem mittels einer
XOR-Operation ein Fehlercode aus den zu übertragenden Bits berechnet und übertragen
wird.
FEC in P2P-Netzwerken kann z.B. durch eine Reed-Solomon-Kodierung [RS60] realisiert werden (wie in dem Live-Streaming-System PULSE [Pia07]). Im PULSE-System
wird die Kodierung nur durch die Quelle ausgeführt. Der Stream wird dabei in einzelne
Blöcke zerlegt, die als Vektoren über einem endlichen Körper betrachtet werden können.
Durch Matrixmultiplikation mit einer sorgfältig gewählten Matrix
1 werden die kodierten
Blöcke erzeugt. Die Quelle verschickt die Originalblöcke und die kodierten Redundanzblöcke. Fehlende Originaldaten können mit Hilfe einer inversen Matrix wiederhergestellt
werden. Matrixmultiplikation und Invertierung erfordern allerdings einen relativ hohen
Rechenaufwand.
Falls FEC von Netzwerkknoten angewandt wird, erhöhen die Berechnungen (Kodierung
und Dekodierung) auf den Knoten die Verzögerungen im Netzwerk. [LR+08, MF09,
MS07]
1
z.B. Vandermonde-Matrix
45
4.2. PROTOKOLLCHARAKTERISTIKEN
KAPITEL 4. ANALYSE
4.2.5.3 NC (Network-Coding/Netzwerkkodierung)
Im Unterschied zur Vorwärtsfehlerkorrektur muss bei der Netzwerkkodierung vorab nicht
der mögliche Paketverlust abgeschätzt werden. Hier erstellen alle Knoten im Netzwerk
eine Kodierung der erhaltenen Daten und geben sie weiter. Abbildung 4.3 stellt das
Prinzip der Netzwerkkodierung vereinfacht dar.
Abbildung 4.3: Prinzip der Netzwerkkodierung (NC) [MF09]
In der Abbildung 4.3 sind S1 und S2 Sender, die die binären Pakete a und b an X und Y
übertragen sollen. Jede Kante kann nur ein Paket transportieren. Der innere Knoten R
kann entweder a oder b weiterleiten. Indem R die Summe, a XOR b, berechnet und an X
und Y weiterleitet, können die Empfänger die Originaldaten errechnen und gleichzeitig
werden weniger Übertragungen benötigt.
Die Netzwerkkodierung in P2P-Streaming-Netzwerken erfolgt allerdings nicht mittels
XOR-Operationen, sondern durch Multiplikation der erhaltenen Daten mit einer Variablenmatrix. Der Stream wird von der Quelle in einzelne Blöcke zerlegt. Jeder Block
kann hier als Eintrag eines Vektors über einem endlichen Körper betrachtet werden. Die
inneren Netzwerkknoten berechnen aus den erhaltenen Blöcken eine Linearkombination,
indem sie den (aus den Blöcken bestehenden) Vektor mit einer Variablenmatrix multiplizieren. Linearkombination und Variablenmatrix werden versendet. Die Empfängerpeers
können die ursprünglichen Blöcke durch Multiplikation der inversen Matrix mit der Linearkombination ermitteln.
In der Regel erhält ein Knoten nicht die Originalnachricht, sondern bereits eine Paketkombination. Daher enthält meist jedes Paket Informationen über alle Pakete. Auf diese
Weise kann NC nicht nur die Robustheit erhöhen, sondern auch die Datenverfügbarkeit
und den Durchsatz im Netzwerk.
Problematisch ist der Berechnungsaufwand und die Beobachtung, dass NC die Gesamtverzögerung im Netzwerk erhöht. Wang et al. argumentieren in [WL07] zwar, dass aufgrund der ohnehin hohen Verzögerung beim Streaming die zusätzliche Verzögerung durch
NC nicht weiter ins Gewicht fallen würde und dass der Berechnungsaufwand auf einem
Standardrechner kein Problem sei. Es ist aber anzunehmen, dass auf weniger leistungsstarken Rechnern (wie z.B. mobilen Geräten) der zusätzliche Berechnungsaufwand ein
Problem darstellt.
Bei NC in P2P-Streaming handelt es sich um ein sehr neues Forschungsgebiet, auf dem
in nächster Zeit sicher mit weiteren Ergebnissen zu rechnen ist. Es wird z.B. vorgeschla-
46
4.2. PROTOKOLLCHARAKTERISTIKEN
KAPITEL 4. ANALYSE
gen, zwischen wichtigen und unwichtigen Multimedia-Daten zu unterscheiden und die
aufwändige Dekodierung nur bei wichtigen Daten durchzuführen. [LR+08, MF09, MS07]
4.2.6 Transportprotokolle
Um den Videostream und die Kontrollnachrichten über das Internet zu versenden, werden Transportprotokolle des Internets benutzt. Das Containerformat wird dabei nicht
als kompletter Stream verschickt, sondern zunächst mit einem sogenannten Packetizer in
gleich groÿe Pakete des entsprechenden Transportprotokolls zerlegt. Die Pakete werden
entweder direkt über die Transportprotokolle der Transportschicht TCP und UDP verschickt. Oder man verwendet je nach Anwendung und Containerformat speziellere Übertragungsprotokolle wie z.B. RTP, das proprietäre RTMP oder GBTP (GoalBit Transport
Protocol [BV+09]), welche wiederum auf TCP oder UDP aufbauen. Aus der Sicht des
OSI-Schichtenmodells handelt es sich bei RTP, RTMP oder GBTP nicht um tatsächliche
Transportprotokolle, da sie in einer Schicht oberhalb der Transportschicht anzusiedeln
sind. Dennoch werden sie in der Literatur oft als Transportprotokolle bezeichnet, weil sie
für den Datentransport konzipiert wurden (siehe auch [Sch08]).
4.2.6.1 RTP
RTP wird oft zum Transport von kontinuierlichen Echtzeitdaten verwendet. Es kann nach
Spezikation mit TCP oder UDP zusammenarbeiten. In der Regel setzt RTP aber auf
UDP auf und bietet dabei Anpassungen für Echtzeitanwendungen.
RTP versieht die Pakete mit einer Kennung für den Payload, einer fortlaufenden Nummer und einem Zeitstempel. Durch die Nummerierung kann der Empfänger feststellen,
ob die RTP-Pakete in der richtigen Reihenfolge gesandt wurden. Der Zeitstempel ermöglicht die Synchronisation unterschiedlicher Datenströme (z.B. Audio, Video) [Sim08]. In
frühen Versionen konnten RTP-Pakete entweder Audioformate oder Videoformate transportieren, aber nicht beides zusammen. Auf Empfängerseite mussten die Audio- und Videodaten zu einem Stream gemuxt werden. Mittlerweile sieht RTP auch den Transport
von Containerformaten nach MPEG-2 oder MPEG-4 vor.
Nur wenige P2P-Streaming-Protokolle geben an, ob sie den Transport über RTP vorsehen, ausgenommen CoolStreaming [ZL+05], GridMedia [ZZ+07] und PeerCast [DB+02].
Die meisten P2P-Streaming-Protokolle erwähnen RTP möglicherweise deshalb nicht, da
der Fokus dieser Protokolle auf dem Aufbau des P2P-Streaming-Overlays und dem Datenaustausch liegt. Die Verwendung von RTP spielt hierbei nur eine untergeordnete Rolle
und hat keinen Einuss auf die sonstigen Protokollcharakteristiken.
Beim Transport mit RTP wird durch den 12-Byte-RTP-Header zusätzlicher Overhead
erzeugt [Sim08]. Zudem versieht oft das P2P-Streaming-Protokoll die Chunks mit Sequenznummer und Zeitstempel und nimmt die Sortierung auf Empfängerseite vor, so
dass der Einsatz von RTP nicht notwendig erscheint und lediglich zu redundanten Daten
führt.
47
4.2. PROTOKOLLCHARAKTERISTIKEN
KAPITEL 4. ANALYSE
4.2.6.2 UDP
UDP, ein Protokoll der Transportschicht im OSI-Schichtenmodell, ist ein verbindungsloses Protokoll mit eingeschränkter Zuverlässigkeit [Kle05]. Die Datensegmente werden
versandt ohne Garantie, dass sie vollständig oder in korrekter Reihenfolge ankommen.
Da UDP so viele Daten verschickt, wie es die Bandbreite erlaubt, und zudem kein Verbindungsaufbau zwischen Sender und Empfänger stattndet, bietet UDP einen schnellen
Datentransport ohne garantierte Qualität. Daher eignet sich UDP für Echtzeitanwendungen im Internet, für die ein kontinuierlicher Datenuss in minderer Qualität eher
akzeptabel ist als ein Datenuss in hoher Qualität, der stockt oder ausfällt.
Gegen den groÿächigen Einsatz von UDP im Internet sprach lange, dass das Internet
unter der UDP-Last zusammenbrechen könnte, was sich bisher nicht bewahrheiten konnte
[Zha10]. Allerdings wird UDP oft von Firewalls blockiert.
P2P-Streaming-Protokolle verwenden UDP oft zum Versand der Kontrollnachrichten
(z.B. PULSE, PPLive, PPStream, SopCast, TVAnts [Pia07, SF+08]). Die kommerziellen
Anbieter PPLive, PPStream und SopCast setzen UDP auch für den Datenversand ein
[Zha10].
4.2.6.3 TCP
TCP, neben UDP das zweite echte Transportprotokoll, ist verbindungsorientiert und
realisiert einen zuverlässigen bidirektionalen Datenübertragungsdienst mit Flusskontrolle
[Kle05]. Die Einhaltung der Bytereihenfolge wird garantiert, nicht empfangene Pakete
werden nochmals versandt und durch die Flusskontrolle kann die Senderate verringert
werden. TCP sieht zudem mehrere gleichzeitige Verbindungen vor.
All diese Eigenschaften verlangsamen den tatsächlichen Transport, was TCP zunächst für
Echtzeitanwendungen uninteressant macht. Andererseits lässt sich die Verbindungsorientiertheit von TCP in P2P-Streaming-Sitzungen gut integrieren. Beim Datenaustausch
werden in Tree-basierten Systemen Verbindungen zwischen Vater und Sohn erstellt, in
Mesh-basierten zwischen Partnern. Wird dazu eine TCP-Verbindung errichtet, erhält der
Peer bei Ausfall des Partners ein FIN-Segment. Um den Partnerausfall festzustellen, müssen somit auf der Anwendungsschicht keine weiteren Mechanismen implementiert werden, welche wiederum Overhead verursachen könnten (wie der Versand von HeartbeatNachrichten 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 verloren gegangene Segmente nochmals zu übertragen mit der Begründung, dass nicht erhaltene Segmente wesentlich schneller von anderen Peers bezogen werden können als durch
den nochmaligen Versand mit TFRC.
4.2.6.4 Wahl des Transportprotokolls
Bei der Wahl des Transportprotokolls ist es wichtig zwischen den Kontrollnachrichten an beliebige Peers und den Nachrichten an die Partner zu unterscheiden. Für den
48
4.3. MESH-PULL-KOMPONENTEN
KAPITEL 4. ANALYSE
Versand von Kontrollnachrichten zu anderen Peers im Overlay (z.B. von MembershipNachrichten) bietet sich UDP an. Da der eigentliche Datenaustausch und der Versand
2 nur zwischen Partnern bzw. Vätern und Söhnen
der dazugehörigen Kontrollnachrichten
stattndet, halte ich hier den Einsatz einer leichtgewichtigen TCP-Variante für sinnvoll.
Die Partnerschaft kann hier errichtet werden, indem die TCP-Verbindung aufgebaut wird.
Wird die Partnerschaft beendet (bei Leave oder Fail) wird auch die TCP-Verbindung beendet.
Um den Overhead durch Kontrollnachrichten zu minimieren, schlagen einige P2P-Streaming-Protokolle vor, die Kontrollnachrichten an die Partner mit den Streamdaten im
Payload zu versenden. Man bezeichnet diesen Versand als piggyback (engl. für Huckepack).
CoolStreaming verwendet als Transportprotokoll für die Streamdaten RTP in Verbindung mit UDP, TCP oder TFRC. In der Implementierung verwende ich aus oben genannten Gründen UDP für den Versand von Membership-Nachrichten und TFRC für
den Nachrichtenaustausch zwischen Partnern, allerdings ohne nochmalige Übertragung
oder Flusskontrolle.
4.2.7 Überblick
In diesem Abschnitt wurden die wesentlichen Charakteristiken von CoolStreaming mit
denen anderer P2P-Live-Streaming-Protokolle verglichen. Für eine umfassende Übersicht
fasst Tabelle 4.1 die Eigenschaften der bekanntesten P2P-Live-Streaming-Protokolle zusammen. Bei dieser tabellarischen Übersicht gehe ich insbesondere auf den Aspekt der
Datenverteilung und auf die Gruppenverwaltung durch Membership-Management ein.
Mittels Membership-Management können Peers weitere Peers im Netzwerk kennenlernen
und so im Falle von Leave oder Fail eines Partners schnell neue Partnerschaften aufbauen.
4.3 Komponenten von Mesh-Pull-Protokollen
In Mesh-Pull-Systemen wie CoolStreaming werden die Streamdaten über dynamische
Routen im Mesh verteilt, wobei die Peers die Streamdaten explizit bei ihren Partnern
anfordern (Pull). Die Datenverteilungswege werden in Mesh-Pull-Systemen durch den
Scheduler bestimmt, der anhand der Partner-Buermaps ermittelt, bei welchen Partnern
welche Segmente angefragt werden.
4.3.1 Scheduler
Die zentrale Komponente bei Mesh-Pull-Mechanismen ist der Scheduler, auch Scheduling-Algorithmus, Packet-Scheduling-Algorithmus/PSA oder Request-Scheduling-Algorithmus [Pia07] genannt. Der Scheduler wird regelmäÿig aufgerufen und berechnet, bei
welchen Partnern welche Segmente angefragt werden.
2
(Buermaps und Requests in Mesh-basierten Systemen)
49
50
2001
2003
2005
2006
2004
2002
2005
2003
2000
2002
2000
2002
2004
2007
2006
2007
2002
2005
2003
2000
2003
ALMI [PS+01]
Bullet [KR+03]
Chainsaw [PK+05]
Chunkyspread [VFC06]
CoolStreaming [ZL+05]
CoopNet [PW+02]
GridMedia [ZT+05]
HostCast [LM03]
Narada [CRZ00]
NICE [BBK02]
Overcast [JG+00]
PeerCast [DB+02]
PPLive [ppl]
PRIME [MR07]
PULSE [PKB06]
R2 [WL07]
Scribe [CD+02]
SopCast [sop]
SplitStream [CD+03]
YOID [Fra00]
ZIGZAG [THD03]
DHT (Pastry)
Gossiping im Mesh
DHT (Pastry)
Rendezvous-Point
Cluster
Mesh
Gossiping im Mesh (Swaplinks)
Gossiping im Mesh (SCAMP)
Zentraler Server
Gossiping
Implizit (Onkel+Groÿväter bekannt)
Mesh
Cluster
Zentralisiert: Quelle
Implizit (Groÿväter bekannt)
Gossiping im Mesh
Bootstrap-Node/Gossiping
Gossiping im Mesh (SCAMP)
Gossiping im Mesh
Zentralisiert: Session-Controller
(auch Rendezvous-Point genannt)
Mesh (RanSub)
Membership-Management
Single-Tree über Pastry
Mesh
Multiple-Tree über Pastry
Single-Tree Tree-rst
Single-Tree Mesh-rst
Single-Tree Mesh-rst [AYC04, SW05]/
Single-Tree Tree-rst [HA+06]
Erst Tree, darüber Mesh (für fehlende
Chunks)
Mesh
Multiple-Tree
Mesh
Multiple-Tree Tree-rst
Unstrukturiertes Overlay
Single-Tree Tree-rst
Single-Tree Mesh-rst
Single-Tree Mesh-rst
Single-Tree Tree-rst
Single-Tree Tree-rst
Mesh
Strukturiertes, unidirektionales Mesh
Mesh
Mesh
Topologie der Streamverteilung
Pull
Push
Pull
Push
Pull-Push-Pull
Push
Push
Push
Push
Push
Pull
Pull
Push (Quelle), Pull (Peers)
Random-Push mit
Random-Network-Coding
Push
Pull
Push
Push
Push
Push-Pull
Push
Art der Streamverteilung
VFC06, VY07, Wan08, ZZ+07]
Tabelle 4.1: Vergleich der Charakteristiken von P2P-Live-Streaming-Protokollen [AYC04, HA+06, Liu04, MR07, Pia07, SW05, SZ+08,
Jahr
Protokoll
4.3. MESH-PULL-KOMPONENTEN
KAPITEL 4. ANALYSE
4.3. MESH-PULL-KOMPONENTEN
KAPITEL 4. ANALYSE
Die Scheduler in den untersuchten Protokollen unterscheiden sich bzgl. der Wahl der
angeforderten Segmente (Chunk-Selection) und der Wahl des potentiellen Senders (PeerSelection).
Chunk-Selection
PRIME fordert zuerst die aktuellsten Segmente an. Eine ähnliche
Strategie empfehlen die Autoren in [YDL07]. Hier werden zunächst die aktuellsten Segmente angefordert. Wenn diese nicht verfügbar sind, werden die älteren Segmente angefragt, die als nächstes abgespielt werden sollen. Die Anfangsverzögerung bei dieser
Strategie ist gröÿer, als wenn nur die demnächst abzuspielenden Segmente angefordert
werden.
CoolStreaming fordert die fehlenden Segmente nach der Verfügbarkeit bei den Partnern
an, so dass Segmente, die nur einmal verfügbar sind, zuerst angefragt werden. Man bezeichnet dieses Verfahren als Rarest-First. Bei diesem Verfahren kann es passieren, dass
die Peers mit den seltensten Segmenten im Netzwerk von Anfragen überschwemmt werden. Um dies zu verhindern, sollte jeder Peer nur so viele Anfragen an einen Partner
schicken, wie dieser voraussichtlich bearbeiten kann. Zu diesem Zweck kann z.B. eine
Obergrenze für Anfragen pro Partner deniert werden. Oder man wendet heuristische
Verfahren an, um die verfügbare Uploadbandbreite des Partners zu ermitteln. Dieses
Verfahren wird im folgenden Abschnitt besprochen.
Einige Protokolle sehen darüber hinaus vor, dass die Anzahl der anzufordernden Segmente je Scheduling-Lauf beschränkt wird. CoolStreaming sieht laut [ZL+05] keine derartige
Begrenzung vor, was theoretisch dazu führen kann, dass ein neuer Peer, der eine laufende
Streaming-Sitzung betritt, versucht, seinen gesamten Puer zu befüllen und dabei die
Partner mit Anfragen überschwemmt.
Peer-Selection
Es bieten sich folgende Mechanismen an, um die Segmentanfragen auf
die Partner, die die Segmente liefern können, zu verteilen:
Random: Fehlende Segmente werden zufällig bei den Partnern angefordert (siehe
z.B. Chainsaw [ZX+09]). Ohne die Implementierung eines Zufallsgenerators könnte
dies zu einer ungleichen Verteilung der Pull-Requests und somit der Bandbreitenanforderungen führen. Denn werden
n
n Partnern angefragt,
1/e (d.h. 36,79%) kein
fehlende Segmente bei
wird bei einem Partner mit einer Wahrscheinlichkeit von
Segment angefordert.
Round-Robin: Die Anfragen werden gleichmäÿig auf die Partner verteilt. Die Bandbreitenkapazitäten der Partner werden nicht berücksichtigt. Partner mit hoher
Bandbreite können bei der Methode möglicherweise zu wenig angefragt werden
und Partner mit einer niedrigen Bandbreite durch Pull-Requests überlastet.
Heuristische Bandbreitenschätzung: CoolStreaming und PRIME weisen ihren Partnern die Pull-Requests gemäÿ ihrer geschätzten Uploadbandbreite zu. Die Qualität
dieses Verfahrens hängt von der Qualität der Bandbreitenschätzung ab (siehe auch
5.4.7.1). Bei einer zuverlässig funktionierenden Bandbreitenschätzung stellt dieses
Verfahren die fairste Variante dar, ist aber komplexer und damit auch fehleranfälliger.
51
4.4. PERFORMANCE-VERGLEICH
KAPITEL 4. ANALYSE
Um Überlastungen des Partners zu vermeiden, kann die Anzahl der Pull-Requests pro
Partner begrenzt werden. Auch bei einer zuverlässigen Bandbreitenschätzung würde
dies zumindest als Fallback-Mechanismus dienen. So wie einige andere Protokolle sieht
CoolStreaming diese Begrenzung nicht vor.
4.3.2 Bearbeitung von Datenrequests
Für den Partner, der Datenanfragen erhält, stellt sich die Frage, in welcher Reihenfolge
er diese bearbeitet. Verschickt er die Daten so, wie sie angefragt werden (FIFO), kann
es passieren, dass ein Partner, der mehrere Segmente auf einmal anfordert, die gesamte
Uploadkapazität des Senders in Anspruch nimmt.
Bei PULSE verwaltet der Peer für jeden Partner eine Request-Queue und zu jedem
Segment einen Zähler replica count, der festhält, wie oft der Peer das Segment bereits
an Partner verschickt hat. Erhält der Peer mehrere Anfragen auf einmal, verschickt er
zuerst die Segmente, die bisher am seltensten versandt wurden, damit diese schneller im
Netz verteilt werden. Die anderen verschickt er in zufälliger Reihenfolge.
GridMedia verwendet einen anderen sehr interessanten Ansatz. Systemweit wird ein Requestintervall
t
t
deniert. Die Sender verschicken Segmente nur während des Requestin-
tervalls . Nach Ablauf von
t verwirft der Sender alle nicht bearbeiteten Anfragen. Fordert
t+Round-Trip-Time, weiÿ
ein Peer ein Segment an und erhält es nicht nach Ablauf von
er, dass er das Segment nochmals anfordern muss und lässt den Scheduler erneut den potentiellen Sender ermitteln [ZZ+07]. Da der Sender nicht alle Anfragen bearbeitet, muss
er dafür sorgen, dass die anfragenden Peers fair bedient werden. Eine faire Methode wäre
ein Zähler, der für jeden Partner den Anteil der bearbeiteten Requests speichert und aktualisiert. Diese Methode ist einfacher zu implementieren und weniger speicherintensiv,
als beispielsweise für jeden Partner eine eigene Request-Queue vorzusehen.
GridMedia bietet somit eine Lösung, wie im Falle von nicht erhaltenen Segmenten vorzugehen ist. Um zu verhindern, dass nicht erhaltene Segmente die Wiedergabe massiv
beeinträchtigen, könnte also ein Segment nach Ablauf eines Zeitintervalls nochmals angefordert werden (in der Honung, dass es rechtzeitig eintrit) oder das fehlende Segment
wird mit Hilfe eines Fehlerkorrekturmechanismus wie FEC rekonstruiert (siehe Abschnitt
4.2.5.2).
Die CoolStreaming-Autoren geben in [ZL+05] lediglich an, dass angeforderte Segmente
durch RTP verschickt werden.
4.4 Performance-Vergleich
Die Qualität von P2P-Streaming-Protokollen lässt sich entweder durch die sogenannte
Quality of Experience (QoE) ausdrücken oder anhand messbarer Eigenschaften. Quality of Experience stellt nach Huang von PPLive zwar die wichtigste Metrik dar, spiegelt
aber nur die subjektive Dienstgüte beim Empfänger wieder. Die Benutzer können z.B.
Auskunft darüber geben, wie gut sie die Bildqualität oder wie störend sie Verzögerungen empfunden haben. Die QoE lässt sich in der Regel nicht automatisiert erfassen oder
vergleichen. [Hua07, tuc10]
52
4.4. PERFORMANCE-VERGLEICH
KAPITEL 4. ANALYSE
Daher wendet man die Mittel der Performance-Evaluierung an. Analog zur PerformanceEvaluierung im P2P-Bereich gilt es auch bei den P2P-Streaming-Protokollen herauszunden, ob das Protokoll die Eigenschaften Skalierbarkeit, Robustheit und Ezienz aufweist.
4.4.1 Protokolleigenschaften
Jede der Eigenschaften Skalierbarkeit, Robustheit und Ezienz wird durch Metriken
ausgedrückt, die sich wiederum aus einem oder mehreren Messwerten zusammensetzen
[Wol10].
Skalierbarkeit
bezeichnet die Fähigkeit eines P2P-/P2P-Streaming-Netzwerks, sich an
eine quantitativ wachsende Anzahl von Peers und/oder Daten anzupassen [Wol10]. Die
Skalierbarkeit wird in Bezug auf eine messbare Kenngröÿe ausgedrückt, z.B. in Bezug auf
den Kontrolloverhead (auch Protokolloverhead), der durch das Verhältnis des Kontrolldatenvolumens zum Videodatenvolumen ermittelt wird. Ist das Wachstum des Kontrolloverheads bei wachsender Peeranzahl logarithmisch begrenzt durch
O(logN ), kann man
sagen, dass das System in Bezug auf den Kontrolloverhead skaliert [MS07].
Robustheit
beschreibt die Eigenschaft eines Netzwerks, auch unter hoher Last und
bei Fehlern (z.B. Ausfällen der Netzwerkstruktur) ein speziziertes Leistungsniveau zu
erhalten [Wol10]. Die Robustheit bezieht sich ebenfalls auf eine Kenngröÿe, die in P2PStreaming-Netzwerken meist unter starkem Churn gemessen wird.
Ezienz
wird in [FH07] ganz allgemein als Wirkungsgrad von Aktivitäten deniert.
In einem P2P-Streaming-Netzwerk kann Ezienz dadurch ausgedrückt werden, wie gut
beim Streamingprozess vorhandene Ressourcen (insbesondere die Netzwerkbandbreite)
genutzt werden. In einem System mit einer hohen Bandbreitenezienz wird z.B. die
Uploadbandbreite aller Peers bestmöglich verwendet.
4.4.2 P2P-Streaming-Metriken
Die ersten ALM-Systeme wurden als Alternative zu IP-Multicast entwickelt, weshalb bei
diesen Tree-basierten ALM-Systemen zur Evaluierung Metriken wie Path-Stretch und
Link-Stress ausschlaggebend waren. Path-Stretch misst das Verhältnis der Pfadlängen
in der Topologie im Vergleich zum kürzesten Pfad (dem direkten Unicast-Weg bzw. der
Ende-zu-Ende-Verzögerung/EED). Link-Stress misst die Anzahl von identischen Paketen
auf einzelnen Teilstrecken, also den Overhead durch redundante Daten. Durch PathStretch und Link-Stress lässt sich bestimmen, wie ezient ein ALM-System im Vergleich
zu IP-Multicast die Daten verschickt. [SWS07]
Die Herausforderung für Tree-basierte Protokolle im Streamingprozess besteht aber eigentlich darin, einen Baum mit geringer Höhe zu errichten und bei Peer-Churn diesen
Baum auszubalancieren. Daher müssen in Tree-basierten Systemen Nachrichten mit Routingtabellen [CRZ00], Membership-Nachrichten und weitere Kontrollnachrichten ausgetauscht werden, die in die Bezierung der Metrik Kontrolloverhead einieÿen:
53
4.4. PERFORMANCE-VERGLEICH
Kontrolloverhead
KAPITEL 4. ANALYSE
ist das Verhältnis aller Kontrollnachrichten in Bytes zu den reinen
Videostreamdaten in Bytes. Der Kontrolloverhead kann entweder als Wert zwischen 0
und 1 oder in Prozent angegeben werden. In Mesh-basierten Systemen ist der Kontrolloverhead sowohl bei Peer-Churn als auch bei Anstieg der Peeranzahl so gut wie konstant.
Das liegt an der dynamischen Wahl von Sendern (also temporären Vätern) sowie an der
konstanten Anzahl von Partnern, an die jeder Peer den Groÿteil der Kontrollnachrichten
verschickt. Beim Test eines Protokolls kann der Kontrolloverhead als Funktion anderer
Gröÿen wie z.B. der Partneranzahl gemessen werden, um optimale Parameterwerte zu
ermitteln.
In Tree-basierten Systemen hängt der Kontrolloverhead vom Wachstum des Netzwerks ab
(siehe Tabelle 4.2). Der geringe Kontrolloverhead von ZIGZAG erklärt sich hier dadurch,
dass die Peers hierarchisch in Clustern strukturiert werden und nur innerhalb dieses
Clusters Gruppennachrichten austauschen.
Protokoll
ALMI
CoopNet
Narada
NICE
Overcast
Scribe
SplitStream
YOID
ZIGZAG
Kontrolloverhead
O(N )
O(logN )
O(N )[CRZ00] bzw. O(N 2 )[HA+06]
O(logN )
O(logN )
O(log2b N )
O(N logN ) bis O(N 2 ) worst-case
O(logN )
O(k) bis O(logN ) mit k=konstanter Knotengrad
Tabelle 4.2: Kontrolloverhead von Tree-basierten ALM-Protokollen in Relation zur Knotenanzahl
N
[AYC04, CRZ00, HA+06]
Beim Live-Streaming sind insbesondere die Verzögerungen bei der Wiedergabe ausschlaggebend. Diese sollten so gering wie möglich sein. Nach Auswahl des Kanals sollte der
Benutzer nicht lange auf den Beginn der Übertragung warten müssen und die Daten
auch nicht wesentlich später als seine Nachbarn erhalten. Während im Tree-basierten
Netzwerk die Abspielverzögerung eines Peers durch seine Position im Baum bestimmt
wird und somit konstant ist, schwanken die Verzögerungen in Mesh-basierten Systemen
stark und stellen daher wichtige Metriken dar.
Startup-Delay/Anfangsverzögerung
beziert die Zeitdierenz zwischen der Kanalaus-
wahl und dem Beginn der Wiedergabe des Live-Streams. Die Anfangsverzögerung wird
in der P2P-Streaming-Literatur auch als Initial-Startup-Latency [HLR08], Click-to-playDelay/C2P [Pia07] oder SETUP-Delay [MP+08] bezeichnet.
Playback-Delay/Abspielverzögerung
beziert die Zeitdierenz zwischen der Ausgabe
eines Streamsegments durch die Quelle und dessen Wiedergabe durch den Peer. Synonym
zu Playback-Delay werden die Begrie Playout-Delay [MR07], Display-Lag [HLR08],
Average-Reception-Delay [Pia07] verwendet.
54
4.4. PERFORMANCE-VERGLEICH
KAPITEL 4. ANALYSE
Eine weitere wichtige Metrik für Mesh-basiertes P2P-Streaming stellt der ContinuityIndex dar:
Continuity-Index (Playback-Continuity-Index, Playback-Continuity)
gibt an, wie kon-
tinuierlich die Wiedergabe des Streams erfolgt. Damit ein Stream kontinuierlich und ohne
Aussetzer abgespielt werden kann, müssen die Streamsegmente rechtzeitig (d.h. vor ihrem jeweiligen Abspielzeitpunkt) eintreen. Der Continuity-Index wird ermittelt, indem
man die Anzahl der rechtzeitig erhaltenen Segmente durch die Anzahl aller Segmente
teilt, die hätten abgespielt werden sollen. Der Continuity-Index kann entweder als Wert
zwischen 0 und 1 oder in Prozent angegeben werden.
Die Streamingqualität drückt sich dadurch aus, dass der Peer den Stream möglichst ohne
Aussetzer empfängt, weshalb ein gröÿtmöglicher Teil der Segmente vor der PlaybackDeadline beim Peer eintreen sollte. Der Continuity-Index kann als Funktion in Relation
zur Partneranzahl, zur Streamingrate oder zu anderen Parametern ermittelt werden.
Tabelle 4.3 vergleicht einige bekannte ALM-Protokolle anhand der besprochenen Metriken (Startup-Delay, Playback-Delay, Continuity-Index, Kontrolloverhead). Die Protokolle sind entweder rein Mesh-basiert (CoolStreaming, GridMedia, PPLive, SopCast) oder
benutzen einen Mesh-/Tree-Ansatz (Bullet, PRIME).
Protokoll
Startup-Delay
Playback-Delay
Continuity-Index bei
Streamingraten von
309-330 kbps / 380 kbps
Kontrolloverhead
Bullet
CoolStreaming
mind. 1min
mind. 1min
3-5%
2%
GridMedia
PPLive
PRIME
SopCast
20s - 2min
30-48s
37s - 5min
2,2-7s
1min
1min
99,5% / 99,3% [ZL+05]
90% / 85% [LJ+06]
99-100% / 88% / 99-100%
3%
5%
5%
Tabelle 4.3: Vergleich von Metriken bei Mesh-basierten und Mesh-/Tree-basierten ALMProtokollen [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 CoolStreaming-Protokolls gemessen wurden. Bei einer Streamingrate von 380 kbps messen
die CoolStreaming-Autoren z.B. einen Continuity-Index von 99,3% [ZL+05], während
Liao et al. in [LJ+06] lediglich auf einen Continuity-Index von 85% kommen. D.h. nach
Liao et al. erhält ein CoolStreaming-Benutzer durchschnittlich 15% des Streams nicht
rechtzeitig. In [ZL+05] wurde der Continuity-Index in einer Simulation mit 200 Peers
gemessen, in [LJ+06] dagegen mit 400 Peers. In [ZL+05] hat ein Peer durchschnittlich 5
Partner, in [LJ+06] mindestens 5 Partner.
Skalierbarkeit und Robustheit eines P2P-Streaming-Protokolls lassen sich durch die Metriken Startup-Delay, Playback-Delay und Continuity-Index ausdrücken. Der Kontrolloverhead ist insbesondere dann interessant, wenn man ein bestehendes Protokoll strukturell verändert und die Auswirkungen testen will.
55
4.5. GRAPH-ANALYSE
KAPITEL 4.
ANALYSE
In [ZL+05] ermittelten die Autoren die Skalierbarkeit von CoolStreaming unter Berücksichtigung von Kontrolloverhead und Continuity-Index. Da der Kontrolloverhead unabhängig von der Overlaygröÿe ist und der Continuity-Index auch beim Wachstum des Netzes von 10 auf 200 Knoten nicht unter 95% fällt, kann man folgern, dass CoolStreaming
skaliert. Bei starkem Churn, wenn jeder Peer z.B. aller 100 Sekunden das Netz betritt
und wieder verlässt, sinkt der Continuity-Index nicht unter 91%, wodurch sich die relative
Robustheit des Systems zeigt.
4.5 Graph-Analyse
CoolStreaming wendet Gossiping an, um Gruppennachrichten über Joins, den aktuellen
Status (Partneranzahl etc.) oder Leaves der Peers zu verteilen. Jeder Peer kennt daher
eine zufällige Teilmenge aller Knoten im Netzwerk, die er in einer partiellen Sicht speichert. Da sowohl Partnerkandidaten für neue Knoten als auch Partner als Ersatz für
ausgefallene Knoten zudem zufällig aus der partiellen Sicht ausgewählt werden, erzeugt
CoolStreaming einen zufälligen Verbindungsgraph (siehe Abbildung 4.4). Der Grad jedes Knotens in diesem Verbindungsgraph liegt aufgrund der Partneranzahl in einem
bestimmten Bereich, optimalerweise zwischen 4 und 6 [ZL+05].
1.0.0.1
1.0.0.5
1.0.0.3
1.0.0.7
1.0.0.4
1.0.0.2
1.0.0.6
1.0.0.8
1.0.0.9
1.0.0.10
Abbildung 4.4: Zufälliger Verbindungsgraph des CoolStreaming-Netzwerks (10 Peers,
maximale Partneranzahl=5)
Die Graph-Analyse in P2P-Streaming-Netzen unterscheidet sich von der Graph-Analyse
in klassischen P2P-Netzen. In P2P-Netzen werden Dateien gesucht, die irgendwo im
Netzwerk liegen können. Für eine eziente Suche ist daher der Durchmesser entscheidend,
d.h. die Länge der längsten aller kürzesten Pfade im Netzwerk. In P2P-Streaming-Netzen
geht es darum, dass die Peers die von der Quelle gestreamten Daten auch bei wachsendem
Netzwerk schnellstmöglich erhalten. Aus diesem Grund wird der Abstand zwischen Quelle
und Peer betrachtet. Man spricht in diesem Zusammenhang von Overlay-Radius oder
Tiefe bzw. Höhe des Multicast-Baumes.
In [ZL+05] haben die Autoren eine logarithmische Relation zwischen Overlay-Radius und
56
4.6. ZUSAMMENFASSUNG
KAPITEL 4. ANALYSE
Netzwerkgröÿe gezeigt. Die durchschnittliche Distanz von der Quelle zu einem Peer wird
durch
O(logN )
begrenzt, mit
N
= Anzahl der Knoten im Netz. Das CoolStreaming-
System skaliert demnach in Bezug auf die Ende-zu-Ende-Verzögerung.
4.6 Zusammenfassung CoolStreaming
CoolStreaming verteilt die Daten über ein zufällig erzeugtes Mesh. Die Datenverteilung
erfolgt über Pull, d.h. die Peers fordern fehlende Daten bei ihren Partner an.
Die Mesh-Pull-Struktur ist einfach strukturiert und lässt sich somit gut implementieren, weshalb sie von allen gröÿeren kommerziellen Systemen (wie PPLive, PPStream,
SopCast, TVAnts) eingesetzt wird. Zudem bietet die Mesh-Pull-Struktur im Vergleich zu
den Tree-basierten Strukturen den Vorteil, dass sie die Bandbreitenkapazitäten der Peers
gleichmäÿiger nutzt und ein robustes Netz erzeugt, das wenig anfällig bei Peer-Churn ist.
Beim P2P-Live-Streaming ist vor allem die Robustheit bei Peer-Churn eine wichtige Anforderung, da es in diesem Anwendungsbereich zu Flash-Crowds und somit zu starkem
Churn kommen kann. Problematisch in Mesh-Pull-Systemen sind die Verzögerungen und
der Overhead durch Kontrollnachrichten. Die Verzögerungen bei CoolStreaming können
von einer Minute bis zu mehreren Minuten (nach Userberichten) betragen. Der Kontrolloverhead ist mit 2% im Vergleich zu anderen Mesh-Pull-Protokollen dagegen relativ
niedrig (siehe auch Tabelle 4.3).
Abbildung 4.5 zeigt den Aufbau des CoolStreaming-Systems nach [ZL+05]. Die Autoren
unterscheiden zwischen den Kernkomponenten Membershipmanager (für die Verwaltung
der partiellen Sicht), Partnershipmanager (für die Verwaltung von Partnerschaften) und
Scheduler.
In vielen P2P-Streaming-Arbeiten wird vor allem der besondere Scheduling-Algorithmus
von CoolStreaming hervorgehoben, der die Segmente gemäÿ ihrer Verfügbarkeit bei den
Partnern in Buermap-ähnlicher Art anfordert. Ist ein Segment nur bei einem Partner
lieferbar, wird es immer bei diesem angefragt. Segmente, die mehrmals verfügbar sind,
werden nach der geschätzten Uploadbandbreite der Partner angefordert. Hat ein Partner
keine Bandbreitenkapazitäten übrig, erhält er keine Datenrequests. Eingehende Datenrequests werden sortiert über RTP verschickt.
Mit Sicherheit stellte der CoolStreaming-Scheduler zu der Zeit seiner Veröentlichung
eine groÿe Neuerung dar, dennoch ergeben sich bei genauerer Prüfung des in [ZL+05]
veröentlichten Algorithmus folgende mögliche Probleme:
1. Die Qualität des Algorithmus hängt von der Korrektheit der heuristischen Bandbreitenschätzung ab.
2. CoolStreaming deniert keine generellen Obergrenzen für die Anzahl der insgesamt
angefragten Segmente. Ein neuer Peer, der seinen kompletten Puer füllen möchte,
kann seine Partner mit Anfragen überschwemmen.
3. Da CoolStreaming auch keine Obergrenze für die Anzahl der angefragten Segmente
pro Partner deniert und alle nur einmal verfügbaren Segmente bei dem entsprechenden Partner ordert, ist folgendes Szenario möglich: Ein Partner, der neuere
57
4.6. ZUSAMMENFASSUNG
KAPITEL 4. ANALYSE
Player
Membershipmanager
Puffer
Partnershipmanager
Buffermap
Scheduler
Netzwerk-Interface
Partner
Partner
Partner
Abbildung 4.5: Systemdiagramm eines CoolStreaming-Peers (nach [ZL+05])
Daten hat als die anderen, erhält alle Datenrequests, da er als einziger die neuesten
Segmente liefern kann.
4. Da in [ZL+05] nicht deniert wurde, dass ein Peer eingehende Datenrequests in
einer bestimmten Reihenfolge abarbeitet oder bei Überlastung Datenrequests ablehnen kann, kann man daraus schlieÿen, dass Requests so bearbeitet werden, wie
sie eintreen. Erhält ein Partner mehr Requests als er bearbeiten kann, kommt es
zu einer Überbeanspruchung seiner Bandbreitenkapazität. Dadurch kann der Peer
schlieÿlich vollständig überlastet werden. Die Verzögerungen auf Seiten der wartenden Empfänger würden sich immer mehr kumulieren.
5. Auch wenn in [ZL+05] und in anderer P2P-Streaming-Literatur betont wird, dass
die seltensten Segmente zuerst angefragt werden, ist dies nicht immer gewährleistet. Die Peers fordern die fehlenden Segmente in Buermap-ähnlicher Art an. Beispielsweise erstellt ein Peer P1 für jeden Partner einen Bit-String von der Gröÿe
des Puers. Jedes Bit steht für ein Segment. Benötigte Bits werden mit einer 1
markiert, nicht benötigte mit 0. Der Oset dieses Strings entspricht der ID des
ersten Puerelements, so dass die IDs der zu liefernden Segmente leicht ermittelt
werden können. Wenn P1 bei einem Partner mehrere Segmente anfordert, so werden
die Segmente aufgrund des Bit-Strings aufsteigend nach ihrer ID angefordert, d.h.
die ältesten Puersegmente zuerst. Das Ziel, dass die seltensten Segmente immer
zuerst angefordert werden, wird durch die Buermap-ähnliche Anfrage kolportiert.
Abschlieÿend möchte ich betonen, dass es durchaus möglich ist, dass die oben geschil-
58
4.6. ZUSAMMENFASSUNG
KAPITEL 4. ANALYSE
derten Probleme in der tatsächlichen CoolStreaming-Implementierung gelöst wurden, da
die Autoren in [ZL+05] nicht alle Protokollcharakteristiken dokumentiert haben. Auf eine Nachfrage meinerseits hin hat mir aber der CoolStreaming-Entwickler Xinyan Zhang
die zuletzt erwähnte Unstimmigkeit bestätigt, nach der die seltensten Segmente nicht
immer zuerst angefragt werden. Sollte dies bei der Implementierung zu Problemen, z.B.
Aussetzern, führen, lieÿe sich das einfach dadurch lösen, dass die Segmente in einer Liste angefragt werden. Zu bedenken ist hier, dass dies die Gröÿe der Kontrollnachrichten
erhöht.
59
5 Implementierung
Dieses Kapitel behandelt die wesentlichen Aspekte der Implementierung des CoolStreaming-Protokolls. Zunächst wird die Auswahl eines geeigneten Vorgehensmodell für Softwareprojekte besprochen. Dann wird auf die Besonderheiten hingewiesen, die es bei der
Implementierung in den P2P-Simulator P2PNetSim und der Integration des Benchmarksystems SimBench [Wol10] zu beachten gilt. Darüber hinaus werden die wesentlichen
Komponenten des implementierten Protokolls besprochen sowie deren Interaktion. Am
Ende des Kapitels werden die angewandten Test- und Verikationsmethoden vorgestellt.
5.1 Implementierung in P2PNetSim
P2PNetSim ist ein parallel arbeitender Netzwerksimulator, der im Unterschied zu vielen anderen Simulatoren mehr als eine Million Knoten im Netzwerk simulieren kann.
P2PNetSim wurde komplett in Java entwickelt und ist somit plattformunabhängig einsetzbar. Der Simulator stellt ein einfaches Netzwerkmodell zur Verfügung, wobei zu Gunsten eines geringstmöglichen Overheads auf die Modellierung von IP-Routing oder der
TCP-Funktionalität verzichtet wurde. [Roj07]
Die Simulation der Peers erfolgt sequentiell in jedem Simulationsschritt. Die zentrale
Peer1 .
Das Peer-Objekt kennt den aktuellen
simtime), kann Nachrichten senden und empfangen und hat
Logger-Objekt der Klasse P2PNetSimLogger.
Komponente dazu ist die abstrakte Klasse
Simulationsschritt (Variable
Zugri auf das
Für die Initialisierung der Peers benötigt P2PNetSim eine XML-Kongurationsdatei. In
dieser Datei kann man zu jedem Peer auch selbst denierte Parameter hinzufügen, welche
im Programm mit
getParam(String key)
ausgelesen werden können. Selbst denierte
Parameter erscheinen in der P2PNetSim-GUI unter Properties (siehe Abbildung 5.1).
In der P2PNetSim-GUI werden oberhalb von Properties Key-Value-Paare der Grundkonguration (Basic conguration) aufgelistet, z.B. die Netzwerkadresse (Address)
oder der Klassenname (Class ID).
Alle Peers, die im Laufe einer Simulation online gehen sollen, müssen in der XMLKongurationsdatei deniert werden. Durch den P2PNetSim-Befehl Connect werden
vor Simulationsbeginn alle Peers aus der Kongurationsdatei initialisiert. P2PNetSim
unterscheidet nicht zwischen einem online-Peer und einem oine-Peer. Dies muss zusammen mit den Join- und Leave-Mechanismen in der jeweiligen Protokoll-Implementierung
umgesetzt werden. Es empehlt sich hier die Integration von SimBench [Wol10], da
1
Peer ist hervorgehoben, da es sich um die konkrete Klasse Peer handelt und nicht um einen Peer
im Netzwerk. Beim Bezug auf Klassen, Pakete, Bibliotheken, Variablen, Konstanten, Methoden,
Datentypen oder Modikatoren erscheinen diese in der Schrift Courier New.
60
5.1. P2PNETSIM
KAPITEL 5. IMPLEMENTIERUNG
Abbildung 5.1: P2PNetSim-GUI mit Anzeige der Grundkonguration (Basic conguration) und selbst denierter Parameter (Properties) von Peer10
SimBench hierfür fertige Methoden anbietet, z.B. für Join, Leave und für die OnlineStatusabfrage (siehe Abschnitt 5.2).
P2PNetSim sieht das Speichern von Logmeldungen in Logdateien sowie die Ausgabe von
Logmeldungen in der GUI vor. Debugmeldungen zur Fehlersuche können in der GUI als
Logmeldungen oder auf der Kommandozeile ausgegeben werden.
Die Peers kommunizieren in P2PNetSim über Nachrichten, d.h. über Objekte der abstrakten Klasse
Message.
Per Default wird jede Nachricht in einem Simulationsschritt
zugestellt. Falls Protokolle der Transport- oder IP-Schicht implementiert werden müssen, empehlt es sich, das zu versendende Segment oder Paket als
Message-Objekt
zu
implementieren.
Während eines Simulationsschrittes fallen beim P2P-Streaming viele Aktionen mit hoher Komplexität an, z.B. die Reparatur des Overlaynetzwerks, der Nachrichtenempfang,
die Ausführung des Scheduling-Algorithmus und der Nachrichtenversand (z.B. von Buffermaps, Datenrequests). Zur übersichtlichen Implementierung in P2PNetSim und zur
ezienten Fehlersuche habe ich daher folgende Kriterien festgelegt:
Implementierung eines schlanken Peers mit möglichst wenig Kontrollstrukturen.
Regelmäÿiger Test der einzelnen Funktionalitäten auÿerhalb von P2PNetSim.
P2PNetSim implementiert IP, jedoch keine Portnummern und somit keine Dienste der
Transportschicht. Im Rahmen der vorliegenden Implementierung wurden daher TCPund UDP-Funktionalitäten integriert (siehe Abschnitt 5.4.2).
Auf der Anwendungsschicht ist die Implementierung eines echten Medienplayers im Simulator nicht erforderlich, da der Medienplayer kein Bestandteil des P2P-StreamingProtokolls 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 Metrik
Anfangsverzögerung (siehe Abschnitt 4.4.2) oder indem gemessen wird, inwieweit die
Streamsegmente rechtzeitig vor der Deadline eintreen (siehe Metrik Continuity-Index
in Abschnitt 4.4.2).
5.2 Integration von SimBench
SimBench ist ein Benchmarksystem, das von Alexander Wolf im Rahmen einer Abschlussarbeit für P2PNetSim entwickelt wurde [Wol10]. Es handelt sich um ein eigenes System
mit Nachrichtenklassen, Befehlsklassen, einem Observer-Konzept und einem Frontend
zur Generierung der XML-Kongurationsdatei.
Das Benchmarksystem ist auf die Evaluierung von P2P-Protokollen für den Dateiaustausch optimiert. Ein Dateisystem ermöglicht dabei die Verteilung von Dateien auf Peers
mit Gleich- oder Normalverteilung. Über eine Befehlszentrale erhält jeder Peer StandardP2P-Befehle (z.B. zum Join, Leave, Fail) sowie Datei-spezische Befehle wie Delete, Lookup und Store.
SimBench ist konzipiert, um als Library (jar-Datei) ohne weitere Anpassungen eingebunden zu werden. Zur Evaluierung des P2P-Streaming-Protokolls war dies aus folgenden
Gründen nicht möglich: Erstens werden beim P2P-Streaming keine Dateien gesucht, ausgetauscht oder dauerhaft gespeichert. Die Datei-spezischen Befehle Delete, Lookup und
Store werden somit nicht benötigt und die Befehlszentrale kann nicht wie vorgesehen
verwendet werden. Zweitens wurde der SimBench-XML-Generator in Anpassung an das
Gnutella-Protokoll entworfen. Für den Einsatz beim P2P-Streaming hätte er eigens angepasst werden müssen. Und drittens sind die vorhandenen SimBench-Metriken nicht zur
Evaluierung von P2P-Streaming-Protokollen geeignet.
Zur Evaluierung des P2P-Streaming-Protokolls CoolStreaming wurde daher auf folgende
Teilfunktionalitäten von SimBench zurückgegrien:
Denition 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
simbench
(mit den
EventHandler-Klassen), stats
common (mit AbstractStatistik),
util be-
(mit Statistikklassen) und
nötigt.
Enum-Werte deniert. Die
Verarbeitung der Messwerte erfolgt in einer eigenen Statistikklasse StreamingStatistik
(extends AbstractStatistik) innerhalb des p2pstreaming-Pakets. Die Statistikklasse
StreamingStatistik stellt auch die Methoden zur Verfügung, mit denen Peers online
und oine gehen können. Die Instanz von StreamingPeer hat ein StreamingStatistikNeue Messwerte werden in der Klasse
stats.Messwert
als
Objekt, übergibt anderen Klassen - falls Messungen erforderlich - eine Referenz auf dieses
Objekt und gibt am Ende jedes Simulationsschrittes die gemessenen Werte als
62
PeerEvent
5.3. VORGEHENSMODELL
zurück. Die Messwerte sammelt die Klasse
KAPITEL 5. IMPLEMENTIERUNG
simbench.SimBenchGlobalEventHandler ein
und gibt sie aus. Auÿerdem speichert diese Klasse die Verbindungsstruktur als gerichteten
Graph ab.
Da SimBench ein nützliches Tool zur Evaluierung von P2P-Protokollen darstellt, sollte
es zum Test von zukünftigen Implementierungen möglichst problemlos eingesetzt werden
können. Für eine direkte Einbindung als Library gilt es, zukünftig Folgendes zu berücksichtigen:
Es sollte ein P2P-Protokoll implementiert und getestet werden, das auf die vorhandene SimBench-Funktionalität (insbesondere Dateiverteilung) zurückgreift.
SimBench wird von Entwicklungsbeginn an eingebunden, so dass die Struktur der
Protokoll- Implementierung an SimBench leicht angepasst werden kann. Eine spätere Integration des Benchmarkssystems empehlt sich aufgrund seiner Komplexität
nicht.
5.3 Wahl des Vorgehensmodells für Softwareprojekte
Ein Softwareprojekt dient der Entwicklung von Software und zeichnet sich - gemäÿ der
Denition von Projekten - durch hohe Komplexität aus sowie dadurch, dass ein deniertes Ziel innerhalb einer denierten Zeitspanne mit begrenzten Mitteln erreicht werden
soll. Zur Realisierung von Softwareprojekten gibt es verschiedene Vorgehensmodelle. Vorgehensmodelle sollen dabei die komplexen Prozesse strukturieren, mit dem Ziel, Zeit und
Kosten zu sparen sowie die Qualität zu verbessern. [pta07]
Bei den klassischen Vorgehensmodellen lassen sich folgende unterscheiden:
Wasserfallmodell
tierung, Test
und
Das Wasserfallmodell trennt die Phasen
Einsatz
Analyse, Design, Implemen-
zeitlich strikt voneinander. Erst nachdem alle Komponenten
auf dem Papier entwickelt wurden, können sie implementiert werden. Und erst nach
Fertigstellung der Implementierung folgt der Test derselbigen. Dies ist nur bei sehr einfachen 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üssen
dennoch ein Grob- und ein Feinentwurf erfolgen, die als Vorgabe für die Implementierung gelten.
V-Modell
Statt einer zeitlich strikten Abfolge werden Aktivitäten und Ergebnisse (z.B.
Modultest) deniert. Das V-Modell ist teilweise sehr bürokratisch und wird in Projekten
der öentlichen Hand verwendet.
63
5.3. VORGEHENSMODELL
KAPITEL 5. IMPLEMENTIERUNG
RUP (Rational Unied Process)
Bei RUP handelt es sich um ein objektorientiertes
Vorgehensmodell für groÿe Projekte, bei dem der Aufwand für die vorgeschriebene Dokumentation sehr groÿ ist.
Die oben genannten Vorgehensmodelle haben den Nachteil, dass sie strenge Vorgaben
machen und in der Praxis recht unexibel sind. Es wird nicht berücksichtigt, dass sich
Anforderungen und Prioritäten während des Projektverlaufs meist ändern und ein vollständiger und korrekter Entwurf des Systems vorab nicht machbar ist. Dazu ist der
administrative Aufwand sehr hoch, was wiederum die Projektdauer verlängert.
Diese Probleme lösen sogenannte agile Vorgehensmodelle. Sie sollen den bürokratischen
Aufwand verringern und die Projektdurchlaufzeiten verkürzen. Sie sehen nur wenige Regeln vor, die exibel angewandt werden können. Es wird nur soviel Dokumentation erstellt
wie 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. Paare
aus Programmierern arbeiten beim Erstellen des Codes zusammen und überprüfen regelmäÿ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 Abschnitt 5.1 festgelegt, dass regelmäÿige Tests auÿerhalb des Simulators unverzichtbar
sind. P2P-Streaming-Protokolle zeichnen sich darüber hinaus durch hohe Komplexität
aus. Trotz der Vorstellung des CoolStreaming-Protokolls in [ZL+05] sind viele Aspekte nicht beschrieben, so dass ein vollständiger Entwurf vor der Implementierung nicht
möglich war. Daher wurde für die vorliegende Implementierung kein klassisches Vorgehensmodell der Softwareentwicklung gewählt, sondern auf Prinzipien der agilen Softwareentwicklung zurückgegrien. Kundenorientierung und Paarprogrammierung wurden
verstä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 und
Durchführung von Integrationstests
Ständige Refaktorisierung von Codeteilen
Insbesondere eine minimale Implementierung zusammen mit der ständigen Überarbeitung des Codes verhindern, dass mehr Funktionen implementiert werden als womöglich
benötigt werden. D.h. im ersten Schritt wird nur soviel umgesetzt wie für den Simulationsablauf 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 des
Protokolls zu stark vom Original abweicht. [pta07]
5.4 Implementierung der Module
Die Implementierung des CoolStreaming-Protokolls in den Simulator P2PNetSim erfolgte
in Java. Das Protokoll wurde dazu in zentrale Klassen und Module zerlegt.
Die zentrale Komponente ist der Streamingpeer, der Nachrichten des abstrakten Typs
StreamingMessage
mit Partnern und sonstigen Peers im Overlay austauscht, siehe Ab-
bildung 5.2.
Streamingpeer
Datenmanager
Scheduler
Partnershipmanager
Player
Puffer
Request
Streamsegmente
Partnerliste
Buffermap
Membership-Message
Peer
Peer
Partner
Partner
Membershipmanager
mCache
Partner
Peer
Peer
Partner
Peer
Peer
CoolStreaming-Overlaynetzwerk
Abbildung 5.2: Implementierung des CoolStreaming-Peers
5.4.1 Überblick
Jeder neue Peer muss zuerst Partnerschaften zu anderen Peers aufbauen, um Streamdaten
austauschen zu können.
Ein neuer Peer kennt zunächst nur die IP-Adresse der Quelle. Nach dem Join kontaktiert
er die Quelle mit einer Hello-Nachricht. Die Quelle schickt ihm in einer HelloReplyNachricht eine Liste mit IP-Adressen möglicher Partnerkandidaten. Um eine Partnerschaft aufzubauen, muss der Peer eine TCP-Verbindung zu einem Partnerkandidat erstellen. Er schickt ein TCPSYN an den Kandidaten, der die TCP-Verbindungsanfrage
65
5.4. MODULE
KAPITEL 5. IMPLEMENTIERUNG
MAX_PARTNER
annimmt (mit TCPACK) oder ablehnt (mit TCPNAK). In der Konstante
kann die maximale Partneranzahl pro Simulationslauf deniert werden. In [ZL+05] empfehlen die CoolStreaming-Autoren 4 bis 6 Partner.
Der Peer speichert seine Partner in der Partnerliste. Die Partner tauschen regelmäÿig
drei Arten von Nachrichten aus: Buermaps, Datenrequests und die eigentlichen Daten
(die Streamsegmente).
Ein Partner, der Daten in seinem Puer vorliegen hat, kommuniziert den Puerinhalt
mit einer Buermap. Die Buermap repräsentiert den Puer in Form eines Bit-Strings.
Jedes vorhandene Segment wird mit einer 1 dargestellt, nicht vorhandene mit einer
0. Auÿerdem enthält die Buermap einen Oset, d.h. die ID (Variable
segment_id)
des ersten Puersegments. Daraus lassen sich die IDs aller weiteren Segmente im Puer
ermitteln.
Nachdem ein neuer Peer Buermaps seiner Partner erhalten hat, ermittelt sein Scheduler,
bei welchem Partner der Peer welche Segmente anfordern soll. Dabei werden die seltenen
Segmente, die nur bei einem Partner vorhanden sind, zuerst berücksichtigt. Der Peer
schickt dann einen Request an die Partner. Die angeforderten Segmente werden vom
Supplier-Peer über die TCP-Verbindung einzeln verschickt und beim Empfänger-Peer
sortiert in den Puer eingefügt. 10 Sekunden nach Erhalt des ersten Segments beginnt
die Datenwiedergabe durch den Player. Nach [ZL+05] wird pro Sekunde ein Segment
abgespielt. Trit ein Segment nicht rechtzeitig ein, kann es nicht abgespielt werden.
Neben den Nachrichten, die nur Partner untereinander austauschen, werden noch sogenannte Membership-Messages versandt. Jeder Peer erstellt regelmäÿig eine MembershipMessage mit einer TTL in Sekunden. Diese Nachricht wird per Gossiping an einen zufällig
ausgewählten Peer aus der partiellen Sicht (hier mCache genannt) verschickt. Solange die
TTL einer Membership-Message gültig ist, wird die Nachricht per Gossiping im Netzwerk
weitergeleitet. Dadurch lernen die Peers neben ihren Partnern weitere Peers im Netzwerk
kennen.
Verlässt ein Peer das Netzwerk kann er sich gracefully verabschieden. Er erstellt eine
Departure-Message, die per Gossiping im Netz verbreitet wird. Die Empfänger dieser
Departure-Message wissen, dass der Erzeuger der Nachricht das Netz verlassen hat und
lö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 mehrmals mit dem Netzwerk verbinden und sich wieder abmelden, ohne dass seine Membervariablen reinitialisiert werden. Daher muss in der Implementierung der Peer beim
Leave alle temporären Daten dieser Sitzung löschen. Beim Verlassen beendet der Peer
die TCP-Verbindungen zu den Partnern durch Versand einer TCPFIN-Nachricht und
löscht danach die Partner aus der Partnerliste. Er löscht die Inhalte der Nachrichtenqueues, der partiellen Netzwerksicht (mCache), des Puers und des Players.
Ist ein Peer oine, werden alle Nachrichten, die an seine Adresse gesandt werden, mit
einer HostUnreachable-Nachricht beantwortet.
66
5.4. MODULE
KAPITEL 5. IMPLEMENTIERUNG
5.4.2 Datentransport
P2PNetSim simuliert IP, aber keine Protokolle der Transportschicht. Da es sich meiner
Meinung nach empehlt, Daten an die Partner mit einer leichtgewichtigen TCP-Variante
zu verschicken und Daten an alle anderen Peers mit UDP (siehe 4.2.6.4), müssen in der
CoolStreaming-Implementierung die wichtigsten Funktionalitäten von TCP und UDP
integriert werden. Insbesondere werden der TCP-Handshake zum Aufbau von Partnerschaften benötigt und die Möglichkeit, parallele Verbindungen zu simulieren.
Die Partner verbinden sich per TCP. Der Austausch der Daten sowie der Kontrollnachrichten erfolgt über diese Verbindung. Dazu wird ein TCP-Handshake mit den Nachrichten TCPSYN und TCPACK simuliert. TCPFIN beendet die Verbindung. Eine Bestätigung von TCPACK oder TCPFIN muss nicht implementiert werden, da in der Simulationsumgebung im Unterschied zum realen Internet keine Pakete verloren gehen können.
Der Sender eines TCPACK- oder TCPFIN-Segments kann davon ausgehen, dass der
Empfänger das Segment erhält.
Da P2PNetSim die Nachrichten aus der Eingangs- bzw. Ausgangsqueue sequentiell ausliest und bearbeitet, könnten groÿe Nachrichten (mit Streamsegmenten) die Queue verstopfen und den Versand bzw. Empfang kurzer Kontrollnachrichten verzögern. Um dieses
Problem zu umgehen, werden Kontrollnachrichten bis zu einer vordenierbaren Gröÿe vor
den Datennachrichten versandt bzw. empfangen.
CoolStreaming verschickt angeforderte Datensegmente in korrekter Reihenfolge mittels
RTP über ein Transportprotokoll [ZL+05]. Die RTP-Funktionalität wird wie folgt implementiert:
Jedes
StreamSegment-Objekt
hat eine eindeutige
segment_id.
Werden mehrere Segmente bei einem Peer angefordert, so verschickt der Sender die
Segmente nach ihrer
segment_id
in aufsteigender Reihenfolge.
Sollten die Segmente beim Empfänger nicht in der angeforderten Reihenfolge ankommen, werden sie sortiert in den Puer eingefügt.
Alle der oben genannten Funktionalitäten werden durch den Datenmanager implementiert, da sie den Datenversand und -erhalt betreen.
Der Datenversand kann aufgrund von geringen Uploadbandbreiten der Sender-Peers verzö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 empfangenden Peer die Downloadbegrenzung, wird der Empfang einer Nachricht doppelt
verzögert (erst beim Upload, dann beim Download). Theoretisch müssten hier die Segmente fragmentiert verschickt werden. Eine Implementierung der Fragmentierung war
aus folgendem Grund dennoch nicht erforderlich: Eine doppelte Verzögerung aufgrund
der Bandbreite kann nur dann eintreten, wenn die Downloadbandbreite des Empfängers kleiner ist als die Streamingrate und der Peer weniger als ein Segment pro Sekunde
empfangen kann. Um am Streamingprozess teilnehmen zu können, muss die Downloadbandbreite eines Peers aber mindestens so groÿ wie die Streamingrate sein. Daher muss
dieser Sonderfall nicht bei der Implementierung berücksichtigt werden.
67
5.4. MODULE
KAPITEL 5. IMPLEMENTIERUNG
5.4.3 Die Klasse StreamingMessage
StreamingMessage. Jeidentifier (vom Typ String)
Alle Nachrichten beim P2P-Streaming sind vom abstrakten Typ
StreamingMessage-Instanz wird durch die Variable
identifier-String enthält den Nachrichtentyp, die Sendezeit in Simulationsschritten, den Absender und den Empfänger. Der identifier-String bietet
de
charakterisiert. Der
folgende Vorteile:
Die Kennung ist menschenlesbar und eignet sich für die Ausgabe in Logmeldungen.
StreamingMessage-Objekts werden zwar der Sender
(getSender()) und der Empfänger (getRecipient()) neu gesetzt, aber der ursprünglich zugewiesene Wert der Variable identifier bleibt unverändert. Da-
Bei der Weiterleitung eines
durch kann der ursprüngliche Sender und der Zeitpunkt der Erzeugung der Streamingmessage jederzeit ausgelesen werden, z.B. beim Empfang einer weitergeleiteten
Gruppennachricht (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 Dierenz 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:
Puergröÿe: Der Quellpuer ist halb so groÿ. In der Standardkonguration umfasst
er 30 statt 60 Segmente und damit Videodaten für 30 Sekunden Abspielzeit.
Puerinhalt: Abgesehen von den ersten 29 Sekunden der Simulation, während derer
der Puer erst befüllt werden muss, ist der Quellpuer immer voll. Jede Sekunde
wird ein Segment ans Ende des Puers angehängt und das älteste Segment gelöscht.
Datenaustausch: Weder fordert die Quelle Daten an noch erhält sie Daten. Die
Quelle ist ein reiner Supplier.
Bei der Implementierung des CoolStreaming-Peers wurde aus Gründen der Übersichtlichkeit und späteren Erweiterbarkeit zwischen der abstrakten Klasse
StreamingPeer
unterschieden, die Grundfunktionalitäten zur Verfügung stellt, und der konkreten Implementierung als Klasse
PullStreamingPeer.
StreamingPeer ist abgeleitet von der abstrakten P2PNetSim-Klasse Peer. Bei der Klasse
StreamingPeer handelt es sich um eine generische Klasse, die den Peer samt Membervariablen initialisiert und Prozeduren für Join und Leave implementiert. Die wiederkehrenden Aufgaben (Nachrichtenempfang, Nachrichtenversand und Overlay-Wartung)
empfangeNachrichten(), sendeNachrichten()
doSim()-Methode.
erscheinen als abstrakte Methoden
repariereOverlay()
in der
und
PullStreamingPeer, abgeleitet von StreamingPeer, implementiert die abstrakten Methoden empfangeNachrichten(), sendeNachrichten() und repariereOverlay() nach
den Vorgaben des Protokolls.
68
5.4. MODULE
KAPITEL 5. IMPLEMENTIERUNG
5.4.5 Hauptmodule eines Streamingpeers
Für die CoolStreaming-Implementierung im Rahmen dieser Arbeit war es wichtig, die
Logik vom Peer in die Module zu verlagern, um so einen übersichtlichen Peer zu erhalten und die komplexen Teile auÿerhalb von P2PNetSim testen zu können. Neben den
CoolStreaming-Modulen Membershipmanager und Partnershipmanager wurde als weiteres Modul der Datenmanager konzipiert (siehe auch Abbildung 5.2).
Während der Streamingpeer Nachrichten versendet und empfängt, erfolgt die Verarbeitung der Nachrichten in den Modulen Datenmanager, Partnershipmanager oder Membershipmanager. Die Module übernehmen damit die Hauptaufgaben jedes CoolStreamingPeers, d.h. die Datenwiedergabe (Playback), den Datenaustausch und die Wartung des
Overlays, siehe Abbildung 5.3.
Aufgaben des CoolStreaming-Peers
Hauptmodule im Streamingpeer
Datenwiedergabe
Datenmanager
Datenaustausch
Membershipmanager
Overlaywartung
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 als
auch der Partnershipmanager zuständig. Der Membershipmanager speichert die partielle
Sicht auf das Overlay, d.h. er kennt Peers im Netzwerk. Über den Partnershipmanager
werden 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 in
einer eigenen Datenstruktur, dem mCache (Kurzform von Membership-Cache):
M CACHEPi ⊂ V
Da der Peer
Pi
sich selbst nicht in seinem
M CACHEPi
speichert, stellt der mCache
stets eine echte Teilmenge der Peers im Netzwerk dar. Der mCache bietet dem Peer eine
partielle Sicht auf das P2P-Overlay. Für den Aufbau und Erhalt dieser partiellen Sicht
ist der Membershipmanager zuständig.
69
5.4. MODULE
KAPITEL 5. IMPLEMENTIERUNG
Partnershipmanager
Der Partnershipmanager baut Partnerschaften auf und verwaltet
diese. Die Menge der Partner des Peers
Pi
kann deniert werden als:
P ART N ERPi ⊆ M CACHEPi ⊂ V
Die Menge der Partnerschaftsbeziehungen
EPi
des Peers
Pi
stellen eine Teilmenge aller
Partnerschaftsbeziehungen im Netzwerk dar:
EPi ⊆ E
Datenmanager
Der Datenmanager regelt die Datengenerierung, den Datenaustausch,
die Speicherung der Datensegmente im Puer sowie die Datenwiedergabe. Nur der Datenmanager kann direkt auf Puer, Player und Scheduler zugreifen.
Von den zentralen koordinierenden Klassen
Modul) und
AbstractPartnershipManager
AbstractDatenManager
(im Datenmanager-
(im Partnershipmanager-Modul) ist jeweils
eine Klasse für die Quelle und eine für gewöhnliche Peers abgeleitet (siehe Abbildung
5.4).
Abbildung 5.4: Klassendiagramm der Hauptmodule
Jedes der drei Hauptmodule Datenmanager, Partnershipmanager und Membershipmanager 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 betreen.
70
5.4. MODULE
KAPITEL 5. IMPLEMENTIERUNG
5.4.6.1 Die Klasse DatenManager
Die Klasse
DatenManager
dient als Verbindungsglied zwischen dem Streamingpeer und
Puer, Player, Scheduler. Sie kontrolliert die Zugrie auf den Puer, die Übergabe der
Segmente an den Player und die Ausführung des Schedulers. Bei Aufruf des Schedulers
übergibt das
DatenManager-Objekt die IDs von den fehlenden Segmenten. Dabei werden
nur die fehlenden Segmente berücksichtigt, die bisher noch nicht angefordert wurden, um
so doppelte Datenrequests zu vermeiden.
5.4.6.2 Die Klasse P2PStream
Ein Stream ist eine ununterbrochene Folge von Segmenten. In der vorliegenden Imple-
P2PStream implementiert, die eine Folge
StreamSegment mit eindeutiger fortlaufender Nummer
mentierung wurde der Stream in der Klasse
gleich groÿer Segmente vom Typ
verwaltet.
Zu Simulationsbeginn initialisiert die Quelle den Stream. Da nach [ZL+05] jedes Segment
eine Sekunde Video umfasst, lässt das
DatenManager-Objekt der Quelle pro Sekunde ein
neues Segment erzeugen.
In einem Single-Source-P2P-Streaming-System kann die Quelle beim Zugri auf das
nächste Streamsegment dieses direkt löschen. Für ein zu implementierendes Multi-SourceSystem, bei dem mehrere Quellen denselben Stream verteilen, müssten der Stream an
zentraler 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 Bytes
ist variabel und richtet sich nach der Streamingrate.
In der vorliegenden Implementierung wurde das Segment in der Klasse
umgesetzt. Jedes
segment_id),
StreamSegment-Objekt
StreamSegment
hat eine eindeutige fortlaufende Nummer (int
kennt die ID des Streams (int
Erstellung in Sekunden
stream_id) und den Zeitpunkt seiner
(double creation_time). Aufgrund der im Internet üblichen
Streamingrate von ca. 400 kbps [LGL08, PM08] wurde die Gröÿe des einsekündigen
Streamsegments in der Simulation auf 50 kB festgelegt. Dieser Wert kann geändert werden (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 übertragen
werden, muss die Nummerierung zyklisch erfolgen. Die Protokolle geben in der Regel
einen maximalen
Integer-Wert
an, nach dem es zu einem Rollback kommt, d.h. die
Nummerierung beginnt wieder bei 0. Ein CoolStreaming-Segment umfasst eine Sekunde
Video und eine
segment_id
kann maximal 2 Byte belegen, also höchstens den Wert
71
5.4. MODULE
KAPITEL 5. IMPLEMENTIERUNG
65535 annehmen. Nach 18 Stunden, 12 Minuten und 15 Sekunden kommt es also zu
einem Rollback, wobei die Autoren in der Protokollbeschreibung grob aufgerundet von
einem Rollback nach 24 Stunden sprechen [ZL+05].
Bei anderen Protokollen variiert die höchstmögliche Segmentnummer je nach Segmentgröÿe. GoalBit lässt z.B. eine Nummerierung von 0 bis
231
zu [BV+09]. Die Verwaltung
der zyklischen Nummerierung wurde der Übersichtlichkeit halber in die separate Klasse
SegmentID
ausgelagert, auf die nur die
P2PStream-Instanz
zugreift.
5.4.6.5 Die Klasse Puer
Die CoolStreaming-Autoren haben zum Puer nur bekanntgegeben, dass er in Form eines
Sliding-Windows organisiert ist und in Simulationen 60 bzw. 120 Segmente zu je einer
Sekunde Video umfasste [ZL+05].
Für die Implementierung des Puers in einem P2P-Live-Streaming-System empehlt es
sich, einen Ringpuer zu verwenden, da die Videodaten nur für einen kurzen Zeitraum im
Puer gespeichert werden müssen und ein Ringpuer ezient implementiert werden kann.
Der Ringpuer wurde durch ein Array aus standardmäÿig 60
realisiert, wobei die Puergröÿe verändert werden kann (siehe
Zwei Variablen (int
StreamSegment-Objekten
Konstante PUFFER_SIZE).
firstindex, int firstsegment_id) speichern jeweils den aktuellen
segment_id des ersten Ringpuer-Elements.
Index und die
Ein P2P-Live-Streaming-Puer muss auch ältere bereits abgespielte Videosegmente speichern, so dass diese älteren Segmente auf Anfrage noch ausgeliefert werden können. In
Anlehnung an [BM+09] habe ich mich entschieden, den Puer wie folgt zu organisieren
(siehe Abbildung 5.5):
Peerpuffer
6
7
8
... ... ... ...
33 34 35 36 37
39
41
PLAYBACK_POS = aktuelle Abspielposition
Quellpuffer
20 21 22
... ... ... ...
47 48 49
8 veraltetes, bereits abgespieltes Segment
41 neues, noch abzuspielendes Segment
Abbildung 5.5: Peerpuer und Puer der Quelle (PUFFER_SIZE=60)
Die Konstante
PLAYBACK_POS
gibt an, an welcher Stelle im Puer das aktuell abzuspie-
lende Segment liegt.
PLAYBACK_POS
wird deniert als:
PLAYBACK_POS=PUFFER_SIZE/2 - 1
Bei gewöhnlichen Peers liegt das nächste abzuspielende Segment immer in der Puermitte. Bei der Quelle liegt das aktuelle Segment am Ende des Puers, da der Quellpuer nur
72
5.4. MODULE
KAPITEL 5. IMPLEMENTIERUNG
halb so groÿ ist wie der Peerpuer.
PLAYBACK_POS wird auch verwendet, um das allererste
Segment an der richtigen Stelle im Puer zu speichern, d.h. bei den Peers in der Puermitte und bei der Quelle am Puerende. Beim Speichern des allerersten Segments werden
auch die Variablen
firstindex und firstsegment_id gesetzt. Alle Segmente, die später
eintreen, werden dann anhand dieser Variablen sortiert in den Puer eingefügt.
Der Zugri auf den Puer erfolgt über den Datenmanager, der neue Segmente einfügt
oder jeweils das älteste Segment aus dem Puer löscht, indem er den Ringpuer um ein
Segment nach links verschiebt.
5.4.6.6 Die Klasse Scheduler
Der Scheduler errechnet, von welchen Partnern und in welcher Reihenfolge fehlende Daten
angefordert 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
Scheduler.berechneSupplier()
DatenManager-Objekt
die
Scheduler-Methode
PartnerListe, die
auf und übergibt eine Kopie der
neben den Buermaps auch die geschätzten Uploadbandbreiten der Partner enthält.
Scheduler.berechneSupplier() liefert ein Objekt des Typs Supplier zurück. Supplier
verwaltet eine Hashtabelle, in der jeweils die Netzwerkadresse eines Partners auf die bei
ihm anzufordernden Segmente zeigt. Der Supplier für die fehlenden Segmente mit segment_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 Puer noch leer ist, muss der Scheduler zunächst ermitteln,
ab welcher Abspielposition, d.h. ab welcher
Klasse
FirstOffset
segment_id,
er Daten anfordern soll. Die
bietet dazu verschiedene Methoden an.
5.4.6.7 Die Klasse FirstOset
Ein neuer Knoten mit leerem Puer fordert anhand der Partner-Buermaps Daten an.
Dabei muss zunächst ein Oset gewählt werden, die
segment_id
des ersten Segments
der anzufordernden Datensequenz. CoolStreaming speziziert die Wahl nicht. Nach dem
Studium anderer Protokolle (z.B. [BM+09]) wurden folgende Möglichkeiten implementiert:
getMostFrequently(): Wähle den Oset, der bei den Partnern am häugsten vorkommt. Falls mehrere Osets gleich oft vorkommen, wähle den niedrigeren Wert
(d.h. die
segment_id
getSmallest():
des älteren Segments).
Wähle immer den niedrigsten Oset.
Die Implementierung weiterer Verfahren ist hier aufgrund der Kapselung möglich. Die
Wahl eines Osets per Zufall erachte ich in der Simulation nicht für sinnvoll, da dies die
Nachvollziehbarkeit und die Verizierbarkeit durch Modultests behindert.
Da die Abspielposition des nächsten abzuspielenden Segments (PLAYBACK_POS) in der
Mitte des Puers liegt, muss der Oset (Variable
geben werden (offset
+ PLAYBACK_POS).
73
offset)
ab dieser Position zurückge-
5.4. MODULE
KAPITEL 5. IMPLEMENTIERUNG
5.4.6.8 Die Klasse Player
Die Klasse
Player
dient dazu, die Wiedergabe eines Segments zu simulieren. Nach
Protokollspezikation wurde der Start der Wiedergabe zunächst auf 10 Sekunden nach
Erhalt des ersten Segments gesetzt. Dieser Wert wurde später aus Optimierungsgründen
erhöht (siehe Abschnitt 6.2).
Player
wurde so einfach wie möglich gehalten und von den restlichen Klassen gekapselt
segment_id (Variable int playback_point)
double playback_time) des nächsten abzuspielenden Segments. Beide Werte (playback_point, playback_time) kann die
Player-Instanz zurück liefern.
implementiert. Die Klasse kennt lediglich die
und den Abspielzeitpunkt in Sekunden (Variable
Der Zugri auf
Player
erfolgt nur über die Klasse
DatenManager und dessen doPlay()DatenManager-Objekt die Variable
Methode. Zur Wiedergabe eines Segments liest das
playback_point
aus, holt das entsprechende Segment aus dem Puer und übergibt es
dem Player durch Aufruf von
Player.play(StreamSegment segment).
Ist das abzu-
Player
eine Fehlermeldung aus. Dann inkrementiert Player die Variablen playback_point und
playback_time jeweils um 1, da pro Sekunde ein Segment abgespielt wird.
spielende Segment nicht im Puer und kann nicht wiedergegeben werden, gibt
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 der
Erzeugung dem Abspielzeitpunkt (playback_time) entspricht.
Nach der Wiedergabe eines Segments verschieben das
DatenManagerQuelle-Objekt
DatenManager-Objekt
und das
den Ringpuer um ein Segment nach links.
5.4.7 Das Paket partnershipmanager
Der Partnershipmanager baut Partnerschaften zu anderen Peers im Netzwerk auf, indem
er TCP-Verbindungen zu diesen Peers erstellt. Er verwaltet die Partner in einem Objekt
der Klasse
PartnerListe.
5.4.7.1 Die Klasse Partner
Zu jedem Partner werden folgende Werte gespeichert: die Netzwerkadresse, die aktuelle
Buermap, die geschätzte Uploadbandbreite, die Anzahl der gelieferten Segmente und
der Zeitpunkt, seitdem der Partner aktiv ist.
Die geschätzte Uploadbandbreite stellt hier einen sehr wichtigen Aspekt dar, da der Scheduler auf die Bandbreitenschätzung zurückgreift. Wird die Bandbreite eines Partners unterschätzt, fordert der Scheduler bei diesem zu wenig Segmente an und die zur Verfügung
stehende Bandbreite wird schlecht genutzt. Bei einer zu hoch veranlagten Bandbreite,
kann ein Partner mit Segmentanforderungen überschwemmt werden. Obwohl die Qualitä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
5.4. MODULE
KAPITEL 5. IMPLEMENTIERUNG
wurde mir mitgeteilt, dass die Bandbreite anhand der Übertragungsrate der Datensegmente ermittelt wird.
Bandbreitenschätzung
Ich habe daher drei mögliche Verfahren erkundet, um aufgrund
dieser 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 jene
Partner, bei denen weniger Segmente angefordert werden und die daher weniger
Segmente schicken. Auch wenn sie die angeforderten Segmente in kürzestmöglicher
Zeit senden, erhöht dies nicht merklich ihre geschätzte Uploadbandbreite, da immer
der Gesamtzeitraum betrachtet wird.
Es wird nicht der gesamte Zeitraum der Partnerschaft betrachtet, sondern lediglich
die Zeit zwischen Anforderung und Eingang der Segmente. Das erhaltene Datenvolumen 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 Lieferzeit) gesetzt wird. Schickt ein Partner ein Segment, so kann anhand der Latenz
neuebandbreite
berechnet werden. Unter Berücksichtigung eines Gewichtungsfaktors G wird aus
der soeben ermittelten Bandbreite (neuebandbreite) und der vorherigen Bandbreite (altebandbreite) die tatsächliche Bandbreite nach folgender Formel geschätzt:
(neuebandbreite ∗ (1 − G)) + (altebandbreite ∗ G). Der Gewichtungsfaktor G
kann zwischen 0 und 1 liegen. Je niedriger G ist, desto stärker wird die neue Bandund der Segmentgröÿe die aktuelle Bandbreite des Partners als
breite bei der Schätzung berücksichtigt.
Das letzte Verfahren bietet vor allem den Vorteil, dass sich Änderungen bei der Uploadkapazität eines Partners (wenn z.B. neue Partner hinzukommen oder Partner entfallen)
schnell in der ermittelten Uploadbandbreite widerspiegeln. Daher habe ich dieses Verfahren implementiert.
5.4.7.2 Die Klasse PartnerListe
Der Partnershipmanager trägt neue Partner in ein Objekt der Klasse
ein, welche die Partner in einer
ArrayList
PartnerListe
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 eingetroen
sind, werden beim nächsten Scheduler-Aufruf bei einem der verbleibenden Partner angefordert.
5.4.8 Das Paket membershipmanager
Die zentrale Aufgabe des Membershipmanagers ist die Verwaltung einer partiellen Sicht
auf das P2P-Streaming-Netzwerk, d.h. auf den mCache. Informationen über aktive Peers
werden dazu im mCache gespeichert.
75
5.4. MODULE
KAPITEL 5. IMPLEMENTIERUNG
Die Peers erstellen regelmäÿig eine sogenannte Membership-Message, die eine fortlaufende Sequenznummer enthält sowie die Netzwerkadresse, die aktuelle Partneranzahl und die
TTL dieser Nachricht. Die TTL gibt an, wie lange die Informationen der Nachricht gültig sind. Die Peers schicken die erstellte Membership-Message an einen zufällig aus dem
mCache ausgewählten Knoten. Erhält ein Peer eine Membership-Message eines anderen
Knotens, leitet er sie auch an einen zufälligen mCache-Knoten weiter.
Verlässt ein Peer das Netz, erstellt er eine Departure-Message. Diese unterscheidet sich
von 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
das Overlay (dem mCache) und die Klasse
MembershipCache mit der partiellen Sicht auf
MembershipManager, die die Zugrie des Peers
auf den mCache verwaltet.
5.4.8.1 Die Klasse MembershipCache
Der mCache speichert zu jedem Knoten maximal einen Eintrag. Zusätzlich zu den Informationen aus der Membership-Message (Sequenznummer, Netzwerkadresse, Partneranzahl, TTL) werden die Zeit des letzten Zugris (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 in
den 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 die
aktuelleren und zudem noch gültig sind. Dazu muss die Sequenznummer in der Nachricht
gröÿer als die gespeicherte sein und die TTL der Nachricht gröÿer als 0. Nur in diesem
Fall wird der Eintrag im mCache aktualisiert. Alle Werte aus der Nachricht werden
übernommen und zusätzlich die aktuelle Zeit als
lastupdatetime gespeichert. Erhält der
Peer 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-Nachricht
schicken. Dadurch kann die Quelle zu Simulationsbeginn ihren mCache schnellstmöglich
mit Partnerkandidaten befüllen. Gewöhnliche Peers speichern die erhaltenen Partnerkandidaten in ihrem mCache. Zudem tragen Quelle und Peers die Absender von eingehenden
TCPSYN-Nachrichten in den mCache ein, sofern sie die Partnerschaftsanfrage annehmen
und auf das erhaltene TCPSYN mit TCPACK antworten. Es ist nicht ratsam, bei jeder eingehenden TCPSYN-Nachricht deren Absender zu speichern, da dies unnötigen
Overhead verursachen würde.
5.4.8.2 Die Klasse MembershipManager
MembershipManager
erstellt Membership-Messages oder Departure-Messages und sucht
einen zufälligen Empfänger aus dem mCache aus. Darüber hinaus bearbeitet er eingehende Gruppennachrichten, leitet sie weiter und liefert dem Peer eine Liste von möglichen
neuen Partnern aus dem mCache.
76
5.4. MODULE
KAPITEL 5. IMPLEMENTIERUNG
Eine Membership-Message wird nur weitergeleitet, falls die Informationen in der Nachricht noch gültig sind, d.h. falls die TTL gröÿer 0 ist. Möchte ein Knoten eine erhaltene Membership-Message weiterleiten, aktualisiert er zuerst die TTL des dazugehörigen
Eintrags im mCache. Dazu berechnet er die Zeit, die seit dem letzten Zugri auf den
mCache-Eintrag vergangen ist, und zieht diese von der gespeicherten TTL ab. Daraus
ergibt sich die verbleibende Gültigkeitsdauer für die Knoteninformation. Bei einer TTL
kleiner oder gleich 0 wird dieser Eintrag aus dem mCache gelöscht und die Nachricht
wird nicht weitergeleitet.
Der Empfänger einer Departure-Message löscht den mCache-Eintrag des abgegangenen
Knotens und leitet die Nachricht weiter, sofern er diese DepartureMessage zum ersten
Mal erhalten hat. Falls der Empfänger zu einer empfangenen Departure-Message keinen
mCache-Eintrag ndet, hat er entweder die gleiche Nachricht schon in einem früheren
Simulationsschritt erhalten (und den Eintrag gelöscht) oder er hatte nie einen mCacheEintrag zu diesem Knoten. In beiden Fällen (DepartureMessage nicht im mCache) leitet
der Empfänger die Nachricht nicht weiter. So kann verhindert werden, dass Nachrichten
in Loops im Netzwerk weitergeleitet werden.
5.4.9 Das Paket util
Die Klassen im Paket
util sind nicht an die vorliegende CoolStreaming-Implementierung
gebunden. Sie können unabhängig von dieser verwendet werden und stellen grundlegende
Funktionalitä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
erweitert den
P2PNetSimLogger
MyLogger
um die Möglichkeit des Loggens in fünf verschiedenen
Logleveln 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,
welche
durch ihre numerische Entsprechung (0-4) gesetzt werden.
Eine Klasse, die Logmeldungen ausgeben und ihren eigenen Loglevel verwalten soll, benötigt ein eigenes
MyLogger-Objekt.
Bei der Entwicklung neuer Klassen hat sich dies als
sehr hilfreich erwiesen. Während der Entwicklung einer Klasse werden beispielsweise alle
Meldungen einschlieÿlich
DEBUG
ausgegeben, bei der fertiggestellten Klasse dagegen nur
noch Meldungen gröÿerer Wichtigkeit (z.B. ab
ERROR).
MyLogger-Konstruktor erhält eine Referenz auf ein Objekt der P2PNetSim-Klasse
P2PNetSimLogger, den Loglevel als int-Wert, die Peeradresse als String sowie den Name der loggenden Klasse als String. Zu Beginn jedes Simulationsschrittes setzt die
StreamingPeer-Instanz den Wert der statischen Variable MyLogger.logsimtime auf die
Der
aktuelle Simulationszeit, so dass diese zusammen mit den vergangenen Sekunden in allen
Logmeldungen ausgegeben werden kann. Eine
Aufbau:
77
MyLogger-Logmeldung
folgt einem festen
5.4. MODULE
KAPITEL 5. IMPLEMENTIERUNG
<LOGLEVEL> <Simulationszeit als simtime/in Sekunden>: <Peer-Adresse> <Logmeldung> (<loggende Klasse>)
Die Klasse
Player
gibt z.B. immer eine
ERROR-Logmeldung
aus, falls ein Segment nicht
vor dem Abspielzeitpunkt eintrit und es daher zu einem Aussetzer kommt. Falls beispielsweise der Peer mit Netzwerkadresse 1.0.0.2/32 das Segment mit
segment_id=41
(=playback_point) nicht abspielen kann, erscheint folgende Logmeldung:
ERROR
: 1.0.0.2/32 AU SSET ZER bei playbackpoint = 41
| {z } 200/20.0sec
{z
}
{z
} | {z } |
|
Loglevel
Logmeldung
Simulationszeit P eer−Adresse
(P layer)
| {z }
Loggende Klasse
5.4.9.2 Die Klasse Bandbreitenregulator
CoolStreaming berücksichtigt die Partnerbandbreite bei der Anforderung fehlender Segmente. 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 Simulationsschritt zugestellt und pro Simulationsschritt kann ein Peer beliebig viele Nachrichten empfangen. In Version 3.0 ist theoretisch eine Bandbreitenbegrenzung vorgesehen,
indem man die maximale Uploadbandbreite als Parameter
maximale Downloadbandbreite als
OutgoingBandwidth bzw. die
IncomingBandwidth in der XML-Kongurationsdatei
Message.setContent(String
setzt und die Nachrichtengröÿe implizit durch Aufruf von
groesse)
übergibt. Als Problem erwies sich, dass bei der Bandbreitenbegrenzung von
P2PNetSim die Lieferzeit von Nachrichten nicht nachvollziehbar variiert. Auch erwies sich
Message.content-String als nicht praktikadaher durch die Klasse Bandbreitenregulator
die Abbildung der Nachrichtengröÿe auf den
bel. Die Bandbreitenbegrenzung wurde
realisiert.
Der Bandbreitenregulator wirkt zwischen dem Empfang bzw. Versand einer Nachricht
receive() bzw. send() und dem tatsächlichen
StreamingPeer-Instanz (siehe Abbildung 5.6).
mit den P2PNetSim-eigenen Methoden
Zugri auf die Nachrichten durch die
Die
StreamingPeer-Instanz initialisiert je ein Bandbreitenregulator-Objekt für Down-
load und Upload. Dadurch werden eine Eingangsqueue und eine Ausgangsqueue für Nachrichten angelegt. Die Werte für die Bandbreitenbegrenzungen können mittels der Parameter
upload_bandbreite
und
download_bandbreite
in der XML-Kongurationsdatei
deniert 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 Simulationsschrittes wird die Methode
doSend()
ausgeführt, die so viele Nachrichten aus der
Ausgangsqueue verschickt, wie es die Uploadbandbreite des Peers erlaubt. Alle Nachrichten, die in einem Simulationsschritt nicht verschickt werden konnten, verbleiben in der
Queue zum Versand in späteren Simulationsschritten.
Zu Beginn jedes Simulationsschrittes werden alle eingegangenen Nachrichten durch Aufruf der Methode
doReceive()
in der Eingangsqueue gespeichert.
78
myreceive()
liefert
5.4. MODULE
KAPITEL 5. IMPLEMENTIERUNG
StreamingPeer.doReceive():
Empfang aller Messages mit receive()
zu Beginn des Simulationsschritts
StreamingPeer.mysend():
StreamingPeer sendet Message
Bandbreitenregulator
verwaltet Messages in Queue
StreamingPeer.doSend():
Tatsächlicher Message-Versand mit send()
am Ende des Simulationsschritts
Abbildung 5.6: Zusammenspiel zwischen
StreamingPeer.myreceive():
StreamingPeer empfängt Message
Bandbreitenregulator
und
StreamingPeer
dem Peer jeweils eine Nachricht aus der Eingangsqueue zurück, sofern noch genügend
Downloadbandbreite zur Verfügung steht. Analog zum Versand bleiben nicht empfangbare Nachrichten in der Queue.
Zum Empfang und Versand von Nachrichten ruft der Peer also anstatt der P2PNetSimMethoden
Methoden
Methoden
receive() bzw. send() die Methoden myreceive() bzw. mysend() auf. Die
myreceive() und mysend() haben die gleiche Signatur wie die P2PNetSimreceive() 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 der
Konstante
SIMSCHRITTE_PRO_SEC
deniert. Eine Sekunde sollte nach meiner Erfahrung
möglichst aus 10 Simulationsschritten bestehen.
Die Methode
getSimtime(double sec)
bildet alle Zeitangaben in Sekunden aus der
Konguration auf Simulationsschritte ab. Intern wird die Zeit in Simulationsschritten
übergeben. Für die Ausgabe werden Simulationsschritte wieder in Sekunden umgerechnet.
Die Umrechnungen bieten folgende Vorteile:
Die Zeitangaben sind menschenlesbar. Das gilt für Logmeldungen als auch für die
Angaben in der Konguration (z.B. Bandbreitenbegrenzung für Upload und Download in Bytes pro Sekunden).
Die in der Protokollspezikation denierten Zeitangaben in Sekunden können direkt
implementiert werden (z.B. die Wiedergabe eines Segments pro Sekunde).
Indem die Peers ihre Aktionen in Intervallen aus Sekunden durchführen (und nicht
in Intervallen aus Simulationsschritten), werden die Aktionen zeitlich voneinander entzerrt. Dies gestaltet die Logmeldungen übersichtlicher und vereinfacht die
Fehlersuche.
79
5.5. TEST
KAPITEL 5. IMPLEMENTIERUNG
Beim Nachrichtenversand können Verzögerungen simuliert werden, die kürzer sind
als eine Sekunde. Dies ist insbesondere für die Implementierung des TCP-Handshakes wichtig und den Versand der nur wenige Bytes groÿen TCPSYN- und
TCPACK-Segmente.
5.4.9.4 Die Klasse StreamingAddress
Für die Implementierung wurde mehrfach ein Set aus Netzwerkadressen benötigt. Bei Verwendung 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, die
equals()-Methode überschrieben, wobei der Vergleich zweier Adressen mit Hilfe der
Darstellung als long-Wert erfolgt (Address.getAddressAsLong()). Die Netzwerkadressen 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 in
allen anderen Klassen der Implementierung zugegrien 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 -korrekturen
führen dazu, dass ein Projekt auch nach scheinbarer Fertigstellung nicht abgeschlossen
werden kann. Nicht selten benutzen Entwickler Tests nur dazu, die Fehlerfreiheit ihres
Codes zu demonstrieren. Man hot, dass der Test erfolgreich durchläuft und die mühsame
Fehlersuche entfällt.
Tatsächlich ist der Sinn von Tests ein anderer. Myers fasst in [Mye04] die Bedeutung des
Testens folgendermaÿen zusammen:
Testing is the process of executing a program with the intent of nding
errors.
Ungetestete Programme sind mit an Sicherheit grenzender Wahrscheinlichkeit fehlerhaft.
Je eher diese unentdeckten Fehler gefunden werden, desto schneller und einfacher lassen
sie sich beheben. Darüber hinaus erhöhen regelmäÿige Test das Vertrauen des Entwicklers
in die Richtigkeit seines Codes und damit seine Bereitschaft, Anpassungen und Erweiterung im Code vorzunehmen.
Die Entwicklung eines Systems sollte mit dem Test einzelner Modul (Modultests/UnitTests) beginnen und im späteren Verlauf weitere Tests vorsehen, z.B. den Test der Integration der Komponenten in das Gesamtsystem und Performancetests. [Mye04]
80
5.5. TEST
KAPITEL 5. IMPLEMENTIERUNG
5.5.2 Modultests
Bereits in 5.1 wurde die Wichtigkeit von regelmäÿigen Modultests betont, die auÿerhalb von P2PNetSim durchgeführt werden. Für jede kritische Funktion sollten Testfälle
deniert 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 deniert
werden. 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 System
aber eine gewisse Gröÿe hat und aufgrund neuer Informationen refaktorisiert werden
muss, ermöglichen Unit-Tests eziente Anpassungen. Nach jeder Änderung kann man
Unit-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. Die
Zeitersparnis durch Unit-Tests wächst dabei mit der Gröÿe des Programms.
Gute Unit-Testprogramme sollten nach [Mar09] folgende Eigenschaften haben:
Unabhängigkeit
Wiederholbarkeit
Die Testprogramme sollten unabhängig voneinander auszuführen sein.
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 herauszunden, 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 Beck
und Eric Gamma während eines gemeinsamen Flugs nach Atlanta entwickelt. Beck wollte
Java lernen und Gamma interessierte sich für Becks Testframework in Smalltalk. Sie nutzten 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 zu
einer zu testenden Klasse erstellen. Wie in 5.5.2 gefordert, kann die Testklasse unabhängig
von 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 Klasse zugegrien werden kann, d.h. Methoden mit den Modikatoren
oder
public.
protected, default
assertEquals() und assertTrue() bzw. assertFalse() ermöglichen
boolean-Rückgabewerte. Es empehlt sich hier, stets assertEquals() zu ver-
Die Methoden
Tests auf
wenden, da diese Methode die Möglichkeit bietet, Ausgaben zu denieren für den Fall,
81
5.5. TEST
KAPITEL 5. IMPLEMENTIERUNG
dass ein Test fehlschlägt. Hier ein Beispiel für eine Methode, die die Klasse
Puffer testet
und prüft, ob der Puer nach dem Löschen aller Puersegmente 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ührten Änderungen (Umbenennung von Variablen oder Methoden) erfolgen auch in den
Testklassen. Die Namen der Testmethoden verändern sich nicht. Beim Verschieben von
Dateien muss die Paketstruktur in dem Testpaket manuell angepasst werden.
Unter Umständen sind Stubs zu erstellen, d.h. Klassen, die vom Testobjekt anstelle des
eigentlichen Objekts aufgerufen werden. Dies ist in der vorliegenden Implementierung
bei den Klassen erforderlich, die separat loggen und ein
MyLogger-Objekt im KonstrukMyLogger-Klasse eine Klasse
Interface P2PNetSimLogger im-
toraufruf instanziieren. Hier habe ich als Ersatz für die
TestLogger
innerhalb des Testpakets angelegt, die das
plementiert. Logmeldungen werden beim Testdurchlauf auf der Standardausgabe ausgegeben.
5.5.2.2 Exemplarischer Testfall
Der Scheduler ist eine zentrale, sehr komplexe Komponente, die man nur mit Hilfe von
Modultests gründlich testen kann. Daher erstellte ich folgenden Testfall, der als Vorlage
für die Implementierung der Testmethoden diente.
Der Scheduler ermittelt vorab, bei welchen Partnern fehlende Segmente angefordert werden. Partner, die ein gesuchtes Segment liefern können, sind potentielle Supplier für dieses
Segment.
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. Im
Realfall werden die Partner-Buermaps ausgewertet. Im Testfall wurde die Segmentverfügbarkeit generisch auf die Partner verteilt: Partner 0 hat alle Segmente, Partner 1 hat
jedes zweite Segment, Partner 2 jedes dritte, Partner 3 jedes vierte und Partner 4 jedes
fünfte Segment verfügbar. In Abbildung 5.7 ist die Segmentverfügbarkeit tabellarisch
dargestellt.
Im nächsten Schritt sortiert man die fehlenden Segmente nach der Häugkeit ihrer Verfügbarkeit (Rarest-First). Die am seltensten verfügbaren Segmente sollen zuerst erscheinen
und damit zuerst vom Scheduler bearbeitet und angefordert werden.
In meinem Testfall erhält man damit folgende sortierte Liste mit IDs fehlender Segmente:
0,6,1,2,4,8,3,5,7,9 (siehe 1.Spalte
seg_id
in der mittleren Scheduling-Tabelle in
Abbildung 5.8)
Neben dieser Liste benötigt der Scheduler weitere Eingaben:
82
5.5. TEST
KAPITEL 5. IMPLEMENTIERUNG
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): Anhand
der Bandbreite in kB/sec errechnet der Scheduler, wie viele Sekunden ein potentieller Supplier benötigt, um ein einzelnes Segment zu verschicken (siehe Spalte
sec_segment[part_id]
deadline
in der obersten Tabelle in Abbildung 5.8).
(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 werden
muss, damit es rechtzeitig abgespielt werden kann. Segment 0 hat also eine Deadline
von 2, Segment 1 eine Deadline von 3 usw. (siehe Spalte
deadline
in der mittleren
Scheduling-Tabelle in Abbildung 5.8)
restzeit[part_id][seg_id] (Restliche Zeit, die einem Partner part_id zur Lieseg_id verbleibt): Initial entspricht die Restzeit von Segment
seg_id der Deadline dieses Segments. Wird ermittelt, dass Partner part_id das
Segment 0 liefern soll, so hat Partner part_id weniger Bandbreite für die Lieferung der übrigen 9 Segmente. Die Restzeit von Partner part_id für alle folgenden
ferung von Segment
Segmente wird dekrementiert, und zwar um die Zeit, die er zur Lieferung von
Segment 0 benötigt (siehe Spalten
restzeit[part_id][seg_id]
in der mittleren
Scheduling-Tabelle in Abbildung 5.8).
Im letzten Schritt ermittelt der Scheduler aus der Menge der potentiellen Supplier den
tatsächlichen Supplier. In der mittleren Scheduling-Tabelle aus Abbildung 5.8 sind dazu
alle 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 nach
folgendem Algorithmus vor:
part_id für das fehlende
part_id an. Dekrementiere
Gibt es nur einen potentiellen Supplier
dann fordere Segment
part_id
seg_id
bei
seg_id,
die Restzeit von
für alle verbleibenden fehlenden Segmente.
Gibt es mehrere Supplier für Segment
ner
Segment
part_id
seg_id, dann fordere seg_id bei dem Part-
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. Dekrementiere 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üner
Schriftfarbe auf gelber Markierung ersichtlich. Der Algorithmus ndet in meinem Testfall für jedes Segment einen Supplier (siehe auch letzte Spalte
Scheduling-Tabelle aus 5.8).
83
supplier
in der mittleren
Abbildung 5.8: Testdaten für Scheduling-Algorithmus
5.5. TEST
KAPITEL 5. IMPLEMENTIERUNG
84
5.6. VERIFIKATION
KAPITEL 5. IMPLEMENTIERUNG
Der Scheduler gibt eine Liste von Suppliern mit den bei ihnen anzufordernden Segmenten
zurück. Die Liste ist so sortiert, dass zuerst bei den Suppliern angefragt wird, die die
seltensten Segmente haben (siehe unterste Tabelle in 5.8).
5.6 Validierung und Verikation
Ein wichtiger Schritt zum Abschluss von Softwareprojekten ist die Validierung bzw. die
Verikation des entwickelten Systems. Dabei ist zwischen den Begrien Validierung und
Verikation zu dierenzieren.
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 Umfeld
wird getestet, ob das entwickelte Produkt den Anforderungen und Wünschen des Kunden
entspricht. Es wird sozusagen gegen die Erwartungen des Kunden validiert. Der Kunde
ist auch am Validierungsprozess beteiligt. Validierungen werden dann durchgeführt, wenn
keine konkrete Spezikation oder kein Prototyp vorliegt.
Verikation
Die zentrale Frage lautet:
Wurde das System richtig entwickelt?
Hier wird
das Ergebnis der Entwicklung gegen die Spezikation geprüft. Dies ist machbar, falls eine
konkrete Spezikation oder ein Prototyp vorliegen. Analytiker, Entwickler und Tester
führen die Verikation durch.
Für das CoolStreaming-Protokoll liegt eine Spezikation vor. Die Angaben der Autoren
aus [ZL+05] können zur Verikation der Implementierung verwendet werden.
Formale Verikationen prüfen die Korrektheit mit Hilfe eines Verikationskalküls. Dies
ist sehr aufwändig und nicht realisierbar für ein Programm dieser Gröÿe. Die Verikation erfolgt daher anhand der Angaben der CoolStreaming-Autoren und wird in den
Implementierungsprozess eingebunden.
Abbildung 5.9 zeigt, wie die Verikation in den Entwicklungsprozess integriert ist. Eine
neue Komponente wird durch einen eigenen Modultest (JUnit-Komponententest) überprüft. Die Komponente wird solange getestet und überarbeitet, bis sie sich gemäÿ der
Spezikation und gemäÿ eigener Designentscheidungen korrekt verhält.
Ist die Entwicklung dieses einzelnen Moduls so weit abgeschlossen, dass es in die Simulationsumgebung integriert werden kann, erfolgt ein Integrationstest durch Aufruf von
P2PNetSim und Abgleich der Ergebnisse anhand der Logmeldungen. Dafür sind aussagekräftige Logmeldungen notwendig.
Schlieÿlich kann man die Korrektheit der Implementierung mit Hilfe des Benchmarksystem SimBench überprüfen. Der von SimBench generierte Verbindungsgraph kann zum
einen Aufschluss über die Qualität der Partnerschaftsbeziehungen geben. Wird ein Peer
anhand der Logmeldungen mit Anfragen überschwemmt, so lässt sich beispielsweise aus
dem 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 alle
Anfragen, da nach [ZL+05] die Segmente, die nur bei einem Partner vorliegen, sofort
85
5.6. VERIFIKATION
KAPITEL 5. IMPLEMENTIERUNG
Programmcode erstellen
JUnit-Komponententests
P2PNetSim-Integration
Integrationstest
Verifikation mit SimBench
Refaktorisierung
Verifikation abgeschlossen
Abbildung 5.9: Verikation der Implementierung
(und ohne Berücksichtigung der Bandbreite) angefragt werden. Zum anderen kann man
die Funktionsweise des gesamten Systems testen, indem man Performancetests durchführt
und die erhaltenen Ergebnisse mit den dokumentierten Testresultaten der Originalimplementierung vergleicht. Die Verikation erfolgt hier mittels statistischer Auswertungen
(siehe Abschnitt 6.2 im folgenden Kapitel). Die entsprechenden Metriken (Kontrolloverhead, Continuity-Index, Startup-Delay und Playback-Delay) wurden bereits im Abschnitt
4.4.2 vorgestellt.
86
6 Auswertung
In den vorangegangenen Kapiteln wurde CoolStreaming, ein P2P-Live-Streaming-Protokoll auf Mesh-Pull-Basis, vorgestellt und analysiert. Im Rahmen der Analyse habe ich
CoolStreaming mit anderen P2P-Live-Streaming-Protokollen verglichen und mögliche
Verbesserungen des CoolStreaming-Protokolls vorgeschlagen (siehe Abschnitt 4.6). In
Kapitel 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 diesem
Kapitel wird zunächst der Simulationsaufbau zur Durchführung der Benchmarktests beschrieben. Anschlieÿend werden die durchgeführten Optimierungen vorgestellt. Zum Abschluss werden aufgrund der Erfahrungen aus der CoolStreaming-Implementierung Rückschlü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 Initialisierungsphase 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ür
meinen Simulationsaufbau, in dem pro Simulationsschritt ein Peer das Netzwerk betritt
und alle Peers mit dem Netzwerk verbunden bleiben. Für die Auswertung ist es nicht
nötig, eine Streamdauer von 120 Minuten zu simulieren, da sich das System bereits nach
relativ kurzer Zeit stabilisiert. Daher lasse ich meine Simulationen über einen simulierten
Zeitraum von 1800 Sekunden (30 Minuten) laufen.
Für die Simulationsläufe sind folgende Parameter wichtig, die - soweit möglich - aus den
Angaben aus [ZL+05] abgeleitet wurden:
Peeranzahl: 200. Laut [ZL+05] nehmen maximal 200 Peers an einer Streamingsitzung teil.
Partneranzahl je Peer: 5. Bei einer Partneranzahl von 4 bis 6 Partnern pro Peer
wurde ein relativ hoher Continuity-Index (>0.983) gemessen. Daher begrenze ich
die maximale Partneranzahl auf 5 Partner pro Peer.
Uploadbandbreite je Peer: 100 kB/sec (abgeleitet aus ADSL-Upstream von 1
Mbps [FH07]).
Downloadbandbreite je Peer: 1 MB/sec (entspricht ADSL-Downstream von
mindestens 8 Mbps).
87
6.2. EVALUIERUNG UND OPTIMIERUNG
KAPITEL 6. AUSWERTUNG
Streamingrate: 50 kB/sec bzw. 400 kbps. 400 kbps ist die im Internet übliche
Streamingrate ([LGL08, PM08]), mit der auch das CoolStreaming-System betrieben wurde ([LX+08]). Die Streamingrate kann in meiner Implementierung geändert werden, indem das per Denition einsekündige Datensegment (Konstante
SEGMENT_SIZE)
mehr bzw. weniger Bytes umfasst.
Puergröÿe: 60 Segmente (entspricht 60 Sekunden Video) [ZL+05]. Der Puer
der Quelle ist mit 30 Segmenten halb so groÿ (siehe auch Abschnitt 5.4.4)
Gewichtungsfaktor für die Bandbreitenschätzung: 0,5. Der Scheduler fordert
anhand der geschätzten Partnerbandbreite bei den Partnern Segmente an, siehe
Abschnitt 5.4.7.1. Ich berücksichtige bei dieser Schätzung einen Gewichtungsfaktor
zwischen 0 und 1. Je näher der Gewichtungsfaktor an 0 liegt, desto schneller werden
längere bzw. kürzere Lieferzeiten bei der geschätzten Bandbreite berücksichtigt. Der
Gewichtungsfaktor von 0,5 hat sich in der Simulation bewährt, da sich einerseits
die Bandbreitenschätzung schnell genug dem tatsächlichen Wert annähert, aber
andererseits einzelne Ausreiÿer (d.h. einzelne Segmente, die sofort oder mit groÿer
Verzö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 Metriken Continuity-Index (siehe Abschnitt 4.4.2) und Kontrolloverhead (siehe Abschnitt
4.4.2) gemessen und die Ergebnisse in [ZL+05] veröentlicht. Meine CoolStreamingImplementierung wird durch Messung der genannten Metriken mit dem Original verglichen und liefert dabei vergleichbar gute Ergebnisse. Da die Protokollspezikation in
[ZL+05] weder ganz vollständig noch immer eindeutig ist, konnten diese guten Ergebnisse erst nach zwei hauptsächlichen Optimierungen erzielt werden, die in diesem Abschnitt
beschrieben 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ücksichtigt. Ist ein Segment nur bei einem Partner verfügbar, wird es bei diesem Partner
angefordert, auch falls er gemäÿ der Bandbreitenschätzung keine Uploadbandbreite mehr
zur Verfügung hat. Da die Protokollspezikation nicht vorsieht, dass ein Partner eingehende Anfragen verwirft, kann es zu einer Überlastung dieses Partners durch Anfragen
kommen. Das kann schlieÿlich dazu führen, dass ein Partner kein einziges angefordertes
Segment mehr rechtzeitig verschickt, da er weiterhin versucht, trotz fehlender Bandbreite
die eingehenden Anfragen nacheinander abzuarbeiten.
In der Simulation meiner Implementierung ist genau dieses beschriebene Szenarium aufgetreten. Abhängig von der zufälligen Verbindungsstruktur im Mesh gab es in den Simulationsläufen eine schwankende Anzahl von Partnern, die Segmente jeweils eher als andere
in ihrem Puer hatten und daher mehr Anfragen erhielten, als sie bearbeiten konnten.
Im Verlauf der einzelnen Simulationen konnten diese Partner schlieÿlich gar nicht mehr
zur Lieferung von Segmenten beitragen, was sich sehr negativ auf den Continuity-Index
88
6.2. EVALUIERUNG UND OPTIMIERUNG
KAPITEL 6. AUSWERTUNG
auswirkte. Der Anteil der nicht rechtzeitig erhaltenen Segmente (im Verhältnis zu den für
die 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. mehr
als die Hälfte des Streams wird nicht rechtzeitig empfangen und kann nicht abgespielt
werden.
Im Rahmen der ersten Optimierung des Systems habe ich also die Bandbreite der Partner
immer berücksichtigt. Auch Segmente, die lediglich bei einem Partner erhältlich sind, werden bei diesem nur angefordert, falls seine geschätzte Uploadbandbreite ausreicht. Diese
Optimierung brachte sofort sichtbare Verbesserungen. Der Continuity-Index verbesserte
sich auf 0,91 und kommt dem Continuity-Index der Original-Implementierung von 0,992
relativ nahe. Abbildung 6.1 zeigt den in zwei repräsentativen Simulationen gemessenen
Continuity-Index vor und nach dieser Optimierung.
Abbildung 6.1: Continuity-Index in Abhängigkeit von der Berücksichtigung der Partnerbandbreite
Die Tatsache, dass Peers überlastet werden können, wenn bei ihnen Segmente unabhängig
von der zur Verfügung stehenden Bandbreite angefordert werden, liegt auf der Hand und
wird durch die Messungen in der Simulation bestätigt. Da der Pseudocode des SchedulerAlgorithmus in der Protokollspezikation an einigen Stellen Ungenauigkeiten aufweist,
haben die Autoren möglicherweise nicht die tatsächlich umgesetzte Version des SchedulerAlgorithmus in [ZL+05] veröentlicht.
Beginn der Wiedergabe
Um den Continuity-Index und damit den Anteil der rechtzeitig
empfangenen Segmente weiter zu erhöhen, betrachtete ich bei der zweiten Optimierung
die Anfangsverzögerung (siehe auch Abschnitt 4.4.2). Von den CoolStreaming-Autoren
89
6.2. EVALUIERUNG UND OPTIMIERUNG
KAPITEL 6. AUSWERTUNG
Abbildung 6.2: Continuity-Index in Abhängigkeit vom Beginn der Wiedergabe
selbst ist nicht bekannt, welche durchschnittliche Anfangsverzögerung (zwischen dem
Betreten des Netzes und dem Beginn der Wiedergabe) gemessen wurde. Andere Quellen berichten von einer Anfangsverzögerung bei CoolStreaming von ca. 60 Sekunden
[LJ+06, OJ08]. Da nach der ersten Optimierung die gemessene durchschnittliche Anfangsverzögerung im Gegensatz dazu lediglich bei 20,2 Sekunden lag, lieÿ ich in meiner
Implementierung die Wiedergabe später beginnen. D.h. das Playback startet nicht 10
Sekunden nach Erhalt des ersten Segments, sondern 15 bzw. 20 Sekunden später (siehe
Abbildung 6.2).
Abbildung 6.2 zeigt den in repräsentativen Simulationen gemessenen Continuity-Index
in Abhängigkeit vom Beginn der Wiedergabe. Der Continuity-Index ist umso höher, je
später die Wiedergabe beginnt. Startet die Wiedergabe 20 Sekunden nach Erhalt des
ersten Segments, liegt der Continuity-Index durchschnittlich bei 0,9989. D.h. lediglich in
0,11% der Fälle werden Segmente nicht rechtzeitig empfangen und es kommt zu Aussetzern bei der Wiedergabe. Diese Verbesserung erklärt sich dadurch, dass den Peers mehr
Zeit zur Verfügung steht, um ihren Puer vor Wiedergabe-Beginn zu befüllen und um
die Bandbreite ihrer Partner anhand der erhaltenen Segmente realistischer einschätzen
zu können.
Bandbreitenschätzung
In Abbildung 6.2 erkennt man, dass der Continuity-Index in den
ersten 200 bis 400 Sekunden schwankt und spätestens ab 600 Sekunden recht konstant
ist. Die dafür verantwortliche Bandbreitenschätzung arbeitet mit Verzögerung (abhängig
vom Gewichtungsfaktor), um unabhängig von Ausreiÿern eine realistische Bandbreite zu
schätzen. Am Anfang werden daher von Partnern mehr bzw. weniger Segmente angefordert, 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 Bandbreitenschä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 angefordert werden und die Wiedergabe 20 Sekunden nach Erhalt des ersten Segments beginnt.
Mit diesen beiden Optimierungen konnte ich den Continuity-Index meiner Implementierung auf durchschnittlich 0,9989 erhöhen, wodurch er höher ist als der entsprechende
Continuity-Index der Original-Implementierung (0,992).
Die durchschnittliche Anfangsverzögerung (zwischen Join und Wiedergabebeginn) liegt
bei 30,6 Sekunden und die durchschnittliche Abspielverzögerung (zwischen Ausgabe des
Segments durch die Quelle und Wiedergabe) bei 28,7 Sekunden. Damit liegen sowohl
Anfangsverzögerung als auch Abspielverzögerung unter den in [OJ08] dokumentierten 60
Sekunden.
Der Kontrolloverhead ist mit 2,76% höher als in der Original-Implementierung (ca. 1,5%).
Die Dierenz lässt sich zum einen dadurch erklären, dass ich möglicherweise die Gröÿe
der Kontrollnachrichten in meiner Implementierung höher als notwendig veranschlagt habe. Zum anderen haben die CoolStreaming-Autoren vorgeschlagen, Kontrollnachrichten
an die Partner mit den Streamdaten im Payload zu verschicken, was das Volumen der
Kontrollnachrichten in der Original-Implementierung ebenfalls verringert [ZL+05].
6.3 Zusammenfassung
Mit CoolStreaming habe ich ein im Realbetrieb erprobtes P2P-Live-Streaming-Protokoll
auf Mesh-Pull-Basis umgesetzt. Meine Implementierung liefert Ergebnisse, die gemessen an der Original-Implementierung vergleichbar gut sind. Die Klasse
Zeit
hat sich bei
der Implementierung als sehr hilfreich erwiesen, da sich durch die Umrechnung von Simulationsschritten in Sekunden die Ergebnisse meiner Implementierung mit denen der
Original-Implementierung direkt vergleichen lassen. Die Klasse
Bandbreitenregulator
war relativ aufwändig zu implementieren, ohne sie wäre die Evaluierung des Protokolls
jedoch nicht möglich gewesen. Der Scheduler-Algorithmus von CoolStreaming basiert
hauptsächlich darauf, dass die Bandbreite korrekt eingeschätzt wird. Über die Bandbreitenschätzung ist leider nichts veröentlicht und die Autoren hielten sich bei Nachfrage
auch bedeckt. Die von mir implementierte Bandbreitenschätzung liefert nach einer relativ
kurzen Anlaufphase zuverlässig realistische Schätzungen, wie sich aus den Ergebnissen
aus der Simulation ersehen lässt.
Bewertung der Optimierung
In meiner Implementierung des CoolStreaming-Protokolls
werden Segmente immer nur dann angefordert, wenn die geschätzte Bandbreite des Senders ausreicht. Dadurch kann es zwar passieren, dass ein Peer vereinzelte Segmente mangels Partnerbandbreite überhaupt nicht anfragen kann und es daher an einzelnen Stellen
zu 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 diese Optimierung wird implizit die Anzahl der ausgehenden Anfragen pro Partner begrenzt.
Es mussten keine expliziten Obergrenzen für ausgehende Anfragen deniert werden, wodurch die Implementierung so nah wie möglich an der Protokollspezikation erfolgte.
Bewertung der Metriken
Das CoolStreaming-Protokoll dient dem Live-Streaming von
Web-TV-Inhalten. Die wichtigste Metrik in diesem Anwendungsbereich ist der ContinuityIndex, da es hier darauf ankommt, dass der Stream mit möglichst wenig Aussetzern übertragen wird. Verzögerungen sind beim Web-TV-Streaming zwar unangenehm, aber nicht
so kritisch zu bewerten wie z.B. bei Videokonferenzanwendungen. Bei der Implementierung hat sich zudem gezeigt, dass der Continuity-Index eine Metrik ist, die von vielen
verschiedenen Faktoren abhängt (z.B. von den tatsächlichen und den geschätzten Uploadbandbreiten der Peers, von der Partneranzahl pro Peer und der Verbindungsstruktur im
Netzwerk). Auÿerdem konnte ein Trade-O zwischen der Anfangsverzögerung und dem
Continuity-Index festgestellt werden. Je später die Wiedergabe beginnt, desto höher ist
der 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 allgemein
gezogen werden. In Mesh-Pull-Systemen fordern die Empfänger-Peers die Segmente und
damit die Senderbandbreite aktiv an. Damit die Senderbandbreite nicht überbeansprucht
wird, muss der Zugri auf die Senderbandbreite gesteuert werden, z.B. durch Schätzung
der Bandbreite.
Das Mesh-Pull-Konzept basiert darauf, dass alle Peers möglichst gleichmäÿig mit ihrer
Bandbreite zum Übertragungsvolumen beitragen, d.h. die Anfragen sollten gleichmäÿig
zwischen den Partnern verteilt werden. Dazu dürfen die Partner in Bezug auf die Abspielverzögerung nicht zu weit auseinander liegen, d.h. ihre Entfernung von der Quelle sollte
nicht zu stark variieren. Da ein Mesh zufällig aufgebaut wird, kann die Verbindungsstruktur im Netzwerk zu diesem Zweck nur dynamisch während des Streamingprozesses
angepasst werden. Als mögliche Erweiterung wird daher in [ZL+05] ein Partnerscore
vorgeschlagen. Da die gemessenen Werte meiner Implementierung schon vergleichbar gut
mit der Original-Implementierung sind und zudem nicht bekannt ist, ob im Original
der Partnerscore tatsächlich integriert ist, wurde auf die Umsetzung des Partnerscores
verzichtet.
Um schlieÿlich die Abspielverzögerungen in Mesh-Pull-Systemen niedrig zu halten, gibt
es die Möglichkeit, dass Statusnachrichten (Buermaps, Segmentanforderungen) nicht
in festen Intervallen versandt werden (wie bei CoolStreaming), sondern immer dann,
wenn sich Änderungen ergeben. Partner verschicken z.B. ihre Buermap, sobald sie neue
Segmente im Puer gespeichert haben und diese zur Verfügung stellen können. Und
bei Eingang einer Partner-Buermap wird der Scheduler gestartet und gegebenenfalls
das fehlende Segment angefordert. Dadurch könnten die Abspielverzögerungen verringert werden, unter Umständen würde dies aber den Overhead durch Kontrollnachrichten
erhöhen.
92
7 Abschluss
In dem letzten Kapitel dieser Arbeit werden die Erfahrungen bei der Entwicklung mit dem
Netzwerksimulator P2PNetSim wiedergegeben. Die Arbeit schlieÿt mit einem Fazit und
einem Ausblick. Im Ausblick werden dabei verschiedene in dieser Arbeit angesprochene
Aspekte 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 des
Netzwerksimulators P2PNetSim Version 3.0 entwickelt. Bei P2PNetSim handelt es sich
um einen verteilt arbeitenden Simulator, wodurch Simulationen auf mehreren Clustern
laufen können, was vor allem bei gröÿeren Simulationen die Laufzeit erheblich verringert.
P2PNetSim ist übersichtlich strukturiert und zudem leicht zu bedienen. Derzeit wird
P2PNetSim komplett überarbeitet. Der Funktionsumfang der neuen Version ist mir nicht
bekannt. Aufgrund meiner Erfahrungen mit P2PNetSim schlage ich vor, folgende Ideen
bei der Realisierung der neuen Version zu berücksichtigen.
Das neue P2PNetSim sollte das Benchmarksystem SimBench fest integrieren, so dass
zukünftige Entwicklungen von Beginn an auf SimBench aufbauen können und die Befehlszentrale (mit Join, Leave und Fail) sowie die XML-Generierung zur Konguration
der Peers nutzen können.
Wünschenswert wäre ebenfalls, dass bereits implementierte Protokolle ebenfalls zur Verfügung gestellt werden, so dass die Verfasser späterer Abschlussarbeiten im Lehrgebiet
Kommunikationsnetze auf den vorhandenen Implementierungen aufbauen können.
Es empehlt sich auÿerdem, wenn die im Rahmen dieser Arbeit realisierten Erweiterun-
StreamingAddress,
Zeit und Bandbreitenregulator. Für die Benutzung der Klasse Bandbreitenregulator
gen und Korrekturen implementiert werden, insbesondere die Klassen
müssen in der XML-Konguration Parameter für die maximalen Upload- und Downloadbandbreiten jedes Peers gesetzt werden. P2PNetSim sieht dafür zwar die Parameter
OutgoingBandwidth
für Upload und
IncomingBandwidth
für Download vor, bietet aber
keine Möglichkeit an, diese aus der Basiskonguration auszulesen. Da
und
OutgoingBandwidth
IncomingBandwidth
auch über den SimBench-XML-Kongurator gesetzt werden
können, sollte die Bandbreitenregulierung in der neuen P2PNetSim-Version diese Parameter benutzen und zudem eine Getter-Methode zum Auslesen der gesetzten Werte
implementieren.
P2PNetSim verschickt die Nachrichten per Zufallsprinzip, d.h. die Nachrichten kommen
nicht in der Reihenfolge an, in der sie abgeschickt wurden. Das Zufallsprinzip erscheint
zwar 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 Protokollen ist es wichtig, dass die Schritte beim Aufbau des Netzes nachvollziehbar sind.
Daher empfehle ich, neben dem Zufallsprinzip auch den deterministischen Versand zu
implementieren.
Bisher werden Exceptions aus den implementierten Protokollen so behandelt, dass die
Simulation weiter läuft und die P2PNetSim-GUI nur die Meldung der Exception ausgibt.
Um gravierende Fehler festzustellen, müssen Logmeldungen mit Logleveln wie
ERROR oder
FATAL ausgegeben und auf Verdacht hin alle Logmeldungen nach diesen Logleveln durchsucht werden, was wenig ezient ist. P2PNetSim sollte daher die Möglichkeit vorsehen,
dass zumindest RuntimeExceptions gefangen und behandelt werden können, so dass die
Simulation bei einem schweren Fehler anhält.
Abschlieÿend ist zu sagen, dass ich die Implementierung von Protokollen in P2PNetSim
zusammen mit dem gleichzeitigen Einsatz von externen Modultest wie JUnit und Performancetests mit SimBench sehr empfehlen kann.
7.2 Fazit
In dieser Arbeit wurde zunächst am Beispiel von China gezeigt, unter welchen Rahmenbedingungen ein für die P2P-Streaming-Forschung förderliches Klima entsteht. Dann
wurde 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 darstellen zu können, wurde aus der groÿen Anzahl in Frage kommender Protokolle CoolStreaming ausgewählt. CoolStreaming, ein P2P-Live-Streaming-Protokoll auf Mesh-PullBasis, ist einfach und übersichtlich strukturiert, ndet in vielen wissenschaftlichen Abhandlungen Erwähnung und ist zudem als kommerzielles System im Realbetrieb erprobt.
Die Analyse von CoolStreaming erfolgte durch Vergleich der Protokollcharakteristiken
mit denen anderer P2P-Live-Streaming-Protokolle. Dabei wurden die Protokollcharakteristiken in einer mir bisher nicht bekannten Tiefe betrachtet und zugleich ein ungewöhnlich breiter Überblick über vorhandene P2P-Live-Streaming-Protokolle gegeben. Im
Rahmen der Analyse wurde auch auf die verschiedenen Begriichkeiten, die sich in der
P2P-Streaming-Literatur nden, hingewiesen, um so den systematischen Überblick zu
vervollständigen.
Eine Herausforderung bei der Implementierung von CoolStreaming stellte die heuristische Schätzung der Partnerbandbreite dar, auf welcher die Qualität des SchedulerAlgorithmus basiert. Diese zentrale Komponente wird in der Protokollspezikation nicht
beschrieben, konnte aber dennoch so implementiert werden, dass sie nach einer relativ
kurzen Anlaufphase zuverlässig realistische Schätzungen liefert. Die Implementierung des
CoolStreaming-Protokolls wurde schlieÿlich mit Hilfe von Benchmarkmessungen ausgewertet und optimiert. Dabei wurde auch auf weitere mögliche Verbesserungen hingewiesen.
94
7.3 Ausblick
Welche Entwicklungen können in Zukunft beim Streaming und insbesondere beim Streaming auf P2P-Basis erwartet werden?
Streaming über HTTP wird im Rahmen von HTML5 standardisiert werden. Die dabei gestreamten Videoformate bauen entweder auf dem lizenzpichtigen H.264-Standard
von MPEG oder auf freien Standards (Ogg Theora, VP8) auf. Der zukünftige Einsatz
von H.264 wird hier davon abhängen, inwieweit die MPEG-Lizenzpolitik den Nutzern
entgegenkommt.
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 Kommunikation zwischen Peers und Tracker regelt. Es bleibt aber abzuwarten, ob sich daraus ein
RFC entwickeln wird und ob kommerzielle P2P-Streaming-Systeme auf diesen Standard
aufsetzen werden. Dies ist insbesondere fraglich, da kommerzielle Systeme eher proprietäre und besser zu kontrollierende Lösungen bevorzugen (siehe am Beispiel von Skype).
Des weiteren sollte man bei P2P-Streaming zwischen den Forschungen im akademischen Bereich und den Entwicklungen im kommerziellen Umfeld unterscheiden. Im akademischen Bereich wird vermehrt mit Forschungsarbeiten über den Einsatz von P2PStreaming auf mobilen Geräten zu rechnen sein. Was kommerzielle Lösungen betrit,
so basieren diese nach wie vor auf der einfach strukturierten Mesh-Topologie. MultiTree-basierte Systeme werden sich meines Erachtens im kommerziellen Umfeld erst dann
durchsetzen können, wenn die dabei angewandte Kodierung (MDC) auch von gängigen
Playern unterstützt wird, was bisher nicht absehbar ist. In den westlichen Industrienationen könnte zudem das Interesse an kommerziellen P2P-Streaming-Lösungen bei einer
stärkeren Verbreitung von IPTV steigen. Derzeit bedienen IPTV-Anbieter nur eine kleine Klientel, so dass über Serverfarmen und CDN-Server Videodaten in HD-Qualität zu
16 Mbps gestreamt werden können. Bei einem massiven Anstieg der Abonnenten werden
diese Architekturen an ihre Grenzen stoÿen und eine Integration von P2P-StreamingStrukturen in die IPTV-Netze wäre denkbar.
Schlussendlich soll betont werden, dass Entwicklungen auch noch von anderen Faktoren beeinusst werden. Während z.B. ein groÿer Anteil der P2P-Streaming-Arbeiten
aus 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,
schaen u.a. politische und rechtliche Entscheidungen in China ein günstiges Umfeld für
Forschungen. In den westlichen Industrienationen ist der Druck von Seiten der Rechteinhaber jedoch groÿ. Zukünftige politische Entscheidungen können im Westen von diesem
Druck geprägt sein und dabei ein P2P-Streaming-feindliches Klima fördern, was wiederum hinderlich für Entwicklungen wäre. Es bleibt zu hoen, dass sich Rechteinhaber
zukünftig nicht mehr von P2P-Streaming bedroht fühlen und so wieder vermehrt mit
Veröentlichungen westlicher P2P-Streaming-Forscher zu rechnen ist.
95
Literaturverzeichnis
[AYC04] C. Abad, W. Yurcik, R.H. Campbell; A Survey and Comparison of End-System
Overlay Multicast Solutions Suitable for Network Centric Warfare; Proceedings
of SPIE, 2004; 2004
[BBK02] S. Banerjee, B. Bhattacharjee, C. Kommareddy; Scalable application layer multicast; Proc. ACM SIGCOMM'02, Pittsburgh, PA, Aug. 2002; 2002
[BM+08] T. Bonald, L. Massoulié, F. Mathieu, D. Perino, A. Twigg; Epidemic Live
Streaming: Optimal Performance Trade-Os; SIGMETRICS '08: Proceedings
of the 2008 ACM SIGMETRICS international conference on Measurement and
modeling of computer systems; 2008
[BM+09] A. Bakker, J.J.D. Mol, J. Yang, L. d'Acunto, J.A. Pouwelse, J. Wang, P. Garbacki, A. Iosup, J. Doumen, J. Roozenburg, M. ten Brinke, F. Zindel, M. Meulpolder, J. Taal, B. Schoon; P2P-Next, Next-Share Platform M8Specication
Part; 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-Peer
Streaming Network; LANC'09 September 24-25, 2009. Pelotas, Brazil; 2009
[CD+02] M. Castro, P. Druschel, A. Kermarrec, A. Nandi, A. Rowstron; SCRIBE: A
large-scale and decentralized application-level multicast infrastructure; IEEE
Journal on Selected Areas in Communication (JSAC), 20(8), 2002, pp. 14891499; 2002
[CD+03] M. Castro, P. Druschel, A. Kermarrec, A. Nandi, A. Rowstron, A. Singh; SplitStream: high-bandwidth multicast in a cooperative environment, Proc. ACM
19th 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 Overlay
Streaming 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 distribution
in Mesh-Based Large Scale P2P Streaming Systems: A uid approach; IEEE
Transactions on Parallel and Distributed Systems; 2010
96
[Cli01]
Clip2;
The
Gnutella
protocol
specication
http://www9.limewire.com/developer/gnutella_protocol_0.4.pdf
v0.4;
(2001);
http://www9.limewire.com; 2001
[cnn09]
China Internet Network Information Center; Statistical Survey Report on Internet Development in China (July 2009); http://www.cnnic.cn; 2009
[cnn10]
China Internet Network Information Center; Statistical Survey Report on Internet Development in China (January 2010); http://www.cnnic.cn; 2010
[CRC08] D. Carra, R. Lo Cigno, A. Russo; On Some Fundamental Properties of P2P
Push/Pull Protocols; ICCE 2008. Second International Conference on Communications and Electronics; 2008
[CRZ00] Y. Chu, S.G. Rao, H. Zhang; A case for end system multicast; In Proceedings
of 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 on
Networking Support for Multicast, Vol. 20, No. 8, 2002; 2002
[CS+01] I. Clarke, O. Sandberg, B. Wiley, T.W. Hong; Freenet: A distributed anonymous
information 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 Applications 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 extended LANs; ACM Transaction on Computer Systems, Vol. 8, No. 2; 1990
[E08]
W. Eelsberg; 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. Jacobson, C. Liu, P. Sharma, L. Wei; Protocol Independent Multicast-Sparse Mode
(PIM-SM) Protocol Specication; http://www.rfc-editor.org/rfc/rfc2362.txt;
1998
[env08]
Envisional Ltd; Background Report on Digital Piracy of Sporting Events; Envisional Ltd and NetResult Ltd; 2008
[ES05]
J. Eberspächer, R. Schollmeier; First and Second Generation of Peer-to-PeerSystems; Peer-to-Peer Systems and Applications 2005; 2005
[Fen97]
W. Fenner; Internet Group Management Protocol, Version 2; http://www.rfceditor.org/rfc/rfc2236.txt; 1997
[FH07]
[Fra00]
P. Fischer, P. Hofer; Lexikon der Informatik; Springer; 2007
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-ppsptracker-protocol-00; http://tools.ietf.org; 2010
[GKM03] A.J. Ganesh, A.-M. Kermarrec, L. Massoulie; Peer-to-peer membership management 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 scheme
for vod service; In: Proceedings of the 12th world wide web conference (WWW03), May 2003; 2003
[GS+07] Y. Guo, K. Suh, J. Kurose, D. Towsley; Directstream: a directory-based peerto-peer video streaming service; Tech. rep., UMass CMPSCI Technical Report
TR 07-30; 2007
[GZ+09] Y.
Gu,
N.
Zong,
H.
Zhang,
Y.
Zhang,
G.
Camarillo,
Y.
Liu;
PPSP
Internet-Draft: Survey of P2P Streaming Applications/ draft-gu-ppsp-survey01; http://tools.ietf.org; 2009
[HA+06] M. Hosseini, D.T. Ahmed, S. Shirmohammadi, N. D. Georganas; A Survey
of Application-Layer Multicast Protocols; IEEE Communications Surveys &
Tutorials 9(3),5874, 2007; 2007
[hei06]
http://www.heise.de/newsticker/meldung/79870; Studie: P2P-Datenvolumen
nimmt in Deutschland weiter zu; http://www.heise.de; 2006
[hei10]
http://www.heise.de; MPEG LA: Keine Lizenzkosten für H.264-kodierte Internetvideos bis Ende 2016; http://www.heise.de/newsticker/meldung/MPEGLA-Keine-Lizenzkosten-fuer-H-264-kodierte-Internetvideos-bis-Ende-2016Update-921885.html, Artikel v. 04.02.2010; 2010
[HF+03] M. Handley, S. Floyd, J. Pahdye, J. Widmer; TCP Friendly Rate Control
(TFRC): Protocol Specication; RFC 3448, January 2003; 2003
[HH+03] M. Hefeeda, A. Habib, B. Botev, D. Xu, B. Bhargava; PROMISE: Peer-to-Peer
Media Streaming Using CollectCast; In Proc. of the 11th ACM international
conference on Multimedia, Berkeley, CA, USA, November, 2003; 2003
[HLR08] X. Hei, Y. Liu, K.W. Ross; IPTV over P2P Streaming Networks: the Mesh-pull
Approach; 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. Giord, K.L. Johnson, M.F. Kaashoek, J.W. O'Toole, Jr.;
Overcast: Reliable Multicasting with an Overlay Network; In: Proceedings of
operating systems design and implementation, pp 197212; 2000
[Jov01]
M.A. Jovanovic; Modeling Large-scale Peer-to-Peer Networks and a Case Study
of Gnutella; University of Cincinnati/Ohio; 2001
98
[Kle05]
R. Klein; Betriebssysteme und Rechnernetze; FernUniversität in Hagen, Kurs
im 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 Data
Dissemination Using an Overlay Mesh; Proceedings of the 19th ACM symposium on Operating systems principles (SOSP'03); 2003
[Ksh08]
N. Kshetri; Looking at the Facts: What we Know (and Don't Know) about the
Chinese Internet Protocol TV Market; Pacic Telecommunications Council's
(PTC); 2008
[LC+05] E.K. Lua, J. Crowcroft, M. Pias, R. Sharma, S. Lim; A Survey and Comparison
of 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 - Computer Systems course project report, April 2004; 2004
[Liu07]
Y. Liu; Reducing or minimizing delays in peer-to-peer communications; Patents
by Straub & Pokotylo; 2007
[Liu10]
Z. Liu; Measurements on Large-scale Peer-assisted Live Streaming: A Survival
Analysis Approach; Master Thesis, University of Toronto; 2010
[LJ+06] X. Liao, H. Jin, Y. Liu, L.M. Ni, D. Deng; AnySee: Scalable live streaming
service 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-toPeer Internet Video Broadcast; Special Issue on Recent Advances in Distributed
Multimedia 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 New
Coolstreaming: Principles, Measurements and Performance Implications; INFOCOM 2008; 2008
[Mar09]
R.C. Martin; Clean Code: A Handbook of Agile Software Craftsmanship; Pearson Education; 2009
[MF09]
E. Magli, P. Frossard; An Overview of Network Coding for Multimedia Streaming; 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 MPEG
LA's AVC License Will Continue Not to Charge Royalties for Internet Video
that is Free to End Users; http://www.mpegla.com; 2010
[MP+08] G. Mara, G. Pau, P. Di Rico, M. Gerla; P2P Streaming Systems: A Survey
and Experiments; STreaming Day 2007; 2008
[MR06]
N. Magharei, R. Rejaie; Understanding mesh based peer-to-peer streaming; In
ACM NOSSDAV 2006, Newport, Rhode Island, USA; 2006
[MR07]
N. Magharei, R. Rejaie; PRIME: Peer-to-Peer receiver-driven mesh-based streaming, Proc. IEEE INFOCOM Conf., May 2007; 2007
[MRG07] N. Magharei, R. Rejaie, Y. Guo; Mesh or Multiple-Tree: A Comparative Study
of 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, Despite Backlash; http://newteevee.com/2009/02/07/cnn-inauguration-p2p-streama-success-despite-backlash/; 2009
[oec09]
OECD/Organisation For Economic Co-operation And Development; Piracy Of
Digital Content; OECD 2009; 2009
[OJ08]
J. Ott, D. Jegadish; Peer-to-Peer Media Streaming; Helsinki University of Technology, 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 Signal
Processing, ProRisc 2005; 2005
[Pia07]
F. Pianese; PULSE An Adaptive Practical Live Streaming System; PhD Thesis,
Université de NiceSophia Antipolis; 2007
[PKB06] F. Pianese, J. Keller, E.W. Biersack; PULSE, a Flexible P2P Live Streaming
System; INFOCOM 2006; 2006
[PK+05] V. Pai, K. Kumar, K. Tamilmani, V. Sambamurthy, A. Mohr; Chainsaw: eliminating 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 level
Multicast Infrastructure; Proceedings of 3rd Usenix Symposium on Internet
Technologies 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 streaming media content using cooperative networking; Proc. ACM NOSSDAV
Workshop, 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, and
routing for large-scale peer-to-peer systems. In IFIP/ACM International Conference on Distributed Systems Platforms (Middleware), pages 329-350, 2001;
2001
[RF+00] S. Ratnasamy, P. Francis, M. Handley, R. Karp, S. Shenker; A scalable content
addressable network; In Computer Communication Review, Vol. 31; 2000
[RG+01] A. Rodriguez, J. Gatrell, J. Karas, R. Peschke; TCP/IP Tutorial and Technical Overview; IBM Corporation, International Technical Support Organization;
2001
[RH+01] S. Ratnasamy, M. Handley, R. Karp, S. Shenker; Application-level Multicast
using Content-Addressable Networks; Proceedings of 2001 International Workshop on Networked Group Communication, pp. 14-29; 2001
[Roj07]
J.B. Rojas; P2PNetSim :: P2P Network Simulation Environment; FernUniversität in Hagen; 2007
[RS60]
I.S. Reed, G. Solomon; Polynomial Codecs over certain nite elds; Journal of
the Society for the Industrial and Applied Mathematics 8 (1960) 300-304; 1960
[Sch07]
R. Schreiner; Computernetzwerke - Von den Grundlagen zur Funktion und Anwendung; 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 Protocol 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; Trac 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 scalable Peer-To-Peer lookup service for internet applications; In Proceedings of
the 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 Overlay Streaming Systems; ICCCN '08. Proceedings of 17th International Conference 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;
Netzwerkezienz
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 of
Peer-to-Peer Streaming Overlays: An Application Perspective; In Proceedings
of IEEE LCN 2008; 2008
[THD03] D.A. Tran, K.A. Hua, T.T. Do; ZIGZAG: An ecient peer- to-peer scheme for
media 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 Unstructured Peer-to-Peer Multicast; In: Proceedings of 5th international workshop on peer-to-peer systems; 2006
[VIF06]
A. Vlavianos, M. Iliofotou, M. Faloutsos; Bitos: enhancing bittorrent for supporting 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; International Conference on Mobile Ubiquitous Computing, Systems, Services and Technologies 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 Computer
Engineering; 2008
[WL07]
M. Wang, B. Li; R2: Random Push with Random Network Coding in Live
Peer-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 of
the IEEE Communications Society, 2009); 2007
[WLQ06] G. Wen, H. Longshe, F. Qiang; Recent Advances in Peer-to-Peer Media Streaming Systems; China Communications October 2006; 2006
102
[Wol10]
A. Wolf; SimBench: Ein Benchmark für den P2P-Simulator P2PNetSim; Abschlussarbeit FernUniversität in Hagen; 2010
[WPD88] D. Waitzmann, C. Patridge, S. Deering; Distance Vector Multicast Routing
Protocol; http://www.rfc-editor.org/rfc/rfc1075.txt; 1988
[XH+02] D. Xu, M. Hefeeda, S. Hambrusch, B. Bhargava; On Peer-to-Peer Media Streaming; 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, and
Practice; 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 Streaming
Protocols; The Chinese University of Hong Kong; 2007
[Zha07]
Q. Zhang; Understanding the Power of Pull-based P2P Streaming Protocol: We
Can 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 FaultTolerant Wide-area Location and Routing. Computer Science Division, University 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-driven
overlay 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]
[Zot10]
N. Zong; Chunk Discovery for P2P Streaming; PPSP Internet-Draft; 2009
V. Zota; Video-Poker: Google will neuen Web-Videostandard etablieren; c't
13/10; 2010
[ZT+05] M. Zhang, Y. Tang, L. Zhao, J.-G. Luo, S. Yang; GRIDMEDIA: A Multi-Sender
Based Peer-to-Peer Multicast System for Video Streaming; IEEE International
Conference on Multimedia and Expo (ICME) 2005: 614-617; 2005
[ZX+09] M. Zhang, Y. Xiong, Q. Zhang, L. Sun, S. Yang; Optimizing the Throughput
of Data-Driven Peer-to-Peer Streaming; In IEEE Transactions on Parallel and
Distributed 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 Operating
System 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-based
Streaming Protocol: Can We Do Better?; In IEEE Journal on Selected Areas in
Communications, 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 Statement
of 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]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
10
Nachfrage nach kommerziellen P2P-Streaming-Systemen (Stand Mai 2010)
[goo10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.1
Perspektivische Annäherung
. . . . . . . . . . . . . . . . . . . . . . . . .
15
2.2
Unicast und IP-Multicast (nach [Sim08]) . . . . . . . . . . . . . . . . . . .
22
2.3
Streaming-Architekturen (nach [LR+08, Vil09])
. . . . . . . . . . . . . .
23
2.4
IP-Multicast und ALM (nach [BBK02])
. . . . . . . . . . . . . . . . . . .
25
3.1
Puer und dazugehörige Buermap . . . . . . . . . . . . . . . . . . . . . .
33
4.1
Verbindungsstruktur bei zufälliger Partnerwahl (links), bei Wahl mit Berücksichtigung der Location-Awareness (Mitte) und bei dem hybriden Ansatz (rechts) [CL+10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2
37
Mesh-Overlay-Schicht (Overlay Layer) und Datenverteilungsschicht (Distribution Layer) in einem P2P-Streaming-Netzwerk [CLB07] . . . . . . . .
38
4.3
Prinzip der Netzwerkkodierung (NC) [MF09]
46
4.4
Zufälliger Verbindungsgraph des CoolStreaming-Netzwerks (10 Peers, ma-
. . . . . . . . . . . . . . . .
ximale Partneranzahl=5) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.5
Systemdiagramm eines CoolStreaming-Peers (nach [ZL+05]) . . . . . . . .
58
5.1
P2PNetSim-GUI mit Anzeige der Grundkonguration (Basic congurati. . . . . .
61
5.2
Implementierung des CoolStreaming-Peers . . . . . . . . . . . . . . . . . .
65
5.3
Zuordnung von Aufgaben zu Hauptmodulen beim CoolStreaming-Peer
5.4
Klassendiagramm der Hauptmodule
on) und selbst denierter Parameter (Properties) von Peer10
. .
69
. . . . . . . . . . . . . . . . . . . . .
70
5.5
Peerpuer und Puer der Quelle (PUFFER_SIZE=60) . . . . . . . . . . . . .
72
5.6
Zusammenspiel zwischen
. .
79
5.7
Verfügbarkeit von
. .
83
5.8
Testdaten für Scheduling-Algorithmus
. . . . . . . . . . . . . . . . . . . .
84
5.9
Verikation der Implementierung
. . . . . . . . . . . . . . . . . . . . . . .
86
6.1
Continuity-Index in Abhängigkeit von der Berücksichtigung der Partner-
6.2
Bandbreitenregulator und StreamingPeer
Segmenten (seg_id 0-9) bei Partnern (part_id 0-4)
bandbreite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
Continuity-Index in Abhängigkeit vom Beginn der Wiedergabe
90
105
. . . . . .
Tabellenverzeichnis
1.1
Websites mit unautorisierten Fuÿball-Streams (Saison 2007/2008) [env08]
2.1
Gängige Kombinationen aus Container, Codecs und Protokollen [Sim08,
tuc10]
3.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
Klassizierung von P2P-Systemen und Vergleich ihrer Eigenschaften [PBV05,
SW05] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1
9
30
Vergleich der Charakteristiken von P2P-Live-Streaming-Protokollen [AYC04,
HA+06, Liu04, MR07, Pia07, SW05, SZ+08, VFC06, VY07, Wan08, ZZ+07]
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2
Kontrolloverhead von Tree-basierten ALM-Protokollen in Relation zur Kno-
4.3
Vergleich von Metriken bei Mesh-basierten und Mesh-/Tree-basierten ALM-
tenanzahl
N
[AYC04, CRZ00, HA+06] . . . . . . . . . . . . . . . . . . . .
Protokollen [Kos08, KR+03, LJ+06, OJ08, ZL+05, ZZ+07]
106
. . . . . . . .
50
54
55
Glossar
Abtastrate (engl. sample rate/sampling rate) Frequenz, mit der analoge Audiosignale
beim Digitalisierungsprozess abgegrien werden (gewöhnlich zwischen 32kHz und
96kHz)
ALM (Application-Level-Multicast/Application-Layer-Multicast) Implementierung von
Multicast auf der Anwendungsebene.
Synonyme: End-System-Multicast/ESM, End-System-Overlay-Multicast, OverlayMulticast, Peer-to-Peer-Multicast, Peer-to-Peer-Broadcast, P2P-Internet-VideoBroadcast, P2P-Internet-Video-Streaming
Buermap Darstellung des lokalen Puerinhalts als Bit-String oder Bitmap. Vorhandene Segmente werden durch 1 repräsentiert, nicht vorhandene durch 0. Bei
der Pull-basierten Datenverteilung müssen die Peers regelmäÿig Buermaps austauschen.
Churn Hohe Fluktuation im Netzwerk, die dadurch entsteht, dass oft neue Peers ins
Netz kommen und verbundene Peers das Netz wieder verlassen.
Containerformat Enthält Audio- und Videoformate, eventuell Untertitel sowie Metainformationen, die die synchronisierte Ausgabe ermöglichen.
Synonym: Wrapperformat
Continuity-Index P2P-Streaming-Metrik. Gibt an, wie kontinuierlich die Wiedergabe
des Streams erfolgt, und wird ermittelt durch die Relation von den rechtzeitig
erhaltenen 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, die
Standards deniert zum Broadcast von digitalen TV-Signalen. Die Verteilung
der digitalen TV-Signale erfolgt per Kabel (DVB-C), Satellit (DVB-S), Antenne (DVB-T) oder mobil (DVB-H über Rundfunknetze).
ESM (End-System-Multicast) bezeichnet nach Sanjay G. Rao ganz allgemein die Architektur, in der ein Multicast-Baum über einem unstrukturierten/strukturierten
P2P-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 nach
kurzer Zeit wieder sehr schnell fällt.
Flooding (Flutsuche) Broadcast an alle Peers im P2P-Netzwerk bis zum Ablauf einer
Time-To-Live/TTL.
fps
(frames per second) Die Bild-/Framerate gibt an, wie viele Bilder pro Sekunde
angezeigt werden.
H.264 Standard zur Videokomprimierung aus dem MPEG-4-Paket des MPEG-Konsortiums. Ermöglicht eine ezientere Komprimierung bei gleichbleibender Videoqualitä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 Einheiten (z.B. Napster, FastTrack, Gnutella 0.6).
2. P2P-System mit heterogenen Eigenschaften, das z.B. ein strukturiertes System mit einem unstrukturiertem System verbindet (z.B. Gnutella-Netzwerk mit
CAN-Routing-Algorithmus).
Join
Ein Peer verbindet sich zum Netzwerk.
Kontrolloverhead P2P-Streaming-Metrik. Misst das Verhältnis von Kontrolldaten (in
Bytes) zu Videodaten (in Bytes).
Leave Ein Peer verlässt das Netzwerk.
Mesh-basiertes P2P-Streaming Die Verteilung der Streamdaten erfolgt über dynamische Routen innerhalb des Mesh.
Mesh (engl. für Masche) Unstrukturiertes/Strukturiertes Netzwerk, über das die Peers
beim P2P-Streaming verbunden sind.
MPEG (Moving Pictures Experts Group) Konsortium, das seit 1991 oene, patentierte
Standards zur Kompression von Video- oder Audiodaten veröentlicht.
Overlay Logisches Netzwerk oberhalb einer physischen Netzwerkstruktur, in denen zwei
Applikationen über einen anderen Pfad kommunizieren als durch die Netzwerkschicht gegeben. Nicht alle P2P-Netzwerke sind Overlay-Netzwerke (siehe Mobile
Ad-hoc-Netzwerke) und nicht alle Overlay-Netzwerke sind P2P-Netzwerke (siehe
Virtual-Private-Networks).
Synonym: Overlay-Netzwerk
P2P-Streaming Streaming über ein P2P-Netzwerk. Beim P2P-Streaming laden Endsysteme den Stream herunter und leiten ihn weiter.
Perceptual-Encoding Kompressionsverfahren für Audiosignale, das nur die durch das
menschliche Gehör wahrnehmbaren Töne speichert.
108
Playback-Delay (Abspielverzögerung) P2P-Streaming-Metrik. Misst die Zeitdierenz
zwischen der Ausgabe eines Streamsegments durch die Quelle und dessen Wiedergabe durch den Peer.
Synonyme: Playout-Delay, Display-Lag, Average-Reception-Delay
Startup-Delay (Anfangsverzögerung) P2P-Streaming-Metrik. Misst die Zeitdierenz
zwischen 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-Streaming
muss die verfügbare Downloadbandbreite mindestens so groÿ wie die Streamingrate sein (im Internet üblich: ca. 400 kbps).
Synonyme: Bitrate/Datenrate des Streams
Streaming Kontinuierliche Übertragung und Verwertung von Audio- und/oder Videodaten ü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 diese
Inhalte zuständig sind. Dies kann durch eine wohldenierte Hash-Funktion realisiert werden.
Synonyme: stra strukturiertes P2P-System, Content-orientiertes P2P-System,
Content-addressierbares P2P-System, System mit Content-basiertem Routing und
System mit Content-adressierbarer Datenhaltung
Tree-basiertes P2P-Streaming Die Verteilung der Streamdaten erfolgt über einen
oder mehrere explizit aufgebaute Multicast-Bäume.
Unstrukturiertes P2P-System P2P-System, in dem die Daten zufällig ohne Relation
zu den Knoten abgelegt werden.
109