DE102009012992A1

DE102009012992A1 - Verfahren und System zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten in einem Datennetz

Info

Publication number: DE102009012992A1
Application number: DE102009012992A
Authority: DE
Inventors: Alexander Lipfert; Quirin Hofstätter
Original assignee: Technische Universitaet Muenchen
Current assignee: Technische Universitaet Muenchen
Priority date: 2009-03-13
Filing date: 2009-03-13
Publication date: 2010-09-23
Anticipated expiration: 2029-03-14
Also published as: WO2010102926A2; DE102009012992B4; US20120084392A1; WO2010102926A3

Abstract

Die Erfindung betrifft ein Verfahren zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten (K1, ..., K8, K', K'') in einem Datennetz, wobei die Medieninhalte eine oder mehrere Mediendateien (VF) umfassen und die Knoten (K1, ..., K8, K', K'') über Adressen in dem Datennetz adressierbar sind. In dem erfindungsgemäßen Verfahren wird für jede im Datennetz bereitzustellende Mediendatei (VF) eine dezentrale, über einen oder mehrere erste Knoten (K1, ..., K8) verwaltete Struktur (R) dadurch gebildet, dass die jeweilige Mediendatei (VF) in eine Mehrzahl von Abschnitten (C) aufgeteilt wird und den Abschnitten (C) jeweils ein Identitätswert (0, ..., 31) aus einem Identitätsintervall, umfassend aufeinander folgende Identitätswerte (0, ..., 31), zugeordnet wird, wobei der oder die ersten Knoten (K1, ..., K8) jeweils für ein Teilintervall aus dem Identitätsintervall und hierdurch für eine Teilmenge an Abschnitten (C) aus der jeweiligen Mediendatei (VF) zuständig sind. In einem jeweiligen ersten Knoten (K1, ..., K8) der dezentralen Struktur (R) wird eine Anzahl von zweiten Knoten (K', K'') mit deren Adressen hinterlegt, wobei der oder die zweiten Knoten (K', K'') zum Bereitstellen der Abschnitte (C) gemäß dem Teilintervall, für das der jeweilige erste Knoten (K1, ..., K8) zuständig ist, vorgesehen sind. Ein Empfangsknoten (SK), der zum Herunterladen zumindest eines Teils einer jeweiligen Mediendatei (VF) vorgesehen ist, ruft mittels einer oder mehrerer Anfragen an die ...

Description

