Ezientes Routing in kooperativen Multimedia-Streaming-Systemen

Transkript

1 Fakultät für Informatik und Automatisierung Institut für Praktische Informatik Fachgebiet Telematik DIPLOMARBEIT ZUR ERLANGUNG DES AKADEMISCHEN GRADES DIPLOMINFORMATIKER Thema: Ezientes Routing in kooperativen Multimedia-Streaming-Systemen vorgelegt der Fakultät für Informatik und Automatisierung der Technischen Universität Ilmenau von Verfasser: Thomas Sesselmann geboren am: 25. Februar 1980 Inv.-Nr.: /015/IN99/2253 verantwortlicher Hochschullehrer: Prof. Dr.-Ing. Dietrich Reschke betreuender wiss. Mitarbeiter: Dipl.-Inf. Thorsten Strufe Ort und Abgabe der Diplomarbeit: Ilmenau, den 21. Juni 2005

2

3 1. Kurzfassung Die Diplomarbeit Ezientes Routing in kooperativen Multimedia-Streaming-Systemen beinhaltet die Entwicklung eines eigenen Routings für ein Multimedia-Streaming- System. Nach der Untersuchung existierender Ansätze konnten die Anforderungen für ein geeignetes Routing festgelegt werden. Das Routing klassiziert die ihm bekannten Peers nach ihrer Lokalität. Diese wird anhand virtueller Positionskoordinaten im Peer-to- Peer-Netzwerk berechnet und teilt für jeden Peer die bekannten Peers in Horizonte ein. Nach der Implementierung des entworfenen Routings soll eine Integration in das Multimedia-Streaming-System ekstream erfolgen und die Funktionalität durch einen Test gezeigt werden /015/IN99/2253 3

4 1. Kurzfassung /015/IN99/2253

5 Inhaltsverzeichnis 1. Kurzfassung 3 Inhaltsverzeichnis 8 2. Einleitung 9 3. Grundlagen Kooperatives System Routing Multicast Multicastrouting Lokalität Peer-to-Peer Organisationsformen für verteilte Systeme Ziele von P2P-Systemen Lookup in P2P-Systemen Multimedia-Streaming Verwandte Ansätze Host-Based Multicast CoopNet SplitStream Layered Peer-to-Peer Streaming Service Adaptive Multicast PeerCast /015/IN99/2253 5

6 Inhaltsverzeichnis 4.7. Scattercast End System Multicast Zigzag Fazit Anforderungen Allgemeine Anforderungen an das System Funktionale Anforderungen Nicht funktionale Anforderungen Entwurf P2P-Streaming-Modell Lokalität Vivaldi Eigene Abwandlung des Vivaldi-Ansatzes Routing Lokalisierung Fluten Registrieren Eigene Ideen Implementierung Architektur von ekstream Routing Schnittstellen Statisches Routing Einfaches dynamisches Routing Lokalitätsbewusstes dynamisches Routing Lokalisierung Schnittstellen Einfache Lokalisierung Admission Control Schnittstellen Statisches Admission Control /015/IN99/2253

7 Inhaltsverzeichnis Einfaches Admission Control Test Testumgebung Verlauf des Tests Auswertung der Logdateien Ergebnisse des Tests Auswertung und Ausblick Schlussbemerkung Bewertung und Ausblick Zusammenfassung Literaturverzeichnis 95 Abbildungsverzeichnis 99 Tabellenverzeichnis 101 Abkürzungsverzeichnis 103 Thesen 105 Eidesstattliche Erklärung 107 A. Anhang 109 A.1. Übersicht über die Logdateien A.2. Datendatei für die Skripte A.3. Perlskript zum sortierten Zusammenfügen zweier Logdateien A.4. Perlskript zum Erzeugen der Dierenz zwischen zwei Logdateien A.5. Perlskript zum sortierten Zusammenfügen aller Logdateien A.6. Perlskript zum Teilen der kompletten Logdatei A.7. Perlskript zum Berechnen der Abstände vieler Vektoren in einer Datei. 118 A.8. Perlskript zum Berechnen der Abstände zweier Knoten zu jedem Zeitpunkt119 A.9. Ausschnitt aus einer Logdatei A.10.Vorgehen zum Ausführen eines Tests A.10.1.Herunterladen des Projekts /015/IN99/2253 7

8 Inhaltsverzeichnis A.10.2.Kompilieren der Testdateien A.10.3.Kongurieren des Datenstroms A.10.4.Starten der Testdateien A.10.5.Starten des mplayers /015/IN99/2253

9 2. Einleitung Diese Diplomarbeit beschäftigt sich mit dem Thema Multimedia-Streaming. Dabei werden besonders die Einüsse der Lokalität auf die Ezienz des Routings und des Streamings betrachtet. Mit der zunehmenden Verbreitung von Breitband-Internetzugängen haben viele die Möglichkeit, Multimedia-Daten aus dem Internet zu beziehen. Dabei existieren eine Menge Anwendungsmöglichkeiten, wie zum Beispiel das Streaming eines groÿen Ereignisses im Internet. Denkbar wäre da ein Konzert oder die Fuÿball-Weltmeisterschaft Die Diensteanbieter haben dabei allerdings einen immensen Bandbreitenbedarf. Um dies zu verdeutlichen, wird hier ein Rechenbeispiel mit einem Nachrichtenstream gezeigt. Der Stream hat eine Bitrate für Video von 300kbit/s und 96kbit/s für Audio. Der Server ist mit 100M bit/s an das Internet angebunden. So können idealerweise maximal 100Mbit/s 396kbit/s = 252 Senken bedient werden. Für mehr Nutzer ist eine gröÿere Ausgangskapazität notwendig. Ein weiterer Rechner mit weiteren 100M bit/s kann das Problem nur lösen, wenn der Flaschenhals nicht am Gateway des Providers liegt oder er müsste an einem anderen Standort aufgestellt werden. Die einfachste Möglichkeit wäre die Verwendung von IP-Multicast, das für die Kommunikationen an viele Empfänger gedacht ist. Allerdings wird IP-Multicast von den meisten Routern im Internet nicht geroutet (siehe Abschnitt 3.3) und stellt daher keine Lösung dar. Einen Ausweg bietet ein Content Distribution Network (CDN). Hierzu werden viele Server global verteilt und über ein Netzwerk verbunden. Der Nutzer wird dann zu einem freien Server weitergeleitet. Anbieter für solche Systeme sind zum Beispiel /015/IN99/2253 9

