Current Page: Greybox » Authoring » Course ID: medieninformatik » Modules » Module ID: m06 » Learning Units » Unit ID: 2_1_20
Last Modified:Tuesday, 2015-05-05 - 08:09:02
 
Tools: ValidatePreview XML Preview HTML Preview PDF
Alternative: Printable HTML

 

Learning Unit ID: 2_1_20
Title: Multimedia-Dateisysteme und Vergleich von MoD Servern
Abstract: Diese LU beschäftigt sich mit den verschiedenen Strategien zur Speicherung und zum Auslesen der Mediendateien auf und von der Festplatte. Zusätzlich werden vier existierenden Media on Demand Server (Berkley VoD System, Tiger VoD System, Darwin Streaming Server, Helix Universal Server) anhand ihrer Leistungen verglichen.
 
Status:

Review II: done.

Version: 8.0
History:

Link auf LU23 done.

Acronyme, Absätze und Wordanführungszeichen done.

Grafiken verkleinern done.

Source done.

Review von Prof. Kosch eingearbeitet.

Graphik Helix überarbeitet.

Unbekannte Character ausgebessert.


Author
Author 1: Harald Kosch E-Mail: harald.kosch@itec.uni-klu.ac.at
Author 2: (empty) E-Mail: (empty)
Author 3: (empty) E-Mail: (empty)
Author 4: (empty) E-Mail: (empty)
Author 5: (empty) E-Mail: (empty)
Organization: Universität Klagenfurt - Institut für Informatik-Systeme

Content

Multimedia Dateisystem Paradigmen

1

Auto

  • Pull Server
    • eher traditionelle Sicht

Auto PC

Pull-Server

Auto PDA_Phone

Pull-Server

Auto

  • Push Server
    • passt besser für A/V

Auto PC

Push-Server

Auto PDA_Phone

Push-Server

Dateiplatzierung auf einer Platte

  • Benachbarte Alloziierung ist vorteilhaft
    • Der Inhalt eines Videoservers ändert sich normalerweise langsam
    • Fragmentierung entwickelt sich nur langsam
  • Interleaving - vermeidet Suche von A/V Dateien
    • Video, Audio, Text in einer einzigen zusammenhängenden Datei je Film
    • Ungewollte Audio- oder Textdateien müssen gelesen werden- Nachteil
Auto PC

Interleaving von Frames

Auto PDA_Phone

Interleaving von Frames

Plattenblockgröße

  • Kleine Plattenblöcke (1-2 KB)
    • Frame in benachbarten Bereichen
Auto PC

Kleine Plattenblöcke

Auto PDA_Phone

Kleine Plattenblöcke

Auto
  • Große Plattenblöcke (z.B. 256 KB)
    • Starke interne Fragmentierung
Auto PC

Große Plattenblöcke

Auto PDA_Phone

Große Plattenblöcke

Buffering

  • Doppeltes Buffering
    • Produzent/Konsument tauschen den Buffer in jedem Durchlauf
Auto PC

Buffering

Auto PDA_Phone

Buffering

Auto
  • Dreifaches Buffering (jeder Buffer kann auch noch doppelt sein)
    1. Datenbeschaffungsbuffer (z.B. von Platte zu Hauptspeicher)
    2. Zwischenbuffer (von Hauptspeicher zu Hauptspeicher)
    3. Zustellungsbuffer (z.B. Hauptspeicher zu Netzwerk)

Platzierung mehrerer Dateien auf einer Platte

Auto PC

Orgelpfeifenverteilung

Auto PDA_Phone

Orgelpfeifenverteilung

Auto
  • Orgelpfeifenverteilung der Dateien am Server-Kopf steht in der Mitte
    • Populärste Filme in der Mitte der Platte
    • Die nächst wichtigen Filme an die jeweilige Seite, etc.

Dateiplatzierung auf einer "Disk Farm"

Auto PC

"Disk Farm"

Auto PDA_Phone

"Disk Farm"

Auto
  • a.) Kein Striping - leicht zu implementieren, schlechte Balance
  • b.) Gleiches Stripingmuster für alle Dateien
  • c.) Gestaffeltes Striping - verschiebt die Startblöcke
  • d.) Zufälliges Striping

