Studienarbeit Implementierung einer IP-Multicast

Universität Paderborn
Studienarbeit
Implementierung einer
IP-Multicast basierten
MPEG-2 Streaming-Anwendung
Simon Oberthür
Matrikelnummer 3660283
Paderborn, den 6. Dezember 2000
Inhaltsverzeichnis
1 Einleitung
1.1 Aufgabenbeschreibung .
1.2 Aufteilung . . . . . . . .
1.2.1 DVB-Cardserver
1.2.2 Applicationserver
1.2.3 CGI . . . . . . .
1.2.4 Client . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Benutzte Protokolle
2.1 IP-Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Adressierung von IP-Multicastpaketen . . . . . . . .
2.1.3 Multicastlevel . . . . . . . . . . . . . . . . . . . . . .
2.1.4 Senden von IP-Multicastpaketen . . . . . . . . . . . .
2.1.5 Empfangen von IP-Multicastpaketen . . . . . . . . .
2.1.6 Routing von IP-Multicastpaketen . . . . . . . . . . .
2.1.7 Motivation für die Verwendung von IP-Multicast . .
2.2 RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Real Time Streaming Protocol . . . . . . . . . . . . .
2.3 RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Real-Time Transport Protocol . . . . . . . . . . . . .
2.4 Einsatz und Motive für die Verwendung von RTSP und RTP
3 Design und Implementierung
3.1 Vorhandene Software . . . . . . . . . . . . . .
3.1.1 pvatots . . . . . . . . . . . . . . . . . .
3.1.2 linux dvb . . . . . . . . . . . . . . . .
3.1.3 sendrtp ts . . . . . . . . . . . . . . . .
3.1.4 Java Media Framework (JMF) . . . . .
3.1.5 Omnithread . . . . . . . . . . . . . . .
3.2 Benutzerschnittstellen . . . . . . . . . . . . .
3.3 Aufbau und Implementierung des Prototypen
3.3.1 DVB-Cardserver . . . . . . . . . . . .
3.3.2 CGI . . . . . . . . . . . . . . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
3
3
3
4
4
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
6
7
8
9
10
11
14
15
15
17
17
18
.
.
.
.
.
.
.
.
.
.
20
20
20
20
20
20
21
21
22
23
23
Inhaltsverzeichnis
3.3.3
3.3.4
3.3.5
Applicationserver . . . . . . . . . . . . . . . . . . . . . . . . . 25
Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Beispielkommunikation zwischen den Modulen . . . . . . . . . 27
4 Zusammenfassung und Ausblick
29
4.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2
1 Einleitung
1.1
Aufgabenbeschreibung
In einem Intranet sollen MPEG-2 codierte TV-Signale von einem Satelliten empfangen, übertragen und von mehreren Clients wiedergegeben werden.
Den Benutzern der Anwendung soll es möglich sein, über ein Webinterface einen
Fernsehsender aus einer Liste von verfügbaren Sendern auszuwählen und diesen dann
mit Hilfe des Clients zu empfangen.
Hierfür stehen im Intranet Linuxserver zur Verfügung, die über eine DVB-Karte
mit einer Satellitenschüssel verbunden sind. Diese Server sollen das TV-Signal des
gewählten Fernsehsenders zu den Clients, die diesen Sender gewählt haben, übertragen. Das TV-Signal soll als MPEG-2 Multicaststream übertragen werden. Um den
MPEG-2 Datenstrom darstellen zu können, verfügen die Clients über eine MPEG-2
Decoderkarte.
1.2
Aufteilung
Die zu implementierende Anwendung setzt sich aus vier Teilprogrammen zusammen:
1.2.1
DVB-Cardserver
Der Cardserver wird auf den Servern mit DVB-Karte gestartet. Das Programm wandelt das Signal der DVB-Karte in einen MPEG-2 Transport Stream“ um und sendet
”
diesen an eine Multicastgruppe. Gesteuert wird der Server vom Applicationserver.
Der Applicationserver kann veranlassen, dass ein bestimmter Sender eingestellt, der
Stream gesendet und das Senden des Streams beendet wird.
1.2.2
Applicationserver
Der Applicationserver wartet auf Anfragen des Players der Clientanwendung. Möchte
ein Client einen Sender empfangen und der Stream des Senders wird schon gesen-
3
1 Einleitung
Cardserv er
Client
Cardserv er
LAN
Client
Client
W ebserv er
A pplicat ionserv er
Client
Abbildung 1.1: Skizze der zu implementierenden Anwendung
det oder ein Cardserver ist noch frei, teilt der Applicationserver dem Client die
Multicastgruppe mit, auf dem der MPEG-2 Stream zu empfangen ist. Ist noch ein
Cardserver frei und der Stream wird noch nicht von einem Cardserver gesendet,
verbindet der Applicationserver sich mit dem freien Cardserver und initiiert dort
das Senden des entsprechenden Streams. Der Applicationserver überwacht die Verbindung zu den aktiven Clients.
1.2.3
CGI
Das CGI wird vom Webserver gestartet, wenn der Benutzer mit seinem Webbrowser
die Einstiegsseite der Anwendung aufruft. Es verbindet sich mit dem Applicationserver, fragt ab welche Sender zur Zeit zur Verfügung stehen und erzeugt dann die
Einstiegsseite, auf der die einzelnen Sender als URL codiert sind.
1.2.4
Client
Wenn der Benutzer einen Sender auf der Einstiegsseite mit seinem Webbrowser
auswählt, wird der Player mit der URL aufgerufen, in der der gewünschte Sender
codiert ist. Er verbindet sich mit dem Applicationserver und teilt ihm die URL mit.
Vom Applicationserver erhält der Player die Multicastadresse auf der der Stream zu
4
1 Einleitung
empfangen ist.
Die Modularisierung der Anwendung bietet mehrere Vorteile: Die Anwendung kann
so auf mehrere Rechner aufgeteilt werden, womit sich die Last wesentlich besser verteilen lässt. Da Applicationserver und CGI nicht viele Ressourcen benötigen, können
sie (falls vorhanden) auf dem Webserver des Intranet gestartet werden, dadurch wird
keine zusätzliche Hardware für diese Komponenten benötigt. Die Skalierbarkeit wird
durch die Modularisierung ebenfalls erhöht: wenn z.B. eine höhere Anzahl an TVSendern, die im LAN gleichzeitig empfangen werden können, gefordert wird, muss
nur ein neuer DVB-Cardserver installiert werden. Die Komponenten kommunizieren
über das standardisierte Protokoll RTSP, dadurch sind einzelne Komponenten leichter gegen Software Dritter austauschbar. Auch lässt sich die Anwendung so leichter
erweitern, z.B. um das Abrufen von Videodaten, die auf anderen Videoservern gespeichert sind und die ebenfalls über eine RTSP-Schnittstelle verfügen.
Der Rest dieser Arbeit gliedert sich wie folgt: In Abschnitt 2 werden die verwendeten Protokolle beschrieben (IP-Multicast, RTSP, RTP), Abschnitt 3 beschäftigt
sich mit dem Design und der prototypischen Implementierung der Anwendung. Im
letzten Abschnitt werden die Ergebnisse der Arbeit und gesammelte Erfahrungen
zusammengefasst und ein Ausblick auf weitergehende Arbeiten gegeben.
5
2 Benutzte Protokolle
2.1
IP-Multicast
In diesem Kapitel werden die Grundlagen von IP-Multicast [10] (im nachfolgenden
Multicast genannt) erklärt. Darüber hinaus wird erläutert wofür Multicast benötigt
und wie es realisiert wird.
2.1.1
Einleitung
Im Internet werden zur Zeit Videodaten fast ausschließlich über Unicast übertragen, das heißt die Daten werden vom Server für jeden Client einzeln verschickt. Die
meisten Internetuser verfügen zur Zeit maximal über einen 64 kBit/s Zugang zum
Internet. Beispielszenario: Ein Server ist mit 100 MBit/s an das Internet angebunden, also kann er maximal 1600 Clients mit je einem 64 kBit/s Unicast-Videostrom
versorgen. Deshalb werden zur Zeit im Internet nur Videodaten verschickt, die qualitativ nicht mit herkömmlichen TV-Signalen vergleichbar sind. Bei einem MPEG-2
Datenstrom, wie wir ihn benötigen um qualitativ hochwertige TV-Signale zu übertragen, sinkt die Zahl der Clients (wie sie in diesem Szenario auftreten), die ein
Server via Unicast bedienen kann, noch einmal stark, da ein MPEG-2 Datenstrom
ca. 4 MBit/s an Bandbreite benötigt. Bei Unicast-Übertragungen werden die gleichen Daten mehrfach über eine Leitung geschickt und dadurch Netzwerkressourcen
verschwendet.
Als Alternative könnte man die Daten per Broadcast übertragen, das heißt die
Daten werden vom Server nur noch einmal verschickt, allerdings an alle Clients. Doch
auch hier wird wieder Netzwerkbandbreite verschwendet, denn die Daten müssen
durch das gesamte Intranet an alle angeschlossenen Hosts geschickt werden, egal ob
sie die Daten empfangen wollen oder nicht. Diese Art Daten zu übertragen scheidet
daher aus.
Multicast erlaubt diese Probleme zu umgehen. Mit Multicast können ein und
dieselben Daten an mehrere Clients verschickt werden, ohne sie mehrmals oder an
alle Clients verschicken zu müssen. Abbildung 2.1 verdeutlicht den Unterschied zwischen Unicast und Multicast.
6
2 Benutzte Protokolle
Em pfänger
Em pfänger
Sender
Sender
Abbildung 2.1: Links: Unicast, Rechts: Multicast
Bei Multicast sendet der Server einfach seine Daten an eine Multicastgruppe.
Dieser Multicastgruppe treten die Clients bei und empfangen von diesem Zeitpunkt
an die Daten, die an diese Gruppe gesendet werden. Eine Multicastgruppe ist also
eine dynamische Gruppe, die die Hosts beinhaltet, die zur Zeit Daten aus dieser
Multicastgruppe empfangen wollen.
2.1.2
Adressierung von IP-Multicastpaketen
Hosts im Internet werden über IP-Adressen angesprochen, die sich aus 32 Bits zusammensetzen. Auf IP-Ebene hat man für Multicast den Adressblock 224.0.0.0/4
(224.0.0.0 bis 239.255.255.255) reserviert. Jede IP, die in der Binärdarstellung mit
1110“ beginnt, ist also eine Multicastadresse. Daher reicht die Überprüfung der
”
ersten 4 Bits einer IP, um festzustellen ob es sich um eine Multicastadresse handelt.
Eine Multicastadresse wird als Multicastgruppe bezeichnet, um zu verdeutlichen,
dass hinter dieser IP-Adresse nicht nur ein Host steht, sondern eine ganze Gruppe
von Hosts.
Um Daten zu empfangen, die an eine Multicastgruppe adressiert sind, ist es notwendig dieser Gruppe beizutreten. Dieser Vorgang wird in Abschnitt 2.1.5 genauer
erläutert.
Es gibt einige Multicastgruppen, die eine spezielle Bedeutung haben. Der Bereich
7
2 Benutzte Protokolle
224.0.0.0-224.0.0.255 ist z.B. für administrative Zwecke reserviert. Hier die beiden
wichtigsten Gruppen aus diesem Bereich:
• 224.0.0.1 ist die all-hosts“-Gruppe. Auf ein Ping an diese IP (Multicastgrup”
pe) sollten alle Multicast-fähigen Hosts antworten, die sich im selben Subnetz
befinden. Ein Host, der Multicast empfangen will, muss also auf jeden Fall
dieser Gruppe beitreten.
• 224.0.0.2 ist die all-routers“-Gruppe. Dieser Gruppe müssen alle Router bei”
treten, die Multicast unterstützen.
Weitere spezielle bzw. reservierte Gruppen sind im RFC 1700: Assigned Numbers“
”
[13] definiert bzw. im DNS (Domain Name Service) unter MCAST.NET und 224.INADDR.ARPA aufgeführt.
2.1.3
Multicastlevel
Man teilt Hosts in drei verschiedene Multicastklassen (Level) ein:
Level 0
Hosts in dieser Klasse unterstützen kein Multicast. Sie können keine Multicastpakete
empfangen, senden oder weiterleiten. Sie ignorieren einfach alle Multicastpakete, die
sie von anderen empfangen. Im Internet gibt es zur Zeit viele Hosts und auch viele
Router, die sich in dieser Klasse befinden, denn in IPv4 ist Multicastunterstützung
nicht vorgeschrieben.
Level 1
Hosts in dieser Klasse können Multicastpakete nur senden. Sie können keiner Multicastgruppe beitreten und deshalb auch keine Multicastpakete empfangen. Es bedarf
nur sehr weniger Änderungen am Sourcecode im IP-Modul eines Level 0“-Hosts,
”
um ihn zu einem Level 1“-Host zu machen.
”
Level 2
Dieses ist die Klasse der Hosts, die Multicast voll unterstützen, d.h. Multicastpakete empfangen und auch senden können. Hierfür müssen sie wissen, wie man einer
Multicastgruppe beitritt und sie wieder verlässt. Deshalb müssen sie auf TCP/IPEbene das Internet Group Management Protocol (IGMP)“ unterstützen, um so
”
dem Router, an dem sie angeschlossen sind, mitteilen zu können, welche Multicastgruppen sie empfangen wollen.
8
2 Benutzte Protokolle
Da es im Internet noch viele Level 0“-Router gibt, existiert zur Zeit keine
”
flächendeckende Multicastunterstützung. Multicast funktioniert also nur in Teilnetzen, sogenannten Multicastinseln“. Diese Teilnetze kann man allerdings mit Hilfe
”
von Tunneln über nicht multicastfähige Router verbinden. Das MBone“ (Multi”
castbackbone) ist so ein virtuell zusammengeschlossenes Multicastnetz.
2.1.4
Senden von IP-Multicastpaketen
TCP als ein Punkt-zu-Punkt Protokoll ist auf Übertragungsebene nicht für Multicast geeignet. Multicastpakete, die man versenden will, behandelt man deshalb fast
genauso wie Unicast-UDP-Pakete: Man öffnet ein UDP-Socket und gibt als Zieladresse die Multicast-IP (Gruppe) an. Das heißt auch, dass auf Übertragungsebene
nicht garantiert werden kann, dass die Pakete wirklich ankommen. In der im Rahmen dieser Arbeit zu implementierenden Anwendung wird deshalb zusätzlich RTP
(vergl. Abschnitt 2.3) benutzt, um Paketverluste festzustellen.
Gegenüber einem normalem UDP-Socket gibt es allerdings noch einige besondere Einstellungen, die man vornehmen kann. Befindet sich im Rechner mehr als ein
Netzwerkinterface, muss man ein Interface bestimmen, über das der Multicastverkehr geroutet werden soll. Außerdem bieten die meisten Betriebssysteme Funktionen
an, mit denen am Socket eingestellt werden kann, ob die gesendeten Daten auch am
sendenden Host empfangen werden sollen (loopback). Eine ganz besondere Rolle
nimmt beim Multicast das TTL-Feld im IP-Header ein, das im nächsten Absatz
beschrieben wird.
TTL - Time To Live
Wie auch bei IP-Paketen bei denen es sich nicht um Multicastpakete handelt, kontrolliert das TTL-Feld die Lebensdauer eines Multicast-Paketes, um zu verhindern,
dass das Paket bei Routingfehlern endlos geroutet wird. Wenn ein Paket einen Router passiert, erniedrigt dieser den TTL-Wert. Beim Erreichen der 0 wird das Paket
nicht mehr weiter geroutet.
Das TTL-Feld wird bei Multicast aber auch benutzt, um die Reichweite der zu
sendenden Pakete zu steuern. Möchte man z.B. — wie im Rahmen der in dieser
Arbeit zu programmierenden Anwendung — Videosignale nur innerhalb eines LAN
und nicht ins gesamte Internet übertragen, setzt man die TTL mit der man die
Pakete senden möchte z.B. auf 31. Bei multicastfähigen Routern gibt es nämlich die
Möglichkeit, einen Schwellenwert für jedes Interface zu definieren. Setzt man diesen
Schwellenwert bei dem Router, der das LAN mit dem Internet verbindet, auf 32,
werden nur Multicastpakete mit einer TTL größer 32 ins Internet weitergeleitet.
Hier eine Liste von TTL-Reichweiten”:
”
9
2 Benutzte Protokolle
TTL
0
1
<32
<64
<128
<255
Reichweite
Beschränkt auf denselben Host.
Beschränkt auf dasselbe Subnetz.
Beschränkt auf einen bestimmten Standort, Organisation oder Abteilung.
Beschränkt auf dieselbe Region.
Beschränkt auf denselben Kontinent.
Unbeschränkt, global.
Wie aus der Liste ersichtlich wird, kann einer TTL keine genaue Reichweite zugeordnet werden. Es liegt immer in der Hand der Router-Administratoren die Schwellenwerte einzustellen. Die Liste gibt aber einen Anhaltspunkt welche Reichweite mit
einer bestimmten TTL erlangt werden sollte.
2.1.5
Empfangen von IP-Multicastpaketen
Auch das Empfangen von Multicastpaketen läuft ähnlich wie das Empfangen von
Unicast-UDP-Paketen ab. Beim Öffnen des Sockets reicht es allerdings nicht aus,
nur die IP der Multicastgruppe anzugeben. Wenn eine Anwendung Multicastpakete
empfangen möchte, ist es wichtig, dass sie dem Betriebssystem mitteilt, an welchen
Gruppen sie interessiert ist, damit das Betriebssystem der/den Multicastgruppe/n
beitreten kann. Die Anwendung empfängt dann nur Multicastpakete von den Gruppen, die sie abonniert“ hat. Das UDP-Protokoll benutzt dabei die Multicastadres”
sen und Portnummern der Pakete, um diese an die richtigen Sockets zu verteilen. Es
ist auch möglich, dass mehrere Programme auf einem Host einer Multicastgruppe
beitreten.
Eine Anwendung tritt beim Beitreten einer Gruppe nicht unbedingt einer globalen Gruppe bei, sondern einer Gruppe auf einem Netzwerkinterface des Hosts.
Dadurch empfängt man nicht automatisch alle Pakete, die weltweit an diese Multicastadresse gesendet werden, denn wie weit IP-Multicastpakete von einem Sender
geroutet werden hängt wie beschrieben von der TTL, mit der sie gesendet werden
und den dazwischen liegenden Routern ab. Wenn sich der Sender und der potentielle Empfänger in zwei verschiedenen Multicastinseln befinden, die nicht über einen
Tunnel miteinander verbunden sind, dann ist eine Multicastkommunikation zwischen
Sender und Empfänger nicht möglich.
Wenn ein Programm nicht mehr am Empfang von Daten aus einer Multicastgruppe interessiert ist, muss es diese beim Betriebssystem wieder abbestellen“.
”
Dieses verlässt die Gruppe allerdings erst wieder, wenn kein Programm mehr diese
Multicastgruppe empfangen möchte.
10
2 Benutzte Protokolle
Das Protokoll IGMP
Das Internet Group Management Protocol (IGMP)“ ist entwickelt worden, um das
”
Beitreten und Verlassen von Multicastgruppen zu standardisieren. Alle Hosts in Level 2 müssen IGMP unterstützen.
IGMP Version 1 wird im RFC 1112 [6] beschrieben. In dieser Version gibt es zwei
Nachrichtentypen: Host Membership Query“ und Host Membership Report“. Ein
”
”
Router kann alle Hosts in einem Subnetz periodisch fragen, welche Gruppen sie
empfangen möchten, und Hosts können als Antwort auf die Anfrage oder spontan
pro Gruppe einen Report abschicken. In Version 1 von IGMP kann ein Host eine
Gruppe nicht gezielt verlassen. Er kann nur warten, bis der Router das nächste Mal
eine Anfrage stellt und dann darauf nicht antworten.
Die wichtigste Änderung an IGMP Version 2 (RFC 2236 [8]) ist ein neuer Nachrichtentyp: Leave Group Message“. Mit dieser Nachricht können die Hosts dem
”
Router mitteilen, dass sie eine Gruppe verlassen wollen. Dieses Verfahren verschwendet weniger Bandbreite, da der Router sofort eine Multicastgruppe abbestellen kann,
wenn kein Host im Subnetz mehr die Gruppe benötigt und nicht erst wenn er eine
Query“ stellt, auf die kein Host antwortet. Außerdem können in Version 2 mehrere
”
Multicastrouter in einem Subnetz koexistieren, in dem der Router mit der kleineren
IP zum Querier“ ausgewählt wird und alle Fragen übernimmt; fällt er aus, springt
”
der nächste ein.
Derzeitig unterstützen die meisten Betriebssysteme IGMP Version 1, viele werden auf IGMP Version 2 vorbereitet. Der Vollständigkeit halber sei noch erwähnt,
dass es schon eine Version 3 von IGMP [5] gibt, in der es zusätzlich Access Control
Lists (ACLs) gibt. Mit den ACLs kann ein Host seinem Router mitteilen, dass er
nur Multicast Pakete empfangen möchte, die von einem bestimmten Sender an die
Gruppe geschickt werden.
2.1.6
Routing von IP-Multicastpaketen
Routing ist im Zusammenhang mit Multicast ein schwieriges Problem, im Folgenden
Abschnitt sollen einige der wichtigsten Algorithmen und Protokolle kurz vorgestellt
werden.
Wenn ein Host einer Multicastgruppe im Internet beitritt, müssen alle Router
zwischen einem Sender, der mit einer genügend hohen TTL sendet, und dem Host
die Pakete Richtung Host weiterleiten. Das Problem ist, eine geeignete Heuristik
auszuwählen, um zu entscheiden, wie Multicastpakete geroutet werden sollen.
Ein trivialer Algorithmus wäre, die Daten überall hinzusenden, so dass jeder
11
2 Benutzte Protokolle
Router sie weiterleitet, doch wäre dies Broadcast. Bis heute wurden mehrere Algorithmen entwickelt, aber in diesem Bereich wird immer noch Forschung betrieben.
Die meisten Verfahren teilt man in Dense Mode“ oder Sparse Mode“ ein. Bei
”
”
dichten“ Multicastnetzen liegen die Empfänger nahe beieinander und Router haben
”
eine relativ hohe Zahl von Teilnehmern zu bedienen, hierfür sind die Dense Mode“”
Algorithmen optimiert. Bei spärlich verteilten Empfängern muss jeder Router nur
wenige Teilnehmer bedienen, dafür liegen alle Empfänger einer Multicast Gruppe
räumlich weit verteilt, hierfür sind die Sparse Mode“-Algorithmen gedacht. Abbil”
dung 2.2 zeigt ein Beispiel für Multicastnetze, in denen die Empfänger nah beieinander liegen, Abbildung 2.3 ein Beispiel für Multicastnetze, in denen die Empfänger
spärlich verteilt sind.
Sender
Router
Empfänger
Abbildung 2.2: Multicastnetze in denen die Empfänger nah beieinander liegen
Flood and Prune
Dieses Protokoll wurde früher im MBone benutzt. Da im MBone alle Standleitungen über einen Pauschalpreis abgerechnet wurden, konnte man verschwenderischer“
”
mit der Bandbreite umgehen. Wenn Daten auf einer Multicastgruppe hereinkamen,
die bisher nicht benutzt worden war, wurden die Daten einfach“ an alle Router
”
weitergeschickt ( Flood“). Die Router bestellten dann die Gruppen wieder ab, wenn
”
kein Client diese Gruppen abonniert hatte ( Prune“).
”
Der Nachteil ist, dass selbst wenn in einem Subnetz keine Multicast Gruppe
benötigt wird, unnötiger Netzwerkverkehr bis zum Router entsteht, bis dieser die
nichtbenötigten Gruppen wieder abbestellt. Dadurch entstehen bei einer Standleitung, die nach Volumen abgerechnet wird, Kosten für Multicast selbst wenn gar kein
12
2 Benutzte Protokolle
Sender
Router
Empfänger
Abbildung 2.3: Multicastnetze in denen die Empfänger spärlich verteilt sind
Multicast benötigt wird.
Dieses Protokoll ist ein Dense Mode“-Verfahren.
”
DVMRP
Das Multicastroutingprotokoll DVMRP (Distance Vector Multicast Routing Protocol), welches im RFC 1075 [16] beschrieben wird, kam lange Zeit im MBone zum
Einsatz. Dieses Protokoll baut auf Flood and Prune auf und greift auf Unicastrouting zurück.
MOSPF
MOSPF (RFC 1585 [11]) ist eine Multicasterweiterung des OSPF-Protokolls (Open
Shortest Path First, RFC 1583 [12]) und greift damit auch auf Unicastrouting
zurück. Dieses Protokoll benötigt viel RAM und Rechenzeit in den Routern, da
beim OSPF der Dijkstra Algorithmus angewendet wird. MOSPF ist heute praktisch
bedeutungslos.
PIM
DVMRP und MOSPF haben den Nachteil, dass sie von einem bestimmten Unicastroutingprotokoll abhängen. Von der Internet Engineering Task Force (IETF)
wurde deshalb PIM (Protocol Independent Multicast) entwickelt. PIM-DM [17] ist
13
2 Benutzte Protokolle
die Dense Mode“-Variante des PIM-Protokolls. Es ist eine abgewandelte Version
”
von DVMRP, die nicht auf Unicast Routing zurückgreift.
Die Sparse Mode“-Variante von PIM ist PIM-SM (RFC 2362 [7]). Sie baut auf
”
sogenannten Rendezvous Points auf.
PIM ist derzeit das meistbenutzte Protokoll. Seine Verbreitung ist darauf zurückzuführen, dass die Firma Cisco in ihren Routern nur PIM unterstützt und ca. 90%
der Router im Internet Cisco-Router sind.
CBT
CBT (Core Based Trees, RFC 2189 [4]) geht von einem zentralen Kernrouter (Core)
aus, über den der gesamte Datenverkehr fließt. Der Kernrouter ist die Wurzel des
Multicastbaumes. Dieser Algorithmus ist in die Sparse Mode“-Algorithmen einzu”
ordnen.
2.1.7
Motivation für die Verwendung von IP-Multicast
Gerade bei der hier zu implementierenden Anwendung ist es sinnvoll Multicast zu benutzen. Es sollen MPEG-2 codierte TV-Signale übertragen werden, die ca. 4 MBit/s
an Bandbreite benötigen. Da es sich um Livestreams“ handelt, werden die gleichen
”
Daten an alle Clients, die denselben Sender empfangen möchten, gesendet. Die Daten nicht mit Multicast zu versenden, wäre Verschwendung der Netzwerkbandbreite. Auch müssen die DVB-Cardserver keine besonders schnelle Netzwerkanbindung
haben, es reicht wenn sie über einen normalen 10 MBit/s Anschluss zum Router
verfügen — wie er noch weit verbreitet ist — unabhängig davon wieviele Clients
einen Stream empfangen sollen. Dies ermöglicht die Skalierbarkeit der Anwendung.
14
2 Benutzte Protokolle
2.2
RTSP
2.2.1
Real Time Streaming Protocol
Das Real Time Streaming Protocol (RTSP)“ ermöglicht die Kontrolle über Echtzeit
”
Audio- und Videostreams und wird im RFC 2326 [15] beschrieben. Das Protokoll
ist nicht für die Übertragung selber, sondern nur für die Steuerung von Multimediaservern zuständig (z.B. Initiieren von Übertragungen).
Nachfolgend einige Anwendungsfälle, für die das RTSP-Protokoll entwickelt wurde. In den Beispielen werden einige Funktionen kurz erläutert, die durch das Protokoll zur Verfügung gestellt werden:
• Multimediadaten von einem Server empfangen und steuern
Ein Client kann bei einem Server eine Beschreibung anfordern und eine Sitzung initialisieren. Der Server kann dem Client dann verschiedene Funktionen
zur Verfügung stellen, z.B. abspielen“, pause“ oder vorspulen“. Wenn das
”
”
”
Abspielen vom Client initiiert wird, teilt der Server dem Client die Multicastadresse und den Port mit, an die der gewünschte Stream geschickt wird.
• Multimediaströme von einem Server aufzeichnen lassen
Ein Multimediaserver, der das Aufzeichnen von Multimediaströmen ermöglicht,
kann von einem Client veranlasst werden einen Stream, den der Client zum
Server sendet, aufzuzeichnen und diesen dann zum Abruf wieder bereitzustellt.
• Einen Multimediaserver in einer Konferenz einbinden
In einer bestehenden Multimediakonferenz kann ein Multimediaserver so gesteuert werden, dass er Medien in die Konferenz einspielt (z.B. Videos, Folienpräsentationen, Audioannotationen, etc.), aber auch Teile oder die ganze
Konferenz aufzeichnet. Dabei können mehrere Teilnehmer dieser Konferenz
den Server steuern. Dieses Anwendungsbeispiel kann zum Beispiel in einer
verteilten Lernanwendung“ zum Einsatz kommen.
”
• Hinzufügen/Ändern von Medien in einer laufenden Präsentation
Sinnvoll für Livepräsentationen ist es, dass der Server dem Client mitteilen
kann, wenn neue Medien verfügbar sind, zum Beispiel in besserer Qualität
15
2 Benutzte Protokolle
oder zusätzliches Material. Zur Lastverteilung kann der Server den Client einem anderen Stream zuordnen und diesen über den neu zu empfangenden
Stream informieren.
Das Protokoll hat Ähnlichkeiten mit HTTP (RFC 2068 [9]), es benutzt ebenfalls
wie dieses eine Text-basierte Syntax und URLs zur Adressierung.
Eine RTSP-URL setzt sich aus rtsp://<host>[:<port>]/<media>“ zusammen.
”
Hierbei bezeichnet host“ den Internet-Namen oder die IP-Adresse des RTSP-Ser”
vers, port“ den Port auf dem der Server Anfragen annimmt und media“ die zu
”
”
steuernde Ressource. Die Angabe des Ports ist optional, ist kein Port angegeben wird
der Port 554 benutzt. Bei der Ressource kann es sich um einen kompletten Stream
oder aber um Teilstreams handeln, die Interpretation liegt beim RTSP-Server und
ist nicht im Protokoll festgelegt.
Beispiele für RTSP-URLs sind:
rtsp://media.beispiel.de:554/dasboot/mpg2video
rtsp://media.beispiel.de/dasboot/audio
rtsp://media.beispiel.de:554/dasboot/video
rtsp://radio.uni-paderborn.de:887/campusradio/mp3
rtsp://media.beispiel.de:554/rekorder/simon
16
2 Benutzte Protokolle
2.3
RTP
2.3.1
Real-Time Transport Protocol
Das Real-Time Transport Protocol (RTP)“ ist ein End-zu-End Verbindungsproto”
koll, welches Unterstützung für die Übertragung von Daten in Echtzeit gibt. Speziell
wurde es für die Übertragung von Audio- und Videodaten in Multimediakonferenzen mit mehreren Teilnehmern entwickelt. RTP ergänzt die zu verschickenden Multimediadaten um einen Header und ermöglicht unter anderem folgende Funktionen:
Identifizierung der transportierten Datentypen, Sequenznummerierung, Zeitstempel,
Multiplexing und Überwachung der Übertragung.
RTP wird in der Anwendungsebene auf das UDP oder Multicastprotokoll aufgesetzt, um zum Beispiel die Sequenznummerierung auszunutzen und den Verlust
von Paketen feststellen zu können. Es bietet keine Unterstützung für Quality-Of”
Service“, reihenfolgetreue oder garantierte Übertragung. Es wird auch als Rahmen”
protokoll“ beschrieben und soll daher nur einen Teil der Funktionen standardisieren,
die benötigt werden um Echtzeit Übertragungen zu ermöglichen.
Im RFC 1889 [14] wird das Protokoll beschrieben, dort wird auch das RTP
”
Control Protocol (RTCP)“ spezifiziert. RTCP wurde unter anderem konzipiert um
Quality-Of-Service“-Aspekte einer Übertragung überwachen zu können.
”
Die folgenden Anwendungsfälle beschreiben Szenarien, in denen das RTP-Protokoll zum Einsatz kommt. An ihnen sollen einige Funktionen von RTP beschrieben
werden.
• Eine Multicastaudiokonferenz
Für eine Audiokonferenz einer Arbeitsgruppe wird im Internet eine Multicastgruppe genutzt. Die Software, die jeder Teilnehmer verwendet, sendet kleine
RTP-Pakete, die 20 Millisekunden Audiodaten enthalten, an die Multicastgruppe.
In jedem dieser RTP Pakete enthält der Header Informationen über die Codierung der Audiodaten (PCM, MP3, etc.), damit kann während der Konferenz
die Codierung geändert werden. Dies ist z.B. sinnvoll, wenn ein neuer Teilnehmer der Konferenz beitritt, der nur mit einer geringen Bandbreite ans Internet
angeschlossen ist oder wenn die Netzwerkverbindung schlechter wird.
Bei IP-Multicast kann es vorkommen, dass einzelne Pakete verloren gehen
oder in der falschen Reihenfolge ankommen. Hier hilft der Anwendung die
Sequenznummer und die Timing-Informationen zur Fehlerkorrektur der Audiodaten. Sequenznummer und Timing-Informationen sind deshalb in jedem
RTP-Header enthalten.
17
2 Benutzte Protokolle
• Eine Audio- und Videokonferenz
Wenn Audio- und Videodaten in einer Konferenz übertragen werden sollen,
können die Daten in getrennten RTP-Strömen übertragen werden. Dies ist
sinnvoll, wenn beispielsweise Teilnehmer nur die Audiodaten empfangen wollen. Auch hierbei können die Timing Informationen, die bei RTP übertragen
werden, genutzt werden um Ton und Bild zu synchronisieren.
• Mixer“
”
Bei einer Multimediakonferenz sind die Teilnehmer mit unterschiedlicher Bandbreite an das Internet angeschlossen. Die Teilnehmer mit einer geringeren
Bandbreite können nur Multimediadaten in niedriger Qualität empfangen.
Damit nicht alle Teilnehmer die Multimediadaten in niedrigen Qualität empfangen müssen, unterstützt das RTP-Protokoll das sogenannte Mixer“ Kon”
zept. Hierbei werden die Teilnehmer in zwei Klassen eingeteilt. Ein Server
übernimmt dann die Funktion des Mixers. Dieser Server verbindet die beiden
Klassen, indem er die Multimediadaten von hoher Qualität in niedrige Qualität
umrechnet und an die Teilnehmer mit schlechter Anbindung den veränderten
RTP-Strom sendet.
• Translator“
”
Eine Multimediakonferenz soll mit Hilfe von IP-Multicast übertragen werden,
die Teilnehmer befinden sich aber in zwei verschiedenen Multicastinseln, Multicastpakete werden nicht zwischen den beiden Inseln geroutet. In diesem Fall
sieht das RTP das Konzept der Translatoren“ vor. Je ein Server übernimmt
”
pro Insel die Funktion eines Translators“, d.h. die RTP-Pakete werden durch
”
die beiden Translatoren getunnelt.
2.4
Einsatz und Motive für die Verwendung von
RTSP und RTP
RTSP
Das RTSP kommt an mehreren Stellen in der hier zu implementierenden Anwendung
zum Einsatz: zwischen CGI und Applicationserver, zwischen Applicationserver und
Cardserver und zwischen Applicationserver und Java-Applet.
RTSP findet als Standard zum Steuern von Multimediaservern immer mehr Einsatz und lässt sich durch seine Offenheit an viele Anwendungsfälle anpassen. Es
kommt außerdem zum Einsatz, da das Austauschen einzelner Komponenten der
Anwendung so wesentlich einfacher zu realisieren ist; daher kann ein anderer Player
eingebunden werden, wenn dieser MPEG-2 und RTSP unterstützt. Auch wäre es
18
2 Benutzte Protokolle
denkbar, einen Digitalen Videorekorder“ über RTSP in die Anwendung zu inte”
grieren.
RTP
Der Cardserver sendet die MPEG-2 codierten TV-Signale über das RTP.
RTP wird verwendet da es sich als Standard für das Übertragen von EchtzeitMultimediadaten durchgesetzt hat. Dieses Protokoll zu benutzen erleichtert auch
die Portierbarkeit der Clientanwendung auf andere Betriebssysteme. Es ist einfacher, für andere Betriebssysteme einen Player zu finden, wenn ein standardisiertes
Protokoll benutzt wird.
19
3 Design und Implementierung
In diesem Abschnitt werden die prototypische Implementierung der Streaming-Anwendung und die bei der Implementierung verwendeten Programme und Bibliotheken beschrieben.
3.1
Vorhandene Software
Nachfolgend werden die Programme beschrieben, auf denen die Anwendung aufbaut.
3.1.1
pvatots
Die DVB-Karte liefert kein Standard MPEG-2 Signal, sondern nur ein verwandtes
PVA-Signal. Das C-Programm pvatots“ wandelt Videodaten, die im PVA-Format
”
vorliegen, in einen MPEG-2 Transport Stream“ um.
”
3.1.2
linux dvb
linux dvb“ ist der Treiber für die vorhandene Fujitsu-Siemens DVB-PCI-Karte.
”
Über ihn lässt sich die DVB-Karte ansprechen. Dieser Treiber ist ein Open-SourceProjekt [2] und steht unter der GNU General Public License (GNU GPL)“.
”
3.1.3
sendrtp ts
Das C-Programm sendrtp ts“ kann einen MPEG-2 Transport Stream“ über RTP
”
”
an eine Multicastadresse versenden. Es steht ebenfalls unter der GNU General Pub”
lic License“.
3.1.4
Java Media Framework (JMF)
Das JMF ist eine Java-API von Sun [1], die Unterstützung für Audio und Video in
Java-Applikationen und -Applets bereitstellt. Sie bietet nicht nur Unterstützung für
20
3 Design und Implementierung
das Abspielen und Aufnehmen von Medien, sondern auch für deren Echtzeitübertragung und -empfang. In der aktuellen Version unterstützt es RTP und RTSP. Weiterhin bietet Sun Beispiel-Applets im Sourcecode an, denen eine RTSP-URL übergeben
wird und die dann einen JMF-Player zum Abspielen von Medien instantiieren.
3.1.5
Omnithread
Omnithread ist eine Bibliothek, die Threadfunktionen für C++-Programme zur
Verfügung stellt. Sie ist Teil des OmniORB-Paketes von AT&T Laboratories [3].
Auch dieses Paket ist frei verfügbar.
3.2
Benutzerschnittstellen
Es gibt zwei verschiedene Personengruppen, die auf die Anwendung zugreifen. Die
Benutzer, die TV Signale empfangen möchten, und die Administratoren des Systems,
die die Server verwalten. Für beide Gruppen müssen verschiedene Funktionen zur
Verfügung gestellt werden. Das Usecasediagramm in Abbildung 3.1 veranschaulicht
diese Funktionen.
DVB−Card−
server
s
atu n
St rage
f
ab
<Admin>
DV B−Card−
serv er v erwalten
Appli cati on−
TV −Sender
v erwalten
server
Status
abfragen
TV Signal
ansehen
Cli ent
Ap
plic
a
ein tions
e
tra
ge rv er
n
ste
erli
nd fen
e
S bru
a mm
gra
o
Pr ählen
w
CG I
Abbildung 3.1: Usecasediagramm der Anwendung
21
<B enut zer>
3 Design und Implementierung
Der Administrator soll am Cardserver den Port einstellen können, auf dem
er Befehle vom Applicationserver entgegen nimmt, und Statusmeldungen auslesen
können.
Am Applicationserver soll der Administrator für jeden Cardserver dessen IPAdresse und Port einstellen können. Außerdem soll er festlegen können, an welche
Multicastgruppe und auf welchem Port ein Cardserver die Signale sendet. Weiterhin
soll er die TV-Sender mit den benötigten Parametern übergeben können, dieses beinhaltet unter anderem den Namen der Sender und deren Trägerfrequenz. Auch beim
Applicationserver soll eine Statusabfrage möglich sein, die den Stand der Cardserver
und der Clients wiedergibt.
Das CGI benötigt die IP-Adresse und den Port des Applicationservers, der Administrator soll dieses am CGI einstellen können. Der Benutzer möchte aus einer
Liste einen TV-Sender auswählen können, diese wird von CGI erzeugt.
Mit dem Player soll der Benutzer den MPEG-2 Multicast Stream empfangen und
wiedergeben können.
3.3
Aufbau und Implementierung des Prototypen
Die Abbildung 3.2 gibt einen Überblick über die Zusammenhänge und Schnittstellen
der Teilprogramme (Module).
M P E G−2 über M ul ti cast
DVB−Card−
server
RTP
Client
RTP
RTSP
RTSP
Webbrowser/HTML
RTSP
Webserver/ HTML
Application−
server
RTSP
RTSP
Cgi
Abbildung 3.2: Zusammenhang und Schnittstellen der Module
22
3 Design und Implementierung
Für die Realisierung der Anwendung stehen Server mit DVB-Karten, ein Server
mit installiertem Apache-Webserver und PC-Workstations mit MPEG-2 Decoderkarten zur Verfügung. Auf den Servern kommt das Open-Source Betriebssystem
Linux und auf den Workstations das Betriebssystem Windows 98“ von Microsoft
”
zum Einsatz.
3.3.1
DVB-Cardserver
Der DVB-Cardserver kommt auf den Linuxrechnern mit DVB-Karte zum Einsatz
und ist in C++ geschrieben. Er spricht die DVB-Karte an, stellt den zu empfangenden Sender ein und liest das PVA-Signal aus. Dieses Signal wandelt der Cardserver
in einen MPEG-2 Transport Stream“ um und sendet diesen mittels RTP an eine
”
Multicastgruppe. Über eine RTSP-Schnittstelle lässt er sich vom Applicationserver
steuern.
Der Applicationserver kann den Cardserver anhalten, so dass er nicht mehr sendet; weiterhin kann er veranlassen dass ein neuer Sender eingestellt wird und dass
der Cardserver zu senden beginnt. Hierfür unterstützt der RTSP-Server die Kommandos: SETUP“, SET PARAMETER“, PLAY“ und TEARDOWN“.
”
”
”
”
Der DVB-Cardserver besteht aus mehreren Threads. Die main“-Routine nimmt
”
die RTSP-Verbindungen (Connects) entgegen und erzeugt für jeden Client ein neues
Klassenobjekt vom Typ RTSPServer“. Jedes dieser Objekte bildet einen Thread.
”
Die RTSPServer“ nehmen die RTSP-Kommandos der Clients entgegen und verar”
beiten diese. Ein anderer Thread baut auf pvatots“ auf und konvertiert die PVA”
Daten aus dem Videodevice (der DVB-Karte) in einen MPEG-2 Transport Stream“,
”
dieser Stream wird in eine Pipe geleitet. Dieser Thread wird mit Hilfe des Klassenobjekts Cardcontroller“ implementiert, welches auch Operationen zum Ansteuern
”
der DVB-Karte bereitstellt. Das Programm sendrtp ts“ wird mit der Pipe als Ein”
gabe gestartet, es sendet den MPEG-2 Transport Stream“ mittels RTP an die
”
Multicastadresse, die vom Applicationserver im SETUP“-Befehl übermittelt wur”
de. Abbildung 3.3 verdeutlicht diesen Prozess.
Konfiguriert wird der Cardserver über die Konfigurationsdatei cardserver.conf“,
”
die der Server in dem Verzeichnis sucht, in dem er gestartet wurde.
Der Prototyp gibt Statusmeldungen auf die Standard-Ausgabe (stdout) aus.
3.3.2
CGI
Das CGI ist ein C++-Programm, das von einem Linuxwebserver gestartet wird,
wenn der Benutzer die Einstiegsseite der Anwendung in seinem Browser aufruft. Es
schickt ein RTSP-Kommando GET PARAMETER“ an den Applicationserver in
”
dem es Informationen über den Parameter tvchannels“ anfordert. Als Antwort wird
”
23
3 Design und Implementierung
DVB−Cardserver
Applic at ion−
s erver
main
conne ct
a ccep t
C a r d con tr o le r
R T SPSe r v e r
R T SP: SET _ PAR AMET ER
f r equen cy,symbo lr a te , ...
C ard−
c ont roler
R T SP−
Server
se tFr equen cy
se tSymbo lr a te
...
R T SP− An two r t: OK
clo se
conne ct
a ccep t
R T SPSe r v e r
R T SP: SET U P
R T SP−
Server
tune C hanne l()
R T SP− An two r t: OK
clo se
conne ct
a ccep t
R T SPSe r v e r
R T SP−
Server
R T SP: PL AY
signa l
R T SP− An two r t: OK
p ipe =popen ( "send r tp_ ts
224 .1 .2 .3 6778 12 ","w")
s endrt p_ t s
clo se
p v a_ to_ ts( p v a Str ea m,p ipe )
R T SPSe r v e r
R T SP: T EARD O WN
Pipe :
MPEG− 2 T r an spo r t Str ea m
R T SP−
Server
R T P übe r Mu ltica st:
MPEG− 2 T r an spo r t Str ea m
conne ct
a ccep t
p la y = f a lse
r e tu r n ( 0 )
R T SP− An two r t: OK
p clo se ( p ipe )
clo se
Abbildung 3.3: Kommunikation der Cardserver-Threads und Applicationserver
24
3 Design und Implementierung
eine Liste der Sender geschickt, die zur Zeit zur Verfügung stehen. Diese Sender werden als RTSP-URL codiert und in einer HTML-Seite zum Webserver zurückgegeben.
Der Webserver überträgt diese HTML-Seite dann zum Browser des Benutzers. Die
Abbildung 3.4 zeigt einen Screenshot einer so erzeugten HTML-Seite.
Die RTSP-URL, an die die Anfrage geschickt wird, steht in der Konfigurationsdatei tvapp.conf“ im CGI-Verzeichnis in dem sich auch das Programm befindet.
”
Abbildung 3.4: Screenshot einer vom CGI erzeugten HTML-Seite
3.3.3
Applicationserver
Der Applicationserver existiert nur einmal im LAN. Er bedient die Cardserver und
verwaltet die Verbindungen der Clients. Er ist ein C++-Programm mit dem Namen mpgtvappd“ und kann auf dem Rechner gestartet werden, auf dem auch der
”
Webserver des LANs läuft.
In drei Listen verwaltet das Programm die Clients, TV-Sender und Cardserver,
in denen es pro Server, TV-Sender und Client ein Objekt anlegt. In diesem Objekt
werden alle wichtigen Informationen gespeichert, zum Beispiel für jeden Client welchen Sender dieser Client empfängt (vergl. Abbildung 3.5).
25
3 Design und Implementierung
my Client s
: Client
: Client
: Client
int socketID = 15
St ring channel = "A RD"
int socketID = 20
St ring channel = "ZDF"
int socketID = 21
St ring channel = "RT L"
: Client
: Client
int socketID = 17
St ring channel = "PRO7"
int socketID = 18
St ring channel = "A RD"
NULL
Abbildung 3.5: Beispielskizze der Clientliste zur Laufzeit
Das Programm öffnet ein Socket, an dem auf RTSP-Verbindungen gewartet wird.
Für jeden Client bzw. CGI wird ein eigener Thread gestartet, der die RTSP-Anfragen
des Clients oder CGI entgegennimmt und verarbeitet.
Stellt das CGI eine GET PARAMETER“-Anfrage nach dem Parameter tv”
”
channels“, schickt das Programm eine Antwort mit den zur Zeit verfügbaren Sendern zurück. Das sind alle Sender, falls noch ein Cardserver frei ist; sonst die Sender,
die gerade von den Cardservern ausgestrahlt werden.
Der Client sendet bei jeder Anfrage zum Applicationserver die RTSP-URL, in
der der gewünschte Sender codiert ist, um im Programm dem Client einen Sender
zuordnen zu können.
Sendet ein Client das RTSP-Kommando SETUP“, überprüft das Programm,
”
ob der gewünschte Sender schon von einem Cardserver ausgestrahlt“ wird. Wenn
”
noch ein Server frei ist (d.h. keinen Stream ausstrahlt), wird die Anfrage positiv
beantwortet und für den Client in der Datenstruktur vermerkt, dass der Client
den Sender empfangen will. Ist kein Cardserver mehr frei, wird der Client abgewiesen. Tritt der Fall ein, dass noch kein Cardserver den Sender ausstrahlt“, schickt
”
der Applicationserver zu einem freien Cardserver RTSP-Kommandos um den Sender einzustellen“. In dem RTSP-Kommando SET PARAMETER“ werden alle
”
”
für den Sender benötigten Daten, wie z.B. Polarisation und Trägerfrequenz, zum
Cardserver übermittelt. Mit dem RTSP-Kommando SETUP“ wird der Sender mit
”
den zuvor übermittelten Daten an der DVB-Karte eingestellt und die Multicastadresse, der Port und die TTL übermittelt. Außerdem wird in dem Datenobjekt,
das zu dem Cardserver gehört, der Sender festgehalten. Dem Client wird in der
RTSP-Antwortnachricht die Multicastadresse und der Port mitgeteilt, auf dem der
26
3 Design und Implementierung
MPEG-2 RTP-Stream zu empfangen ist nachdem das PLAY“-Kommando abge”
setzt wurde.
Sendet ein Client nach dem SETUP“-Befehl das RTSP-Kommando PLAY“,
”
”
schickt der Applicationserver dem Cardserver, der seine DVB-Karte auf den Sender eingestellt hat, das RTSP-Kommando PLAY“, falls der Cardserver den Sender
”
noch nicht ausstrahlt.
Der Applicationserver hält die TCP-Verbindung, die beim RTSP-Protokoll zustande kommt, aufrecht. Dadurch kann er feststellen, ob der Client aktiv ist. Diese
Information ist wichtig, da er so die Clients den einzelnen Cardservern zuordnen
und feststellen kann, wenn kein Client mehr von einem DVB-Cardserver Signale
empfängt.
Bricht die Verbindung zwischen Client und Applicationserver ab oder sendet der
Client das RTSP-Kommando TEARDOWN“, überprüft das Programm, ob noch
”
weitere Clients den Stream empfangen. Ist dies nicht der Fall, wird zum Cardserver
ein TEARDOWN“-Befehl geschickt und festgehalten, dass der Cardserver wieder
”
frei“ ist.
”
Auch der Prototyp des Applicationserver gibt Statusmeldungen auf die StandardAusgabe aus.
3.3.4
Client
Der Client ist ein Java-Applet von Sun welches auf JMF aufbaut. Vom Browser
wird das Applet gestartet, wenn ein Sender ausgewählt wird. Beim Start wird dem
Applet die RTSP-URL übergeben und es verbindet sich mit dem Applicationserver
über RTSP. Vom Server erhält es die Adresse, die die Multicastgruppe und den Port
enthält, auf dem der MPEG-Stream zu empfangen ist.
3.3.5
Beispielkommunikation zwischen den Modulen
Die Abbildung 3.6 zeigt den Ablauf der Kommunikation zwischen den Modulen an
einem Beispiel, in dem ein Benutzer auf die Anwendung zugreift. In diesem Beispiel
ist ein Cardserver noch frei und der Benutzer wählt einen Sender aus, der noch nicht
von einem anderen Cardserver ins LAN via MPEG-2 Multicaststream übertragen
wird. Wenn der Benutzer den Sender nicht mehr Empfangen möchte, benötigt auch
kein anderer Client diesen Sender mehr.
27
3 Design und Implementierung
Web−
browser
Webserver/
CG I
Appli cati on−
server
DVB−
Cardserver
GET
htt p://t v . upb. de/ cgi/t v app. cgi
GET _ PAR AMET ER channels
rt sp://t v . upb. de/t v app
R T SP− An two r t: Sende r liste
H T ML − Se ite mit Sende r liste
r tsp ://tv .upb .de
/tv /channe l/ARD
Cli ent
(Java−
Appl et)
SET U P rt sp://t v . upb. de
/t v / channels/ A RD
SET _ PAR AMET ER
rt sp:// cs01. upb. de/t v / channel
R T SP− An two r t: OK
SET U P
rt sp:// cs01. upb. de/t v / channel
T ransport: 224. 1. 2. 3: 6778
R T SP− An two r t: OK
R T SP− An two r t: OK
T ransport: 224. 1. 2. 3: 6778
PL AY rt sp://t v . upb. de
/t v / channels/ A RD
PL AY
rt sp:// cs01. upb. de/t v / channel
R T SP− An two r t: OK
R T SP− An two r t: OK
RT P M PEG−2
M u l ticast Stream
T EARD O WN rt sp://
t v . upb. de/t v / channels/ A RD
T EARD O WN
rt sp:// cs01. upb. de/t v / channel
R T SP− An two r t: OK
R T SP− An two r t: OK
Abbildung 3.6: Beispiel des Nachrichtenaustausches der Module
28
4 Zusammenfassung und Ausblick
In diesem Kapitel werden die Ergebnisse zusammengefasst und die technischen Probleme aufgeführt, die sich während der Implementierung des Prototypen ergeben
haben. Außerdem werden Ideen zur Erweiterung der Anwendung kurz vorgestellt.
4.1
Ergebnisse
Die prototypische Implementierung überträgt das qualitativ hochwertige Videosignal
über ein IP basiertes LAN. IP-Multicast wird verwendet um die Netzwerkressource
nicht unnötig hoch zu belasten und den restlichen Datenverkehr im Intranet nicht
zu beeinträchtigen. Durch Verwendung von standardisierten Komponenten (RTSP,
RTP, Webinterface) steht einer Erweiterbarkeit der Anwendung nichts im Weg. Die
Modularisierung der Anwendung fördert die Portierbarkeit einzelner Teile der Anwendung auf verschiedene Betriebsysteme. Durch Verwendung von IP-Multicast und
der Wahl eines modularen Aufbaus ist die implementierte Anwendung skalierbar. Es
können sowohl eine große Anzahl von Benutzern bedient werden, als auch eine variable Anzahl von gleichzeitig ausgestrahlten Sendern gehandhabt werden. Die Anzahl
der Benutzer ist sogar nahezu beliebig groß, wenn alle den gleichen Sender anfordern. Durch das Webinterface kann die Anwendung ins Intranet eingebettet werden,
da das Interface auf HTML aufbaut, ist es leicht an das Layout des Intranets anzupassen.
Technische Probleme bei der Implementierung
Vorhandene Software
JMF selbst unterstützt keine Decodierung eines MPEG-2 Streams. Das JMF gibt
es in mehreren Ausführungen, als reine Java-API und als sogennante Performance
”
Packs“. Diese Packs“ sind jeweils für ein Betriebsystem optimiert. Das Windows
”
”
Perfomance Pack“ des JMF gibt die eingehenden Multimediadaten weiter an die
Direct Show“-Schnittstelle von Microsofts Direct X“. Mit Hilfe einer MPEG-2
”
”
Decoderkarte unterstützt Direct Show“ die Wiedergabe von MPEG-2 Transport
”
”
Streams“. So ist es möglich mit den Beispielprogrammen des JMF einen MPEG-2
”
Transport Stream“ aus einem File wiederzugeben, da hier die Datentyperkennung
29
4 Zusammenfassung und Ausblick
von Direct Show“ übernommen wird. Die Typenerkennung des MPEG-2 Multicast”
streams im JMF stellte sich aber als Problem dar. Das JMF empfängt die via Multicast verschickten Daten, unterstützt aber den Payload“-Typ des Streams nicht,
”
der für MPEG-2 Streams im RTP-Header vorgesehen ist. Aus diesem Grund gibt
das Java-Applet das Videosignal nicht wieder.
Multicast im Informatik Rechnerbetrieb (IRB) der Universität Paderborn
Wie in Abschnitt 2.1.3 beschrieben, ist die Unterstützung von Multicast in IPv4
nicht vorgeschrieben. Die Linux Rechner, auf denen der Prototyp des Cardserver
entwickelt wurde, unterstützten zu Beginn der Entwicklung kein Multicast. Um die
Unterstützung von Multicast zu ermöglichen, musste hierfür ein neuer Linuxkernel
installiert werden. Die Cisco-Router die im IRB zum Einsatz kommen, sowie der
Windows 98 Rechner auf dem der Client gestartet wird, unterstützen Multicast.
4.2
Ausblick
Die Übertragung der Videoströme mit RTP macht die Anwendung offen für das
in Abschnitt 2.3 beschriebene Mixer“-Konzept, d.h. denkbar ist eine Skalierung
”
der MPEG-Ströme. Das Signal kann in MPEG-1 umgerechnet werden, welches immer noch eine vergleichbare Qualität mit VHS-Video bietet. Über dieses Konzept
könnten auch Rechner als Client fungieren, die über keine MPEG-2 Decoderkarte
verfügen oder auf denen ein anderes Betriebsystemen als Windows 98 installiert ist.
Durch die Benutzung des RTSP-Protokolls ist es möglich, Multimediaserver, die
Videomaterial bereitstellen, in die Anwendung zu integrieren. Auch die Integration
eines digitalen Videorekorders, der RTSP unterstützt ist denkbar.
Das Management der Cardserver für große LANs könnte verbessert werden.
Wenn in solchen Netzen die Cardserver topologisch an verschiedenen Stellen aufgestellt werden, macht es Sinn die Wahl des Senders, dessen codiertes Signal ein
Cardserver versendet und die Wahl der TTL, mit der er sendet, flexibler zu gestalten. Zur Zeit sendet ein Cardserver einen Stream eines Senders solange aus, bis kein
Client mehr den Stream empfängt. Wenn aber in einem Netzwerksegment des LANs,
in dem die Hosts topologisch nah beieinander liegen, viele Clients einen speziellen
Sender empfangen, ist es sinnvoll einen Cardserver aus diesem Netzwerksegment die
Videodaten ausstrahlen zu lassen und nicht einen Cardserver in einem entfernten
Segment.
30
Literaturverzeichnis
[1] JMF Home Page. http://java.sun.com/products/java-media/jmf/index.html.
Sun Microsystems, Inc.
[2] Linux TV. http://www.linuxtv.org/dvb.
[3] omniORB
Free
High
Performance
CORBA
2
ORB.
http://www.uk.research.att.com/omniORB/.
AT&T Laboratories Cambridge.
[4] A. Ballardie.
Core Based Trees (CBT version 2) Multicast Routing.
http://www.ietf.org/rfc/rfc2189.txt, 1997. RFC 2189.
[5] Brad Cain, Steve Deering, Bill Fenner, Isidor Kouvelas, and Ajit Thyagarajan.
Internet Group Management Protocol, Version 3. http://www.ietf.org/internetdrafts/draft-ietf-idmr-igmp-v3-05.txt, 2000. draft-ietf-idmr-igmp-v3-05.txt.
[6] S.
Deering.
Host
Extension
for
http://www.ietf.org/rfc/rfc1112.txt, 1989. RFC 1112.
IP
Multicasting.
[7] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. Protocol Independent Multicast-Sparse
Mode (PIM-SM): Protocol Specification. http://www.ietf.org/rfc/rfc2362.txt,
1998. RFC 2362.
[8] W. Fenner.
Internet Group Management Protocol,
http://www.ietf.org/rfc/rfc2236.txt, 1997. RFC 2236.
Version
2.
[9] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee. Hypertext Transfer Protocol – HTTP/1.1. http://www.ietf.org/rfc/rfc2068.txt, 1997.
RFC 2068.
[10] Juan-Mariano de Goyeneche.
Multicast
http://www.linuxdoc.org/, March 1998.
over
TCP/IP
HOWTO.
[11] J. Moy. MOSPF: Analysis and Experience. http://www.ietf.org/rfc/rfc1585.txt,
1994. RFC 1585.
[12] J. Moy. OSPF Version 2. http://www.ietf.org/rfc/rfc1583.txt, 1994. RFC
1583.
31
Literaturverzeichnis
[13] J.
Reynolds
and
J.
Postel.
Assigned
http://www.ietf.org/rfc/rfc1700.txt, 1994. RFC 1700.
Numbers.
[14] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A Transport
Protocol for Real-Time Applications. http://www.ietf.org/rfc/rfc1889.txt, 1996.
RFC 1889.
[15] H. Schulzrinne, A. Rao, and R. Lanphier. Real Time Streaming Protocol
(RTSP). http://www.ietf.org/rfc/rfc2326.txt, 1998. RFC 2326.
[16] D. Waitzman, C. Partridge, and S. Deering. Distance Vector Multicast Routing
Protocol. http://www.ietf.org/rfc/rfc1075.txt, 1988. RFC 1075.
[17] L. Wei, et. al. Protocol Independent Multicast Version 2 Dense Mode Specification. http://www.ietf.org, 1999. draft-ietf-pim-v2-dm-03.txt.
32