Instant peer-to-peer media streaming for use in multi-party conferencing. - Masterarbeit

Transkript

1 Instant peer-to-peer media streaming for use in multi-party conferencing - Masterarbeit Institut für Softwaretechnik und Datenkommunikation Hochschule Mannheim Paul-Wittsack-Straße Mannheim Autor: Lyubomir Lyubenov Matr.-Nr.: Studiengang: Informationstechnik Betreuer: Prof. Dr. Eckhart Körner, Hochschule Mannheim Dipl. -Ing. Lothar Grimm, T-Systems ES GmbH, Darmstadt

2 Ehrenwörtliche Erklärung Ich versichere, dass ich die vorliegende Arbeit selbständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten und nicht veröffentlichten Schriften entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit hat in dieser oder ähnlicher Form keiner anderen Prüfungsbehörde vorgelegen. Mannheim, den Lyubomir Lyubenov

3 Abstrakt Application Layer Multicast (ALM) ist eine Technik, die in den letzten Jahren immer mehr an Bedeutung gewonnen hat. Sie basiert auf Peer-To-Peer (P2P) Kommunikation. Eine von vielen auf ALM basierenden Anwendungen ist das Video Streaming, auch in der Form als Live-Übertragung. Diese Arbeit beschäftigt sich zunächst mit ALM und den zugrunde liegenden P2P- Netzen. Die existierenden Ansätze für P2P-Netze werden eingeführt und nach ihren Architekturen klassifiziert. Des Weiteren wird eine freie Implementierung eines P2P- Protokolls namens Pastry vorgestellt, speziell mit ihrer Erweiterung SplitStream. SplitStream bietet eine API, die den Aufbau eines ALM für Live Video Streaming ermöglicht. Für die Medienübertragung kann dabei das Real-time Transport Protocol (RTP) eingesetzt werden. Weiterer Schwerpunkt dieser Arbeit ist das multi-party Conferencing mit dem SIP- Protokoll, welches die Signalisierung für die Audio- und Videokommunikation unter mehreren Endnutzern zur Verfügung stellt. Der praktische Teil dieser Arbeit befasst sich mit der Implementierung eines Plugins für den SIP User Agent (UA) SIP Communicator, welcher unter der GNU GPL Lizenz steht. Der SIP Communicator wird in Java entwickelt und setzt auf das dynamische Java Modulsystem OSGi auf, welches eine Service-Orientierte Programmierung ermöglicht. Die Aufgabe des für den SIP Communicator entwickelten Plugins ist der Aufbau eines ALM auf Basis von SplitStream, welches ein Live Video Streaming unter den Nutzern in einer multi-party Conference ermöglicht. Dafür wurde auch die SIP- Signalisierung des UAs erweitert, um SIP-basierte Konferenzgespräche zu unterstützen. Beispielszenarien für die Nutzung von P2P Live Video Streaming in Konferenzen sind das Einspielen eines Urlaubvideos oder die Live-Übertragung eines Popkonzerts in eine bestehende SIP Session. Derartige Szenarien werden in den aktuellen Conferencing Tools noch gar nicht unterstützt. Abschließend werden die Ergebnisse analysiert und die weiterführenden Aufgaben definiert.

4 Abstract In the past few years Application Layer Multicast (ALM) gained more and more importance. Peer-to-peer (p2p) networks catalyse the importance of this new technology. There are different applications based on ALM. One of them is live video streaming. In this master thesis, we describe at first the p2p technology. Then we classify the different p2p networks depending on their architecture. We work with a free p2p protocol called Pastry and its extension SplitStream. SplitSteam provides a programming API for the establishment of an ALM. We also consider the Real-time Transport Protocol (RTP) protocol which defines a standardized packet format for delivering audio and video over the Internet. Next, we describe the Session Initiation Protocol (SIP) protocol that is widely used for setting up and tearing down multimedia communication sessions such as voice and video conferences over the Internet. The practical part of this thesis deals with the implementation of a plug-in for a SIP User Agent (UA). We use the SIP Communicator (SC) that is an audio/video Internet phone and instant messenger. It supports some of the most popular instant messaging and telephony protocols such as SIP, Jabber and ICQ. The SIP Communicator is Open Source Software, and is freely available under the terms of the GNU Lesser General Public License. SC works with the Java-based service platform OSGi. Thus, we also provide a small introduction to service-oriented programming. The new SC plug-in can be deployed to construct an ALM based on SplitStream. The UAs will then be able to distribute videos in a live mode among the participants in a conference. Our example scenario is the multicasting of a holiday video or a rock concert within a SIP session. Thereby, we want to demonstrate a future use of p2p video streaming. This use case is a major highlight of the thesis as there is no implementation yet of this feature in any current instant messenger. In the conclusion we discuss the obtained results and possible future works.