10 2. Einleitung Akamai1, Speedera2 und Mirror Image Internet3. Der Nachteil von solchen Systemen sind die hohen Kosten, da die Kapazitäten bei den Anbietern gemietet werden müssen (In [Heidenreich (2004) S.40] ist dieser Ansatz näher erläutert.). Somit kommt diese Lösung nur für groÿe Firmen in Frage. In dieser Diplomarbeit wird eine weitere Möglichkeit untersucht, dieses Problem zu lösen. Die Teilnehmer werden in einem Peer-to-Peer-Netzwerk organisiert und arbeiten kooperativ. Daher bieten alle Teilnehmer, die schon Daten empfangen haben, diese auch anderen Teilnehmern wieder an. Hierbei existiert das Problem, dass die meisten Nutzer als breitbandigen Anschluss ADSL (Asymmetric Digital Subscriber Line ) verwenden und daher zwar den kompletten Stream empfangen können, aber nur einen Bruchteil der notwendigen Bandbreite wieder zur Verfügung stellen können. Als Gesamtziel kann die eziente Nutzung der Ressourcen gesehen werden. Dies wird durch einen Multisource-Ansatz, bei dem mehrere Teilnehmer einem gemeinsam die Daten liefern können, erreicht. Ebenso wird versucht, lokalitätserhaltende Topologien aufzubauen, um die Netzwerkressourcen zu schonen. Die Arbeit gliedert sich wie folgt: Zuerst werden einige Grundlagen im Kapitel 3 gelegt und anschlieÿend einige existierende Ansätze (Kapitel 4) vorgestellt. Darauf folgend werden die Anforderungen (Kapitel 5) für das eigene System festgelegt und danach die Komponenten Routing und Lokalisierung entworfen (Kapitel 6). Diese Komponenten werden dann im Kapitel 7 in das existierende System ekstream4 integriert und in Kapitel 8 getestet. Abschlieÿend erfolgt eine Bewertung der Arbeit (Kapitel 9). 1http:// 2http:// 3http:// 4http:// /015/IN99/2253

11 3. Grundlagen In diesem Kapitel werden die grundlegenden Begrie, die für das weitere Verständnis dieser Arbeit notwendig sind, erläutert Kooperatives System In einem kooperativen System stellt jeder Knoten seine Ressourcen, insbesondere die von ihm empfangenen Daten, anderen Knoten zur Verfügung. Auf diese Art wird die Gesamtkapazität des Systems erhöht, da nicht alle Senken ihre Daten von einem Server beziehen müssen Routing Im Internet sind Router die tragenden Elemente, da sie einzelne Netze miteinander verbinden. Sie arbeiten auf Schicht 3 (Netzwerkschicht) des ISO/OSI-Referenzmodells und wählen den Weg eines Paketes über das Netzwerk. Routen können statisch festgelegt werden, wie dies zum Beispiel bei dem Default-Gateway eines jeden Rechners der Fall ist. In der Regel legen die Router im Internet ihre Routen allerdings dynamisch fest bzw. ändern sie dynamisch, um eigenständig auf Änderungen (zum Beispiel Ausfall eines Routers oder Überlastung einer Verbindung) reagieren zu können. Die prinzipielle Aufgabe eines Routing-Verfahrens ist, die Entscheidung zu fällen, zu welchem Ausgang ein eingegangenes Paket weitergeleitet werden soll. Die primären Ziele sind hierbei ein allgemein hoher Netzdurchsatz und eine geringe mittlere Paketverzögerung. Generell wird dabei versucht, ein /015/IN99/

12 3. Grundlagen Datenpaket von der Quelle zum Ziel über den Pfad mit den geringsten Kosten zu leiten. Als Kosten können hierbei z. B. die aktuelle Auslastung oder Verzögerung einer Verbindung, die Kapazität oder Fehlerrate einer Verbindung, die tatsächlichen Kosten der Übertragung über eine Verbindung etc. angesetzt werden. Die Entscheidung über das Kostenmodell liegt im Allgemeinen bei einem Netzbetreiber. [Krüger und Reschke (2004) S.156] 3.3. Multicast Multicast ist eine Gruppenkommunikation, dabei werden die gleichen Daten an mehrere Empfänger gleichzeitig verschickt. Bei Unicast ist immer nur die Übertragung von einem Sender zu einem Empfänger möglich. Üblicherweise wird mit Multicast die Multicast-Funktionalität des IP-Protokolls bezeichnet, womit das eziente Senden von Daten an viele Empfänger zur gleichen Zeit in IP-Netzwerken möglich wird. Dazu werden spezielle Multicast-Adressen aus dem IP- Adressbereich verwendet. Dabei liegt der Vorteil darin, dass die Daten auf jedem Link jeweils nur einmal geschickt werden müssen und erst bei den angeschlossenen Routern und Switchen dupliziert werden. IP-Multicast wird von den meisten Routern im Internet allerdings aus verschiedenen Gründen nicht geroutet (aus [Weber (2004)] und [Banerjee und Bhattacharjee (2002)]): Es wird eine erweiterte Router-Software benötigt, die für jede Multicast-Adresse einen extra Eintrag über ihren Zustand verwaltet. Die Komplexität des Routings erhöht sich dadurch enorm bei gleichzeitigem Verlust der Skalierbarkeit. Ein Angreifer könnte über Multicast viele Empfänger gleichzeitig überuten und so leicht das Netzwerk überlasten (DoS1-Attacke). Die Trac-Berechnung, basierend auf der eingehenden oder ausgehenden Bandbreite, müsste angepasst werden. Jeder Gruppe muss dynamisch eine Adresse aus dem globalen IP-Multicast- Adressraum zugeordnet werden. Eine skalierbare und zuverlässige Verteilung der 1 Denial of Service /015/IN99/2253