Striping nach Frames vs. Blöcke

  • Striping von Frames
    • Frame_1 wird auf Platte_1 gespeichert, Frame_2 auf Platte_2 etc.
    • Frames haben verschiedene Größen
    • Frames werden einzeln gelesen: keine Beschleunigung bei einzelnen Videos, aber die Gesamtauslastung ist besser balanziert
  • Striping von Blöcken
    • System kann leicht mehrere Blöcke lesen
    • Anforderungen an Buffer können hoch werden
    • z.B. 1000 aktive Benutzer, 4 Platten, 256 KB Blöcke werden benötigt
    • 1 GB RAM Buffer - noch annehmbar auf einem starken Server
  • Breites bzw. begrenztes Striping
    • Benutzt alle Platten bzw. eine Teilmenge der Platten fürs Striping

Datei Caching

  • Die meisten Filme werden auf DVD311 oder Band gespeichert
    • Bei Anfrage werden sie auf die Platte kopiert
    • Daraus ergibt sich eine große Start-up Verzögerung
  • Die populärsten Filme werden auf der Platte gespeichert
    • Gut für populäre Filme, unfair gegenüber den anderen
  • Die ersten Minuten jedes Films werden auf der Platte gespeichert
    • Der Teil des Films auf der Platte wird gestartet, während der Rest von anderen Medien geholt wird

Statisches und dynamisches Platten-Scheduling

  • Statisches Platten-Scheduling
    • In jeder Runde fragt jeder Film nach einem Frame
      • Eine Runde besteht 33.3msec für NTSC164, 40msec für PAL167
    • Anfragen sind wie üblich optimiert (z.B. SCAN)
  • Dynamisches Platten-Scheduling
    • Bedienung von Anfragen, die während des Scheduling-Zyklus eintreffen
    • Scan-EDF439 Algorithmus
      • Wahl der Anforderung mit der höchsten Zeitschranke
      • Unter Anforderungen mit gleicher Zeitschranke wird SCAN angewandt
      • Effizienz ist abhängig von der Häufigkeit der Anwendung

2

Auto

Die Anforderung an ein Multimedia-Dateisystem hängt grundsätzlich davon ab ob der Video Server als Push- oder Pull-Server eingesetzt wird:

Auto PC

Pull-Server

Auto PDA_Phone

Pull-Server

Auto PC

Push-Server

Auto PDA_Phone

Push-Server

Auto

Beim Design von Medien-Servern unterscheidet man anwendungsspezifisch zwischen einem Datenzugriff, der ausschließlich durch einen Daten anfordernden und sendenden Benutzer kontrolliert wird (Abbildung a), und einem solchen, bei dem der Server den Sendeprozess kontrolliert, auch wenn jener durch den Benutzer initiiert wurde (Abbildung b). Ein Medien-Server, der im ersten Modus betrieben wird, wird als Pull-Server bezeichnet, analog ein im zweiten Modus arbeitender als Push-Server.

Pull-Server
stellen die traditionelle Sicht von Servern dar. Sie sind beim Zugriff auf multimediale Dokumente in LAN44-Umgebungen die geeignete Wahl, da ein linearer Zugriff auf diese Daten zwar oft vorkommt, aber nicht die Regel darstellt.
Push-Server
sind eine gute Wahl für eine Broadcast- bzw. Multicast-Verteilung von Daten über eine große räumliche Distanz hinweg, in der eine Benutzerinteraktion nie oder nur selten auftritt. Anwendungen, die in bezug auf diese Anforderungen nicht eindeutig abzugrenzen sind, können mit beiden Ansätzen realisiert werden.

Dateiplatzierung auf einer Platte

Für die Dateiplatzierung auf der Platte gibt es grundsätzlich 2 Alternativen. Man kann die Dateien in aufeinanderfolgenden Blocks oder verteilt auf der Festplatte speichern. Die aufeinanderfolgende Speicherung ist leicht zu implementieren und bietet den Vorteil, dass nur der Beginn einer zu lesenden Datei gesucht werden muss. Allerdings ergibt sich das Problem der Fragmentierung (Zerstückelung) der Festplatte durch Einfüge-, Lösch- und Änderungsoperationen.

Die verteilte Speicherung der Dateien vermeidet dieses Problem von Anfang an, allerdings sind beim Lesen einer Datei mehrere Suchoperationen notwendig, da die Datei nicht in aufeinanderfolgenden Blöcken gespeichert ist.

Aufgrund der Tatsache, dass sich der Inhalt eines Videoservers nur sehr langsam ändert und dadurch das Problem der Fragmentierung nur geringfügig auftritt, ist hier die Speicherung in aufeinanderfolgenden Blöcken zu bevorzugen.

Darüber hinaus muss untersucht werden, wie unterschiedliche Tracks (im einfachsten Fall der Audio und Videotrack) auf der Platte platziert werden können. Dazu verwendet man häufig Interleaving.
Interleaving ist eine Technik, bei der die zusammengehörigen Video-, Audio- und Textdateien eines Films in einer zusammenhängenden Datei gespeichert werden (siehe untere Abbildung)