5 Inhaltsverzeichnis 1. Einführung Motivation Zielsetzung Überblick der Kapitel Technologischer Hintergrund SIP (Session Initiation Protocol) SDP (Session Description Protocol) RTP (Realtime Transport Protocol) Peer-to-Peer-Netze Einführung Klassifizierung Peer-To-Peer-Netze für Live Video Streaming Einführung Baumbasierte Systeme Vermaschte Systeme OSGi - Dynamic Module System for Java Einführung Die OSGi Service Plattform Implementierungen Das OSGi Framework Grundelemente Konzept SIP-basierte Konferenz mit Live Video Streaming Das P2P Konzept Hashfunktionen Pastry Scribe SplitStream Das OSGi-Schichtenmodell Module-Schicht Die Lifecycle-Management-Schicht Die Service-Schicht Die Security-Schicht Die Framework Services Realisierung Erstellen eines SplitStream Clients Entwicklung eines OSGi Pugins Erstellen von eigenen Modulen für den SIP Communicator SplitStream Erweiterungen für den SIP Communicator P2P-Live-Video-Streaming-Proxy Anbindung an den SIP Communicator Zusammenfassung Ergebnisse Weiterführende Aufgaben Anhang A: Use Case für Integration von SplitStream mit SIP Anhang B: Abbildungsverzeichnis Anhang C: Listingverzeichnis Anhang D: Literaturverzeichnis... 83

6 1. Einführung 1. Einführung 1.1 Motivation Im Zeitalter von Web 2.0 werden immer neue Onlinedienste angeboten. Das Video- Sharing wird immer beliebter, nicht nur bei Jugendlichen, sondern auch bei Erwachsenen. In den meisten Fällen ruft ein Nutzer eine entsprechende Webseite auf und schaut sich ein eingebettetes Video an. Er ist dabei mehr oder minder passiv, es fehlt das Gemeinschaftserlebnis. Man wünscht sich daher eine Möglichkeit, Videos und Musik mit anderen zu teilen und zwar in Echtzeit. Die Tauschbörsen bieten keine echte Alternative, da man dort abwarten muss, bis die Media-Datei heruntergeladen ist. Aktuell existieren ausgereifte Peer-to-Peer (P2P) Netze. Die zugrunde liegende Technologie wird immer intelligenter, angefangen bei hybriden P2P Netzen, bei denen ein Server vorhanden ist, um bestimmte Aufgaben zu erfüllen, bis hin zu reinen P2P-Architekturen, wo die Clients alle Funktionen erbringen. Andererseits stehen Internet-Protokolle wie SIP zur Verfügung, um die Audio- und Videokommunikation zwischen Onlinenutzern zu vermitteln. Es sollte von daher möglich sein, die unterschiedlichen Technologien in einem einzigen Produkt zu vereinen, so dass das gemeinsame Anschauen eines Videos während einer Audio- bzw. Videokonferenz stattfinden kann. Damit werden Leute von geografisch entfernten Regionen näher aneinander gebracht, um ihre Videos, aber auch Gefühle besser auszutauschen. 1.2 Zielsetzung Ziel dieser Masterarbeit ist es, einen existierenden SIP User Agent für die Unterstützung von Media Streaming zu erweitern. Als Beispielszenarien dienen das Einspielen eines Urlaubvideos oder die Live-Übertragung eines Popkonzerts in eine bestehende SIP Session. Dabei kann es sich um eine SIP Session mit zwei oder mehr Teilnehmern handeln. Zur effizienten Medienverteilung in einer großen Gruppe wird ein Application Layer Multicast (Peer-to-Peer Video Streaming) eingesetzt. Ausgangspunkt für die Implementierung ist der als Open Source von der Universität Straßbourg entwickelte Instant Messenger SIP Communicator (SC), und speziell seine Erweiterung zur Unterstützung des SIP Protokolls. Der SIP Communicator ist in Java entwickelt und setzt auf das dynamische Java Modulsystem OSGi auf. Der IM Client ist in zweierlei Hinsicht zu erweitern: Erweiterung der SIP Signalisierung für Konferenzen mit beliebiger Anzahl Teilnehmer

