Das Peer-to-Peer Videosystem - Die Architektur


In Kapitel 2 wurde ein Video-on-demand System vorgestellt, auf welchem aktuelle Systeme basieren. Dabei beziehen alle Clients ihre Multimediadatei direkt von ein und demselben Server. Bei einem Peer-to-Peer Videosystem ist dieses nicht der Fall. In diesem System sind die Clients selber für die Verteilung der Dateien zuständig. Zuerst fragt ein Client bei einem Multimediaserver nach einer bestimmten Datei an und bezieht die Datei auch direkt von diesem Server. Fragt nun ein weiterer Client genau nach dieser Datei beim Multimediaserver an, dann wird er an den Client weitergeleitet, der die Datei bereits erhalten hat. Es ist nun dessen Aufgabe, die Datei weiter zu geben. Dadurch entsteht jedesmal eine Kette, wie es in Abbildung 23 gezeigt wird.


Abbildung 23 Beispiel eines Peer-to-Peer Videosystems



Damit ein Client auch die nötigen Informationen erhält, damit er seine Datei von einem anderen Client beziehen kann, wird in das System noch ein Verzeichnisserver integriert. Dieser verwaltet intern, welcher Client im Besitz welcher Multimediadatei ist. Ein Client fragt also bei diesem Verzeichnisserver an und wird dementsprechend umgeleitet. Jeder Client muß in der Lage sein, die Dateien lokal auf einer Festplatte abzuspeichern und auch wieder weiterzugeben, er wird dadurch selbst zu einem Server.

Das System besteht also aus drei Komponenten:



Da nun die Clients für die Verteilung der Filme zuständig sind, kommt es zu einer erheblichen Entlastung der Server. Im Idealfall greift nur genau ein Client auf einen Server zu. Wenn ein Server in der Kette ausfällt, gibt es noch genügend andere Server, welche den Client versorgen können.


Abbildung 24 Ein Server in der Kette fällt aus



Die Ressourcen der einzelnen Clients werden auch besser ausgenutzt. Jeder durchschnittliche PC ist in der Lage eine Multimediadatei zu präsentieren und auf Grund der enorm gestiegenen Kapazität von Festplatten auch lokal abzuspeichern. Da der Client auch nur für wenige andere Clients zur selben Zeit als Server dienen soll, bildet auch durch die Übertragung der Datei kein Hindernis, dieses kann ein normaler PC ohne größere Probleme bewerkstelligen.

Im folgenden Kapitel werden alle drei Komponenten und ihre Funktionsweise und Aufgaben beschrieben. Der Multimediaserver, der in Abbildung.23 gezeigt wird, soll als Ausgangspunkt gesehen werden. Er ist nur für die Einspeisung von neuen Dateien in das Netzwerk zuständig.


Die Aufgabe des Clients


Jeder Client kennt die Adresse eines oder mehrerer Verzeichnisserver im Netzwerk. Die Adressen von Verzeichnisserver können auf einer Webseite angekündigt werden. Handelt es sich um ein kleines oder geschlossenes Netzwerk, kann die Adresse der Verzeichnisserver auch fest vorgegeben werden (siehe Kapitel 5.5 auf Seite 56). Der Client braucht nicht ständigen Kontakt zum Verzeichnisserver halten, dieses würde nur den Netzwerkehr unnötig erhöhen. Es reicht, wenn in einem bestimmten Intervall untersucht wird, ob die Verzeichnisserver noch existieren.



Abbildung 25 Ein Client hält losen Kontakt zu mehreren Verzeichnisservern



Der Verzeichnisserver ist dafür zuständig die Clients auf Anfrage nach einer Datei an einen Server zu verweisen. Der Verzeichnisserver besitzt eine Datenbank, in welcher alle dafür nötigen Informationen stehen. Mit Hilfe dieser Datenbank werden dem Client die Daten zugeschickt, die der Client benötigt, um Kontakt zu einem Server aufzunehmen. Zur Kontaktaufnahme ist der Client auf die Netzwerkadresse des Servers angewiesen. Wenn daraufhin die Verbindungsaufnahme zum Server erfolgreich ist, kann die Übertragung der Datei beginnen. Abbildung 26 und Tabelle 5 sollen den Ablauf einer Anfrage skizzieren.


Tabelle 5 Erläuterungen zu Abbildung 26

1

Ein Client fragt beim Verzeichnisserver nach einer Datei

2

Der Verzeichnisserver sucht aus seiner Datenbank den passenden Eintrag