Auto PC

Interleaving von Frames

Auto PDA_Phone

Interleaving von Frames

Auto

Mithilfe von Interleaving ist es möglich, die Suche aller zu einem Frame zugehörigen Dateien (Video, Audio, Text) zu vermeiden. Nachteilig ist allerdings, dass bei Auslesen der Datei auch nicht benötigte Audio- und Textdateien gelesen werden müssen.

Plattenblockgröße

Die Plattenblockgröße spielt eine große Rolle in der Multimedia-Datenorganisation. Man unterscheidet Strategien mit kleinen und solche mit großen Plattenblöcken.

Auto PC

Kleine Plattenblöcke

Auto PDA_Phone

Kleine Plattenblöcke

Auto

Abbildung a zeigt die Dateiorganisation mit kleinen Datenblöcken. Die Blöcke sind um einiges kleiner als die durchschnittliche Framegröße (z.B. für MPEG31-2 ist die durchschnittliche Framegröße 16 KB). In dieser Organisation wird ein Frameindex für jeden Film benötigt. Dieser beinhaltet je einen Eintrag pro Frame, der sich aus einem Pointer auf das betreffende Frame und einem Blockzähler zusammensetzt. Das Frame besteht aus allen zugehörigen Video-, Audio- und Textdateien, die in aufeinanderfolgenden Blocks gespeichert sind. So ist es möglich mit einem Plattenzugriff das ganze Frame zu lesen.

Auto PC

Große Plattenblöcke

Auto PDA_Phone

Große Plattenblöcke

Auto

In Abbildung b wird eine Dateiorganisation mit großen Datenblöcken (z.B. 256 KB), welche jeweils mehrere Frames enthalten, dargestellt.
Für diese Organisation wird nur ein Blockindex verwendet, welcher dem I-Node eines traditionellen UNIX-Dateisystems entspricht. Der Index enthält zusätzliche Informationen, wie z.B. die Nummer des ersten Frames pro Block. Wenn kein Aufspalten von Frames über Blöcke erlaubt ist, so führt das dazu, dass Speicherplatz am Ende eines Blocks ungenutzt bleibt. Dadurch kann die Organisation unter starker interner Fragmentierung leiden. Wenn die Dateiplatzierung die Auffüllung der Blöcke fordert, so werden Frames auch über zwei Blöcke aufgeteilt. Das kann allerdings durch den erhöhten Suchaufwand zu Performanceverlusten führen.

Buffering

Bei Multimedia Ein-/ Ausgabeoperationen ist die Verwendung eines Buffers notwendig.

Auto PC

Buffering

Buffering PDA_Phone

Buffering

Auto

Eine weit verbreitete Technik ist das sogenannte Double Buffering. Wie man aus der obigen Abbildung ersehen kann, dient ein Buffer dem Produzenten eines Streams, der andere Buffer ist für den Konsumenten des Streams gedacht. Nach jedem Durchlauf werden die Buffer getauscht. So kann beispielsweise bei der Übertragung eines Videos der Inhalt des einen Buffers vom Benutzer gelesen werden, während der zweite mit den neu ankommenden Frames gefüllt wird. Hat der Benutzer nun den Inhalt des ersten Buffers ausgelesen, so kann er direkt mit dem Lesen des zweiten fortfahren, während der erste Buffer wieder neu gefüllt wird.

Es gibt auch die Möglichkeit mit drei Buffern (Triple Buffering), einem Datenbeschaffungsbuffer, einem Zwischenbuffer und einem Zustellungsbuffer, zu arbeiten. Der erste hat die Aufgabe die Daten, die von einem I/O Gerät z.B. von der Platte zum Hauptspeicher geladen werden, zu buffern. Der zweite speichert Daten, die innerhalb des Hauptspeichers übertragen werden, zwischen. Aufgabe des dritten ist die Zwischenspeicherung von Daten die an I/O Geräte geliefert werden, z.B. vom Hauptspeicher ans Netzwerk. Zusätzlich ist es möglich, bei jedem dieser Buffer das Konzept des doppelten Bufferings anzuwenden.

Platzierung mehrerer Dateien auf einer Platte

Auto PC

Orgelpfeifenverteilung

Auto PDA_Phone

Orgelpfeifenverteilung

Auto