7 1. Einführung Integration des VLC Media Players mit Peer-to-Peer Proxy. Ein Peer-to-Peer Live Video Streaming System wurde bereits in einer vorherigen Masterarbeit entwickelt. [thr] 1.3 Überblick der Kapitel Dieses Dokument soll dem Leser als Erstes einen Überblick über die Peer-To-Peer - Technologie und Overlay-Netze für Live Video Streaming geben. Zusätzlich werden die Protokolle für die Übertragung von Medienströmen im Internet eingeführt. Das zweite Kapitel beginnt mit der Beschreibung der Media-Protokolle SIP, SDP und RTP, die die Basis für eine Audio- bzw. Videokommunikation bilden. Anschließend werden die P2P-Netze klassifiziert. Schließlich wird die service-orientierte Architektur OSGi mit ihren Grundbausteinen vorgestellt. Sie spielt bei der nachfolgenden Implementierung eine wichtige Rolle. Im Kapitel 3 liegt der Fokus auf der Entwicklung einer geeigneten SIP Signalisierung für Live Video Streaming in Konferenzen. Dazu werden auch die Pastry-Technologie und die aus ihr stammenden Weiterentwicklungen Scribe und SplitStream näher beschrieben. Schließlich wird das OSGi Schichtenmodell weiter ausgebaut. Kapitel 4 widmet sich der Java-Implementierung des Konzeptes aus Kapitel 3. Es wird gezeigt, wie man einen SplitStream Client und ein OSGi Bundle erstellen kann. Zusätzlich wird die Schnittstelle des SIP Communicators für die Entwicklung eigener Module betrachtet. Mit Hilfe dieser Kenntnisse werden am Ende des Kapitels die am SIP Communicator vorgenommenen Erweiterungen beschrieben. Zum Abschluss werden in Kapitel 5 die erreichten Ergebnisse zusammengefasst und der Ausblick auf weitere Entwicklungen gegeben

8 2. Technologischer Hintergrund 2. Technologischer Hintergrund In diesem Kapitel werden Technologien und Protokolle beschrieben, die P2P Video Streaming ermöglichen. An erster Stelle werden SIP und SDP vorgestellt, die zum Aufbau, zur Steuerung und zum Abbau einer Kommunikationssitzung zwischen zwei oder mehr Teilnehmern eingesetzt werden. Kapitel 2.3 führt das Real-Time Transport Protocol (RTP) ein, welches zur kontinuierlichen Übertragung von audiovisuellen Daten (Streams) über IP-basierte Netzwerke benutzt wird. Anschließend werden die Techniken der P2P-Netze analysiert und nach ihrer Struktur klassifiziert. Als logische Fortsetzung werden die unterschiedlichen Topologien für P2P Live Video Streaming Netze betrachtet. Auf Basis ihrer Vor- und Nachteile werden die aktuellen Trends auf diesem Gebiet herausgearbeitet. Abschließend wird die OSGi Service Plattform mit ihren Grundelementen vorgestellt. 2.1 SIP (Session Initiation Protocol) Das Session Initiation Protocol (SIP) ist ein Netzwerkprotokoll zum Aufbau einer Kommunikationssitzung zwischen zwei und mehr Teilnehmern. Das Protokoll wird in den RFC 3261 [r1] (früher RFC 2543 [r2]) spezifiziert. Im Gegensatz zu H.323, das von der ITU-T stammt, wurde SIP mit Blick auf das Internet von der IETF entwickelt und orientiert sich an der Architektur gängiger Internet Anwendungen. Dabei wurde von Beginn an auf leichte Implementierbarkeit, Skalierbarkeit, Erweiterbarkeit und Flexibilität geachtet. SIP kann benutzt werden, um beliebige Sessions mit einem oder mehreren Teilnehmern zu verwalten. Dabei ist es nicht auf Internet Telefonie beschränkt, sondern Sessions können beliebige Multimediaströme, Konferenzen, Computerspiele usw. sein. [Wiki] Mit Hilfe des SIP-Protokolls werden die Initialisierungen der Verbindung vorgenommen sowie Daten und Parameter der Verbindung ausgetauscht. SIP ähnelt sehr dem HTTP Protokoll, denn es ist ASCII formatiert und unterteilt die Art der Nachrichtenübermittelung in Requests (aktive Anfragen) und Responses (passive Antworten auf Anfragen). Bei Request Anfragen steht die Art der Anforderung in der ersten Zeile. Es gibt folgende Request Typen: INVITE Lädt einen anderen Client zu einem Gespräch ein ACK Bestätigt den Verbindungsaufbau und leitet somit den Gesprächsbeginn ein BYE Beendet die aktuelle Sitzung OPTIONS Dient zur Ermittlung von Benutzer- und Serverdaten, wird jedoch nicht für den Aufbau benötigt CANCEL Wird vorwiegend von Servern oder Proxies zum Signalisieren eines Abbruches verwendet - 8 -