13 Adressen ist ein Problem Multicast Die Realisierung einer sicheren Übertragung ist auch deutlich schwieriger, da die sichere Verteilung eines Sitzungsschlüssels an alle Gruppenmitglieder sehr komplex ist. Die Umsetzung von höheren Funktionen wie Flusskontrolle, Sicherheit oder Zuverlässigkeit ist deutlich schwieriger als bei Unicast. Die Entwicklung von Multicastanwendungen scheitert meist an der nicht vorhandenen Infrastruktur. Des Weiteren besteht ohne entsprechende Anwendungen kein Bedarf für die aufwändige Infrastruktur. Auf Grund dieser Probleme sind viele Ansätze entstanden, einen Multicast auf der Anwendungsebene zu implementieren. Die Aufgaben der Router, die Pakete zu vervielfältigen und weiterzuleiten, fällt den einzelnen Knoten (Mitgliedern der Multicast- Gruppe) zu. Diese Knoten werden dabei über ein selbstorganisierendes virtuelles Netz miteinander verbunden, das sozusagen über das physikalische Netzwerk gelegt wird, weshalb es Overlay-Netz heiÿt. Weiterleitungen von einem Knoten zu einem Anderen können nur über Wege in diesem Overlay-Netz gehen. Im Weiteren wird der Multicast auf der Anwendungsebene (Application-Layer-Multicast) Overlay-Multicast genannt. In Abbildung 3.1 ist der Unterschied zwischen Unicast, IP-Multicast und Overlay- Multicast dargestellt. Dieses Beispiel zeigt einen Server, der einen über Videokamera aufgenommenen Stream anbietet und fünf andere Rechner, die auf diesen Stream zugreifen wollen. In Abbildung 3.1(a) ist die zugrunde liegende Netzstruktur mit drei Routern zu sehen (grau). Nun werden die Knoten über ein virtuelles Netz verbunden, das Overlay-Netz (rot). Die gepunkteten Pfeile (blau) in Abbildung 3.1(b) (Unicastübertragung), 3.1(c) (Übertragung mit IP-Multicast) und 3.1(d) (Übertragung mit Overlay-Netz) symbolisieren die Datenübertragung. Dabei ist zu sehen, dass der Server bei der Unicastübertragung unter hoher Last steht, da er alle Anfragen zu bearbeiten hat und jedem einzelnen Client antworten muss. Daher hat auch der Link nahe der Quelle eine sehr groÿe Auslastung. Deswegen ist zu erkennen, dass IP-Multicast die eektivste Datenübertragung bezüglich des Ressourcenverbrauchs (Serverlast und Bandbreite im Netz) ist. Um bewerten zu können, wie gut eine bestimmte Implementierung von Overlay-Multicast ist, werden einige wichtige Performance-Metriken nach /015/IN99/

14 3. Grundlagen (a) Physikalische Topologie und Overlay-Netz (b) Übertragung mit Unicast (c) Übertragung mit IP-Multicast (d) Übertragung mit Overlay-Multicast Abbildung 3.1.: Übertragung mittels Unicast, IP-Multicast und Overlay-Multicast [Banerjee und Bhattacharjee (2002)] eingeführt: Stress: Stress wird pro Link oder Router der Topologie deniert und ist die Anzahl der identischen Pakete, die über den Link oder Knoten gesendet werden. Bei IP- Multicast existieren keine redundanten Pakete, daher ist der Stress für alle Links im Netzwerk eins. Stretch: Stretch ist pro Mitglied deniert und entspricht dem Verhältnis zwischen der Länge des Pfades zur Quelle über das Overlay-Netzwerk und dem Pfad einer direkten Unicast-Verbindung. Bei der klassischen Client/Server-Topologie ist der Stretch eins bei jedem Mitglied und damit optimal, da jeder Client zum Server /015/IN99/2253

15 eine eigene direkte Unicast-Verbindung hat Multicastrouting Kontroll-Overhead: Jeder Knoten tauscht mit seinem Nachbarn im Overlay-Netzwerk Aktualisierungsnachrichten aus. Diese Nachrichten werden als Kontroll-Overhead bezeichnet und sind eine wichtige Metrik für die Skalierbarkeit. Der Stress muss klein sein, damit die Knoten und Links nicht überlastet werden. Allerdings sollte auch der Stretch niedrig sein, damit die Ende-zu-Ende-Verzögerung gering gehalten wird. Das Problem ist jedoch, dass dies zwei konkurrierende Ziele sind, sodass ein guter Mittelweg gefunden werden muss. Obwohl Overlay-Multicast ebenfalls Probleme besitzt, überwiegen die Vorteile. Er kann einfach an die jeweilige Anwendung angepasst werden und funktioniert ohne den besonderen Support der Internet-Service-Provider Multicastrouting Die Aufgabe des Multicastroutings ist es, ein möglichst ezientes Overlay-Netz aufzubauen. Prinzipiell gibt es keine Einschränkungen für den Aufbau eines solchen Overlay-Netzwerkes. In Abbildung 3.2 sind die drei prinzipiellen Topologieformen veranschaulicht, entweder ein Baum2 wie in Abbildung 3.2(a), oder ein Netz. Das Netz kann entweder kreisfrei (Abbildung 3.2(b)) sein oder Kreise enthalten (Abbildung 3.2(c)). Während die Router im Internet stabil sind, können die Knoten jederzeit dem Netzwerk beitreten oder es verlassen. Die groÿe Schwierigkeit besteht darin, dass diese Knoten die Funktionalität der Router nachbilden sollen und derzeitige Routingalgorithmen im Internet nicht auf eine solch starke Dynamik ausgelegt sind. Dies macht das Management des Netzwerkes bedeutend schwieriger und muss beim Aufbau des Overlay-Netzes berücksichtigt werden. 2 In diesem Fall wird auch vom Multicast-Baum gesprochen /015/IN99/

16 3. Grundlagen (a) Multicastbaum (b) Netz ohne Kreise 3.5. Lokalität (c) Netz mit Kreisen Abbildung 3.2.: Topologieformen für das Overlay-Netz Verschiedene Hosts im Internet sind typischerweise über viele dazwischen liegende Router verbunden. Dabei ist die Verbindung zwischen ihnen im Allgemeinen stabiler, hat eine kleinere Verzögerung und meist auch mehr Bandbreite, je weniger Komponenten bzw. Router zwischen ihnen liegen. Daher liegt es nahe, die Lokalität im Peer-to-Peer- Netzwerk zu berücksichtigen, um das Netzwerk weniger zu belasten und die Vorteile der besseren Verbindung zu nutzen. Im Extremfall sind zwei Knoten innerhalb eines lokalen LANs und könnten so sinnvollerweise die Daten nur einmal über ihren Uplink beziehen. Da so das Schicken der Daten über unnötig lange Pfade vermieden wird, kann auch /015/IN99/2253