Die Erfindung betrifft ein Verfahren und ein System zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten in einem Datennetz, wobei die Medieninhalte eine oder mehrere Mediendateien umfassen und die Knoten über Adressen in dem Datennetz adressierbar sind.
Aus dem Stand der Technik sind verschiedene Verfahren bekannt, wie in einem Datennetz aus einer Mehrzahl von Knoten Medieninhalte anderen Knoten bereitgestellt werden können. Bekannte Lösungen ermöglichen dabei auch das Streamen von Mediendateien, d. h. das parallele Abspielen der Mediendatei während des Herunterladens.
Zum Bereitstellen von Mediendateien gibt es sog. Client-Server-Lösungen, bei denen eine Mediendatei zentral von einem Server bereitgestellt wird und anschließend von verschiedenen Client-Knoten herunter geladen werden kann. Diese Lösung hat den Nachteil, dass die gesamte Datenmenge der Datei für jeden Client-Knoten über das Datennetz angefordert und herunter geladen wird, so dass es hierdurch zu einer hohen Netzbelastung kommt.
Um einen Medienstrom in dem Datennetz zu verteilen und hierdurch das Herunterladen des gesamten Stroms für jeden anfragenden Knoten zu vermeiden, ist es aus dem Stand der Technik für paketbasierte Netze bekannt, ein sog. IP-Multicast zu verwenden, bei dem in dem Netz spezielle Streaming-Router zur Weiterleitung von Datenströmen eingesetzt werden. Diese Lösung hat den Nachteil, dass in einem bestehenden paketbasierten Netz, beispielsweise im Internet, Veränderungen durch die Implementierung von Streaming-Routern vorgenommen werden müssen.
Aus dem Stand der Technik sind zum Herunterladen von Medieninhalten ferner sog. Content-Distribution-Netzwerke bekannt, welche spezielle Proxy-Rechner verwenden, welche Medienströme aus dem Netz von einem Medienserver anfordern und sie an entsprechende Client-Knoten weiterleiten. Auch bei dieser Lösung muss die Netz-Infrastruktur durch die Implementierung geeigneter Proxys angepasst werden.
Ein weiterer Ansatz zur Verteilung von Mediendateien in einem Datennetz ist in der Druckschrift W.-P. K. Yiu, X. Jin und S.-H. G. Chan, „Distributed Storage to Support User Interactivity in Peer-to-Peer Video Streaming", IEEE ICC '06, 2006, beschrieben. Gemäß dem dort vorgestellten Verfahren wird ein VoD-Streaming (VoD = Video an Demand) in einem verteilten Peer-to-Peer-Netz ermöglicht, wobei alle bereitzustellenden Videos in Abschnitte aufgeteilt werden und die Abschnitte dezentral über die Knoten des Peer-to-Peer-Netzes bereitgestellt werden. Da über das dezentrale Netz eine Vielzahl von Videos verwaltet wird, ist die Suche nach einer entsprechend zu streamenden Videodatei aufwändig und führt zu Verzögerungen beim Abspielen des Videos.
Aufgabe der Erfindung ist es, ein Verfahren und ein System zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten in einem Datennetz zu schaffen, wel che ohne Veränderung der Struktur des Datennetzes eine schnelle und zuverlässige Bereitstellung der Medieninhalte ermöglichen.
Diese Aufgabe wird durch das Verfahren gemäß Patentanspruch 1 bzw. das System gemäß Patentanspruch 28 gelöst. Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen definiert.
In dem erfindungsgemäßen Verfahren wird für jede, im Datennetz bereitzustellende Mediendatei separat eine dezentrale, über einen oder mehrere erste Knoten verwaltete Struktur dadurch gebildet, dass die jeweilige Mediendatei in eine Mehrzahl von Abschnitten aufgeteilt wird und den Abschnitten jeweils ein Identitätswert aus einem Identitätsintervall umfassend aufeinander folgende Identitätswerte zugeordnet wird, wobei der oder die ersten Knoten jeweils für ein Teilintervall aus dem Identitätsintervall und hierdurch für eine Teilmenge an Abschnitten aus der jeweiligen Mediendatei zuständig sind.
Zur Bereitstellung der Abschnitte über die dezentrale Struktur wird in dem erfindungsgemäßen Verfahren in einem jeweiligen ersten Knoten der dezentralen Struktur eine Anzahl von zweiten Knoten mit deren Adressen hinterlegt, wobei der oder die zweiten Knoten zum Bereitstellen der Abschnitte gemäß dem Teilintervall, für das der jeweilige erste Knoten zuständig ist, vorgesehen sind. Zweite Knoten sind dabei insbesondere solche Knoten, bei denen in Abhängigkeit von bestimmten Kriterien davon ausgegangen werden kann, dass diese zweiten Knoten in ihrem Speicher tatsächlich die entsprechenden Abschnitte der Mediendatei enthalten. Nichtsdestotrotz muss die Verfügbarkeit der Abschnitte in den zweiten Knoten nicht garantiert sein.
Das Herunterladen zumindest eines Teils einer jeweiligen Mediendatei über einen entsprechenden Empfangsknoten läuft erfindungsgemäß mittels entsprechender Anfragen an die dezentrale Struktur ab. Dabei ruft der entsprechende Empfangsknoten mittels einer oder mehrerer Anfragen an die ersten Knoten in der dezentralen Struktur der jeweiligen Mediendatei die Adressen von zweiten Knoten umfassend zumin dest einen Teil derjenigen zweiten Knoten ab, welche zum Bereitstellen der Abschnitte des zumindest einen Teils der Mediendatei vorgesehen sind. Anschließend werden Abschnitte umfassend die Abschnitte des zumindest einen Teils der Mediendatei von zumindest einem Teil der zweiten Knoten, deren Adressen abgerufen wurden, durch den Empfangsknoten herunter geladen.
Hier und im Folgenden bedeutet „Herunterladen eines Abschnitts” nicht zwangsläufig, dass die Gesamtmenge an Informationen eines Abschnitts herunter geladen werden muss. Vielmehr kann gegebenenfalls auch nur ein bestimmter Anteil des Abschnitts herunter geladen werden, beispielsweise derart, dass der Inhalt des Abschnitts in verringerter Qualität bereitgestellt wird.
Das erfindungsgemäße Verfahren zeichnet sich dadurch aus, dass für jede einzelne Mediendatei eine separate dezentrale Struktur gebildet wird, welche die Verwaltung der Abschnitte der Mediendatei übernimmt. Es wird somit für jede Mediendatei ein überschaubares dezentrales Netz gebildet, welches ein schnelles und effizientes Herunterladen der Mediendatei durch einen entsprechenden Empfangsknoten ermöglicht.
Ein bevorzugter Anwendungsfall des erfindungsgemäßen Verfahrens ist dessen Verwendung in einem paketbasierten Datennetz, insbesondere dem Internet. Die Adressen der Knoten sind dabei insbesondere IP-Adresse. Das Verfahren wird vorzugsweise in der Anwendungsschicht des OSI-Referenzmodells als ALM-Protokoll (ALM = Application Layer Multicast) implementiert.
In einer bevorzugten Ausführungsform enthält eine jeweilige Mediendatei einen abspielbaren Medienstrom, insbesondere einen Audio- und/oder Videostrom. Die Abschnitte der Mediendatei stellen dabei zeitlich aufeinander folgende Abschnitte des Medienstroms dar, wobei die Identitätswerte des Identitätsintervalls in Abspielreihenfolge des Medienstroms den Abschnitten zugeordnet werden. Das heißt, je größer der entsprechende Identitätswert ist, desto später ist auch der Abspielzeitpunkt des Abschnitts im Medienstrom. Vorzugsweise wird das erfindungsgemäße Verfahren dabei zum sog. Streamen des Medienstroms eingesetzt, bei dem ein Empfangsknoten parallel zum Herunterladen die herunter geladenen Abschnitte des Medienstroms abspielt.
Die erfindungsgemäß bereitgestellte dezentrale Struktur zum Verwalten von Abschnitten einer einzelnen Mediendatei kann dabei insbesondere mit bekannten Peer-to-Peer-Protokollen bzw. als Ringstruktur in dem Datennetz implementiert werden. Vorzugsweise wird dabei als Ringstruktur der hinlänglich aus dem Stand der Technik bekannte Chord-Ring verwendet. Die Mechanismen eines Chord-Rings zum Bereitstellen und zur Suche nach Ressourcen können dann in dem erfindungsgemäßen Verfahren genutzt werden.
In einer besonders bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens stellt ein Empfangsknoten, der Abschnitte einer Mediendatei herunter lädt, diese auch anderen Knoten zur Verfügung. Dies erfolgt dadurch, dass der Empfangsknoten mit seiner Adresse als zweiter Knoten in den entsprechenden ersten Knoten, welche für die vom Empfangsknoten herunter geladenen Abschnitte zuständig sind, hinterlegt wird.
In einer weiteren Ausführungsform der Erfindung wird ein Mechanismus zum Schutz vor dem Ausfall von ersten Knoten bereitgestellt, wodurch ein zuverlässiges Herunterladen von Mediendateien auch bei Ausfall eines ersten Knotens sichergestellt wird. Hierzu wird die Anzahl von in einem jeweiligen ersten Knoten hinterlegten zweiten Knoten in anderen ersten Knoten repliziert, insbesondere zumindest in einem Nachbarknoten, welcher für ein Teilintervall zuständig ist, das sich an das Teilintervall anschließt, für das der jeweilige erste Knoten zuständig ist.
In einer weiteren, bevorzugten Variante der Erfindung wird die Anzahl von in einem jeweiligen ersten Knoten hinterlegten zweiten Knoten in der Form von einer oder mehreren Listen hinterlegt. Vorzugsweise umfassen das oder die Listen in einem jeweiligen ersten Knoten eine oder mehrere erste und/oder zweite Listen. Sowohl die ersten als auch die zweiten Listen können dazu verwendet werden, um von diesen Listen entsprechende Abschnitte bei zweiten Knoten herunter zu laden. Eine erste Liste enthält dabei zweite Knoten mit permanent zum Herunterladen durch andere Knoten verfügbaren Abschnitten, wobei die Verfügbarkeit des jeweiligen zweiten Knotens durch regelmäßigen Nachrichtenaustausch des zweiten Knotens mit dem jeweiligen ersten Knoten überprüft wird. Hierdurch wird die dauerhafte Verfügbarkeit von Abschnitten einer Mediendatei in dem Datennetz gewährleistet. Im Gegensatz zu der ersten Liste umfasst eine zweite Liste diejenigen Knoten, welche bei dem jeweiligen ersten Knoten innerhalb eines vorbestimmten zurückliegenden Zeitraums Adressen von zweiten Knoten abgerufen haben. Eine zweite Liste enthält somit Knoten, von denen mit einer gewissen Wahrscheinlichkeit davon ausgegangen werden kann, dass sie auch entsprechend angefragte Abschnitte einer Mediendatei enthalten, da die Knoten in der zweiten Liste auch selbst diese Abschnitte angefragt haben.
Zur Verbreitung der permanent verfügbaren Abschnitte lädt ein Empfangsknoten in einer bevorzugten Variante der Erfindung Abschnitte von zweiten Knoten aus der ersten und/oder zweiten Liste herunter, wobei die herunter zu ladenden Abschnitte nach einem oder mehreren vorbestimmten Kriterien, insbesondere zufällig, ausgewählt werden. Das heißt, ein Empfangsknoten sucht mittels einer Anfrage nach einem entsprechenden ersten Knoten, der einen zufällig ausgewählten Abschnitt verwaltet und fragt von diesem ersten Knoten die erste oder zweite Liste ab. Er lädt dann den entsprechenden Abschnitt von einem zweiten Knoten aus der ersten oder zweiten Liste herunter. Der herunter zu ladenden Abschnitt muss dabei kein Abschnitt sein, den der Empfangsknoten für das Abspielen der von ihm gerade herunter geladenen Mediendatei benötigt wird. Somit läuft im Hintergrund neben einem Laden von Abschnitten aus einer Mediendatei auch eine Verteilung von weiteren Abschnitten in dem Datennetz ab, wodurch an mehreren Stellen im Netz permanent verfügbare Abschnitte bereitgestellt werden, so dass ein zuverlässiger Download von verschiedenen Download-Quellen im Netz ermöglicht wird.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens, bei dem die herunter geladene Mediendatei gestreamt wird, werden zweite Knoten aus der ersten Liste umso stärker zum Herunterladen eines abzuspielenden Abschnitts bevorzugt, je näher der abzuspielende Abschnitt am aktuellen Abspielzeitpunkt der Mediendatei liegt. Auf diese Weise wird sichergestellt, dass demnächst abzuspielende Abschnitte einer Mediendatei von zuverlässigen Quellen, welche die entsprechenden Abschnitte permanent zur Verfügung stellen, herunter geladen werden. Hierdurch werden Verzögerungen beim Abspielen der Mediendatei vermieden.
In einer besonders bevorzugten Ausführungsform der Erfindung kann sich ein Empfangsknoten nicht nur an der Verteilung von Abschnitten einer Mediendatei, sondern auch an der Verwaltung der Ringstruktur beteiligen. Dabei wird ein Empfangsknoten in Abhängigkeit von einem oder mehreren Kriterien als erster Knoten in die dezentrale Struktur einer jeweiligen Mediendatei dadurch aufgenommen, dass dem Empfangsknoten die Zuständigkeit für ein Teilintervall aus dem Identitätsintervall zugewiesen wird. Insbesondere können aus dem Stand der Technik bekannte Mechanismen zur Aufnahme von Knoten in dezentrale Strukturen verwendet werden. Solche Mechanismen sind beispielsweise für Chord-Ringe bekannt.
Vorzugsweise sind das oder die Kriterien zur Aufnahme eines Empfangsknotens in die dezentrale Struktur derart ausgestaltet, dass für einen Empfangsknoten eine Maximalanzahl von Malen nach einem Teilintervall des Identitätsintervalls gesucht wird, dessen Zuständigkeit ein neuer Knoten in der dezentralen Struktur übernehmen kann, wobei im Falle, dass kein Teilintervall nach der Maximalanzahl von Malen gefunden wird, der Empfangsknoten nicht als erster Knoten in die dezentrale Struktur aufgenommen wird. Ebenso besteht die Möglichkeit, dass nur solche Empfangsknoten in die dezentrale Struktur aufgenommen werden, welche eine vorbestimmte Mindestgröße an Ressourcen bereitstellen können. Unter Ressourcen sind dabei insbesondere entsprechend verfügbare Uploadraten bzw. Speicherkapazitäten bzw. Rechenkapazitäten des Knotens zu verstehen. Hierdurch wird sichergestellt, dass nur Knoten mit ausreichender Kapazität an der Verwaltung der dezentralen Struktur teil nehmen. Somit wird eine Überlastung von Knoten vermieden und die Ausfallsicherheit des Verfahrens verbessert.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens wird dem in die dezentrale Struktur aufzunehmenden Empfangsknoten zufällig oder nach einem vorbestimmten Muster eine Zuständigkeit für ein Teilintervall zugewiesen, wobei das vorbestimmte Muster insbesondere derart ausgestaltet ist, dass für Abschnitte mit kleineren Identitätswerten mehr Knoten zuständig sind als für Abschnitte mit größeren Identitätswerten. Für Mediendateien in der Form von abzuspielenden Medienströmen wird hierdurch die Erkenntnis berücksichtigt, dass ein Nutzer in der Regel bereits am Anfang des Abspielens eines Medienstroms entscheidet, ob er den Medienstrom weiter anschauen möchte oder nicht. Somit unterliegen Knoten, welche Abschnitte mit kleinen Identitätswerten verwalten, einer höheren Belastung als Knoten mit größeren Identitätswerten, so dass eine dichtere Knoten-Besetzung für Abschnitte mit kleinen Identitätswerten sinnvoll ist.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens kennt in der dezentralen Struktur ein jeweiliger erster Knoten den Nachbarknoten, welcher für ein Teilintervall zuständig ist, das sich an das Teilintervall, für das der jeweilige erste Knoten zuständig ist, in Richtung hin zu höheren Identitätswerten anschließt, wobei die Adresse des Nachbarknotens durch den jeweiligen ersten Knoten bei einem Abruf der Adressen der zweiten Knoten an den Empfangsknoten übermittelt wird. Bei einem abzuspielenden Medienstrom wird dabei die Anzahl der Anfragen reduziert, da ein Empfangsknoten bereits die Information über die Adresse des entsprechenden Nachbarknotens erhält, der zweite Knoten verwaltet, von denen nachfolgend abzuspielende Abschnitte herunter geladen werden können. Insbesondere verfügt der jeweilige erste Knoten dabei über weitere Informationen über den Nachbarknoten, welche neben der Adresse des Nachbarknotens an den Empfangsknoten übermittelt werden und aus denen der Empfangsknoten das Teilintervall ermittelt, für das der Nachbarknoten zuständig ist. Hierdurch kann der Empfangsknoten auf einmal die Adressen der zweiten Knoten für alle Abschnitte abfragen, für welche der Nachbarknoten zuständig ist.
In einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens werden Abschnitte durch einen Empfangsknoten in Abhängigkeit von einem oder mehreren, für die Abschnitte vergebenen Prioritäten herunter geladen, wobei Abschnitte mit höheren Prioritäten beim Herunterladen bevorzugt werden. Beim Herunterladen eines abzuspielenden Medienstroms ist für einen Empfangsknoten vorzugsweise ein erstes Zeitintervall vorgegeben, wobei der Empfangsknoten ausgehend von seinem aktuellen Abspielzeitpunkt des Medienstroms Abschnitte, welche im abgespielten Medienstrom in dem ersten Zeitintervall nach dem Abspielzeitpunkt liegen, mit höherer Priorität als andere Abschnitte herunter lädt. Auf diese Weise erfolgt ein priorisierter Download dahingehend, dass demnächst abzuspielende Abschnitte beim Herunterladen bevorzugt werden. Hierdurch wird ein kontinuierliches Abspielen des Medienstroms sichergestellt. Insbesondere werden dabei Abschnitte innerhalb des ersten Zeitintervalls, welche den aktuellen Abspielzeitpunkt enthalten, mit höherer Priorität als die anderen Abschnitte im ersten Zeitintervall herunter geladen.
In einer weiteren Variante des erfindungsgemäßen Verfahrens ist für einen Empfangsknoten neben dem ersten Zeitintervall auch ein zweites Zeitintervall vorgegeben, welches größer als das erste Zeitintervall ist, wobei der Empfangsknoten ausgehend von seinem aktuellen Abspielzeitpunkt des Medienstroms Abschnitte, welche im abgespielten Medienstrom in dem zweiten Zeitintervall nach dem Abspielzeitpunkt und außerhalb des ersten zeitlichen Intervalls liegen, mit niedrigerer Priorität als die Abschnitte innerhalb des ersten Zeitintervalls herunter lädt.
Vorzugsweise lädt ein Empfangsknoten Abschnitte zur Bereitstellung als permanent verfügbare Abschnitte mit niedrigerer Priorität als die Abschnitte aus dem ersten oder zweiten Zeitintervall nach dem aktuellen Abspielzeitpunkt herunter. Hierdurch wird berücksichtigt, dass das Herunterladen von Abschnitten zur permanenten Be reitstellung vollkommen zeitunkritisch ist, da diese Abschnitte nicht zum Abspielen der aktuell herunter geladenen Mediendatei benötigt werden.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens werden die Abschnitte einer Mediendatei jeweils in kleinere Teilabschnitte aufgeteilt. Dabei kann beim Herunterladen eines Abschnitts der gesamte Abschnitt, jedoch auch nur eine Auswahl von Teilabschnitten aus dem Abschnitt herunter geladen werden. Vorzugsweise sind die Teilabschnitte aller Abschnitte einer jeweiligen Mediendatei in mehrere Kanäle gruppiert, welche verschiedene Qualitätsstufen der Mediendatei repräsentieren. Auf diese Weise wird durch gezieltes Herunterladen von Teilabschnitten eines Kanals eine qualitätsangepasste Wiedergabe der Mediendatei, insbesondere ein qualitätsangepasstes Abspielen eines Medienstroms, ermöglicht.
Vorzugsweise liest ein Empfangsknoten zur Verarbeitung der Teilabschnitte Informationen über die Teilabschnitte, insbesondere hinsichtlich der Zuordnung der Teilabschnitte zu Qualitätsstufen, aus einer Informationsdatei aus. Auf diese Weise kann sich ein Empfangsknoten die Informationen holen, welche Qualität bzw. Sprache und dergleichen er abspielen kann und welche Teilabschnitte er hierzu auswählen muss.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens werden Informationen zu einer jeweiligen Mediendatei in einem Meta-Container bereitgestellt, welcher von einem Empfangsknoten herunter geladen werden kann. Hierdurch können dem Nutzer des Empfangsknotens entsprechende Informationen über die bereitgestellten Mediendateien bereitgestellt werden, wobei der Nutzer anhand dieser Informationen entscheiden kann, ob das Herunterladen der Mediendatei für ihn interessant ist, welche Qualität und eventuell welche Sprache er auswählen möchte.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens werden eine Mehrzahl von Mediendateien über einen suchbaren Index im Datennetz bereitgestellt, wobei für jeden Index zumindest ein Teil der Adressen der ersten Knoten der für die jeweilige Mediendatei gebildeten dezentralen Struktur hinterlegt ist. Somit erhält ein Empfangsknoten, der eine über den Index ermittelte Mediendatei gefunden hat, sogleich eine Information über Zugangspunkte in die Ringstruktur, so dass der Empfangsknoten unmittelbar durch Adressierung eines der Zugangspunkte den Prozess des Herunterladens der Mediendatei beginnen kann.
Neben dem oben beschriebenen Verfahren betrifft die Erfindung ferner ein System zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten in einem Datennetz, wobei die Medieninhalte eine oder mehrere Mediendateien umfassen und die Knoten über Adressen in dem Datennetz adressierbar sind. Das System verwaltet die Mehrzahl von Knoten dabei derart, dass jede Variante des oben beschriebenen Verfahrens mit dem System durchführbar ist. Das System wird dabei vorzugsweise durch entsprechende Software auf den einzelnen Knoten implementiert, wobei die Software ein Bereitstellen bzw. Herunterladen von Mediendateien gemäß dem erfindungsgemäßen Verfahren ermöglicht.
Darüber hinaus betrifft die Erfindung einen Knoten zur Verwendung in dem erfindungsgemäßen Verfahren, wobei der Knoten derart ausgestaltet ist, dass er bei Betrieb in dem Verfahren als erster Knoten oder als zweiter Knoten oder als Empfangsknoten fungiert.
Ausführungsbeispiele der Erfindung werden nachfolgend anhand der beigefügten Figuren detailliert beschrieben.
Es zeigen:
1 eine schematische Darstellung der Bereitstellung einer Videodatei über eine Ringstruktur gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens;
2 eine Detaildarstellung der in 1 gezeigten Ringstruktur, wobei die in der Ringstruktur verwalteten Listen verdeutlicht sind;
3 eine schematische Darstellung einer Aufteilung der Abschnitte einer Videodatei in kleinere Teilabschnitte gemäß einer Ausführungsform der Erfindung;
4 ein Ablaufdiagramm, welches die Suche eines Knotens nach Abschnitten einer Videodatei in einer Ringstruktur gemäß 1 bzw. 2 verdeutlicht; und
5 eine schematische Darstellung des Streamens einer Videodatei in einem entsprechenden, die Videodatei empfangenden Knoten gemäß einer Ausführungsform der Erfindung.
Durch die nachfolgend beschriebenen Ausführungsformen des erfindungsgemäßen Verfahrens werden Mediendateien in entsprechenden Knoten eines Datennetzes zur Verfügung gestellt. Das Datennetz stellt dabei ein paketbasiertes Datennetz dar, welches auf der Schicht 3 des OSI-Referenzmodells das IP-Protokoll verwendet. Bei den Knoten des Datennetzes handelt es sich um entsprechende Rechner im Internet, welche über IP-Adressen angesprochen werden können. Die nachfolgend beschriebene Peer-to-Peer-Struktur wird dabei auf der Anwendungsschicht des OSI-Referenzmodells in der Form eines ALM-Protokolls (ALM = Application Layer Multicast) umgesetzt. Die nachfolgenden Prinzipien sind jedoch nicht auf bestimmte Arten von Datennetzen bzw. Protokollen beschränkt, sondern können auch in anderen Netzen und über andere Protokolle implementiert werden.
Basierend auf dem nachfolgend erläuterten Verfahren werden Medieninhalte in der Form von Mediendateien und insbesondere in der Form von Videodateien zum Herunterladen durch Knoten bereitgestellt. Die Medieninhalte sind dabei nicht auf Videos beschränkt, sondern können beliebige andere Inhalte umfassen, wie z. B. nur reine Audiodateien. Die Bereitstellung der Mediendatei erfolgt in der nachfolgend beschriebenen Ausführungsform durch einen entsprechenden Videoanbieter, der über das Internet kostenlos bzw. gegen Bezahlung Videos zum Streamen für andere Kno ten des Netzes bereitstellt. Damit ein Knoten nach Videos suchen kann bzw. diese herunter laden kann, muss eine entsprechende Client-Software auf dem Knoten installiert sein. Die Software wird vorzugsweise von dem Videoanbieter bereitgestellt und ist derart ausgestaltet, dass mit allen Knoten, welche diese Software verwenden, die erfindungsgemäße Verteilung und das erfindungsgemäße Herunterladen von Videos ermöglicht werden.
Neben dem soeben beschriebenen Szenario des Anbieten von Videoinhalten durch einen kommerziellen Anbieter kann das erfindungsgemäße Verfahren auch von beliebigen anderen Personen bzw. Institutionen zum Bereitstellen von Medieninhalten genutzt werden. Beispielsweise können Firmen ihr selbstproduziertes Material bezüglich ihrer Produkte basierend auf dem erfindungsgemäßen Verfahren bereitstellen und ebenso können Privatpersonen eigenes Videomaterial mit anderen Benutzern austauschen.
In dem in 1 gezeigten Szenario stellt ein kommerzieller Videoanbieter über einen Server SE Videodateien zum Herunterladen durch Nutzer bereit. Die Nutzer sind dabei repräsentiert durch entsprechende Knoten, welche Rechner darstellen, die von einem Nutzer bedient werden und über eine Internetverbindung verfügen, so dass sie über eine entsprechende IP-Adresse angesprochen werden können. Auf den Knoten, über welche die Dienste des Videoanbieters genutzt werden, ist jeweils eine entsprechende Client-Software installiert. Damit das bereitgestellte Videomaterial auch durch andere Knoten gefunden werden kann, werden durch den Videoanbieter die entsprechenden Videodateien im Rahmen eines Index-Prozesses indiziert. In der Ausführungsform der 1 läuft dieser Index-Prozess als zentraler Prozess auf dem Server SE ab. Es besteht jedoch auch die Möglichkeit, dass dieser Prozess als verteilter Prozess zum Einsatz kommt, so dass an diesem Prozess diverse leistungsfähige Rechnerknoten beteiligt sind.
Wie in 1 angedeutet ist, wird durch den Index-Prozess eine entsprechende Tabelle T generiert, in der jedem bereitgestellten Video eine Index-Nummer zugeordnet ist, wobei in 1 beispielhaft die Index-Nummern 1, 2 und 34 angedeutet sind. Jedem Index ist dabei ein über eine Hash-Funktion erzeugter Datei-Hash zugeordnet, anhand dem die einzelnen Videodateien unterschieden werden können und nach dem zum Auffinden von Videodateien gesucht werden kann. In der dargestellten Tabelle T ist ferner für jeden Index angegeben, welche aktiven Knoten zu einer Ringstruktur gehören, welche der Datei zugeordnet ist. Die Ringstruktur wird im Folgenden noch näher erläutert und ist in 1 durch das Bezugszeichen R angedeutet. Basierend auf dem bereitgestellten Index kann somit ein Knoten nach entsprechenden Videodateien suchen, wobei dem Knoten für eine aufgefundene Videodatei auch entsprechende aktive Knoten angegeben werden, welche dem suchenden Knoten als Einstiegspunkte zum Herunterladen des Videos dienen.
Ein wesentlicher Aspekt des nachfolgend erläuterten Verfahrens zur Bereitstellung von Videoinhalten besteht darin, dass für jede Videodatei eine dezentral verwaltete Ringstruktur R gebildet ist, wobei die Zuweisung einer Videodatei zu einer Ringstruktur schematisch durch den Pfeil P angedeutet ist. Zur Generierung dieser Ringstruktur R wird das entsprechende bereitzustellende Video in eine Vielzahl von Abschnitten eingeteilt, welche im Folgenden auch als Chunks bezeichnet sind. Jeder Chunk enthält dabei einen zeitlichen Abschnitt der abgespielten Videodatei. In dem Szenario der 1 wird die Videodatei in 32 Chunks eingeteilt, welche durch entsprechend nummerierte Quadrate 0, 1, ..., 31 angedeutet sind und zumindest teilweise mit dem Bezugszeichen C bezeichnet sind. Jedem Abschnitt wird somit ein Identitätswert aus einem 5-Bit-Intervall von Identitätswerten zugewiesen, wobei eine höhere Nummer eines Identitätswerts einen späteren zeitlichen Abschnitt des Videos repräsentiert. Hierdurch wird die in 1 gezeigte Ringstruktur geschaffen, bei der jedem Chunk eine Position auf einem 5-Bit-Ring mit 32 Positionen zugeordnet ist.
Die Chunks C werden dabei durch entsprechende Knoten verwaltet, welche gemäß Anspruch 1 als erste Knoten bezeichnet werden. Diese Knoten sind solche Knoten, welche auch entsprechende Videoinhalte von anderen Knoten herunter laden können. Somit beteiligen sich die den Dienst des Videoanbieters nutzenden Knoten auch an der Verwaltung entsprechender Videos. In dem Szenario der 1 ist dabei nicht jede Position des Rings mit einem Knoten besetzt. Vielmehr existieren insgesamt acht Knoten K1 bis K8. Der Knoten K1 besetzt dabei die Position 0 des Rings, der Knoten K2 die Position 4, der Knoten K3 die Position 6, der Knoten K4 die Position 13, der Knoten K5 die Position 19, der Knoten K6 die Position 24, der Knoten K7 die Position 27 und der Knoten K8 die Position 31. Jeder der Knoten verwaltet dabei die Chunks an der Position, an der er sitzt, sowie an allen vorhergehenden Positionen bis zum vorhergehenden Knoten. Das heißt, der Knoten K1 verwaltet den Chunk 0, der Knoten K2 die Chunks 1 bis 4, Der Knoten K3 die Chunks 5 und 6, der Knoten K4 die Chunks 7 bis 13, der Knoten K5 die Chunks 14 bis 19, der Knoten K6 die Chunks 20 bis 24, der Knoten K7 die Chunks 25 bis 27 und der Knoten K8 die Chunks 28 bis 31.
Die Verwaltung durch die Ringstruktur R mit Hilfe der Knoten K1 bis K8 erfolgt vorzugsweise basierend auf bekannten Peer-to-Peer-Protokollen. Besonders bevorzugt wird hierbei der aus dem Stand der Technik bekannte Chord-Ring verwendet, der entsprechende Mechanismen zur Verwaltung und Suche nach Ressourcen in dem am Ring beteiligten Knoten bereitstellt. Es können jedoch auch beliebige andere Peer-to-Peer-Protokolle verwendet werden, mit denen innerhalb eines Verteilnetzes nach Knoten mit Zuständigkeiten für Intervalle an Identitätswerten gesucht werden kann und welche ferner einen Mechanismus bereitstellen, mit dem neue Knoten in das Verteilernetz aufgenommen werden können bzw. auch Knoten das Verteilernetz wieder verlassen können.
Jedem der einzelnen Knoten K1 bis K8 in der Ringstruktur R ist eine Anzahl von weiteren Knoten des Datennetzes zugeordnet, welche die entsprechenden Chunks enthalten, für welche die jeweiligen Knoten K1 bis K8 des Rings R zuständig sind. Diese, die Chunks enthaltenden Knoten entsprechen dabei den zweiten Knoten im Sinne von Anspruch 1 und werden in entsprechenden Listen verwaltet, wie in 2 verdeutlicht ist. Es existiert dabei für jeden Identitätswert eines Chunks in der Ringstruktur R sowohl eine permanente Replikationsliste, welche als PeRL bezeichnet wird, sowie eine momentane Replikationsliste, welche als PaRL bezeichnet wird. In 2 sind beispielhaft zwischen den Knoten K1 und K3 einige Positionen von Identitätswerten von Chunks durch vertikale Linien angedeutet, von denen aus Übersichtlichkeitsgründen lediglich eine Linie mit dem Bezugszeichen L bezeichnet ist. Der Knoten K2 verwaltet dabei die Identitätswerte der Chunks 1 bis 4, so dass in diesem Knoten für jeden der Chunks sowohl eine PeRL als auch eine PaRL hinterlegt ist.
In der PeRL-Liste werden für einen jeweiligen Chunk alle Knoten mit deren Knotenzugangspunkten (d. h. Adresse und Port) gesammelt, die den Chunk permanent bereitstellen. Wie weiter unten noch näher erläutert wird, ist mit entsprechenden Mechanismen dafür gesorgt, dass es ausreichend viele Knoten gibt, welche Chunks dauerhaft zum Download bereitstellen. Zu solchen Knoten zählen unter anderem auch diejenigen Knoten, die eine komplette Kopie des Videos besitzen. Dauerhaft bedeutet in diesem Zusammenhang, solange der entsprechende Knoten am Netz zur Verteilung der Videos beteiligt ist. In 2 ist schematisch der Aufbau einer PeRL-Liste wiedergegeben. Die PeRL-Liste enthält für jeden Knoten, der dauerhaft den entsprechenden Chunk bereitstellt, einen Eintrag. Beispielhaft ist ein Eintrag für einen Knoten K' hervorgehoben. In jedem Eintrag wird der Zeitpunkt t spezifiziert, zu dem der entsprechende Eintrag zum letzten Mal aktualisiert wurde. Ebenso ist die entsprechende IP-Adresse des Knotens angegeben. In der PeRL-Liste sind insbesondere auch Knoten enthalten, welche eine komplette Kopie des Videos bereitstellen. Diese Knoten sind speziell markiert. Zur ständigen Aktualisierung der Einträge aus der PeRL-Liste werden dabei sog. Keep-Alive-Nachrichten, welche hinlänglich aus Peer-to-Peer-Protokollen bekannt sind, zwischen den einzelnen Knoten ausgetauscht, wie weiter unten noch näher erläutert wird.
Neben der PeRL-Liste ist in 2 auch schematisch eine PaRL-Liste für einen Chunk wiedergegeben. In dem Beispiel der 2 enthält diese Liste nur einen Eintrag für einen Knoten K''. In dieser Liste werden Knoten eingetragen, welche den entsprechenden Chunk, zu dem die PaRL-Liste gehört, innerhalb eines vorgegebenen zurückliegenden Zeitraums angefragt haben. Jeder Eintrag in der PaRL-Liste gibt dabei neben der IP-Adresse des entsprechenden Knotens auch den Zeitpunkt t wieder, zu dem der Chunk angefragt wurde. Diese PaRL-Liste wird nicht mit Keep-Alive-Nachrichten aktualisiert. Vielmehr werden in der Liste alle Knoten eingetragen, die den Chunk angefragt haben und die nach Eintritt einer gewissen Bedingung, spätestens nach Ablauf einer vorbestimmten Zeitperiode, wieder herausgelöscht werden. Auf diese Weise wird es ermöglicht, zeitlich starke Schwankungen bei der Nachfrage nach einem Chunk auszugleichen, denn es kann davon ausgegangen werden, dass ein Knoten, welcher einen entsprechenden Chunk angefragt hat, diesen auch herunter geladen hat und somit bereitstellen kann. Somit können neben den Knoten aus der PeRL-Liste auch Knoten aus der PaRL-Liste zum Herunterladen von Chunks genutzt werden.
Der Ring R gemäß 1 bzw. 2 wird von entsprechenden Streaming-Knoten SK (4), welche den Empfangsknoten im Sinne von Anspruch 1 entsprechen, dazu genutzt, um aufeinander folgend entsprechende Chunks herunter zu laden, wobei die Informationen über die Knoten, welche die Chunks bereitstellen, aus dem Ring über die darin enthaltenen Knoten K1 bis K8 abgerufen werden. Das Streamen des durch den Ring R bereitgestellten Videos durch einen Streaming-Knoten wird in 2 durch ein entsprechendes Streaming-Fenster W angedeutet. Dieses Fenster stellt eine minimale Puffergröße bei Streaming-Knoten dar, der zum Abspielen des Videos mit Chunks gefüllt wird und der beim Abspielen des Videos möglichst gefüllt bleiben sollte. In dem Szenario der 2 umfasst das Streaming-Fenster W sechs Chunks und der Streaming-Knoten beginnt gerade mit dem Abspielen des Videos an der Position 0. Bei fortschreitender Abspielzeit bewegt sich das Streaming-Fenster mit dem sich im Uhrzeigersinn verschiebenden Abspielzeitpunkt fort. Durch entsprechende Mechanismen, welche weiter unten noch näher erläutert werden, wird sichergestellt, dass der Streaming-Knoten bevorzugt immer solche Chunks herunter lädt, welche innerhalb des Streaming-Fensters W liegen, um hierdurch ein verzögerungsfreies Abspielen des Videos zu gewährleisten.
Bevor der eigentliche Download eines Videos durch einen Streaming-Knoten gestartet wird, benötigt der Streaming-Knoten zunächst die entsprechenden Download-Quellen, welche in den zuvor erläuterten PeRL- bzw. PaRL-Listen enthalten sind. Deshalb werden durch den Streaming-Knoten Suchanfragen nach dem von ihm benötigten Chunk-Nummern in den Ring R gestellt, wobei hierzu bekannte Mechanismen des Chord-Protokolls genutzt werden können. Die Suchanfrage wird dabei an einen der Zugangspunkte des Netzes gerichtet, welche in der Tabelle T für das entsprechend herunter zu ladende Video hinterlegt sind. Es ist dabei egal, über welchen Zugangspunkt eine entsprechende Anfrage in den Ring gestellt wird, da anhand des Chord-Routings die Anfrage sicher direkt ihr Ziel erreicht. Jede Anfrage, die ihr Ziel erreicht hat, wird vom zuständigen Knoten im Ring mit der Übersendung der entsprechenden PeRL- und PaRL-Listen für den entsprechend angefragten Chunk beantwortet.
Anders als beim herkömmlichen File-Sharing werden verschiedene Teile des Videos nicht zufällig oder nach Verfügbarkeit herunter geladen, sondern abhängig vom aktuellen Abspielzeitpunkt. Dies wurde bereits im Vorangegangenen basierend auf dem verwendeten Streaming-Fenster W erläutert. Die Größe des Streaming-Fensters gibt dabei an, wie weit im Voraus das Video herunter geladen sein sollte, um ein bestimmtes Abspielen zu ermöglichen und eventuelle Download-Schwankungen auszugleichen. Das Streaming-Fenster sollte jedoch auch nicht zu groß sein, da dies immer mit einer Abspielverzögerung bis zur Füllung des Fensters verbunden ist. Die durch das Streaming-Fenster vorgegebene Pufferzeit ist dabei direkt mit einer entsprechenden bereitzustellenden Puffergröße im Streaming-Knoten verbunden. Insbesondere ist die bereitzustellende Puffergröße das Produkt aus durchschnittlicher Abspielrate und Pufferzeit. Aus der Puffergröße kann dann direkt bestimmt werden, wie viele Chunks im Voraus herunter geladen werden müssen, um diesen Puffer zu füllen. Die Anzahl der Chunks ist insbesondere der Quotient aus Puffergröße und Chunk-Größe.
Bevor im Detail der Vorgang des Bereitstellens und Herunterladens eines Videos basierend auf einem entsprechenden Ring beschrieben wird, werden zunächst die in der nachfolgend beschriebenen Ausführungsform verwendeten Strukturen der herunter zu ladenden Videodateien erläutert.
Die Unterteilung einer entsprechenden Videodatei in kleinere Chunks dient der leichteren Organisation der normalerweise sehr großen Streaming-Dateien. Die Verantwortung für einen Chunk wird an einem entsprechenden Identitätswerts im Ring R abgelegt, der dort von einem Knoten verwaltet wird. Die eigentliche Videoinformation wird an sehr vielen verschiedenen Knoten repliziert, wobei die Information, welche Knoten die jeweiligen Chunks enthalten, in den oben erläuterten PeRL- bzw. PaRL-Listen in dem für den jeweiligen Chunk zuständigen Knoten abgespeichert ist.
Bevor initial durch einen Knoten eine Videodatei in das Netz gestellt wird, müssen einige vorbereitende Schritte durch den initialen Quellknoten durchgeführt werden. Insbesondere muss die Videodatei zunächst auf ihre Streaming-Tauglichkeit überprüft werden. Ist die Datei streamingtauglich, wird die gesamte Datei mit einem effizienten und standardisierten Coder, z. B. basierend auf MPEG-4/AVC bzw. H-264 umcodiert. Schließlich wird das Video in die gewählte Dateistruktur umgeformt. Zum Auffinden des Videos wird anschließend ein eindeutiger Video-Hashwert gebildet und ferner werden charakterisierende Informationen des Videos in einem entsprechenden Container für Metainformationen gesammelt und gespeichert. Dieser Container wird weiter unten noch näher erläutert.
Nach Abschluss dieser vorbereitenden Schritte wird ein neuer Eintrag für das Video in der Index-Liste generiert, welche in 1 mit dem Bezugszeichen T bezeichnet ist. Dort werden die Angaben und der Metacontainer abgelegt und geprüft. Nach erfolgreicher Prüfung wird der Videostream öffentlich gemacht und die Liste T von Zugangspunkten zum Chord-Ring mit deren IP-Adressen angelegt. In dieser Liste wird zunächst nur der initiale Quellknoten eingetragen. In bestimmten Abständen wird die Liste immer wieder aktualisiert und um neue, zum Chord-Ring hinzukommenden Adressen ergänzt.
In der hier beschriebenen Ausführungsform des erfindungsgemäßen Verfahrens wird ein Videostrom nicht nur in kleinere Chunks eingeteilt, sondern die Chunks werden nochmals in kleinere Teilabschnitte aufgeteilt, welche im Folgenden als Atonks (Atonk = Atomic Chunk) bezeichnet werden. Ein Atonk bezeichnet dabei einen Teil des entsprechenden Chunks und wird mit einem Label markiert. Diese Aufteilung ist nochmals in 3 verdeutlicht. Im oberen Rechteck R1 ist dabei der Transcodiervorgang der ursprünglichen Videodatei zur Bildung von Chunks und Atonks dargestellt. Zunächst erfolgt die Separation des Videos VF in einzelne Chunks C, von denen in 3 die Chunks mit den Nummern 0 bis 6 angedeutet sind. Jeder einzelne Chunk C wird dann codiert, woraufhin in dem Chunk entsprechende kleinere Atonks AT mit zugewiesenen Labeln A, B, C, usw. generiert werden. Die Codierung ist in 3 dabei für den Chunk mit der Nummer 0 angedeutet.
Zur Bildung der Atonks wird eine vorgegebene Atonk-Map verwendet, welche in 3 mit AM bezeichnet ist. Die Labels der einzelnen Chunks setzen sich über die gesamte Videodatei fort, d. h. jeder Chunk enthält Atonks AT mit entsprechenden Labels A, B, C, usw. Durch entsprechende Wahl der Labels können Kanäle gebildet werden, wobei einem Kanal alle Atonks eines Labels zugewiesen sind. Je nach gewähltem Label werden dann beim Herunterladen eines Chunks nur die Atonks gemäß dem gewählten Label übertragen. In 3 ist eine Transmission in entsprechenden Videoströmen V1 bzw. V2 bzw. V3 für Atonks mit den Labeln A bzw. B bzw. C angedeutet.
Innerhalb des unteren Rechtecks R2 der 3 ist die Decodierung der entsprechend herunter geladenen Atonks mit einem Decoder des Streaming-Knotens wiedergegeben. Die einzelnen herunter geladenen Streams können dann basierend auf der gleichen Atonk-Map AM, die bereits beim Codieren verwendet wurde, den entsprechenden Labeln A, B, C, usw. zugeordnet werden. In dem in 3 dargestellten Ausfüh rungsbeispiel stellen die einzelnen Labels verschiedene Qualitätsstufen des Videos dar. Der Label A ist in die niedrigste Qualitätsstufe und durch sukzessives Hinzunehmen der Chunks mit dem Label B, C, usw. wird die Wiedergabequalität des Videos weiter erhöht. Durch Multiplexing der Chunks mit den unterschiedlichen Labeln kann somit ein qualitätsangepasstes Abspielen des Videos erreicht werden.
Es gibt verschiedene Möglichkeiten, wie unterschiedliche Kanäle durch Kennzeichnung der Atonks mit Labeln gebildet werden können. Im Folgenden werden einige Beispiele für eine entsprechende Kanalisierung des Videostroms mittels Atonks gegeben. Im einfachsten Fall werden die Video- und Audioinformationen der Videodatei zwar komprimiert, aber untereinander trennbar in die Atonks abgelegt. Die Ablage erfolgt sequentiell und ist damit sehr einfach wieder zu decodieren. Unterschiedliche Qualitätsstufen, wie sie im Vorangegangenen erwähnt wurden, sind dabei jedoch nicht möglich.
Eine weitere Variante ist eine Bild-Kanalisierung, bei der das Videomaterial in drei Kanäle unterteilt wird. Basiert das Material auf den MPEG-Standards, gibt es in einem codierten Video drei unterschiedlich wichtige Arten von Bilderframes. Die wichtigsten sind die sog. I-Frames, welche als Standbilder vorkommen. Sie verbrauchen den größten Speicherplatz und kommen in der Codierung deshalb nur in vorbestimmten Abständen vor. Zwischen einzelnen I-Frames liegen die wesentlich verlustreicher codierten P-Frames und B-Frames. Diese lassen sich beim Abspielen nur noch mit Hilfe vorangegangener I-Frames oder anderer P-Frames berechnen. Wenn man alle Frames einer Sorte innerhalb eines Chunks einem Atonk-Label zuordnet, so erhält man drei Videokanäle. Der I-Frame-Kanal ist beim Abspielen in jedem Fall erforderlich und liefert eine Art Basis-Qualität. Durch Hinzufügen des Kanals mit den P-Frames und des Kanals mit den B-Frames kann die Qualität des Videos entsprechend gesteigert werden.
Eine weitere Art der Kanalisierung basierend auf Atonks ist die sog. Beschreibungs-Kanalisierung. Diese Kanalisierung ermöglicht die Unterteilung des Videomaterials in beliebig viele Kanäle. Dabei kommt ein aus dem Stand der Technik bekanntes Verfahren zum Einsatz, welches als „Multiple Description Coding” bezeichnet wird. Dieses Verfahren erzeugt verschiedene Beschreibungen von ein und demselben Videomaterial. Ein Schicht-Codierer erstellt dabei eine Basis-Schicht und beliebig viele Erweiterungs-Schichten aus dem Original. Die Basis-Schicht wird – analog wie bei der Bild-Kanalisierung des I-Frame-Kanals – zum Abspielen immer benötigt. Über die Erweiterungs-Schichten können anschließend beliebig viele Qualitätsstufen eingeführt werden. Weist man jeder dieser Schichten bzw. Beschreibungen ein entsprechendes Atonk-Label zu, erhält man die Möglichkeit, beliebig viele Kanäle und damit Qualitätsstufen einzuführen, wie dies auch bereits in 3 angedeutet ist.
Des Weiteren kann eine sog. Auflösungs-Kanalisierung bei der Erzeugung der Atonks verwendet werden. Diese Kanalisierung erzeugt durch Unterteilung des Videomaterials eine sehr große Anzahl an Kanälen. Dabei wird durch wiederholte Unter-Abtastung eine reduzierte Auflösung des Videos erzeugt. Nach jeder Unter-Abtastung wird für jedes Bild des Videos durch Interpolation wieder die alte Auflösung erzeugt. Der dabei entstandene Interpolations-Fehler wird weiterverwendet, die interpolierten Bilder werden verworfen und der Unterabtastungs-Prozess wiederholt sich aufsetzend auf der gerade verwendeten Auflösungsstufe. Diese Schritte wiederholen sich, bis die gewünschte kleinste Auflösung erreicht wurde. Die Version eines jeden Bildes spiegelt den Basis-Kanal wieder. Jede zuvor durchgeführte Unter-Abtastungs-Stufe liefert das Material für einen Erweiterungs-Kanal. Über sie werden die jeweiligen Interpolations-Fehler der Einzelbilder übertragen. Diese Fehlerwerte weisen eine sehr hohe Redundanz auf und lassen sich deswegen sehr gut komprimieren. Der Empfänger in der Form des Streaming-Knotens kann mit Hilfe des Basisbilds und den dazugehörigen Interpolation-Fehlern ein fast fehlerfreies Originalbild rekonstruieren. Auf diese Weise lassen sich sehr viele Qualitätsstufen des Videos erzeugen.
Chunks und Atonks unterscheiden sich in mehreren Merkmalen. Herunter geladene Chunks können eigenständig abgespielt werden, dies ist bei Atonks nur bedingt mög lich. Atonks können ganz unterschiedliche Größen besitzen, während Chunks gleich groß sind. Je nach verwendeter Codierung müssen nicht alle Atonks zum Abspielen eines Chunks herunter geladen werden. Das Video kommt jedoch ins Stocken, wenn nicht zumindest die notwendigsten Teile aller Chunks herunter geladen werden.
Vorraussetzung für die Einteilung der Chunks in Atonks ist die bereits oben erwähnte Atonk-Map, welche am Anfang eines Chunks und bei jedem Identitätswert im Chord-Ring abgelegt wird. Die Atonk-Map gibt dabei eine Anleitung, welche Atonks herunter geladen wird müssen, um eine gewisse Qualität zu erhalten oder welche Atonks die wichtigsten sind. Atonks können Video- oder Audioinformationen enthalten und sind mit einem Label markiert. Die Bedeutung eines Labels muss in der Atonk-Map definiert werden. Die Separation eines Videos in Chunks kann je nach verwendeter Codierung vor oder nach der Codierung und der Umformung des Videos in die erwünschte Dateistruktur erfolgen. Die Datei ist dann streamingfähig und für eine verteilte Organisation im Rahmen der in 1 bzw. 2 gezeigten Ringstruktur R geeignet. Mit einer der bekannten Hash-Funktionen wird ein Hashwert für das bereitzustellende Video erzeugt. Dazu können charakterisierende Werte des Videos, wie z. B. Einstellungsdatum, Videogröße, Dateistruktur oder ähnliches herangezogen werden.
In der hier beschriebenen Ausführungsform des erfindungsgemäßen Verfahrens werden zur Organisation der Videoverbreitung Metadateien verwendet, welche wichtige Informationen über das entsprechende Video in einem Metacontainer enthalten. Ein Metacontainer stellt dabei ein Objekt dar, in dem mehrere Metadateien zu einem Videostrom gesammelt und gespeichert werden. Die Metadateien an sich sind nicht veränderbar, es können aber neue in den Metacontainer hinzugefügt werden und eventuell auch Metadateien entfernt werden. In den Metadateien werden verschiedene charakterisierende Informationen zu der Videodatei gespeichert. Insbesondere können in einem Metacontainer gegebenenfalls auch weitere Tonspuren eines Videos abgelegt werden.
In einer besonders bevorzugten Ausführungsform setzt sich der Metacontainer aus einer Video-Metadatei, einer Inhalts-Metadatei, einer Audio-Metadatei sowie gegebenenfalls weiteren Audiospuren zusammen. In der Video-Metadatei werden Informationen zu der Videodatei und dem Aufbau des Videostreams gesammelt. Diese Informationen umfassen insbesondere den Hashwert des bereitgestellten Videos, die Größe der gesamten Videodatei ohne Audio, die Anzahl und Größe der Video-Chunks, den Aufbau und die Größe der Atonks, Kapitelsprungmarken, Qualitätsstufenmerkmale sowie die verwendeten Video-Coder.
In der Inhalts-Metadatei werden charakterisierende Informationen zum Video gesammelt. Diese dienen den Benutzern auch vor dem Abspielen des Videos als Anhaltspunkt, um welches Video es sich handelt. Die Inhalts-Metadatei umfasst insbesondere den Hashwert des Videos, eine Video-Kurzbeschreibung, Informationen zu den Darstellern, dem Produzenten, dem Veröffentlicher und das Genre des Videos sowie gegebennenfalls weitere charakterisierenden Informationen.
In einer Audio-Metadatei werden Informationen zur jeweiligen Tonspur gesammelt. Insbesondere umfasst diese Datei den Hashwert des Videos, die Größe der gesamten Tonspur, die Anzahl und Größe der Ton-Chunks, die verwendeten Audio-Codierer für die Tonspur sowie Audio-Metadaten, wie Sprache, Qualität der Audiospur und dergleichen.
Im Folgenden wird detailliert das Herunterladen eines Videos durch einen entsprechenden Streaming-Knoten basierend auf einer Ausführungsform des erfindungsgemäßen Verfahrens erläutert. Zunächst wird auf dem entsprechenden Rechner des Streaming-Knotens durch einen Benutzer die Client-Software zur Durchführung des erfindungsgemäßen Verfahrens gestartet. Im Rahmen der Software kann der Nutzer einen bestimmten Anbieter zum Herunterladen seines Videos auswählen. Die Software kontaktiert dann die ihr vorher bekannte Adresse des Anbieter-Servers, der in 1 mit SE bezeichnet ist. Nach einem Login kann dann eine aktuelle Liste mit Informationen zu den vorhandenen Videostreams auf den Streaming-Knoten herunter geladen werden. Wenn der Nutzer des Streaming-Knotens ein bestimmtes Video sucht, kann er auch die Videostreams nach bestimmten Kriterien wie Genre, Schauspieler, Sprache und dergleichen, sortieren. Die Suche läuft entweder lokal auf dem Straming-Knoten ab, wobei in diesem Fall die komplette Liste verfügbarer Videostreams herunter geladen werden muss. Es besteht auch die Möglichkeit, eine Anfrage an den Server des Anbieters zu senden, der dann eine Liste von möglichen Ergebnissen liefert. Die Informationen hierzu werden aus dem zuvor beschriebenen Meta-Container extrahiert, wobei insbesondere die Inhalts-Metadatei dem Nutzer des Streaming-Knotens zur Entscheidungsfindung dient.
Nach Auswahl eines bestimmten Videostreams über einen Streaming-Knoten wird die Auswahl der aktuell verfügbaren Zugangspunkte herunter geladen, die in der Liste T der 1 in der Spalte „aktive Knoten” für das entsprechende Video hinterlegt ist. Bevor das eigentliche Streaming beginnt, wird durch den Streaming-Knoten zunächst überprüft, ob er zumindest einen der Zugangspunkte erreichen kann und ob an dieser Stelle der entsprechende Chord-Ring, über den die Chunks des Videos verwaltet werden, zur Verfügung steht. Anschließend wird anhand einer Kompatibilitätsprüfung sichergestellt, ob und mit welchen Einschränkungen der Videostream auf dem Streaming-Knoten abgespielt werden kann.
Erst wenn die obigen Bedingungen ausreichend erfüllt sind, wird von dem Streaming-Knoten erfragt, in welcher Sprache und Qualität das Streaming betrachtet werden soll. Es stehen dabei nur diejenigen Varianten zur Verfügung, die nach der Kompatibilitätsprüfung für erfüllbar eingeschätzt werden und laut dem Meta-Container verfügbar sind. Alternativ kann der Benutzer des Streaming-Knotens, abhängig vom Anbieter, gegebenenfalls auch die Komplettaufnahme auswählen, bei der der Stream aufgenommen wird und erst nach vollständigem Herunterladen abgespielt werden kann.
Während der soeben beschriebenen Abfrage von Informationen durch den Streaming-Knoten werden bereits Prozesse für das Video-Streaming, das Herunterladen von permanent verfügbaren Chunks auf den Streaming-Knoten sowie den Eintritt des Streaming-Knotens in den Chord-Ring gestartet. Diese Prozesse werden im Folgenden erläutert.
In der hier beschriebenen Ausführungsform wird ein Streaming-Knoten, der Chunks aus dem entsprechenden Chord-Ring herunter laden möchte, unter bestimmten Bedingungen auch Teil des Chord-Rings. Das heißt, ein Streaming-Knoten wird auf diese Weise auch an der Verwaltung von Chunks eines Videos beteiligt. Es bestehen dabei verschiedene Möglichkeiten, welchem Identitätswert und damit welchem Identitätsintervall der Streaming-Knoten zugewiesen wird. In einer Variante wählt der Streaming-Knoten selbständig einen Identitätswert aus dem Chord-Ring per Zufallsverfahren aus und überprüft dessen Belegung im Ring mit einer speziellen Suche. Falls der entsprechende Identitätswert bereits durch einen Knoten besetzt ist, wiederholt sich dieser Vorgang, bis eine freie Position gefunden wurde. Gegebenenfalls kann der Vorgang auch nach einer vorbestimmten Anzahl von Anfragen abgebrochen werden, wobei in diesem Fall der Streaming-Knoten nicht Teil des Chord-Rings wird.
In einer weiteren Variante wird der Identitätswert, der durch den Streaming-Knoten zu besetzen ist, nach einem festen Muster gewählt. Dabei kann insbesondere berücksichtigt werden, dass häufig nur die ersten Minuten eines Videos durch Benutzer abgespielt werden. In vielen Fällen stellt ein Nutzer nämlich bereits am Anfang des Videos fest, dass er dieses Video nicht mag und bricht das Streaming ab. Auf diese Weise entstehen höhere Belastungen für Ringpositionen mit niedrigeren Identitätswerten als für Ringpositionen mit höheren Identitätswerten. Diese Tatsache kann durch ein entsprechendes Eintritts-Muster berücksichtigt werden. Der Streaming-Knoten kennt dabei im Vorhinein das Eintrittsmuster. Dieses Muster könnte gegebenenfalls auch in dem Meta-Container des Videos abgelegt sein. Das Muster beschreibt, in welcher festen Reihenfolge die Positionen im entsprechenden Chord-Ring besetzt werden sollen. Demzufolge sendet der Streaming-Knoten eine spezielle Anfrage an den ersten Identitätswert des Musters. Ist dieser Identitätswert besetzt, leitet der angefragte Knoten die Anfrage an den nächsten Identitätswert im Muster weiter. Das wiederholt sich, bis die erste freie Position gefunden wurde, an der sich der Streaming-Knoten dann mit dem Ring verbindet. Gegebenenfalls kann die Suche auch abgebrochen werden, wenn eine vorbestimmte Anzahl an Anfragen nicht zu einem freien Knoten geführt hat.
Unter Umständen kann die Suche nach einem freien Knoten bei einem nahezu vollbesetzten Chord-Ring lange dauern. Da jedoch das eigentliche Abspielen des Videostreams nicht an den endgültigen Eintritt des Streaming-Knotens in den Ring gebunden ist, tritt hierdurch jedoch keine Verzögerung beim Streaming auf. Hat der Streaming-Knoten schließlich eine Position im Chord-Ring gefunden, an der er dem Chord-Ring beitreten wird, werden die vom Chord-Protokoll spezifizierten Mechanismen zum Eintritt in den Ring ausgeführt. Diese Mechanismen sind hinlänglich aus dem Stand der Technik bekannt und werden deshalb nicht im Detail erläutert. Von dem neu zu dem Ring hinzukommenden Streaming-Knoten müssen dabei sämtliche Verwaltungsaufgaben zum Erhalt des Rings übernommen werden, die Routing-Tabelle erzeugt und aktuell gehalten werden und die Verantwortung bzw. Zuständigkeit für den zugewiesenen Teil des Rings übernommen werden. Die Zuständigkeit erstreckt sich dabei von der Position, an welcher der Streaming-Knoten dem Ring beitritt, bis zu der Position des im Knoten davor liegenden Knotens. Durch den hinzukommenden Streaming-Knoten müssen ferner auch die entsprechenden PeRL- bzw. PaRL-Listen der jeweiligen Identitätswerte aktuell gehalten werden und Suchanfragen beantwortet bzw. weitergeleitet werden.
In der hier beschriebenen Ausführungsform der Erfindung wird darüber hinaus eine redundante Kopie der in einem Knoten des Rings gesammelten Informationen erstellt, um im Falle des Ausfalls eines Knotens keinen Informationsverlust zu riskieren. Dabei werden die gesammelten Informationen eines Knotens redundant in dem Nachfolgeknoten gespeichert und in regelmäßigen Abständen mit dem Original aktualisiert. Falls ein Knoten aus dem Ring ausfällt, kann der Nachfolgeknoten sofort den Zuständigkeitsbereich des ausfallenden Knotens übernehmen. Eine annähernd aktu elle Version der PeRL- bzw. PaRL-Listen hat er dabei bereits verfügbar. Die Verwaltung im Netz ist somit auch bei häufigen Knotenausfällen weitestgehend sichergestellt.
Sollte der Fall auftreten, dass der Streaming-Knoten den Chord-Ring nicht beitreten kann, weil bereits jede Position im Ring mit einem Knoten besetzt ist, sind verschiedenen Varianten möglich. In einer ersten Variante tritt der Streaming-Knoten dem Ring nicht bei. Dabei kann, wie bereits oben erwähnt wurde, der Versuch des Eintritts in den Ring abgebrochen werden, wenn eine gewisse Anzahl an Eintrittsversuchen aufgrund von besetzten Ringpositionen gescheitert ist. Solche Knoten übernehmen dann keine Verwaltungsfunktion im Ring. Gegebenenfalls besteht auch die Möglichkeit, dass solche Knoten eine höhere Anzahl von permanent bereitzustellenden Chunks speichern müssen, wobei die permanente Speicherung der Chunks parallel zum Streaming erfolgt, wie weiter unten noch näher erläutert wird. Gegebenenfalls kann der Eintritt eines Streaming-Knotens in einem Ring in regelmäßigen Abständen auch erneut versucht werden. Sollte dann die Anzahl der Knoten im Ring gesunken sein, ist der Eintritt des Knotens in den Ring möglich.
In einer weiteren Variante kann der Eintritt in den Ring auch von Eigenschaften des Knotens abhängig gemacht werden. Beispielsweise können nur solche Streaming-Knoten in den Ring beitreten, welche eine gewisse Ressourcengröße überschreiten, wobei die Ressourcen insbesondere die verfügbare Uploadrate bzw. Rechenkapazität bzw. den verfügbaren Speicher des Knotens betreffen. Alle Streaming-Knoten, die dem Ring nicht beigetreten sind, aktualisieren in festen Abständen eine Liste mit Zugangspunkten in den Ring, wobei eine aktualisierte Liste beispielsweise basierend auf der Liste T gemäß 1 von dem Videoanbieter herunter geladen werden kann.
Mit der soeben geschilderten Variante, bei der nur Knoten mit ausreichenden Ressourcen dem Ring beitreten, wird verhindert, dass schwache Knoten im Ring überlastet werden. Natürlich kann es auch in dieser Variante zu einem vollbesetzten Ring kommen. In diesem Fall wird dann auf die zuvor beschriebene Variante zurückgegriffen, d. h. der Knoten tritt nicht dem Ring bei.
Gemäß den obigen Ausführungsformen sollte sich ein Streaming-Knoten an der Organisation des entsprechenden Chord-Rings beteiligen, indem er dem Ring beitritt. Es kann jedoch auch der Fall auftreten, dass der Streaming-Knoten nicht Teil des Rings wird. Im Unterschied dazu wird in der hier beschriebenen Ausführungsform sichergestellt, dass sich ein Streaming-Knoten jedoch auf jeden Fall an der Verbreitung des Videos dadurch beteiligt, dass er permanent für andere Knoten verfügbare Chunks bereitstellt. Es wird hiermit erreicht, dass jeder Streaming-Knoten auch dazu gezwungen wird, seine Upload-Kapazität für andere Knoten bereitzustellen. Knoten, welche gewisse Chunks permanent zur Verfügung stellen, sind zum einen die Knoten, die eine komplette Kopie des Videos besitzen, und damit alle Chunks permanent enthalten. Ferner übernehmen all die Knoten, welche das Video selbst nur streamen, die Replizierverantwortung für eine gewisse Anzahl an Chunks, solange sie mit dem Netz verbunden sind. Es wird somit eine Replikation der Chunks in einer Mehrzahl von Knoten erreicht, wodurch die Ausfallsicherheit des Netzes erhöht wird.
Fällt beispielsweise ein Knoten im Netz aus, geht bei entsprechend hoher Replikation des Chunks nur ein kleiner Teil der Chunk-Verfügbarkeit verloren. Dies führt zu Stabilität und Ausfallsicherheit. Je höher die Chunk-Replikation ist, desto mehr Quellen hat ein Streaming-Knoten, aus denen er Chunks zum Herunterladen auswählen kann. Wenn während des Herunterladens eines Chunks ein Quellknoten ausfällt, werden die Atonks von dieser Quelle nicht mehr vollständig beim Empfänger ankommen. Da es jedoch auch genügend andere Quellen gibt, bei denen Atonks erfolgreich herunter geladen werden konnten, wirkt sich der Ausfall nicht durch Unterbrechungen, sondern nur in einer schlechteren Qualität aus. Dabei ist zu berücksichtigen, dass in der hier beschriebenen Ausführungsform des erfindungsgemäßen Verfahrens sowohl Mehrfach-Downloads für den gleichen Chunk als auch unterschiedliche Qualitätsabstufungen bei der Codierung des Videos ermöglicht werden.
Die permanente Chunk-Replikation wird pro repliziertem Chunk eine vorbestimmte Anzahl an Malen durchlaufen. Die durch einen Streaming-Knoten durchgeführte Replikation eines Chunks läuft dabei nach einem festgelegten Schema ab. Zunächst wählt der Streaming-Knoten eine Chunk-Nummer aus dem Ring aus, aus dem er eine Videodatei gerade streamt. Die Auswahl kann dabei zufällig erfolgen. Nachdem ein entsprechender Identitätswert gewählt wurde und der für diesen Identitätswert zuständige Knoten im Chord-Ring basierend auf einer entsprechenden Suche gefunden wurde, sendet der Streaming-Knoten eine Anfrage an den gefundenen Knoten, mit der die PeRL- und PaRL-Listen der entsprechenden Chunk-Nummer angefordert werden. Nach Erhalt dieser Listen wird der Chunk komplett mit allen Tonspuren und dem entsprechenden Meta-Container des Videos herunter geladen.
Sobald ein Streaming-Knoten einen neuen, zu replizierenden Chunk vollständig herunter geladen hat, lässt er sich selbst in die PeRL-Liste des entsprechenden Knotens eintragen, der in dem Chord-Ring für den Chunk zuständig ist. Um diese Liste immer aktuell zu halten, werden in regelmäßigen Abständen sog. Keep-Alive-Nachrichten ausgetauscht. Dazu sendet der Streaming-Knoten auch nach Abschluss des Streamings für jeden replizierten Chunk eine Nachricht an den für den jeweiligen Identitätswert verantwortlichen Chord-Knoten und teilt ihm mit, dass die Replikation noch verfügbar ist. Da er die Adresse des für den Identitätswert zuständigen Knotens bereits kennt, besteht der Keep-Alive-Mechanismus normalerweise aus einem einfachen Nachrichtenaustausch. Wenn sich an den Zuständigkeiten im Chord-Ring nichts geändert hat, wird die Meldung quittiert zurückgesendet. Im anderen Fall muss eine Suche nach der Chunk-Nummer in den Ring gestellt werden und nach der Auflösung müssen die Keep-Alive-Nachrichten erneut an die neue Adresse geschickt werden.
Nachfolgend wird nunmehr das eigentliche Video-Streaming durch den Streaming-Knoten erläutert. Dabei wird genau geregelt, auf welche Weise ein Streaming-Knoten entsprechende PeRL- bzw. PaRL-Listen anfordert und von den darin aufgelisteten Knoten die Chunks herunter lädt. Im Regelfall möchte ein Nutzer des Streaming-Knotens das zu streamende Video ganz von Anfang an beginnen. Nichtsdesto trotz kann ein Nutzer in dem hier beschriebenen Verfahren das Video auch an einem anderen Punkt als am Anfang beginnen, wenn er den Anfang des Videos beispielsweise bereits gesehen hat. In beiden Fällen ist der vom Nutzer gewählte Startpunkt des Videos in eine entsprechende Chunk-Nummer umzusetzen, deren Chunk als erstes herunter geladen werden soll. Ein Knoten, der ganz neu im Streaming-Netz ist, wird mit der Chunk-Nummer 0 beginnen. Für springende Teilnehmer müssen die Chunk-Nummern direkt nach der jeweiligen Auswahl berechnet werden. Dies lässt sich in einfacher Weise realisieren, da die Anzahl und Größe der Chunks sowie die Länge des Streams über den oben beschriebenen Meta-Container bekannt ist.
Nachdem über den Meta-Container die Chunk-Nummer des zuerst herunter zu ladenden Chunks bestimmt wurde, wird durch den Streaming-Knoten eine Suche nach dem korrespondierenden Identitätswert in den Chord-Ring gestellt. Es werden dabei die hinlänglich bekannten Suchmechanismen aus Chord verwendet, wobei die Suchabfrage in geeigneter Weise zwischen den Chord-Knoten weitergeleitet und verarbeitet wird, bis der zuständige Chord-Knoten gefunden ist. Nach Auffinden des zuständigen Chord-Knotens werden als Antwort an den Streaming-Knoten die entsprechenden Replikationslisten des Chord-Knotens, der Meta-Container des Videos sowie die Atonk-Map zurückgesendet. Zusätzlich fügt der zuständige Chord-Knoten noch weitere Informationen über den aktuellen Chord-Ring-Aufbau an. Der Mechanismus des zusätzlichen Einfügens von Informationen wird im Folgenden als „Successor Piggyback” bezeichnet. Dabei werden folgende Informationen an die Antwortnachricht angehängt.