9 2. Technologischer Hintergrund REGISTER Damit meldet sich der SIP-Teilnehmer am SIP-Server oder SIP Proxy an. Häufig wird hier eine verschlüsselte Benutzer Authentifizierung nach dem MD5 Hash - Verfahren vorgenommen INFO Dient zum Transport beliebiger Informationen in der Payload der SIP Nachricht. Die durch das SDP eingestellten Parameter werden dadurch nicht beeinflusst. Häufig werden XML- Dateien zur Statuskontrolle oder Steuerung übertragen MESSAGE Dient der Realisierung eines Instant Messengers, der Chat Nachrichten sofort überträgt und anzeigt PRACK Dient der vorläufigen Bestätigung einer wichtigen Response Nachricht der 100er Reihe SUBSCRIBE Signalisiert dem SIP Server, SIP Proxy oder SIP Client, dass der Benutzer über eine bestimmte Status Änderung informiert werden möchte. Beispiel hierfür ist die Presence Funktion des Instant Messengers, welche Auskunft darüber erteilt, ob ein Benutzer gerade online oder beschäftigt ist Notify Ist die oben beschriebene Mitteilung, dass sich ein Status geändert hat. Häufig wird hier ein XML File angehängt, das den neuen Status beschreibt UNSUBSCRIBE Löscht die Statusbenachrichtigung wieder Die Response-Nachrichten werden in Form eines dreistelligen Zahlencodes in der ersten Headerzeile zurückgegeben. Die Festlegung entspricht weitgehend der des HTTP Protokolls: Vorläufige Bestätigung, mit dem Ziel den Request Steller auf ein bestimmtes Ereignis warten zu lassen. Gebräuchlichstes Beispiel ist die 180 Ringing Response. Sie signalisiert dem Anrufer, dass die Gegenstelle klingelt Bestätigung des Requests. Die 200 OK Response ist hier die Standard Antwort Umleitung. Der Client sollte die vom Server neu übermittelte Adresse benutzen Client Fehler. Die 404-Not found Response ist auch aus der www Welt bekannt. Die Fehlermeldung wird ausgegeben, wenn die angegebene SIP URL nicht in eine IP-Adresse aufgelöst werden kann Server Fehler. Diese Error-Response zeigt häufig einen Ausfall oder Absturz der Software an. Die 508-Not implemented - Response besagt, dass der Client den Request nicht bearbeiten kann, da diese Funktion noch - 9 -

10 2. Technologischer Hintergrund nicht implementiert ist (z.b. wenn ein SIP-Client eine Instant Message an ein älteres SIP Phone schickt). Die antwortende Response-Nachricht enthält weitgehend dieselben Parameter, wie der aufrufende Request (sh. Abb. 2-1). Abbildung 2-1: Kommunikation über SIP Besonders wichtig ist die Adressierung der Endgeräte (im Nachfolgenden Client genannt) über -ähnliche Adressen der Form Dabei spielt es keine Rolle, ob sich die IP Adresse des Clients ändert, denn bei dem Start und in regelmäßigen Zeitabständen muss der Client sich bei seinem zuständigen SIP Provider registrieren. Der Provider betreibt für die Namens-/ Adressumsetzung hierzu einen so genannten SIP Proxy, der unter der entsprechenden Domain rund um die Uhr verfügbar ist. Die Clients schicken ihre Anfragen an den Proxy, der diese dann an die entsprechenden Gegenstellen weiterleitet. Man unterscheidet zwischen Stateless - und Statefull Proxies. Erstere realisieren hauptsächlich die oben beschriebene Adressumsetzung. Die Statefull - Proxy-Server merken sich zusätzlich für jede Verbindung zwischen den Clients den aktuellen Status der Sitzung. Dadurch ist es möglich, die getätigte Verbindung und deren Dauer zu protokollieren, um so eventuell eine Kostenabrechnung zu realisieren