17 3.5. Lokalität (a) Overlay-Netzwerk mit Berücksichtigung der Lokalität (b) Overlay-Netzwerk ohne Berücksichtigung der Lokalität Abbildung 3.3.: Einuss der Lokalität auf die Netzwerk-Ezienz des Overlay- Netzwerks die Belastung der darunter liegenden Netzwerkstruktur vermieden werden, wie in Abbildung 3.3 zu sehen ist. Das lokalitätserhaltende Overlay-Netzwerk ist in Abbildung 3.3(a) und das nicht lokalitätserhaltende Overlay-Netzwerk in Abbildung 3.3(b) veranschaulicht. Dabei sind die Router und die physikalischen Verbindungen grau dargestellt. Die roten Pfeile stellen die logischen Verbindungen zwischen den Knoten im Overlay-Netz dar und die blau gepunkteten Pfeile zeigen die Datenübertragung durch das physikalische Netzwerk. Die Bestimmung der Lokalität kann dabei nicht über exakte geographische Entfernungen geschehen, da diese sehr schwer zu ermitteln und unter Umständen auch nicht optimal sind. Besser und einfacher ist es, die Lokalität anhand von geeigneten bestimmbaren Netzwerkparametern, wie zum Beispiel Anzahl der Hops3 und gemittelte Antwortzeiten, zu bestimmen. [Strufe (2003)] 3 Die Anzahl der Hops entspricht die Anzahl der Router entlang des Pfades zwischen zwei Endsystemen /015/IN99/

18 3. Grundlagen 3.6. Peer-to-Peer Unter Peer-to-Peer (P2P) wird die Kommunikation unter Gleichgestellten verstanden. In einem Peer-to-Peer-Netzwerk gibt es keine eindeutigen Server oder Clients, jeder Client muss auch als Server auftreten. Aus diesem Grund wird auch nur von Peers oder Knoten gesprochen. Ein wesentlicher Vorteil von P2P-Netzen ist, dass keine konkrete oder feste Struktur existiert und somit das Netzwerk sehr ausfallsicher ist. P2P weist eine n:m Kommunikationsbeziehung im Gegensatz zu Client/Server, wie zum Beispiel bei einem Webserver, mit 1:n auf Organisationsformen für verteilte Systeme Die Topologien von verteilten Systemen sind: Zentralisiert: Hierbei existiert eine zentrale Instanz, an die alle anderen Knoten ihre Anfragen senden. Diese Topologie ist keine P2P-Struktur, da nicht jeder die gleichen Aufgaben übernehmen kann. Damit der zentrale Server diese Anfragen (Lookup) beantworten kann, müssen die Ressourcen/Dienste bei ihm zuvor angemeldet werden. Somit stellt es sich als erheblich einfacher heraus, alle Ressourcen/Dienste im System bekannt zu machen. Allerdings ist dabei kein absolutes Wissen möglich, sondern nur ein zeitlich begrenzter Ausschnitt. Diese zentrale Struktur beinhaltet jedoch wieder die Schwachstelle, dass die Anfragen den Server überlasten können und somit der Server die Leistungsfähigkeit insbesondere auch die Skalierbarkeit des Gesamtsystems bestimmt. Im schlimmsten Fall fällt dieser zentrale Server aus und das gesamte restliche Netz ist funktionsunfähig, da alle von ihm abhängig sind. Ein Beispiel für diese Struktur ist Napster4. Dezentralisiert: Bei einem voll dezentralisierten System müssen alle Funktionen von den Knoten selbst organisiert werden. Insbesondere können Dienste oder Ressourcen nicht registriert werden, weswegen ein Lookup-Service bedeutend schwieriger zu realisieren ist. Dafür fallen aber auch alle Nachteile einer zentralen Architektur weg, wie zum Beispiel beim Ausfall eines zentralen Servers. Ein Vertreter dieser Struktur ist Gnutella5. 4http:// 5http://rfc-gnutella.sourceforge.net /015/IN99/2253

19 3.6. Peer-to-Peer Hybrid: Bei der hybriden Architektur wird versucht, die Vorteile der zentralen und der dezentralen Architektur zu vereinen. Meist existieren hierbei zwei Knoten-Typen, die normalen Nodes und die Supernodes. Die meist ressourcenstärkeren Supernodes übernehmen dabei die anspruchsvollen Aufgaben wie Koordination der Sucher und die Verwaltung der Knoten. Einfache Knoten können so ihre Ressourcen/Dienste bei den Supernodes registrieren, und auch dort nach Ressourcen nachfragen. Die Supernodes übernehmen in diesem Fall also die Aufgabe des zentralen Servers, werden allerdings je nach Bedarf neu gewählt und koordinieren sich untereinander. Ein Beispiel für diese Architektur ist FastTrack Ziele von P2P-Systemen Die Ziele beim Einsatz von P2P-Systemen werden in [Heidenreich (2004)] genauer beschrieben, wobei hier nur die wichtigsten kurz beschrieben werden sollen. Kostenteilung/-reduktion: Da bei der klassischen Client/Server-Struktur, alle Clients von einem Server bearbeitet werden müssen, kann an dieser Stelle schnell eine Überlastung auftreten. Die P2P-Architektur versucht die Last oder Kosten, wie zum Beispiel Speicherplatz, Rechenkapazität oder Bandbreite auf mehrere Knoten zu verteilen. Zusammenfassen von Ressourcen: Es können Ressourcen aller Peers zusammengefasst werden, um eine gemeinsame Aufgabe zu erfüllen. Beispiele hierfür wären das verteilte Rechnen von oder Find-a-Drug8. Verbesserte Skalierbarkeit und Zuverlässigkeit: Da Dienste nicht nur von einem Server bereitgestellt werden, sondern auch von anderen Knoten, wird eine erheblich bessere Skalierbarkeit und auch Ausfallsicherheit erreicht. Hohe Dynamik: Peer-to-Peer-Systeme sind darauf ausgelegt, dass einzelne Knoten sehr dynamisch handeln können und sind demnach auch in der Lage mit solchen Situationen umzugehen. 6http:// 7 Zum Finden von Spuren extraterrestrischen Lebens ( 8 Zum Finden von Heilmitteln für verschiedene Krankheiten ( /015/IN99/