Um mehrere Mediendateien optimal auf einer Platte zu speichern kann die Zipf-Verteilung, welche bereits in der vorherigen LU ausführlich erklärt wurde, angewendet werden. Es werden die Filme der Priorität nach von der Mitte der Platte nach außen gespeichert, wodurch eine sogenannte Orgelpfeifenverteilung, wie in der Abbildung ersichtlich, entsteht. Der Kopf der Platte steht in der Mitte, also über den populärsten Filmen.

Dateiplatzierung auf einer "Disk Farm"

Hat man nun mehrere Platten (Disk Farm) zur Speicherung der Dateien zur Verfügung, so gibt es verschiedene Strategien die Dateien darauf zu speichern. Eine solche Disk Farm wird abstrakt als eine einzige dargestellt. Ziel dieser Abstraktion ist die Steigerung der Performance und der Verlässlichkeit.

Auto PC

"Disk Farm"

Auto PDA_Phone

"Disk Farm"

Auto

Abbildung a zeigt die Speicherung von Dateien ohne Striping, hierbei wird eine Platte nach der anderen gefüllt. Diese Variante ist leicht zu implementieren, allerdings weist sie eine schlechte Balanzierung auf, da einige Dateien öfter angefragt werden als andere und somit auf gewisse Platten öfter zugegriffen wird. Das kann auch zu schlechten Zugriffszeiten führen, da der Zugriff auf die Festplatte einen Engpass darstellt.

In Abbildung b wird für alle gespeicherten Dateien das gleiche Stripingmuster verwendet. Die einzelnen Stripeeinheiten werden nach dem gleichen Muster auf die einzelnen Platten verteilt. Problematisch ist hierbei, dass bei vielen gleichzeitigen Anfragen nach Videos zu Beginn immer auf die gleichen Platten zugegriffen wird.

Abbildung c stellt gestaffeltes Striping dar. Hier wird jeweils die erste Stripeeinheit jeder Datei auf einer anderen Platte gespeichert.

In Abbildung d sieht man die Verteilung der Dateien mittels zufälligen Stripings. Durch zufälliges Striping werden die Dateien gleichmäßig auf die einzelnen Platten verteilt. Dadurch wird die Zugriffszeit verringert und die Balanzierung erhöht.

Striping nach Frames vs. Blöcke

Beim Striping werden die einzelnen Dateien in Stripeeinheiten unterteilt. Man kann entweder Frames (constant time length) oder Blöcke (constant data length) als Stripeeinheiten definieren. Diese Einheiten werden nach verschiedenen Verfahren über alle Platten verteilt.

Wird ein Frame als Stripeeinheit definiert, so wird oft das erste Frame auf der ersten Platte, das zweite auf der zweiten Platte usw. gespeichert. Die Größe der Frames ist unterschiedlich, sie geben aber die gleiche Anzahl an Millisekunden Spielzeit wieder. Bei diesem Striping werden die Frames einzeln ausgelesen. Das führt zwar zu keiner Beschleunigung beim Auslesen einzelner Filme, allerdings ist die Gesamtauslastung ausgeglichener.

Wird ein Block als Stripeeinheit herangezogen, so führt das zu einer Beschleunigung beim Auslesen eines Videos, da das System leicht mehrere Blöcke lesen kann. Allerdings können die Anforderungen an den Buffer sehr hoch sein, da eine große Menge an Daten gleichzeitig gelesen wird.

Im Vergleich zu dynamischer Dateiplatzierung wird Plattenstriping nicht komplexer wenn die Anzahl der Platten ansteigt. Durch Striping wird die Auslastung ausgeglichener, woraus sich kürzere Antwortzeiten und ein größerer Durchsatz ergeben. Es ist möglich eine Datei entweder über alle Platten (breites Striping) oder nur auf eine Teilmenge der Platten (begrenztes Striping) zu verteilen. Beim breiten Striping sind nur geringe Informationen über die Auslastung nötig um Entscheidungen über die Platzierung der Dateien zu treffen, wohingegen begrenztes Striping viel Information über die Auslastung benötigt um die Dateien optimal auf den Platten zu platzieren.

Datei Caching