11 2. Technologischer Hintergrund Abbildung 2-2: Verbindungsaufbau mit Proxy Server Zu beachten ist bei der oben gezeigten Abbildung 2-2, dass die eigentlichen Sprachdaten im RTP Protokoll nicht über den SIP - Proxy laufen, sondern direkt, d.h. peer to peer, übertragen werden. 2.2 SDP (Session Description Protocol) Das zuvor erwähnte SIP-Protokoll überträgt selbst keine verbindungsspezifischen Parameter, wie zum Beispiel das verwendete Internet-Protokoll, IP-Addresse, Port und die zur Verfügung stehenden Audio- / Video-Codecs. Es fügt hierfür das Session Description Protocol (SDP) in die eigene Payload ein. Auch das SDP-Protokoll ist ASCII formatiert, die Parameter werden durch Abkürzungen eingeleitet: v Protokollversion o Absender und Session-Identifier s Session-Name t Medienzeitstempel m Medienname und adresse

12 2. Technologischer Hintergrund i Session-Information u URI der Session e adresse p Telefonnummer b Bandbreiten-Informationen z Zeitzonen-Einstellungen k Chiffrierungsschlüssel a Session Attribut Sollte es während einer aufgebauten Kommunikation zur Veränderung der Audio- / Video-Codecs kommen, so ist es im SIP Protokoll vorgesehen, dass man eine Re- INVITE Nachricht verschicken kann, die in ihrem SDP Header die neuen Verbindungsparameter enthält. Es ist wichtig anzumerken, dass der Call-ID Parameter im SIP Header unverändert bleibt. Die Call-ID stellt die eindeutige Zuordnung eines SIP-Kommunikationselements zu einer bestimmten Session dar. Alle Nachrichten und Statusinformationen, die eine bestimmte Session betreffen, tragen dieselbe Call-ID, die mindestens aus einem vom Session-Initiator generierten Zufallscode besteht. [sip] 2.3 RTP (Realtime Transport Protocol) Das Realtime Transport Protocol (RTP) wurde von der Audio-Video Transport Group der IETF entwickelt und ist Bestandteil von H.323. Es liegt auf der Anwendungsschicht und kann netzwerkbasierte Video- oder Audiokommunikation abwickeln (sh. Abb. 2-3). Zur Unterscheidung der Medien unterscheidet RTP zwischen verschiedenen Codierungsformaten, sodass die übertragenen Daten anwendungsunabhängig verwendet werden können. Für diesen Zweck wurden verschiedene RTP-Profile für Audio und Video definiert

13 2. Technologischer Hintergrund Abbildung 2-3: RTP im TCP/IP-Protokollstapel Das RTP-Protokoll ist unabhängig von den darunter liegenden Protokollen, es wird in der Regel mit dem UDP-Protokoll betrieben, wobei die RTP-Datenpakete in die UDP- Datenpakete eingepackt werden. Das RTP-Protokoll basiert auf einer Ende-zu-Ende-Verbindung und unterstützt Unicast-Verbindungen, aber auch IP-Multicast. Es erkennt und korrigiert fehlende, doppelte oder in falscher Reihenfolge empfangene Datenpakete. Im RTP-Header existieren neben diversen Datenfeldern für die Version und das Padding zwei Datenfelder für die eindeutige Identifizierung der Datenquellen und der Quelladressen. Die Statusinformationen der Quellen werden durch das RTCP- Protokoll, das Bestandteil von RTP ist, durch periodisches Senden rückgemeldet. [itw] 2.4 Peer-to-Peer-Netze Einführung Peer-to-Peer-Netzwerke erfreuen sich immer größerer Beliebtheit. Ständig werden neue Anwendungen auf dieser Basis entwickelt. Das Internet bietet einen großen Vorrat an Ressourcen, sowohl in Form von Speicherplatz, als auch an Rechenleistung. Es ist möglich, mit Hilfe von Peer-to-Peer-Netzwerken solche Ressourcen zu teilen, genauso wie sie zu vereinen. Datenmessungen sagen voraus, dass das Datentransfervolumen solcher Anwendungen stark steigt und einen sehr wesentlichen Teil des Internetverkehrs ausmacht

14 2. Technologischer Hintergrund Peer-to-Peer bedeutet Kommunikation unter Gleichen. Das heißt, dass solche Netzwerke im Gegensatz zum heute aktuellen Client/Server-Prinzip stehen (sh Abb. 2-4), bei dem Server Dienste anbieten, die von Clients genutzt werden. Ein Beispiel dafür sind Webserver und die auf Nutzerseite installierten Browser. In einem Peer-to- Peer Netzwerk ist prinzipiell jeder Knoten gleich und nimmt die Rolle eines Servers, eines Clients und eines Routers an, der Nachrichten weiterleitet. Dafür wird ein Overlay-Netzwerk gebildet, das über der bestehenden Infrastruktur eines Netzwerkes, zum Beispiel des Internets, aufgebaut wird. Abbildung 2-4: Client/Server Verbindungsprinzip Klassifizierung Man unterscheidet drei Arten von Peer-to-Peer Netzwerken: Zentralisiert: Es gibt zentrale Server (sh. Abb. 2-5), die die Kommunikation steuern. Beispielsweise bei Napster wurden die Verzeichnisinhalte der Knoten auf solchen Servern gespeichert. Anfragen von Knoten wurden von diesen Maschinen bearbeitet und entsprechende Ergebnisknoten mit gewünschtem Inhalt zurückgeliefert