– die eigene Adresse des zuständigen Chord-Knotens;
– der Identitätswert bzw. die Position, die der zuständige Chord-Knoten im Chord-Ring selbst einnimmt;
– die Adresse des unmittelbaren Nachfolgeknotens im Chord-Ring;
– der Identitätswert bzw. die Position, die der unmittelbare Nachfolgeknoten im Chord-Ring einnimmt.

Anhand der obigen Informationen kann der Streaming-Knoten erkennen, welcher Chord-Knoten für die nächste anzufordernde Chunk-Nummer im Chord-Ring zuständig ist und welche Adresse dieser Knoten besitzt. Auf diese Weise wird erreicht, dass ein Streaming-Knoten keine erneute Anfrage nach Nachfolgeknoten im Chord-Ring zum Herunterladen von neuen Chunks stellen muss, da ihm der Nachfolgeknoten im Chord-Ring bereits bekannt ist. Hierdurch wird der Netzverkehr reduziert.
4 zeigt nochmals ausschnittsweise das Herunterladen der PeRL- bzw. PaRL-Listen gemäß dem Successor-Piggyback-Verfahren. Die PeRL- und PaRL-Listen werden dabei allgemein als Replikationslisten bezeichnet. Das Diagramm der 4 beruht auf dem in 1 bzw. 2 dargestellten Chord-Ring R. Ferner wird davon ausgegangen, dass der Stream am Anfang des Videos, d. h. an der Position 0, beginnen soll. Zunächst richtet der Streaming-Knoten SK in Schritt S1 eine Suchanfrage an den Chord-Ring R zum Auffinden der Position 0. Nach Auflösen der Suche wird dem Streaming-Knoten in Schritt S2 die Adresse des Knotens K1 zurückgegeben. Der Streaming-Knoten sendet dann in Schritt S3 eine Anfrage nach den Replikationslisten für den Chunk 0 an den Knoten K1. Der Knoten K1 beantwortet diese Anfrage in Schritt S4 durch Übersenden der entsprechenden Replikationslisten samt den Informationen über den Nachfolgeknoten K2 an den Streaming-Knoten SK. Anschließend kann der Streaming-Knoten SK dann den entsprechenden Chunk 0 von einem oder mehreren der Knoten aus den Replikationslisten herunter laden.
Im nächsten Schritt S5 fragt der Streaming-Knoten direkt beim Nachfolger K2 die entsprechenden Replikationslisten der Chunks ab, für welche der Nachfolgeknoten K2 zuständig ist. Dies sind die Replikationslisten für die Chunks 1, 2, 3 und 4. Für diese Chunks sind also keine weiteren Suchanfragen im Chord-Ring mehr notwendig. Der Knoten K2 sendet dann in Schritt S6 die entsprechenden Replikationslisten sowie Informationen über den Nachfolgeknoten K3 zurück, woraufhin auch hierfür die Downloads initiiert werden. Das Verfahren setzt sich fort, indem der Streaming-Knoten SK in Schritt S7 eine entsprechende Anfrage nach Replikationslisten für die Chunks 5 und 6 an den Nachfolgeknoten K3 richtet, woraufhin wiederum die ent sprechenden Replikationslisten an den Streaming-Knoten SK übermittelt werden und der Download der nächsten Chunks beginnen kann.
Wie sich aus 4 ergibt, kann durch die permanente Übermittlung der Adresse und der Chunk-Position des Nachfolgeknotens auf mehrfache Suchanfragen an den Chord-Ring verzichtet werden, da dem Streaming-Knoten immer bekannt ist, welcher Nachfolgeknoten die nächsten herunter zu ladenden Chunks verwaltet. Wenn ein Streaming-Knoten das Video in Reihenfolge ansieht, hangelt er sich somit in dem Chord-Ring gemäß 1 bzw. 2 im Uhrzeigersinn von Identitätswert zu Identitätswert, ohne eine weitere Suche in den Chord-Ring stellen zu müssen. Nach jeder Anfrage werden dem Knoten zudem aktuelle Veränderungen, beispielsweise Änderungen an der Zuständigkeit im Chord-Ring, mitgeteilt. Erst wenn der Knoten im Stream springt oder eine Verbindung zu einem der Chord-Knoten fehlschlägt, muss eine erneute Suchanfrage in den Ring gestellt werden.
In kleinen Netzen mit wenigen daran beteiligten Knoten wachsen die PeRL- bzw. PaRL-Listen zu keiner sonderlichen Größe heran. Es ist in diesem Fall unproblematisch, diese Listen komplett zu verbreiten. Ab einer gewissen Anzahl von an der Verteilung des Videos beteiligten Knoten ist es nicht mehr ratsam, die kompletten Listen zur ständigen Verbreitung zu verteilen. Dies ist auch nicht erforderlich, da ein Streaming-Knoten sich zum Download nur eine kleine Anzahl an Quellen heraussucht, von denen er die Chunks herunter lädt.
Demzufolge wird die PeRL-Liste ab einer bestimmten Größe an Einträgen nicht mehr komplett verbreitet. Vielmehr wählt der Chord-Knoten, von dem die Liste angefragt wird, lediglich eine gewisse Untermenge zufälliger Quellen aus und sendet deren Information an den Streaming-Knoten. Es sollte dabei jedoch darauf geachtet werden, dass jede Anfrage mit anderen Quellen bedient wird. Der Chord-Knoten könnte beispielsweise in der PeRL-Liste vermerken, wie oft eine Quelle schon versendet wurde. Dadurch lässt sich eine gute Gleichmäßigkeit der zum Download verwendeten Quellen erreichen. Im Unterschied zu der PeRL-Liste ist es für die PaRL- Liste in der hier beschriebenen Ausführungsform erforderlich, dass diese Liste komplett zu jedem Streaming-Knoten übermittelt wird, wie weiter unten noch näher beschrieben wird.
Ein Streaming-Knoten wählt immer nur die Tonspur und die von ihm gewünschte Videoqualität, d. h. die entsprechenden Atonks, des gerade gestreamten Videos herunter. Mit jeder Anfrage nach den Replikationslisten wird der Streaming-Knoten automatisch als Quelle in die entsprechende PaRL-Liste des angefragten Chunks eingetragen. Dazu werden die Adresse und der Zeitstempel abgelegt. Der entsprechende Chord-Knoten, in dessen PaRL-Liste der Streaming-Knoten eingetragen wird, hat allerdings keine Informationen darüber, welche Atonks und ob der gerade eingetragene Knoten überhaupt etwas herunter geladen hat. Außerdem werden für die Einträge der PaRL-Liste keine Keep-Alive-Nachrichten zur Überprüfung der Quellen ausgetauscht, wie dies bei den PeRL-Listen der Fall ist. Somit werden in den PaRL-Listen Knoten geführt, bei denen lediglich die Wahrscheinlichkeit hoch ist, dass sie den Chunk gemäß der PaRL-Liste zumindest teilweise besitzen und zur Verfügung stellen können. Anders als für PeRL-Einträge gibt es somit für die PaRL-Einträge keine Garantien für die Verfügbarkeit der Quellen.
Da die PaRL-Liste immer ganz verteilt werden soll, darf sie nicht zu groß werden. Um dies zu erreichen und gleichzeitig die Verfügbarkeitswahrscheinlichkeit der Quellen aus der PaRL-Liste zu steigern, werden in der hier beschriebenen Ausführungsform einige begrenzende Maßnahmen eingesetzt. Insbesondere werden Knoten aus der PeRL-Liste nicht in die PaRL-Liste aufgenommen. Ferner werden nach Ablauf einer festen Zeit alte Einträge in der PaRL-Liste gelöscht. Darüber hinaus meldet ein Streaming-Knoten, der beim Download auf einen nicht verfügbaren Knoten in der PaRL-Liste gestoßen ist, die mangelnde Verfügbarkeit des Knotens an den zuständigen Chord-Knoten. Dieser löscht den Eintrag, nachdem er dies selbst überprüft hat. Schließlich wird die PaRL-Liste noch durch eine maximale Größe an Einträgen begrenzt, und wenn dieser Wert überschritten wird, werden die ältesten Einträge gelöscht, um für neue Einträge in der PaRL-Liste Platz zu machen.
Die obigen Maßnahmen stellen sicher, dass die PaRL-Liste immer so klein wie möglich gehalten wird. Zudem wird die Wahrscheinlichkeit erhöht, dass die Knoten in der PaRL-Liste wirklich den Chunk besitzen, da nach Ablauf einer festen Zeit alte Einträge gelöscht werden und die Nichtverfügbarkeit von Knoten dem Chord-Ring mitgeteilt wird. Ferner wird durch die Beschränkung der PaRL-Liste auf eine maximale Größe auch für große Netze garantiert, dass der entsprechende Chord-Knoten im Ring nie überlastet wird. Die Verwendung von PaRL-Listen bietet einige Vorteile, wie nachfolgend erläutert wird.
Ein streamender Knoten, der einen Chunk herunter geladen hat, hält diesen zunächst in einem Puffer vor, bis der Chunk tatsächlich abgespielt wird. Anstatt die Datei nach dem Abspielen sofort zu löschen, belässt der Knoten den Chunk in der hier beschriebenen Ausführungsform der Erfindung noch eine Weile in seinem Speicher. Das kann man auch als Rückwärts-Pufferung bezeichnen, da der Chunk sich in Relation zum Abspielzeitpunkt rückwärts bewegt. Zum einen dient der Rückwärtspuffer für den Fall, dass der Nutzer eine Szene sofort nach dem Abspielen noch einmal abspielen möchte. Zum anderen kann der Chunk noch länger über die PaRL-Liste zum Download für andere Knoten angeboten werden. Die Größe des Rückwärts-Puffers kann dem üblicherweise verwendeten Puffer entsprechen, der in 2 durch das Streaming-Fenster W repräsentiert wird. Gegebenenfalls kann der Rückwärts-Puffer sogar den gesamten bisher abgespielten Stream beinhalten. Dies hängt letztendlich vom verfügbaren Speicherplatz ab. Die Verwendung der PaRL-Liste in Kombination mit der soeben beschriebenen Rückwärts-Pufferung bietet Vorteile, wie anhand der nachfolgenden Beispiele erläutert wird.
Es wird angenommen, dass der streamende Knoten X das Abspielen bei der Chunk-Nummer 0 beginnt, den er bereits herunter geladen hat. Gleichzeitig befindet sich der Streaming-Knoten in der Phase des Pufferaufbaus mit einer Puffergröße von sechs Chunks. Er lädt also die Chunks 1 bis 5 herunter und speichert sie im Puffer. Der Knoten X ist somit in den PaRL-Listen bei den Identitätswerten 0 bis 5 eingetragen.
Sein Abspielzeitpunkt wandert nun von Chunk-Nummer 0 auf Chunk-Nummer 1 über. Der Videostream wird aus dem Puffer bedient. Ein anderer Knoten Y tritt auch in das Netz ein und beginnt ebenfalls mit dem Streaming bei der Chunk-Nummer 0. Da X in der PaRL-Liste der Chunk-Nummer 0 steht, kann der Knoten Y nunmehr den Chunk 0 von dem Knoten X herunter laden und abspielen. Auf gleiche Weise kann der Knoten Y zum Pufferaufbau auch die Chunks 1 bis 5 vom Knoten X herunter laden.
Somit lädt in diesem Beispiel der Knoten Y vom Knoten X alle Chunks 1 bis 5 herunter. Die Videoqualität der Chunks entspricht dabei der Qualität, mit der Chunks beim Knoten X herunter geladen wurden. Über die PaRL-Liste hat der Knoten Y die Informationen, dass der Knoten X die gewünschten Chunks 0 bis 5 besitzt. Dabei bezieht Y den Chunk 0 aus dem Rückwärts-Puffer vom Knoten X und die Chunks 1 bis 5 aus dem normalen Puffer. Ohne Rückwärts-Puffereng müsste sich der Knoten Y eine andere Quelle suchen, da der Chunk 0 dem Knoten Y nicht mehr zur Verfügung stehen würde. Mit Hilfe der PaRL-Liste werden somit zum einen die Knoten in der PeRL-Liste entlastet und zum anderen enthalten die Einträge in der PaRL-Liste ein sequentielles Muster. Gemäß dem obigen Beispiel taucht der Knoten X in den PaRL-Listen für die Chunk-Nummern 0 bis 5 auf, was der Knoten Y durch Vergleich dieser PaRL-Listen herausfinden kann. Wenn der Knoten Y somit den Chunk 0 erfolgreich herunter laden konnte, funktioniert dies mit hoher Wahrscheinlichkeit auch mit den darauffolgenden Chunks 1 bis 5. Zusätzlich ist auch ein Push-Service denkbar, falls der Knoten Y die auf den Chunk 5 folgenden Chunks ebenfalls besitzt. Sobald der Knoten Y die Chunks 1 bis 5 erfolgreich vom Knoten X empfangen hat, sendet X automatisch auch den folgenden Chunk 6 an Y. X sendet die Chunks dabei der Reihe nach solange an den Knoten Y, bis Y den Push stoppt oder in dem Puffer von X keine Chunks mehr enthalten sind.
Insgesamt können somit aufeinander folgend mehrere Chunks von einem Knoten herunter geladen werden. Gemäß dem obigen Beispiel lädt der Knoten Y dabei die Atonks mit dem gleichen Label aus verschiedenen Chunks des Knotens X herunter.
Dies ist vor allem vor dem Hintergrund relevant, dass die Knoten aus der PaRL-Liste nicht den kompletten Informationsinhalt des Chunks besitzen, sondern nur die Sprache und Bildqualität, welche sie selbst gewählt haben. Wenn der Knoten Y bei dem Knoten X somit die gesuchten Atonks für Chunk 0 gefunden hat, dann wird das voraussichtlich auch für die Chunks 1 bis 5 so sein. Sollte das tatsächlich nicht der Fall sein, oder sollte X generell eine niedrigere Qualität bzw. andere Sprache betrachtet haben, müssen die fehlenden Atonks von anderen Quellen aus der entsprechenden PaRL-Liste bzw. PeRL-Liste herunter geladen werden.
Basierend auf dem soeben erläuterten Beispiel wird nunmehr auch ersichtlich, warum die PaRL-Listen bei der Verwendung des Successor-Piggyback-Verfahrens immer komplett verteilt werden sollten. Bei dem Successor-Piggyback-Verfahren lernt der Streaming-Knoten durch Weiterreichen von Nachfolger zu Nachfolger sehr schnell die für die Replikationslisten zuständigen Knoten kennen. Von diesen kann er sich sofort einen ganzen Satz von PaRL-Listen für mehrere aufeinander folgende Identitätswerte herunter laden. Diese PaRL-Listen kann er dann miteinander vergleichen, um die Knoten herauszufiltern, von denen er ein ganzes Paket an Chunks herunter laden kann. Die PaRL-Listen müssen deshalb immer komplett bei dem vergleichenden Knoten vorliegen. Wenn nur eine zufällige Auswahl verschickt wird, würde diese im Vergleich nicht mehr so viele Treffer liefern.
5 verdeutlicht nochmals die Verwendung eines Puffers mit Rückwärts-Pufferung in einem Streaming-Knoten. Die gespeicherten Chunks sind dabei in 5 durch entsprechende Balken wiedergegeben, welche nur zum Teil mit dem Bezugszeichen C bezeichnet sind. Der Knoten umfasst dabei einen temporären Puffer B1 mit einem Vorwärts-Puffer B101 und einem Rückwärts-Puffer B102. Der Vorwärts-Puffer entspricht dabei im Wesentlichen dem Streaming-Fenster gemäß 2. Im Rückwärts-Puffer werden bereits abgespielte Chunks des Streams gespeichert. Die Abspielrichtung ist dabei durch den Pfeil P' angedeutet, und der aktuelle Abspielzeitpunkt ist durch das Bezugszeichen Z wiedergegeben. Wie sich aus 5 ergibt, wird der temporäre Puffer neben dem Streamen auch zur Bereitstellung der Chunks für PaRL- Listen genutzt. Neben dem temporären Puffer B1 ist ferner ein permanenter Speicher B2 vorgesehen. Sofern dieser Speicher noch nicht gefüllt ist, werden während des Streamens des Videos parallel Chunks herunter geladen, welche permanent zum Download für andere Knoten zur Verfügung gestellt werden. Diese Chunks werden für die entsprechenden PeRL-Listen bereitgestellt.
Im Folgenden wird erläutert, nach welchen Kriterien ein Streaming-Knoten entsprechende Download-Quellen aus den ihm bereitgestellten PeRL- bzw. PaRL-Listen auswählen kann. Es können dabei beliebige Kriterien verwendet werden, wobei im Folgenden nur Beispiele von möglichen Download-Reihenfolgen gegeben werden. Zunächst kann ein Streaming-Knoten überprüfen, ob er den herunter zu ladenden Chunk möglicherweise lokal gespeichert hat. Dabei überprüft er insbesondere seinen Puffer (insbesondere auch seinen Rückwärts-Puffer), die bei ihm hinterlegten permanenten Replikationen, ob eine komplette Kopie des Videos bei ihm gespeichert wird oder ob der Chunk basierend auf dem obigen Push-Mechanismus bereits im ausreichenden Maße gepusht wird.
Sollte der Chunk nicht lokal gespeichert sein, kann beispielsweise zuerst in den PaRL-Listen nach passenden Quellen gesucht werden. Die Suche kann dabei nach der Lokalität unter Berücksichtigung des IP-Prefixes der Download-Quelle ablaufen, wobei Download-Quellen mit größerer Nähe zum Streaming-Knoten bevorzugt werden. Ferner können Download-Quellen bevorzugt werden, bei denen man mit einer Verbindung auf mehrere Chunks zugreifen kann. Diese Erkenntnis kann durch den oben beschriebenen Vergleich der herunter geladenen PaRL-Listen von mehreren Identitätswerten erreicht werden. Bevorzugt werden ferner Quellen, von denen Knoten bereits herunter geladen wurden. Gegebenenfalls besteht jedoch auch die Möglichkeit, dass Download-Quellen aus den PaRL-Listen zufällig ausgewählt werden.
Die Auswahl von Download-Quellen aus PeRL-Listen kann gegebenenfalls der Auswahl von Download-Quellen aus den PaRL-Listen nachgeschaltet sein, d. h. ein Download aus der PeRL-Liste wird erst dann durchgeführt, wenn eine Download- Quelle in der PaRL-Liste nicht gefunden wurde bzw. nicht verfügbar ist. Dies ist jedoch nicht zwingend erforderlich, und es können gegebenenfalls auch parallel zu den PaRL-Listen Download-Quellen aus PeRL-Listen verwendet werden oder auch zunächst nur Download-Quellen aus den PeRL-Listen verwendet werden.
Beim Download aus den PeRL-Listen kann wiederum die Lokalität der Download-Quelle in Bezug auf den Streaming-Knoten unter Berücksichtigung des IP-Prefixes der Download-Quelle berücksichtigt werden, wobei wiederum nähere Download-Quellen bevorzugt werden. Ebenso kann die Download-Quelle gegebenenfalls auch zufällig aus der PeRL-Liste ausgewählt werden.
Bei der Wahl der Download-Quellen ist vor allem die Atonk-Map behilflich, die dem Streaming-Knoten mitteilt, welche Atonks er für eine gewissen Sprache oder Qualität benötigt. Für die noch fehlenden Atonks überprüft der Knoten per Anfrage, ob die Quelle sie zur Verfügung stellt. Ist das der Fall, lädt er die Atonks herunter. Wird auf die Anfragen nicht geantwortet, springt er zu einer anderen Quelle.
Weitere Kriterien bei der Wahl der Download-Quellen können beispielsweise wie folgt sein:

i) Beim Download werden möglichst verschiedene Download-Quellen für einen jeweiligen Chunk berücksichtigt, um die Auswirkungen eines Knotenausfalls möglichst gering zu halten;
ii) es werden Download-Quellen mit der geringsten Latenz zum Streaming-Knoten zur schnelleren Datenübertragung verwendet;
iii) für Chunks, die nahe am Abspielzeitpunkt des beim Streaming-Knoten abgespielten Videos liegen, werden Download-Quellen aus der PeRL-Liste gegenüber der PaRL-Liste bevorzugt, um einen zuverlässigen Download sicherzustellen.

Nachdem sich ein Streaming-Knoten geeignete Download-Quellen herausgesucht hat, leitet er den Datentransfer durch das Senden von Anfragenachrichten an jede dieser Quellen ein. Die Nachrichten sollen dabei zum einen überprüfen, ob die benötigten Daten tatsächlich an der jeweiligen Quelle liegen. Zum anderen müssen Rahmenbedingungen für den Transfer geschaffen werden. Im Folgenden werden die Informationen aufgelistet, die in dieser Anfragenachricht enthalten sein sollten:

– Hashwert des Streams;
– Chunk-Nummer(n);
– Label der gewünschten Atonks;
– Priorität der Anfrage;
– Datenartenrichtwert;
– Adresse des anfragenden Knotens;
– Sendezeitstempel.