Da Filme im Allgemeinen großen Speicherplatz benötigen, ist es hilfreich, sich über die Art der verwendeten Speichermedien Gedanken zu machen. Es ist möglich den Großteil der Filme auf DVD311 oder Band zu speichern. Das birgt den Vorteil, dass diese Medien billiger sind als die Speicherung auf Festplatten. Allerdings ergibt sich eine große Start-up Verzögerung, da die Filme, wenn sie angefragt werden, erst auf die Platte kopiert werden müssen, bevor sie übertragen werden.
Speichert man die Filme mit der größten Popularität auf der Platte und die restlichen auf anderen Medien, verringert sich zumindest bei den gefragten Filmen die Start-up Verzögerung. Allerdings ist diese Methode unfair gegenüber Anforderungen für weniger gefragte Filme, da hier die Start-up Verzögerung immer noch sehr hoch ist.
Eine fairere Methode ist es, die ersten paar Minuten jedes vorhandenen Films auf der Platte zu speichern. Sobald eine Anfrage für einen Film eintrifft, wird der Teil des Films der auf der Platte liegt übertragen. Gleichzeitig wird der Rest des Films von den anderen Medien auf die Platte geladen und von dort aus an den Benutzer übertragen. Dadurch ergibt sich ebenfalls eine geringere Start-up Verzögerung.

Statisches und dynamisches Platten-Scheduling

Platten-Scheduling hat die Aufgabe die Reihenfolge festzulegen, in der die anstehenden Plattenanforderungen befriedigt werden. Die angestrebten Ziele entsprechen denen aller Scheduler, das sind kurze Antwortzeiten, hoher Durchsatz und Fairness, wobei kurze Antwortzeiten und hoher Durchsatz konfliktäre Ziele darstellen.

Beim statischen Platten-Scheduling wird in jeder Runde nach einem Frame pro Film angefragt. Eine Runde entspricht z.B. 33,3 msec für NTSC164 und 40 msec für PAL167. Die angefragten Blöcke werden, nachdem ein Optimierungsalgorithmus auf die Anfragen angewendet wurde, an die Benutzer ausgeliefert. Ein möglicher Optimierungsalgorithmus ist SCAN. Hierbei bewegt sich der Plattenkopf zunächst nur in eine Richtung, bis es dort keine anstehenden Anforderungen mehr gibt, dann in die andere Richtung (bidirektional) um die Suchzeit zu minimieren. Dieser Algorithmus bietet einen guten Kompromiss zwischen den Anforderungen an Durchsatz und Antwortzeiten, allerdings ist er ziemlich unfair (Anforderungen können "verhungern").

Beim dynamischen Platten-Scheduling können auch Anfragen bedient werden, die während eines Scheduling-Zyklus eintreffen. Einen dynamischen Scheduling Algorithmus stellt Scan-EDF439 dar. SCAN-EDF439 (SCAN-Earliest-Deadline-First) ist eine Kombination aus SCAN und EDF439. Die Optimierung der Suche wird mit den Echtzeitgarantien von EDF folgendermaßen kombiniert: Die Anforderung mit der frühesten Zeitschranke wird wie in EDF439 immer zuerst bedient. Unter Anforderungen mit derselben bzw. einer ähnlichen Zeitschranke wird zunächst die ausgewählt, die in der Bewegungsrichtung des Plattenkopfes liegt. Unter den verbleibenden wird dieses Prinzip wiederholt, bis keine Anforderung mit dieser Zeitschranke mehr übrig ist. Später eintreffende Anfragen werden aufgrund ihrer Zeitschranken und der Position der angefragten Datei auf der Platte in die Reihenfolge der Abarbeitung eingegliedert. Da diese Optimierung nur in Kraft tritt, wenn Anforderungen mit derselben Zeitschranke vorliegen, hängt die Effizienz des Algorithmus davon ab, wie oft er angewendet werden kann (d. h. wie viele Anforderungen dieselbe oder ähnliche Zeitschranken haben).

Vergleich von MoD Servern

1

Auto

Kriterien:

  • Echtzeit-Auslieferung
    • Starkes oder schwaches periodisches Abspielen, Benutzung von RTP106+RTSP146
      Skalierbarkeit
    • Horizontal: # der Serverknoten kann wachsen
    • Vertikal: Kapazität der existierenden Knoten kann wachsen
  • Fehlertoleranz - Redundanz verfügbar
  • Transparenz - der Benutzer sieht nur ein System
  • Systemkosten pro Benutzer
    • Kosten_Benutzer = benötigte Bandbreite_Benutzer * Dauer_Benutzer

Das Berkeley Video-on-Demand System

  • NMoD442 für Unternehmen
  • Datenakquirierung zu ASs
  • AS wählt den besten VFS
Das Berkeley Video-on-Demand System
Servicemodell Pull
Skalierbarkeit Medium, h+v
Architektur Verteilt
RT Streaming Nein
Fehlertoleranz Ja
Kosten/Benutzer Sehr hoch
Auto PC

Das Berkeley VoD System

Auto PDA_Phone

Das Berkeley VoD System

Das Tiger VoD System

  • Weitreichendes NMoD442 (µsoft)
  • Breites Striping
  • Größtenteils parallel
