Qualitaetsverbessertes Peer-to-Peer

Bachelorarbeit
Zum Thema
Qualitätsverbessertes Peer-to-Peer-basiertes IPTV
durch Bandbreitenersparnis im Upload
Eingereicht von Zierke, Robert am 25.06.2012
geboren am
05.02.1985
in Güstrow
an der
Universität Rostock
Gutachter:
Betreuer:
Prof. Dr.-Ing. Dirk Timmermann
Institut für Angewandte Mikroelektronik und Datentechnik
Dipl.-Ing. Peter Danielis
M.Sc. Jan Skdozik
Institut für Angewandte Mikroelektronik und Datentechnik
Kurzreferat
Unter IPTV versteht man die Übertragung von Multimediadiensten wie
Fernsehen, Video, Audio und Daten über IP-basierte Netze. Dabei ist für
die Annahme des Dienstes durch den Nutzer eine hohe Qualität, Sicherheit, Interaktivität in Form eines Rückkanals sowie hohe Zuverlässigkeit
notwendig. Für die mehrfache Verteilung der Datenströme (Multicast)
an alle Nutzer gibt es neben IP-Multicast auch die Möglichkeit der Peerto-Peer (P2P)-basierten Verteilung. Vielfach ist hierbei die Dienstgüte
allerdings noch nicht ausreichend.
Deshalb befasst sich diese Bachelorarbeit mit einer P2PNetzwerksimulation, die eine Verringerung der Latenz sowie eine Ersparnis
der Bandbreite erbringen soll. Diese Ersparnis soll durch eine Verlagerung
des Uploads von Live-Streams auf die DSLAMs erzielt werden.
Inhaltsverzeichnis
Abbildungs- und Tabellenverzeichnis
5
Abkürzungsverzeichnis
6
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Aufbau dieser Arbeit . . . . . . . . . . . . . . . . . . . . . .
7
8
9
2 Grundlagen
2.1 Das P2P-basierte Netzwerkmodell
2.1.1 Unstrukturierter Ansatz . . .
2.1.2 Strukturierter Ansatz . . . .
2.2 P2P-IPTV . . . . . . . . . . . . .
2.2.1 Grundarten . . . . . . . . . .
2.2.2 Struktur . . . . . . . . . . .
2.2.3 BitTorrent-Technik . . . . . .
2.3 Vergleich der Übertragungsarten .
.
.
.
.
.
.
.
.
10
10
12
16
16
17
18
19
20
.
.
.
.
.
22
22
23
24
25
26
4 Umsetzung und Implementierung
4.1 Einarbeitung in die Simulation . . . . . . . . . . . . . . . . .
28
28
3 Konzept
3.1 P2P-Protokolle . . . . . . . .
3.2 BitTorrent-Spezifikation . . .
3.2.1 Tracker-Protokoll . . . .
3.2.2 Peer-Wire-Protokoll . .
3.3 Überlegung zur Ersparnis der
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Bandbreite
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.1.1 Grundlegende Einstellungen
4.2 Simulator . . . . . . . . . . . . .
4.3 Simulation . . . . . . . . . . . .
4.3.1 Testaufbau . . . . . . . . .
4.3.2 Auswertung der Simulation
.
.
.
.
.
28
29
30
32
34
5 Auswertung
5.1 Simulation mit verändertem Konzept . . . . . . . . . . . . .
5.2 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
38
39
6 Zusammenfassung
41
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Abbildungs- und Tabellenverzeichnis
Abb. 2.1:Client-Server-Netzwerk [Weh05] . . . .
Abb. 2.2:Dezentralisiertes P2P-Netzwerk [Weh05]
Abb. 2.3:Übersicht P2P-Systeme [Kaf12] . . . . .
Abb. 2.4:Ansicht eines Hybriden Systems [Akb11]
Abb. 2.5:Verbindungsstruktur . . . . . . . . . . .
Tab. 2.1:Vergleich der Übertragungsarten [Hei12]
.
.
.
.
.
.
11
11
14
15
18
20
Abb. 3.1:Arbeitsweise von BitTorrent [20112] . . . . . . . . . . .
Abb. 3.2:Darstellung des Konzeptes . . . . . . . . . . . . . . . .
25
26
Tab. 4.1:Szenarienübersicht . . . . . . . . . . . . . . . . . . . . .
Abb. 4.1:Simulationsablauf-Diagramm . . . . . . . . . . . . . . .
33
34
Tab. 5.1:Latenz der einzelnen Szenarien . . . . . . . . . . . . . .
Abb. 5.1:Auslastung des Up- und Downloads . . . . . . . . . . .
Tab. 5.2:Ergebniszusammenfassung . . . . . . . . . . . . . . . . .
36
37
40
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Abkürzungsverzeichnis
A/D
CSN
DHTs
DSLAMs
DVB-T
EM
FTP
HD
HTTP
ID
IP
IPTV
ISP
MD5
MsgP2P
MsgP2T
MsgT2P
NED
OSI
P2P
TCP
TTL
TV
UDP
VoIP
ZDF
Analog-Digital
Client-Server-Network
Distributed Hash Tables
Digital Subscriber Line Access Multiplexers
Digital-Video-Broadcasting-Terrestrial
Europameisterschaft
File-Transfer Protocol
High Definition
Hypertext Transfer Protocol
Identification
Internet-Protocol
Internet-Protocol-Television
Internet Service Provider
Message Digest Algorithm 5
Nachricht PeerToPeer
Nachricht PeerToTracker
Nachricht TrackerToPeer
Network Describtion
Open-System-Interconnection
Peer-to-Peer
Transmission Control Protocol
Time-To-Live
Television
User Datagram Protocol
Voice-over-Internet-Protocol
Zweites Deutsches Fernsehen
6
1 Einleitung
Die Weiterentwicklung der Technik und der Verteilung von Daten im Internet schreitet immer weiter voran. Daher ist es nicht verwunderlich, dass
immer neue Methoden entwickelt werden, um mit Teilnehmern auf der ganzen Welt zu kommunizieren oder Daten auszutauschen. Das Fernsehen über
das Internet ist eine dieser Entwicklungen. In den Anfängen des sogenannten Internet-Protocol-Television (IPTV) war es hoch modern, die Streams
über das Client-Server-Network (CSN) zu verteilen, was auch heute noch
in weiten Teilen verbreitet wird. Seit einigen Jahren wird an einer neuen
Methode gearbeitet. Das Ziel dabei ist es, Live-Streams mit Hilfe einer anderen Methode zu verteilen, um nicht auf Internet-Protocol (IP)-Multicast
angewiesen zu sein. Die Technik, welche dafür genutzt wird, nennt sich
P2P und soll eine sichere, verzögerungsfreie und Server-entlastende Alternative zum CSN darstellen. Diese Entwicklung wird jedoch von noch nicht
vielen Anbietern des IPTV genutzt, da es immer noch Schwächen in der
Verteilung der Kanäle gibt. Eine dieser Schwächen ist die Upload-Rate der
einzelnen Clients im Netzwerk. Bei den Überlegungen wie die Upload- zu
Download-Rate gesetzt werden soll, haben sich die Entwickler überlegt,
dass ein User wesentlich mehr Download als Upload hat.
7
1.1 Motivation
So ist die Idee gewesen, dass eine Anfrage, welche als Upload gesendet
wird, wenig Bandbreite in Anspruch nimmt. Die Datenmenge, welche der
Client bezieht, ist jedoch um ein Vielfaches größer. Da bei dem P2P-IPTV
der gesamte Stream in kleine Datenteile zerteilt und von unterschiedlichen
Teilnehmern im Netzwerk zusammengesetzt und sofort wieder auf einem
Rückkanal zur Verfügung gestellt wird, wird eine große Bandbreite verschenkt.
Der wichtigste Aspekt bei der Rückverteilung ist die Latenz. Diese
entsteht durch die drastischen Unterschiede im Down- und Upload. Daher
forschen Entwickler an einer Bandbreitenersparnis bei der Verteilung von
Streams in einem P2P-Netz, wofür es verschiedene Möglichkeiten gibt. In
der Realität ein geeignetes Netzwerk aufzubauen, gestaltet sich schwierig.
Da nicht nur 2 bis 10 Nutzer an dieser Simulation teilnehmen können,
muss zur Entwicklung ein Simulator genutzt werden, da sonst kein reales
Netz simuliert werden kann. In solchen Simulatoren können weit aus mehr
Clients eingebunden werden und nach Belieben u.a. die Bandbreite so
eingestellt werden, wie es den Voraussetzungen entspricht. Weiterhin ist
zu untersuchen, welches Ersparnis erzielt werden kann, indem nicht mehr
die Peers, sondern die DSLAMs die Streams speichern und weiterleiten.
Die Peers haben eine asymmetrische Bandbreite, daher entsteht eine
Latenz beim Down- und Upload der gleichen Datenmenge. Da die DSLAMs einen symmetrischen Down- und Upload aufweisen, würde die
Latenz beim Upload der Streams von den Peers eingespart werden. Dies
hätte die Auswirkung, dass die Peers ihren Upload nicht mehr zur Weiterleitung von Streams nutzen müssten und so diese Bandbreite für andere
Aktivitäten zur Verfügung hätten.
8
Im Zuge dieser Arbeit soll eine mögliche Qualitätsverbesserung für P2Pbasiertes IPTV untersucht werden, indem eine Entlastung von Zugangsnetzen durch Bandbreitenersparnis im Upload vorgenommen wird. Untersucht werden unter anderem die Auswirkungen bezüglich Bandbreitenersparnis im Upload sowie eine Verringerung der Latenz. Mit einer geringeren Upload-Auslastung können parallel VoIP oder Online-Gaming durchgeführt werden.
1.2 Aufbau dieser Arbeit
Diese Arbeit befasst sich mit der Verbesserung des P2P-IPTV mit Hilfe eines geeigneten Simulators. Aufgrund dessen werden zu Beginn der Arbeit
Grundlagen über P2P-Netze sowie den benötigten Simulator Omnet++
vorgestellt. Weiterhin werden in den Grundlagen DSLAMs und deren Funktionsweise beschrieben.
In Kapitel 3 werden das Konzept erläutert und die Grundüberlegungen für
die Lösung des Problems vorgestellt. Darauf folgend wird in Kapitel 4 die
Beschreibung der Umsetzung und der Implementierung erläutert, welche
für eine Lösung erforderlich ist. Im 5. Kapitel werden verschiedene Szenarien dargestellt und ausgewertet.
9
2 Grundlagen
Um Daten in einem Netzwerk austauschen zu können, gibt es mehrere
Möglichkeiten. Zum einen können die Daten über ein CSN übermittelt
werden, wobei durch den Einsatz von Server- und Raumkapazitäten ein
größerer Mehraufwand betrieben werden muss. Zum anderen können die
Daten zwischen den Peers in einem P2P-basierten Netz ausgetauscht
werden, in dem die Peers sowohl Clients als auch Server darstellen. Die
Grundlagen beschäftigen sich mit den Unterschieden zwischen den beiden
Netzwerkarten sowie dem IPTV.
Die Peers sind mit einem Tracker-Server, auf welchem sich Daten anderer
Netzwerkteilnehmer befinden, zum Informationsaustausch verbunden.
Das entspricht einem zentralisierten System. Darüber hinaus nehmen die
Peers eigenständig ohne einen Server Verbindung auf. Die Identifizierungen bezüglich der Richtigkeit der Daten wird über die Hash-Prüfsumme
geregelt.
2.1 Das P2P-basierte Netzwerkmodell
Die Idee zur Entwicklung eines P2P-Netzes lässt sich bis in das Jahr
1960 zurückverfolgen. Die Obersten des Militärs hatten Angst nach einem möglichem Atomkrieg die Kommunikation zwischen, den noch vorhandenen und unversehrten Rechnern nicht mehr aufrecht erhalten zu
können. Damit die Funktionalität trotz alledem noch gewährleistet ist,
wurden 1964 verschiedene Kriterien aufgestellt. Die Teilnehmer sollen bei
10
zerstörten Teilen des Netzwerks weiter miteinander kommunizieren können.
Die Kommunikationseinheiten sollen nicht voneinander abhängig sein und
eine vollständige Selbstständigkeit besitzen [Geb04]. In einem P2P-Netz
Client1
Client1
Client1
Server
Client1
Client1
Client1
Client1
Client1
Abbildung 2.1: Client-Server-Netzwerk
[Weh05]
Abbildung 2.2: Dezentralisiertes
Netzwerk [Weh05]
P2P-
sind die Nutzer, wie in Abbildung 2.2 dargestellt, nicht mit einem Server
verbunden, welche das gesamte Netzwerk organisieren und verwalten. Das
heißt, dass sich ein P2P-basiertes System selbst organisiert. Anders als bei
einem klassischen CSN (siehe Abbildung 2.1) sind die User in einem P2PNetz gleichberechtigt und sowohl Client als auch Server. Die Nutzer haben
keine Kenntnis darüber, ob sie gerade als Client oder als Server in dem
jeweiligen Netzwerk fungieren [Fis03, Weh05].
Vorteil gegenüber CSN
Die Vorteile zu einem CSN sind, dass gegebenenfalls lediglich Server eingesetzt werden, um Listen mit Informationen zu speichern und keine großen
Datenmengen. Die Datenteile werden auf den Rechnern der teilnehmenden
Clients gepuffert und dann bei Bedarf weitergeleitet, so dass lediglich in
hybriden Systemen eine Minderheit an Teilnehmer mit einem Datenserver verbunden sein muss. Durch die Speicherung der Datenteile auf den
einzelnen Rechnern ergibt sich der nächste Vorteil eines P2P-Netzes. Das
Netzwerk wird zuverlässiger und bei einer hohen Anzahl von Teilnehmern
kann die Gesamtheit der gewünschten Datenmenge in einer schnelleren
11
Zeit empfangen werden. Dies führt zu weniger Abbrüchen während einer
Übertragung. Beim CSN müssen die jeweiligen Server ständig erreichbar
sein. Dabei kann es bei einem Ausfall eines Servers zum Zusammenbruch
des Netzwerkes kommen [Fis03, Weh05].
Das P2P-Netzwerkmodell wird in verschiedene Ansätze unterteilt, wie in
Abbildung 2.3 gezeigt wird. Zu denen gehören der unstrukturierte Ansatz
sowie auch der strukturierte Ansatz.
2.1.1 Unstrukturierter Ansatz
Im Rahmen des unstrukturierten Ansatzes ist das Gnutella-Netzwerk
[Sha01] zu benennen. Dieses wurde ursprünglich zum Austausch von Musikdateien in verschiedene Formate und später für Voice-over-InternetProtocol (VoIP) und Web-TV genutzt. Sobald ein Nutzer im Netzwerk
eine Anfrage stellt, sendet dieser eine Broadcast-Nachricht an alle Teilnehmer in dem jeweiligen Netz. Wenn mehrere Teilnehmer die gesuchte
Datei gespeichert haben, werden diese in kleine Teile zerlegt. Der suchende Client bekommt dabei, unwissend von wem die Dateistücke sind, seine
gewünschte Datei von unterschiedlichen Peers. Der unstrukturierte Ansatz
ist daher gut für das P2P-IPTV geeignet. Bei dem Empfang des Streams
erhalten die Nutzer keine Information darüber, von welchem Peer der Teil
des Streams gesendet wurde.
Der unstrukturierte Ansatz wird in verschiedene Systeme unterteilt, zu denen das zentralisierte-, dezentralisierte sowie das hybride System gehören.
Zentralisiertes System
Das zentralisierte System ähnelt einem CSN, da alle Peers mit einem
Server verbunden sind. Jedoch dient der Server nicht dazu Dateien zu
speichern und weiterzuleiten, sondern lediglich um Suchanfragen zu bearbeiten und den suchenden mitzuteilen, welcher Client die gewünschte
Datei besitzt. Der Server ist ebenfalls nicht für den Verbindungsaufbau
12
zwischen den Clients zuständig. Dies wird zwischen den Teilnehmern
selbst organisiert [Bau04]. Die in Frage kommenden Peers senden die
Dateistücke direkt an den Suchenden. Die Server im Netzwerk speichern
keine Dateien, sondern ausschließlich Informationen über den Nutzer und
deren Ressourcen. Dies ist an dem Beispiel des IPTV-Netz zu erkennen.
Dort werden die Informationen in einem sogenannten Tracker-Server
gespeichert.
Vorteile dieses Systems sind die Zuverlässigkeit und die Schnelligkeit
für das Finden gewünschter Daten, da diese als Liste auf den Servern gespeichert sind. Der Nachteil des Systems ist die fehlende Robustheit. Fällt
der Server aus müssen sich die Peers im gesamten Netzwerk selbstständig
erkundigen, welche Peers den gewünschten Stream verteilen [Dus].
Dezentralisiertes System
Das dezentralisierte System wird auch als reines P2P bezeichnet. In
diesem System gibt es keine Server und die Clients verwalten und organisieren sich komplett selbstständig. Auch in diesem Netz sind alle Peers
gleichberechtigt und können sowohl Sender als auch Empfänger sein. Die
umgangssprachliche Bezeichnung für solche Clients ist ’Servent’ [Bau04].
Die zentrale Steuereinheit, welche für die neu einsteigenden Clients
in das Netzwerk zuständig ist, entfällt in diesem Falle, da die Teilnehmer
direkt miteinander kommunizieren. Dies ist bei der Verbindungsaufnahme
zu den Peers in einem Netz der Fall, in welchem Television (TV)-Streams
weitergeleitet werden. Die Suchanfragen in einem dezentralisierten System
werden mit einem Time-To-Live (TTL)-Zähler vor Überlastung des Netzes
gesichert. Ein Peer sendet eine Suchanfrage für eine Datei an seinen
Nachbarn, dieser dekrementiert den TTL-Zähler um 1 und sendet die
Anfrage an den nächsten Nachbarn weiter. Hat die Suchanfrage auf dem
bisher zurückgelegten Weg nichts ergeben, wird die Suche abgebrochen,
13
Peer-to-Peer-Systeme
Unstrukturierte Systeme
Zentralisiert
Strukturierte Systeme
Dezentralisiert
Hybrid
DHT
Routing
Table
Routing
Table
Routing
Table
Routing
Table
Abbildung 2.3: Übersicht P2P-Systeme [Kaf12]
wenn der TTL-Zähler 0 erreicht hat. Der Client, welcher die Anfrage in
das Netz geschickt hat, wird durch eine Nachricht der Zeitüberschreitung
informiert und die Suchanfrage wird aus dem Netz entfernt [Dus, Fis03].
Der wegfallende Single-Point-of-Failure ist dabei ein Vorteil. Das bedeutet,
dass das System bei einem Ausfall eines Peers nicht zusammenbricht,
sondern die Teile der Streams von anderen Peers empfangen werden.
Der Nachteil ist, dass nicht alle Peers im Netzwerk bei Anfragen erreicht
werden, da die Aufgabe nach der TTL erlischt. Diese erreichten Peers
haben eventuell eine noch geringere Upload-Rate und die Performance des
gesamten Netzwerkes wird noch geringer.
Hybrides System
Bei einem hybriden System besitzen die neu zu implementierenden Knoten
eine Liste mit ihren eigenen Informationen, welche an einen Server gesendet werden. Dieser Server, welcher in einem P2P-basierten IPTV-Netzwerk
als Tracker-Server bezeichnet wird, leitet alle ankommenden Anfragen von
Clients an die dafür vorgesehenen Zielsysteme weiter. Die auszutauschen-
14
den Daten werden von den sich selber organisierenden Peers untereinander
verteilt [Bau11]. Bei den hybriden Systemen gibt es Teilnehmer, die sich
mit einer sehr hohen Bandbreite und sehr guter Erreichbarkeit herauskristallisieren. Diese werden SuperPeers genannt. Aufgabe dieser SuperPeers
ist es Anfragen aus dem Netzwerk entgegenzunehmen und diese an die
weiteren Teilnehmer in dem Netzwerk weiterzuleiten.
Peer 2
Peer 4
Peer 3
Peer 5
Peer 1
Server
Server
Peer6
Server
Peer 7
Peer 9
Peer 8
Abbildung 2.4: Ansicht eines Hybriden Systems [Akb11]
Um mit einem Netzwerk zu arbeiten, in denen SuperPeers vorhanden sind,
müssen die Netzwerkteilnehmer in Gruppen aufgeteilt werden. In diesen
Gruppen muss mindestens 1 SuperPeer vorhanden sein. Sollten mehrere dieser Hochleistungsrechner existieren, erhöht das die Robustheit des
Netzwerks [tea11, Man06].
Bei den hybriden Systemen werden Protokolle wie das e-Donkey-Protokoll
genutzt, welches vom Unternehmen MetaMachine Inc. im Jahr 2000 entwickelt wurde. Das eDonkeyProtokoll hatte zu dieser Zeit eine große Bedeutung. Es wird beispielsweise beim File-Sharing eingesetzt [Kau11, Akb11].
15
2.1.2 Strukturierter Ansatz
Die Unterscheidung der strukturierten zu den unstrukturierten Netzen liegt
in der Suchstruktur, wobei die strukturierten Netze als Grundlage dafür
die Distributed Hash Tables (DHTs) nutzen.
DHTs
Bei den DHTs wird jedem Client ein eindeutiger Schlüssel zugewiesen, was
eine schnellere Antwort auf eine Suchanfrage in einem Netzwerk ermöglicht.
Weiterhin arbeitet jeder Peer als ein Server. Mittels des Schlüssels ist es
den Peers möglich, die entsprechenden Daten zu finden [Dus]. Wenn ein
Peer eine Suchanfrage erhält, durchsucht dieser zuerst das eigene System,
ob dieses das Zielsystem für die Anfrage darstellt. Sollte das nicht der Fall
sein, leitet dieser die Anfrage zu anderen Peers weiter, bis das richtige
System gefunden wurde.
Die Einbindung eines neuen Peers in das Netzwerk läuft ebenfalls
unproblematischer und schneller ab, als bei anderen Systemen. Hierbei
wird ein neu hinzukommender Knoten mit allen Daten seiner Nachbarn
versorgt, die jeweils seine Zuständigkeit verlangen [Dus].
2.2 P2P-IPTV
Das IPTV erlangt derzeit immer mehr an Bedeutung und stellt eine immer
größere Konkurrenz für das Fernsehen über herkömmliche Empfangsarten
dar. So kommt das Signale nicht mehr über ein Koaxialkabel oder eine
Satellitenschüssel, sondern über die Datenleitung und wird in Paketform
gesendet. Die sonst bekannte Übertragung des Fernsehsignals über die
Frequenz wird bei dem IPTV außen vor gelassen und so per User Datagram Protocol (UDP) oder Transmission Control Protocol (TCP) zu den
Verbrauchern übertragen.
16
Bei der deutschen Telekom AG gab es im Geschäftsjahr 2011 12,3 Millionen
Kunden mit einem Breitband-Anschluss, wovon 1,6 Millionen das IPTVAngebot T-Entertain abonniert hatten [AG11]. Da es bei der Telekom
keine P2P-basierte Übertragung gibt, laufen die Server auf Hochleistung.
Wollen nun alle 1,6 Millionen (Zahl bis Ende 2011) den selben Kanal
abonnieren, kann es zu einem Serverausfall kommen, da dieser die Flut an
Anfragen nicht mehr beantworten kann.
IPTV-Anbieter wie die Deutsche Telekom AG oder Telefonica nutzen
CSN, um Daten zu übertragen. Anbieter wie Zattoo wollen die Serverlast
verringern und nutzen daher das immer weiter voranschreitende P2PSystem [HT10]. Bei dem IPTV ist es den Anbietern wichtig, die Daten
einer Live-Übertragung schnellst möglich an die anfordernden Peers zu
übertragen, die sogenannte Übertragung in Echtzeit. Dabei existiert eine
harte Echtzeit die aussagt, dass eine Live-Übertragung in einer bestimmten Zeit bei dem Verbraucher ankommen muss. Dem gegenüber steht
die weiche Echtzeit, bei dem es ebenfalls Zeitkriterien gibt, diese jedoch
lediglich als Richtwerte anzusehen sind. Bei der harten Echtzeit wird bei
einer Zeitüberschreitung ein Fehler ausgegeben.
Zum Übertragen von Live-Streams in einem P2P-Netzwerk ist es erforderlich, ein Übertragungsprotokoll einzusetzen mit dem die Möglichkeit
besteht, Daten zwischen den Clients zu übertragen, ohne einen Server
zur Verwaltung zu verwenden. Das dafür geeignete Protokoll ist eine
BitTorrent-Spezifikation (siehe Abschnitt 2.2.3 und 3.2).
2.2.1 Grundarten
Die zwei Grundarten des IPTV sind zum einen das Live-Video-Streaming
und zum anderen Video-on-Demand. Beim Live-Video-Streaming ist es
möglich, ein zur selben Zeit laufendes Programm, dass permanent eingespeist ist, im Internet anzusehen. Dieser Stream wird als Multicast an das
17
Netz gesendet. Der Nutzer hat hier jedoch keine Möglichkeit das laufende
Programm anzuhalten und zu einer beliebigen Zeit an der selben Stelle
wieder weiterlaufen zu lassen [HT10]. Anders ist es bei Video-on-Demand.
Hier können User zu jeder beliebigen Zeit Filme und Sendungen starten.
Diese Sendungen laufen nicht zeitgleich im Fernsehprogramm, sondern sind
auf den Servern gespeichert.
2.2.2 Struktur
In einem Netzwerk, in dem Live-Streams von IPTV gesendet werden,
sind verschiedene Hardware-Komponenten notwendig. Es muss mindestens einen Tracker-Server geben, der die im Netz befindlichen Peers
mit Informationen über andere Peers versorgt (Schritt 2 in Abbildung 2.4).
SourceServer
TrackerServer
2
1
Peer
Neuer
Peer
3
Teilstream
Teilstream
3
Peer
Teilstream
Peer
Peer
Teilstream
Abbildung 2.5: Verbindungsstruktur
Des Weiteren muss es einen Source-Server geben (Schritt 1 Abbildung 2.4),
der die Informationen weiterleitet, die den Nutzern die gewünschten Inhalte
liefern. Der Source-Server dient dazu, die Anfragen der Peers entgegenzunehmen, welche einen Live-Stream anfordern, so dass dieser dann dem Peer
diejenigen Peers mitteilt, von denen er den Stream erhält. Diese werden in
Schritt 3 in Abbildung 2.4 untereinander ausgetauscht.
18
Bei dem P2P-IPTV wird der gesamte Stream in kleine Teile (Chunks) zerteilt, damit die Möglichkeit besteht, den Stream von mehreren Quellen
parallel herunterzuladen.
Tracker-Server
In einem Netzwerk mit BitTorrent-Spezifikationen ist es notwendig, einen
Tracker-Server zu implementieren. Der Tracker-Server enthält eine Liste
von den vorhandenen Peers in einem Netzwerk, mit der Peer-Identification
(ID) sowie den Kanälen, welche die Peers gebucht haben und verteilen.
Jeder neu in das Netzwerk eintretende Client nimmt Verbindung mit dem
Tracker-Server auf und meldet sich bei ihm an. Die Daten, welche bei der
Anmeldung ausgetauscht werden, sind Informationen über die Identität
der einzelnen Peers.
Bei jeder neuen Anforderung eines Kanals wird der Tracker-Server informiert. Dieser teilt dem anfragenden Peer mit, welche weiteren Peers im
Netzwerk den selben Stream herunterladen und weiter verteilen. Parallel
erweitert dieser seine Liste über die Informationen zu den bestehenden
Peers im Netzwerk, damit die Verteilung der Streams bei weiteren Anfragen noch schneller durchgeführt werden kann.
2.2.3 BitTorrent-Technik
Das verwendete Protokoll zur Übertragung von Daten und Live-Streams
im Internet ist das 2001 von Bram Cohen entwickelte BitTorrent-Protokoll.
Das für das P2P-IPTV erweiterte BitTorrent-Protokoll ist eine sogenannte Echtzeit-Version des für File-Sharing-Programme entwickelten Protokolls [www12]. Es baut jedem Stream ein eigenes Netzwerk zur Datenverteilung auf, so dass die Daten nicht durch ein übergreifendes File-SharingNetzwerk laufen müssen.
Wie es für P2P-Anwendungen von Vorteil ist, können über BitTorrent parallel Streams übertragen werden und das zusätzlich von unterschiedlichen
19
Peers. Es existiert lediglich ein Server zur Verwaltung einer Liste mit Netzwerkteilnehmern, der sogenannte Tracker. Die Peers verwalten sich jedoch
selbstständig [Xyl09].
2.3 Vergleich der Übertragungsarten
Auch bei einem Vergleich zwischen den herkömmlichen Übertragungsarten
und dem P2P-IPTV gibt es Unterschiede. Dazu wurde ein Experiment
durchgeführt, in dem die Verzögerungen deutlich herausgestellt wurden [Hei12]. Da das IPTV in diesem Test keine Rolle gespielt hat, wurde
es in einem weiteren Experiment eigenständig hinzugefügt.
Übertragungsart
Latenz/ s
Analog Kabel
0
Satellit SD
1
Digital Kabel SD
2
Digital Kabel HD
2
DVB-T
2
Sattelit HD
3
P2P-IPTV
50
Tabelle 2.1: Vergleich der Übertragungsarten [Hei12]
Das Ergebnis dieses Tests zeigt deutlich, dass nicht nur beim P2PIPTV Verzögerungen auftreten, sondern auch bei anderen Empfangsmöglichkeiten. So ist beim analogen Kabel-TV die geringste
Verzögerung festzustellen, die im Vergleich mit den anderen Arten
0,2 s Latenz hat. Dagegen ist die größte Verzögerung beim Empfang
mittels einem Satelliten High Definition (HD)-Anschluss zu verzeichnen.
Das digitale Kabelsignal und auch Digital-Video-Broadcasting-Terrestrial
(DVB-T) hatten untereinander keine Verzögerung, sind jedoch noch
später bei dem Empfänger als das analoge Kabelsignal [Hei12]. Das mittels analogem Kabel bei einer Live-Übertragung eines Fußballspiels am
20
ehesten gejubelt werden kann, ist damit zu begründen, dass das Signal für
einen digitalen Empfänger zunächst einmal aufbereitet werden muss. Das
analoge Signal wird dabei über einen Analog-Digital (A/D)-Wandler in
ein digitales Signal umgewandelt.
Dieses Experiment wurde erweitert, indem ebenfalls ein Test zwischen
einem analogen Signal und dem P2P-Empfang durchgeführt wurde. Die
am besten geeignete Möglichkeit war eine Live-Übertragung während eines
Fußball-Spiels bei der Europameisterschaft (EM) 2012. Dazu wurde das
analoge Signal vom Zweites Deutsches Fernsehen (ZDF) mit dem P2Pbasierten Stream von Zattoo [www11, www08] verglichen. Aufgrund der
angezeigten Spieldauer war zu erkennen, dass über Zattoo der Live-Stream
um 50 s später zu sehen war als bei ZDF.
21
3 Konzept
Um die P2P-basierten IPTV-Protokolle simulieren zu können, ist es utopisch, ein reales Netzwerk aufzubauen. Ein objektives Ergebnis erhält man
daher mit Simulatoren, die ein P2P-Netz mit allen gewünschten Eigenschaften darstellen können.
Da die Bandbreite in den Netzwerken aufgrund der Upload-Rate voll ausgelastet ist, ist es den Peers fast unmöglich, weitere Funktionen im Internet
wie beispielsweise VoIP oder Online-Gaming neben dem IPTV zu nutzen.
Mit einem Simulator, der an der Karlsruher Universität entwickelt und bereitgestellt wurde, soll dieses Projekt realisiert werden. Zum einen soll der
Simulator mit einer an die Realität angepasste Umgebung dargestellt und
zum anderen sollte alles von einem Arbeitsplatz aus durchgeführt werden,
um Zeit und Platz zu sparen.
3.1 P2P-Protokolle
Um Verbindungen zwischen Peers herstellen und Daten und Streams austauschen zu können, müssen P2P-basierte Programme das Open-SystemInterconnection (OSI)-Modell in der Schicht 7 (Anwendungsschicht) durchlaufen. Im Folgenden durchlaufen die Pakete die Transportschicht, die 4.
Schicht im OSI-Referenz-Modell. In dieser Schicht wird primär TCP zur
Übertragung von größeren Datenmengen genutzt. Diese Datenmengen werden in Blöcke aufgeteilt. Es wird allerdings auch UDP, welches sich für eine
zustandslose Kommunikation eignet, verwendet. Ein Vorteil von P2P kristallisiert sich auf Schicht 4 deutlich heraus. Eine einzige Anwendung erzeugt
22
durch TCP und UDP eine Vielzahl von Instanzen auf der 4. Schicht [Xyl09].
Dadurch wird eine enorm hohe Datenrate in einem Netzwerk, in dem viele
Nutzer integriert sind, erzeugt. Da die Nutzer den Austausch der Daten
und Streams selber organisieren und nicht auf Server angewiesen sind, sind
auch keine Netzausfälle durch überlastete Server zu erwarten.
3.2 BitTorrent-Spezifikation
Das zur Übertragung verwendete Protokoll ist eine Spezifikation des vom
File-Sharing bekannten BitTorrent-Protokolls. Das BitTorrent-Protokoll
nutzt eine Vielzahl kleiner Datenblöcke, die unterschiedliche Informationen zu gesuchten Daten enthalten. Zu den Informationen gehören unter
anderem Informationen wie der Tracker, verschiedene Dateinamen und die
Blockanzahl mit der jeweiligen Prüfsumme. Die Datenübertragung findet
jedoch nicht im BitTorrent Netzwerk statt, sondern wird über Hypertext
Transfer Protocol (HTTP) oder File-Transfer Protocol (FTP) übertragen
[Deg08]. Die zu übertragenden Dateien können eindeutig identifiziert werden. Durch einen geeigneten Code ist es möglich, die Quelle der Datei
ausfindig zu machen. Der von BitTorrent verwendete Code ist der Message
Digest Algorithm 5 (MD5)-Code.
Message Digest Algorithm 5
Dieser Code ist in der Lage, aus einer beliebig langen Nachricht eine 128Bit-Prüfsumme zu erzeugen. Die angeforderten Dateien werden dann mit
der jeweiligen Prüfsumme verglichen. Tritt ein Fehler auf, werden diese
Dateien erneut heruntergeladen. Dies muss gegebenenfalls auch von einer
anderen Quelle übernommen werden. Die Datei, welche heruntergeladen
wird, muss hingegen bestätigt werden. Das erfolgt indem die Prüfsumme
nach dem Herunterladen in einer extrahierten Datei mitgeteilt wird. Die
Prüfsumme der erhaltenen Datei kann über verschiedene Programme er-
23
rechnet und dann mit der mitgeteilten MD5-Prüfsumme verglichen werden. Sofern beide Summen identisch sind, ist die Vertraulichkeit der Datei gewährleistet. Hinsichtlich der Sicherheit, die vor allem in einem P2PNetzwerk gewährleistet sein sollte, ist man mit dem MD5-Code auf der sicheren Seite. Im Jahr 1994 wurde eine Weiterentwicklung des vorher noch
auf Fehlern basierenden Codes MD4 vorgenommen.
Nachdem die Daten vollständig von einem Client erhalten wurden, wird
die gesamte Datei wieder gesplittet, damit eine schnelle Weiterverteilung
möglich ist. Die einzelnen Teile werden den anderen Peers im Netzwerk zur
Verfügung gestellt, sobald ein Teil einer Datei von einem Peer heruntergeladen und die Prüfsummen verglichen wurden. Der Tracker-Server wird
darüber benachrichtigt und kann somit die anderen Clients informieren.
3.2.1 Tracker-Protokoll
Im BitTorrent-Netzwerk bildet der Tracker-Server die zentrale Instanz.
Diese zieht ein geringeres Ausfallrisiko mit sich, wenn mehrere Tracker
zur Verfügung stehen. Der Ablauf der Übertragung einer BitTorrent-Datei
erfolgt über die Bildung der Info-Hash. Die Datei wird dann auf eine
Prüfsumme abgebildet und bringt den Vorteil mit sich bringt, dass nicht
mehrere Hashes in einem Netzwerk existieren und weitergeleitet werden
können. Es existieren keine Dateien, die mehrere Namen in dem Netzwerk
aufweisen [Deg08, Xyl09].
Wird ein Client gestartet, so erzeugt der BitTorrent-Client eine sogenannte Peer-ID, die einmalig in dem Netzwerk vorkommt und eindeutig
zugewiesen werden kann. Die Verbindung zwischen einem BitTorrentClient und einem Tracker wird mittels HTTP hergestellt. Dazu wird
die Peer-ID sowie weitere Zusatzinformationen in einem HTTP-Request
übergeben. Diese genannten Informationen sind nicht für die Erkennung
notwendig [Deg08, Xyl09]. Die Verbindung in einem BitTorrent-Netzwerk
erfolgt in Schicht 4 des OSI-Modells mittels TCP. Der Verbindungsaufbau
24
Peers 1
Peers 2
Tracker
Peers 3
Peers 5
Peers 4
Abbildung 3.1: Arbeitsweise von BitTorrent [20112]
bei TCP wird durch gegenseitiges Senden von Paketen vorgenommen,
in denen eine Zeichenkette an den zu erreichenden Client gesendet wird.
Umgangssprachlich wird dieser Vorgang als Handshake zwischen den
Peers bezeichnet. Außerdem sind in den Paketen die Peer-ID sowie die
Info-Hashes vorhanden. Als Bestätigung, dass eine Verbindung hergestellt
ist, antwortet der benachrichtigte Client mit der gleichen Zeichenkette.
Die Schwachstelle dieser Übertragungsmethode ist jedoch, dass keine
sicheren Verbindungen hergestellt werden können, da die Inhalte nicht verschlüsselt werden. Die einzige Verschlüsselung wird dahingehend genutzt,
um den Internet Service Provider (ISP)-Filter zu umgehen.
3.2.2 Peer-Wire-Protokoll
Die Peers verbinden sich mit dem Dreiwege-Handshake. Die Verbindung
kann eingegangen werden, sobald die Peers von dem Tracker die Information haben, welcher Client den gewünschten Stream besitzt. Die Peers lernen
immer wieder neue Nachbarn und Nutzer des Netzwerkes kennen, da sie in
regelmäßigen Abständen eine Verbindung mit dem Tracker-Server aufnehmen und die aktualisierte Liste der Nutzer im Netz vorfinden. Durch die
Implementierung des nodeMaxCon-Befehls ist eine maximale Begrenzung
von Verbindungen vorgegeben.
25
3.3 Überlegung zur Ersparnis der Bandbreite
Der P2P-IPTV-Stream hat aufgrund der Asymmetrie zwischen Downund Upload, im Gegensatz zu anderen Übertragungsarten, eine Latenz
von 50 Sekunden von der Quelle der ausstrahlenden TV-Anstalt bis zum
Empfänger. Die Bandbreite ist bei P2P-Netzwerken im Upload voll ausgelastet, jedoch nicht im Download. So ist zu vermuten, dass bei einigen
Netzwerken durch diesen Unterschied viel Bandbreite verschenkt wird, aufgrund der geringeren Upload-Rate im Gegensatz zur Download-Rate. Da
die User vor der Zeit des P2P-IPTV weniger Anfragen gesendet haben,
war die Upload-Rate geringer. Dies bedeutet, dass die Teilnehmer in einem
Peer 4
Peer 5
Peer 1
DSLAMs
Peer 6
Bandbreitenersparnis
Peer 2
DSLAMs
Peer 7
Backbone
Peer 3
Peer 8
Upload
Download
DSLAMs
Peer 9
Abbildung 3.2: Darstellung des Konzeptes
Netzwerk, aufgrund der asymmetrischen Raten, nicht in der Lage sind, mit
gleicher Schnelligkeit Datenpakete weiterzuleiten wie empfangen können.
Dadurch wird die gesamte Bandbreite im Netzwerk auf die Upload-Rate
der einzelnen Peers herunter dividiert. Damit geht ein Großteil der Effizienz
verloren.
26
Lösungsansatz
Eine Lösungsvariante ist die Überlegung, dass die Streams in den Digital Subscriber Line Access Multiplexers (DSLAMs) der jeweiligen Netzbetreiber für die verschiedenen Teile des Netzwerkes zwischengespeichert
werden. Die DSLAMs übernehmen dann sinngemäß die Aufgabe eines Servers, der den Stream speichert und an die Nutzer weiterleitet, welche den
Stream anfordern. Der eigentliche Peer, der vorher sowohl herunter- als
auch hochladen musste, macht nichts weiter, als eine Anfrage zu senden
um einen Stream anzufordern und diesen zu empfangen. Außerdem muss
er den DSLAMs informieren, an welche Peers dieser weiterleiten muss. So
kann die Latenz verringert werden, da die Übertragungsstrecke vom Peer
zum DSLAMs bei der Weiterverteilung gespart wird.
Die Bandbreite kann so für weitere Aufgaben genutzt werden, beispielsweise für VoIP oder andere Online-Aufgaben, die eine hohe Upload-Bandbreite
erfordern. Die Peers werden somit entlastet und übergeben ihre Aufgaben
den DSLAMs. Dieses Vorhaben muss in allen DSLAMs durchgeführt werden. Sollte in einem Netzwerk eine Umrüstung nur in einigen Knoten vorgenommen werden und in anderen Zweigen weiterhin die Peers den Stream
weiter verteilen, ist die Ersparnis, die sich mit diesem Konzept erzielen
lässt, hinfällig.
27
4 Umsetzung und Implementierung
Die nachfolgende Beschreibung der Implementierung zur Simulation eines P2P-basierten IPTV-Konzeptes basiert auf dem vorhandenen Projekt
P2PTVSim von Omnet++.
4.1 Einarbeitung in die Simulation
Der Simulator, welcher für die beschriebene Aufgabe ausgewählt wurde, ist
der auf Eclipse basierende Simulator Omnet++ in der Version 4.2.2. Mit
der Network Describtion (NED)-Language ist es dem Simulator möglich,
Netzwerke in einer Größenordnung von 2 - 400 Knoten und deren Datenverkehr zu simulieren. Die Simulation wurde mit dem Plugin P2PTVSim
durchgeführt. Dazu steht ein Netzwerk mit 50 Knoten sowie ein TrackerServer als auch mehreren Source-Server zur Verfügung. Für die Implementierung wurde die Software auf dem Betriebssystem installiert. Das verwendete Betriebssystem ist Windows 7 Professional. In erster Instanz wurde
die Simulationsumgebung Omnet++-4.2.2 konfiguriert, so dass in den weiteren Schritten die für die Simulation nötigen Plugins hinzugefügt werden
konnten.
4.1.1 Grundlegende Einstellungen
Nachdem Anlegen eines Workspaces konnte das Netzwerk bearbeitet und
erstellt werden, so dass die gewünschte Simulation durchgeführt werden
konnte. In die Simulation wurden sowohl einfache Peers mit der Funktiona-
28
lität normaler Clients als auch SuperPeers, die eine höhere Performance als
andere Peers im Netzwerk besitzen, eingebaut. Die Peers holen sich die Informationen der anderen Peers und entscheiden aufgrund der Performance
und Bandbreite mit welchen Peers Verbindung aufgenommen werden soll.
Des weiteren ist ein Tracker-Server implementiert, mit dem die Peers in
Verbindung treten. Damit ist es ihnen möglich, Informationen über Anfragen zu erhalten, von welchem Peer diese beantwortet werden können. Der
Tracker nimmt Detailinformationen über neu in das Netzwerk hinzugefügte
Peers auf, so dass dieser bei Anfragen anderer Peers die neuesten Updates
über das Netzwerk zur Verfügung hat.
Nachdem die Peers einmal eine Verbindung mit einem anderen Peer über
den Tracker-Server aufgenommen haben, können diese ohne den Tracker
zu kontaktieren selbstständig mit den Peers in Verbindung treten. Sollte
der Tracker mit mehreren Anfragen beschäftigt sein, wird den Peers eine
Nachricht zurückgesendet, dass diese es zu einem späteren Zeitpunkt noch
einmal versuchen sollten.
Die Source-Server werden ebenfalls als Peers angesehen, wobei diese keine
Daten aus dem Netzwerk downloaden, sondern lediglich Informationen zu
Kanälen bereitstellen, die von anderen Peers aus dem Netz angefordert werden. Wenn genügend Peers den selben Kanal abonniert haben, wird dieser
an die anderen Nutzer über das BitTorrent-Protokoll in kleinen Paketen
weitergeleitet.
4.2 Simulator
Für das Projekt der P2P-basierten IPTV-Simulation ist das Plugin
P2PTVSim der Plattform Omnet++ geeignet. Das Framework Omnet++
soll der wissenschaftlichen Arbeit dienen und ist für solche Zwecke als
Open Source Software erhältlich. Mit diesem Programm können sowohl
Netzwerkprotokolle simuliert als auch Analysen für die Leistungen durchgeführt werden. Die Benutzeroberfläche basiert auf der Eclipse-Umgebung,
29
die mit den verschiedensten Programmiersprachen genutzt werden kann.
Für das Projekt wurde die Sprache C++ gewählt, wobei Omnet++
ebenfalls mit den Sprachen C# und Java verwendet werden kann [Com09].
Die Anwendungsfälle, welche damit simuliert werden sollen, sind in der
Automatisierung sowie bei Multimedia-Streaming zu finden.
Omnet++ ist das einzige Programm, das sich für die Simulation
des P2P-IPTV qualifiziert hat. Omnet++ stellt eine geeignete Oberflächengestaltung dar sowie schon vorhandene zu implementierende
Programmcodes. Mit dem Programm können die benötigten Tracker
Server sowie verschiedene Peers und Netzwerkknoten dargestellt werden,
welche miteinander kommunizieren können. Zudem wird die benötigte
Zeit, die ein Stream zu einem Peer zurücklegt, aufgezeigt, so dass die
Latenz gut erfasst werden kann.
4.3 Simulation
Teilumgebung
Um eine reale Testumgebung erreichen zu können, wurden die Einstellungen in einer .ini Datei so festgelegt, dass das Netzwerk aus 100 PeerNodes
besteht. Zusätzlich wurde ein Tracker-Server sowie 10 SuperPeers und 5
Source-Servern implementiert.
Für die erste Simulation wurde die Down- zu Upload-Rate optimiert. Dabei wurde davon ausgegangen, dass bei einem Stream im Upload genau die
selbe Anzahl von Daten hochgeladen wird, wie im Download heruntergeladen wurde. Dass heißt, dass trotz der asymmetrischen Verteilung zwischen
Down- und Upload, die Daten vollständig weitergeleitet werden sollen. Das
Zeitlimit wurde für die erste Simulation auf 30 Sekunden eingestellt.
30
Laufzeiteinstellungen
Beim Start der Simulation ist das Szenario auszuwählen, unter welchen
Einstellungen das System getestet werden soll. Zu wählen ist unter 5 verschiedenen Szenarien, die alle unterschiedliche Einstellungen mit sich bringen. Die Einstellungen umfassen die Simulationszeit sowie die Bandbreite
im Down- und Upload, aber auch die zur Auswertung benötigte Auslastung. Nachdem die Auswahl der Szenarien getroffen wurde, kann die Simulation gestartet werden. Dabei ist es sinnvoll, die gesamte Simulation zu
überwachen, um im Anschluss eine grafische Auswertung vorliegen zu haben. Der Simulationsablauf wird aufgenommen und die Teilnehmer haben
damit begonnen, Pakete und Nachrichten auszutauschen.
Ablauf
Im ersten Schritt senden die Peers eine Nachricht an den Tracker, um
diesen damit zu informieren, dass die Peers in das Netzwerk integriert sind.
Der Tracker erweitert seine Liste über das bestehende Netzwerk, um so
schneller Anfragen bearbeiten zu können. Nachdem die Informationen aller
Teilnehmer verarbeitet wurden, konnten die Peers Kanäle anfordern. Die
Peers erhalten vom Tracker Informationen über mögliche Quellen. Diese
werden von den Peers kontaktiert und senden die gewünschten Streams
an die weiteren Peers. Wenn eine Anfrage an den Tracker gesendet wird,
dieser jedoch keinen positiven Eintrag in seiner Liste hat, wird dem Peer
eine Nachricht gesendet, dass dieser zu einem späteren Zeitpunkt seine
Anfrage wiederholen soll. Befindet sich kein Peer in dem Netzwerk, der den
angeforderten Stream enthält und verteilen kann, wird der Anfragensteller
direkt an den Source-Server weitergeleitet, so dass der Peer der erste im
Netz ist, der diesen Kanal verteilen kann.
Die Nutzer im Netzwerk richten sich nach der Upload-Rate der jeweiligen
Quellen der Streams. Die Download-Rate kann noch so hoch sein, doch der
Upload ist begrenzt und somit auch die Performance.
31
4.3.1 Testaufbau
Das zu simulierende Netzwerk wurde auf der Grundlage der
Geschäftsjahreszahlen der Deutschen Telekom AG aus dem Jahr 2011
erstellt. Die Simulation ist mit verschiedenen Laufzeiten durchgeführt
worden, so dass die Upload- sowie Download-Auslastung gut dargestellt werden konnte. Da die Download-Geschwindigkeit viel größer als
die Upload-Geschwindigkeit ist, wurden im Vorfeld der Simulationen
verschiedene Überlegungen getroffen.
Beschreibung der Szenarien
Eine Überlegung vor der Simulation war, dass die Upload-Auslastung
um ein Vielfaches höher ist, als die des Downloads. Daher wurden die
Bandbreiten der Szenarien dahingehend angeglichen und in der Testumgebung berücksichtigt. Für die Simulation wurde das erste Szenario mit
einer Download-Bandbreite von 17.000 kbps um ein Vielfaches höher,
als die Upload-Bandbreite mit 1.024 kbps, gewählt. Zudem wurden in
diesem Szenario die Anzahl der Peers mit 50 so gesetzt, dass ein objektives
Ergebnis erzielt werden konnte (siehe Tabelle 5.1).
In einem weiteren Szenario wurde die Bandbreite mit 10.000 kbps im
Download und 625 kbps im Upload den Peers zugeordnet worden, die eine
längere Strecke zu den DSLAMs hatten. Zudem wurde dieses Szenario mit
einer Anzahl von 25, 50 und 100 Peers durchgeführt. Diese Unterscheidung
sollte beweisen, dass mit einer steigender Anzahl von Netzwerkteilnehmern die Latenz verringert wird, da die Teil-Streams von mehreren Peers
empfangen werden können. Eine weitere Überlegung ist gewesen, dass die
Latenz bei einer längeren Simulationszeit ebenfalls größer wird. Dies beruht auf Grundlage dessen, dass die Streams nach dem Empfangen wieder
hochgeladen und weitergeleitet werden müssen. Da der Upload geringer
ist als der Download, ist zu erwarten, dass die Verzögerung des Streams,
32
der vom Source-Server in das Netzwerk ausgegeben wurde, mit einiger
Verzögerung bei den Peers ankommen wird. Bei Live-Übertragungen ist
es wichtig, dass die Streams in Echtzeit übertragen werden, also ohne eine
wahrzunehmende Verzögerung.
Download/ kbps
Upload/ kbps
Anzahl Peers
Streamlänge/ kB
Szenario 1
17.000
1.024
50
2.635
Szenario 2
10.000
625
25
2.635
Szenario 2
10.000
625
50
2.635
Szenario 2
10.000
625
100
2.635
Szenario 3
6.000
625
50
2.635
Szenario 4
2.000
125
50
2.635
Szenario 5
1.000
62,5
50
2.635
Ø
7.200
442,3
50
2.635
Tabelle 4.1: Szenarienübersicht
Im 3., 4. und 5. Szenario wurde die Teilnehmeranzahl jeweils auf 50 Peers
eingestellt, wobei lediglich die Bandbreiten verändert wurden. Dabei sind
die Bandbreiten im 3. Szenario auf 6.000 kbps im Download sowie 625
kbps im Upload gewählt worden. Für Anschlüsse, welche nicht in der
direkten Nähe eines DSLAMs angesiedelt sind, wie es auf vielen Dörfern
zur Zeit noch der Fall ist, wurden die Bandbreiten in den Szenarien 4
und 5 dementsprechend angeglichen. Dabei ist das Szenario 4 mit einer
Download-Rate von 2.000 kbps und einer Upload-Rate von 125 kbps
sowie in Szenario 5 mit einer Download-Rate von 1.000 kbps und einer
Upload-Rate vom 62,5 kbps festgelegt worden. Da nicht alle Peers die
selbe Bandbreite empfangen können, wurden in einem weiteren Szenario
die durchschnittlichen Werte der vorher verwendeten Szenarien eingestellt,
um ein noch objektiveres Ergebnis erzielen zu können. So wurden im
Download 7.200 kbps und im Upload 442,3 kbps verwendet. Die Simulationszeit wurde auf 30 Sekunden gesetzt.
33
4.3.2 Auswertung der Simulation
In einer EventLog-Datei, die während der Simulation erstellt wird, ist
deutlich abzulesen, welche Zeit zwischen Anforderung und Weiterleitung
der Streams vergeht. Zu Beginn der Simulation melden sich die Peers bei
dem Tracker-Server als Client im Netzwerk an.
Abbildung 4.1: Simulationsablauf-Diagramm
Die dabei verschickten Daten stehen in der Nachricht PeerToTracker (MsgP2T)-Datei und enthalten die PeerID, die auszuführende
Operation sowie Daten, die Information über den jeweiligen TV-Kanal
enthalten. Im weiteren Verlauf der Simulation senden die Peers eine An34
frage an den Tracker, welcher mit der Nachricht TrackerToPeer (MsgT2P)
antwortet. In dieser Antwort sind die verfügbaren Peers des Netzwerkes
aufgelistet, die den gewünschten Kanal besitzen und verteilen. Bis es zu
der Anforderung kommt, vergehen 2 s der gesamten Simulation. Nach
dieser Zeit beginnen die Peers untereinander Verbindungen herzustellen,
um die Streams austauschen zu können. Die Streams werden mit der
Nachricht PeerToPeer (MsgP2P) übertragen. In dieser Nachricht sind
ebenfalls die PeerID sowie Teile des gewünschten Kanals enthalten, die
als Stream übertragen werden.
Es wird die Zeit gemessen, wann eine Datei erhalten und nach welcher Zeit diese zu dem nächsten Peer weitergeleitet wurde. Aus den
Werten ist deutlich zu erkennen, dass die Peers durch die geringe UploadRate 1,24 s an Zeit verschenken. Im ersten Durchlauf der Simulation wurde
eine Download-Rate von 2,07 MB und eine Upload-Rate von 750 kBps
eingestellt. Nachdem die Simulation beendet war, war zu erkennen, wann
die Events gestartet wurden und welcher Peer den Stream empfangen
und weitergeleitet hat. Die bis dahin vergangene Zeit ist auf der x-Achse
abzulesen. Des weiteren stand eine Vektor-Grafik als Auswertung der
Ergebnisse zur Verfügung. Aus dieser Grafik konnte die Upload- sowie
Download-Performance der einzelnen Netzwerkelemente abgelesen werden.
In der Abbildung 5.1 wird ersichtlich, dass der Upload in seiner Performance mit 98% wesentlich mehr ausgelastet ist als der Download, welcher nur
20% Auslastung aufweist. Dies ist damit zu begründen, dass der Upload
zwar die gleiche Menge an Daten zu verarbeiten hat, jedoch eine höhere
Auslastung aufweist.
35
5 Auswertung
Für die Auswertung der verschiedenen Szenarien sind die Ergebnisse in Tabelle 5.1 dargestellt. Da nicht überall die selbe Bandbreite zur Verfügung
stand, wurden die Szenarien auf unterschiedlichen Bandbreiten sowie einer
unterschiedlichen Anzahl an Peers in einem Netzwerkknoten durchgeführt.
Die Einstellungen wurden so vorgenommen, dass die gleiche Menge an
Daten die heruntergeladen wird auch im Upload weiter verteilt wird. Um
ein reales Ergebnis zu erzielen, wurde die Paketlänge nicht variiert, denn
alle Teilnehmer empfangen einen gleichlangen Stream.
Download/ kbps
Upload/ kbps
Latenz/ s
Szenario 1
17.000
1.024
1,24
Szenario 2
10.000
625
2,36
Szenario 3
6.000
375
3,5
Szenario 4
2.000
125
10,54
Szenario 5
1.000
62,5
21,8
Ø
7.200
442,3
7,888
Tabelle 5.1: Latenz der einzelnen Szenarien
Die Ergebnisse der einzelnen Szenarien haben den Erwartungen entsprochen. Bei unterschiedlichen Bandbreiten im Down- sowie Upload hat sich
bezüglich der Performance nichts geändert.
Wenn die selbe Menge an Daten nach dem Herunterladen wieder hochgeladen wird, so ist die Auslastung des Uploads, aufgrund der niedrigen
Bandbreite, fünf mal höher als die des Downloads. Dieses Phänomen
ist in Abbildung 5.1 deutlich zu erkennen. Beim P2P-IPTV wird permanent ein Stream in Paketteilen verschickt, jedoch kann dieser nur
36
mit der selben Rate heruntergeladen werden, wie er von den anderen
Peers hochgeladen wird. In einem Netzwerk gibt es je nach Entfernung
der Clients zum DSLAMs immer wieder Unterschiede im Erreichen der
angeforderten Bandbreite. Clients bei denen vom DSLAMs keine weite
Strecke überbrückt wird, haben eine bessere Bandbreite zur Verfügung als
Clients die 3 km entfernt liegen.
120
Auslastung / %
100
80
Upload
Download
60
40
20
0
1
2
3
4
5
6
7
Simulationszeit / s
Abbildung 5.1: Auslastung des Up- und Downloads
In der Tabelle 5.1 ist die errechnete durchschnittliche Latenzzeit aller Peers
deutlich ersichtlich. Die Verzögerung nimmt mit niedriger werdender Bandbreite zu. Während bei einer Bandbreite von 17.000 kbps eine Verzögerung
von 1,24 s entsteht, liegt die Latenz bei einer Bandbreite von 1000 kbps
bei 21,8 s.
Bei Szenario 6 wurden die durchschnittlichen Bandbreiten aller Szenarien
ausgewertet. Dies ergab eine Latenz von 7,888 s. Zudem ließ sich feststellen, dass die Anzahl der Nutzer bei gleichbleibender Bandbreite ebenfalls
von Bedeutung war. Wie in Szenario 2 in Abschnitt 4.3.1 vermutet wurde,
hatte die Simulation mit 25 Peers eine Latenz von 2,6 s. Die Simulation
37
mit 50 Peers hatte nur noch eine Latenz von 2,4 s. Bei 100 Peers lag die
Latenz bei 2,1 s und hat damit die Erwartungen bestätigt, dass bei steigender Anzahl von Nutzern in einem P2P-Netz die Latenz verringert wird
und die Streams schneller weitergeleitet werden können.
Nach zwei Versuchen ein beschädigtes Paket zu versenden wurde ein neues
Paket generiert oder eine neue Quelle angefordert. Diese Szenarien passieren in einem realen Netzwerk häufig, aber auch dass Knoten ausfallen
oder fehlerbehaftete Datenpakete versendet werden. Die Zeit, um eine neue
Quelle für diese Teile im Netz zu finden, wirkt sich negativ auf die gesamte
Latenz des Streams aus.
5.1 Simulation mit verändertem Konzept
Die Simulation wurde dahingehend geändert, dass die Peers vom Upload
der Streams entlastet wurden und die DSLAMs die Teile weitergeleitet
haben. Der Quellcode der PeerNodes wurde so geändert, dass diese nur
herunterladen müssen. In diesem Fall sollen die Peers den Stream nicht
mehr weiterleiten.
In den DSLAMs wurde der Teil der Weiterleitung implementiert, so dass
diese die Aufgabe des Verteilens übernehmen. Da in den DSLAMs eine
symmetrische Bandbreite möglich ist und somit genauso schnell die Daten
empfangen, als auch weitergeleitet werden können, ist dies ebenfalls ein
Vorteil dieser Technik.
Die DSLAMs haben mit einer Bandbreite von 155 Mbps keine Probleme, die Daten schneller weiterzuleiten, als die Peers es können. Die
teilnehmenden Peers müssen also wie von den Entwicklern vorgesehen,
den Upload nur noch mit Anfragen von Kanälen belasten.
Wie aus den Ergebnissen aus Abschnitt 4.3.2 zu erwarten war, lässt sich
durch die Einsparung der Upload-Bandbreite auf der Strecke zwischen
Peer und DSLAMs, durch die Umstrukturierung, eine Zeit von 1,22 s in
38
der Übertragung sparen. Die Peers erhalten nun direkt von den DSLAMs
den Stream und die komplette Upload-Rate der Peers ist frei. Dadurch
wird die Upload-Rate der DSLAMs stärker in Anspruch genommen. Doch
sind die Bandbreiten eines DSLAMs mit 155 Mbps, im Vergleich zu einem
normalen Peer mit durchschnittlich 17.000 kbps, viel höher.
Verzögerung durch Download-Rate
Die einzige Verzögerung die auf dieser Strecke noch auftreten kann, ist den
unterschiedlichen Download-Raten der einzelnen Peers geschuldet. Diese
Verzögerungen belaufen sich jedoch auf 0 ms - 0,5 ms, je nach DownloadRate. Peers mit einer hohen Download-Rate bekommen das gesendete LiveBild schneller zu sehen und haben auf der DSLAMs - Peer Strecke nahezu
0 s Verzögerung. Bei Peers mit einer geringen Bandbreite, wie es in weiten
Teilen Deutschlands auf Dörfern der Fall ist, haben aufgrund ihres Downloads eine Verzögerung von bis zu 500 ms.
5.2 Fazit
Aufgrund der ausgewerteten Ergebnisse der Simulation lässt sich sagen,
dass sich das Konzept zur Verringerung der Latenz durch eine umstrukturierte Aufgabenverteilung lohnt (siehe Tabelle 5.2). Die Auswertung
hat unter anderem ergeben, dass die Peers in der Upload-Bandbreite
vollständig entlastet werden, indem nicht die Peers, sondern die DSLAMs
den Stream weiterleiten müssen. Die Bandbreite der Peers ist somit frei
für andere Aufgaben, beispielsweise für VoIP oder Online-Gaming.
Zudem wird durch die Auswertung ersichtlich, dass die Streams eine
geringere Latenz aufweisen. So ist festzustellen, dass es bei Peers mit einer
Bandbreite von 1024 kbps im Upload zu einer Latenzverringerung von
1,24 s kommt. Bei Peers mit einer geringeren Bandbreiten im Upload,
beispielsweise 62,5 kbps, ist eine Einsparung von 21,8 s zu erzielen. Da es
39
kein Netzwerk gibt, indem alle Peers die selbe Bandbreite erhalten, ist bei
einer Gleichverteilung der Bandbreiten im Mittel eine Latenz-Ersparnis
von 7,888 s erzielt worden. Bei einer Variation der Anzahl der Peers war
ebenfalls ersichtlich, dass bei einer geringen Anzahl die Latenz höher ist, als
bei einer hohen Anzahl. Dies bedeutet ebenfalls, dass es bei Kanälen, die
nur von wenigen Peers angefordert werden zu einer größeren Verzögerung
kommt, als bei Kanälen die von vielen Peers angefordert werden. Auch
hier spiegelt sich also wieder, dass das Konzept der Umstrukturierung
der Aufgaben lohnenswert ist und die Latenz so nicht mehr von der
Upload-Rate und von der Anzahl der Teilnehmer abhängt.
Ereignis
Ergebnis
Durchschnittliche Latenz der Szenarien vor der Umstrukturierung
7,888 s
Zeitersparnis nach der Umstrukturierung
7,85 s
Upload-Kapazität nach der Umstrukturierung
100 %
Latenz zu herkömmlichen Übertragungsarten
50 s
Tabelle 5.2: Ergebniszusammenfassung
Zwar liegt die Verzögerung im Gegensatz zu herkömmlichen
Übertragungswegen trotz verringerter Latenz immer noch hinter diesen,
doch ist mit einer weiterführenden Entwicklung eine weitere Annäherung
zu erwarten. Des weiteren ist festzustellen, dass die Auslastung des
Uploads vor der Umstrukturierung bei 100 % lag und damit die Peers
mit der Verteilung des Streams völlig ausgelastet waren. Nachdem die
Aufgabe der Verteilung den DSLAMs übergeben wurde, sind die Peers zu
99 % erreichbar.
Zusätzlich wurde die Latenz zu den herkömmlichen Empfangsarten im
Durchschnitt verringert und das P2P-basierte IPTV ist dem Live-TV
in Echtzeit ein Stück näher gekommen. Rechnet man die Zeitersparnis
nach der Umstrukturierung der Latenzzeit von davor entgegen, so sind
Empfangsarten wie Kabel- oder Satellit nur noch um 42 s schneller.
40
6 Zusammenfassung
Das P2P-basierte IPTV erfordert eine gute Performance im Bereich des
Uploads. In den bisher entwickelten Netzen kommt es immer wieder zu
Verzögerungen zwischen dem live gesendetem Bild und dem Empfang des
Streams bei einem P2P-IPTV-Teilnehmer. Bei den Bandbreiten kommt
es zu einer asymmetrischen Verteilung zwischen der Download- und der
Upload-Rate. Der Download ist um Faktor 16 größer als der Upload, dabei
sind immer wieder Verzögerungen in der Weiterleitung der Live-Streams zu
beobachten. Das beschriebene Konzept hat in der Umsetzung gezeigt, dass
es bei den unterschiedlichen Bandbreiten zu Einsparungen im Bereich der
Latenz kommt. Zudem wird der gesamte Upload der Peers frei und kann
für weitere Aufgaben z.B. VoIP genutzt werden. Bei einer Umrüstung aller
DSLAMs, um die Aufgaben der Peers übernehmen zu können, ist bei dem
ersten Szenario eine Zeitersparnis von 1,24 s festzustellen. Bei weiteren
Szenarien, in denen geringere Bandbreiten eingestellt wurden, waren die
Ersparnisse noch höher und stiegen bis zu auf 21,8 s bei einer Upload-Rate
von 62,5 kbps an. Aus den Werten der Tabelle 5.1 ist zu erkennen, dass
es im Mittelwert der eingestellten Bandbreiten zu einer durchschnittlichen
Einsparung der Latenz von 7,888 s kommt.
Es ist ebenfalls festzustellen, dass das P2P-IPTV mit den heutigen Entwicklungen und Erkenntnissen eine gute Alternative zum herkömmlichen
Empfang des TV-Signals darstellt. Im Hinblick auf andere Empfangsarten
hat die Simulation ebenfalls gezeigt, dass das P2P-IPTV den größten Unterschied zur Echtzeit liefert. Mit dem heutigen Stand dient dies doch eher
als sekundäre Variante des Empfangs.
41
Literaturverzeichnis
[20112] About Bit Torrent.
http://www.bittorrent.com/intl/de/
company/about. Version: 2012
[AG11] AG, Deutsche T.: Das Geschäftsjahr 2011 / Deutsche Telekom
AG. 2011. – Forschungsbericht
[Akb11] Akbari, S.M.Y Seyyedi B.: Hybrid CDN-P2P architectures for
live video streaming: Comparative study of connected and unconnected meshes. (2011)
[Bau04] Bauer, Matthias: Peer-to-Peer Überblick über Konzepte, Architekturen, Plattformen und aktuelle Entwicklungen. Grin Verlag,
2004
[Bau11] Baumgart, Ingmar: Verteilter Namensdienst für dezentrale IPTelefonie. Scientific Publishing, 2011
[Com09] Community, Omnet++: What is Omnet++. http://www.
omnetpp.org/home/what-is-omnet. Version: 2009
[Deg08] Degner, Klaus: Inhaltsbasierte Analyse des Tauschverhaltens in
P2P-Netzwerken, Universität Leipzig, Diplomarbeit, 2008
[Dus]
Dustdar, Manfred Hauswirth S.: Peer-to-Peer: Grundlagen und
Architektur.
[Fis03]
Fischbach, Detlef Schoder K.: Peer-to-Peer-Netzwerke für das
Ressourcenmanagement. WI-State of the Art, 2003
[Geb04] Gebhart, Sarah: Peer-to-Peer Data Management. 2004
42
[Hei12]
Heise: EM im TV: Wer zuletzt jubelt... / Heise Zeitschriften
Verlag. 2012. – Forschungsbericht
[HT10]
http://www.hit-tv.eu/IPTV.html
[Kaf12] Kafkar, Gerhard:
P2P (peer to peer network).
http://www.itwissen.info/definition/lexikon/
Peer-to-Peer-Netz-P2P-peer-to-peer-network.html.
Version: 2012
[Kau11] Kaune, Sebastian: Performance and Availability in Peer-to-Peer
content distribuiton systems: A case for a multilateral incentive
approach, Technische Universität Darmstadt, Diplomarbeit, 2011
[Man06] Mannl, Uwe ; BTU Cottbus (Hrsg.): Hierarchische Peer-toPeer-Netze. BTU Cottbus, 2006
[Sha01] Shahmehri, Ross Lee Graham N. (Hrsg.): Peer-To-Peer Computing. 2001
[tea11]
teaching.org e: Peer-to-Peer. http://www.e-teaching.
org/technik/vernetzung/architektur/peer-to-peer/.
Version: 09. 2011
[Weh05] Wehrle, Ralf Steinmetz K.: Peer-to-Peer Systems and Applications. Springer, 2005
[www08] www.zattoo.com:
Freeware der Woche: Internetfernsehen mit Zattoo.
http://www.netzwelt.de/news/
77437-freeware-woche-internetfernsehen-zattoo.html.
Version: 2008
[www11] www.zattoo.com: Deutsches Fernsehen kostenlos empfangen. http://www.netzwelt.de/download/6133-zattoo.html.
Version: 2011
[www12] www.bittorrent.com: BitTorrent: Dateien verteilen in ra-
43
santer Geschwindigkeit. http://www.netzwelt.de/download/
3456-bittorrent.html. Version: Januar 2012
[Xyl09] Xylomenos, Konstantinos Katsaros Vasileios P. Kemerlis Charilaos Stais G.: A BitTorrent Module for the OMNeT++ Simulator.
(2009)
44
Eidesstattliche Erklärung
Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit
selbstständig und ohne Benutzung anderer als der angegebenen Hilfsmittel
angefertigt habe. Die aus den Quellen direkt oder indirekt übernommenen
Gedanken sind als solche kenntlich gemacht. Die Arbeit hat mit gleichem bzw. in wesentlichen Teilen gleichem Inhalt noch keiner anderen
Prüfungsbehörde vorgelegen.
————————
Ort, Datum
————————
Unterschrift
45