3

Der Verzeichnisserver sendet dem Client die gewünschte Information zu

4

Der Client kennt nun eine Server im Netz, der die angeforderte Datei besitzt und baut zu diesem eine Verbindung auf

5

Der Server schickt an den Client die angeforderte Datei




Abbildung 26 Die Anfrage eines Clients



Während der Client die Multimediadatei erhält, hat er die Aufgabe, die Datei zu präsentieren und gleichzeitig muß er die Datei auf einer lokale Festplatte abspeichern. Dieses ist die Grundvoraussetzung dafür, daß dieser Client zum Server für andere Teilnehmer im Netzwerk werden kann.



Abbildung 27 Die Aufgabe des Clients



Die Fähigkeiten eines Servers


Der Server hat im Netzwerk genau eine Aufgabe und das ist die Weitergabe von Dateien. Da es sich um ein Multimedianetzwerk handeln soll, sind an den Transport der Daten spezielle Anforderungen gestellt. Es ist zwingend erforderlich, daß die Daten in Echtzeit ausgeliefert werden. Vorzugsweise soll die Streamingtechnologie zum Einsatz kommen, dabei ist es unerheblich, ob nun das FastStart oder das RealTime Verfahren benutzt werden. Der Server muß im Besitz von Informationen über die verfügbaren Dateien, die sich auf seiner lokalen Festplatte befinden, sein. Wie bereits beschrieben, ist der Verzeichnisserver für die Weitergabe von Informationen an die Clients zuständig, also muß der Server seine Informationen an den Verzeichnisserver weitergeben. Dafür stehen zwei Möglichkeiten zur Verfügung:


  1. Erst auf Anfrage eines Verzeichnisservers werden die Informationen übermittelt. Der Verzeichnisserver cacht diese Informationen dann, um weitere Anfragen schneller zu beantworten. Dieses hat den Nachteil, daß jeder Server losen Kontakt zu einem oder mehreren Verzeichnisservern halten muß und außerdem kann ein hohes Aufkommen an Netzwerkverkehr zu Stande kommen.

  2. Der Server übermittelt einmalig beim Start seine Informationen an den Verzeichnisserver und meldet sich beim Beenden seines Dienstes wieder ab. Dadurch können vom Verzeichnisserver Anfragen schneller beantwortet werden und der Netzwerkverkehr wird auf einem geringen Level gehalten.


Abbildung 28 zeigt den prinzipiellen Ablauf der Informationsübertragung eines Servers an einen Verzeichnisserver. Der Server überträgt dabei eine Liste mit seinen lokal abgespeicherten Dateien. Dieses wird vom Verzeichnisserver in seine lokale Datenbank eingetragen.


Abbildung 28 Server überträgt seine Informationen an einen Verzeichnisserver



Es ist zu überlegen, welche Informationen der Server außer einer Dateiliste noch übertragen sollte. Als sinnvoll können sich dabei die folgenden Punkte erweisen:



Wenn ein Server seinen Dienst beenden möchte, dann meldet er sich vorher bei seinem Verzeichnisserver ab. Dazu nimmt der Server Kontakt zu seinem Verzeichnisserver auf und meldet ihm, daß er den Dienst beenden möchte. Daraufhin löscht der Verzeichnisserver alle Einträge in seiner Datenbank, die zu diesem Server gehören. Durch das An -und Abmelden eines jeden Servers entsteht ein exaktes Bild über die Verfügbarkeit von Dateien im Netzwerk. Selbstverständlich besteht auch die Möglichkeit, daß ein Server seinen Dienst beendet, ohne sich vorher abzumelden. Dieses kann z.B. geschehen, wenn das System abstürzt oder Netzwerkstörungen vorliegen. Um diesem Problem vorzubeugen müßte ein Verzeichnisserver in einem bestimmten Intervall Kontakt zu allen Servern aufzunehmen, die in seiner Datenbank eingetragen sind. Wenn dann ein Server nicht auf diese Anfrage reagiert, wird dieser Server aus der Datenbank gestrichen. Dadurch entsteht wieder ein erhöhter Netzwerkverkehr, allerdings ist der noch immer geringer als wenn jeder Server alle ihm bekannten Verzeichnisserver kontaktiert.



Abbildung 29 Kontaktverbindungen zwischen Verzeichnisservern und Servern