20 3. Grundlagen Ad-hoc-Kommunikation: Durch das grundsätzliche Fehlen eines zentralen Servers ist es möglich mit P2P-Systemen einfach eine Ad-hoc-Kommunikation aufzubauen Lookup in P2P-Systemen Da bei P2P-Systemen Ressourcen und Objekte sehr dynamisch beitreten und wegfallen können, ist die Lokalisation dieser besonders schwierig. Um solche Objekte und Ressourcen aufzuspüren, ist ein so genannter Lookup-Dienst erforderlich, welcher aus zwei Stufen besteht: Lokalisierungsdienste bilden Bezeichner9 auf Referenzen10 ab Namensdienste bilden Namen11 auf Bezeichner ab Um nun solche Namens- und Lokalisierungsdienste zu realisieren, existieren grundsätzlich zwei Möglichkeiten für die Suche: Speicherung und Abfrage in einer zentralen Registrierung Durchsuchen des gesamten Systems Das Durchsuchen des gesamten Systems wird zum Beispiel über ein Fluten12 des Netzwerkes mit Anfragen realisiert. Jeder Knoten muss eine an sie gestellte Anfrage lokal überprüfen und an alle weiteren bekannten Knoten (auÿer dem Anfragenden) weiterleiten. Auf diese Art wird der gesamte Suchraum abgedeckt. Diese Suche führt dann allerdings zu einem, auf die Anzahl der teilnehmenden Knoten bezogen, exponentiellen Kommunikationsaufkommen und belastet so bei vielen Anfragen das System stark. Eine bessere Variante ist eine Registrierung der Ressourcen. Bei der zentralen und hybriden Architektur ist leicht ein Server zu nden, der für die jeweilige Registrierung zuständig ist (selbst bei der hybriden Architektur hat ein Knoten nur einen oder eine 9 Ein Bezeichner dient der eindeutigen Identizierung einer Ressource. 10 Mit Hilfe einer Referenz kann die durch den Bezeichner festgelegte Ressource im Netzwerk adressiert bzw. gefunden werden. 11 Ein Name dient meist der Adressierung mehrerer Ressourcen, die aber unterschiedliche Bezeichner haben können. 12 Wie dies etwa bei Gnutella realisiert wird /015/IN99/2253

21 3.7. Multimedia-Streaming sehr kleine Anzahl von Supernodes). Nun muss allerdings bei der hybriden Architektur auch eine weitere Suche unter den Supernodes möglich sein. Dabei entsteht dasselbe Problem wie bei der vollständig dezentralen Architektur, nur mit weniger Knoten und deshalb weniger Aufwand. [Strufe (2003)] 3.7. Multimedia-Streaming Der Begri Multimedia ist sehr vielschichtig, in dieser Arbeit soll aber darunter vordergründig die Verknüpfung von Audio und Video verstanden werden. Als Streaming wird die kontinuierliche Übertragung eines Datenstromes von einer Quelle zur Senke bezeichnet. Zumeist bietet das Format (Kodierung) der übertragenen Daten die Möglichkeit, sie bereits anzuzeigen (nutzen), bevor sie vollständig übertragen worden sind. Bei dem Spezialfall Multimedia-Streaming, werden Multimedia-Daten in Form eines Streams verschickt. Dabei besitzen die Multimedia-Daten besondere Eigenschaften: Es handelt sich meist um groÿe Datenmengen, die selbst komprimiert eine hohe Bandbreite benötigen. Es ist notwendig, dass die Daten zeitgenau abgespielt werden, da es sonst zu Verfälschungen der Informationen kommt. Der Aufbau der Daten ist strukturiert. Es herrscht eine strikte zeitliche Abhängigkeit der Daten. Daraus ergeben sich spezielle Anforderungen beim Multimedia-Streaming: Die Daten müssen rechtzeitig vor dem Abspielzeitpunkt empfangen werden. Die Daten müssen in einem Format kodiert sein, sodass die Nutzung ohne vollständige Daten ermöglicht wird (nicht streng abhängige Daten) /015/IN99/

22 3. Grundlagen Die Bandbreite muss groÿ genug sein, um mindestens so viele Daten pro Zeitraum empfangen zu können, wie zum Abspielen pro Zeitraum notwendig ist (Datenrate der Daten Bandbreite des Übertragungskanals). Die Rechtzeitigkeitsanforderung stellt immer noch eine Herausforderung dar, da die Standardkommunikationsprotokolle wie TCP/IP nicht für Zeitschranken ausgelegt sind. Bei der Entwicklung dieser Protokolle wurde mehr Wert auf die Zuverlässigkeit gelegt. Prinzipiell existieren zwei verschiedene Arten von Streaming-Methoden: Live-Streaming: Hierbei werden an der Quelle kontinuierlich neue Daten erzeugt. Zum Beispiel wird per Kamera ein Fuÿballspiel aufgenommen und direkt mit Hilfe eines Rechners digitalisiert und encodiert. Dies wird dann als Stream übertragen. Video-on-Demand: Im Gegensatz zum Live-Streaming sind vom Anfang an alle Daten vorhanden und gespeichert. So ist es möglich zu einem beliebigen Zeitpunkt (on demand) einen Stream anzufordern und sogar bei einem beliebigen Oset anzufangen. Theoretisch ist es möglich, während des Streamings mehr Daten anzufordern, als gerade verbraucht werden können, wenn die verfügbare Bandbreite des Übertragungsmediums gröÿer als die Datenrate des Streams ist. Für den Nutzer besteht kaum ein Unterschied zwischen Live-Streaming und Videoon-Demand. Jedoch ist der Unterschied, dass bei Live-Streaming die Daten so schnell wie möglich angezeigt werden sollen, während bei Video-on-Demand viel mehr Daten im Voraus heruntergeladen bzw. gepuert werden können. Somit kann ein Fehler bei der Übertragung bei Video-on-Demand eher durch nochmaliges Senden ausgeglichen werden, als bei Live-Streaming /015/IN99/2253

23 4. Verwandte Ansätze Es existieren in der derzeitigen Forschung viele Anwendungen von Multimedia-Streaming in P2P-Netzwerken. In diesem Kapitel sollen nun einige Ansätze mit unterschiedlichen Lösungsmöglichkeiten vorgestellt werden. Alle Ansätze stellen fest, dass Multicast in der Netzwerkschicht nicht anwendbar ist (Begründung siehe Abschnitt 3.3) und daher eine Lösung auf der Anwendungsebene entwickelt werden muss. Anfangs werden mit Host-Based Multicast und CoopNet in den Abschnitten 4.1 und 4.2 zwei zentrale Ansätze vorgestellt und darauf folgen die verteilten Ansätze. Die Abschnitte 4.3 und 4.4 beschreiben die zwei Systeme SplitStream und Layered Peerto-Peer Streaming, die wie CoopNet den Stream in mehrere Teilströme unterteilen und dann auf unterschiedlichen Pfaden an den Empfänger senden. Mit Service Adaptive Multicast (siehe Abschnitt 4.5) folgt nun ein Ansatz mit verteilten Hash-Tabellen und Landmark-Vektoren. Bei PeerCast, im Abschnitt 4.6 vorgestellt, ist die Kernentwicklung eine Zwischenschicht zwischen Anwendung und Netzwerk. Scattercast und End System Multicast (siehe Abschnitt 4.7 und 4.8) verwenden ein Reverse-Path-Forwarding Algorithmus, um Verteilungsbäume für die Daten aufzubauen. Zum Schluss wird im Abschnitt 4.9 Zigzag vorgestellt, dass auf einem hierarchischen Modell mit Clustern basiert Host-Based Multicast Beim Host-Based Multicast [Roca und El-Sayed (2001)] (HBM) wird eine Gruppenkommunikation auf der Anwendungsebene entwickelt. Dabei wird zwischen den Core- Members, als Hauptteil der Verteilungsstruktur, und den Non-Core-Members, als einfache Blattknoten in der Topologie, unterschieden. Das Overlay-Netz wird von einem /015/IN99/