15 2. Technologischer Hintergrund Abbildung 2-5: Zentralisierte P2P-Architektur Strukturiert, dezentralisiert: In solchen Systemen existieren keine zentralen Server mehr, jedoch herrscht eine bestimmte vordefinierte Netzwerkstruktur vor (sh. Abb. 2-6). In dieser Struktur werden Dateien an bestimmten Orten platziert, um Anfragen besser bearbeiten zu können. Solche Systeme sind beispielsweise Distributed Hash Tables (DHT) wie Tapestry, Pastry, Chord oder CAN. Abbildung 2-6: Strukturierte, dezentralisirte P2P-Architektur

16 2. Technologischer Hintergrund Unstrukturiert, dezentralisiert: In diesen Systemen gibt es auch keine zentralen Server (sh. Abb. 2-7). Hinzu kommt, dass die vordefinierte Netzwerkstruktur wegfällt und es keine Regelung über die Dateiplatzierungen mehr gibt. Dadurch werden die Suchmechanismen meist über Flooding umgesetzt, so dass eine sehr hohe Netzlast entsteht. Ein Beispiel für ein unstrukturiert dezentralisiertes Peerto-Peer-Netzwerk ist Freenet. Abbildung 2-7: Reine P2P-Architektur Zentralisierte Systeme haben zwar den Vorteil, dass Anfragen durch zentrale Indexe leichter realisiert werden können, jedoch gerade die zentralen Server bilden den Schwachpunkt dieser Netzwerke. Zum einen können dadurch schnell Engpässe entstehen, wenn die Anzahl der Anfragen auf einem Server steigt, und zum anderen funktioniert das Netzwerk ohne die Server nicht. Somit gibt es zentrale Angriffspunkte, um das gesamte Netzwerk einzuschränken. Ein weiterer Punkt ist die Vertraulichkeit der Daten. Dritte können leicht von wenigen Stellen aus das gesamte Netzwerk überwachen. Dezentralisierte Netzwerke haben diese Probleme nicht. Sie sind sehr viel robuster gegen Ausfälle und Überwachung, da es keine zentralen Instanzen gibt. Wenn wenige Knoten ausfallen, bleibt das Netzwerk weiterhin funktionsfähig. In unstrukturierten Systemen entsteht das Problem des Overheads der Suche. Im Gegensatz dazu stehen die strukturierten Netzwerke. DHT Systeme (dt.: verteilte Hashtabellen) bieten eine Hashtabellen-ähnliche Funktionalität an, bei der Objekte auf Knoten abgebildet werden. Das System liefert auf die Anfrage nach einem Objekt den Knoten, der es speichert. [dp]