Das Tiger VoD System
Servicemodell Pull (closed)
Skalierbarkeit Medium, h+v
Architektur Verteilt
RT Streaming Ja
Fehlertoleranz Ja
Kosten/Benutzer Sehr hoch
Auto PC

Das Tiger VoD System

Auto PDA_Phone

Das Tiger VoD System

Der Darwin Streaming Server

  • Open source v. von Apple QuickTime SS
  • MPEG31-1,2,4, RTP106, RTSP146, uni+multicast
  • Skip Schutz®: verwendet übermäßige Bandbreite um Daten schneller als RT zu buffern
Der Darwin Streaming Server
  Broadcast TMoD
Servicemodell Push (open) Pull (closed)
Skalierbarkeit Hoch, h+v Medium, v
Architektur Verteilt Zentriert
RT Streaming Ja Ja
Fehlertoleranz Ja Nein
Kosten/Benutzer Sehr gering Sehr hoch
Auto PC

Der Darwin Streaming Server

Auto PDA_Phone

Der Darwin Streaming Server

Der Helix Universal Server

  • Real Networks®, teilweise Open Source
  • Viele Formate + Protokolle
  • Splitting a) push, b) pull
    • Kette von Sendern und Empfängern
Der Helix Universal Server
  Broadcast TMoD
Servicemodell Push (open) Pull (closed)
Skalierbarkeit Hoch, h+v Hoch, h+v
Architektur Verteilt Verteilt
RT Streaming Ja Ja
Fehlertoleranz Ja Ja
Kosten/Benutzer Sehr niedrig Sehr niedrig
Auto PC

Der Helix Universal Server

Auto PDA_Phone

Der Helix Universal Server

 

2

Auto

Um verschiedene Systeme miteinander vergleichen zu können müssen bestimmte Kriterien zur Beurteilung herangezogen werden.

  • Bei Media on Demand Servern ist ein Kriterium die Möglichkeit der Echtzeit-Auslieferung. Hierbei ist wichtig, ob vom Server das Real Time Transport Protocol (RTP106) und das Real Time Streaming Protocol (RTSP146) unterstützt wird. RTP106 ist ein IP-basiertes Protokol, dass die Übertragung von Echtzeit-Daten, wie Video und Audio Streams unterstützt (siehe LU MM-Übertragungsprotokolle). RTSP146 erlaubt die Beschreibung von angebotenen Inhalten und Übertragungsparametern, unterstützt die Aushandlung und Festlegung des Übertragungskanals und der Transportmethode, die Steuerung mehrerer zu einer Übertragung gehörender Medienströme und widmet sich Fragen der Lizensierung. Durch Verwendung von Zeitstempeln mit hoher Genauigkeit ist es auch für digitale Editieroperationen (bspw. Filmschnitt) geeignet. RTSP146 ist unabhängig vom unterliegenden Transportprotokoll und kann daher sowohl über UDP141 als auch über TCP145 eingesetzt werden.
  • Des weiteren ist die Möglichkeit der Skalierbarkeit ein wichtiges Kriterium bei der Bewertung von MoD Servern. Zum einen sollte die Möglichkeit der horizontalen Erweiterung, das bedeutet eine Steigerung der Anzahl der Serverknoten, zum andere eine vertikale Erweiterung, durch Steigerung der Kapazität der existierenden Knoten, geboten werden.
  • Die Fehlertoleranz stellt ein weiteres wichtiges Kriterium dar. Diese kann eigentlich nur durch redundante Speicherung der Daten (z.B. RAID107 System) realisiert werden, was auf der anderen Seite zum Verlust von Speicherkapazität führt.
  • Um den Zugang für den Benutzer zu vereinfachen und ihm Transparenz zu gewähren, sollte der Medienserver für ihn nur als ein System erkennbar sein.
  • Die Systemkosten sind ebenso von enormer Wichtigkeit. Die Kosten pro Benutzer ergeben sich aus der von ihm benötigten Bandbreite multipliziert mit der Dauer der Übertragung

Das Berkeley VoD System

Das Berkeley VoD System
Servicemodell Pull
Skalierbarkeit Medium, h+v
Architektur Verteilt
RT Streaming Nein
Fehlertoleranz Ja
Kosten/Benutzer Sehr hoch
Auto PC

Das Berkeley VoD System

Auto PDA_Phone

Das Berkeley VoD System

Auto