24 4. Verwandte Ansätze zentralen Rendezvous-Point berechnet, der dann die Core-Members und die Non-Core- Members benachrichtigt. Dieser Rendezvous-Point kennt alle Mitglieder und ihre Entfernungen zueinander (Für die Denition der Entfernung können unterschiedliche Metriken verwendet werden.). Diese Abstände werden periodisch von den Core-Members und den Non-Core-Members berechnet und dem Rendezvous-Point mitgeteilt. HBM besitzt, bedingt durch die zentrale Architektur, eine begrenzte Skalierbarkeit und muss ein groÿes Vertrauen in die Verfügbarkeit des Rendezvous-Point haben. Auf der anderen Seite ist dies eine einfache Lösung mit wenig Last auf der Knotenseite und ohne Probleme mit Abhängigkeiten, die bei verteilten Algorithmen auftreten. Auÿerdem wird eine relativ gute Topologie in Abhängigkeit zur Genauigkeit der Entfernungsmessung erzeugt, die besondere Knoteneigenschaften berücksichtigen kann CoopNet Bei Cooperative Networking (CoopNet)[Padmanabhan u.a.(2002)][padmanabhan u.a. (2003)] wird das Client-/Server-Modell nicht durch ein P2P-Netzwerk ersetzt, sondern ergänzt. Nur wenn der Server in Zeiten groÿer Belastung nicht mehr in der Lage ist, die Anfragen selbst zu bedienen, baut er eine Verteilungsstruktur auf, bei der alle Clients kooperieren müssen, um ihn zu entlasten. Es wird davon ausgegangen, dass die Clients dem Netzwerk nur zur Verfügung stehen, solange sie selbst Daten empfangen wollen. Dies kann eine kurze Zeit von z. B. wenigen Minuten sein. Die kooperative Verteilungsstruktur besteht aus mehreren Bäumen, die vom Server verwaltet werden. Der Datenstrom wird mit Hilfe von Multiple Description Coding [Goyal (2001)] (MDC) in Teildatenströme aufgeteilt und auf je einem Baum an die Clients verteilt. Um Redundanz zu erreichen, müssen die inneren Knoten jedes Baumes unterschiedlich sein, idealerweise wird jeder Knoten nur in einem Baum als innerer Knoten und sonst immer als Blattknoten verwendet. Als Quelle ist der Server auch die Wurzel jedes Baumes. Der Ausfall eines Knotens führt auf diese Art nur zum Verlust eines Teildatenstromes für seine Kinderknoten. Dadurch nimmt nur vorübergehend die Qualität des Streams ab und führt nicht zum kompletten Verlust. Durch die zentrale Struktur ist die Verwaltung des Netzwerkes einfach, da der Server /015/IN99/2253

25 4.3. SplitStream alle Ressourcen kennt. Der Knotengrad jedes Knotens wird durch seine verfügbare ausgehende Bandbreite beschränkt. Bei dem Beitritt eines Knotens meldet sich dieser einfach beim Server und erhält von ihm eine Liste von Vaterknoten (für jeden Baum genau einen Knoten). Die Auswahl der Vaterknoten durch den Server kann zufällig oder deterministisch erfolgen, um die Bäume unterschiedlich aufzubauen. Es stört wenig, dass der Server ein Single Point of Failure bei der Verwaltung des Netzwerkes darstellt, denn er ist gleichzeitig Quelle der Daten und ohne Quelle ist die Verteilungsstruktur überüssig. Allerdings wird auf diese Art die Skalierbarkeit des Netzwerkes eingeschränkt, da durch die alleinige Verwaltung der Verteilungsbäume ein groÿer Kontroll-Overhead bei dem Server herrscht SplitStream SplitStream [Castro u.a. (2003)] ist ein System zum Verteilen von bandbreitenintensiven Daten mit Hilfe von Multicast auf der Anwendungsebene. Dabei wird versucht, die Unausgewogenheit von internen Knoten und Blattknoten in einem Multicast-Baum zu lösen. Ein baumbasierter Multicast passt leider von Natur aus nicht gut in eine kooperative Umgebung, denn ein ezienter Multicast-Baum hat eine möglichst geringe Höhe und damit wenig interne Knoten und viele Blattknoten. Die internen Knoten müssen viel Arbeit in die Aufteilung und Weiterleitung der Daten stecken und die Blattknoten nehmen nicht aktiv an der Kooperation teil. Deshalb wird bei SplitStream der Datenstrom geteilt (in Stripes) und jeder Teil über einen separaten Multicast-Baum geschickt. Nun wird versucht, jeden Knoten nur in einen Multicast-Baum als inneren Knoten zu verwenden. Dadurch wird die Last gleichmäÿig auf alle Knoten verteilt. Für Streaming-Daten wird dabei MDC verwendet. Wodurch auch die Robustheit des Systems gegen einen Knotenausfall verbessert werden kann. Jeder Knoten ist nur einmal interner Knoten und bei seinem Ausfall fehlt seinen Kindern nur ein kleiner Teil des Datenstromes. Dadurch ist die Qualität zwar bis zur Reparatur dieses Baumes etwas geringer, aber der Stream kann weiterhin abgespielt werden. SplitStream beruht auf dem strukturierten P2P-Overlay-Netzwerk Pastry [Rowstron und Druschel(2001)] und dem darauf aufgebauten Application-Layer-Multicast-System /015/IN99/