17 2. Technologischer Hintergrund 2.5 Peer-To-Peer-Netze für Live Video Streaming Der folgende Abschnitt besteht zum Großteil aus einer Übersetzung des englischsprachigen Artikels A survey on peer-to-peer video streaming systems [sr], welcher die unterschiedlichen P2P Streaming Architekturen analysiert. In letzter Zeit steigt die Zahl der Benutzer, die Video-over-IP im Internet nutzen. Das traditionelle Client/Server-Videostreaming kostet die Provider viel Geld wegen der benötigten Bandbreite. Die P2P Netze sind der beste Anreiz für neue verteilte Netzwerkanwendungen. Kürzlich wurden von einigen Anbietern P2P Streaming Systeme eingeführt, die Live- und Video-on-Demand (VoD) Streaming-Dienste anbieten, deren Kosten deutlich geringer ausfielen. In diesem Kapitel werden die existierenden P2P Lösungen für Live Video Streaming betrachtet. Die Topologien für diese P2P Streaming Systeme sind Baum (tree), Multi-Baum (multi-tree) und vermaschte (mesh) Strukturen. Im Folgenden werden die Herausforderungen und die Lösungen für die Live Video Streaming Systeme in einer P2P-Umgebung geschildert Einführung Im Jahr 2006 stieg die Zahl der ausgelieferten Video Streams im Internet um 38,8 % auf 24,92 Mrd. Allein youtube.com hostet mehr als 45 TBytes Videomaterial und die Anzahl der angeschauten Videos bis September 2006 stieg auf 1,73 Mrd. Bei steigenden Bandbreiten im Zugang wird erwartet, dass der Video-Verkehr der dominierende Datenverkehr in der Zukunft sein wird. Die Basislösung für Videostreaming ist das Client/Server Model. Der Client initiirt eine Verbindung mit dem Quellserver und der Videoinhalt wird direkt zum Client gestreamt. Eine Variation von diesem Model ist die Content Delivery Network (CDN) -basierte Lösung. Bei ihr werden zuerst die Inhalte zu anderen Zustellservern geschoben, die an strategischen Stellen im Netz platziert sind, so dass bei einem Download der Client aufgefordert wird, von dem am nähsten liegenen Server die Daten zu laden. CDN kürzt sehr effektiv die Zeit zum Download und kann damit mehr Benutzer gleichzeitig bedienen. Youtube setzt CDN ein, um seine Endnutzer zu versorgen. Die größte Herausforderung für die Server-basierte Architektur liegt bei der Skalierbarkeit. Die Videos mit hoher Qualität brauchen auch eine hohe Datenrate. Mit den heutigen Kompressionsverfahren benötigt man 400 kbps, um TV Qualität zu erreichen. Die Bandbreite des Providers muss proportional mit der Clientzahl wachsen. Das macht das Server-basierte Video Streaming teuer und stimuliert gleichzeitig die Entwicklung von P2P Anwendungen. Die Grundidee bei den P2P Applikationen ist, dass die Benutzer als Client und Server fungieren, bekannt als Peer. Im P2P Netzwerk laden die Benutzer nicht nur Daten herunter, sondern senden diese auch an andere Benutzer im Netz. Die Uploadgeschwindigkeit von den Endnutzern wird effizient ausgenutzt, um die sonst reduzierte Bandbreite beim Client/Server Prinzip zu ersetzen. Anwendungen wie BitTorrent und emule werden verbreitet angewendet, um schnellen Datenaustausch über das Internet zu ermöglichen. Weiter wird die P2P Technologie eingesetzt, um Dienste wie Mediastreaming anzubieten. Anwendungen wie PPLive und PPStream wurden entwickelt, um Dienste wie Video-on-Demand und Live-TV zu unterstützen

18 2. Technologischer Hintergrund Studien zufolge haben in 2006 mehr als Users gleichzeitig broadcast Videos geschaut, mit einer Bitrate von 400 bis 800 kbps. Die P2P Streaming Systeme können in zwei Gruppen klassifiziert werden. Das sind die Baum- und die vermaschten Strukturen. Die Baumstruktur besitzt gut organiserte Overlaystruktur und liefert Videos, indem sie die Daten an ihren untergeordneten Knoten (children peers) sendet. Ein grosser Nachteil von dieser Architektur ist ihre Anfälligkeit für Benutzerdynamik im Netz. Beispielsweise wenn sich ein Benutzer abmeldet, wird er die Übertragung an seine Kinder stören. Bei den vermaschten Strukturen sind die Peers nicht an eine statische Topologie gebunden. Stattdessen ist die Architektur auf das ständige An- und Abmelden von Benutzern spezialisert. Die Peers verbinden sich dynamisch mit einer Zufallszahl von anderen Peers in dem System. Periodisch tauschen sie Informationen über ihren Datenbestand aus. Die Peers beziehen die Videodaten von ihren Nachbarn, die bereits die Daten erhalten haben. Diese Eigenschaften machen die vermaschten Videostreaming Systeme sehr robust gegen Benutzerdynamik. Dennoch, die ständige Bewegung von Peers macht die Effizienz von Videoverteilung unberechenbar. Die Pakete können unterschiedliche Routen nehmen, um an das Ziel zu kommen. Als Konsequenz leiden die Benutzer an abfallender Videoqualität durch die niedrigen Bitraten, längere Startupverzögerungen und Einfrieren des Bildes während der Übertragung. Das Videostreaming kann man in zwei Kategorien klassifizieren: Live Video und Video-on-Demand. Bei der Live Übertragung werden die Inhalte in Echtzeit unter allen Nutzern verbreitet. Das Abspielen des Videos ist unter allen Peers synchronisiert. Dagegen erfreuen sich die Video-on-Demand Nutzer an der Flexibilität, sich diejenigen Videos anzuschauen, die sie möchten und wann sie möchten. Das Abspielen von einem Video ist nicht unter den Peers synchronisiert. In diesem Abschnitt werden die verschiedenen Overlaystrukturen näher beschrieben Baumbasierte Systeme In den jungen Jahren des Internet wurde das IP Level Multicast als effizienter Weg zum Streamen von Audio und Video eingesetzt. Bei der IP Mutlicast Session ist der Server mit allen Clients verbunden, indem sie einen Multicast Baum mit Hilfe der IP Router aufbauen. Leider ist dieses Verfahren mit einer hohen Komplexität und Verwaltungsaufwand verbunden. Deswegen fand das IP Level Multicast nie eine größere Anwendung im Internet. Stattdessen wurden die Funktionen auf der Anwendungsschicht implementiert. Videoserver und User formen das Application Layer Multicast, wo die Videoinhalte verbreitet werden. Single-tree Streaming Ähnlich wie beim IP Multicast Baum, welcher auf Routern auf der Netzwerkschicht basiert, bilden die User einen Baum auf der Anwendungsschicht, dessen Wurzel beim Videoserver liegt (sh. Abb. 2-8). Jeder Peer verbindet sich mit dem Baum auf einer bestimmten Ebene. Er bekommt die Videodaten von seinen Eltern über sich und leitet die empfangenen Inhalte weiter an seine Kinder. Abbildung 2-8 illustriert einen Application Layer Multicast Baum mit zehn Knoten