Abbildung 29 veranschaulicht, daß der Netzwerkverkehr geringer ist, wenn die Verzeichnisserver in periodischen Intervallen die Server kontaktieren. Die Anzahl der Verbindungsaufnahmen von Verzeichnisservern zu Servern wird durch die roten, gestrichelten Linien verdeutlicht. Würden die Server Kontakt zu allen ihnen bekannten Verzeichnisservern aufnehmen, dann ist die Anzahl der Netzwerverbindungen die Summe der roten und blauen Linien.


Das Herzstück - DerVerzeichnisserver


Die Aufgaben des Verzeichnisservers wurden bereits in den vorherigen Kapiteln leicht angerissen. Er muß jedem Client an einen Server weiterleiten können und er muß die Informationen, die er von einem Server erhält, intern speichern. Dafür eignet sich am Besten ein relationales Datenbanksystem. Ein Verzeichnisserver ist vergleichbar mit den 'Supernodes' aus Abbildung 19 auf Seite 38. Es ist nicht unbedingt zwingend, daß jeder Verzeichnisserver über eine eigene Datenbank verfügt. Mehrere Verzeichnisserver können gemeinsam auf ein und dieselbe Datenbank zugreifen.



Abbildung 30 Mehrere Verzeichnisserver greifen auf die gleiche Datenbank zu



Das in Abbildung 30 gezeigte Modell erlaubt dem System Ressourcen zu sparen. Dazu kommt noch, daß im laufenden Betrieb die Entscheidung fallen kann, daß ein Teilnehmer die Stellung eines Verzeichnisservers einnehmen soll. Es müßte sich dann bereits auf seinem lokalen System eine Datenbank befinden und da jeder Teilnehmer ein potentieller Kandidat ist, müßte also auf jedem System eine Datenbank installiert sein. Für dieses System sind als Betreiber eines Verzeichnisservers Teilnehmer geeignet, die sich einen relativ langen Zeitraum im Netzwerk befinden. Damit wird verhindert, daß ständig neue Teilnehmer ausgesucht werden müssen, welche den Betrieb eines Verzeichnisservers übernehmen. Beendet ein Verzeichnisserver seinen Betrieb, dann übergibt er einfach seine lokal gespeicherten Informationen an einen anderen Verzeichnisserver. Er muß allerdings allen Servern, die sich bei ihm angemeldet hatten, mitteilen, daß er aus dem Netzwerk aufscheidet und welcher Verzeichnisserver nun für sie verantwortlich ist. Die Weitergabe der Informationen an einen anderen Verzeichnisserver entfällt, wenn das Model in Abbildung 30 gewählt wird.


Es besteht die Möglichkeit, daß ein Verzeichnisserver eine Anfrage eines Clients nicht beantworten kann, da die angeforderte Datei in seiner Datenbank nicht existiert. Es gibt nun zwei Optionen, dieses Problem zu lösen:


  1. Der Client wird an einen anderen Verzeichnisserver weitergeleitet.

  2. Der Verzeichnisserver kommuniziert direkt mit anderen Verzeichnisservern im Netzwerk.



Abbildung 31 Die zwei Möglichkeiten eine Datei im Netzwerk zu finden



Die zweite Option kommt dabei der Kommunikation in einem Peer-to-Peer Netzwerk näher als die erste Option. Es muß bei beiden Optionen darauf geachtet werden, daß sich nicht einen Endlosschleife bildet. Eine Anfrage darf also eine bestimmte Anzahl von Weiterleitungen nicht überschreiten. Für die Kommunikation zwischen den Verzeichnisservern kann entweder ein eigenes Protokoll entworfen werden oder es wird ein bereits vorhandenes eingesetzt. Das Gnutella Protokoll erfüllt für diese Aufgabe alle gestellten Anforderungen (siehe 4.3).


Der Verzeichnisserver sollte einen möglichst kurzen Weg für die Übertragung einer Datei finden. Es ist z.B. unsinnig einem Client, der sich in den USA befindet, einen Server anzubieten, der sich in Europa befindet. Es sollte immer versucht werden, einen Server zu finden, der sich in der Nähe eines Clients befindet. Damit kann auch gleichzeitig verhindert werden, daß während des Transports zu viele Router passiert werden. Der Idealfall würde eintreten, wenn sich Server und Client im selben Subnetz befinden würden.



Abbildung 32 Zwei Server bieten die gleiche Datei an



Selbstverständlich braucht dieses nicht das einzige Kriterium sein. Der kürzeste Weg muß zu einem nicht unbedingt der schnellste Weg durch ein Netzwerk sein. Eine weitere Option wäre einen Pfad zu finden, welcher der kostengünstigste ist.