26 4. Verwandte Ansätze Scribe [Castro u.a. (2002)]. Nach eigenen Angaben ist die Konstruktion des Multicast- Baumes balanciert und die Verzögerung und der Stress relativ klein. Allerdings ist die Verwaltung dieser vielen Multicast-Bäume sehr komplex und aufwändig, da die Pfade unabhängig voneinander sein sollen und jeder Knoten nur einmal innerer Knoten sein darf. Der Kontroll-Overhead steigt ebenfalls, weil jeder Baum extra verwaltet werden muss Layered Peer-to-Peer Streaming Layered Peer-to-Peer Streaming [Cui und Nahrstedt(2003)] stellt eine P2P-Lösung zum Verteilen von On-Demand-Multimedia-Daten dar. Es wird davon ausgegangen, dass Nutzeranfragen asynchron ankommen und die Peers heterogene Netzwerkbandbreiten besitzen. Die Schlüsseltechniken sind Cache-and-Relay (zwischenspeichern und weiterleiten) und Layer-encodiertes 1 Streaming. Durch den Layer-encodierten Stream wird es den Peers ermöglicht, unterschiedliche Qualitäten eines Streams je nach der eigenen Leistungsfähigkeit (z. B. der eingehenden Bandbreite) zu empfangen. Jeder Peer speichert den empfangenen Stream in einem lokalen Ringpuer und kann Peers, die später diese Daten anfordern, als Quelle bedienen. Ein Peer kann verschiedene Layer von unterschiedlichen Peers parallel empfangen. Es wird ein greedy Ansatz vorgestellt, der immer die maximal mögliche, ausgehende Bandbreite der Quelle mit der geringsten Anzahl an Layern verwendet. Damit erhält ein Peer die maximal mögliche Anzahl an Layern. Der Algorithmus wird von jedem Empfängerknoten selbst berechnet. Nach eigenen Angaben wird eine eziente Nutzung der Bandbreitenressourcen der Sender-Peers, eine Skalierbarkeit durch die Bandbreitenersparnis beim Server und eine optimale Streaming-Qualität von allen Peers erreicht. Allerdings wird bei dem System nur auf die Verteilung der Daten eingegangen und nicht auf die Verwaltung der Peers. 1 Der Stream besteht aus {l0, l 1, l 2,..., l L } Layern mit l 0 als Basislayer und den restlichen Layern als Erweiterungslayer. Die Layer bauen aufeinander auf und Layer l i kann nur decodiert werden, wenn alle vorhergehenden Layer (l 0 bis l i 1 ) ebenfalls vorhanden sind. Mit der Anzahl der Layer kann die Qualität des Streams beeinusst werden /015/IN99/2253

27 4.5. Service Adaptive Multicast 4.5. Service Adaptive Multicast Ein weiterer Ansatz für Multimedia-Streaming mit Overlay-Multicast ist Service A- daptive Multicast [Banerjee u.a. (2003)] (SAM). SAM geht davon aus, dass verschiedene Nutzer die Daten auf unterschiedliche Weise erhalten wollen. Zum Beispiel benötigt ein Nutzer die Daten verschlüsselt oder den Audio-Stream in einer anderen Sprache, wobei ein anderer Nutzer einen transcodierten Stream benötigt. In SAM existiert eine globale Informationsbasis in Form einer skalierbaren, fehlertoleranten und verwaltungsfreien verteilten Hash-Table (DHT2). Dabei ndet eine DHT- Topologie wie bei CAN [Ratnasamy u.a. (2001)] Verwendung. Mit Hilfe von einem Landmark-Clustering wie in [Ng und Zhang (2001)] wird für jeden Knoten ein Lokalitätsvektor (Landmark-Vektor) erzeugt. Anhand dieser Vektoren, können die Entfernungen zwischen zwei Knoten bestimmt werden. Da einfaches Landmark-Clustering jedoch bei nahen Knoten relativ ungenau ist, wird hierarchisches Landmark-Clustering verwendet. Zusätzlich erfolgt eine Adaptierung des Vektors mit Hilfe von Round Trip Times (RTT). Bei hierarchischem Landmark-Clustering wird zuerst die grobe Position mit Hilfe von globalen Landmarks bestimmt und dann durch lokalen Landmarks verfeinert. Mit diesen Lokalitäts-Informationen, die in der globalen DHT gespeichert sind, wird ein Multicast-Baum erzeugt. Nach eigenen Angaben besitzt SAM sehr schnelle Algorithmen zum Erstellen und Verändern des Baumes, bei denen zudem meist nur lokale Änderungen notwendig sind. Bei dem Erzeugen von neuen Pfaden wird möglichst auf existierende nahe Pfade zurückgegrien. Die Mechanismen sind daher sehr skalierbar und können so mit einer sehr groÿen Anzahl an Service-Anbietern und auch Service-Empfängern umgehen. Bei SAM sind zwar mehrere Service-Anbieter vorgesehen, aber das kooperative Senden von Daten von mehreren Sendern zu einem Empfänger wurde nicht realisiert. Jeder Empfänger kann eigene Anforderungen an die Daten haben (z. B. nur einen Audio- Stream) und ist so möglicherweise inkompatibel zu anderen Knoten, die wiederum andere Anforderungen aufweisen (z. B. Audio- und Video-Stream). Auf die daraus resultierenden Probleme, dass dadurch nur noch eine ungenügende Anzahl von anbie- 2 Distributed Hash Table /015/IN99/

28 4. Verwandte Ansätze tenden Knoten existiert, wird nicht eingegangen PeerCast PeerCast [Deshpande u.a.(2002)] ist eine Live-Streaming Architektur über ein dynamisches P2P-Netzwerk. Ein Peering-Layer ermöglicht einen ezienten Aufbau und Pege des Overlay-Netzes. Die Overlay-Struktur ist ein (Multicast-)Baum mit der Quelle als Wurzel. Das Peering-Layer ist hierbei die Kernentwicklung und bendet sich zwischen der Transport- und Anwendungsschicht. Die Knoten koordinieren sich innerhalb dieses Peering-Layers selbst und pegen den Multicast-Baum. Existierende Anwendungen müssen nicht geändert werden, um mit Hilfe dieses Peering-Layers Streaming zu betreiben. Es ist auf einfache Art und Weise möglich mit hunderten autonomen und kurzlebigen3 Knoten eine hochdynamische Gruppe zu bilden. Die nach Ausfall eines Knotens abgetrennten Teile des Netzes werden wieder in den Baum eingegliedert, ohne dass zu groÿe Datenverluste entstehen. Da jeder Knoten seine Ressourcen (Rechenleistung, Speicher, Bandbreite) selbst am besten kennt, entscheidet jeder Knoten für sich wie viele Clients er bedienen kann. EinneuerKnotenwirdvonderWurzeldesBaumesanimmerweiternachuntengeleitet, bis er einen Server gefunden hat, der noch über freie Kapazitäten verfügt. Für die Auswahl des Kindknotens können verschiedene Methoden angewendet werden. Neben der zufälligen oder Round-Robin Methode steht noch Smart-Placement zur Verfügung, wobei versucht wird anhand der Position4 im Netzwerk die Knoten weiterzuleiten. Das kombinierte Senden von Daten von mehreren Servern an einen Knoten ist hier nicht möglich und es existiert nur eine geringe Berücksichtigung der Lokalität. 3 im Minutenbereich 4 Der Knoten wird zu dem Kindsknoten weitergeleitet, zu dem er die kürzeste Latenzzeit hat /015/IN99/2253