19 2. Technologischer Hintergrund Es gibt zwei Peers auf Schicht 1, die ihre Daten direkt vom Streamingserver beziehen. Vier Peers auf Schicht 2 bekommen die Pakete von den Eltern von Schicht 1. Drei von denen leiten die erhaltenen Videodaten an vier weitere Peers auf die unterste Ebene weiter. Abbildung 2-8: P2P Video Streaming auf Basis von Application Layer Multicast Bei dieser Konstellation aus zehn Peers sind mehrere Möglichkeiten vorhanden, um einen Streamingbaum aufzubauen. Die Hauptbetrachtung beinhaltet die Tiefe des Baums und die Auslastung der inneren Knoten. Peers aus den niedrigen Schichten erhalten den Videostrom vor den Peers aus den höheren Schichten. Um die Verzögerungen zu minimieren, sollte man die Anzahl der Schichten so klein wie möglich halten. Mit anderen Worten, die Baumtopologie sollte so breit wie möglich auf einer Schicht sein. Die innen liegenden Knoten können mit ihrer Uploadgeschwindigkeit nur an eine begrenzte Zahl von Kinderknoten Daten weiterleiten. Die Bitrate beschränkt ihre Kapazität. Im Normalfall für die Zwecke von load balancing und Fehlerstabilität muss die Ausgangsgeschwindigkeit der Peers unterhalb ihres Maximum liegen. Ein anderer wichtiger Punkt bei der Baumstruktur ist die Wartung des Systems. Die Benutzer können im Regelfall sehr dynamisch sein. Der User kann eine Session angekündigt oder unangekündigt, etwa beim Rechner-Absturz, verlassen. Beim Verlassen wird die Verbindung zu allen seinen Kinderknoten unterbrochen und damit können sie keine Videosequenzen mehr empfangen. Abbildung 2-9 zeigt ein mögliches Szenario, wenn ein Peer nahe an dem Videoserver den Baum verlässt. So werden alle fünf der unterliegenden Knoten vom Quellserver getrennt

20 2. Technologischer Hintergrund Abbildung 2-9: Ausfall eines Knoten Abbildung 2-10 zeigt wie der Baum die Verbindung zu den Peers erneut herstellt, indem sie vom Server oder anderen Peers vererbt wird. Abbildung 2-10: Korrektur des Baumes nach dem Ausfall Die Baumstruktur kann entweder zentral oder verteilt aufgebaut und gewartet werden. Bei der zentralisierten Lösung kontrolliert der Server den Aufbau und die Wiederherstellung eines Baums. Wenn sich ein User im System anmeldet, kontaktiert er als erstes den Zentralserver. In diesem Fall entscheidet der Server auf Basis der momentanen Baumstruktur, an welcher Position sich der Peer verbindet und benachrichtigt seine Elternknoten. Der Server kann das Verlassen eines Knotens aufspüren, indem er seine Abmelde-Nachricht auswertet oder nach einem bestimmten Timeout-Verfahren. In beiden Fällen muss die Topologie des Systems neu kalkuliert werden. Bei großen Streaming Systemen kann es vorkommen, dass die Serverressourcen knapp werden. Um dies zu vermeiden, werden Algorithmen angewendet, um die nötigen Wartungsarbeiten verteilt zu erledigen