Der Verzeichnisserver kann auch dafür genutzt werden, um die Echtheit und Unversehrtheit einer Datei festzustellen. Bevor eine Datei zum ersten Mal in das Netzwerk eingespeist wird, wird von dieser Datei mit Hilfe einer Hashfunktion ein eindeutiges Echtheitszertifikat erstellt. Hashfunktionen können für diese Aufgabe benutzt werden, da sie in der Lage sind, Prüfsummen zu erstellen. Diese Prüfsummen müssen zwei wichtigen Kriterien erfüllen:


  1. Es soll unwahrscheinlich sein, daß zwei Datenmengen zufällig die gleiche Prüfsumme haben.

  2. Es soll sehr schwierig sein, zu einer vorgegebenen Prüfsumme eine entsprechende Datei zu finden. Diese muß auch gelten, wenn der Algorithmus, mit welcher die Prüfsumme erzeugt wurde, bekannt ist.


Jeder einzelne Server im Netzwerk erstellt einfach von jeder ihm vorliegenden Datei eine Prüfsumme und überträgt diese an seinen Verzeichnisserver. Der vergleicht diesen Wert dann einfach mit dem Ausgangswert und kann dann entscheiden, ob diese Datei verwendbar ist. Beispielsweise kann der MD5 Algorithmus implementiert werden. MD5 ist ein sogenannte 'komplexe one-way-Hashfunktion'.


Diese Problematik ist nicht zu unterschätzen, da viele Peer-to-Peer Tauschbörsen mit genau diesem Problem zu kämpfen haben. Viele Benutzer geben, häufig auch unwissentlich, beschädigte Datei zum Tausch frei und zum anderen versucht die Musikindustrie die Taschbörsen mit gefälschten Audidateien zu überschwemmen, damit den Benutzern die Lust am Tauschen vergehen soll.

Unter Verwendung dieser Prüfsumme kann der Verzeichnisserver auch überprüfen, ob sich diese Datei überhaupt im Netzwerk befinden dürfte. Damit könnte vorgebeugt werden, daß Benutzer selber Dateien ins Netzwerk einspeisen. Dieses würde verhindern, daß Raubkopien verteilt werden.


Mögliche Probleme


Es muß sich auch mit möglich auftretenden Problemen und ihren Auswirkungen auf das System beschäftigt werden. Grundsätzlich kann jede der drei Komponenten eine Fehler im System verursachen. Jetzt muß überdacht werden, welche Komponente also welche Komplikation hervorrufen kann.


Damit ein Peer-to-Peer Videosystem überhaupt reibungslos arbeiten kann, wird auch eine bestimmte Anzahl an Nodes benötigt. In diesem Fall greift das Gesetz von Metcalfe, welches besagt, je mehr Personen an einem Netzwerk teilnehmen, desto größer ist sein Nutzen. Würden nur wenige Nodes teilnehmen, würde doch ein zentraler Server benötigt, der als Reserve dienen müßte, da zu wenige Dateien im Netzwerk verteilt liegen. Dieser Punkt ist aber schwer beeinflußbar.


Ein weiterer möglicher Problemfall ist das Netzwerk selber. Sind die Nodes mit einer zu geringen Bandbreite angeschlossen, kann kein RealTime Streaming eingesetzt werden. Das aktuelle T-DSL Angebot der Deutschen Telekom sieht nur vor, daß ein PC mit 128 kbit angeschlossen wird. Für hochwertiges Videostreaming ist das nicht ausreichend, es würde gerade für akzeptables Audiostreaming reichen, allerdings auch nur dann, wenn der Upstream nicht durch andere Aktivitäten des Clients belegt wird. Außerdem muß der Client darauf achten, daß seine lokale Festplatte nicht komplett von gespeicherten Multimediadateien belegt wird. Dieses würde bedeuten, daß der Anwender entweder selber seine Festplatte aufräume müßte und zu einem gegebenen Zeitpunkt Dateien löschen müßte oder es wird die Fernwartung von außen erlaubt. Dieses könnte automatisch durch eine Zusatzfunktion im Verzeichnisserver geschehen. Es ist allerdings recht unwahrscheinlich, daß der normale Nutzer den Zugriff auf sein heimisches System erlaubt.