29 4.7. Scattercast 4.7. Scattercast Scattercast [Chawathe (2003)] ist ein Ansatz für Live-Streaming von einem auf eine Anwendung anpassbaren hybriden Overlay-Netzwerks mit Scattercast Proxys. Die Proxys werden über ein Netz von Unicast-Verbindungen untereinander verbunden. Ein Distance Vector Multicast Routing Protocol (DVMRP) [RFC 1075 (1988)] berechnet dann einen Source-Routed-Reverse-Shortest-Path-Tree für jede Quelle. Die Clients verbinden sich dann zu einem lokalen Proxy und beziehen von ihm ihre Daten. An dieser Stelle kann dann lokal auch Netzwerk-Multicast verwendet werden End System Multicast [Chu u.a. (2002)] haben mit End System Multicast (ESM5) einen Ansatz für eine Gruppenkommunikation auf der Anwendungsebene entwickelt. Für die Realisierung von ESM wurde das Narada-Protokoll entwickelt, das die Endsysteme in einer selbstorganisierenden Overlay-Struktur auf einer voll dezentralisierten Weise verwaltet. Alle Gruppenmitglieder werden in einem Overlay-Netz verwaltet und sobald ein Sender Daten an eine Menge von Empfängern senden will, wird ein Spannbaum aufgebaut. Der Spannbaum wird mit Hilfe einer eigenen Version von DVMRP [RFC 1075 (1988)] erzeugt. Durch die ständige Überwachung der Verbindungen wird die Qualität des Netzes ständig verbessert, da die Verbindungen gegebenenfalls verändert werden um einen guten Spannbaum aufzubauen. Narada ist sehr robust gegenüber Ausfällen von Endsystemen und dynamischen Änderungen von Gruppenmitgliedschaften, da jedes Mitglied eine Liste über alle anderen Mitglieder einer Gruppe verwaltet. Diese Listen müssen allerdings ständig aktuell gehalten werden, was einen erheblichen Verwaltungsaufwand darstellt und die Skalierbarkeit einschränkt, sodass das ESM auf kleine bis mittlere Gruppengröÿen (einige hundert Mitglieder) beschränkt ist. 5http://esm.cs.cmu.edu /015/IN99/

30 4. Verwandte Ansätze 4.9. Zigzag Zigzag [Tran u.a. (2003b)] [Tran u.a. (2003a)] ist eine P2P-Technologie für das Live- Streaming der bandbreitenintensiven Multimedia-Daten von einer Quelle zu einer groÿen Menge an Empfängern im Internet. Dies wird über eine Implementierung eines Multicast auf der Anwendungsebene erreicht. Jeder Knoten wird als ein Peer angesehen, der seine schon erhaltenen Daten weiteren Knoten zur Verfügung stellen kann. Dabei wird ein Verteilungsbaum (Multicast-Baum) aufgebaut, dessen Wurzel der Server6 ist. Die Ende-zu-Ende-Verzögerung wird groÿ, wenn viele Empfänger vor einem aktuell betrachteten Knoten liegen, also nahe den Blättern im Baum. Um diese Verzögerung zu verringern, muss die Baumhöhe klein sein. Mit kleiner Baumhöhe erhöht sich allerdings der Grad der Knoten. Dabei entsteht ein Engpass bei diesem Knoten und die Verzögerung steigt wieder. Deswegen sollte der Knotengrad durch eine Konstante beschränkt werden. Für die Bewertung der Skalierbarkeit eines solchen Systems ist der Kontroll-Overhead7 ein wichtiges Kriterium. Er sollte möglichst klein und lokal begrenzt (keine Server- Interaktion) gehalten werden. Zigzag verwendet zwei verschiedene Strukturen: die administrative Organisation und den darauf aufgebauten Multicast-Baum. Die administrative Organisation organisiert alle Empfänger in einer Hierarchie von Clustern, welche in der Gröÿe beschränkt sind. Die Wege der Datenübertragung werden im Multicast-Baum festgelegt. In Abbildung 4.1 werden diese zwei Strukturen veranschaulicht. Eine administrative Organisation von Peers ist in der Abbildung 4.1(a) zu sehen. Hierbei handelt es sich um eine schichtenbasierte Clusterhierarchie, die nach folgenden Regeln deniert ist (Nachfolgend gilt: H ist die Anzahl der Layer, N die Anzahl der Knoten, k > 3 ist eine Konstante.): Layer-0 beinhaltet alle Peers. Peers in Layer-j (j<h 1) sind eingeteilt in Cluster der Gröÿe [k, 3k]. 6 Da es nur eine Ursprungsquelle gibt, wird sie hier als Server bezeichnet. 7 Der Kontroll-Overhead entspricht dem Kommunikationsaufwand, der für die Aufrechterhaltung des Netzwerkes (insbesondere des Multicast-Baums) notwendig ist /015/IN99/2253

31 4.9. Zigzag (a) Administrative Organisation (b) Multicast-Baum Abbildung 4.1.: Zigzag-Struktur [Tran u.a. (2003b)] Layer-(H 1) hat nur einen Cluster der Gröÿe [2, 3k]. Ein Peer in einem Cluster auf Layer-j wird zum Head dieses Clusters gewählt. Dabei wird er automatisch Mitglied in einem Cluster auf Layer-j +1 (j<h 1). Der Server ist Head aller Cluster, denen er angehört. Ein Peer in einem Cluster auf Layer-j wird Associate-Head dieses Clusters, wobei dieser Peer jedoch nicht schon Head dieses Clusters sein darf. Die Ausnahme ist der Server auf Layer-(H 1), dort ist er Head und Associate-Head gleichzeitig. Die Beschränkung der Cluster nach oben mit 3k statt 2k dient der Vermeidung des /015/IN99/