Anhand des Sendezeitstempels und der Empfangszeit kann die Quelle entscheiden, ob die Nachricht noch aktuell ist. Alte Anfragen werden einfach verworfen. Wenn aufgrund von vielen Anfragen nicht alle sofort bedient werden können, wird die Warteschlange nach Empfangszeiten abgearbeitet.
Anhand der ersten drei der oben aufgelisteten Punkte kann die Download-Quelle genau identifizieren, welche Daten angefordert werden und ob sie verfügbar sind. Über die Priorität erkennt die Download-Quelle außerdem, wie wichtig die Anfrage ist. Davon abhängig entscheidet die Download-Quelle, ob der Transfer zustande kommt und wie viel Datenrate dafür reserviert werden kann.
Der vom anfragenden Knoten übermittelte Datenratenrichtwert soll der Download-Quelle mitteilen, in welchem ungefähren Umfang sich die Belastung für sie einpendeln wird. Dieser Wert richtet sich nach der Abspielrate oder ebenfalls nach der Dringlichkeit, mit der die Atonks benötigt werden. Für die Quelle ist dieser Richtwert neben der Priorität ein Entscheidungskriterium, ob sie die Anfrage annehmen wird. Sollte die Quelle sich bereits am Rande der Auslastung befinden, wird sie Anfragen mit hohen Richtwerten ablehnen.
Die verschiedenen Antwortmöglichkeiten einer Download-Quelle auf die Anfrage können demnach sein:

– Ablehnung mit Grund (beispielsweise Überlastung);
– Nichtverfügbarkeit der Daten;
– Teilverfügbarkeit der Daten und welche das sind;
– Akzeptieren der gesamten Anfrage.

Neben einer geeigneten Auswahl von Download-Quellen werden in der hier beschriebenen Ausführungsform des Verfahrens die auf den Streaming-Knoten herunter zu ladenden Chunks mit verschiedenen Prioritätsnummern versehen und somit in verschiedene Prioritätsklassen eingeteilt. Durch die Prioritätsklassen wird ein priorisierter Download nach bestimmten Kriterien geschaffen, durch den sichergestellt wird, dass dringend benötigte Chunks, beispielsweise Chunks nahe am aktuellen Abspielzeitpunkt des Videos, schneller und mit höheren Datenraten bearbeitet werden als nicht so dringend benötigte Chunks, beispielsweise solche Chunks, welche zur permanenten Bereitstellung für andere Knoten herunter geladen werden. Um Anfragen nach höher priorisierten Chunks zu bedienen, können auch bereits laufende Datentransfers mit niedriger Priorität pausiert oder ganz abgebrochen werden.
Um die Abspielverzögerung so klein wie möglich zu halten, kann gegebenenfalls auch die Qualität der herunter zu ladenden Chunks adaptiert werden. Insbesondere können Chunks nahe am Abspielzeitpunkt in niedriger Qualität und damit deutlich schneller herunter geladen und abgespielt werden als Chunks mit größerem zeitlichem Abstand zum Abspielzeitpunkt. Eine Qualitätsanpassung sollte insbesondere dann vorgenommen werden, wenn durch den Streaming-Knoten noch kein Puffer aufgebaut wurde. Mit steigendem Puffer kann dann die Qualität der herunter zu ladenden Chunks langsam erhöht und die Abspielrate maximiert werden. Im Folgen den wird dargelegt, wie in der hier beschriebenen Ausführungsform der Erfindung die Chunks in Prioritätsklassen mit Prioritäten 1 bis 5 eingeteilt werden und durch welche Eigenschaften und Bedeutungen sich diese Prioritäten auszeichnen. Die Prioritätsnummern wurden dabei derart gewählt, dass die Priorität eines Chunks umso höher ist, je kleiner die entsprechende Prioritätsnummer ist.
Priorität 1:
Diese Priorität gilt für den gesamten Chunk, der mit dem aktuellen Abspielzeitpunkt des Videos übereinstimmt, jedoch noch nicht herunter geladen wurde und zum unmittelbaren Abspielen benötigt wird. Das heißt, das Abspielen ist momentan unterbrochen. Die Zeit zum Herunterladen dieses Chunks entspricht also der Abspielverzögerung und muss so klein wie möglich sein. Die Anzahl der Chunks mit Priorität 1 ist pro Streaming-Knoten auf genau einen Chunk limitiert. Gegebenenfalls kann der Chunk auf mehrere parallele Downloads aufgeteilt werden. Es werden dabei die maximal möglichen Datenraten von Quelle und Senke ausgeschöpft.
Priorität 2:
Diese Priorität gilt für die Chunks direkt hinter dem Abspielzeitpunkt, und zwar bis zu demjenigen Chunk, der das Ende des Download-Fensters W markiert, welches in 2 verdeutlicht ist. Die Größe des diesem Download-Fenster entsprechenden Puffers wird dabei aus Test- und Erfahrungswerten abgeleitet und sollte folgende Kriterien erfüllen: Ein Knoten mit einem Puffer der Größe des Streaming-Fensters sollte fehlerfrei streamen, wenn er nur mit Priorität 1 und 2 arbeiten würde. Diese beiden Prioritäten dürfen jedoch nur verwendet werden, um einen schnellen Beginn und danach ein stabiles Abspielen des Streams zu garantieren. Chunks mit Priorität 1 oder 2 treten insbesondere beim Neustart oder bei einem Sprung im Stream auf, bei dem der Puffer komplett neu aufgebaut werden muss. Diese Situationen sind durch den Nutzer des Streaming-Knotens hervorgerufen und können deshalb auch nicht vorhergesehen werden. Damit nicht pausenlos diese hohen Prioritäten verwendet werden und sie damit ihre Wirksamkeit verlieren, muss es noch weitere Prioritäten für den normalen Datentransfer geben, welche im Folgenden erläutert werden.
Priorität 3:
Diese Priorität ist die Standardpriorität der Knoten, bei denen der Puffer gemäß dem Streaming-Fenster W der 2 komplett gefüllt ist. Sie wird für die Chunks verwendet, die zum Auffüllen des Puffers von der minimalen, durch das Streaming-Fenster vorgegebenen Größe bis zu einer maximalen Größe notwendig sind. Die maximale Größe wird dabei in geeigneter Weise derart festgelegt, dass Chunks mit der Priorität 3 im Schritt mit genauso viel Datenrate geliefert werden wie das Abspielen in Anspruch nimmt. Dabei können die Knoten sehr variabel je nach Auslastung die Datenraten variieren lassen und damit den Puffer bis zur maximalen Größe effektiv ausnutzen. Es ist wünschenswert, nach dem Starten des Streams möglichst schnell in diese Klasse zu gelangen und dort zu bleiben. Die Download-Geschwindigkeit wird dabei möglichst maximiert, es sollte jedoch noch Platz für weitere Datentransfers vorhanden sein.
Priorität 4:
Diese Priorität wird zum Herunterladen der permanent zum Download für andere Knoten zur Verfügung stehenden Chunks eingesetzt. Die Priorität ist entsprechend niedriger, da das Herunterladen der Chunks zur permanenten Replikation komplett zeitunkritisch ist. Sie ist jedoch noch wichtiger als ein normaler Dateitransfer, da auf die permanente Replikation möglichst schnell wieder Knoten zugreifen können sollen. Die Raten bestimmen sich aus den im Moment frei verfügbaren Kapazitäten, schwanken also sehr stark mit der Auslastung und werden häufig unterbrochen.
Priorität 5:
Diese Priorität entspricht einem normalen Dateitransfer. Hierdurch soll ermöglicht werden, dass eine Videodatei nicht sofort als Stream abgespielt wird, sondern lediglich aufgenommen wird. Der Download ist also hier ebenfalls komplett zeitunkritisch. Die Chunks werden demnach nicht der Reihenfolge nach über ein Streaming-Fenster ausgewählt, sondern beliebig nach den verfügbaren Kapazitäten gewählt. Wenn sich der Nutzer des Streaming-Knotens doch noch dazu entschließt, den Stream frühzeitig zu starten, wird ihm mitgeteilt, dass es in diesem Fall keine Garantie des fehlerfreien Abspielens gibt. Die Datenraten für die Priorität 5 bestimmen sich einzig und allein aus den noch freien Kapazitäten der verschiedenen Knoten. Der Streaming-Knoten sendet also seine Wünsche an die verschiedenen Download-Quellen aller Chunks. Diese antworten zwar, warten mit dem Dateitransfer jedoch solange, bis sie freie ungenutzte Kapazitäten zur Verfügung haben. Damit keine Nachrichtenflut entsteht, wird die erlaubte Anzahl an Anfragen zum Herunterladen von Chunks mit Priorität 5 zeitlich begrenzt. Es werden mit dieser Methode freie Kapazitäten nutzbar gemacht, denn der aufnehmende Knoten stellt die komplett geladenen Chunks später selbst zur Verfügung. Dann kann man auch mit höheren Prioritäten darauf zugreifen. Nach der Aufnahme des Chunks gehört dieser Knoten zu denen, die das Video komplett besitzen. Der Download von Chunks mit der Priorität 5 sollte also zur Stabilisierung des Netzes beitragen, da Knoten, welche eine Videodatei mit Priorität 5 herunter laden, in der Regel mehr zum Netz beitragen als sie Last verursachen. Außerdem wird es hierdurch auch Knoten mit geringen Ressourcen und Datenraten ermöglicht, sich ein entsprechendes Video aus dem Netz herunterzuladen.
Durch eine Verminderung der Qualität von herunter zu ladenden Chunks mit hoher Priorität, insbesondere mit Priorität 1 und 2, kann die Abspielverzögerung eines Videos verkürzt werden und der Pufferaufbau beschleunigt werden. Hierdurch wird erreicht, dass ein Nutzer, der ein Video herunter laden möchte, nicht sehr lange auf das Abspielen des Videos warten muss. Dafür nimmt er zwar eine schlechtere Qualität in Kauf, die jedoch sehr schnell nach dem Start ihr Optimum erreicht. Die Qualität des Videos wird vorzugsweise durch die Priorität folgendermaßen beeinflusst:

– Alle Knoten, die einen Chunk mit Priorität 1 herunter laden, wählen nur Atonks aus dem Chunk aus, die für eine minimale Qualität nötig sind. Dadurch wird der Chunk schneller abspielbar, die Qualität ist jedoch niedriger als beim Herunterladen aller Atonks aus dem Chunk.
– Ähnliches gilt für Chunks mit der Priorität 2. Allerdings entscheidet hierbei der Zeitpunkt, zu dem der Chunk benötigt wird, darüber, welche Qualität benutzt wird. An dem Chunk wird solange geladen, bis er entweder komplettiert wurde oder die Priorität auf 1 übergeht. Im zweiten Fall wird der Chunk sofort abgespielt, vorausgesetzt, dass die Atonks für die minimale Qualität verfügbar sind.
– Bei der Priorität 3 hängt die Qualität der Chunks von der durchschnittlichen Downloadrate ab. Diese wiederum hängt von den möglichen Raten der Quellen und des Empfängers ab. Da die heutigen Internetanbindungen sehr stark asynchron sind, wird voraussichtlich der Upload, also die Datenrate der Quelle, das die Qualität bestimmende Kriterium sein.
– Bei Downloads mit Priorität 4 und 5 werden die Chunks in voller Größe herunter geladen. Es wird solange gewartet, bis alle Atonks komplett herunter geladen sind.

Weiterhin beeinflussen die Prioritäten auch die Wahl der Quellen. Vorzugsweise werden deshalb sehr zeitkritische Anfragen verstärkt an diejenigen Knoten gestellt, welche die Chunks mit Sicherheit besitzen, d. h. welche als Einträge in der PeRL-Liste des entsprechenden Chord-Knotens hinterlegt sind. Es sind hierbei folgende Kriterien denkbar, wie die Download-Quellen in Abhängigkeit von den oben dargelegten Prioritäten ausgewählt werden:

– Bei Anfragen nach Chunks mit Priorität 1 werden zuerst die Knoten aus der PeRL-Liste befragt. Sollten diese überlastet sein, kann man immer noch auf die Knoten aus der PaRL-Liste wechseln. Im Normalfall werden dadurch kürzere Antwortzeiten ermöglicht. Da die gewünschten Atonks mit Sicherheit vorhanden sind, können sie auch mit Sicherheit akzeptiert werden. Da sie ferner die höchste Priorität besitzen, werden sie mit hoher Wahrscheinlichkeit auch sofort bedient werden. Der Knoten muss die Anfragen somit nicht erneut an andere Quellknoten versenden und spart somit Zeit.
– Ähnliches gilt für den Download von Chunks mit Priorität 2. Hier wird jedoch zunächst versucht, möglichst viele Atonks aus der PaRL-Liste zu holen. Erst nach Ablauf einer gewissen Zeit werden für die noch fehlenden Atonks die Knoten aus der PeRL-Liste verwendet.
– Bei den weniger wichtigen Prioritäten wird versucht, die PeRL-Knoten so gut wie möglich zu entlasten.

Eine Anfrage nach einem Chunk wird in der hier beschriebenen Ausführungsform des erfindungsgemäßen Verfahrens redundant an verschiedene Download-Quellen gleichzeitig ausgesendet. Das heißt, je nach Priorität können auch mehrere Anfragen nach ein und demselben Atonk an mehrere unterschiedliche Quellen gesendet werden. Für den Fall von singulären Downloads wird dann pro Chunk nur diejenige Quelle verwendet, welche die höchste Kapazität verspricht. Im Falle von multiplen Downloads werden pro Chunk und Typ alle Quellen verwendet, welche die Anfrage akzeptiert haben. Bei den Prioritäten 3, 4 und 5 benötigt man nicht unbedingt redundante Anfragen, da dem Knoten genug Zeit zum Warten bleibt.
Nachdem eine Quelle zum Herunterladen eines Atonks gefunden wurde und die Quelle eine Anfrage des Streaming-Knotens für einen Download akzeptiert hat, kann der Download initiiert werden. Der Download erfolgt abhängig von den Gegebenheiten der am Download beteiligten Knoten auf unterschiedliche Weise.
Im Normalfall werden die Daten des Videos von der Quelle zum Empfänger ohne „Hand-Shake” über UDP übertragen. Wenn der Empfänger hinter einer Firewall/NAT agiert, wird der Transfer mit TCP gelöst. Das heißt, der Streaming-Knoten öffnet dann die Datenverbindung und damit einen Port in der Firewall. Kommt auf eine Download-Anfrage keine Antwort zurück, wird nach Ablauf eines Timers erneut nach einer anderen Quelle gesucht. Das Problem, Verbindungen in Peer-to-Peer-Netzen auch mit Knoten zu ermöglichen, die sich hinter Barrieren befinden, ist inzwischen durch bekannte Mechanismen sehr gut gelöst. Diese Mechanismen kön nen auch in der hier beschriebenen Ausführungsform zum Download von Knoten hinter Firewalls eingesetzt werden.
Der bevorzugte Anwendungsfall des hier beschriebenen Verfahrens ist das Streamen des Videos, d. h. das Abspielen des Videos parallel zum Herunterladen. Zum Abspielen wird dabei der entsprechende Chunk, der komplett herunter geladen wird, decodiert, wobei hierzu zunächst eine Kopie des Chunks erstellt wird, denn das Original dient anderen Knoten weiterhin als Quelle. Mit einem geeigneten Medienplayer wird dann die decodierte Datei abgespielt, wobei dem Medienplayer als Quelle die lokal gespeicherte Mediendatei angegeben wird. Dem Medienplayer ist dabei nicht bekannt, wie die Daten an diese Stelle kommen. Für den Player scheint es so, als enthielte die Mediendatei an dieser Stelle bereits den gesamten Stream. Auf diese Weise lassen sich alle Video-on-Demand-Funktionen wie Vorspulen oder Springen realisieren. Ist der gewünschte Teil des Videos noch nicht vorhanden, wird eine entsprechende Anfrage des Medienplayers zuvor abgefangen und in die gewünschte Chunk-Nummer umgesetzt, welche dann aus dem Netz so schnell wie möglich herunter geladen, lokal decodiert und in die abzuspielende Mediendatei integriert wird, so dass der Medienplayer sie dann abspielen kann. Der Medienplayer wartet solange. Anschließend füllt er seinerseits einen Streaming-Puffer, den er zum flüssigen Abspielen benötigt. Der soeben beschriebene Mechanismus erlaubt den Einsatz von verbreiteten Medienplayern zum Abspielen von mit dem erfindungsgemäßen Verfahren gestreamten Mediendateien.
Das soeben beschriebene Verfahren weist eine Reihe von Vorteilen auf. Mit dem Verfahren wird eine Verteilplattform von Medieninhalten für verschiedenste Anbieter geschaffen, wobei insbesondere ein Video-on-Demand-Streaming ermöglicht wird. Das Verfahren basiert dabei auf der Implementierung einer dezentralen Struktur für jedes Video, wobei einzelne Abschnitte eines Videos auf verschiedene Knoten der Struktur verteilt werden, so dass sie von verschiedenen Rechnern im Netz herunter geladen werden können. Das System kümmert sich dabei im Hintergrund darum, dass eine Mediendatei beim Streamen ohne Stoppen abgespielt werden kann. Das Verfahren ermöglicht die Implementierung sowohl von Video-on-Demand als auch von Videorecorder-Funktionen. Es ist dabei keine zentrale Einheit mehr notwendig, um die Verwaltung oder Bereitstellung des Videoaustausches zu organisieren. Darüber hinaus beteiligt sich jeder Knoten, der Medieninhalte herunter lädt, gleichzeitig auch an der Verteilung der Medieninhalte im Netz bzw. gegebenenfalls auch an der Verwaltung des Videos in einer dezentralen Struktur.
Das erfindungsgemäße Verfahren kann in verschiedensten Anwendungsbereichen eingesetzt werden. Beispielsweise können mit dem Verfahren kostenlose oder Bezahl-Video-Dienste angeboten werden und Unternehmen können gegebenenfalls auch kostenlos selbst produziertes Medienmaterial zur Verbreitung im Markt bereitstellen. Ebenso kann das Verfahren gegebenenfalls auch durch Privatanwender genutzt werden, welche eigenes Videomaterial per Streaming in das Datennetz stellen möchten.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