Problematisch ist auch die Einbindung von Servern, die sich in einem Netzwerk befinden, das nur über einen privaten IP Adreßbereich verfügt, wie er in RFC 1597 definiert wird. Diese Server gelangen über ein Gateway ins Internet, welches mit Hilfe von NAT die private IP Adresse in eine 'echte' IP Adresse umwandelt. Diese Server sind von außen nur erreichbar, wenn das vorgeschaltete Gateway 'Port Forwarding' beherrscht.



Abbildung 33 Server hinter einem Gateway



Während der Dateiübertragung vom Server zum Client können mehrere Fehler auftreten. Diese beschädigten Dateien sollen, wie bereits in Kapitel 5.3 beschrieben, vom Verzeichnisserver aussortiert werden. Wenn RealTime Streaming zum Einsatz kommt, besteht die Gefahr, daß Pakete, die über UDP verschickt werden, nicht ihr Ziel erreichen. Damit wäre eine Datei bereits nicht mehr verwendbar. Außerdem besteht im Verhalten des Nutzers eine Fehlerquelle. Er dürfte während der Übertragung nicht innerhalb der Datei springen, er dürfte nicht spulen, da die Daten in der Reihenfolge auf die Festplatte geschrieben werden, wie sie präsentiert werden. Um dieses zu verhindern, dürfte nicht das RealTime Verfahren eingesetzt werden, hier müßte dann das FastStart Verfahren Anwendung finden.


Potentielle Einsatzfelder


Das Peer-to-Peer Videosystem ist für den Einsatz in offenen und geschlossenen Netzwerken geeignet. Mit einem offenen Netzwerk ist hier das Internet gemeint. Es würde damit in direkter Konkurrenz zu den in Kapitel 4.1 beschriebenen Filesharingdiensten stehen. Der Dienst könnte aber auch von einem Provider wie AOL oder T-Online angeboten werden, der dieses Angebot nur exklusiv seinen Kunden macht.


Weitaus interessanter wäre der Einsatz aber in einem geschlossenen Netzwerk. Dieses könnte z.B. ein Studentwohnheim sein oder aber das Netz einer Kabel-TV Gesellschaft. Zur Zeit gibt es Bemühungen das Kabelnetz zu einem vollwertigen Ersatz zum Telefonnetz auszubauen. Es sollen dann Dienste wie Internetanschluß, Telefonie und auch interaktives TV angeboten werden. Das Hauptproblem liegt zur Zeit aber daran, daß das Kabelnetz keinen Rückkanal vom Kunden zum Provider besitzt. Es können lediglich Daten vom Provider zum Kunden fließen. Mehrere Gesellschaften bieten aber bereits Internetanschlüsse über das Kabelnetz an [26]. Um interaktive TV Dienste bereitzustellen, muß jeder Kunde, der daran teilhaben möchte, mit einer Set-Top-Box ausgerüstet werden. An genau dieser Stelle kann dann das Peer-to-Peer Videosystem eingesetzt werden. Die Set-Top-Box muß dann mit einem Server und einem Client ausgerüstet werden. Zusätzliche müßte jede Box über eine Festplatte verfügen. Der Datenverkehr würde dann hauptsächlich im Netz der Kabel-TV Gesellschaft stattfinden. Dieser Dienst würde dann auch mit nur einem Verzeichnisserver auskommen. Als allgemeiner Standard für Set-Top-Boxen kristallisiert sich immer mehr die MHP Spezifikation heraus. Diese definiert eine offene Schnittstelle zum Zugriff auf interaktive TV Dienste, wozu auch Video-on-Demand Angebote gehören sollen.


Ein weiterer Fall wäre der Einsatz z.B. in Zügen und Flugzeugen, die über ein lokales Netzwerk verfügen. Die Passagiere hätten dann Zugriff über ein Terminal, das sich im Sitz des Vordermanns befindet, auf die Videothek des Flugzeugs oder des Zuges. Das Flugzeug oder der Zug bräuchte dann nicht extra über eine größere Anzahl an Servern verfügen. Hier liegt der Vorteil in der Reduktion von Raum und Gewicht. Zusätzliches Gewicht ist in der Luftfahrtindustrie ein wesentlicher Kostenfaktor. Je leichter ein Flugzeug ist, desto weniger Treibstoff verbraucht es auch.


In den beschriebenen geschlossenen Netzwerken hätten die Betreiber des Dienstes jeweils auch vollständigen Zugriff auf die Clients. Damit würde auch die Möglichkeit bestehen, daß ein Zugriff von außen auf die Clients zum Administrieren erfolgen kann. In einem PC Netzwerk wäre das, wie in Kapitel 5.4 bereits erwähnt, nicht möglich.