Das Berkeley Distributed VoD System ist ein hierarchisch aufgebautes Speichersystem mit der Aufgabe, transparenten Zugang zu einer großen Menge an Videomaterial zu bieten. Das System setzt sich aus einer Datenbank, einer oder mehr Videodatei-Servern (VFS444) und einem oder mehr Archivservern (AS) zusammen. Die Datenbank beinhaltet Metadaten und Indexe über die gespeicherten Videos. Die VFS444 speichern Videos auf Platten für die Echtzeitabspielung. Die AS haben die Aufgabe, die tertiären Speichergeräte (z.B. optische Platten oder Bandplattenstationen) zu verwalten. Im Endeffekt stellen die VFS einen Online-Cache für die Videos, welche auf den tertiären Speichergeräten abgelegt sind, dar.
Der AS hat die Aufgabe zu entscheiden, auf welchen VFS444 ein angefragtes Video geladen werden soll. Diese Entscheidung basiert vor allem auf der momentanen Netzwerkauslastung, der Auslastung der VFS444, von welchem der Benutzer das Video abspielt.
Das Berkeley VoD432 System stellt eine Pull-Architektur dar. Bis zu einem gewissen Maße ist es möglich, das System sowohl horizontal als auch vertikal zu erweitern. Durch redundante Speicherung wird auch Fehlertoleranz geboten. Aufgrund der Tatsache, dass dieses System generiert wurde um einem kleinen, autorisierten Benutzerkreis den Zugang zu einer großen Menge an Videomaterial zu ermöglichen, sind die Systemkosten pro Benutzer sehr hoch.

Das Tiger VoD System

Das Tiger VoD System
Servicemodell Pull (closed)
Skalierbarkeit Medium, h+v
Architektur Verteilt
RT Streaming Ja
Fehlertoleranz Ja
Kosten/Benutzer Sehr hoch
Auto PC

Das Tiger VoD System

Auto PDA_Phone

Das Tiger VoD System

Auto

Das Tiger VoD432 System wurde von Microsoft entwickelt und stellt eine verteilte Pull-Architektur dar. Das System arbeitet größtenteils parallel und wurde entwickelt um die Speicherung und Übertragung von interaktiver Multimedia, hauptsächlich in groß angelegten Systemen, wie interaktives Fernsehen (ITV) zu unterstützen.
Das Tiger VoD System verwendet breites Striping zu Speicherung der Filme. Die Filme werden zur Zeit in 1 MB Blöcken über alle Platten verteilt. Die Verteilung erfolgt in der Reihenfolge der Plattennummern. Beim Auslesen der Filme werden die einzelnen Pakete von den Festplatten zum ATM Netzwerkkontroller geleitet, welcher sie dann zu den Benutzern überträgt.
Aufgrund der verteilten Architektur des Systems ist sowohl eine horizontale, als auch eine vertikale Skalierung möglich.
Das Tiger System verwendet verschachteltes Declustering um Fehlertoleranz zu bieten. Diese Methode basiert auf Spiegelungsschemen. Ist ein Datenblock auf der i-ten Platte gespeichert, so wird die Kopie des Blockes auf die Platten i bis i+d verteilt, wobei d den Decluster-Faktor darstellt. Je größer d gewählt wird, desto kleiner ist die reservierte Recovery-Bandbreite, da d die Anzahl der Platten, über die die Arbeit der fehlerhaften Platte verteilt wird, erhöht. Wird d hingegen zu klein gewählt so besteht eine größere Wahrscheinlichkeit, dass auch die Platten, welche für die Sekundärspeicherung genutzt werden, fehlerhaft sind. Die Auswahl der Größe von d stellt somit einen Kompromiss zwischen diesen beiden Extremen dar. Dadurch kann das Tiger System nur eine begrenzte Fehlertoleranz bieten.

Der Darwin Streaming Server

Der Darwin Streaming Server
  Broadcast TMoD
Servicemodell Push (open) Pull (closed)
Skalierbarkeit Hoch, h+v Medium, v
Architektur Verteilt Zentriert
RT Streaming Ja Ja
Fehlertoleranz Ja Nein
Kosten/Benutzer Sehr gering Sehr hoch
Auto PC

Der Darwin Streaming Server

Auto PDA_Phone

Der Darwin Streaming Server

Auto