- W.-P. K. Yiu, X. Jin und S.-H. G. Chan, „Distributed Storage to Support User Interactivity in Peer-to-Peer Video Streaming”, IEEE ICC '06, 2006 [0006]

Claims

Verfahren zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten (K1, ..., K8, K', K'') in einem Datennetz, wobei die Medieninhalte eine oder mehrere Mediendateien (VF) umfassen und die Knoten (K1, ..., K8, K', K'') über Adressen in dem Datennetz adressierbar sind, bei dem: – für jede im Datennetz bereitzustellende Mediendatei (VF) eine dezentrale, über einen oder mehrere erste Knoten (K1, ..., K8) verwaltete Struktur (R) dadurch gebildet wird, dass die jeweilige Mediendatei (VF) in eine Mehrzahl von Abschnitten (C) aufgeteilt wird und den Abschnitten (C) jeweils ein Identitätswert (0, ..., 31) aus einem Identitätsintervall umfassend aufeinander folgende Identitätswerte (0, ..., 31) zugeordnet wird, wobei der oder die ersten Knoten (K1, ..., K8) jeweils für ein Teilintervall aus dem Identitätsintervall und hierdurch für eine Teilmenge an Abschnitten (C) aus der jeweiligen Mediendatei (VF) zuständig sind; – in einem jeweiligen ersten Knoten (K1, ..., K8) der dezentralen Struktur (R) eine Anzahl von zweiten Knoten (K', K'') mit deren Adressen hinterlegt wird, wobei der oder die zweiten Knoten (K', K'') zum Bereitstellen der Abschnitte (C) gemäß dem Teilintervall, für das der jeweilige erste Knoten (K1, ..., K8) zuständig ist, vorgesehen sind; – ein Empfangsknoten (SK), der zum Herunterladen zumindest eines Teils einer jeweiligen Mediendatei (VF) vorgesehen ist, mittels einer oder mehrerer Anfragen an die ersten Knoten (K1, ..., K8) in der dezentralen Struktur (R) der Mediendatei (VF) die Adressen von zweiten Knoten (K', K'') umfassend zumindest einen Teil derjenigen zweiten Knoten (K', K'') abruft, welche zum Bereitstellen der Abschnitte (C) des zumindest einen Teils der Mediendatei (VF) vorgesehen sind, und Abschnitte (C) umfassend die Abschnitte (C) des zumindest einen Teils der Mediendatei (VF) von zumindest einem Teil der zweiten Knoten (K', K''), deren Adressen abgerufen wurden, herunter lädt.
Verfahren nach Anspruch 1, bei dem eine jeweilige Mediendatei (VF) einen abspielbaren Medienstrom, insbesondere einen Audio- und/oder Videostrom, enthält und die Abschnitte (C) der Mediendatei (VF) zeitlich aufeinander folgende Abschnitte (C) des Medienstroms sind, wobei die Identitätswerte (0, ..., 31) des Identitätsintervalls in Abspielreihenfolge des Medienstroms den Abschnitten (C) zugeordnet werden, so dass ein höherer Identitätswert (0, ..., 31) einem später abgespielten Abschnitt (C) im Medienstrom entspricht.
Verfahren nach Anspruch 2, bei dem ein Empfangsknoten (SK) parallel zum Herunterladen die herunter geladenen Abschnitte (C) des Medienstroms abspielt.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die dezentrale Struktur (R) eine Ringstruktur ist und/oder über ein Peer-To-Peer-Protokoll verwaltet wird, wobei für die jeweilige Mediendatei (VF) insbesondere ein Chord-Ring gebildet wird.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem ein Empfangsknoten (SK) ein oder mehrere der von ihm herunter geladenen Abschnitte (C) anderen Knoten dadurch bereitstellt, dass er mit seiner Adresse als zweiter Knoten (K', K'') in den entsprechenden ersten Knoten (K1, ..., K8), welche für die vom Empfangsknoten (SK) herunter geladenen Abschnitte (C) zuständig sind, hinterlegt wird.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Anzahl von in einem jeweiligen ersten Knoten (K1, ..., K8) hinterlegten zweiten Knoten (K', K'') in anderen ersten Knoten (K1, ..., K8) repliziert wird, insbesondere zumindest in einem Nachbarknoten, welcher für ein Teilintervall zuständig ist, das sich an das Teilintervall anschließt, für das der jeweilige erste Knoten (K1, ..., K8) zuständig ist.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Anzahl von in einem jeweiligen ersten Knoten (K1, ..., K8) hinterlegten zweiten Knoten (K', K'') in der Form von einer oder mehreren Listen (PeRL, PaRL) hinterlegt wird.
Verfahren nach Anspruch 7, bei dem das oder die Listen in einem jeweiligen ersten Knoten (K1, ..., K8) eine oder mehrere erste und/oder zweite Listen (PeRL, PaRL) umfassen, wobei – eine erste Liste (PeRL) zweite Knoten (K') mit permanent zum Herunterladen durch andere Knoten verfügbaren Abschnitten enthält, wobei die Verfügbarkeit des jeweiligen zweiten Knotens (K') durch regelmäßigen Nachrichtenaustausch des zweiten Knotens (K') mit dem jeweiligen ersten Knoten (K1, ..., K8) überprüft wird; – eine zweite Liste (PaRL) diejenigen Knoten (K'') umfasst, welche bei dem jeweiligen ersten Knoten (K1, ..., K8) innerhalb eines vorbestimmten zurückliegenden Zeitraums Adressen von zweiten Knoten (K', K'') abgerufen haben.
Verfahren nach Anspruch 8, bei dem ein Empfangsknoten (SK) Abschnitte (C) von zweiten Knoten (K', K'') aus der ersten und/oder zweiten Liste (PeRL, PaRL) zur Bereitstellung als permanent verfügbare Abschnitte (C) herunter lädt, wobei die herunter zu ladenden Abschnitte (C) nach einem oder mehreren vorbestimmte Kriterien, insbesondere zufällig, ausgewählt werden.
Verfahren nach Anspruch 8 oder 9, wenn abhängig von Anspruch 3, bei dem zweite Knoten (K', K'') aus der ersten Liste (PeRL) umso stärker zum Herunterladen eines abzuspielenden Abschnitts (C) durch den Empfangsknoten (SK) bevorzugt werden, je näher der abzuspielende Abschnitt (C) am aktuellen Abspielzeitpunkt der Mediendatei (VF) liegt.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem ein Empfangsknoten (SK) in Abhängigkeit von einem oder mehreren Kriterien als erster Knoten (K1, ..., K8) in die dezentrale Struktur (R) einer jeweiligen Mediendatei (VF) dadurch aufgenommen wird, dass dem Empfangsknoten (SK) die Zuständigkeit für ein Teilintervall aus dem Identitätsintervall zugewiesen wird.
Verfahren nach Anspruch 11, bei dem das oder die Kriterien derart ausgestaltet sind, dass für einen Empfangsknoten (SK) eine Maximalanzahl von Malen nach einem Teilintervall des Identitätsintervalls gesucht wird, dessen Zuständigkeit ein neuer Knoten in der dezentralen Struktur (R) übernehmen kann, wobei im Falle, dass kein Teilintervall nach der Maximalanzahl von Malen gefunden wird, der Empfangsknoten (SK) nicht als erster Knoten (K1, ..., K8) in die dezentrale Struktur (R) aufgenommen wird.
Verfahren nach Anspruch 11 oder 12, bei dem gemäß dem oder den Kriterien nur solche Empfangsknoten (SK) in die dezentrale Struktur (R) aufgenommen werden, welche eine vorbestimmte Mindestgröße an Ressourcen bereitstellen können.
Verfahren nach einem der Ansprüche 11 bis 13, wobei dem in die dezentrale Struktur (R) aufzunehmenden Empfangsknoten (SK) zufällig oder nach einem vorbestimmen Muster eine Zuständigkeit für ein Teilintervall zugewiesen wird, wobei das vorbestimmte Muster insbesondere derart ausgestaltet ist, dass für Abschnitte (C) mit kleinen Identitätswerten (0, ..., 31) mehr erste Knoten (K1, ..., K8) zuständig sind als für Abschnitte mit größeren Identitätswerten (0, ..., 31).
Verfahren nach einem der vorhergehenden Ansprüche, bei dem in der dezentralen Struktur (R) ein jeweiliger erster Knoten (K1, ..., K8) den Nachbarknoten kennt, welcher für ein Teilintervall zuständig ist, das sich an das Teilintervall, für das der jeweilige erste Knoten (K1, ..., K8) zuständig ist, in Richtung hin zu höheren Identitätswerten (0, ..., 31) anschließt, wobei die Adresse des Nachbarknotens durch den jeweiligen ersten Knoten (K1, ..., K8) bei einem Abruf der Adressen der zweiten Knoten (K', K'') an den Empfangsknoten (SK) übermittelt wird.
Verfahren nach Anspruch 15, bei dem der jeweilige erste Knoten (K1, ..., K8) über weitere Informationen über den Nachbarknoten verfügt, welche neben der Adresse des Nachbarknotens an den Empfangskoten (SK) übermittelt werden und aus denen der Empfangsknoten (SK) das Teilintervall ermittelt, für das der Nachbarknoten zuständig ist.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Abschnitte (C) durch einen Empfangsknoten (SK) in Abhängigkeit von einer oder mehreren, für die Abschnitte (C) vergebenen Prioritäten herunter geladen werden, wobei Abschnitte (C) mit höheren Prioritäten beim Herunterladen bevorzugt werden.
Verfahren nach Anspruch 17, wenn abhängig von Anspruch 3, bei dem für einen Empfangsknoten (SK) ein erstes Zeitintervall (W) vorgegeben ist, wobei der Empfangsknoten (SK) ausgehend von seinem aktuellen Abspielzeitpunkt (Z) des Medienstroms Abschnitte (C), welche im abgespielten Medienstrom in dem ersten Zeitintervall (W) nach dem aktuellen Abspielzeitpunkt (Z) liegen, mit höherer Priorität als andere Abschnitte herunter lädt.
Verfahren nach Anspruch 18, bei dem Abschnitte (C) innerhalb des ersten Zeitintervalls (W), welche den aktuellen Abspielzeitpunkt enthalten, mit höherer Priorität als die anderen Abschnitte (Z) im ersten Zeitintervall (W) herunter geladen werden.
Verfahren nach Anspruch 18 oder 19, bei dem für einen Empfangsknoten (SK) ein zweites Zeitintervall vorgegeben ist, welches größer als das erste Zeitinter vall (W) ist, wobei der Empfangsknoten (SK) ausgehend von seinem aktuellen Abspielzeitpunkt (Z) des Medienstroms Abschnitte, welche im abgespielten Medienstrom in dem zweiten Zeitintervall nach dem aktuellen Abspielzeitpunkt (Z) und außerhalb des ersten Zeitintervalls (W) liegen, mit niedrigerer Priorität als die Abschnitte innerhalb des ersten Zeitintervalls (W) herunter lädt.
Verfahren nach Anspruch 20, wenn abhängig von Anspruch 7, bei dem ein Empfangsknoten (SK) Abschnitte (C) zur Bereitstellung als permanent verfügbare Abschnitte (C) mit niedrigerer Priorität als die Abschnitte (C) aus dem ersten oder zweiten Zeitintervall nach dem aktuellen Abspielzeitpunkt (Z) herunter lädt.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Abschnitte (C) einer jeweiligen Mediendatei (VF) jeweils in kleinere Teilabschnitte (AT) aufgeteilt sind.
Verfahren nach Anspruch 22, bei dem bei Herunterladen eines Abschnitts (C) der gesamte Abschnitt (C) oder eine Auswahl von Teilabschnitten (AT) aus dem Abschnitt (C) herunter geladen wird.
Verfahren nach Anspruch 22 oder 23, bei dem die Teilabschnitte (AT) aller Abschnitte (C) einer jeweiligen Mediendatei (VF) in mehrere Kanäle gruppiert sind, welche verschiedene Qualitätsstufen der Mediendatei (VF) repräsentieren.
Verfahren nach einem der Ansprüche 22 bis 24, bei dem ein Empfangsknoten (SK) Informationen über die Teilabschnitte (AT), insbesondere hinsichtlich der Zuordnung der Teilabschnitte (AT) zu Qualitätsstufen, aus einer Informationsdatei (AM) ausliest.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem Informationen zu einer jeweiligen Mediendatei (VF) in einem Meta-Container bereitgestellt werden, welcher von einem Empfangsknoten (SK) herunter geladen werden kann.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem eine Mehrzahl von Mediendateien (VF) über eine suchbaren Index im Datennetz bereitgestellt werden, wobei für jeden Index zumindest ein Teil der Adressen der ersten Knoten (K1, ..., K8) der für die jeweilige Mediendatei (VF) gebildeten dezentralen Struktur (R) hinterlegt ist.
System zum Bereitstellen von Medieninhalten für eine Mehrzahl von Knoten (K1, ..., K8, K', K'') in einem Datennetz, wobei die Medieninhalte eine oder mehrere Mediendateien (VF) umfassen und die Knoten (K1, ..., K8, K', K'') über Adressen in dem Datennetz adressierbar sind, wobei das System die Mehrzahl von Knoten (K1, ..., K8, K', K'') derart verwaltet, dass: – für jede im Datennetz bereitzustellende Mediendatei (VF) separat eine dezentrale, über einen oder mehrere erste Knoten (K1, ..., K8) verwaltete Struktur (R) dadurch gebildet wird, dass die jeweilige Mediendatei (VF) in eine Mehrzahl von Abschnitten (C) aufgeteilt wird und den Abschnitten (C) jeweils ein Identitätswert (0, ..., 31) aus einem Identitätsintervall umfassend aufeinander folgende Identitätswerte (0, ..., 31) zugeordnet wird, wobei der oder die ersten Knoten (K1, ..., K8) jeweils für ein Teilintervall aus dem Identitätsintervall und hierdurch für eine Teilmenge an Abschnitten (C) aus der jeweiligen Mediendatei (VF) zuständig sind; – in einem jeweiligen ersten Knoten (K1, ..., K8) der dezentralen Struktur (R) eine Anzahl von zweiten Knoten (K', K'') mit deren Adressen hinterlegt wird, wobei der oder die zweiten Knoten (K', K'') zum Bereitstellen der Abschnitte (C) gemäß dem Teilintervall, für das der jeweilige erste Knoten (K1, ..., K8) zuständig ist, vorgesehen sind; – ein Empfangsknoten (SK), der zum Herunterladen zumindest eines Teils einer jeweiligen Mediendatei (VF) vorgesehen ist, mittels einer oder mehrerer Anfragen an die ersten Knoten (K1, ..., K8) in der dezentralen Struktur (R) der jeweiligen Mediendatei (VF) die Adressen von zweiten Knoten (K', K'') umfassend zumindest einen Teil derjenigen zweiten Knoten (K', K'') abruft, welche zum Bereitstellen der Abschnitte (C) des zumindest einen Teils der Mediendatei (VF) vorgesehen sind, und Abschnitte (C) umfassend die Abschnitte (C) des zumindest einen Teils der Mediendatei (VF) von zumindest einem Teil der zweiten Knoten (K', K''), deren Adressen abgerufen wurden, herunter lädt.
System nach Anspruch 28, welches derart ausgestaltet ist, dass mit dem System ein Verfahren nach einem der Ansprüche 1 bis 25 durchführbar ist.
Knoten zur Verwendung in einem Verfahren nach einem der Ansprüche 1 bis 27, wobei der Knoten (K1, ..., K8, K', K'') derart ausgestaltet ist, dass er bei Betrieb in dem Verfahren als erster Knoten (K1, ..., K8) oder als zweiter Knoten (K', K'') oder als Empfangsknoten fungiert.