Der Darwin Streaming Server ist die Open Source Version des Quick Time Streaming Servers von Apple. Er unterstützt MPEG31-1,2,4 und verwendet für die Übertragung der Multimedia-Daten die Standards RTP106 und RTSP146. Der Server hat die Möglichkeit die Streams sowohl über Multicast als auch das traditionellere Unicast zu übertragen. Die Übertragungsmöglichkeiten für Echtzeit-Streaming-Medien lassen sich in zwei Kategorien teilen: Live-Broadcast und On-Demand. Die Live-Broadcast Übertragungen werden von einer Push-Server Architektur getätigt, die sowohl horizontal als auch vertikal stark skalierbar ist. On-Demand Dienste werden von einem Server, der auf der Pull-Architektur aufbaut, angeboten, wobei diese Architektur zentriert ist und nur bedingte Möglichkeiten der vertikalen Skalierung bietet.
Beim Echtzeit-Streaming hängt die Qualität von der verfügbaren Bandbreite des Netzwerks ab, das Server und Benutzer verbindet. Um Übertragungsfehler wie Unterbrechungen und Aussetzer zu vermeiden, verwendet der Darwin Server Skip-Schutz. Der Skip-Schutz nutzt überzählige Bandbreite, um Daten im Voraus schneller als in Echtzeit beim Benutzer zu buffern. Gehen Pakete verloren, werden aufgrund der Kommunikation zwischen Benutzer und Server nur die verlorenen Pakete erneut übertragen, sodass Beeinträchtigungen im Netzwerkverkehr möglichst gering gehalten werden. Der Darwin Server kann auch als Relay konfiguriert werden. Ein Relay sendet empfangene Streams an mehrere Benutzer weiter. Dadurch ist es möglich die Bandbreitenanforderungen bei Broadcast zu reduzieren und einen Lastenausgleich unter den Servern zu erreichen.

Der Helix Universal Server

Der Helix Universal Server
  Broadcast TMoD
Servicemodell Push (open) Pull (closed)
Skalierbarkeit Hoch, h+v Hoch, h+v
Architektur Verteilt Verteilt
RT Streaming Ja Ja
Fehlertoleranz Ja Ja
Kosten/Benutzer Sehr niedrig Sehr niedrig
Auto PC

Der Helix Universal Server

Auto PDA_Phone

Der Helix Universal Server

Auto

Der Helix Universal Server ist eine Entwicklung von Real Networks, der in der Lage ist 55 verschiedene Formate zu unterstützen, wie z.B. MPEG31-2,4, Apple QuickTime, und Windows Media. Zusätzlich bietet er Unterstützung für alle gängigen Real-Time Protokolle.

Die Helix DNA Plattform setzt sich zusammen aus einem Helix DNA Benutzer, einem Helix DNA Server und einem Helix DNA Produzent (siehe obige Abbildung).

  • Der Helix DNA Benutzer ist eine universelle Playback Maschine, welche die Dekodierung und das Abspielen von Datentypen unterstützt.
  • Aufgabe des Helix DNA Servers ist die Übertragung der Medien über das Netzwerk. Er ist skalierbar, und bietet eine Echtzeit-Übertragung von Medien über IP-Netzwerke. Aufgrund der Tatsache, dass der Server auf den Prinzipien der Erweiterbarkeit und Datenkompatibilität entwickelt wurde, kann er relativ leicht für eine große Anzahl an Übertragungsapplikationen adaptiert werden.
  • Der Helix DNA Produzent übernimmt die Transkodierung von Mediendaten in die verschiedenen Formate in Broadcast- und on-Demand-Ströme.

Insgesamt bietet die Helix DNA Plattform eine Ende-zu-Ende Technologie für die Erstellung, Übertragung und das Abspielen von Multimedia über das Internet.

Die Ausstrahlung von Broadcast Übertragungen erfolgt über eine Push-Architektur, MoD-Dienste werden durch eine Pull-Architektur angeboten. Vom Server wird eine dynamische Anpassung an die jeweils zur Verfügung stehende Bandbreite sichergestellt. Dabei bedient er jeden Benutzer mit der für ihn besten Bandbreite. So kann sichergestellt werden, dass selbst Betrachter mit niedriger Bandbreite die Datenströme unterbrechungsfrei, aber mit entsprechend geringer Qualität empfangen können, während Betrachter mit hohen Bandbreiten in den Genuss der optimalen Videoqualität kommen.
Der Helix Server bietet eine zuverlässige Übertragung, bei Service-Fehlern oder ungeplanten Ausfällen werden Anfragen automatisch auf die Backup-Server geroutet.

3

Das Berkley VoD System

Weitere Informationen unter: LOD3

Das Tiger VoD System

Weitere Informationen unter:LOD3

  • BFD97

Der Darwin Streaming Server

Weitere Informationen unter:LOD3

Der Helix Universal Server

Weitere Informationen unter:LOD3

Bbiliographie

2

Auto

Ste00

JCB97

WBS98

BFD97


Notes
(empty)