Document [original]

Adaptive Overlays in Peer-to-Peer Netzwerken

vorgelegt von

M.Sc.Wirtschaftsinformatiker

Alexander L¨

oser

Von der Fakult¨

at IV Elektrotechnik und Informatik

der Technischen Universit¨

at Berlin

zur Erlangung des akademischen Grades

Doktor der Ingenieurwissenschaften

– Dr.-Ing. –

genehmigte Dissertation

Promotionsausschuss:

Vorsitzender: Prof. Dr. Sahin Albayrak

Berichter: Prof. Dr. Herbert Weber

Berichter: Prof. Dr. Wolfgang Nejdl

Tag der wissenschaftlichen Aussprache: 28. September 2005

Berlin 2005

D 83

Kurzfassung

Drei aktuelle Trends haben neue Perspektiven f¨

ur die Recherche in Unternehmens-

daten geschaffen: Eine Explosion lokal gespeicherter Daten, der Bedarf des Aus-

tausches dieser Daten in und zwischen einzelnen Unternehmen und ein zunehmen-

der Kundenwunsch nach einer integrativen Suche in lokalen und entfernten Quel-

len. Alle drei Aspekte zusammen bewirken einen Marktwert f¨

ur Dienste der Art

’Integrierte Suche’.

Ein wesentlicher Teilaspekt eines unternehmens¨

ubergreifenden Suchdienstes

ist die Auswahl relevanter Datenquellen, beispielsweise vernetzte Desktops im Un-

ternehmen. Der Mehrwert dieses Dienstes entsteht in der effizienten und geschick-

ten Auswahl von Quellen; der Dienst soll m¨

oglichst wenig Quellen anfragen und

trotzdem m¨

oglichst alle relevanten Quellen finden. Aufgrund der Un¨

ubersehbarkeit

und Dynamik der Daten sowie der Volatilit¨

at und Autonomie der Quellen ist die

Entwicklung dieses Dienstes eine besondere Herausforderung f¨

ur die Informatik.

Die vorliegende Dissertation beschreibt einen solchen Dienst am Beispiel von

Peer-to-Peer Netzwerken. Inspiriert durch Milgram’s Untersuchungen der Small

World Netzwerke entwickeln wir eine neue Routing Strategie f¨

ur ein volatiles

Netzwerk, in dem ein Peer eine Person repr¨

asentiert. Aus den Interaktionen der

Peers leiten wir zus¨

atzliche Verbindungen im Netzwerk, sogenannte Shortcuts, ab,

die jeder Peer lokal in einem Index speichert. Dadurch entsteht ein Overlay Netz-

werk, welches eine f¨

ur das effiziente Routing besonders hilfreiche Anordnung der

Peers aufweist: Peers mit ¨

ahnlichen Interessen sind direkt miteinander vernetzt. Ei-

ne dynamische Kombination von themenspezifischen, vernetzungsabh¨

angigen und

zuf¨

alligen Routing Strategien entlang der Shortcuts erm¨

oglicht die gezielte und ef-

fiziente Auswahl relevanter Quellen mit minimaler Belastung des Netzwerkes und

ohne manuelle Unterst¨

utzung durch den Benutzer. F¨

ur die Verwaltung der loka-

len Shortcut Indices entwickeln wir einen neue Indexstrategie. Diese erlaubt die

gezielte Aktualisierung lokal gespeicherter Shortcuts und ber¨

ucksichtigt sowohl

Anderungen der Verf¨

ugbarkeit von Quellen als auch von Daten im Netzwerk.

Die Ergebnisse der vorliegenden Arbeit unterst¨

utzen maßgeblich die Entwick-

lung eines integrierten Suchdienstes. Simulationen zeigen, dass, gegen¨

uber ver-

gleichbaren Ans¨

atzen, der Recall f¨

ur eine Anfrage deutlich erh¨

oht und die Kosten

f¨

ur eine Anfrage drastisch gesenkt werden. Shortcut Overlay Netzwerke sind ro-

bust, sie tolerieren wechselnde Interessen sowie eine hohe Volatilit¨

at der Peers.

Diese Eigenschaften, kombiniert mit der vollst¨

andig lokalen Erstellung, Auswahl

und Verwaltung der Indices, machen Shortcut Overlay Netzwerke zu einer sehr

vielversprechenden Alternative zu Flooding-basierten Ans¨

atzen oder verteilten Has-

htabellen.

Abstract

In research and business currently we notify three key trends: the explosion of un-

structured data; the critical need to formally manage content; and internetworking

and collaboration within and between enterprises.

Peer-to-Peer information systems address the need to access content wherever

it resides, to produce content while maintaining control over it, and to collabora-

te efficiently by sharing real-time data within a distributed network of stakehol-

ders. Enterprises that are highly dependent on sharing real-time information across

geographically spread knowledge workers are likely to benefit immediately from

peer-to-peer information systems.

This thesis focuses on the issue of determining a relevant peer in a completely

decentralized and volatile setting without any static peers, such as necessitated by

peer-to-peer information systems in virtual organizations. Example applications,

such as the networked semantic desktop and legal music sharing, serve as ratio-

nale throughout the thesis. We discuss, which routing strategies exist, when they

should be used, and -most importantly- how can we enhance their recall and lower

their communication costs. The full autonomy of peers as well as the full con-

trol of their own resources preclude prominent resource location and query routing

schemes, such as distributed hash tables. We propose a new resource location and

a semantic query routing approach that exploits social metaphors of topical ex-

perts and experts’ experts as well as semantic similarity of queries and information

sources. The novel design principle of our approach lies in the dynamic adaptation

of the network topology, driven by the history of successful or semantically similar

queries. This is memorized by using bounded local shortcut indexes storing seman-

tically labelled shortcuts and a dynamic shortcut selection strategy, which forwards

queries to a community of peers that are likely to best answer queries.

Our results support the development of a completely decentralized peer-to-peer

information system significant. Extensive simulations show that the clustering of

peers within semantic communities drastically improves the overall performance

of our algorithm even in a highly volatile setting, while our index policy locally

indices the ’right’ peers, that provide resources to the core interests of a requesting

peer. Shortcut overlays are robust; they tolerate interests shifts and high network

volatility. These attractive properties, combined with the locality preserving de-

sign of the index management and peer selection algorithm, pose shortcut overlay

networks as a very promising alternative to state of the art semantic routing ap-

proaches.

Danksagung

Viele Menschen in meinem beruflichen und privaten Umfeld haben mich beim

Entstehen dieser Arbeit begleitet. Zuerst danke ich meinen beiden Betreuern f¨

ihre Unterst¨

utzung und ihren Rat w¨

ahrend der Anfertigung dieser Arbeit. Profes-

sor Weber stellte mir in der CIS Gruppe an der Technischen Universit¨

at Berlin die

Arbeitsumgebung und die wissenschaftliche Infrastruktur zur Verf¨

ugung. Professor

Nejdl vom Forschungszentrum L3S half mir bei der Ausrichtung es Themas. Zu-

sammen begleiteten mich beide Betreuer in der Anfertigung der Arbeit und halfen

mir durch viele wertvolle Kommentare.

Ich bedanke mich bei meinen Kollegen der Fachgruppe ’Computergest¨

utzte In-

formationssysteme’ f¨

ur die sch¨

one Zeit und die vielen kontroversen Diskussionen.

Mein Dank geht an Dr. Ralf-Detlef Kutsche f¨

ur die Unterst¨

utzung meiner For-

schung. Bei Lutz Friedel und Claudia Gantzer bedanke ich mich f¨

ur die prompte

L¨

osung technischer und administrativer Probleme.

Diese Arbeit h¨

atte nicht ohne die finanzielle Begleitung durch das Berlin- Bran-

denburger Graduiertenkolleg f¨

ur verteilte Informationssysteme (DFG Stipendium

GRK 316/3, Sprecher Prof. Dr. Oliver G¨

unther) geschrieben werden k¨

onnen. Prof.

Dr. Felix Naumann von der Humboldt Universit¨

at danke ich besonders f¨

ur sei-

ne stetig konstruktiven Kommentare. Durch die regelm¨

aßigen Treffen des kleinen

und großen GKs erhielt ich kontinuierlich wertvolle Anregungen und lehrreiche

Kritiken.

Viele, wichtige und hilfreiche Diskussionen, Anregungen zum ’Um die Ecke

Denken’ und die notwendige Motivation erhielt ich von der Peer-to-Peer Commu-

nity am Forschungszentrum L3S, insbesondere Dr. Wolf-Tilo Balke, Dr. Martin

Wolpers, Wolf Siberski und Uwe Thaden und am AIFB Karlsruhe, insbesondere

von Prof. Dr. Steffen Staab und Christoph Tempich. Ganz herzlich bedanke ich

mich auch bei meinen Diplomanden Bastian Quilitz, Kai Schubert und Frederick

Zimmer f¨

ur deren Unterst¨

utzung bei der Implementierung der Simulationsumge-

bung. Ein wichtiger Begleiter seit meinem ersten Studien-Semester war und ist

Prof. Dr. Harald Brandenburg von der FHTW Berlin, der mir auch in schwierigen

Zeiten mit Rat und Hilfe zur Seite stand. Dr. Andy Seaborne und dem Europ¨

aischen

Leonardo Programm danke ich f¨

ur die finanzielle und inhaltliche Unterst¨

utzung

w¨

ahrend meines Aufenthaltes in der Semantic Web Gruppe in den Hewlett Packard

Research Labs Bristol.

Schließlich gilt mein Dank meinen Freunden und meiner Familie f¨

ur ihre ste-

tige Motivation und Unterst¨

utzung.

III

Inhaltsverzeichnis

I Informationssuche in Peer-to-Peer Netzwerken 1

1 Einf¨

uhrung 2

1.1 Peer-to-Peer basierte Suche von Informationen . . . . . . . . . . 4

1.2 Adaptive Overlay Cluster . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Problemstellung und Vorgehensweise . . . . . . . . . . . . . . . 8

1.4 Gliederung ............................. 10

2 Anwendungen und Architekturmodelle 12

2.1 Peer-to-Peer Netzwerke . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Anwendungen f¨

ur die Informationssuche . . . . . . . . . . . . . . 15

2.2.1 Legale Musiktauschb¨

orse.................. 15

2.2.2 Semantisch vernetzte Arbeitspl¨

atze ............ 16

2.3 Architekturvarianten zur Informationssuche . . . . . . . . . . . . 17

2.3.1 Grad der Zentralisierung . . . . . . . . . . . . . . . . . . 17

2.3.2 Struktur des Overlay und der Indizes . . . . . . . . . . . . 18

2.4 Zusammenfassung ......................... 22

3 Routing auf der Basis globaler Indizes 23

3.1 Edutella............................... 23

3.1.1 Registrierung von Peers im Index . . . . . . . . . . . . . 26

3.1.2 Bearbeitung von Anfragen . . . . . . . . . . . . . . . . . 28

3.1.3 Aktualisierung des Index . . . . . . . . . . . . . . . . . . 29

3.2 TOPICS............................... 32

3.2.1 Abbildung von Themen-Hierarchien in einer DHT . . . . 36

3.2.2 Semantisches Browsen in einer DHT . . . . . . . . . . . 38

3.2.3 Lastverteilungstrategien . . . . . . . . . . . . . . . . . . 39

3.3 VerwandteArbeiten......................... 42

3.4 Zusammenfassung ......................... 43

Inhaltsverzeichnis

II Adaptive Overlays auf der Basis lokaler Shortcut Indizes 45

4 Der INGA Ansatz 46

4.1 Anforderungen ........................... 46

4.2 Soziale Netzwerke und das Small World Ph¨

anomen . . . . . . . . 50

4.2.1 Charakteristiken von Small World Netzwerken . . . . . . 51

4.2.2 Definition von Shortcuts auf Basis sozialer Metaphern . . 52

4.2.3 Formale Definition von Shortcut Netzwerken . . . . . . . 55

4.3 INGA Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . 57

4.3.1 Netzwerk Management . . . . . . . . . . . . . . . . . . . 57

4.3.2 Lokales Dokumenten Repository . . . . . . . . . . . . . . 59

4.3.3 Management und Auswahl von Shortcuts . . . . . . . . . 60

4.3.4 Format der Anfrage- und Resultatnachrichten . . . . . . . 61

4.4 VerwandteArbeiten......................... 63

4.5 Zusammenfassung ......................... 64

5 Erzeugung von Shortcuts 65

5.1 Merkmale von Shortcuts . . . . . . . . . . . . . . . . . . . . . . 65

5.2 Anfrageabh¨

angigeShortcuts .................... 67

5.2.1 Content Provider Layer . . . . . . . . . . . . . . . . . . . 67

5.2.2 Recommender Layer . . . . . . . . . . . . . . . . . . . . 69

5.3 Anfrageunabh¨

anigeShortcuts.................... 72

5.3.1 Default Network Layer . . . . . . . . . . . . . . . . . . . 73

5.3.2 Bootstrapping Layer . . . . . . . . . . . . . . . . . . . . 74

5.4 VerwandteArbeiten......................... 76

5.5 Zusammenfassung ......................... 77

6 Index Verwaltung und Routing Modell 78

6.1 Interaktionen und Ablaufmodell . . . . . . . . . . . . . . . . . . 78

6.2 Dynamisches Routing Modell . . . . . . . . . . . . . . . . . . . 80

6.2.1 GreedyRouting....................... 80

6.2.2 High Out-Degree Routing . . . . . . . . . . . . . . . . . 82

6.2.3 Firework Query Routing . . . . . . . . . . . . . . . . . . 83

6.2.4 Serendipity Routing . . . . . . . . . . . . . . . . . . . . 83

6.2.5 Dynamische Auswahl der Strategie . . . . . . . . . . . . 84

6.3 IndexManagement ......................... 86

6.4 VerwandteArbeiten......................... 89

6.4.1 Index Management . . . . . . . . . . . . . . . . . . . . . 89

6.4.2 Routing Ans¨

atze ...................... 90

6.5 Zusammenfassung ......................... 92

Inhaltsverzeichnis

7 Simulation und Evaluierung 93

7.1 Modellierung des Systems . . . . . . . . . . . . . . . . . . . . . 93

7.1.1 Initiale Struktur des Netzwerkes . . . . . . . . . . . . . . 93

7.1.2 Verteilung der Anfragen und Themen . . . . . . . . . . . 94

7.1.3 Modellierung von Dynamik . . . . . . . . . . . . . . . . 96

7.2 Methodik der Simulation . . . . . . . . . . . . . . . . . . . . . . 96

7.2.1 Metriken .......................... 97

7.2.2 Implementierung ¨

ahnlicher Systeme . . . . . . . . . . . . 99

7.3 Evaluierung............................. 100

7.3.1 Verhalten in einem statischen Netzwerk . . . . . . . . . . 100

7.3.2 Verhalten in einem dynamischen Netzwerk . . . . . . . . 104

7.3.3 Beitrag der Layer und Einfluss der Index Parameter . . . . 108

7.4 Zusammenfassung ......................... 113

III Diskussion 115

8 Zusammenfassende Diskussion 116

8.1 Zusammenfassung ......................... 116

8.2 Perspektiven zuk¨

unftiger Forschung . . . . . . . . . . . . . . . . 120

Literaturverzeichnis 122

Abbildungsverzeichnis

1.1 Adaptive Overlay Cluster . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Klassifikation von Information Sharing Systemen . . . . . . . . . 19

3.1 HyperCuP Super-Peer Topologie . . . . . . . . . . . . . . . . . . 25

3.2 Super-Peer/Peer Routing Index . . . . . . . . . . . . . . . . . . . 26

3.3 Super-Peer/Super-Peer Routing Index . . . . . . . . . . . . . . . 28

3.4 SP/SP Index von SP2........................ 28

3.5 Unterst¨

utzte Anfragen f¨

ur unterschiedliche Granularit¨

aten . . . . . 29

3.6 Beispiel f¨

ur das Edutella Routing Modell . . . . . . . . . . . . . 30

3.7 HyperCuP Topology and Spanning Tree Example . . . . . . . . . 31

3.8 Semantisches Overlay Netzwerk . . . . . . . . . . . . . . . . . . 33

3.9 Architekturmodell f¨

ur das Themen-Hierarchie-basierte Routing . 34

3.10 Verteilung von Dokumenten ¨

uber eine Themen-Hierarchie . . . . 37

4.1 Visualisierung der Indizes an einem Beispiel . . . . . . . . . . . . 53

4.2 Architektur eines INGA Peers . . . . . . . . . . . . . . . . . . . 58

4.3 INGA Datenmodel und Beispiel . . . . . . . . . . . . . . . . . . 59

5.1 Klassifikation von Shortcuts . . . . . . . . . . . . . . . . . . . . 67

5.2 Content Provider Shortcut Erstellung . . . . . . . . . . . . . . . . 68

5.3 Recommender Shortcut Erstellung (aktiv) . . . . . . . . . . . . . 71

5.4 Recommender Shortcut Erstellung (passiv) . . . . . . . . . . . . 72

5.5 Erstellung des Default Network Overlay . . . . . . . . . . . . . . 74

5.6 Bootstrapping Shortcut Erstellung . . . . . . . . . . . . . . . . . 76

6.1 Routing und Aktualisierung . . . . . . . . . . . . . . . . . . . . . 79

7.1 Verteilung der Autoren ¨

uber die Themen (Popularit¨

at der Themen). 95

7.2 Verteilung der Themen ¨

uber die Autoren . . . . . . . . . . . . . . 95

7.3 Verteilung der Verf¨

ugbarkeit .................... 97

7.4 In der Simulation verwendete Parameter . . . . . . . . . . . . . . 98

VII

Abbildungsverzeichnis

7.5 Recall: Statisches Netzwerk . . . . . . . . . . . . . . . . . . . . 101

7.6 K¨

urzester Pfad: Statisches Netzwerk . . . . . . . . . . . . . . . . 102

7.7 Nachrichten: Statisches Netzwerk . . . . . . . . . . . . . . . . . 103

7.8 Message Gain: Statisches Netzwerk . . . . . . . . . . . . . . . . 104

7.9 Recall: Dynamisches Netzwerk . . . . . . . . . . . . . . . . . . . 105

7.10 Nachrichten: Dynamisches Netzwerk . . . . . . . . . . . . . . . . 106

7.11 Message Gain: Dynamisches Netzwerk . . . . . . . . . . . . . . 107

7.12 Message: Beitrag einzelner Layer im dynamischen Netzwerk . . . 108

7.13 Recall: Beitrag einzelner Layer im dynamischen Netzwerk . . . . 109

7.14 Message Gain: Beitrag einzelner Layer im dynamischen Netzwerk 110

7.15 Vergleich der Indexgr¨

osse im dynamischen Netzwerk . . . . . . . 111

7.16 Vergleich der Indexewichtung . . . . . . . . . . . . . . . . . . . 112

VIII

Teil I

Informationssuche in

Peer-to-Peer Netzwerken



Einf¨

uhrung

Das Internet wurde traditionell als eine Kommunikationsinfrastruktur betrachtet.

Mit ihr ist es m¨

oglich, so der Anspruch, jede Information zu jedem Zeitpunkt an

jeden Ort zu transportieren. Mit der Einf¨

uhrung des World Wide Web trat ein an-

derer Aspekt der Nutzung des Internets in den Vordergrund: Nicht mehr die ge-

zielte Kommunikation zwischen Partnern, sondern die indirekte Kommunikation

uber Web-Pages steht im Mittelpunkt der Betrachtung. Deren Folge ist eine ¨

Uber-

schwemmung mit einer Flut von Informationen. Das Future Net [Web04] - das

Internet der kommunizierenden Gemeinschaften - wird neue, abstraktere Kom-

munikationstechnologien zur Verf¨

ugung stellen m¨

ussen, die einer zielgerichteten

Kommunikation von Individuen und Gemeinschaften von Individuen mit ihren je-

weiligen spezifischen Eigenschaften gerecht wird.

Parallel zur Entwicklung des World-Wide-Web hat sich das Peer-to-Peer (P2P)

Paradigma zu einem der meistdiskutierten Ph¨

anomene in der j¨

ungeren Geschichte

der Informationstechnologie herausgebildet. Peer-to-Peer Netzwerke bilden die In-

frastruktur f¨

ur virtuelle Gemeinschaften, die Ressourcen teilen, den Informations-

austausch beschleunigen und neuartige kollaborative Arbeitsumgebungen erm¨

ogli-

chen. Den enormen Erfolg von Peer-to-Peer Technologie belegen die popul¨

aren

File Sharing Systeme, wie Napster, Gnutella und ihre Nachfolger. Durch die In-

stallation einer kostenlosen Software und ohne Ber¨

ucksichtigung besonderer admi-

nistrativer oder finanzieller Vereinbarungen wird der Computer spontan Teil einer

existierenden, v¨

ollig dezentralen, selbstorganisierenden Infrastruktur.



Napster und Gnutella zeigen den hohen Bedarf der Musik-Community, Audio

Clips ¨

uber das Internet mit anderen Musik-Fans auszutauschen. Das Spektrum

potentieller Anwendungsbereiche f¨

ur den unternehmerischen Einsatz von Peer-to-

Peer Netzwerken ist jedoch deutlich breiter. Die Nutzung von Peer-to-Peer Netz-

werken f¨

ur die Publikation, die Suche und den Austausch von Office Dokumenten

innerhalb der ’Community’ eines Unternehmens wurde bereits f¨

ur eine vergleichs-

weise kleine Anzahl von Nutzern in Systemen, wie YOUSERV [AGS02] mit meh-

reren hundert Nutzer oder in Groove [Net04], in mehreren kleinen Gruppen mit bis

zu hundert Nutzern, realisiert. Durch eine Suche und den Austausch von Dokumen-

ten ¨

uber eine Peer-to-Peer Infrastruktur wird kollaborative Wissens-Koproduktion,

in virtuellen, spontan miteinander verbundenen Communities, innerhalb und au-

ßerhalb institutioneller Barrieren erst erm¨

oglicht bzw. deutlich vereinfacht. Neue

Formen der lokalen Suche, wie durch die Google Desktop Search, werden eine

Peer-to-Peer basierte Suche in den lokalen Desktops aller Mitarbeiter eines Un-

ternehmens oder einer virtuellen Organisation unterst¨

utzen. Jede Art von Doku-

ment wird schnell auffindbar sein - sei es eine Textdatei, eine E-Mail, eine Tabelle

oder eine andere Art von Dokument. Ein weiteres Beispiel ist das System Bibster

[HBM+04]. Es erlaubt das Management, die globale Suche, Publikation und Iden-

tifikation inkonsistenter bibliographischer Metadaten innerhalb der Research Com-

munity. Durch die Peer-to-Peer Philosophie tr¨

agt jeder Peer einen Teil der Kosten,

z.B. Bandbreite oder Speicherplatz, f¨

ur die Suche und Publikation der Metadaten.

Im medizinischen Bereich wird die sichere und standardisierte Suche in Patien-

tendaten durch die behandelnden ¨

Arzte ohne eine zentrale Instanz ¨

uber ein Peer-

to-Peer System realisiert. Beispielsweise erlaubt das System Care Data Exchange

[Exc04] die Suche in von anderen ¨

Arzten erfassten Patientendaten, wie bereits fest-

gestellte allergische Reaktionen auf verordnete Medikamente, durchgef¨

uhrte EKGs

vor einem Herzanfall oder den Schwangerschaftsverlauf einer Mutter. Es erlaubt

die Korrektur inkonsistenter Eingaben durch den Arzt und erm¨

oglicht die Einspa-

rung von Kosten f¨

ur eine zentrale Infrastruktur. Dar¨

uber hinaus ist geplant, auch

Patienten Einsicht in Ihre eigenen Daten zu geben. Zum Schutz der Daten m¨

ussen

sich die behandelnden ¨

Arzte ¨

uber einen zentralen Index anmelden. Der Index erh¨

alt

Verweise f¨

ur jeden Patienten auf die in bisher behandelten ¨

Arzte. Die eigentlichen

Daten der Patienten werden lokal bei den einzelnen ¨

Arzten gespeichert.

Die Einfachheit und ”kostenlose“Nutzung vorhandener Peer-to-Peer Infrastruk-

turen, ohne eine ¨

Uberwachung und Kontrolle durch eine zentrale Steuerungsin-

stanz, hat in den letzten Jahren zu einem Anwachsen der Nutzeranzahl gef¨

uhrt

und eine enorme Nachfrage nach Verfahren und Technologien stimuliert, wie auch

grosse Peer-to-Peer Netzwerke effizienter und noch kosteng¨

unstiger realisiert wer-

den k¨

onnen. Durch die starke Verteilung der Inhalte ¨

uber eine grosse Anzahl von

Peers und deren Autonomie und Dynamik entstehen Herausforderungen bei der



1.1. Peer-to-Peer basierte Suche von Informationen

Realisierung von Peer-to-Peer-basierten Information Sharing Netzwerken. Beispie-

le sind Verfahren f¨

ur die gerechte Verteilung der Kosten ¨

uber die Peers, wie Band-

breite und Speicherplatz, die ¨

Uberbr¨

uckung semantischer Heterogenit¨

aten bei der

Annotation oder die Reduzierung von Netzwerkkosten beim h¨

aufig auftretenden

Eintreten und Verlassen einzelner Peers in das Netzwerk (Churn). Die vorliegende

Arbeit widmet sich der wichtigsten fundamentalen Fragestellung ohne deren Be-

antwortung die Verteilung der Inhalte obsolet wird: Was ist eine effiziente Strategie

f¨

ur die Suche und das Auffinden von Dokumenten in einem solchen Netzwerk?

1.1 Peer-to-Peer basierte Suche von Informationen

Peer-to-Peer Netzwerke weisen im Gegensatz zu zentralen oder Client/Server ba-

sierten Architekturen folgende interessante Besonderheiten auf:

•Verf¨

ugbarkeit und Dynamik der Knoten. Begr¨

undet durch die Autonomie

der einzelnen Knoten und deren schiere Menge existiert eine hohe Dyna-

mik der verf¨

ugbaren Peers im Netz. So betr¨

agt in File Sharing Netzwerken

die durchschnittliche Online Zeit eines Peers ungef¨

ahr eine Stunde [Mar02,

CLL04]. Das bedeutetet einerseits, dass nach einem Ausfall oder Verlassen

des Peers s¨

amtliche von diesem Peer publizierte Inhalte nicht mehr verf¨

ugbar

sind und das andererseits die Last f¨

ur die Wartung und Selbstorganisation des

Netzwerkes auf andere Knoten ¨

ubertragen werden muss. Diese Volatilit¨

erfordert neue Technologien f¨

ur die zeitnahe Indizierung und das verteilte

Management der Inhalte.

•Selbstorganisation ohne Koordinierung durch eine zentrale Instanz. Ei-

ne verteilte Speicherung und Suche der Inhalte erfolgt h¨

aufig aus dem Wunsch

heraus, keine zentrale Instanz im System zu haben. Dieser Wunsch resultiert

eher aus ideologischen Gr¨

unden, wie dem Wunsch der lokalen Kontrolle

uber die Inhalte, der Vermeidung eines zentralen Zensors und der gerech-

ten Aufteilung der laufenden Kosten des Systems. Sekund¨

ar erfolgt inherent

eine hohe Verteilung der Inhalte aus der technischen Notwendigkeit der Ver-

meidung von Single-Point-of-Failures oder aus Gr¨

unden der Skalierbarkeit

und Robustheit [RBR+04, MKL+02].

•Verschmelzung der Anbieter- und Nachfragerrolle. Im Gegensatz zu der

h¨

aufig strengen Trennung von Informationsnachfrager (Information Con-

sumer) und Informationsanbieter (Information Provider) in zentralistischen

oder Client/Server basierten Informationssystemen verschmelzen beide Rol-

len in einem Peer-to-Peer System. Ein Peer in einem Peer-to-Peer Netzwerk,



1.1. Peer-to-Peer basierte Suche von Informationen

der h¨

aufig einen konkreten menschlichen Nutzer repr¨

asentiert, stellt ebenso

Anfragen nach Inhalten an andere Peers, wie auch von dem eigenen Peer

eingehende Anfragen beantwortet werden [NWQ+02, MKL+02].

•Technische Heterogenit¨

at der Knoten. Aufgrund der Autonomie der ein-

zelnen Knoten sind ihre technischen Zugriffseigenschaften, wie Bandbreite

und Zugriffszeit, heterogen [YGM03].

Peer-to-Peer Netzwerke f¨

ur die Suche von Dokumenten weisen dar¨

uber hinaus fol-

gende Besonderheiten auf:

•Unterschiedliche Popularit¨

at der Dokumente und Anfragen. Die Doku-

mente in Peer-to-Peer Information Sharing Systemen sind stark im Netzwerk

verteilt. Typische Gr¨

ossenordnungen aktueller File-Sharing Netzwerke be-

tragen mehrere hunderttausend Peers von denen jeder Peer wenige bis zu

mehreren tausend Dokumenten anbietet. Aufgrund der vollst¨

andig dezentra-

len Speicherung sind popul¨

are Inhalte redundant vorhanden und verbreiten

sich bei entsprechender Nachfrage auch mit hoher Geschwindigkeit. In Mu-

sik Sharing Netzwerken n¨

ahert sich die Verteilung der Inhalte und die Ver-

teilung der Anfragen ¨

uber die Peers einer ZIPF [Zip49] Verteilung an.

•Verwendung von Metadaten. Metadaten, Daten ¨

uber Daten, werden in Peer-

to-Peer Netzwerken zur Beschreibung von zwei Klassen von Entit¨

aten ver-

wendet. In aktuellen File Sharing Netzwerken werden Dokumente durch

einen homogenen Metadatensatz beschrieben. Beispielsweise sind in E- Lear-

ning Netzwerken die Standards Dublin Core und LOM zur Annotation von

Dokumenten weit verbreitet. Ebenfalls werden in unstrukturierten Peer-to-

Peer Netzwerken Peers durch (implizit gewonnene) Metadaten beschrieben.

Diese Modelle erm¨

oglichen den Einsatz von Ranking Verfahren f¨

ur Peers,

die zur Verringerung der Nachrichten f¨

ur eine Suche f¨

uhren k¨

onnen. In die-

ser Arbeit werden beide Formen von Metadaten in Peer-to-Peer Netzwerken

untersucht.

•Strategien f¨

ur eine verteilte Suche. Aufgrund des h¨

aufig fehlenden zentra-

len Index haben sich zwei Strategien f¨

ur die Suche etabliert: Strategien mit

einem globalen (verteilten) Index und Strategien mit einem lokalen Index.

Beispiele f¨

ur die Suche auf der Basis eines globalen (verteilten) Index sind

Verteilte Hashtabellen (Distributed Hash Tables) und Routing Indizes. Eine

Suche auf der Basis lokal vorhandener Informationen erfolgt auch durch das

Uberfluten des Netzwerkes oder durch das Prinzip der Shortcuts. Ein Ziel der

aktuellen Forschung ist die Minimierung der Nachrichten f¨

ur eine Suchan-



1.2. Adaptive Overlay Cluster

frage und f¨

ur die Pflege des verwendeten Index. In dieser Arbeit stellen wir

Suchstrategien vor, die sowohl globale und lokale Indizes ber¨

ucksichtigen.

Die Existenz dieser besonderen Eigenschaften von Peer-to-Peer Systemen stellt

neue M¨

oglichkeiten f¨

ur die Gewinnung von Daten ¨

uber das Verhalten einzelner

Peers bereit und erlaubt v¨

ollig neue Ans¨

atze f¨

ur eine ganzheitlichen Optimierung

der Suche in derartigen Informationssystemen.

1.2 Adaptive Overlay Cluster

Eine der wichtigsten Funktionen in einem Peer-to-Peer Netzwerk ist die Suche

nach Inhalten f¨

ur eine gegebene Anfrage. Die globale Verf¨

ugbarkeit einer grossen

Anzahl von Anbietern von Inhalten und deren hohe Dynamik in einem Peer-to-Peer

Netzwerk erfordert neue Methoden f¨

ur eine effiziente Suche. Eine Anfrage kann

nicht mehr an alle zur Anfragezeit verf¨

ugbaren Quellen innerhalb des Netzwerkes

geleitet werden, da die Kosten, wie die Anzahl der ben¨

otigten Nachrichten, daf¨

zu gross w¨

urden. Optimal w¨

are ein Ansatz bei dem das physische Netz aller zur

Anfragezeit verf¨

ugbaren Quellen auf genau die Peers eingeschr¨

ankt werden, die f¨

eine Anfrage auch die richtigen Inhalte bereitstellen und die Anfrage beantworten

k¨

onnen. Wir bezeichnen eine solche Struktur als ein Overlay Netzwerk. In dieser

Arbeit untersuchen wir Overlay Netzwerke, die Peers auf der Basis gemeinsamer

oder ¨

ahnlicher Merkmale miteinander verbinden. Dadurch entstehen Cluster von

Peers mit Dokumenten zu einem gemeinsamen Thema. Durch die Autonomie des

einzelnen Peers sind diese nicht immer verf¨

ugbar bzw. ver¨

andern ihre verf¨

ugbaren

Dokumente. F¨

ur einen Overlay Cluster m¨

ussen adaptiv neu verf¨

ugbare Dokumen-

te und Peers selbstst¨

andig registriert, bzw. nicht mehr verf¨

ugbare Dokumente und

Peers gel¨

oscht werden. Eine Anfrage in einem solchem Netzwerk ist ein zweige-

teilter Prozess:

1. Zur Anfragezeit werden Peers gesucht, die passende Inhalte f¨

ur eine Anfrage

speichern. Die Menge dieser Peers bildet einen adaptiven Overlay Cluster f¨

diese Anfrage.

2. Die Anfrage wird an alle (oder an ausgesuchte Peers) aus dem adaptiven

Overlay weitergeleitet. Jeder Peer, der die Anfrage erh¨

alt, sucht lokal nach

f¨

ur die Anfrage passenden Dokumenten.

Durch eine solche anfragespezifische Auswahl von Peers profitieren zwei Klassen

von Akteuren:



1.2. Adaptive Overlay Cluster

Adaptive Overlay Cluster

Default Network

Overlay for ’Eric Clapton’

Query Eric Clapton

Abbildung 1.1: Adaptive Overlay Cluster

•Da die Anfrage direkt an die ”passenden “Peers gesendet wird, k¨

onnen f¨

den anfragenden Peer die Zeit bis zur ersten Antwort auf die Anfrage und

der Aufwand zur Beantwortung der Anfrage signifikant gesenkt werden.

•Im Vergleich zu einer naiven Strategie erhalten Peers, die keine f¨

ur die An-

frage passenden Inhalte publizieren, auch keine ¨

uberfl¨

ussigen Nachrichten.

Vielmehr werden die ben¨

otigten Ressourcen, wie Anzahl der Nachrichten

im Netzwerk und Rechenkapazit¨

at lokaler Peers, auf eine kleine Anzahl aus-

gew¨

ahlter Peers beschr¨

ankt.

Grafik 1.1 zeigt ein physisches Netzwerk mit sechs Peers PA, ..., PF. Die Knoten

bilden ein Peer-to-Peer Netzwerk. Jeder Peer publiziert Dokumente, beispielswei-

se Audio Clips, und stellt Anfragen. In der Grafik stellt Peer PEeine Anfrage Q1

zu Audioclips von ”Eric Clapton“. Die Peers B, C und F speichern Audio Clips zu

Q1. Sie sind untereinander direkt verbunden und bilden einen adaptiven Overlay

Cluster f¨

ur die gestellte Anfrage. Die Anfrage wird an einen PEbekannten Peer ge-

leitet, der Mitglied des Overlays f¨

ur die Anfrage ist. Innerhalb des Overlays sucht

jeder Peer lokal Audio Clips zu Q1und sendet die gefundenen Resultate an PE

zur¨

uck.

Die Realisierung einer Zuordnung von Peers zur adaptiven Overlay Cluster soll-

te weitestgehend automatisiert erfolgen, da eine manuelle Auswahl der Peers auf-

grund der hohen Anzahl der Peers und ihrer hohen Dynamik nicht mehr manuell

durchf¨

uhrbar ist. In dieser Arbeit untersuchen wir dazu zwei Ans¨

atze. Im ersten

Ansatz registrieren Peers in einem globalen, verteilten Index, welche Anfragen zu

welchen Dokumenten sie unterst¨

utzen. Im zweiten Ansatz beobachtetet ein Peer

aufgrund bereits gestellter Anfragen des eigenen oder anderer Peers, welche Peers



1.3. Problemstellung und Vorgehensweise

im Netzwerk Antworten liefern konnten und verwaltet diese Informationen in ei-

nem lokalen Index. Auf dessen Basis w¨

ahlt er f¨

ur eine Anfrage die besten Peers

aus.

1.3 Problemstellung und Vorgehensweise

Diese Arbeit behandelt das Problem der effizienten Suche von Inhalten in Peer-to-

Peer Netzwerken. F¨

ur ein gegebenes Netzwerk, bestehend aus einer Menge von dy-

namischen Peers die Inhalte anbieten und einem Peer der bestimmte Inhalte sucht,

entwickeln wir Methoden (I) f¨

ur das aktive und passive Gewinnen von Metada-

ten anderer Peers im Netzwerk, (II) der Auswahl der besten Peers f¨

ur eine An-

frage ausschließlich auf der Basis lokalen Wissens und (III) f¨

ur die Kombination

verschiedener Routingstrategien. Wir teilen das Problem in folgende Teilprobleme

auf:

•Definition globaler Indexstrukturen. Wir untersuchen zwei Ans¨

atze, bei

denen Peers Metadaten ¨

uber ihre verf¨

ugbaren Dokumente in einem dezen-

tralen Index registrieren. Dazu stellen wir zwei Index Strukturen in einem

Super-Peer Netzwerk vor, bei der eine kleine Anzahl stabiler Peers den In-

dex verwaltet und eine Suche in den Profilen dynamisch im Netzwerk vor-

handener Peers erm¨

oglicht.

•Definition sozialer Metaphern. Das Routing mit der Technologie der adap-

tiven Overlay Clustern erfolgt entlang Shortcuts zu einer themenspezifischen

Menge von Peers. Wir definieren den Begriff des Shortcuts als unidirektio-

nale Relation zwischen zwei Peers. Ausgehend von der Kommunikation in

sozialen Netzwerken leiten wir Metaphern f¨

ur die Bildung von Shortcuts her

und definieren f¨

unf Typen von Shortcuts.

•Einf¨

uhrung von lokalen Indexstrukturen und einem Architekturmodell.

Shortcut Netzwerke repr¨

asentieren eine adaptive und dynamische Netzwerk-

schicht ¨

uber der physischen Netzwerkschicht. Zur lokalen und dezentra-

len Verwaltung dieses Netzwerkes definieren wir die Index-Struktur f¨

ur die

Speicherung von Shortcuts als Beziehung zwischen Anfragen eines Peers

aus der Vergangenheit und bereits gefundenen Inhalten anderer Peers. Aus-

gehend von den Basiskomponenten eines Peers in einem Informationsharing

Netzwerk stellen wir die Architektur eines Peer in einem Shortcut Netzwerk

vor.

•Gewinnung von Metadaten f¨

ur die Bewertung von Peers. Durch die hohe

Verteilung der Inhalte, die Volatilit¨

at der Peers und die fehlende zentrale



1.3. Problemstellung und Vorgehensweise

Instanz sind Metadaten zur Generierung von Shortcuts und zur Auswahl von

Peers f¨

ur eine Anfrage besonders schwierig zu ermitteln. Zus¨

atzlich sollen

sie ohne explizite Interaktionen mit dem Nutzer erhoben werden k¨

onnen. Wir

stellen einen Algorithmus vor, der Metadaten implizit bei der Ausf¨

uhrung

von Anfragen sammelt. Neu mit dem Netzwerk verbundene Peers erlernen

schnell neue Shortcuts zu anderen Peers.

•Bewertung und Auswahl der besten Peers. F¨

ur verschiedene Typen von

Shortcuts definieren wir Metriken zur Auswahl der besten Peers f¨

ur eine

Anfrage. In Peer-to-Peer Netzwerken wird die Berechnung dieses Masses

durch das fehlende globale Wissen ¨

uber die Inhalte der verteilten Peers er-

schwert. Auf der Basis von Strategien f¨

ur die Suche in sozialen Netzwerken

definieren wir Algorithmen zur Auswahl der besten Peers f¨

ur eine Anfra-

ge. Abh¨

angig von dem lokal vorhandenen Wissen ¨

uber das Netzwerken wird

dynamisch die optimale Strategie zur Weiterleitung der Anfrage bestimmt.

•Entwicklung von Algorithmen f¨

ur die Pflege der lokalen Indizes. Jeder

Peer pflegt lokal seinen Index mit den gesammelten Daten ¨

uber Anfragen

und Inhalte anderer Peers. Aufgrund der Dynamik der Peers und ihrer ge-

speicherten Inhalte veralteten diese Daten jedoch schnell. Wir untersuchen

verschiedene Strategien und formulieren Algorithmen f¨

ur die Aktualisierung

der lokalen Indizes.

•Simulation mit realen Daten. Zur empirischen ¨

Uberpr¨

ufung und Quantifi-

zierung der Verfahren simulieren wir alle Ans¨

atze anhand reeller Daten, die

wir aus dem des Open Directory [DMO] ableiten. Wir vergleichen unseren

Ansatz mit dem Gnutella Ansatz und weiteren aktuellen Routing Ans¨

atzen

f¨

ur Shortcut Netzwerke im Hinblick auf die Kosten, der Genauigkeit des

Routings und den Recall f¨

ur eine Anfrage.

Die methodische Vorgehensweise umfasst zwei grundlegende Teilaspekte, die theo-

retische Fundierung der Arbeit und die praktische Untersuchung der Leistungsf¨

ahig-

keit der gefundenen Algorithmen und Metriken. Wir definieren Begriffe und Ter-

minologien f¨

ur das Routing von Anfragen in Peer-to-Peer Netzwerken und untersu-

chen und analysieren Schw¨

achen existierender Verfahren. Dazu wird auf aktuelle,

zum Teil eigene, Ver¨

offentlichungen aus dem Bereich des Peer-to-Peer Information

Retrieval und der semantischen Suche in Peer-to-Peer Netzwerken zur¨

uckgegrif-

fen. Der praktische Teil der Arbeit umfasst die empirische Untersuchung Effizienz

der Algorithmen durch eine Simulation und auf der Basis reeller Daten. Zuerst sol-

len die gefundenen Metriken auf die Daten angewendet und fehlende Metadaten

berechnet werden. In einem weiteren Schritt werden die in der Arbeit entwickelten



1.4. Gliederung

Algorithmen mit g¨

angigen Algorithmen f¨

ur die Lokalisierung von Inhalten vergli-

chen.

1.4 Gliederung

Die Arbeit gliedert sich in drei Teile. F¨

ur jeden Teil fassen wir kurz den Inhalt

zusammen und verweisen auf eigene Publikationen, in denen diese Ideen und Re-

sultate pr¨

asentiert wurden. Zum Schluss jedes Kapitels diskutieren wir unseren

Ansatz mit verwandten Arbeiten:

Teil I - Informationssuche in Peer-to-Peer Netzwerken

Kapitel 1: Einf¨

uhrung

Dieses Kapitel motiviert und f¨

uhrt in das Problem der Lokalisierung von Inhalten

in Peer-to-Peer Netzwerken ein. Zur Reduzierung der Kosten f¨

ur die Lokalisierung

soll eine Anfrage m¨

oglichst nur an Peers gesandt werden, die passende Inhalte pu-

blizieren. Wir teilen das Problem in mehrere Teilproblemstellungen auf und stellen

die Gliederung der Arbeit vor.

Kapitel 2: Anwendungen und Architekturmodelle

Wir analysieren typische Charakteristiken potentieller Anwendungen der Informa-

tionssuche in Peer-to-Peer Netzwerken und stellen die Anwendungsgebiete Legale

Musiktauschb¨

orse und Group ware kurz vor. Sp¨

ater klassifizieren wir in der Praxis

und in der Forschung auftretende Architekturmodelle anhand des Grades der Zen-

tralisierung und der Struktur des Overlays.

Kapitel 3: Routing auf der Basis globaler Indizes

Wir stellen zwei neue Routing Strategien vor, die mit unterschiedlichen Technolo-

gien einen verteilten globalen Index implementieren. F¨

ur das Themen-Hierarchie

basierte Routing auf der Basis von verteilten Hashtabellen stellen wir das Sy-

stem TOPICS [L¨

os04b, LSZ04] vor. Das System Edutella zeigt das Routing in

einem schema-basierten Netzwerken auf der Basis von Routing Indizes [LNWS03,

NWS+03].

Teil II- Adaptive Overlays auf der Basis lokaler Shortcut Indizes

Kapitel 4: Der INGA Ansatz

Wir beschreiben detailliert das Konzept adaptiver Overlays auf der Basis lokaler

Indizes als logische Schicht ¨

uber dem physischen Netzwerk, definieren soziale

Metaphern f¨

ur das Routing und die Kernkomponenten der Architektur, wie lokale

Indizes und Shortcuts [L¨

os04a, LWSN03, LNS+03].



1.4. Gliederung

Kapitel 5: Erzeugung von Shortcuts

Auf der Basis sozialer Metaphern entwickeln wir ein neues Overlay-Modell. Zur

Erstellung des Overlays entwickeln wir Verfahren zur Gewinnung von Metadaten

uber einen Peer. Dazu beobachten wir Anfragen und deren Resultate [LT05].

Kapitel 6: Index Verwaltung und Routing Modell

Auf der Basis der Bewertung eines Peers f¨

ur eine Anfrage entwickeln wir einen

neuen Algorithmus f¨

ur das Weiterleiten von Anfragen. Dazu untersuchen wir Heu-

ristiken und leiten aus diesen Algorithmen ab. Wir untersuchen Algorithmen, die

eine exakte ¨

Ubereinstimmung zwischen einer Anfrage und einem Index Eintrag

erfordern, Algorithmen die ¨

Ahnlichkeiten ber¨

ucksichtigen und stellen Funktionen

zu Berechnung der ¨

Ahnlichkeit vor [LST05, LTQ+05].

Kapitel 7: Simulation und Evaluierung

Zur empirischen Bewertung der Algorithmen werden mit reellen Daten verschie-

dene Szenarien simuliert. Die Ergebnisse der Simulationen werden anhand der An-

zahl der Ergebnisse f¨

ur eine Suche und auf den Verbrauch von Nachrichten mitein-

ander verglichen. Ziel ist das Finden einer optimalen Kombination aus Aufwand

und Nutzen f¨

ur eine Suchanfrage.

Teil III - Diskussion

Kapitel 8: Zusammenfassende Diskussion

Dieses Kapitel diskutiert die wichtigsten Ergebnisse der Arbeit. Es schliesst mit

der Betrachtung weiterer Forschungsrichtungen ab.



Anwendungen und Architekturmodelle

In diesem Kapitel geben wir eine ¨

Ubersicht typischer Charakteristiken von Peer-

to-Peer Systemen und stellen potentielle Anwendungen der Informationssuche vor.

Im zweiten Teil diskutieren wir in der Praxis und Forschung auftretende Architek-

turmodelle, die wir klassifizieren anhand des Grades der Zentralisierung und der

Struktur des Overlays.

2.1 Peer-to-Peer Netzwerke

Eine neue Welle von Netzwerk Architekturen bilden die Basis f¨

ur neue Dienste in

verteilten Informationssystemen. Beispiele sind die Internet Telephonie mit Skype,

der Austausch von Medien ¨

uber Gnutella, die elektronische Zusammenarbeit in

Gruppen mit Groove oder die verteilte Analyse von interstellaren Signalen mit Se-

ti@Home. Die Autoren in [Ora01, ATS04, MKL+02] verstehen unter einer solchen

Peer-to-Peer Architektur ein ’sich selbst organisierendes System gleichberechtig-

ter, autonomer Einheiten (Peers)’, das ’vorzugsweise ohne Nutzung zentraler Dien-

ste auf der Basis eines Rechnernetzes mit dem Ziel der gegenseitigen Nutzung von

Ressourcen (CPU Zyklen, Speicherplatz oder Informationen) operiert’. Der Begriff

Peer-to-Peer wird gelegentlich mit folgenden anderen Begriffen verwechselt:

•Client-Server repr¨

asentiert die Ausf¨

uhrung von Rechnern in einem Netzwerk

mit den Rollen der Clients und der Server. Typischerweise verteilen sich

beide Rollen auf unterschiedliche Rechner im Netzwerk, wobei meist ein



2.1. Peer-to-Peer Netzwerke

Rechner als Server und die restlichen Rechner als Clients fungieren. Jeder

Rechner kann beide Rollen, jedoch f¨

ur unterschiedliche Dienste, gleichzeitig

wahrnehmen. Beispielsweise agiert ein Rechner als Mail-Server und bezieht

die daf¨

ur ben¨

otigte Software als FTP Client beziehen.

•Distributed Computing wird definiert als ein Computersystem, in dem meh-

rere miteinander verbundene Computer dessen Aufgaben unter einander auf-

teilen. Derartige Systeme beinhalten Cluster von Computern, die Ressourcen

uber das Internet von vernetzten Computern beziehen. Wir verwenden den

Begriff auch f¨

ur Systeme, die Peer-to-Peer Eigenschaften aufweisen.

•Grid Computing wird von [IF99] definiert als die koordinierte, gegenseitige

Nutzung freier Ressourcen und das gemeinsame L¨

osen von Problem in vir-

tuellen Organisationen. Ein Grid ist eine Infrastruktur die Berechnungen op-

timal auf ein Netzwerk von Computern aufteilt. H¨

aufig wird die Vernetzung

uber das Client-Server Modell realisiert, beispielsweise beim Seti@Home

Projekt.

•Ad-hoc Communication wird definiert als ein System, dass eine Kommu-

nikation zwischen Computern erm¨

oglicht, ohne das eine Infrastruktur davor

bereits zwischen diesen existierte. Das Netzwerk und die beteiligten Compu-

ter kontrollieren ihre Kommunikation, Sicherheit und Identit¨

at eigenst¨

andig.

Peer-to-Peer Systeme k¨

onnen auf der Basis existierender Ad-Hoc Infrastruk-

turen realisiert werden.

Letztendlich l¨

asst sich jedoch nur schwer festlegen, welches System ein Peer-to-

Peer System ist und welches nicht. Wir glauben, dass dieser Mangel an einer ein-

heitlichen Definition vielmehr durch die Verwendung des Begriffs aufgrund ei-

ner subjektiv wahrgenommenen Peer-to-Peer Interaktion in einer Anwendung, als

durch eine konkrete technologische Umsetzung entsteht.

In der Literatur [MKL+02, ATS04] werden Peer-to-Peer-Systeme durch fol-

gende, technisch orientierte Charakteristika beschrieben, wobei oftmals nur im Ide-

alfall alle Charakteristika gleichzeitig zutreffen:

•Selbst-Organisation. Peer-to-Peer Netze organisieren sich selbstst¨

andig in

einem Netzwerk und ermitteln ihre Nachbarn in einem verteilten Prozess.

•Symmetrische Kommunikation. Peers agieren als Server, in dem sie An-

fragen beantworten und Dienste zur Verf¨

ugung stellen, und als Client, in dem

sie Anfragen stellen und Dienste nutzen.



2.1. Peer-to-Peer Netzwerke

•Dezentrale Kontrolle. Jeder Peer definiert seine Rolle und den Grad seiner

aktiven und passiven Partizipation im Netzwerk autonom, ohne eine zentrale,

kontrollierende Instanz.

•Eindeutige Identifikation eines Peers. Jeder Peer kann ¨

uber einen eindeuti-

gen Schl¨

ussel identifiziert werden. Im Peer-to-Peer Netzwerk Gnutella wird

eine GUID f¨

ur jeden Peer vergeben, wenn er sich mit dem Netzwerk verbin-

det. Der Ansatz verf¨

ugt ¨

uber den Nachteil, das der Schl¨

ussel sich von Sessi-

on zu Session ¨

andern kann. Zur L¨

osung dieses Problems verf¨

ugt das JXTA

Netzwerk ¨

uber das Konzept des Virtual Addressing [TAA+03]. F¨

ur jeden

Peer wird eine von dessen IP Adresse unabh¨

angige logische PeerID ¨

uber

eine 128-Bit Hashfunktion berechnet. Zu Begin jeder Session identifiziert

sich der Nutzer mit einem Passwort und einer UserID. Bei Erfolg wird ihm

vom System seine eindeutige logische PeerID zugewiesen. Die Abbildung

der logischen PeerID in die physische Adresse erfolgt im JXTA Rendevouz

Netzwerk. Der Ansatz hat den Vorteil, dass ein Laptop, der ¨

uber ein DHCP

Netzwerk angemeldet wird, immer derselben logischen PeerID zugewiesen

wird. Ebenfalls kann einer Person nur eine PeerID zugewiesen werden, die

vom eingesetzten Ger¨

at (Laptop, PDA, Desktop PC) unabh¨

angig ist.

Die Autoren in [RBR+04] identifizieren folgende Charakteristiken, die einen Ein-

satz von Peer-to-Peer Technologien aus ¨

okonomischer Sicht rechtfertigen:

1. Verf¨

ugbares Budget. Ist das Budget f¨

ur eine zentrale L¨

osung ausreichend

wird eine Peer-to-Peer basierte L¨

osung aufgrund ihrer Komplexit¨

at, der Pro-

bleme beim Testen und ihrer Ineffizienz, vergleichbar mit einer zentralen

L¨

osung, nicht in Betracht kommen. Ist das Budget jedoch eng begrenzt, mo-

tivieren die geringen Kosten f¨

ur eine Peer-to-Peer basierte L¨

osung. H¨

aufig

stellt sogar der kontinuierliche Aufbau eines Systems aus einzelnen Peers

die einzig ¨

okonomisch akzeptable Vorgehensweise dar.

2. Relevanz der Ressourcen und Dienste. Die Relevanz beschreibt den Be-

darf eines Nutzers an einer nur im Peer-to-Peer System verf¨

ugbaren Res-

source (einem Dokument) oder einem Dienst (einer verteilten Suchmaschine

in einem Unternehmen). Eine geringe Relevanz korreliert mit einer geringen

Kooperation innerhalb des Peer-to-Peer Systems und erfordert zus¨

atzliche

Anreize.

3. Vertrauen der Nutzer. Die Identifizierung und Isolierung ’b¨

osartiger’ Peers

erfordert zus¨

atzliche Kosten. Derartige Peers stellen falsche, unvollst¨

andi-

ge oder nutzlose Dokumente zur Verf¨

ugung oder agieren ausschliesslich als

Konsument von Dokumenten.



2.2. Anwendungen f¨

ur die Informationssuche

4. ¨

Anderungsrate des Systems. Aktualit¨

at, Qualit¨

at und Vollst¨

andigkeit einer

Anfrage variieren durch die hohe Dynamik der vorhandenen Dokumente und

die Volatilit¨

at der einzelnen Peers.

5. Bedeutsamkeit der Anwendung. Ist eine Anwendung von zentraler Bedeu-

tung f¨

ur ein Unternehmen, werden Nutzer Systeme mit einer zentralen Kon-

trolle, hoher Fehlertoleranz und hoher Ausfallsicherheit bevorzugen.

2.2 Anwendungen f¨

ur die Informationssuche

Wir stellen zwei Anwendungen f¨

ur die Informationssuche in Peer-to-Peer Netzwer-

ken aus der aktuellen akademischen Forschung (Semantisch vernetzte Arbeitspl¨

atze)

und aus der Praxis (Legale Musiktauschb¨

orse) vor. Anschließend bewerten wir die-

se anhand der im letzten Abschnitt definierten Kriterien.

2.2.1 Legale Musiktauschb¨

orse

In der Vergangenheit wurden File-Sharing Anwendungen immer wieder mit dem

illegalen Tausch von Medien in Verbindung gebracht. Durch den offenen DRM-

Standard der Open Mobile Alliance (OMA) [OMA04] wurden die Grundlagen f¨

einen effektiven, hersteller- und betreiberunabh¨

angigen Schutz digitaler Rechte ge-

schaffen. Zuk¨

unftige legale Musiktauschb¨

orsen, wie der Napster Nachfolger Sno-

Cap [tPW05], nutzen die Vorteile der Peer-to-Peer Tauschb¨

orsen f¨

ur den Vertrieb

von Musik und integrieren die Rechteinhaber in das System. Sie entkoppeln die

Verwaltung der Rechte von den im Peer-to-Peer Netzwerk getauschten Medien.

Jedes Dokument verf¨

ugt ¨

uber eine DRM Kennung, die dessen Rechte f¨

ur einen

Nutzer spezifiert. Wird eine Datei von einem Nutzer kopiert bzw. abgespielt, so

muss die Kopie durch den Erwerb von Rechten freigeschaltet werden. W¨

ahrend die

Verwaltung der Rechte separat in einem zentralen Dienst erfolgt, werden die Doku-

mente im einem Peer-to-Peer Netzwerk publiziert, gesucht, zusammengestellt und

verteilt. Die Dokumente sind ¨

uber Metadaten, beispielsweise K¨

unstler, Title, Gen-

re, des ID3V2 Standards annotiert. Zur Beschreibung der Genre und Stimmung der

Musik existieren Themen-Hierarchien f¨

ur Musik, wie allmusic.com,musicmoz.org.

Die Metadaten werden durch zentrale, frei zug¨

angliche ID3V2 Datenbanken, wie

Freedb.org, verwaltet und manuell durch die Nutzer annotiert.

F¨

ur den Inhaber der Rechte an der Musik stellt dieses Modell eine kosteng¨

unsti-

ge und selbstorganiserende Infrastruktur f¨

ur den Vertrieb bereit. Die Kosten f¨

Vertrieb, Speicherung und die Zusammenstellung der Musik werden durch die Nut-

zer des Peer-to-Peer Systems getragen. Die Verf¨

ugbarkeit der Dokumente korre-

liert mit der Popularit¨

at, popul¨

are Dokumente sind hoch verf¨

ugbar. In File-Sharing



2.2. Anwendungen f¨

ur die Informationssuche

Anwendungen ist die ¨

Anderungsrate des Systems hoch, da dessen Nutzer oftmals

h¨

aufig nur f¨

ur kurze Zeit online sind und Dokumente h¨

aufig hinzugef¨

ugt werden.

Peers vertrauen typischerweise einander, das die bereitgestellten Dokumente auch

vollst¨

andig sind. Zur Sicherung der Qualit¨

at und des Vertrauens k¨

onnen Nutzer in

diesen Systemen in Kontakt treten, einander Musiktitel empfehlen und diese legal

austauschen. F¨

ur die Weitervermittlung von Musik erhalten Nutzer Anreize, wie

kostenlose Downloads. Der Austausch von Musik stellt keine kritische Anwen-

dung f¨

ur den einzelnen Nutzer dar.

2.2.2 Semantisch vernetzte Arbeitspl¨

atze

Mitarbeiter verbringen viel Zeit damit, nach Informationen zu suchen. Zeitaufwand

und Kosten f¨

ur die Informationssuche und -weitergabe sind hoch, oft m¨

ussen Mit-

arbeiter um Mithilfe gebeten werden. Das notwendige Wissen ist implizit ¨

uber die

Expertise einzelner Mitarbeiter und explizit in deren lokal verf¨

ugbaren Dokumen-

ten gespeichert [NT95]. Ein Zugriff auf die lokal gespeicherten Dokumente der

einzelnen Mitarbeiter w¨

urde den Recall der Dokumentensuche in einem Unterneh-

men vergr¨

ossern und gleichzeitig potentielle Experten f¨

ur eine Anfrage identifizie-

ren.

Verschiedene Forschungsprojekte [DF04, TEF+04, HBM+04, ACMH02] un-

tersuchen Peer-to-Peer Technologien f¨

ur eine semantische Suche nach Dokumen-

ten im Unternehmen und in virtuellen Organisationen mit mehreren tausend Peers.

Microsoft [Coo05] setzt die Technologie f¨

ur die Segmente Home Office und Small

Enterprise als Group Ware Infrastruktur f¨

ur bis zu zehn Peers ein, f¨

ur die der Kauf

und Betrieb eines Servers zu teuer wird. Sie nutzen den Zusammenhang zwischen

der Generierung, Verwaltung, Publikation und semantischen Einordnung von Do-

kumenten auf dem lokalem Desktop durch den Nutzer. ¨

Uber eine Vernetzung der

einzelnen Arbeitspl¨

atze entsteht eine kosteng¨

unstige, selbstorganisierende Infra-

struktur ohne zentrale Koordination zum Austausch von Dokumenten und zur Iden-

tifikation von Experten. Mit der Nutzung des Peer-to-Peer-Verfahrens wird die Su-

che dezentral und ohne Verwaltungsaufwand betrieben. Dadurch sind die Daten

aktuell und es Kosten werden eingespart. Eine Relevanz der Anwendung h¨

angt von

der Bereitschaft der Mitarbeiter zur Publikation von Dokumenten, der Verf¨

ugbar-

keit m¨

oglicher Alternativen (wie einer vorhandenen zentralen Ablage oder Suche

im Intranet) und der Unternehmenskultur ab. Im akademischen Umfeld und in

Non-Government Organisationen erwarten wir eine Offenlegung der Zuordnung

eines Nutzers zu einem Peer. Durch die lokale Erzeugung von Dokumenten und

die Mobilit¨

at der Endger¨

ate erwarten wir eine hohe ¨

Anderungsrate. Aufgrund des

fr¨

uhen Entwicklungsstadiums der Anwendung lassen sich keine Aussagen ¨

uber ih-

re Bedeutsamkeit treffen.



2.3. Architekturvarianten zur Informationssuche

2.3 Architekturvarianten zur Informationssuche

Die Autoren in [ATS04, MKL+02] haben Peer-to-Peer Systeme f¨

ur die Lokalisie-

rung von Dokumenten nach dem Grad der Zentralisierung und der Struktur des

Overlay Netzwerkes klassifiziert. Wir ¨

ubernehmen diese Struktur und stellen Prin-

zipien und Beispiele f¨

ur die jeweilige Architektur vor.

2.3.1 Grad der Zentralisierung

Obwohl Peer-to-Peer Systeme in ihrer einfachsten Form, dem vollst¨

andig dezentra-

len Ansatz, keine zentralen Komponenten aufweisen, werden in der Praxis h¨

aufig

Systeme mit einem unterschiedlichen Anteil von Zentralisierung verwendet. Wir

unterscheiden die folgenden drei Klassen von Zentralisierung:

Vollst¨

andig dezentralisiert. In diesen Systemen haben alle Knoten die gleichen

Aufgaben und agieren sowohl als Client als auch als Server. Es existiert keine

zentrale Instanz im Netzwerk. Nachrichten und Dokumente werden direkt zwi-

schen Peers ausgetauscht. Aufgrund des Fehlens eines Single Points of Failures,

der hohen Dynamik und Un¨

ubersichtlichkeit der beteiligten Peers und der schlech-

ten Kontrollm¨

oglichkeit sind diese Systeme hinsichtlich technologischer Angrif-

fe (Zerst¨

orung von Peers, ¨

Uberflutung von Peers mit Anfragen) und ’politischer

Angriffe’ (Austausch illegal erworbener Dokumente, Verbieten des Netzwerkes)

robust. Beispiele f¨

ur dieses Architekturmodell sind Gnutella [DZW04] bis zur

Version V0.4, Freehaven [DFA00], CAN [RFH+01], CHORD [SMK+01], Pastry

[RD01], P-Grid [Abe01] und Tapestry [ZKJ01].

Super-Peer. Die Autoren in [CLL04, SGG03] argumentieren, dass nicht alle

Peers in einem Peer-to-Peer Netzwerk ¨

uber gleiche technische Leistungsf¨

ahigkeit

verf¨

ugen. Super-Peer Netzwerke sind zwischen vollst¨

andig zentraliserten Netzwer-

ken und vollst¨

andig dezentralen Netzwerken einzuordnen. Sie f¨

uhren Hierarchie, in

Form von Super-Peer Knoten, in das Netzwerk ein. Super-Peers verf¨

ugen ¨

uber eine

besondere Leistungsf¨

ahigkeit und nehmen komplexe Aufgaben, wie das Routing

oder die Verwaltung der Peers, innerhalb des Netzwerkes wahr [GMY02, Gon01].

Ein Super-Peer in einem solchen Netzwerk agiert als zentraler Server f¨

ur eine An-

zahl von Clients. Diese richten ihre Anfragen an einen Super-Peer und erhalten

Resultate von einem Super-Peer. Super-Peers sind ¨

uber ein ’pures’ Peer-to-Peer

Netzwerk miteinander verbunden und leiten Nachrichten innerhalb dieses Netz-

werkes weiter. Dieses Architekturmodell verteilt die Last f¨

ur die Bearbeitung von

Anfragen und die Verwaltung des Netzwerkes auf wenige vorwiegend statische



2.3. Architekturvarianten zur Informationssuche

Super-Peer im Netzwerk. Ein Nachteil des Ansatzes ist die komplexe und dynami-

sche Identifikation und Festlegung von Super-Peers [YGM03].

Hybrid. In diesen Systemen existiert ein zentraler Server, der die Interaktion

zwischen den einzelnen Peers und deren Verwaltung ¨

uber ein zentrales Verzeichnis

steuert. Peers registrieren ihr Profil in einem zentralen Verzeichnis und stellen An-

fragen, die mit den registrierten Profilen verglichen werden. Sind passende Peers

f¨

ur eine Anfrage identifiziert worden, erfolgt der Austausch von Dokumenten di-

rekt zwischen zwei Peers.

Dieses Modell erfordert eine zentrale Infrastruktur um die Profile der einzel-

nen Peers zu verwalten. Diese Infrastruktur stellt einen Single Point of Failure dar.

Bei einer Erh¨

ohung der Anzahl von Peers im Netzwerk erh¨

ohen sich auch die Ko-

sten f¨

ur die zentrale Infrastruktur. Ein Vorteil des Modells ist die Kontrolle der im

Netzwerk publizierten Dokumente und angeschlossenen Peers. Napster [Nap03]

und dessen Nachfolger SnoCap verwenden diese Architektur, um eine Kontrolle

uber die konsumierte Musik zu gew¨

ahrleisten und Daten ¨

uber das Verhalten der

Nutzer zu sammeln.

2.3.2 Struktur des Overlay und der Indizes

Unter Struktur verstehen wir die zuf¨

allige oder durch Regeln definierte Anordnung

der Peers und Dokumente in der Overlay Struktur. Die Anordnung der Dokumente

und Peers kann ¨

uber den Einsatz von Indizes vorgenommen werden. Wir unter-

scheiden globale Indizes, bei denen ein verteilter Index von allen Peers gemeinsam

nach einem Muster verwaltet und f¨

ur Anfragen ausgewertet wird und lokale Indi-

zes, bei denen jeder Peer seinen eigenen Index verwaltet und f¨

ur eigene Anfragen

den eigenen oder den Index eines entfernten Peers benutzt.

Unstrukturiert ohne Indizes. In diesen Netzwerken ist die Anordnung von Do-

kumenten v¨

ollig unabh¨

angig von der Overlay Struktur. Indizes werden nicht ver-

wendet. Ein Funktion ist die Lokalisierung von Dokumenten. Typische Suchans¨

atze

uberfluten das Netzwerk mit Anfragen durch Tiefen- oder Breitensuche, bis die

gew¨

unschte Anzahl von Dokumenten gefunden wurde oder die Anfrage eine be-

stimmte Entfernung, gemessen in der Anzahl kontaktierter Peers, erreicht hat [Rit01].

Der Nachteil unstrukturierter Modelle ist die ¨

Uberflutung des Netzwerkes mit An-

fragen.

H¨

aufig werden diese Modelle mit Super-Peer Modellen kombiniert, um die Be-

arbeitung einer Anfrage und die damit verbundene hohe Anzahl von Nachrichten

auf wenige Peers zu reduzieren [YGM03, TAA+03]. Eine weitere Form ist die

Verwendung von Random Walks, wobei Anfragen an zuf¨

allig ausgew¨

ahlte Peers



2.3. Architekturvarianten zur Informationssuche

Zentralisierung

Ohne Super Peer Hybrid

Unstrukturiert Gnutella v0.4 Gnutella v0.6 Napster

FreeHeaven Kazaa SnowCap

Semi-Strukturiert ForeSeer GIA

INGA

Strukturiert (Peers) Structella Edutella

Strukturiert (Peers & Dok.) CHORD TOPICS

CAN

PASTRY

P-Grid

Abbildung 2.1: Klassifikation von Information Sharing Systemen

gesendet werden. In Verbindung mit einer Replikation von Dokumenten verringert

dieser Ansatz signifikant die Anzahl der Nachrichten und die Zeit bis zum ersten

Finden eines Dokuments [LCC+02].

Semi-strukturiert auf der Basis lokaler Indizes. Diese Netzwerke verf¨

ugen

uber ein unstrukturiertes Overlay. Durch Interaktionen mit benachbarten und ent-

fernten Peers werden Informationen ¨

uber deren publizierte Dokumente ausgetauscht

und in einem lokalen Index verwaltet. Anfragen zwischen Peers werden auf der

Basis dieser Indizes an Peers mit exakt passenden oder ¨

ahnlichen Dokumenten

weitergeleitet. Das Overlay der initalen und meist zuf¨

allig zugeordneten Nachbarn

eines Peers ver¨

andert sich mit der Anzahl der Interaktionen zu einem Overlay aus

logisch zueinander geh¨

orenden Nachbarn.

Die Autoren von [CGM02a] verwenden lokale Routing Indizes, in denen In-

formationen ¨

uber verf¨

ugbare Dokumente der Nachbarn eines Peers gespeichert

werden. Die Nachbarn sind durch die initiale Netzwerk Struktur bestimmt. Mit

Hilfe der Indizes wird eine Anfrage nur an Nachbarn mit exakt passenden Doku-

menten weitergeleitet. In ForeSeer [CW04] wird der Ansatz verbessert, indem die

Dokumente der Nachbarn eines Peers mit Hilfe von Bloom Filtern [Blo70] zusam-

mengefasst werden. Dadurch wird f¨

ur den Austausch der Profile zwischen zwei

Peers weniger Bandbreite ben¨

otigt. Zus¨

atzlich werden den initalen Nachbarn wei-

tere Nachbarn hinzugef¨

ugt, die in der Vergangenheit besonders h¨

aufig auf eine An-

frage antworten konnten. Eine Anfrage wird entweder an initiale Nachbarn oder

an Nachbarn mit exakt passenden Dokumenten weitergeleitet. Im GIA Netzwerk

[CRB+03] werden Anfragen an Nachbarn weitergeleitet, die eine hohen Anzahl



2.3. Architekturvarianten zur Informationssuche

von Anfragen pro Sekunde verarbeiten oder eine hohe Bandbreite haben. In Kapi-

tel 4 stellen wir das INGA System vor, bei dem ein Peer adaptiv seine Nachbarn

in verschiedenen lokalen Indizes auf der Basis sozialer Metaphern und ¨

ahnlicher

Interessen verwaltet. Eine Anfrage wird entweder an Nachbarn mit den ¨

ahnlichsten

Interessen oder mit einer besonders guten Vernetzung weitergeleitet.

Unstrukturierte und semi-strukturierte Overlays eigenen sich besonders f¨

ur Appli-

kationen, bei den folgende Eigenschaften angenommen werden k¨

onnen [CRB+03,

KBS02, ATS04]:

•Die Peers weisen eine hohe Dynamik auf.

•Das Netzwerk enth¨

alt vorwiegend popul¨

are und h¨

aufig replizierte Dokumen-

te.

•Die Nutzer sind mit einer unvollst¨

andigen Auswahl der besten Dokumente

f¨

ur eine Anfrage zufrieden gestellt.

•Die Nutzer m¨

ochten unmittelbar und lokal die im Index gespeicherten Daten

kontrollieren k¨

onnen.

•Die Suche erfolgt ¨

uber Keywords.

Strukturiert auf der Basis globaler Indizes. Motiviert durch die schlechte Ska-

lierbarkeit unstrukturierter Netzwerke wurden Overlay Netzwerke entwickelt, die

Peers und Dokumente durch fest definierte Regeln in eine Overlay Struktur einf¨

ugen.

Peers und Dokumente werden durch Schl¨

ussel beschrieben und in einem globalen

Index auf der Basis einer verteilten Hashtabelle verwaltet. Wir unterscheiden zwi-

schen Overlay Strukturen, die entweder nur Peers oder Peers und Dokumente im

gemeinsamen Index verwalten.

•Peers. Gossiping Systeme ben¨

otigen eine Technologie zur Realisierung ei-

nes effizienten Broadcast, so dass jeder Peer eine Nachricht genau nur einmal

erh¨

alt. Structella [MCR03] speichert alle verf¨

ugbaren Peers in einer verteil-

ten Hashtabelle. Eine Nachricht wird in der verwendeten Ring Topologie

im Uhrzeigersinn an jeden Peer geleitet. Zur Optimierung wird der Ring in

O(log N)Segmente aufgeteilt. Eine Nachricht wird an jeden ersten Peer

jedes Segments gesandt und von diesem im Uhrzeigersinn an die nachfol-

genden Peers innerhalb des Segments weitergeleitet.

In Edutella [NWS+03] (siehe auch Kapitel 3.1) wird eine Overlay Struk-

tur verwendet, um einen effizienten Broadcast einer komplexen Anfrage an



2.3. Architekturvarianten zur Informationssuche

alle Peers zu realisieren und um neue Peers in Routing Indizes zu integrie-

ren. Dazu werden die Peers in Form der HyperCup Topologie angeordnet

[SSDN02], die eine Overlay Struktur auf der Basis von Caley Graphen bil-

det. Zur Optimierung des Broadcasts werden Routing Indizes und ein Super-

Peer Netzwerk eingesetzt.

•Dokumente und Peers. In diesen Systemen wird jedem Dokument und je-

dem Peer ein eindeutiger Schl¨

ussel zugewiesen. Die Overlay Struktur ist

durch Regeln genau spezifiert. Dokumente (bzw. Verweise zu diesen) und

Peers (bzw. deren Adresse) werden an genau definierten Stellen in das Over-

lay eingef¨

ugt. Diese Systeme verf¨

ugen ¨

uber ein Mapping zwischen Schl¨

usseln

von Dokumenten, Schl¨

usseln von Peers und deren Position im Overlay Netz-

werk in Form einer verteilten Hashtabelle. Jeder Peer verwaltet einen Teil

der Hashtabelle. Zur Lokalisierung eines Dokuments f¨

ur eine Anfrage wird

durch Anwenden einer Hashfunktion ein Schl¨

ussel gebildet und die Anfrage

wird zu dem Peer geleitet, der diesen Schl¨

ussel verwaltet. Typische Beispiele

sind CAN [RFH+01], CHORD [SMK+01], Pastry [RD01], P-Grid [Abe01]

und Tapestry [ZKJ01]. In Kapitel 3.2 stellen wir das TOPICS System vor,

welches semantische Profile von Peers in einer verteilten Hashtabelle spei-

chert und ein Browsen in ihnen erm¨

oglicht.

Strukurierte Overlays eigenen sich besonders f¨

ur Anwendungen bei denen folgen-

de Eigenschaften angenommen werden k¨

onnen [CRB+03, KBS02, ATS04]:

•hohe Skalierbarkeit f¨

ur eine hohe Anzahl von Peers und Dokumenten

•exakte ¨

Ubereinstimmung der Anfrage mit einem Dokument bzw. dessen

Schl¨

ussel

•geringe Volatilit¨

at der Peers und Dokumente

•geringe Replikation der Dokumente

Durch Virtualisierung eines Schl¨

ussels in einem strukturierten Netzwerk tritt je-

doch das Problem auf, das f¨

ur eine Anfrage der Schl¨

ussel des Dokuments bereits

zum Moment der Anfrage bekannt sein muss. Daraus resultieren zwei weitere Pro-

bleme [KBS02]:

•Zerst¨

orung der Lokalit¨

at. Durch die Verwendung von Hash-Schl¨

usseln f¨

die Identifizierung von Dokumenten wird die logische Lokalit¨

at der an einem

Peer gespeicherten Dokumente zerst¨

ort. M¨

oglichkeiten f¨

ur das Browsing in

den Dokumenten, das Pre-fetching der Dokumente und eine effiziente Suche

in den Dokumenten innerhalb eines lokalen Peers gehen verloren.



2.4. Zusammenfassung

•Verlust von Informationen auf Anwendungsebene. In Dateisystemen wer-

den Dokumente typischerweise in nutzerspezifische Hierarchien eingeord-

net. Innerhalb der Hierarchie stehen Dokumente die nahe in der Hierarchie

gespeichert wurden auch h¨

aufig in enger logischer Beziehung. Durch die

Verwendung von Hash-Schl¨

usseln f¨

ur Dateien wird diese logische Bezie-

hung jedoch zerst¨

ort.

Weitere offene Forschungsprobleme sind die Optimierung strukturierter Overlays

f¨

ur Netzwerke mit hohem Churn und Verfahren zum Lastausgleich innerhalb der

verteilten Hashtabelle. In Abschnitt 3.2 stellen wir ausgew¨

ahlte Verfahren daf¨

vor.

2.4 Zusammenfassung

Dieses Kapitel beinhaltet zwei Beitr¨

age. Im ersten Teil definieren wir Merkmale

von Anwendungen f¨

ur die Informationsssuche in Peer-to-Peer Systemen und be-

schreiben anhand der Merkmale die Anwendungen ’Musiktauschb¨

orse’ und ’Se-

mantisch vernetzte Arbeitspl¨

atze’. Im zweiten Teil klassifizieren wir in der Praxis

und Forschung verwendete Peer-to-Peer Systeme f¨

ur die Informationssuche nach

dem Grad der Zentralisierung und der Struktur der Overlays und klassifizieren die

in dieser Arbeit vorgestellten Systeme, Edutella und TOPICS als ein Super-Peer

basiertes System mit einem strukturierten, globalen Index und das INGA als ein

semi-struktueriertes System mit lokalen Indizes.



Routing auf der Basis globaler Indizes

In diesem Kapitel werden zwei neue Ans¨

atze f¨

ur die Lokalisierung von mit Me-

tadaten annotierten Ressourcen in einem Peer-to-Peer Netzwerk vorgestellt. Bei-

de Ans¨

atze unterst¨

utzen die Speicherung komplexer Metadatenstrukturen in einem

vollst¨

andig verteilten Index. Der Edutella Ansatz [NWS+03, LNWS03, NWS+04]

erlaubt die Formulierung und das Routing von Anfragen f¨

ur komplexe Metadaten-

schema. Wir stellen den Aufbau des Index in Verbindung mit einem Super-Peer

Netzwerk vor und erl¨

autern das Routing-Verfahren am Beispiel der Metadaten-

schema Dublin Core und LOM. Der TOPICS Ansatz [L¨

os04b, LSZ04] erm¨

oglicht

das Browsen in verteilten Ressourcen, die ¨

uber Metadaten in einer Themen - Hier-

archie klassifiziert wurden. Wir stellen den Aufbau des globalen Index auf der Ba-

sis einer verteilten Hash Tabelle vor und zeigen das Browsen im Index.

3.1 Edutella

Die heutige universit¨

are Ausbildung ist durch eine stetig wachsende Anzahl von

Studenten und eine immer geringeren Anzahl von betreuenden Lehrkr¨

aften ge-

kennzeichnet. Diese Situation wird noch vervollst¨

andigt durch eine wachsende

Anzahl von interdisziplin¨

aren Studienprogrammen und inhomogenen Studiengrup-

pen. Zusammenfassend f¨

uhren diese Faktoren zu einer immer mehr selbstgesteu-

erten und auch ”unbetreuten“ Suche der Studenten nach passenden Materialien f¨

Ihr Studienziel. Ebenfalls stehen Dozenten und Lehrer vor der Aufgabe, Materia-



3.1. Edutella

lien f¨

ur eine immer gr¨

ossere Anzahl von Studenten mit heterogenen Leistungsvor-

aussetzungen zu erstellen. Dabei wird eine zu geringe Anzahl von existierenden

Materialien, auch anderer Institutionen, wiederverwendet. Durch Initiativen, wie

”Neue Medien in der Bildung“ oder das vom MIT initiierte Vorhaben Open Course

Ware Project [OCW03], sind in den letzten Jahren viele autonome, weltweit ver-

teilte Datenbanken mit qualitativ hochwertigen E-Learning Inhalten zu verschie-

densten Studiengebieten entstanden [LGH02]. Aufgrund der Verteiltheit und der

Heterogenit¨

at der Anbieter haben Nutzer des Netzwerkes jedoch grosse Schwie-

rigkeiten f¨

ur ihr Lernziel passende Materialien zu finden.

Das E-Learning Netzwerk, Edutella [NWQ+02] bietet eine technologische Platt-

form zur einer integrierten Bereitstellung heterogener, autonomer E-Learning Da-

tenbanken in einem Netzwerk f¨

ur den Web-weiten Zugriff der Studenten. Es wurde

f¨

ur ein Szenario mit folgenden Eigenschaften entwickelt:

Globaler verteilter Index. Aufgrund der fehlenden politischen und administrati-

ven Vereinbarungen zwischen den Bildungsanbietern ist kein gemeinsamer

Index m¨

oglich. Vielmehr soll jeder Bildungsanbieter einen kleinen Teil des

Index lokal verwalten und durch eine geeignete Infrastruktur dem Nutzer

einen globalen Zugriff erm¨

oglicht werden.

Hoch verf¨

ugbare, autonome Quellen. Anbieter, wie beispielsweise Lehrst¨

uhle an

Universit¨

aten, stellen ihre Inhalte innerhalb der Plattform bereit, ohne die

Autonomie ¨

uber die Materialien zu verlieren. Die Quellen, bzw. die unterlie-

genden Rechner, weisen eine geringe Volatilit¨

at auf und k¨

onnen zus¨

atzliche

Dienste, wie das Routing von Anfragen, ¨

ubernehmen.

Dom¨

anenspezifische Metadaten. Dokumente sind mit E-Learning Metadaten, bei-

spielsweise nach dem LOM [IEE02] oder Dublin Core Standard [BMB02],

annotiert.

Komplexe, schema-basierte Anfragen. Anfragen erfolgen in den Metadaten der

Dokumente und k¨

onnen mehrere Pr¨

adikate beinhalten.

Edutella wurde f¨

ur mehrere hundert weltweit verteilte Anbieter von Materialien

und mehrere zehntausend Nutzer konzipiert. Ein blindes Versenden einer Anfrage

an alle Anbieter ist nicht erw¨

unscht. Vielmehr sollen f¨

ur eine Anfrage passende

Anbieter von E-Learning Materialien, abh¨

angig von den in der Anfrage verlangten

und an einer Quelle unterst¨

utzen Schema Elementen, ausgew¨

ahlt werden. Zur Re-

duzierung der Nachrichten kombiniert das Edutella Netzwerk folgende drei Tech-

nologien:



3.1. Edutella

Abbildung 3.1: HyperCuP Super-Peer Topologie

Super-Peer Netzwerk. Das Netzwerk verwendet eine Super-Peer Netzwerk Struk-

tur, bei der permanent verf¨

ugbare Peers sich zu statischen Super-Peer ver-

binden. Die Netzwerk Struktur erlaubt die lokale Verwaltung der spezifi-

schen Ressourcen f¨

ur die Publikation und Verwaltung von Inhalten an einem

Peer, w¨

ahrend der Super-Peer die notwendige Bandbreite und Rechenlei-

stung f¨

ur die Weiterleitung der Anfragen zur Verf¨

ugung stellt. Super-Peer

basierte Peer-to-Peer Infrastrukturen (siehe auch Abschnitt 2.3.1) verf¨

ugen

uber eine zweistufige Routing Architektur: Zuerst wird eine Anfrage von ei-

nem Peer an in das Super-Peer Netzwerk (Backbone) geleitet. Abh¨

angig von

den in der Anfrage gesuchten Schema Attributen wird die Anfrage ¨

uber das

Super-Peer Netzwerk an weitere, mit dem Super-Peer Netzwerk verbundene

Peers verteilt.

HyperCup Topologie. F¨

ur ein effizientes Weiterleiten von Anfragen innerhalb

des Super-Peer Netzwerkes sind diese in Form der HyperCup Topologie

[SSDN02] angeordnet. Ein Vorteil der HyperCup Topologie ist ein effizien-

ter Broadcast von Anfragen. W¨

ahrend eines Broadcasts stellt jeder Knoten

im Super-Peer Netzwerk die Wurzel f¨

ur die Konstruktion eine Spanning Tree

uber das gesamte Peer-to-Peer Netzwerk dar. Ein Beispiel f¨

ur die Anordnung

der Super-Peers innerhalb der Netzwerk Struktur zeigt Grafik 3.1.

Ein neuer Super-Peer verbindet sich mit dem Netzwerk durch eine Anfra-

ge an einen anderen, bereits verbundenen Super-Peer. Dieser leitet die An-

frage an weitere Super-Peers in der HyperCup Topologie. Um den neuen

Super-Peer zu integrieren und bereits verbundene Super-Peers zu benach-

richtigen, werden mit dieser Topologie O(log(N)) Nachrichten versandt.

Die Pfadl¨

ange innerhalb der Topologie betr¨

agt log2N. Jeder Knoten verf¨

ugt



3.1. Edutella

Abbildung 3.2: Super-Peer/Peer Routing Index

uber eine log2NNachbarn f¨

ur jeden Knoten im Super-Peer Netzwerk, wo-

bei Ndie absolute Anzahl von Knoten im Super-Peer Netzwerk darstellt.

Schema basierte Routing Indizes. Erh¨

alt ein Super-Peer eine Anfrage, sind zu-

n¨

achst alle an dem Super-Peer verbundenen Peers potentielle Kandidaten

f¨

ur eine Weiterleitung der Anfrage. Zur Reduzierung der Nachrichten in

einem Super-Peer Netzwerk erfolgt das Routing auf der Basis von Indizes

[NWS+03] und Routing Tabellen [CGM02a]. Der Edutella Ansatz verwen-

det zwei verschiedene Indizes: Super-Peer/Peer Indizes und Super-Peer/Super-

Peer Indizes. Ziel ist ein Weiterleiten einer Anfrage nur an Peers, die eine

Anfrage aufgrund ihres Schemas auch beantworten k¨

onnen.

3.1.1 Registrierung von Peers im Index

F¨

ur die Registrierung eines Peers an einem Super-Peer, und im Index, sendet der

Peer eine Advertise-Nachricht an den Super-Peer. Sie beinhaltet Informationen

uber unterst¨

utzte Schemata des Peers. Jeder Peer muss mindestens ein Schema,

beispielsweise eine Teilmenge des LOM oder Dublin Core Schemas, f¨

ur eine er-

folgreiche Registrierung definieren. Aufgrund der Volatilit¨

at der Peers ist eine Re-

gistrierung nur innerhalb eines bestimmten Zeitraums g¨

ultig. Wir w¨

ahlen einen

ahnlichen Ansatz wie im DHCP: Nach Ablauf der Zeit muss der Peer sich erneut

an einem Super-Peer registrieren. F¨

allt ein Super-Peer aus, m¨

ussen sich die betrof-

fenen Peers erneut an einem anderen Super-Peer registrieren.

Der Super-Peer/Peer Index. Er beschreibt die Schema Informationen aller an

einem Super-Peer registrierten Peers. Er dient zur Auswahl von Peers f¨

ur einge-

hende Anfragen. Dar¨

uber hinaus bildet er die Grundlage f¨

ur einen weiteren Index,

den Super-Peer/Super-Peer Index, der das Routing innerhalb des Super-Peer Netz-

werkes bestimmt. Beide Indizes beinhalten Informationen ¨

uber registrierte Peers

auf folgenden Granularit¨

atsstufen:



3.1. Edutella

Schema Index. Wir nehmen an, dass verschiedene Peers unterschiedliche Sche-

ma unterst¨

utzen. Jedes Schema wird eindeutig ¨

uber den verwendeten Na-

me Space identifiziert. Der Super-Peer/Peer Routing Index beinhaltet einen

eindeutigen Bezeichner f¨

ur das Schema und die Peers, die das Schema un-

terst¨

utzen.

Property/Sets of Properties Index. Ein Routing Index kann auch Teile eines Sche-

mas einem Peer zuordnen. Eine solche Teilmenge besteht aus einzelnen At-

tributen, sog. Properties. Sie werden ¨

uber ihren Namen und das Schema,

dem sie zugeordnet sind, eindeutig identifiziert. Jedem Attribut sind die Peers,

die das Attribut unterst¨

utzen, zugeordnet.

Property Value Range Index. Einige Attribute beinhalten Werte aus bereits exi-

stierenden Themen-Hierarchien. F¨

ur diese Attribute k¨

onnen m¨

ogliche g¨

ulti-

ge Wertebereiche definiert werden. Applikationen im Bereich des E-Learning

nutzen vordefinierte Wertebereiche, z.B. f¨

ur die Einschr¨

ankung der Themen

f¨

ur eine Anfrage. In Beispiel 3.4 wird der Wertebereich f¨

ur das Attribut

dc:subject auf das Thema ccs:software-eng. eingeschr¨

ankt.

Property Value Index. Analog zu klassischen Datenbanken erlauben wir die Ein-

schr¨

ankung auf spezifische Werte f¨

ur ein Attribut. Der Index verweist auf

einen Peer, der diese Attribut-Wert Kombination unterst¨

utzt. In Beispiel 3.4

wird das im E-Learning h¨

aufig unterst¨

utzte Attribut dc:language auf die

deutsche Sprache eingeschr¨

ankt.

Der Super-Peer/Super-Peer Index. Diese Indizes repr¨

asentieren Ausz¨

uge und

Zusammenfassungen aus dem Super-Peer/Peer Index. Sie beinhalten die selben

Metadaten wie Super-Peer/Peer Indizes, verweisen jedoch auf die direkten Nach-

barn im Super-Peer Netzwerk (siehe auch Grafik 3.3). Anfragen werden zu be-

nachbarten Super-Peers entlang des Super-Peer/Super-Peer Index weitergeleitet

und dann ¨

uber den Super-Peer/Peer Index an einzelne Peers verteilt.

Beispiel 3.1.1 (Edutella SP-SP Index). Ein Beispiel f¨

ur einen Super-Peer/Peer In-

dex zeigt Grafik 3.6. Tabelle 3.4 zeigt dazu die unterschiedlichen Granularit¨

aten

des Index an Super-Peer SP2. Der Index beinhaltet alle direkten Nachbarn des

Super-Peers(SP1,SP3,SP4), die das Schema DC unterst¨

utzen. Ebenfalls beinhal-

tet der Index zwei Nachbarn, Peer SP1und Peer SP4, die ebenfalls das LOM Sche-

ma unterst¨

utzen. Weiterhin beinhaltet der Index Eintr¨

age ¨

uber den Wertebereich

Property Value Range in Verbindung mit der ACM CCS1Themen-Klassifikation:

1http://www.acm.org/class/1998/



3.1. Edutella

Abbildung 3.3: Super-Peer/Super-Peer Routing Index

Granularity Index of SP2

Schema dc SP1,SP3,SP4

lom SP1,SP4

Property

dc:subject SP1,SP3,SP4

dc:language SP1,SP4

lom:context SP1,SP4

Property dc:subject ccs:networks SP3

Value Range dc:subject ccs:software-eng. SP1,SP4

Property lom:context “undergrad” SP1,SP4

Value dc:language “de” SP1,SP4

Abbildung 3.4: SP/SP Index von SP2

ccs:networks ist ein ¨

ubergeordnetes Konzept f¨

ur ccs:ethernet und ccs:clientserver.

3.1.2 Bearbeitung von Anfragen

Die Aufgabe der verschiedenen Indizes ist die zus¨

atzliche Reduzierung der Nach-

richten f¨

ur eine Anfrage. Dazu wird eine Anfrage ¨

uber den Super-Peer/Peer und

den Super-Peer/Super-Peer Index an die Super-Peers bzw. Peers weitergeleitet, die

f¨

ur diese Anfrage die ben¨

otigten Schema Elemente im Index registriert haben. Eine

Ubereinstimmung bedeutet, das ein Peer die Anfrage beantworten kann, garantiert

jedoch keine nicht-leere Menge an Resultaten.

Beispiel 3.1.2 (Anfragebearbeitung in Edutella). Wir illustrieren die Funktions-

weise der Indizes an folgendem Beispiel:

Suche Lernmaterialien in deutscher Sprache aus dem Bereich Software-

Engineering f¨

ur Studenten im Grundstudium.



3.1. Edutella

Granularit¨

at Anfrage

Schema dc,lom

Property dc:subject,dc:language,lom:context

Property Value Range dc:subject ccs:sw’engineering

Property

Value

lom:context “undergrad”

dc:language “de”

Abbildung 3.5: Unterst¨

utzte Anfragen f¨

ur unterschiedliche Granularit¨

aten

Wir formalisieren diese Anfrage und verwenden Schema Elemente f¨

ur Dokumente

aus dem Schema DC und f¨

ur Lernmaterialien aus dem Schema LOM. Zus¨

atzlich

verwenden wir die ACM CCS Hierarchie zur Klassifikation der Dokumente:

Suche jede Resource bei der die Eigenschaft dc:language mit “de”,

dc:subject mit ccs:softwareengineering und lom:context mit “under-

grad” ¨

ubereinstimmt.

Tabelle 3.5 zeigt die notwendigen Granularit¨

aten innerhalb der Anfrage, beispiels-

weise wird mit DC und LOM auf Schema Level zugegriffen und bei lom :context =

undergrad auf Werteebene usw. Grafik 3.6 zeigt, wie Peer P0die Anfrage an

Super-Peer SP1sendet. Im unserem Beispiel kann die Anfrage von Peer P1und P4

beantwortet werden. Diese Peers sind an Super-Peer SP1und SP4registriert, de-

ren Index beinhaltet Metadaten ¨

uber die Resources rand sdie zur Anfrage passen.

Auf der Basis einer ¨

Ubereinstimmung im Schema-Level Index leitet Super-Peer

SP1die Anfrage nur an Peer P1weiter, der die Schemata lom and dc unterst¨

utzt.

Auf der Basis einer ¨

Ubereinstimmung im Property-level-index wird die Anfrage

von Super-Peer SP1an Peer P1weitergeleitet, da dieser Peer die Schema Ele-

mente dc:subject,dc:language and lom:context unterst¨

utzt. Aufbauend auf dem

Super-Peer/Super-Peer Index an SP1und SP2(siehe auch Abbildung 3.4) wird

die Anfrage an den Super-Peer SP4weitergeleitet. Hier erfolgt ebenfalls ein Ab-

gleich der Anfrage im Super-Peer/Peer Index. Aufgrund der ¨

Ubereinstimmung der

in der Anfrage geforderten Schema Elemente mit den von P4im Index registrierten

Schema Elementen wird die Anfrage an P4weitergeleitet. ∗

3.1.3 Aktualisierung des Index

Strategie und Ziel. Eine Aktualisierung des Super-Peer/Peer Index an einem

Super-Peer erfolgt dann, wenn ein neuer Peer sich im Index registriert, wenn die

Schema Informationen ¨

uber einen bereits registrierten Peer sich ¨

andern oder wenn

ein Peer den Index verl¨

asst. Verl¨

asst ein Peer den Super-Peer, werden alle Referen-

zen ¨

uber den Peer im Index gel¨

oscht. Dieser Fall tritt ebenfalls ein, wenn ein Peer



3.1. Edutella

Abbildung 3.6: Beispiel f¨

ur das Edutella Routing Modell

seine Registrierung nicht mehr regelm¨

assig wiederholt. Registriert sich ein Peer an

einem Super-Peer, werden die Schema Informationen des Peers mit den bereits am

Super-Peer vorhandenen Informationen anderer Peers verglichen. Existiert bereits

ein Eintrag f¨

ur am Peer verwendetes ein Schema oder ein Attribut, wird nur der

Peer im Index registriert, sonst wird das neue Schema oder das Attribut dem In-

dex hinzugef¨

ugt. Der Index stellt einen invertierten Index dar, in dem verwendete

Schema, Attribute usw. auf einzelne Peers abgebildet werden.

Algorithmus. Der Algorithmus f¨

ur den Eintrag eines Peers an einem Super-Peer

l¨

asst sich wie folgt formalisieren:

•Wir definieren Sals eine Menge von Schema Elementen. Wir verstehen un-

ter einem Schema Element dabei einzelne Attribute und vollst¨

andige Sche-

ma, wie DC:S={siki= 1...n}.

•Wir nehmen an, das ein Super-Peer bereits eine Menge von Schema Elemen-

ten Sxin seinem Super-Peer/Peer Index speichert. Wir verstehen unter dem

Super-Peer/Peer Index eine Abbildung si7→ {Pjkj= 1...m}.

•Wir definieren Pyals einen neuen Peer, der eine Registrierung am Super-

Peer SPxmit einer Menge von Schema Elementen ausf¨

uhren m¨

ochte.

Der Algorithmus f¨

ur die Registrierung eines Peers an einem Super-Peer lautet:

1. Wenn Sy⊆Sx, dann addiere Pyzur Liste der Peers an jedem si∈Sy



3.1. Edutella

Abbildung 3.7: HyperCuP Topology and Spanning Tree Example

2. Sonst, wenn Sy\Sx={sn, ..., sm} 6=∅, aktualisiere SP/P Index durch

Addieren von neuen Zeilen sn7→ Py, ..., sm7→ Py.

Aktualisierung des Super-Peer/Super-Peer Index. Wir beschreiben die Ak-

tualisierung des Super-Peer/Super-Peer Index im Super-Peer Backbone Netzwerk

im Fall, dass an einem Super-Peer ein neuer Peer registriert wurde. Wir nehmen

an, das jede Registrierung einen Aktualisierung des Super-Peer/Super-Peer Index

ausl¨

ost. Da der Super-Peer/Super-Peer Index eine Zusammenfassung aller verwen-

deten Schema Elemente an einem Super-Peer repr¨

asentiert, erfolgt eine Aktuali-

sierung nur, wenn ein neues Schema Element hinzugef¨

ugt wird. Wir betrachten

als Beispiel das Netzwerk in Grafik 3.6 und den Super-Peer/Super-Peer Index von

Super-Peer SP2, der in Tabelle 3.4 dargestellt ist. Ein neuer Peer Pxregistriert

sich an an Super-Peer SP1mit dem Attribut dc:language. Diese Registrierung l¨

ost

keine Aktualisierung des Super-Peer/Super-Peer Index aus, da dieses Schema Ele-

ment bereits im Super-Peer/Peer Index von SP1registriert war. Die Registrierung

eines weiteren Peers Pyan Sp1l¨

ost eine Aktualisierung aus, da dieses Element im

Super-Peer/Peer Index neu registriert werden muss.



3.2. TOPICS

Strategie und Ziel. Wie bereits in den vorhergehenden Abschnitten erw¨

ahnt

wurde, ist das Super-Peer Netzwerk in Form einer HyperCup Topologie organi-

siert, die implizit jeden Super-Peer als Wurzel in einem Spanning Tree ¨

uber das

gesamt Super-Peer Netzwerk definiert. ¨

Ahnlich dem Weiterleiten von Anfragen

agiert jeder Super-Peer ebenfalls als Wurzel f¨

ur einen Spanning Tree, jedoch in der

’entgegengesetzten Richtung’. Grafik 3.7 zeigt das am Beispiel f¨

ur Super-Peer G

und einen einfachen W¨

urfel, der drei Dimensionen aufspannt, so das jeder Knoten

drei Nachbarn hat.

F¨

ur die Aktualisierung des Super-Peer/Super-Peer Index, nach einer vorherigen

Aktualisierung des Super-Peer/Peer Index, erstellen wir einen Spanning Tree von

Super-Peer Gaus und gehen wie folgt vor: Super-Peer Gsendet eine Nachricht

zur Aktualisierung an alle seine Nachbarn. Jede Nachricht beinhaltet die Dimen-

sion der Kante, ¨

uber die sie gesandt wird. Super-Peers, die die Nachricht erhalten,

aktualisieren ihren Super-Peer/Super-Peer Index und leiten die Nachricht an al-

le Super-Peers mit einer geringeren Dimension weiter. Ein Super-Peer leitet eine

Nachricht nicht weiter, wenn keine Aktualisierung des Super-Peer/Super-Peer In-

dex erfolgt ist.

Algorithmus. Wir formalisieren den Algorithmus f¨

ur die Konstruktion des Span-

ning Trees wie folgt:

•F¨

ur alle si∈Sx∩Syf¨

uge die Dimension von SPxder Liste der Dimensionen

in der Spalte sihinzu, wenn die Dimension noch nicht existiert.

•F¨

ur alle si∈Sx\Syf¨

uge eine neue Spalte si7→ dimension(SPx)ein.

3.2 TOPICS

Neben komplexen Schema-basierten Beschreibungen der Dokumente werden in

verschiedenen Dom¨

anen Dokumente auch anhand semantischer Netze beschrie-

ben. Aufgrund ihres einfachen Aufbaus und der geringen Anzahl semantischer

Beziehungen zwischen den Konzepten wird h¨

aufig eine Themen-Hierarchie ver-

wendet. Einzelne E-Learning Repositories bieten Lernmaterialien zu verschiede-

nen Themen an. Zur Klassifikation der Themen werden Themen-Hierarchien der

Global Network Academy, der ACM Library oder des Open Directories verwendet.

Ein weiteres Beispiel sind digitaler Musikplattformen. Kunden tauschen Musik,

die zu einem bestimmten Genre geh¨

ort. AllMusic und MusicMoz klassifizieren ei-

ne halbe Million Musikst¨

ucke in einer Themen-Hierarchie nach Genre, K¨

unstler

und (Musik)Stimmung. Das Topics Netzwerk unterst¨

utzt die Lokalisierung von se-



3.2. TOPICS

Music Sharing Peers

Semantic Overlays

/Decade/1990

/Composers/Beethoven

/Style/Latin/Brazil/Bossa Nova

/Style/Classical/Symphony

Abbildung 3.8: Semantisches Overlay Netzwerk

mantisch annotierten Dokumenten in einem verteilten Netzwerk. Es wurde f¨

ur ein

Szenario mit folgenden Eigenschaften entwickelt:

Hohe Volatilit¨

at der Peers. Dokumente k¨

onnen lokal auf den Rechnern der ein-

zelnen Nutzer gespeichert werden. Aufgrund deren Autonomie k¨

onnen ein-

zelne Peer das Netzwerk jederzeit verlassen oder beitreten.

Browsen. Gew¨

unscht ist ein Browsen in der Themen-Hierarchie durch den Nut-

zer. Wird ein passendes Thema gefunden, soll eine Anfrage nach konkreten

Dokumenten nur an die Peers geleitet werden, die passende Dokumente f¨

das Thema bereitstellen.

Semantische Overlays Das TOPICS Netzwerk adaptiert Semantic Overlay Net-

works [LNS+03, CGM02b]. In derartigen Netzwerken wird das physikali-

sche Netzwerk in Themen-basierte Overlays aufgeteilt. Abh¨

angig von den

an einem Peer verf¨

ugbaren Dokumenten geh¨

ort ein Peer einem oder mehre-

ren Overlays an.

Beispiel 3.2.1 (Semantisches Overlay Netzwerk.). Grafik 3.8 zeigt sechs Peers,

die Musik zu unterschiedlichen Genres bereitstellen. Peers die zum selben Thema

geh¨

oren, formen ein Semantic Overlay Network (SON), beispielsweise

/Style/Latin/Brazil/Bossa Nova 7→ (A, B, C, D)

/Sytle/Classics/Symphonies 7→ (B, C, D)

Die Grundz¨

uge der TOPICS Architektur sind in Abbildung 3.9 dargestellt. Die Ar-

chitektur besteht aus zwei Komponenten: einem verteilten Index und autonomen

Peers, die sich im Index registrieren und in diesem browsen. Zur technischen Rea-

lisierung des Index kombiniert das TOPICS Netzwerk drei Komponenten:



3.2. TOPICS

Peer Node

Node

Profile

Metadata

Extractor

Summarizer

MP3 File

Distributed Catalog based on Super-Peers

Profile Node: E

/Composers/Beethoven

/Style/Classical/Symphony

Taxonomy Paths

--------------------------------------------------

/Style/Latin/Brazil/Bossa Nova

/Style/Classical/Symphony

/Composers/Beethoven

/Decade/1990

Node IDs

------------

A,B,C,D

C,D,E,F

B.C.D

Query:

/Composers/Beethoven AND

/Style/Classical //

Query Interface

Result Interpreter

Result:

Node E

Abbildung 3.9: Architekturmodell f¨

ur das Themen-Hierarchie-basierte Routing

Super-Peer Netzwerk. ¨

Ahnlich dem Edutella Netzwerk setzt sich der Index aus

einem Super-Peer mit wenigen statischen Peers zusammen [GMY02]. Super-

Peers erlauben Peers eine Registrierung und verteilen deren Profil im Index.

Eine Anfrage eines Peers wird zuerst an das Super-Peer Netzwerk weiterge-

leitet, in dem die Suche im verteilten Index erfolgt. In einem zweiten Schritt

wird das Resultat zum anfragenden Peer weitergeleitet.

Verteilte Hashtabellen. Sogenannte Distributed Hash Tables (DHT) eignen sich

f¨

ur Netzwerke mit geringer Volatilit¨

at und zur Suche von Objekten ¨

uber ex-

akte Schl¨

ussel. Sie erlauben die Suche nach Objekten ¨

uber deterministische

Routing Algorithmen und skalieren f¨

ur eine hohe Anzahl von Peers. Auf-

grund des statischen Super-Peer Netzwerkes und der eindeutigen Identifi-

zierung eines Themas in einer Themen-Hierarchie haben wir uns f¨

ur diese

Technologie entschieden.

Semantisches Hash-Schema. DHTs erlauben nur die Abbildung einfacher Struk-

turen von einen Schl¨

ussel auf ein Objekt. Zur Abbildung und f¨

ur den Zugriff

auf die Struktur einer Themen-Hierarchie stellen wir in Abschnitt 3.2.1 ein

geeignetes Konzept vor.



3.2. TOPICS

Die Operationen eines einzelnen Peers lassen sich in die Registrierung/Deregistrie-

rung und das Browsen im Index aufteilen:

•Registrierung/Deregistrierung. F¨

ur die Registrierung eines Peers im In-

dex werden zuerst die Metadaten aus den Dokumenten extrahiert. Aktuelle

Metadaten f¨

ur MP3, beispielsweise der ID3v2 Standard, stellen bereits eine

einfache Genre Klassifikation zur Verf¨

ugung. Wir nehmen an, das in Zukunft

jede Musikdatei ¨

uber eine ausf¨

uhrliche Klassifikation verf¨

ugt.

Eine weitere Komponente, der Summarizer, analysiert die Metadaten der

Dokumente und fasst f¨

ur jeden Peer die Beschreibungen zusammen. Ein Bei-

spiel f¨

ur eine Zusammenfassung in XML Notation wird im obigen Beispiel

auf der rechten Seite gezeigt. Es besteht aus einer ID des Peers, der Dekade,

der Anzahl der an diesem Peer zu der Dekade verf¨

ugbaren Dokumente, dem

Genre und der Anzahl der Dokumente zu dem Genre. Das fertig berechnete

Profil wird beim Eintritt des Peers im Index registriert. Verl¨

asst der Peer den

Index so wird das Profil gel¨

oscht. Eine genaue Beschreibung der einzelnen

Algorithmen f¨

ur die (De-) und Registrierung von einzelnen Peers erfolgt in

[Zim04].

Metadaten-Modell einer Datei:

<File>

Jobim_Corcovado.mp3

</File>

<1990/>

</Decade>

<Style>

<Latin>

</Brazil>

</Latin>

</Style>

</MP3File>

Metadaten-Modell eines Peers:

<Node>

<1990/>

</Decade>

<Style>

<Latin>

</Brazil>

</Latin>

</Style>

<Style>

</Style>

</Node>

•Browsen im Index. Ein Peer kann den Index nach einem Genre oder ei-

ner Dekade anfragen. F¨

ur die Anfrage verwenden wir eine Teilmenge der



3.2. TOPICS

verbreiteten XPATH Sprache[W3C03], die einen guten Kompromiss zwi-

schen Anfragem¨

oglichkeit und Einfachheit darstellt und die Auswahl von

Teilb¨

aumen erlaubt. Ein Dokument stimmt mit einem XPATH Ausdruck

uberein, wenn die Auswertung des Ausdruckes ein nicht leeres Ergebinis-

objekt erzeugt. Der folgende Ausdruck w¨

ahlt Peers aus, die Musikdateien

zum Genre Bossa Nova publizieren:

q1 = /Node/Style/Latin/Brazil/BossaNova/

Das Ergebnis der Anfrage ist eine Menge Sivon Peer, die mit der Anfrage

ubereinstimmen, beispielsweise f¨

ur die Anfrage Sq1= (A, B, C, D).

3.2.1 Abbildung von Themen-Hierarchien in einer DHT

Das Ziel von Distributed Hash Tables (DHT), wie CAN [RFH+01], Chord [SMK+01],

Pastry [RD01], P-Grid [Abe01] und Tapestry [ZKJ01], ist das effiziente Auffinden

von Daten in einer verteilten, dezentralen Infrastruktur. Dazu besitzen alle Syste-

me einen Routing-Algorithmus, der die Operation lookup(key) bei N Knoten

im Netzwerk unter Verwendung von O(log N)Nachrichten ausf¨

uhren kann. Die-

ser Schl¨

ussel wird dynamisch einem im Netzwerk existierenden Knoten zugewie-

sen, der auch als Root des Schl¨

ussels bezeichnet wird. Zur eindeutigen Zuweisung

von Schl¨

usseln zu Knoten besitzt in einer DHT jeder Knoten eine eindeutige ID.

Zus¨

atzlich wird eine Funktion zur Zuweisung von Schl¨

ussel zu Knoten-ID defi-

niert. Um Nachrichten effizient zum Root eines Schl¨

ussels zu routen, wird ¨

uber

der physikalischen Netzwerkebene noch eine logische Ebene zum Routing mit-

tels Schl¨

usseln erstellt. Dazu besitzt jeder Knoten eine Routingtabelle mit Knoten-

IDs und entsprechenden IP-Adressen bestimmter Knoten des Netzwerkes. Zum

Root eines Schl¨

ussels wird geroutet, indem aus der Routingtabelle ein Knoten aus-

gew¨

ahlt wird, dessen ID sukzessive n¨

aher am Schl¨

ussel ist.

Zur Realisierung der Abbildung der Beziehungen der Themen-Hierarchie bie-

tet die DHT die Methoden put(key, data) und lookup(key) um beliebige

Daten unter einem Schl¨

ussel zu speichern, beziehungsweise die Daten unter einem

Schl¨

ussel zu erfragen. Themen sind in einer Themen-Hierarchie eindeutig ¨

uber ih-

ren Pfad definiert, den wir als Schl¨

ussel verwenden.

Definition 3.2.1 (Schl¨

ussel f¨

ur ein Thema). Sei tein Thema, tpath der Pfad durch

den das Thema definiert ist und heine Hashfunktion dann ergibt sich der Schl¨

ussel

ktpath f¨

ur tdurch

kt=h(tpath)



3.2. TOPICS

Style

Latin

Brasil

Bossa Nova

Classical

Symphony

Abbildung 3.10: Verteilung von Dokumenten ¨

uber eine Themen-Hierarchie

Beispiel 3.2.2. Sei tdas Thema Bossa Nova definiert durch /Style/Latin/Brazil/-

Bossa Nova dann wird der Schl¨

ussel berechnet als

$EA66 = h(/Style/Latin/Brazil/BossaNova)

Unter jedem Schl¨

ussel speichern wir die Peers, die Dokumente f¨

ur das Thema im

Index registriert haben. Dazu verwenden wir das Konzept der invertierten Liste.

Definition 3.2.2 (Objekt f¨

ur einen Schl¨

ussel (1)). Unter jedem ktspeichern wir

alle IDs passender iPeers PID1...PIDif¨

ur t.♣

Beispiel 3.2.3 (Objekt f¨

ur einen Schl¨

ussel (1)). F¨

ur die in Abbildung 3.8 beschrie-

benen Peers beinhaltet die verteilte Hashtabelle folgende Eintr¨

age:

Hash Key Objekt

$EA66 A,B,C,D

$CCEE C,D,E,F

$AB55 B,C,D

$6520 E

$EA66 /Style/Latin/Brazil/Bossa Nova

$CCEE /Style/Classical/Symphony

$AB55 /Decade/1990

$6520 /Composers/Beethoven

∗

Werden unter einem Schl¨

ussel ktkeine Peers gefunden, so soll die Suche bei den

in subsumierender Beziehung zu tstehenden Termen fortgesetzt werden k¨

onnen.

Definition 3.2.3 (Objekt f¨

ur einen Schl¨

ussel (2)). Getrennt von den IDs der Peers

werden unter einem ktalle Terme t0vtgespeichert. Dazu wird f¨

ur jedes Thema

t∈tpath mit Hilfe der Hashfunktion hein Schl¨

ussel berechnet, beginnend mit dem

spezifischsten Thema. ♣

Beispiel 3.2.4 (Objekt f¨

ur einen Schl¨

ussel(2)). Wir wenden die Hashfunktion auf

jeden Teilpfad an:



3.2. TOPICS

$EA66 /Style/Latin/Brazil/Bossa Nova

$AB33 /Style/Latin/Brazil

$3A56 /Style/Latin

$FF7A /Style

$CCEE /Style/Classical/Symphony

$BA7F /Style/Classical

Zur Erhaltung der Subsumption Beziehung speichern wir im Index f¨

ur das n¨

achst-

spezifischere Thema timit tvtiein Mapping w(ti, t):

Hash Key Objekt

$FF7A w/Style/Classical

w/Style/Latin

$BA7F w/Style/Classical/Symphony

$3A56 w/Style/Latin/Brazil

$AB33 w/Style/Latin/Brazil/Bossa Nova/

∗

Die vollst¨

andige Hashtabelle speichert im Objekt eines Schl¨

ussel sowohl die regi-

strierten Peers und vorhandene Beziehungen:

Hash Key Objekt

$3A56 w/Style/Latin/Brazil

$AB33 w/Style/Latin/Brazil/Bossa Nova/

$BA7F w/Style/Classical/Symphony

$CCEE C,D,E,F

$EA66 A,B,C,D

$FF7A w/Style/Classical

w/Style/Latin

3.2.2 Semantisches Browsen in einer DHT

Die semantischen Strukturen des verteilten Index erlauben einem Nutzer des Brow-

sen im Index. Dabei treten folgende drei F¨

alle auf.

Exakte ¨

Ubereinstimmung. Eine Beispiel f¨

ur eine exakte Anfrage ist Gib alle

Peers, die Musik von Beethoven anbieten:

q1 = /Composers/Beethoven/



3.2. TOPICS

Die Berechnung der PIDs unterscheidet sich nicht von einem Standard Lookup

in der verteilten Hashtabelle. F¨

ur q1wird der Hashwert $6520 entsprechend De-

finition 3.2.1 berechnet. Mit der Funktion lookup(h(q1)) wird folgende PID f¨

q1ermittelt: q1=E. Da nur ein Lookup notwendig ist betragen die Kosten f¨

ur den

Lookup O(log N)Nachrichten.

Spezielleres Thema. Der Nutzer kennt nur den Pfad f¨

ur ein spezielleres Thema.

Ein Beispiel f¨

ur eine solche Anfrage ist: Gib alle Peers mit Bossa Nova Gitarren

St¨

ucken:

q2 = /Style/Latin/Brazil/BossaNova/Guitar/

Eine Anwendung der Hash Funktion h(q2) und der Funktion lookup(h(q2)) im

Index erfolgt mit einer leeren Resultatmenge. Der Nutzer w¨

ahlt das n¨

achstgenerelle

Thema aus der Struktur der Anfrage.

q20=/Style/Latin/Brazil/BossaNova/

und ermittelt das Resultat q20={A, B, C, D}

Generelleres Thema. Durch die Speicherung der semantischen Beziehungen in

der verteilten Hashtabelle k¨

onnen wir f¨

ur eine Anfrage auch Peers ber¨

ucksichti-

gen, deren Inhalte auch f¨

ur ein spezielleres Thema registriert sind, als das in der

Anfrage definierte Thema. Ein Nutzer kann dadurch den semantischen Baum ite-

rativ nach spezielleren Themen durchsuchen und ist damit nicht mehr auf einen

exakte ¨

Ubereinstimmung mit der Anfrage angewiesen. Ein Beispiel f¨

ur eine solche

Anfrage ist: Gib mir alle Peers die klassische Musik anbieten:

q3 = /Style/Classic//

Wiederum wird auf q3die Hashfunktion angewendet und das Ergebnis im Index

angefragt mit der Funktion lookup(h(q3)). Das Ergebnis ist in diesem Fall ein Ver-

weis auf die Unterkategorie /Style/Classics/Symphony. Da der Nutzer keine

passenden Peers erhalten hat, bildet er eine neue Anfrage q30. F¨

ur q30wird iterativ

ein weiterer Lookup ausgef¨

uhrt lookup(h(q30)), das Ergebnis ist q3’ = {C,D,E,F}.

Die Anzahl der Nachrichten steigt mit der Anzahl der besuchten Mappings m. Die

gesamten Kosten f¨

ur die eine solche Anfrage betragen O(log N)∗ |m|.

3.2.3 Lastverteilungstrategien

Die unterschiedliche Popularit¨

at und Nachfrage einzelner Themen belastet die Super-

Peer Knoten des globalen Index unterschiedlich stark. Im ung¨

unstigsten Fall erh¨

alt



3.2. TOPICS

ein Super-Peer eine hohe Anzahl von Anfragen bzw. eine hohe Anzahl von Regi-

strierungen von Peer-Modellen innerhalb einer kurzen Zeitspanne. Diese ungleiche

Verteilung kann zur v¨

olligen Auslastung einzelner Super-Peers f¨

uhren, w¨

ahrend

auf anderen Super-Peers noch freie Kapazit¨

aten verf¨

ugbar sind. Die Folge ist ei-

ne schlechte Skalierung des verteilten Index f¨

ur Anfragen mit besonders popul¨

aren

Themen. In Peer-to-Peer Systemen wird diesem Problem durch Verfahren der Last-

verteilung (Load Balancing) begegnet. Wir unterteilen das Problem der Lastvertei-

lung f¨

ur unser Szenario in folgende Teilprobleme:

•Lastverteilung f¨

ur die Registrierung im Index

•Lastverteilung von Anfragen an den Index

Wir stellen ausgew¨

ahlte State-Of-The-Art Ans¨

atze am Beispiel von CHORD [SMK+01]

kurz vor und wenden diese auf unser Szenario an. Aufgrund der Komplexit¨

at der

einzelnen Ans¨

atze verweisen wir f¨

ur eine ausf¨

uhrliche Diskussion auf die im fol-

genden Abschnitt aufgef¨

uhrte Literatur. Eine Implementierung der vorgestellten

Ans¨

atze f¨

ur das Szenario erfolgte in [Zim04].

Lastverteilung f¨

ur die Registrierung im Index

Um den globalen Index aktuell zu halten, registriert jeder Peer bei jedem Eintre-

ten in das Netzwerk und innerhalb eines bestimmten Zeitintervalls, beispielswei-

se einmal innerhalb 3600 Sekunden, sein vollst¨

andiges Model im Index. Dadurch

entsteht Last an den Super-Peers f¨

ur die Speicherung der Modelle der Peers und

f¨

ur die ¨

Ubertragung der Modelle. Durch die Zipf-verteilte [Zip49] Popularit¨

at der

Themen erhalten Super-Peers, die f¨

ur besonders popul¨

are Themen zust¨

andig sind,

auch besonders viele Anfragen von Peers f¨

ur eine Registrierung. Dadurch entsteht

an diesen Peers ein erh¨

ohtes Aufkommen von Nachrichten und ein erh¨

ohter Spei-

cherplatzbedarf f¨

ur die Speicherung der Modelle.

Eine L¨

osungsvariante f¨

ur das CHORD Netzwerk ist das in [SMK+01] vor-

gestellte Konzept der Virtual Server. Jeder Super-Peer besitzt mehrere virtuelle

IDs mit denen er an der DHT teilnimmt und so vorgibt, mehrere nicht zusam-

menh¨

angende virtuelle Index Knoten zu repr¨

asentieren. Die Gr¨

osse des Adressrau-

mes eines Super-Peers ergibt sich damit aus der Summe der einzelnen Gr¨

ossen

der Adressr¨

aume der virtuellen Index Knoten. Wird die Last f¨

ur einen Super-Peer

zu hoch, kann ein virtueller Index Knoten, und damit nur ein Teil des Adressrau-

mes, von einem ¨

uberlasteten Super-Peer auf einen weniger belasteten Super-Peer

transferiert werden. Das beinhaltet den Transfer der Schl¨

ussel und der unter dem

Schl¨

ussel registrierten Objekte. Ein Transfer des virtuellen Super-Peers wird durch

die Chord-Operationen leave und join durchgef¨

uhrt. Das Ziel ist die Optimierung



3.2. TOPICS

der ¨

uberlasteten Super-Peers (Heavy Nodes) durch den Transfer zu unbelasteten

Knoten (Light Nodes). Dazu speichert der Lastverteilungsalgorithmus die Lastin-

formationen der Super-Peers in einer Reihe von Verzeichnissen. Diese Verzeich-

nisse f¨

uhren periodisch eine Neuzuweisung von virtuellen Super-Peers durch, um

die Last besser zu verteilen. Algorithmen f¨

ur die Neuzuweisung der Verzeichnisse

werden f¨

ur statische Netzwerke in [RLS+03] und f¨

ur dynamische Netzwerke in

[GBL+04] vorgestellt.

Lastverteilung der Anfragen an den Index

Durch die Zipf-Verteilung [Zip49] der unterschiedlich popul¨

aren Anfragen [Sri01,

SGG03] werden einige Knoten mit einer besonders hohen Anzahl von Anfragen

belastet [YRS02]. Bei einer Lastverteilung mit dem Virtual Server Ansatz wird nur

die ungleiche Last beim Einf¨

ugen von Modellen ber¨

ucksichtigt. Ein speziell auf

Anfragen ausgerichteter Algorithmus w¨

urde diese Lastverteilung nochmals ver-

bessern.

Verschiedene Designer [SMK+01, RFH+01] von Peer-to-Peer Systemen ha-

ben das Caching von Index Eintr¨

agen entlang des Anfragepfades vorgeschlagen.

Diese Strategie wird auch als Path Caching with Expiration (PCX) bezeichnet, da

die im Cache vorhandenen Ergebnisse nach einer bestimmten Zeit als veraltet an-

gesehen und gel¨

oscht werden. PCX ist w¨

unschenswert, da es die Last f¨

ur popul¨

are

Anfragen ¨

uber mehrere Knoten verteilt, die Latenz reduziert und Hot Spots vermei-

det. Im Chord Ansatz gibt O(log n) Verweise auf einen Knoten des Netzwerkes. Im

letzten Routingschritt zu einem Knoten kann eine Anfrage nur von einer kleinen

Anzahl anderer Knoten stammen. In PCX erfolgt ein Cachen entlang des Anfra-

gepfades sinnvoll, da auch bei wenigen im Cache vorhandenen Ergebnissen mit

hoher Wahrscheinlichkeit eine Anfrage auf ein bereits im Cache vorhandenes Er-

gebnis trifft bevor sie den eigentliches Zielknoten erreicht. In diesen F¨

allen kann

die Anfrage sofort aus den Daten im Cache beantwortet werden. Dadurch wird die

Bandbreite f¨

ur das Routing der Anfrage bis zu ihren eigentlichen Zielknoten und

die Bandbreite f¨

ur das Routing der Ergebnisse zur¨

uck eingespart. Zus¨

atzlich wird

die Antwortzeit von Anfragen verringert, da weniger Routingschritte ben¨

otigen

werden.

Eine wichtige Frage ist die Aktualit¨

at des Caches in einem Peer-to-Peer Netz-

werk. Aufgrund der hohen Dynamik der Peers veralten die Inhalte der Caches

schnell. Die Zeitdauer der G¨

ultigkeit eines Eintrags im Cache muss bei PCX kurz

sein, wenn keine veralteten Ergebnisse zur¨

uckgeliefert werden sollen. Eine Folge

davon ist, dass in bis zu 50 % aller F¨

alle eine Anfrage auf einen passenden und

auch g¨

ultigen Cacheeintrag trifft, diesen aber nicht benutzen kann, da er als ver-

altet angesehen wird [CK01]. Roussopoulos [RB03] schl¨

agt zur Optimierung das



3.3. Verwandte Arbeiten

Controlled Update Propagation (CUP) Verfahren vor, um Caches aktuell zu hal-

ten. Knoten k¨

onnen sich an bestimmten Schl¨

usseln registrieren, so dass sie Updates

f¨

ur Inhalte unter diesem Schl¨

ussel erhalten. F¨

ur jeden Schl¨

ussel zu dem ein Knoten

Anfragen erh¨

alt, wird die Anzahl der Anfragen in einer bestimmten Zeit registriert.

Anhand einer Metrik aus der Popularit¨

at, der Entfernung in Routingschritten von

dem f¨

ur den Schl¨

ussel verantwortlichen Super-Peer und der H¨

aufigkeit von Upda-

tes f¨

ur einen Schl¨

ussel, kann ein Knoten berechnen ob es sich lohnt, weiter Updates

f¨

ur den Schl¨

ussel zu erhalten oder sich f¨

ur Updates zu registrieren. Erh¨

alt ein Kno-

ten ein Update, so spart sich der Knoten die Kosten f¨

ur das Weiterleiten der Anfra-

ge und den Empfang des Suchergebnisses, hat daf¨

ur aber Kosten f¨

ur den Empfang

der Updates zu erbringen. Wenn die Kosten der Einsparungen den Overhead ¨

uber-

steigen, so entscheidet sich ein Super-Peer daf¨

ur Updates f¨

ur einen Schl¨

ussel zu

erhalten. Ist es nicht mehr von Vorteil Updates zu erhalten, so de-registriert sich

ein Knoten am Schl¨

ussel. Simulationen der Autoren von CUP haben gezeigt, dass

je mehr Anfragen an ein System gestellt wurden, desto gr¨

osser waren die Einspa-

rungen mit CUP an Bandbreite und desto geringer war die Latenzzeit von Anfragen

im Vergleich zu PCX.

3.3 Verwandte Arbeiten

Verteilte Datenbanken [Vz99] benutzen Kataloge zur Speicherung von Informa-

tionen ¨

uber die Fragmentierung der Datenbank. Jede Datenbank verf¨

ugt ¨

uber eine

eigene Replica des Kataloges und berechnet auf dieser Grundlage, ob eine Anfrage

lokal oder an einer entfernten Datenbank ausgef¨

uhrt werden soll. Da alle Datenban-

ken eines verteilten Datenbank Managementsystems (DDBMS) unter der Kontrol-

le einer einzelnen Autorit¨

at verbleiben, ist die Anzahl der einzelnen Datenbanken

beschr¨

ankt.

Globale Kataloge zur Lokalisierung von Datenquellen und Dateien wurden

k¨

urzlich zur Optimierung der Auswahl von verteilten, text-basierten Datenquel-

len f¨

ur eine Anfrage vorgestellt. Im Gegensatz zu TOPICS und Edutella basiert der

Ansatz von [FPV+98] auf einem zentralen Verzeichnis, das einen unerw¨

unschten

Single Point of Failure darstellt. Zur Vermeidung dieses Problems stellen [GGM95]

[DADA96] einem hierarchischen Broker Ansatz vor, der jedoch zus¨

atzlichen admi-

nistrativen Aufwand f¨

ur die Pflege der asymmetrischen Netzwerk Struktur ben¨

otigt.

Die in diesem Kapitel vorgestellten Ans¨

atze TOPICS und Edutella unterscheiden

sich von dieser Design-Philosophie, da sie keine zentrale Kontrolle des Systems

voraussetzen.

Eine ¨

ahnliche Idee wie TOPICS und Edutella verfolgen verteilte Publish/Sub-

scribe Ans¨

atze. Ein Beispiel f¨

ur ein solches System ist INS/Twine [BBK02]. Die



3.4. Zusammenfassung

Beschreibungen der Ressourcen werden in einer verteilten Hashtabelle gespeichert

und abgefragt. Zur Vermeidung einer ungleichen Belastung der Knoten in der DHT

werden die Beschreibungen gleich ¨

uber die Knoten verteilt. Zus¨

atzlich wird jede

Beschreibung redundant gespeichert. Das System unterst¨

utzt keine semantischen

Beziehungen zwischen den Beschreibungen einzelner Ressourcen.

SCRIBE [RKCD01] realisiert einen Multi-Cast auf Anwendungsbene. Es ba-

siert auf dem DHT-Protokoll Pastry [RD01]. Nutzer und Nachrichten k¨

onnen the-

matisch Gruppen zugeordnet werden. Nachrichten werden dann innerhalb der Grup-

pe an alle Mitglieder weitergeleitet. Das System erlaubt nur ein exakten Vergleich

zwischen dem Thema einer Nachricht und der Gruppe.

Galanis beschreibt in [GWJD03] einen Katalog der ebenfalls auf der Basis

verteilter Hashtabellen realisiert wird. Der Ansatz speichert XML Schemata in ei-

nem globalen verteilten Index. Anfragen erfolgen auf der Basis komplexer XML-

Schemata. Das Matching ist jedoch auf exakte ¨

Ubereinstimmungen zwischen einer

Anfrage und dem Schema begrenzt und unterst¨

utzt keine semantischen Beziehun-

gen.

Ein Vision f¨

ur die semantische Interoperabilit¨

at wird von Bernstein in [BGK+02]

beschrieben. Er stellt das (Local Relational Model) LRM vor, das die Transformati-

on von Anfragen aufgrund der lokalen Schemata der einzelnen Peers erlaubt. Durch

Query-Rewriting wird die Anfrage ¨

uber Mapping Regeln auf lokale Schemata ab-

gebildet.

Ahnlich dem Edutella Ansatz integriert das PIAZZA Projekt [HIMT03] ver-

schiedene Informationsquellen in ein Peer Data Management System. Es verf¨

ugt

uber zus¨

atzliche Mappings zwischen den Schemata der einzelnen Peers und leitet

Anfragen entlang der Schemata. In Kontrast zu Edutella verwendet PIAZZA ein

hybrides Peer-to-Peer Modell. Die Indizierung der einzelnen Peers und das Map-

ping erfolgt in einer zentralen Komponente.

3.4 Zusammenfassung

Ziel dieses Kapitels war die Vorstellung von Konzepten zur Realisierung eines glo-

balen und verteilten Index. Er soll die Registrierung und Lokalisierung von Res-

sourcen mit komplexen Metadatenstrukturen unterst¨

utzen. Dazu stellen wir zwei

neue Frameworks, Edutella und TOPICS, vor. Beide Ans¨

atze verwenden einen glo-

balen, jedoch vollst¨

andig verteilten Index in einem Peer-to-Peer Netzwerk. Ein sol-

cher Index ist besonders f¨

ur Szenarien interessant, in denen keine finanziellen oder

administrativen Voraussetzungen f¨

ur eine zentrale Infrastruktur geschaffen wer-

den k¨

onnen, jedoch eine kleine Anzahl permanent verf¨

ugbarer Rechner dezentral

vernetzt ist. Technologisch realisieren beide Ans¨

atze den Index ¨

uber eine Super-



3.4. Zusammenfassung

Peer Infrastruktur. Zur Verringerung der Nachrichten f¨

ur das Routing und die Re-

gistrierung der Peers verwenden wir in Edutella neben der Super-Peer Infrastruktur

einen effizienten Broadcast Algorithmus und einen zweigeteilten Routing-Index.

Der TOPICS Ansatz verf¨

ugt ¨

uber eine Index Struktur auf der Basis verteilter Has-

htabellen, die im Super-Peer Netzwerk verwaltet wird. Im Index speichern wir die

semantische Struktur einer Themen-Hierarchie und Peers, die ein konkretes Thema

unterst¨

utzen.



Teil II

Adaptive Overlays auf der Basis

lokaler Shortcut Indizes



Der INGA Ansatz

Die Suche in Peer-to-Peer Netzwerken kann sowohl mit einem globalen Index und

mit lokalen Index Strukturen erm¨

oglicht werden. In dieser Arbeit betrachten wir

beide Ans¨

atze. Im letzten Kapitel haben wir bereits Overlay Netzwerke auf der

Basis eines globalen und in einem statischen Super-Peer Netzwerk verteilten Index

vorgestellt. In diesem Kapitel entwickeln wir eine neue Art von Overlay Netzwer-

ken auf der Basis von Shortcuts, die wir in lokalen Indices speichern. Die grund-

legende Idee des INGA Ansatzes (Interest based Node Grouping Architecture) ist

es, die Anzahl der anzufragenden Peers durch die Analyse bereits gestellter er-

folgreicher Anfragen des eigenen oder anderer Peers einzuschr¨

anken. Jeder Peer

verwaltet dazu Informationen ¨

uber Shortcuts, Anfragen und erfolgte Antworten in

einem lokalen Index. Zum Aufbau der Shortcuts stellen wir soziale Metaphern auf

und f¨

uhren kurz in den Zusammenhang zwischen dem Small World Ph¨

anomen und

sozialen Netzwerken ein. Zum Abschluss dieses Kapitels zeigen wir die Architek-

tur eines Peers im INGA Netzwerk.

4.1 Anforderungen

In den letzten Jahren sind in Forschung und Industrie verst¨

arkt drei Trends zu be-

obachten: eine Explosion unstrukturierter lokaler Daten, die Notwendigkeit der

Strukturierung dieser Daten und der Austausch von Daten und Strukturen in und

zwischen einzelnen Unternehmen. Aufgrund der Un¨

ubersehbarkeit und Un¨

uber-



4.1. Anforderungen

schaubarkeit von Personen und vorhandenen Dokumenten wird der Informations-

suche in grossen Unternehmen und verteilten Organisationen ein wesentlicher An-

teil der gesamten Arbeitszeit gewidmet. Verschiedene Anbieter haben das Problem

erkannt und stellen Software f¨

ur das Durchsuchen des lokalen Desktops bereit.

Erfolgreiche Beispiele daf¨

ur sind Google Desktop Search, die Microsoft Desktop

Search oder das Copernic Search System.

Ein Großteil aller relevanten Informationen wird in einem Unternehmen je-

doch ’Peer-to-Peer’ - von Kollege zu Kollege - ausgetauscht, aber nur wenn man

den ’richtigen Kollegen’ auch kennt. Diese Funktionalit¨

at der vernetzen Desktop

Suche wird jedoch von den derzeitig existierenden lokalen Desktop Such Techno-

logien noch nicht zur Verf¨

ugung gestellt. Zur Reduzierung des Aufwandes und der

Kosten der Informationssuche in einem Unternehmen und seinem Netzwerk, wie

Partnern und Kunden, werden neben den verf¨

ugbaren Web-Suchmaschinen immer

h¨

aufiger lokale Suchwerkzeuge ben¨

otigt, die f¨

ur eine Suche im vernetzten Unter-

nehmen optimiert sind. Nur wenn ein Unternehmen die W¨

unsche seiner Kunden

kennt, kann es seine Produkte und Dienstleistungen gezielt auf deren Bed¨

urfnisse

abstellen. Nur wenn ein Unternehmen das kollektive und individuelle Wissen sei-

ner Mitarbeiter erschließt, verk¨

urzt es seine Produktentwicklungszeiten, minimiert

die Gefahr von Fehlentwicklungen und macht sich unabh¨

angig von einzelnen Wis-

senstr¨

agern und gewinnt die entscheidenden Wettbewerbsvorteile, die den lang-

fristigen Erfolg sicherstellen. Im privaten Bereich existieren bereits erfolgreiche

Peer-to-Peer Anwendungen, wie Gnutella und Kazaa, die eine einfache lokale Pu-

blikation und Suche von Musik-Dateien in einem Netzwerk erm¨

oglichen. Da kein

Single Point of Failure existiert, sind diese Netzwerke robust. Durch ihre Selbst-

organisation ben¨

otigen sie keine zentrale Administration und erlauben durch den

verteilten Ansatz keine zentrale politische Kontrolle. Bisher wurden diese Techno-

logien jedoch nur f¨

ur die Internet-weite Suche nach Medienclips verwendet.

Inspiriert durch [FFK04] schlagen wir vor, durch den Austausch und die Suche

von Dokumenten innerhalb und ausserhalb institutioneller Barrieren eine kolla-

borative Wissens - Koproduktion zu erm¨

oglichen bzw. deutlich zu vereinfachen.

Wir sehen das Einsatzspektrum von Peer-to-Peer Anwendungen in Unternehmen

mit einem hohem Potential an Knowledge Workern, die an ihren lokalen Desktops

Dokumente zu ihren Interessen ansammeln und neue Dokumente produzieren. In

diesem und den folgenden Kapiteln kombinieren wir in der Interest-based Node

Grouping Architecture, kurz INGA Desktop Netzwerk, die Vorz¨

uge der verteilten

Suche, die Selbstorganisation und die Robustheit von Peer-to-Peer Technologien

mit der Suche in lokalen Desktops. Unser Ziel ist die Beschreibung von technolo-

gischen Konzepten f¨

ur einen neuen Typ von Infrastrukturen f¨

ur den Austausch und

die Suche von lokal verf¨

ugbaren Dokumenten.



4.1. Anforderungen

In der Theorie eigenen sich Peer-to-Peer Netzwerke ideal f¨

ur die Realisierung ei-

nes vernetzten Desktop-Netzwerkes. Ein Hauptproblem in der Praxis besteht je-

doch in einer kosteng¨

unstigen und effizienten Realisierung der Suche in den ver-

teilten Desktops. Prinzipiell stehen daf¨

ur zwei Typen von Peer-to-Peer Netzwer-

ken zur Verf¨

ugung: Unstrukturierte [Gnu04] und strukturierte [SMK+01, RFH+01,

RD01, Abe01] Peer-to-Peer Netzwerke. Im Folgenden stellen wir ausgesuchte De-

signmerkmale einer Infrastruktur zur Desktopsuche vor und diskutieren die Vor-

und Nachteile der jeweiligen Peer-to-Peer Konzepte:

•Lokale Kontrolle. Die Akzeptanz des INGA Desktop Netzwerkes h¨

angt

stark von der Kontrolle der eigenen Daten ab. In einem Desktop Netzwerk

sollte die Speicherung und Verwaltung nutzerbezogener Informationen aus-

schließlich lokal erfolgen. Sie erm¨

oglicht einem Nutzer die unmittelbare

Kontrolle ¨

uber das eigene Profil, beispielsweise ¨

uber gespeicherte Anfragen

und publizierte Dokumente.

In unstrukturierten Netzwerken erfolgt die Speicherung und der Zugriff auf

das Profils eines Peers ausschließlich lokal. Im Gegensatz dazu wird in struk-

turierten und hybriden Netzwerken [Nap03] das Profil des Nutzers an einem

entfernten Peer registriert und abgefragt, der Nutzer gibt dadurch die Kon-

trolle ¨

uber seiner Daten ab. Das f¨

uhrt einerseits zu einer technologischen

(Single Point of Failure)und zu einer ’politischen’ Abh¨

angigkeit (Auswer-

tung der Nutzerdaten f¨

ur Werbemails, Sperren einzelner Dateien und Nut-

zer).

•Geringe Managementkosten f¨

ur den einzelnen Peer. Durch die Installati-

on einer kostenlosen Software und ohne Ber¨

ucksichtigung besonderer ad-

ministrativer oder finanzieller Vereinbarungen wird ein Peer spontan Teil

einer existierenden, v¨

ollig dezentralen, selbstorganisierenden Infrastruktur.

Die Kosten f¨

ur die Publikation und das L¨

oschen von Dokumenten und der

Bekanntmachung der Identit¨

at des Peers sollen je nach Nutzung und Betei-

ligung ¨

uber die Peers im Netzwerk verteilt werden. Insgesamt soll im INGA

Desktop Netzwerk jeder Peer nur geringe Ressourcen zur Verwaltung von

Dokumenten und des Netzwerkes beisteuern.

Bedingt durch das konsistente Hashing in einem strukturierten Netzwerk

verwaltet jeder Peer zu einem grossen Anteil Profile anderer Peers. Dieser

Ansatz hat mehrere Nachteile: Die Informationen sind meist f¨

ur den eigenen

Peer von geringer Relevanz und nicht direkt nutzbar. Jeder Peer muss je-

doch zus¨

atzliche technische Ressourcen, wie Bandbreite und Speicherplatz,

zur Verf¨

ugung stellen. F¨

ur eine gerechte Verteilung der Kosten werden Tech-

nologien zum Lastausgleich und f¨

ur die Replikation eingesetzt. F¨

ur volatile



4.1. Anforderungen

Netzwerke sind die daf¨

ur anfallenden Kosten hoch.[LHH+04] zeigen, das,

durch den Aufwand f¨

ur das h¨

aufige Publizieren und L¨

oschen von Eintr¨

agen

im Index f¨

ur popul¨

are Dokumente, strukturierte Peer-to-Peer Netzwerke eine

geringere Effizienz aufweisen, als unstrukturierte Netzwerke mit auf ¨

Uber-

flutung basierenden Ans¨

atzen.

Unstrukturierte Netzwerke weisen deutlich geringere Kosten f¨

ur die Verwal-

tung des Netzwerkes und der Verwaltung der auf einem Peer gespeicherten

Dokumente auf. Typischerweise verwaltet jeder Peer nur sein eigenes Profil.

Derartige Netzwerke nutzen die ungleiche Verteilung popul¨

arer Inhalte f¨

die Optimierung der Suche aus und passen sich mit geringem Aufwand an

eine dynamische Verf¨

ugbarkeit von Dokumenten und Peers an.

•Effizientes Routing von Anfragen. In Netzwerken mit mehreren 10.000

Teilnehmern und einer hohen Anzahl von Anfragen pro Peer sind die Kosten

f¨

ur eine Suchanfrage, respektive die Anzahl der Nachrichten, ausschlagge-

bend f¨

ur die Effizienz des Routing Verfahrens. Um das INGA Desktop Netz-

werk auch f¨

ur eine grosse Anzahl von Nutzern zu erm¨

oglichen, muss eine

effiziente Routing Technologie eingesetzt werden.

Durch die Verwendung von deterministischen Routing Algorithmen skalie-

ren strukturierte Netzwerke gut f¨

ur eine grosse Anzahl von Peers. Diese

Netzwerke eigenen sich besonders f¨

ur die Lokalisierung von Dateien mit

einer exakten ¨

Ubereinstimmung mit der Anfrage und von Dateien, die durch

einen eindeutigen Schl¨

ussel gekennzeichnet werden k¨

onnen.

Suchstrategien in unstrukturierten Netzwerken basieren auf der unkontrol-

lierten ¨

Uberflutung des Netzwerkes mit Nachrichten. Sie sind einfach und

robust, auch f¨

ur hoch volatile Netzwerke, ben¨

otigen jedoch eine hohe An-

zahl von Nachrichten [GMY02].

Gew¨

unscht ist eine Infrastruktur, die ¨

uber die Vorz¨

uge eines unstrukturierten Netz-

werkes, wie geringe Publikationskosten bei hoher Dynamik, Lokalit¨

at des Peer

Profils, effizientes Bearbeiten komplexer Anfragen, verf¨

ugt, jedoch deren Nach-

teile, wie die hohe Anzahl von Nachrichten f¨

ur Suchanfragen und den geringen

Recall f¨

ur unpopul¨

are Dokumente, behebt. Diese Anforderungen ¨

uberschreiten die

Leistungsf¨

ahigkeit aktueller Peer-to-Peer Technologien. Ideal w¨

are ein Ansatz, bei

dem ein anfragender Peer mit hoher Wahrscheinlichkeit bereits ’seine Communi-

ty’, Peers mit potentiellen Antworten, kennt und eine Anfrage nur an diese Aus-

wahl leiten muss.

Wir haben einen Ansatz entwickelt, der auf den Prinzipien der Suche in so-

zialen Netzwerken aufbaut. Ein Peer gewinnt ¨

uber die Zeit Informationen, welche



4.2. Soziale Netzwerke und das Small World Ph¨

anomen

anderen Peers besonders ’gut’ Antworten beisteuern konnte und verfeinert die-

ses Wissen ¨

uber sein ’pers¨

onliches Experten Netzwerk’ durch st¨

andige Interaktion

weiter. Dadurch verlagert sich die Herausforderung der Suche in einem Peer-to-

Peer Netzwerk zur Suche nach Personen, die entweder eine spezielle Anfrage be-

antworten k¨

onnen oder an eine Person weiterleiten k¨

onnen, die jemanden kennt,

der unsere Anfrage beantworten kann. Die Suche dieser Personen h¨

angt stark von

unserem vorhandenen Expertennetzwerk ab: den uns bekannten Experten und de-

ren Experten usw. In unserem Ansatz ¨

ubertragen wir das Aufbauen von pers¨

onli-

chen Netzwerken ¨

uber soziale Kontakte und das effiziente Finden von Experten auf

die technische Netzwerkinfrastruktur eines Peer-to-Peer Systems.

4.2 Soziale Netzwerke und das Small World Ph¨

anomen

Das Small World Phenomenon ist ein 1967 gepr¨

agter soziologischer Begriff, der

innerhalb der sozialen Vernetzung in der modernen Gesellschaft den hohen Grad

abk¨

urzender Wege (Shortcuts) durch pers¨

onliche Beziehungen bezeichnet. Es be-

zieht sich auf eine Prognose, nach der jeder Mensch auf der Welt mit jedem anderen

uber eine ¨

uberraschend kurze Kette von Bekanntschaftsbeziehungen verbunden ist.

Dies ist erstaunlicherweise m¨

oglich, obwohl die ’Dichte’ des sozialen Netzwerks

aller Akteure - gemessen als das Verh¨

altnis der realen zu den rechnerisch m¨

ogli-

chen Kontakten der Kontaktpersonen eines jedweden Akteurs - extrem gering ist,

n¨

amlich nahe 0. Der Begriff geht auf den US-amerikanischen Sozialpsychologen

Stanley Milgram [Mil67] zur¨

uck, der in den 1960er Jahren experimentell feststell-

te, dass beliebige Menschen durch eine Kette aus nur wenigen miteinander bekann-

ten Personen verbunden sind. Er gab Versuchspersonen einen Brief an eine ihnen

v¨

ollig unbekannte Zielperson, den sie an einen Bekannten schicken sollten, von

dem sie glaubten, dass er dem Adressaten n¨

aherstehen w¨

urde. Dieser sollte dann

ebenso verfahren, bis der Brief schliesslich sein Ziel erreichte. Milgram ermittel-

te in seinen Experimenten, das solche Ketten durchschnittlich aus 6 Personen (six

degrees of separation) bestehen. Aufbauend auf seinen Versuchen charakterisierte

er Small World Netzwerke durch zwei Eigenschaften:

1. Es existieren kurze Pfade (Shortcuts).

2. Die beteiligten Personen sind erfolgreich im Routen entlang kurzer Pfade.

Bekannte Small World Netzwerke sind zum Beispiel das amerikanische Stromnetz,

nahezu alle Teilmengen von sozialen Netzwerken, eine Submenge der Seiten des

WWW, Zitate und Verweise in wissenschaftlichen Artikel oder auch die Router des

Internet.



4.2. Soziale Netzwerke und das Small World Ph¨

anomen

4.2.1 Charakteristiken von Small World Netzwerken

Die mathematisierte Netzwerkforschung hat im Zuge der Besch¨

aftigung mit Small

World Netzwerken eine Pluralit¨

at von Strukturmustern festgestellt und dabei ihr

besonderes Augenmerk auf sogenannte skalenfreie Netze gelegt. Dabei handelt es

sich um Netzwerke, bei denen einige wenige Knoten (sogenannte hubs) potentiell

unendlich viele Verbindungen aufweisen, w¨

ahrend ein Großteil der ¨

ubrigen Knoten

relativ wenige Beziehungen zu anderen Knoten hat. Um den Begriff des Small

World Netzwerkes genauer zu definieren, verwenden wir die, von [Wat03, Kle00b]

beschriebenen, folgenden f¨

unf Charakteristiken:

1. Kleiner Netzwerkdurchmesser. Der Abstand, gemessen in Hops, zwischen

zwei zuf¨

allig gew¨

ahlten Knoten in einem Graphen ist gering.

Definition 4.2.1 (Durchschnittliche k¨

urzeste Anzahl von Hops). Sei G=

(V, E)ein Graph, bestehend aus Knoten Vund Kanten E, mit denen die

Knoten verbunden sind. Dmin(i, j)repr¨

asentiert die k¨

urzeste Distanz zwi-

schen zwei Knoten iund jmit i, j ∈V. Weiterhin bezeichne Ndie Anzahl

der Knoten in Gmit |V|=N. Der durchschnittliche Netzwerkdurchmesser

in G, bezeichnet als Dia(G)wird definiert als:

Dia(G) = 1

2!X

i6=j

Dmin(i, j)

Dia(G)ist das Verh¨

altnis der Summe aller k¨

urzesten Pfade zwischen belie-

bigen zwei Knoten in Gund allen anderen m¨

oglichen paarweisen Verbindun-

gen in G.♣

2. D¨

unne Vernetzung. Im Vergleich mit einem vollst¨

andig verbundenen Gra-

phen, in dem jeder Knoten mit jedem anderen Knoten ¨

uber eine Kante ver-

bunden ist, verf¨

ugt die Mehrzahl der Peers in Small World Netzwerken nur

uber eine geringe Anzahl von Verbindungen zu anderen Knoten.

3. Power-Law Verteilung. Small World Netzwerke weisen typische Eigen-

schaften eines skalenfreien Netzwerkes auf, die ¨

uber keine typische Anzahl

von Verbindungen pro Knoten verf¨

ugen. Vielmehr ist in Small World Netz-

werken die Anzahl der Verbindungen Power-Law verteilt. Dabei handelt es

sich um Netzwerke, bei denen einige wenige Knoten (sog. hubs) eine beson-

ders hohe Anzahl von Verbindungen aufweisen, w¨

ahrend ein Grossteil der

ubrigen Knoten relativ wenige Beziehungen zu anderen Knoten hat.



4.2. Soziale Netzwerke und das Small World Ph¨

anomen

4. Entstehen von Clustern. In Small World Netzwerken ist die Wahrschein-

lichkeit hoch, dass zwei Knoten, die jeweils eine Kante zu einem dritten

Knoten haben, auch untereinander verbunden sind. In sozialen Netzwerken

sind die Freunde einer Person meistens auch untereinander bekannt, weil sie

sich ¨

uber den gemeinsamen Freund kennengelernt haben (Transitivit¨

atsprin-

zip). Mathematisch wird diese Tatsache ¨

uber den Clustering-Koeffizienten

beschrieben, der f¨

ur Small World-Netzwerke ¨

uberdurchschnittlich hoch ist.

Definition 4.2.2 (Clustering Koeffizient). Sei Ddie Distanz zweier Knoten

u, v ∈V. Die Nachbarschaft eines Knoten vist gegeben als eine Menge von

Knoten Γv={u:D(u, v)=1}. Sei kvdie maximale Anzahl der Links

zu benachbarten Knoten f¨

ur einen Knoten v∈Vund sei Cvder lokale

Clustering Koeffizient von vmit

Cv=|E(Γv)|

kv∗(kv−1)

wobei E(Γv)einen Operator darstellt, der die Anzahl der Links in der Men-

ge von Γvz¨

ahlt. Der Clustering Koeffizient C(G)eines Graphen Gwird defi-

niert als

C(G) = 1

v∈V

Anders ausgedr¨

uckt, C(G)misst die ’Kompaktheit’ des Graphen.

5. Hohe Fehlertoleranz. Die spezielle Vernetzung eines skalenfreien Netzes

macht ein solches Netzwerk robust gegen den Ausfall einiger zuf¨

alliger Kno-

ten oder Kanten. Falls aber stark vernetzte Knoten, sogenannte hubs, gezielt

entfernt werden, zerf¨

allt das Netzwerk schnell in Teilnetze. Dies ist unter an-

derem der Grund, warum der Ausfall nur weniger Router im Internet weit-

reichende Auswirkungen haben kann.

4.2.2 Definition von Shortcuts auf Basis sozialer Metaphern

Motiviert durch die Unzul¨

anglichkeiten strukturierter und unstrukturierter Peer-to-

Peer Ans¨

atze und inspiriert durch die Eigenschaften von Small World Netzwerken

haben wir einen neuen Ansatz f¨

ur das Routing in einem unstrukturierten Netzwerk

entwickelt. Als Analogie zu sozialen Netzwerken setzen wir dazu einen Peer mit

einer Person in einem sozialen Netzwerk gleich. Unser Ansatz basiert vollst¨

andig

auf lokalem Wissen, das ein Peer ¨

uber bereits gestellte Fragen und erzielte Antwor-

ten gewonnen hat. Jeder Peer spezialisiert sich auf einen bestimmten Teilbereich



4.2. Soziale Netzwerke und das Small World Ph¨

anomen

Text

Bootstrapping Overlay

Default Network Layer

Recommender Overlay

Content Provider Overlay

/Top/Computer/UML

? =

Abbildung 4.1: Visualisierung der Indizes an einem Beispiel

von Interessen. Ein Peer speichert nur Wissen ¨

uber andere Peers, die ihn selbst

interessieren. Dieses Wissen wird in Form von Shortcuts lokal gespeichert.

Zur Erstellung der Shortcuts verwenden wir eine Reihe von sozialen Meta-

phern. Aufgrund von Beobachtungen unterscheiden wir vier Typen von Personen

in unserem Netzwerk, an die wir Anfragen richten. In dieser Arbeit verstehen wir

unter eine Anfrage einen Term, der in einer Themen-Hierarchie definiert wurde

(siehe Definition 4.2.3). Ein Beispiel ist die Bildung einer Anfrage nach Dokumen-

ten zur Beschreibungssprache UMLaus dem Term /Top/Computer/UML. Die

folgenden Metaphern k¨

onnen jedoch auch f¨

ur Anfragen, die aus mehreren Termen

bestehen, angewandt werden. Wir definieren die folgenden Metaphern:

1. Eine Anfrage wird an eine Person gestellt, die diese Anfrage in der Vergan-

genheit bereits korrekt beantwortet hat. Wir nennen eine solche Person einen

Content Provider und organisieren die korrespondierenden Peers im Content

Provider Layer.

2. Kennen wir keine Person, die eine ¨

ahnliche Anfrage in der Vergangenheit

beantwortet hat, suchen wir nach Personen, die eine ¨

ahnliche Anfrage in

der Vergangenheit gestellt hat. Wir nehmen an, das diese Person mit hoher

Wahrscheinlichkeit bereits einen Content Provider kennt, der unsere Anfrage



4.2. Soziale Netzwerke und das Small World Ph¨

anomen

beantworten kann. Wir nennen derartige Personen Recommender und orga-

nisieren die korrespondierenden Peers im Recommender Layer.

3. Wenn wir keine Person zur Beantwortung einer Anfrage bereits kennen,

schicken wir die Anfrage zu einer Person, die bereits ein ’breites’ sozia-

les Netzwerk zu anderen Personen entwickelt hat. Solche Personen formen

unser initiales soziales Netzwerk. Die korrespondierenden Peers bilden den

Bootstrapping Layer.

4. Kennen wir immer noch keine Person zur Beantwortung der Anfrage leiten

wir die Anfrage an zuf¨

allig ausgew¨

ahlte Personen weiter. Um auch neue

Personen f¨

ur bereits bekannte Anfragen kennenzulernen, wenden wir diese

Form der Weiterleitung zus¨

atzlich in zuf¨

alligen Abst¨

anden an. Wir nennen

derartige Personen unser Default Network und leiten eine Anfrage an, die

durch die initiale Netzwerk Struktur vorgegebenen Nachbarn weiter.

Die verschiedenen Layer werden durch verschiedene, unabh¨

angige Indizes an ei-

nem Peer lokal repr¨

asentiert. Grafik 4.1 visualisiert den Inhalt der Indizes am Bei-

spiel von Peer 8. Der Peer verf¨

ugt ¨

uber zwei Nachbarn im Default Overlay und

Bootstrapping Overlay, die ¨

uber keine gemeinsame Schnittmenge verf¨

ugen. Der

Index von Peer 8 hat drei Content Provider und vier Recommender Peers identifi-

ziert und in seinem Index lokal gespeichert.

Peers lernen durch ihre Interaktionen andere Peers im Netzwerk kennen. Auf

der Basis der oben geschilderten Annahmen erstellen Peers lokale Shortcuts zu an-

deren Peers. Die Shortcuts aller Peers bilden ein adaptives Overlay Netzwerk, in

dem das Routing erfolgt. F¨

ur eine Anfrage w¨

ahlt ein Peer auf der Basis seines lo-

kalen Wissens die besten Peers f¨

ur die Weiterleitung der Anfrage aus. Wir w¨

ahlen

entweder Peers aus, die eine Anfrage beantworten k¨

onnen, mit hoher Wahrschein-

lichkeit f¨

ur die Anfrage passende Peers kennen, bzw. Peers, die gut vernetzt sind.

Dazu ber¨

ucksichtigen wir die in den sozialen Metaphern implizit vorgegebene Rei-

henfolge. Wir versuchen Peers auszuw¨

ahlen, die eine exakte Antwort auf die An-

frage bereits gegeben haben und w¨

ahlen dann Peers aus, die ¨

ahnliche Anfragen

bereits gestellt haben, bzw besonders gut vernetzt sind oder, letztendlich, durch

Zufall mit unserem Peer benachbart sind.

Im Gegensatz zu den im vergangenen Kapitel beschriebenen Ans¨

atzen ben¨

oti-

gen wir keine Registrierung des Peer-Profile in einem zentralen oder verteilten

Index. Jeder Peer verf¨

ugt ¨

uber die vollst¨

andige Kontrolle der lokalen Daten und

der Weiterleitung von Anfragen. Ein weiterer Vorteil eines Shortcut Netzwerkes

ist die ’egoistische’ Verwaltung der technischen Ressourcen eines Peers. Ein Peer

stellt nur Speicherplatz und Bandbreite zur Verwaltung von Shortcuts zu entfernten

Peers und f¨

ur das Weiterleiten von Anfragen zur Verf¨

ugung, die mit seinen eigenen



4.2. Soziale Netzwerke und das Small World Ph¨

anomen

Interessen ¨

ubereinstimmen. Schliesslich nutzen wir f¨

ur das effiziente Routing der

Anfragen die Small World Charakteristiken des Shortcut-Overlay aus.

4.2.3 Formale Definition von Shortcut Netzwerken

In diesem Abschnitt f¨

uhren wir das Konzept der adaptiven Overlay Netzwerke auf

der Basis von Shortcuts formal ein. Wir modellieren unser System als eine Menge

von NKnoten in dem jeder ni∈Neine Menge von DiDokumenten verwaltet.

Jeder Knoten repr¨

asentiert einen Peer. Dabei kann ein Dokument an mehr als einem

Knoten vorhanden sein. Wir bezeichnen die Menge aller Dokumente als D.

Definition 4.2.3 (Themenhierarchie). Sei Teine Themen-Hierarchie. Jedes se-

mantische Konzept in ihr entspricht einem Thema t∈ T , das durch einen Path

tpath eindeutig definiert wird. ♣

Definition 4.2.4 (Dokument). Jedes Dokument d(t1, ..., ti)∈ D ist mindestens

einem Thema t1, ..., ti∈ T zugeordnet. ♣

Anfragen nach Dokumenten erfolgen durch das Stellen einer Anfrage q(t).

Definition 4.2.5 (Anfrage). Eine Anfrage q(t)enth¨

alt genau ein Thema t, mit t∈

T.♣

Wir modellieren eine ¨

Ubereinstimmung zwischen einer Anfrage q(t)und einem

Dokument d(t1, ..., ti)als eine bin¨

are Funktion M(q(t), d(t1...ti)), deren Resultat

1bei einer ¨

Ubereinstimmung und sonst 0 ist.

Definition 4.2.6 ( ¨

Ubereinstimmung zwischen Dokument und Anfrage).

M(q(t), d(t1...ti)) = (1, wenn t⊆(t1, .., ti)|t, t1, ..., ti∈ T

0, sonst

.♣

Eine Anfrage kann an einem Peer entweder mit keinem, mit einem oder mit meh-

reren passende Dokumenten ¨

ubereinstimmen. Die Anzahl der ¨

Ubereinstimmungen

an einem Peer f¨

ur eine Anfrage bezeichnen wir als Query Hits.

Definition 4.2.7 (Query Hits und erfolgreiche Anfrage). Wir definieren die An-

zahl der Treffer (hits) an einem Knoten nif¨

ur eine Anfrage qals

H(q(t), ni) = X

d∈Di

M(q(t), di)

und bezeichnen alle Anfragen, die mit mindestens einem Dokument an einem Peer

ubereinstimmen, als erfolgreiche Anfrage. ♣



4.2. Soziale Netzwerke und das Small World Ph¨

anomen

Unstrukturierte Peer-to-Peer Netzwerke, wie Gnutella, erzeugen ein einzelnes Over-

lay Netzwerk. In diesen ist ein Peer mit einigen anderen Peers, seinen Nachbarn,

uber zuf¨

allig gew¨

ahlte Shortcuts verbunden, die wiederum ¨

uber Shortcuts mit an-

deren Nachbarn verbunden sind.

Definition 4.2.8 (Shortcut). Wir bezeichnen einen Shortcut als einen Triple

(ni, nj, l, type)in dem niund njunidirectional miteinander verbundene Peers, l

eine Zeichenkette (String) und type den Typ des Overlays repr¨

asentiert. ♣

Jeder Peer verf¨

ugt neben den zuf¨

alligen gew¨

ahlten Shortcuts des Default Over-

lay Netzwerkes ¨

uber weitere, entsprechend den sozialen Metaphern ausgew¨

ahlte,

Shortcuts f¨

ur drei weitere Typen von Overlay Netzwerken: Content Provider, Re-

commender und Bootstrapping Overlay. F¨

ur jeden Typ definieren wir folgende Se-

mantiken f¨

ur lund type:

Definition 4.2.9 (Content, Recommender, Bootstrapping und Default Overlay).

Wir definieren eine Menge von Peers na, ..., nz, die Dokumente f¨

ur ein Thema tpu-

blizieren und die dem Knoten nibekannt sind, als einen Content Provider Overlay

f¨

ur das Thema tmit l=tsowie type =co und schreiben COt

ni.

Beispiel:

CO/T op/Computer/UML

8={3,4,9}

Wir definieren eine Menge von Knoten na, ..., nz, die Anfragen f¨

ur das Thema tge-

stellt haben und die dem Knoten nibekannt sind, als einen Recommender Overlay

f¨

ur das Thema tmit l=tsowie type =ro und schreiben ROt

ni.

Beispiel:

RO/T op/Computer/UML

8={1,6,9,10}

Wir definieren eine Menge von Knoten na, ..., nz, die besonders gut vernetzt und

dem Knoten nibekannt sind, als einen Bootstrapping Overlay mit l=null sowie

type =bo und schreiben BOni.

Beispiel:

BO8={1,6,10}

Wir definieren eine Menge von Knoten na, ..., nz, die mit niin der initialen Netz-

werk Struktur miteinander verbunden sind, als Default Network Overlay mit l=

null sowie type =do und schreiben DOni.

Beispiel:

DO8={1,7}

Grafik 4.1 zeigt die verschiedenen Overlays am Beispiel f¨

ur Peer acht und dem

Thema /Top/Computer/UML.



4.3. INGA Systemarchitektur

Definition 4.2.10 (Adaptives Overlay Netzwerk auf der Basis von Shortcuts).

Alle Shortcuts mit demselben Label lbilden ein gemeinsames Adaptives Overlay

Netzwerk ONl. Gegeben zwei Peers ni,njmit ni6=nj, definieren wir ONlals

ONl={(ni, nj)∈N×N∧ |∃ a Shortcut (ni, nj, l, type)}

Jedes ONlunterst¨

utzt drei Funktionen:

1. Create(nj,l,type), bei dem ein Peer njeinen Shortcut der Form

(ni, nj, l, type)|ni, nj∈ONlzu einem entfernten Peer njerzeugt.

2. Search(q(l)) bei der durch eine Anfrage q(l)eine Teilmenge von Content

Provider Peers aus ONlzur¨

uckgegeben wird, die q(l)beantworten k¨

onnen.

3. Delete(nj,l,type) in der ein Peer einen Shortcut zum Peer njf¨

ur den Type

type und f¨

ur das Netzwerk ONll¨

oscht . ♣

Die Implementation dieser Funktionen wird in Kapitel 5 und 6 vorgestellt.

4.3 INGA Systemarchitektur

Die INGA Infrastruktur bietet typische Peer-to-Peer Funktionalit¨

at, wie das Publi-

zieren und Suchen von Dokumenten, an. Sie unterscheidet sich jedoch von anderen

Peer-to-Peer Systemen dadurch, dass Peers miteinander kooperieren und Informa-

tionen f¨

ur das Weiterleiten von Anfragen austauschen. Jeder Peer speichert Short-

cuts in Form von Tupeln Themen ×Peers. Dabei speichert jeder Peer ’egoistisch’

nur Shortcuts zu anderen Peers, die den Peer selbst interessieren. Um Antworten

auf Anfragen zu erhalten, ’sozialisiert’ sich der Peer mit anderen Peers. Er durch-

sucht deren Shortcut Index und gewinnt neue Shortcuts. Unser Ansatz verwendet

das Peer-to-Peer Paradigma einerseits f¨

ur den Austausch von Dokumenten und an-

dererseits f¨

ur den Austausch von Shortcut zwischen den Peers. Im Folgenden stel-

len wir die Komponenten unserer Infrastruktur vor und erl¨

autern ihre Funktion und

Aufgabe. Grafik 4.2 gibt einen ¨

Uberblick ¨

uber einen Peer in der INGA Infrastruk-

tur.

4.3.1 Netzwerk Management

Als Basisinfrastruktur verwenden wir das JXTA Netzwerk [Gon01, TAA+03]. Das

Open Source Project geh¨

ort zu den f¨

uhrenden Industrieplattformen f¨

ur Peer-to-Peer

Technologie. Es wurde urspr¨

unglich von SUN Microsystems initiiert und wird von

einer breiten Gemeinschaft akademischer und industrieller Nutzer weiterentwickelt



4.3. INGA Systemarchitektur

INGA Peer

Local

Content

Database

Local

Shortcut

Index

Shortcut

Management

Content

Management

Network Management

Query / Result Interface

Peer 2

Peer 4

Peer 3

Routing

Logic

Abbildung 4.2: Architektur eines INGA Peers

und verbessert. Aktuelle JXTA Projekte [Tra04] erfolgen zum Beispiel im Bereich

der Navigationsdaten der US Coast Guard, der Suche in verteilte Immobiliendaten

National Association of Realtors of America und der Suche in verteilten Lernobjekt

Repositories mit Edutella [NWS+03].

Unser Ansatz ist auch auf andere Infrastrukturen ¨

ubertragbar, sofern diese min-

destens die folgenden zwei Funktionen zur Verf¨

ugung stellen:

•Austausch von Nachrichten mit anderen Peers. Nachrichten sind die Basis-

Einheit in der Peers Daten austauschen. Wir nehmen an, das jeder Peer eine

konkrete Implementierung dazu aufweist. Das JXTA Netzwerk erlaubt den

Austausch von Nachrichten mit anderen Peers unabh¨

angig von ihrer Position

im Netzwerk (Firewall, NAT). Dazu werden entweder das TCP/IP oder das

HTTP Protokoll benutzt.

•Eindeutige Identifikation eines Peers. Jeder Peer im Netzwerk muss ¨

uber

einen eindeutigen Schl¨

ussel identifiziert werden. Im einfachsten Fall ist das

die IP Adresse des Peers. Weitere Verfahren, beispielsweise f¨

ur das JXTA

Netzwerk und Gnutella, werden in Abschnitt 2.1 beschrieben.



4.3. INGA Systemarchitektur

odp:Topic

odp:ExtermalPage

rdfs:Class

Peer1:

/pub/uml_intro.ppt

odp:/Top/

rdf:type

odp:/Top/Computer/UML

rdf:type

odp:/Top/Computer

rdf:type

odp:narrow

odp:instanceOf

UML

dc:title

Computer

Top

dc:title

UML

Tutorial

dc:title

jxtaUrn:Peer1/pub/

uml_intro.ppt

dc:identifier

Peer1

dc:source

Abbildung 4.3: INGA Datenmodel und Beispiel

4.3.2 Lokales Dokumenten Repository

Analog zu File Sharing Netzwerken kann jeder Peer ausgew¨

ahlte Dateien anderen

Peers zur Verf¨

ugung stellen. Dateien, die bereits von einem anderen Peer geladen

wurden, k¨

onnen ebenfalls publiziert werden. Wir beschreiben zuerst das Datenmo-

dell und sp¨

ater die Aufgaben der Komponente:

Datenmodell zur Publikation von Dateien. Informationen zu Dateien werden

syntaktisch in Form von RDF Metadaten dargestellt. In diesem und den fol-

genden Kapiteln nehmen wir an, dass jede Datei mindestens in einer Themen-

Hierarchie klassifiziert ist und mit Metadaten annotiert ist. Semantisch wer-

den die Metadaten durch das existierende RDF(S) Datenmodell [BG03, LS99],

den Dublin Core Standard [Ini04] und das Datenmodel des Open Directory

beschrieben [BG03]. Im Beispiel in Grafik 4.3 publiziert ein Peer eine Da-

tei zum Thema UML Tutorials. Jede Ressource von Typ odp:ExternalPage,

also eine lokale Datei an einem Peer, stellt eine konkrete Instanz f¨

ur eine Re-

source von Typ odp:topic, also ein Thema aus der ODP Themen-Hierarchie,

dar. Einzelne Themen stehen semantisch untereinander in einer Spezialisie-

rungsbeziehung, die durch die Relation odp:narrow ausgedr¨

uckt wird.

Publizieren von Dateien und Metadaten. Jeder Peer hat die M¨

oglichkeit, Infor-



4.3. INGA Systemarchitektur

mationen ¨

uber Dateien zu publizieren, die er anderen Peers zur Verf¨

ugung

stellen m¨

ochte. Dazu ver¨

offentlicht der Peer lokal Metadaten ¨

uber seine vor-

handenen Dateien. In dieser Arbeit wurde die Implementierung auf der Basis

des Sesame RDF Repositories [BKvH02] durchgef¨

uhrt.

Anfragen formulieren und Resultate zur¨

uckgeben. Jeder Peer verf¨

ugt ¨

uber

eine Schnittstelle zur Formulierung von Anfragen. Zur technischen Rea-

lisierung wurde in der Arbeit die im Sesame verf¨

ugbare SeRQL Sprache

[BKvH02] f¨

ur die Formulierung von Anfragen verwendet.

Beispiel 4.3.1 (SeRQL Anfrage). Die folgende Anfrage sucht nach eindeu-

tigen Schl¨

usseln f¨

ur alle Dateien mit dem Thema UML:

SELECT {dc:identifier}

FROM {odp:externalPage}

<odp:instanceOf> {<odp:/Top/Computer/UML>}

using namespace

odp = <!http://dmoz.org/rdf#>,

dc = <!http://purl.org/dc/elements/1.0#>

∗

4.3.3 Management und Auswahl von Shortcuts

Im Gegensatz zu aktuellen Filesharing Netzwerken, wie Gnutella oder Kazaa, sam-

melt jeder INGA Peer ’Wissen’ ¨

uber die publizierten Dateien anderer Peers im

Netzwerk. Dieses Wissen speichert der Peer in einem lokalem Shortcut Index. Auf

dessen Basis trifft der Peer die Entscheidung, an welche anderen Peer eine An-

frage weitergeleitet werden soll. Die Verwaltung des Index erfolgt in der Shortcut

Management Component. Ihre Aufgaben sind:

Erstellen und L¨

oschen von Shortcuts. Aus erfolgreichen Anfragen werden In-

formationen ¨

uber den antwortenden Peer und Peers die die Anfrage weiter-

geleitet haben, im Shortcut Index gespeichert. Kann der Index keine wei-

teren Shortcuts mehr aufnehmen, werden durch eine Index-Policy Eintr¨

age

aus dem Index entfernt, bzw. ausgetauscht. In Kapitel 5 und 6 diskutieren

wir Verfahren zur Erstellung und zum L¨

oschen von Shortcuts.

Auswahl der besten Peers f¨

ur eine Anfrage. F¨

ur eine Anfrage, entweder eines

entfernten oder des lokalen Peers, werden lokal die besten Peers ausgew¨

ahlt,

an die eine Anfrage weitergeleitet wird. Die Auswahl der Peers basiert auf

dem Wissen ¨

uber andere Peers, deren Performance in der Vergangenheit und

der ¨

Ahnlichkeit des Themas der Anfrage zu bereits gespeicherten Shortcuts.



4.3. INGA Systemarchitektur

In Abschnitt 6.2 stellen wir verschiedene Strategien f¨

ur die Auswahl der be-

sten Peers auf der Basis lokalen Wissens vor.

4.3.4 Format der Anfrage- und Resultatnachrichten

Peers tauschen Nachrichten in Form von Anfragenachrichten (Query Messages)

und Resultatnachrichten (Result Messages) miteinander aus. Um schneller Infor-

mationen ¨

uber andere Peers zu sammeln, werden bestimmte zus¨

atzliche Informa-

tionen in den Nachrichten von den Peers beim Empfang ausgewertet. In diesem

Abschnitt beschreiben wir das Format der Anfrage- und Resultat Nachrichten.

Anfrage und Resultatnachrichten beinhalten immer den transitiven Pfad, den

die Anfrage, beginnend vom anfragenden Peer, bereits zur¨

uckgelegt hat. Wir be-

zeichnen ihn als Message Pfad und benutzen ihn, um Informationen zum Aufbau

von Shortcuts zu gewinnen.

Definition 4.3.1 (Message Path). Sei Pquery ein anfragender Peer und Pa, ..., Pz

eine Liste von Peers, die den transitiven Weg der Anfrage beschreiben. Wir definie-

ren den Message Path als Liste MP mit

MP = (Pquery, Pa, ..., Pz)

Kann ein Peer Panswer auf eine Anfrage antworten definieren wir den Message

Path als Liste MPanswer mit

MPanswer = (Pquery, Pa, ..., Pz, Panswer)

.♣

Jede Anfrage eines Peers wird in Form einer Query Message an andere Peers wei-

tergeleitet.

Definition 4.3.2 (Query Message). Sei

•q(t)—t∈ T die Anfrage

•QID ein f¨

ur die Anfrage eindeutiger Schl¨

ussel

•MP der transitive Weg der Anfrage

•BC ein ganzzahliger positiver Wert, der die Bootstrapping Capability von

Pquery beschreibt (siehe Definition 5.3.3)

•maxHops die maximale L¨

ange Anzahl der Hops, die die Anfrage zur¨

ucklegen

darf



4.3. INGA Systemarchitektur

dann definieren wir eine Query Message als ein Quintuple

MQuery = (q(t), QID, MP, BC, maxHops)

.♣

Anmerkung: Das Modell einer Anfrage eines INGA Peers ist angelehnt an das

Modell von Gnutella [Kan99]. Analog zu Gnutella und zur Vermeidung des Sen-

dens der Nachricht an Peers, die eine Anfrage bereits erhalten haben, beinhaltet

die Nachricht die PeerIDs aller Peers, die die Nachricht bereits erhalten haben. Sie

sind im Message Path, beginnend mit dem anfragenden Peer, geordnet. Weiterhin

enth¨

alt jede Anfrage einen eindeutigen Schl¨

ussel, die QID. Wir vermeiden damit,

dass ein Peer mehrmals auf die gleiche Anfrage antwortet und damit die Anzahl

der Nachrichten im Netzwerk erh¨

oht. Eindeutige Schl¨

ussel f¨

ur Anfragen werden

in JXTA durch einen speziellen Zufallsgenerator erzeugt. Die Variable BC bein-

haltet Informationen ¨

uber den Grad der Vernetzung des anfragenden Peers, deren

Berechnung in Definition 5.3.3 vorgestellt wird. Peers die eine Anfrage erhalten,

lernen dadurch schnell andere Peers kennen, die eine hohen Grad der Vernetzung

aufweisen.

Das Resultat auf eine erfolgreiche Anfrage wird in einer Result Message ¨

ubert-

ragen.

Definition 4.3.3 (Result Message). Sei

•q(t)mit t∈ T die Anfrage

•MPanswer der transitive Weg der Anfrage, inklusive dem antwortendem Peer

• H(q(t), Panswer)die Query Hits der Dokumente an dem antwortenden Peer

die zu der Anfrage passen

dann definieren wir eine Result Message als ein Triple

MResult = (q(t), MPanswer,H(q, Panswer))

.♣

Anmerkung: Im Gegensatz zum Gnutella-Protokoll sendet ein Peer eine Antwort

direkt an den anfragenden Peer zur¨

uck. Dessen PID wird aus dem Message Path

ermittelt .



4.4. Verwandte Arbeiten

4.4 Verwandte Arbeiten

Die Auswahl von Experten f¨

ur eine Anfrage innerhalb einer Organisation und die

Suche nach dem passenden Peer f¨

ur eine Anfrage sind eng verwandte Fragestel-

lungen. Wir unterscheiden verwandte Arbeiten innerhalb der Suche in Peer-to-Peer

Netzwerken, auf dem Gebiet der verteilten Desktop Suche und Arbeiten zur Loka-

lisierung von Experten.

Der Gnutella Ansatz [Gnu04] leitet eine Anfrage ungerichtet an eine grosse

Anzahl von Peers. Typischerweise kann ein Grossteil der erreichten Peers die An-

frage nicht beantworten, wodurch das Netzwerk mit vielen unn¨

otigen Nachrichten

belastet wird. Zur Vermeidung einer ¨

Uberflutung des Netzwerkes mit Nachrichten

wurden die Systeme Edutella in Abschnitt 3.1 und TOPICS in Abschnitt 3.2 vor-

gestellt. Diese Systeme verwenden einen globalen, verteilten Index auf der Basis

eines strukturierten Peer-to-Peer Overlays. Durch die technisch bedingte Vertei-

lung der Eintr¨

age im Index entsteht jedoch zus¨

atzlicher Aufwand f¨

ur die Lastver-

teilung, Replikation und Aktualisierung des Index. ¨

Ahnlich Gnutella basiert der

INGA Ansatz auf einem unstrukturierten Peer-to-Peer Overlay. Im Gegensatz zu

beiden Ans¨

atzen verf¨

ugt er ¨

uber einen adaptiven Overlay auf der Basis der Inter-

essen der Peers und kombiniert geringe Verwaltungskosten eines unstrukturierten

Netzwerkes mit der gerichteten Suche in einem Overlay Netzwerk. Peers, die durch

ihre Interessen miteinander in Beziehung stehen, werden durch Shortcuts dyna-

misch miteinander verbunden. Eine Anfrage wird entlang des Shortcut Overlays an

die lokal bekannten besten Peers geleitet. Ein ¨

ahnlicher Ansatz wird in [CGM02b]

vorgestellt, Die Autoren verwenden ein semantisches Overlay Netzwerk, in dem

Dokumente Kategorien zugeordnet werden. Es bleibt jedoch offen, wie der Index

gebildet wird und wie die Peers den Index verwalten.

Das Problem der Desktop Suche wird h¨

aufig in Zusammenhang mit einer In-

frastruktur f¨

ur die kollaborative Zusammenarbeit in Gruppen betrachtet. [DF04]

gibt mit dem Networked Semantic Desktop eine Vision des vernetzten Desktops

wieder. Eine Implementation der lokalen, jedoch nicht verteilten, Desktops Su-

che, erfolgte in Gnowsis [Sau03]. YouServ [AGS02] erm¨

oglichen eine einfache

und kosteng¨

unstige Publikation lokal gespeicherter Dokumente ¨

uber einen zentra-

len Index. Groove Networks erlaubt eine kollaborative Arbeitsumgebung und den

Austausch von Dokumenten f¨

ur kleine Arbeitsgruppen durch einen vollst¨

andig re-

plizierten Index.

MINDS und ReferralWeb sind zwei grundlegende Ans¨

atze f¨

ur Referral Sy-

stems. In diesen Systemen leiten Agtenten eingehende Anfragen an Nutzer mit

den passenden Profil weiter. ¨

Ahnlich den Shortcuts verf¨

ugt jeder Agent ¨

uber ein

eigenes Netz von Referrals, ¨

uber das die Anfragen weitergeleitet werden. MINDS

[HMSB87] stellt Heuristiken f¨

ur das Erlernen und die Erstellung von Referrals



4.5. Zusammenfassung

vor, w¨

ahrend ReferralWeb [KSS97] sich auf das Finden geeigneter Startknoten im

Netzwerk konzentriert. Beide Systeme verwenden als Basis die sozialen Netzwer-

ke der zu den Agenten korrespondierenden Nutzer. Im Gegensatz zu unserem An-

satz verwenden die Systeme nur das Prinzip der erfolgreichen Antworten, ber¨

uck-

sichtigen auch keine Anfragen oder eine besonders gute Vernetzung der einzelnen

Nutzer. Ein weiterer wichtiger Unterschied liegt in dem zentralen Index, der die Pu-

blikation der Profile der einzelnen Nutzer und deren regelm¨

assige Aktualisierung

erfordert.

4.5 Zusammenfassung

In diesem Kapitel wurde die Idee adaptiver Overlay Netzwerke, ihre Terminologie

und die Systemarchitektur vorgestellt. Peers erstellen und verwalten Shortcuts zu

anderen Peers in lokalen Indizes auf der Basis sozialer Metaphern und leiten An-

fragen entlang des Shortcut Netzwerkes weiter. Unser Ansatz erweitert die grund-

legende Architektur eines Peers in einem unstrukturierten Netzwerk um weitere

Komponenten, wie das Management von Shortcuts und die Auswahl von Shortcuts

f¨

ur eine Anfrage.

Der Ansatz unterscheidet sich von strukturierten Netzwerken durch den fehlen-

den globalen Index und erlaubt eine vollst¨

andig lokale Kontrolle des Profils eines

Peers. Weitere Kosten, zum Beispiel f¨

ur den Lastausgleich und die Pflege eines

globalen Index fallen nicht an. Die Erstellung des Overlay Netzwerkes erfolgt im-

plizit durch Beobachtung der Aktionen eines Nutzers und erfordert keine weitere

manuelle Pflege durch den Nutzer.



Erzeugung von Shortcuts

Nachdem im letzten Kapitel die grundlegende Idee des INGA Ansatzes vorge-

stellt wurde, beschreiben wir in diesem Kapitel die Erstellung von Shortcuts. Zur

Einf¨

uhrung klassifizieren wir die von uns identifizierten Typen von Shortcuts. Da-

nach stellen wir neu entwickelten Strategien und Technologien f¨

ur das schnelle

Erlernen von anfrageabh¨

angigen und anfrageunabh¨

angigen Shortcuts vor.

5.1 Merkmale von Shortcuts

In diesem Abschnitt definieren wir Merkmale zur Klassifikation von Shortcuts. An-

hand dieser Merkmale identifizieren wir sechs Klassen von Shortcuts, die zus¨

atz-

liche Kanten zwischen ausgew¨

ahlten Peers erzeugen und dadurch unterschiedliche

Overlays ¨

uber der initialen Netzwerk Struktur bilden. Folgende Eigenschaften wur-

den von uns in die Klassifikation (siehe Grafik 5.1) ¨

ubertragen:

Bi/Uni-direktionale Shortcuts. Bi-direktionale Shortcuts erfordern neben einer

initialen Best¨

atigung auch eine laufende Aktualisierung durch beide Peers.

Dieser Vorgang basiert nicht mehr nur auf dem alleinigen lokalen Wissen

eines Peers, sondern erfordert den Austausch von Informationen zwischen

den beteiligten Peers. Dadurch entstehen zus¨

atzliche Nachrichten im Netz-

werk. Uni-direktionale Verbindungen werden in der technologischen Basis-

Infrastruktur dieser Arbeit, dem JXTA Netzwerk und in Gnutella oder dem

HTTP Protokoll, angewendet. Shortcuts, die auf der Basis dieses einfaches



5.1. Merkmale von Shortcuts

Modells erzeugt werden, erm¨

oglichen einem Peer eine Entscheidung nur

auf der Basis seines eigenen lokalen Wissens, ob ein Shortcut erstellt oder

gel¨

oscht wird. Aufgrund der Einfachheit des Modells und seiner (Entscheidungs)-

Autonomie unabh¨

angig von anderen Peers im Netzwerk betrachten wir in

dieser Arbeit nur uni-direktionale Shortcuts.

In/Out-Bound Shortcuts. Peers, die dem Netzwerk neu beigetreten sind, kennen

noch keine anderen Peers im Netzwerk. Eine Kernaufgabe des Shortcut Ma-

nagements ist die implizite Erstellung m¨

oglichst vieler und relevanter Short-

cuts innerhalb kurzer Zeit. Dazu ber¨

ucksichtigen wir sowohl Strategien f¨

die Erstellung Out-Bound uni-direktionaler Shortcuts und In-Bound uni-di-

rektionaler Shortcuts.

Auf der Basis der in Abschnitt 4.2.2 definierten sozialen Metaphern ver-

wenden wir Outbound uni-direktionale Verbindungen zur Erstellung von

Shortcuts, die durch den Sender einer Anfrage ohne Best¨

atigung durch den

Empf¨

anger erstellt werden. Beispiele daf¨

ur sind Shortcuts, die auf der Basis

gefundener Antworten zu einer Anfrage ermittelt werden (Content Provider

Shortcuts), Shortcuts, die auf der Basis der durch den eigenen Peer gestellten

und von einem anderem Peer erfolgreich weitergeleiteten Anfrage erzeugt

werden (aktive Recommender Shortcuts) und Shortcuts, die wir initial und

zuf¨

allig zu anderen Peers im Netzwerk aufbauen (Default Network Short-

cuts).

Inbound uni-direktionale Verbindungen verwenden wir zu Erstellung von

Shortcuts, die durch den Empf¨

anger einer Anfrage gebildet werden. Bei-

spiele daf¨

ur sind Shortcuts zu Peers, die eine Anfrage stellen, die uns selbst

interessiert (passive Recommender Shortcuts) oder Shortcuts zu Peers, die

uns in ihrer Anfrage mitteilen, wie gut sie im Netzwerk mit anderen Peers

vernetzt sind (Bootstrapping Shortcuts).

Query/Non-Query Dependent Shortcuts. Um eine Anfrage m¨

oglichst nicht ko-

stenintensiv ¨

uber das Netzwerk fluten zu m¨

ussen, unterscheiden wir zwi-

schen Shortcuts, die einem bestimmten Thema (siehe Definition 4.2.3) zu-

geordnet sind und Shortcuts, die nicht diese Eigenschaft aufweisen. Da-

mit ber¨

ucksichtigen wir einerseits Anfragen, die themenspezifisch entlang

von Content Provider oder Recommender Shortcuts weitergeleitet werden

k¨

onnen. Andererseits unterst¨

utzen wir auch Anfragen, f¨

ur die noch keine

thematisch passenden Peers identifiziert wurden. Diese werden entlang von

Bootstrapping Shortcuts zur Peers weitergeleitet, die bereits gut vernetzt

sind.



5.2. Anfrageabh¨

angige Shortcuts

Uni-directional

Bi-directional

In-Bound

Out-Bound

Passive

Recommender

Bootstrapping

Content Provider

Default Network

(JXTA)

Active

Recomender

Default Network

(Gnutella 2)

Query Dependent

Non-Query Dependent

Abbildung 5.1: Klassifikation von Shortcuts

5.2 Anfrageabh¨

angige Shortcuts

In diesem Abschnitt beschreiben wir, wie die Shortcut Management Komponente

die Erstellung zweier neuer Typen von Shortcuts, Content Provider Shortcuts und

Recommender Peer Shortcuts, durchf¨

uhrt. Derartige anfrageabh¨

angige Shortcuts

sind genau einem Thema und einem Peer zugeordnet. Wir stellen Einflussgr¨

ossen

und Beispiele f¨

ur ihre Erstellung vor, definieren die Form des jeweiligen Shortcut

Index und pr¨

asentieren Verfahren f¨

ur dessen Aktualisierung.

5.2.1 Content Provider Layer

Einflussgr¨

ossen. Das Design des Content Provider Shortcut Overlay wurde durch

k¨

urzlich ver¨

offentlichte Arbeiten von [SMZ03] [TSW04] [Coo04] inspiriert und

basiert auf dem einfachen, jedoch leistungsf¨

ahigen Prinzip der Interest-based Lo-

cality.

Definition 5.2.1 (Interest-based Locality f¨

ur Content Provider Peers). Kann ein

Content Provider Peer eine oder mehrere Anfragen eines Peers erfolgreich beant-

worten, so ist es wahrscheinlich, das der Content Provider ¨

uber weitere, f¨

ur den

anfragenden Peer interessante, Dokumente verf¨

ugt. ♣

Wir bewerten die F¨

ahigkeit eines entfernten Peers, passende Dokumente f¨

ur unsere

Anfrage zur Verf¨

ugung zu stellen. Der Peer f¨

ugt seinem lokalem Index f¨

ur jede er-



5.2. Anfrageabh¨

angige Shortcuts

Route by

Flooding

Create

Shortcut

?=/Education/UML, TTL = 3

(a) Fluten und Antworten

Route by

Flooding

Create

Shortcut

(b) Erstellung

Abbildung 5.2: Content Provider Shortcut Erstellung

folgreiche Antwort Content Provider Shortcuts zu. Dieser Prozess erfolgt solange,

bis der Index vollst¨

andig belegt ist, andernfalls werden existierende Shortcuts mit

neu gefundenen Shortcuts ausgetauscht.

Erstellung. Wenn ein neuer Peer dem Netzwerk beitritt, verf¨

ugt er noch ¨

uber

keine Informationen ¨

uber die Interessen anderer Peers. Durch das Stellen von An-

fragen ¨

uber den Default Network Overlay im INGA Netzwerk durch Fluten, ver-

sucht der Peer entfernte Peers f¨

ur die Beantwortung der Anfrage zu finden. Eine

erfolgreiche Anfrage ermittelt eine Menge von Peers, die potentielle Kandidaten

f¨

ur einen Eintrag im Content Provider Shortcut Index des anfragenden Peer dar-

stellen. Wir definieren einen Eintrag f¨

ur einen Content Provider Shortcut im Index

als:

Definition 5.2.2 (Content Provider Shortcut Index). Sei niein anfragender Kno-

ten, q(t)eine Anfrage mit t∈ T ,njein antwortender Knoten, cdie Kennung f¨

Content Provider Shortcuts und ut die Zeit der Erstellung des Shortcuts, dann de-

finieren wir die Struktur eines Eintrags im Content Provider Shortcut Index von ni

als einen Tuple

coni= (t, nj,H(q(t), nj), c, ut)|coni∈ COni

.♣

Beispiel 5.2.1 (Erstellung eines Content Provider Shortcut). Grafik 5.2 zeigt die

Erstellung von Content Provider Shortcuts am Beispiel von Peer 2. Zuerst flutet

der Peer das Netzwerk mit einer Anfrage zum Thema /Education/UML und



5.2. Anfrageabh¨

angige Shortcuts

einer TTL von drei Hops. Peer 2 erh¨

alt Antworten von Peer 3 und 5 (siehe Gra-

fik 5.2(a)). In einem zweiten Schritt f¨

ugt Peer 2 seinem lokalen Index f¨

ur Content

Provider Shortcuts zwei neue Eintr¨

age hinzu. Grafik 5.1 zeigt die Index Struktur

in tabellarischer Form. Entsprechend Definition 5.2.2 enth¨

alt der Index das Thema

der Anfrage, die PID des antwortenden Peers, die Anzahl der Ergebnisse f¨

ur die

Anfrage, den Typ des Shortcuts und den Zeitpunkt der Erstellung. Im Beispiel hat

Peer drei 23 ¨

Ubereinstimmungen f¨

ur die Anfrage erzielt und wurde am 21. April

2005 um 10:38:56 erstellt. . ∗

Shortcut φPID Query Hits Type Update

/Education/UML 3 23 c 210405103856

/Education/UML 5 20 c 210405103856

Tabelle 5.1: Index f¨

ur Peer 2 mit Content Shortcuts

Nachfolgende Anfragen werden mit den bereits bekannten Themen und korrespon-

dierenden Peers im Index verglichen. Die Anfragen k¨

onnen einerseits vom lokalen

Peer selbst stammen, in diesem Fall w¨

urde der Peer eine Anfrage mehrfach stel-

len. Viel h¨

aufiger tritt der Fall auf, das ein entfernter Peer eine Anfrage mit dem

selben Thema stellt. Wird die Anfrage des entfernte Peer zum Index des eigenen

lokalen Peer weitergeleitet, profitiert der entfernte Peer vom bereits gesammel-

ten ’Wissen’ des eigenen lokalen Peers. Wenn ein Peer kein passendes Thema

f¨

ur die Anfrage in einem Content Provider Index findet, wird f¨

ur die Anfrage ein

Peer auf der Basis anderer lokaler Indizes f¨

ur Overlays ausgew¨

ahlt, beispielsweise

des Recommender-, Bootstrapping- oder des Default Network Overlays. Geeignete

Auswahl- und Routingverfahren stellen wir in Abschnitt 6.2 vor.

5.2.2 Recommender Layer

Einflussgr¨

ossen. Typischerweise werden einige Peers besonders erfolgreich im

Finden geeigneter Content Provider sein. Durch eine hohe Anzahl von Anfragen

zu einem Thema kann ein entfernter Peer ein Spezialwissen ¨

uber passende Con-

tent Provider aufbauen. Ein anfragender Peer ist besonders an einem solchem Peer

interessiert, wenn beide eine hohe ¨

Uberdeckung in ihren Anfragen aufweisen, sie

sich also beide f¨

ur die selben Themen interessieren.

Definition 5.2.3 (Interest-based Locality f¨

ur Recommender Peers). Wenn ein ent-

fernter Peer ¨

uber passende Content Provider Shortcuts f¨

ur eine Anfrage eines loka-

len Peers verf¨

ugt, ist es wahrscheinlich, das der entfernte Peer auch ¨

uber passende

Content Provider Shortcuts f¨

ur nachfolgende Anfragen verf¨

ugt bzw. Anfragen mit

ahnlichen Themen stellt. ♣



5.2. Anfrageabh¨

angige Shortcuts

Ahnlich Content Provider Shortcuts repr¨

asentieren Recommender Shortcuts zus¨

atz-

liche Kanten in einem Overlay Netzwerk. Wir bewerten jedoch f¨

ur Recommender

Peers nicht die Anzahl der bereits an einem entfernten Peer gespeicherten Doku-

mente, sondern die F¨

ahigkeit des Recommender Peers die ’richtigen’ Anfragen zu

stellen und Shortcuts mit f¨

ur uns relevanten Themen zu anderen Peers im Netzwerk

aufzubauen. Wird f¨

ur eine Anfrage an einem Peer kein geeigneter Content Provi-

der Shortcut gefunden, so wird versucht, f¨

ur die Anfrage die ’besten’ Recommen-

der Shortcuts auszuw¨

ahlen. Recommender Shortcuts sollen die Wahrscheinlich-

keit erh¨

ohen, das f¨

ur eine Anfrage mit m¨

oglichst wenig Nachrichten die passenden

Peers gefunden werden. Strategien zur Erstellung von Recommender Shortcuts er-

folgen aktiv oder passiv:

Aktive Erstellung durch eigene Anfragen. Eine aktive Erstellung eines Recom-

mender Peers erfolgt durch aktives Senden und Auswerten einer erfolgreichen An-

frage durch den eigenen Peer. Der Sender der Anfrage extrahiert aus dem Message

Pfad der Result Message (siehe Definition 4.3.3) den vorletzten Peer. Dieser Peer

hat die Anfrage unmittelbar zum Content Provider weitergeleitet.

Definition 5.2.4 (Recommender Peer Shortcut Index (aktiv)). Sei niein anfra-

gender Knoten, q(t)eine Anfrage mit t∈ T ,nkder vorletzte Knoten im Message

Pfad der Result Message, H(q(t), nj)die durch den Shortcut erzielten Query Hits,

rf¨

ur den Typ Recommender Shortcut und ut den Zeitpunkt seiner Erstellung, dann

definieren wir die Struktur eines Eintrags im Recommender Index von nials einen

Tuple

roni= (t, nk,H(q(t), nj), r, ut)|roni∈ ROni

.♣

Beispiel 5.2.2 (Aktive Erstellung von Recommender Shortcuts). Grafik 5.3(a)

zeigt die aktive Erstellung von Recommender Shortcuts am Beispiel von Peer 2.

Basierend auf dem Fluten des Netzwerkes zur Identifikation von Content Provider

Shortcuts identifiziert Peer 2 ¨

uber den Pfad der Result Message, das Peer 4 und

Peer 6 die Nachricht zu einem Content Provider Peer weitergeleitet haben. Zu die-

sen Peers erstellt Peer 2 jeweils einen Recommender Shortcut (Grafik 5.3(b) und

Tabelle 5.2).

Passive Erstellung durch gezieltes ’Zuh¨

oren’. Um den Lernprozess f¨

ur Re-

commender Shortcuts weiter zu beschleunigen, werden auch Recommender Short-

cuts aufgrund von Anfragen gebildet, die ein lokaler Peer nicht selbst gestellt hat.



5.2. Anfrageabh¨

angige Shortcuts

Route by

Flooding

Create

Shortcut

?=/Education/UML, TTL = 3

(a) Fluten und Antworten

Route by

Flooding

Create

Shortcut

(b) Erstellung

Abbildung 5.3: Recommender Shortcut Erstellung (aktiv)

Shortcut PID Query Hits Type Update

/Education/UML 4 23 r 210405103856

/Education/UML 6 20 r 210405103856

/Education/UML 3 23 c 210405103856

/Education/UML 5 20 c 210405103856

Tabelle 5.2: Index f¨

ur Peer 2 mit Content und Recommender Shortcuts

Dazu werden Anfragen anderer Peers ausgewertet, die durch den eigenen lokalen

Peer weitergeleitet werden. Im Gegensatz zu der aktiven Strategie zur Erstellung

von Recommender Shortcuts sammeln wir dadurch f¨

ur popul¨

are Themen schnell

Informationen ¨

uber passende Peers ohne eigene Aktivit¨

at.

Definition 5.2.5 (Recommender Peer Shortcut Index (passiv)). Sei nlein anfra-

gender Knoten, niein Knoten durch den die Anfrage geleitet wird, q(t)eine An-

frage mit t∈ T ,rf¨

ur den Type Recommender Shortcut und ut f¨

ur den Zeitpunkt

seiner Erstellung dann definieren wir die Struktur eines Eintrags im Recommender

Index von nials einen Tuple

roni= (t, nl,H(q(t), nj), r, ut)|roni∈ ROni

Da wir die Anzahl der erzielten Query Hits nicht kennen, setzen wir H(q(t), nj= 1

in der optimistischen Annahme, das nlf¨

ur die Anfrage passende Peers findet. ♣

Beispiel 5.2.3 (Passive Recommender Short Erstellung). Grafik 5.4 zeigt die Er-

stellung von Recommender Shortcuts mit einer passiven Strategie. Peer 8 erh¨

alt



5.3. Anfrageunabh¨

anige Shortcuts

Route by

Flooding

Create

Shortcut

?=/Education/UML, TTL = 3

(a) Fluten und Antworten

Route by

Flooding

Create

Shortcut

(b) Erstellung

Abbildung 5.4: Recommender Shortcut Erstellung (passiv)

durch Fluten eine Anfrage zum Thema /UML/Education. Anhand der Query Mes-

sage (siehe Definition 4.3.2) wird Peer 2 als anfragender Peer ermittelt. Zu diesem

Peer erstellt Peer 8 einen Recommender Shortcut (Grafik 5.4(b) und Tabelle 5.3).

Shortcut PID Query Hits Type Update

/Education/UML 2 1 r 210405103856

Tabelle 5.3: Index f¨

ur Peer 8 mit passivem Recommender Shortcut

5.3 Anfrageunabh¨

anige Shortcuts

Anfrageunabh¨

angige Shortcuts erlauben das Weiterleiten einer Anfrage unabh¨

angig

von dem gew¨

ahlten Thema der Anfrage. Verf¨

ugt ein Peer ¨

uber keine Shortcuts,

muss er eine initiale Menge von Verbindungen zu anderen Peers aufbauen. Im er-

sten Teil des Abschnittes beschreiben wir den Prozess zum Aufbau des Default

Network Overlays. Ist dieser Overlay gebildet, k¨

onnen Bootstrapping Shortcuts zu

besonders gut vernetzten Peers erstellt werden. Diese anfrageunabh¨

angigen Short-

cuts erlauben eine Reduzierung der Nachrichten gegen¨

uber dem Default Overlay

Network. Im zweiten Teil des Abschnittes stellen wir Strategien zur Erstellung und

Aktualisierung dieses neuen Shortcut Typs vor.



5.3. Anfrageunabh¨

anige Shortcuts

5.3.1 Default Network Layer

Einflussgr¨

ossen. Um einem unstrukturierten Netzwerk beizutreten, muss ein Peer

eine Menge Peers kennenlernen, die bereits mit dem Netzwerk verkn¨

upft sind. Die-

se initiale Menge an Peers erlaubt das Auffinden weiterer Peers im Netzwerk. Wir

bezeichnen sie als Default Network Layer. Historisch gesehen wurden diese Peers

in den fr¨

uhen Tagen von Gnutella noch m¨

undlich oder in Newsgroups propagiert.

Dadurch wurden h¨

aufig Peers miteinander vernetzt, die ¨

ahnliche Interessen aufwie-

sen. Aufgrund dieser Lokalit¨

at ben¨

otigten Anfragen wenige Nachrichten [Ora01].

Mit der Schliessung von Napster und der steigenden Popularit¨

at von Gnutella wur-

de dieser Prozess durch neue Technologien automatisiert. Dadurch wurden Peers

’zuf¨

allig’ miteinander vernetzt, was in einem erh¨

ohten Aufkommen von Nachrich-

ten f¨

ur eine Anfrage resultierte.

Definition 5.3.1 (Default Network Overlay). Als Default Network Overlay eines

Peers bezeichnen wir eine Menge von zuf¨

allig ausgew¨

ahlten Peers, die aufgrund

der initialen Netzwerk Struktur mit dem Peer benachbart sind. ♣

Erstellung. Die Erstellung des Default Network Layers basiert auf dem Rendez-

vous Protokoll des JXTA Netzwerkes. Zus¨

atzlich zum eigentlichen Peer-to-Peer

Netzwerk existiert ein Netzwerk von Rendezvous Super-Peers. Diese speichern die

PID von Peers im Netzwerk. Strategien zum Austausch und zur Aktualisierung von

PIDs zwischen den Rendezvous Peers werden in [TAA+03] vorgestellt. Im Gnu-

tella Netzwerk existiert ein ¨

ahnliches verteiltes Konzept, der Gnutella Web Cache.

In ihm werden die IP-Adressen aktuell mit dem Netzwerk verbundener Peers ¨

uber

das HTTP Protokoll registriert, aktualisiert und publiziert [KAD+04].

Definition 5.3.2 (Default Network Overlay Index). Sei niein anfragender Kno-

ten und njein benachbarter Knoten, dann definieren wir die Struktur eines Eintrag

im Default Network Overlay von nials

doni= (nj)|doni∈ DOni

Zu Beginn verbindet sich ein Peer zu einem beliebigen Rendezvous ¨

uber das HTTP

oder TCP Protokoll. Der Peer erh¨

alt eine Liste von PIDs zuf¨

allig ausgew¨

ahlter

Peers, die bereits mit dem Default Overlay Netzwerk verbunden sind. Im JXTA

Protokoll basiert die Liste der Peers auf den aktuell am Rendezvous Peer registrier-

ten Peers. Zu einer Teilmenge dieser Peers werden neue Verbindungen erstellt. Auf

der Basis dieser Verbindungen kann eine Suche und Erstellung weiterer Shortcuts

erfolgen. Schliesslich registriert sich der Peer ebenfalls an einem Rendezvous Peer.

Der Prozess wird wiederholt, wenn benachbarte Peer aus dem eigenen Default Net-

work Overlay das Netzwerk verlassen.



5.3. Anfrageunabh¨

anige Shortcuts

Rdv1

Rdv2

Rdv3

Rendevouz Peer Network

Default Network Overlay

(a) Verbinden mit Rendezvous Peer

Rdv1

Rdv2

Rdv3

Rendevouz Peer Network

Default Network Overlay

(b) Erstellung

Abbildung 5.5: Erstellung des Default Network Overlay

Beispiel 5.3.1 (Default Overlay Network). Grafik 5.5 zeigt den zweistufigen Pro-

zess der Registrierung im Default Network Overlay f¨

ur Peer 12. Der Peer verbin-

det sich mit dem zuf¨

allig ausgew¨

ahlten Rendezvous Peer Rdv3und erh¨

alt eine

Liste bereits am Netzwerk teilnehmender Peers (Grafik 5.5(a)). Peer 12 verbindet

sich zu Peer 5 und Peer 11 und registriert sich ebenfalls als Teilnehmer des Netz-

werkes im Rendezvous Peer Rdv3(Grafik 5.5(b)). ∗

5.3.2 Bootstrapping Layer

Einflussgr¨

ossen. Manchmal hat ein Peer f¨

ur eine Anfrage kein passendes The-

ma in seinem lokalen Index registriert. In diesem Fall muss der Peer die Anfrage

uber einen Shortcut weiterleiten, der nicht einem spezifischen Thema zugeordnet

ist. Bisher haben wir dazu nur das Weiterleiten ¨

uber Shortcuts des Default Network

Overlay betrachtet. Diese Strategie basiert auf dem Fluten des Netzwerkes und ist

mit einer hohen Anzahl an Nachrichten verbunden. Adamic et.al. hat in [ALPH01]

eine High Out Degree Strategie vorgestellt, bei der die Anzahl der Nachrichten

in einem unstrukturierten Netzwerk im Vergleich zur naiven Strategie der ¨

Uber-

flutung des Netzwerkes mit Nachrichten deutlich gesenkt wird. Wir wenden diese

Erkenntnis f¨

ur die Definition des Bootstrapping Overlay an.

Die Eigenschaft eines Peers f¨

ur das Bootstrapping wird ¨

uber seine Bootstrap-

ping Capability definiert. Wir definieren Bootstrapping Nodes als Peers, die ei-

nerseits viele ausgehende Shortcuts zu disjunkten Peers registrieren konnten, also

einen hohen OutDegree aufweisen und zu denen m¨

oglichst viele disjunkte Peers

einen Shortcut aufgebaut haben, also Peers die einen hohen Indegree aufweisen.



5.3. Anfrageunabh¨

anige Shortcuts

Definition 5.3.3 (Bootstrapping Capability). Sei OutDegreenidie Anzahl disjunk-

ter Peers zu denen niShortcuts registriert hat und InDegreenidie Anzahl unter-

schiedlicher Peers, die mit einen Shortcut auf niverweisen, dann definieren wir

die Bootstrapping Capability BCnivon niwie folgt:

BCni= (Outdgreeni+ 1) ×(InDegreeni+ 1)

Zur Vermeidung von ’Null’ Werten begrenzen wir beide Werte. Um eine Ann¨

ahrung

des InDegree in einem verteilten Netzwerk ohne vorhandenes globales Wissen zu

erm¨

oglichen, registrieren wir f¨

ur jeden gespeicherten Shortcut den vorletzten Peer

aus dem Pfad der Anfrage, da diese Peers einen Shortcut auf den lokalen Peer ge-

speichert haben. Bei aktiven Recommender Shortcuts ist dieser Peer identisch mit

dem Recommender Peer. Die Anzahl disjunkter Peers ergibt eine Ann¨

aherung des

Indegree. Ein hoher Wert von BCnibeschreibt einen Peer, der mit vielen Peers

uber lokalen Shortcuts vernetzt ist und dessen Shortcuts f¨

ur viele andere Peers re-

levant sind. ¨

Ahnlich [Kle98] verstehen wir derartige Peers als adaptive, themenun-

abh¨

angige Information Hubs im Netzwerk. Sie sind besonders hilfreich, f¨

ur Peers,

die dem Netzwerk neu beigetreten sind und die noch keine Peers f¨

ur ihre Anfragen

sammeln konnten (warm-up problem) bzw. f¨

ur Peers die eine Anfrage zu einem

Thema stellen, f¨

ur das sie keine lokalen Referenzen registriert haben.

Erstellung. Zur Gewinnung der Bootstrapping Information verwenden wir eine

Strategie, bei der jeder Peer in der Anfrage die eigenen Bootstrapping Informatio-

nen in der Query Message (siehe auch Definition 4.3.2) sendet. Zu jeder Anfrage,

die durch den Peer geleitet wird, speichern wir die Bootstrapping Capability des

anfragenden Peers.

Definition 5.3.4 (Bootstrapping Index). Sei niein anfragender Knoten, BCnisei-

ne Bootstrapping Capability und njein Knoten, durch den eine Anfrage geleitet

wird, dann definieren wir einen Index Eintrag in njals

bonj= (ni, BCni)|bonj∈ BOnj

Beispiel 5.3.2 (Bootstrapping Index). In Grafik 5.6 sendet Peer 2 eine Anfrage

und mit der Query Message auch seine Bootstrapping Capability. Wir nehmen an,

das Peer 2 bisher vier Shortcuts zu vier Peers f¨

ur ein Thema erstellt hat. Die Anfra-

ge erh¨

alt auch Peer 8, der diese Information in seinem Bootstrapping Index spei-

chert und einen Bootstrapping Shortcut zu Peer 2 aufbaut. Tabelle 5.4 erweitert das

Beispiel aus Tabelle 5.3 und zeigt den vollst¨

andigen Index von Peer 8 mit Boot-

strapping Informationen.



5.4. Verwandte Arbeiten

Route by

Flooding

Create

Shortcut

Shortcuts

from Peer 2

(a) Fluten

Route by

Flooding

Create

Shortcut

Shortcuts

from Peer 2

(b) Erstellung

Abbildung 5.6: Bootstrapping Shortcut Erstellung

Shortcut PID Query Hits Type Update BO

/Education/UML 2 1 r 210405103856 4

Tabelle 5.4: Index Peer 8 mit Bootstrapping Informationen

5.4 Verwandte Arbeiten

Die Verwendung von Shortcuts zur Verbesserung des Routings in unstrukturierten

Peer-to-Peer Netzwerken ist noch wenig untersucht. Studien [FHKM04, GDS+03]

haben gezeigt, das Peers sowohl geographische oder Interessen-basierte Lokalit¨

aufweisen.

Die Autoren in [SMZ03, Coo04, BCAA04] definieren Interest-based Locality

durch Shortcuts zu Peers, die eine Anfrage in der Vergangenheit exakt beantwor-

ten konnten. Sie zeigen, das durch den Einsatz dieser Shortcuts in einem unstruk-

turierten Netzwerk die Anzahl der Nachrichten gesenkt werden kann. Wir haben

die Idee beider Arbeiten aufgegriffen und in die Erstellung von Content Provider

Shortcuts einfließen lassen. Unser Modell der verschiedenen Shortcuts Overlays

ber¨

ucksichtigt ausserdem Peers, die sich durch erfolgreiche Anfragen und eine gu-

te Vernetzung auszeichnen.

Arbeiten von [CW04, CMH+02] und neuere Arbeiten zum Freenet Next Ge-

neration Routing Algorithm untersuchen Shortcuts die auf der geographische Lo-

kalit¨

at von anfragenden und antwortenden Peers basieren. Ihre Arbeiten beruhen

auf der These, das geographisch nahe Peers mit h¨

oherer Wahrscheinlichkeit ei-

ne Anfrage beantworten k¨

onnen, als entfernte Peers. Ziel ist die Reduzierung der

Latenzzeit und die Optimierung der verf¨

ugbaren Bandbreite im Netzwerk. Diese

Arbeitens sind orthogonal zu unserer Arbeit. Sie beziehen sich auf die Optimie-

rung der Netzwerk Struktur auf der Basis technischer Kriterien, w¨

ahrend wir Peers



5.5. Zusammenfassung

gruppieren, die an gleichen Themen interessiert sind.

5.5 Zusammenfassung

Dieses Kapitel zeigt Strategien zur Erstellung von Shortcuts in unstrukturierten

Peer-to-Peer Netzwerken. Der Beitrag dieses Kapitels liegt in der Klassifikation

von Shortcuts und in der Entwicklung neuer, jedoch einfacher, Strategien zur Er-

stellung von Shortcuts. Wir unterscheiden zwischen Shortcuts, die abh¨

angig oder

unabh¨

angig von dem konkreten Thema der Anfrage erzeugt werden. Zur ersten

Kategorie geh¨

oren Shortcuts zu Peers, die eine Antwort auf eine Anfrage geben

konnten Shortcuts, Shortcuts zu Peers die eine Nachricht weitergeleitet haben und

Shortcuts zu Peers, die eine Anfrage zu diesem Thema bereits in der Vergangen-

heit gestellt haben. Zur letzteren Kategorie geh¨

oren Shortcuts zu Peers, die gut

vernetzt sind und Shortcuts zu zuf¨

allig ausgew¨

ahlten Peers. F¨

ur den Aufbau von

Shortcuts analysieren wir die Resultate einer Anfrage, den Weg unserer Anfra-

ge ¨

uber entfernte Peers und Anfragen, die durch einen lokalen Peer weitergeleitet

wurden. Shortcuts werden in zwei lokalen Index gespeichert, ein Index Shortcuts

zum Default Network Layer, der den ’Index’ momentan existierender unstruktu-

rierter Netzwerke abbildet und ein erweiterter Index, der Content-, Recommender-

und Bootstrapping Shortcuts abbildet.



Index Verwaltung und Routing Modell

Dieses Kapitel ist der Auswahl von Peers f¨

ur eine Anfrage auf der Basis lokal re-

gistrierter Shortcuts gewidmet. Wir zeigen den Ablauf des Routings von Anfragen

in Shortcut Netzwerken mit den beiden Kernfunktionen Index Management und

Shortcut Auswahl. Die Auswahl von registrierten Shortcuts f¨

ur eine Anfrage und

das L¨

oschen bereits registrierter Shortcuts beeinflussen sich gegenseitig. Im ersten

Teil dieses Kapitels pr¨

asentieren wir einen neuen Routing Algorithmus zur Aus-

wahl von Shortcuts. Der Algorithmus ber¨

ucksichtigt dynamisch, welche Shortcuts

bereits in den verschiedenen lokalen Indizes vorhanden sind. Im zweiten Teil des

Kapitels stellen wir eine Strategie zur Aktualisierung der Indizes vor.

6.1 Interaktionen und Ablaufmodell

Das INGA Netzwerk beinhaltet verschiedene Aktivit¨

aten, die entweder von einem

Peer lokal oder in Interaktion mit entfernten Peers ausgef¨

uhrt werden. Grafik 6.1

zeigt eine ¨

Ubersicht des Verhaltens lokaler Peers und entfernter Peers w¨

ahrend des

Anfrageprozesses.

Lokal: Senden der Anfrage. Der lokale Peer stellt zuerst die eigenen Informa-

tionen f¨

ur die Query Message entsprechend Definition 4.3.2 zusammen (Prepare

Query). Dann w¨

ahlt der lokale Peer aufgrund seines zu diesem Zeitpunkt vorhan-

denen lokalen Wissens dynamisch passende Shortcuts f¨

ur die Anfrage aus (Se-



6.1. Interaktionen und Ablaufmodell

Prepare Query

Send Query

Receive Query

q : Query

-------------

[TTL-1]

Update Index

(BO, RO)

Update Query

Results

found?

Send Answer

Select Shortcuts

Send Query

Receive Answer

a : Answer

q : Query

--------------

[TTL-1]

TTL=0

reached?

[True]

[False]

[True]

Update Index

(CO, RO)

Local Peer

Remote Peer

Select

Shortcuts

[False]

Next Remote Peer

Receive Query

Abbildung 6.1: Routing und Aktualisierung

lect Shortcuts), beispielsweise im ’Idealfall’ passende Content Provider Shortcuts.

Schließlich wird die Anfrage ¨

uber die ausgew¨

ahlten Shortcuts an entfernte Peers

gesendet (Send Query) und die Anzahl verbleibender Hops (TTL) reduziert.

Im Netzwerk: Beantworten der Anfrage. Erh¨

alt ein entfernter Peer eine Anfra-

ge, werden die in ihr enthaltenen Informationen, wie anfragender Peer, Bootstrap-

ping Capability oder das Thema der Anfrage extrahiert und der lokale Recommen-

der und Bootstrapping Index aktualisiert (Update Index (BO,RO)). In Abschnitt

6.3 stellen wir dazu geeignete Algorithmen vor. Dann versucht der Peer passende

Antworten f¨

ur die Anfrage zu finden. Ist das der Fall, erzeugt der entfernte Peer

eine Result Message entsprechend Definition 4.3.3 und sendet die Resultate zum

anfragenden Peer zur¨

uck (Send Answer).

Im Netzwerk: Weiterleiten der Anfrage. Erh¨

alt ein Peer eine Anfrage in der

die maximale Anzahl m¨

oglicher Hops noch nicht erreicht ist, wird die Anfrage



6.2. Dynamisches Routing Modell

mit der ID des aktuellen Peers erg¨

anzt (Update Query). Ebenfalls werden dyna-

misch weitere Shortcuts zur Weiterleitung der Anfrage ausgew¨

ahlt (Select Short-

cuts). Basierend auf der ¨

Ahnlichkeit der Anfrage mit bereits registrierten Shortcuts

sind das entweder anfrageabh¨

angige oder anfrageunabh¨

angige Shortcuts. In Ab-

schnitt 6.2 stellen wir einen Algorithmus zur dynamischen Auswahl der Shortcuts

vor. Schließlich wird die Anfrage an weitere ausgew¨

ahlte Peers gesandt und die

Anzahl verbleibender Hops in der Anfrage reduziert (Send Query).

Lokal: Empfangen von Antworten. Wenn ein Peer eine Antwort empf¨

angt (Re-

ceive Answer), werden aus der Result Message (siehe Definition 4.3.3) Informatio-

nen ¨

uber die Anzahl der Antworten, den antwortenden Peer und weiter leitende

Peers extrahiert und der lokale Recommender und Content Provider Index aktuali-

siert (Update Index (Co, RO)).

6.2 Dynamisches Routing Modell

In Abschnitt 5.1 definieren wir vier Typen von Shortcuts, die an einem Peer re-

gistriert werden k¨

onnen. F¨

ur jeden dieser Typen existieren in der Literatur bereits

Routing Strategien, die mit unterschiedlicher Effizienz eine Anfrage weiterleiten.

Wir stellen die Strategien kurz vor und adaptieren sie f¨

ur das INGA Netzwerk. Im

zweiten Teil stellen wir einen neuen Algorithmus vor, der die top-k Shortcuts f¨

eine Anfrage an einem Peer lokal ausw¨

ahlt. Der Algorithmus untersucht, welche

Shortcuts f¨

ur das Thema Anfrage bereits bekannt sind und w¨

ahlt dynamisch die

passende(n) Routing Strategie(n) aus.

6.2.1 Greedy Routing

Strategie und Ziel. Analog zu den Arbeiten von Kleinberg [Kle00b] und Mil-

gram verwenden wir eine Greedy Routing Strategie, die eine Nachricht ¨

uber die

top-k Shortcuts leiten und die gr¨

oßte ¨

Ahnlichkeit mit der Anfrage aufweisen. Das

INGA Netzwerk verwendet eine Funktion zur Messung der semantischen ¨

Ahn-

lichkeit zwischen einer Anfrage und einem anfrageabh¨

angigen Shortcut. Derartige

Funktionen sind h¨

aufig dom¨

anenspezifisch und h¨

angen von der verwendeten On-

tologie ab. Wir benutzen die von Li et.al. [LBM03] vorgeschlagene ¨

Ahnlichkeits-

funktion f¨

ur Themen-Hierarchien.

Definition 6.2.1 (Semantische ¨

Ahnlichkeit in einer Themen-Hierarchie). Sei

simTopic :Q×Φ7→ [0,1] eine ¨

Ahnlichkeitsfunktion zwischen einer Anfrage q∈Q

und einem anfrageabh¨

angigen Shortcut φ∈Φ. Weiterhin seien beide Element



6.2. Dynamisches Routing Modell

derselben Themen -Hierarchie q, φ ∈ T . Wir definieren deren ¨

Ahnlichkeit als

simTopic(q, φ) = (e−αl ·eβh−e−βh

eβh+e−βh if q6=φ

1otherwise

wobei ldie L¨

ange der k¨

urzesten Verbindung zwischen qund φund hdie minima-

le H¨

ohe entweder von qoder φin der Themen-Hierarchie bildet. αund βsind

Konstanten, die den Beitrag von hund lskalieren. Folgend den Experimenten von

[LBM03] verwenden wir α=0.2 und β=0.6 . ♣

Die Funktion simTopic weist f¨

ur eine hohe ¨

Ahnlichkeit einen Wert nahe 1 und f¨

eine geringe ¨

Ahnlichkeit einen Wert nahe 0 auf.

Algorithmus. Algorithmus 1 zeigt den TopGreedy Algorithmus. Er w¨

ahlt f¨

eine Anfrage die top-k anfrageabh¨

angigen Shortcuts aus, die ¨

uber einem Grenz-

wert liegen. Der Algorithmus sucht die ¨

ahnlichsten Shortcuts f¨

ur die Anfrage

Algorithm 1 TopGreedy

Require: Query q,Set index,int k,int tgreedy

1: topShortcuts ← {}

2: s tmp ←index

3: while (s tmp is not empty) ∧(k>0) do

4: Next ←maxSimT opic(q, s tmp)

5: if simTopic (q,Next)> tgreedy then

6: s tmp ←s tmp −(Next)

7: if (Next routes not to a peer in topShortcuts)then

8: topShortcuts ←topShortcuts +Next

9: k←k−1

10: end if

11: else

12: break

13: end if

14: end while

15: Return topShortcuts

(Zeile 4-6), beginnend mit dem Shortcut mit der h¨

ochsten ¨

Ahnlichkeit. Wir ver-

wenden einen Schwellwert tgreedy um Peers mit einer geringen ¨

Ahnlichkeit nicht

zu ber¨

ucksichtigen. Der Algorithmus vermeidet ¨

uberlappende Shortcuts, beispiels-

weise zwei gew¨

ahlte Shortcuts, die zu dem gleichen Peer f¨

uhren (Zeile 7-9). Der

Algorithmus bricht ab, wenn bereits alle Shortcuts gepr¨

uft oder top-k Shortcuts



6.2. Dynamisches Routing Modell

ausgew¨

ahlt wurden (Zeile 3) und wenn keine Shortcuts mehr vorliegen, die einen

gew¨

ahlten Grenzwert ¨

uberschreiten (Zeile 11-12).

6.2.2 High Out-Degree Routing

Strategie und Ziel. Im INGA Netzwerk w¨

ahlen wir die Knoten aus, die viele

Peers zu unterschiedlichen Themen kennen. Dazu verwenden wir die Bootstrap-

ping Capability entsprechend Definition 5.3.3. F¨

ur eine Anfrage w¨

ahlen wir die

lokal registrierten Bootstrapping Shortcuts mit der h¨

ochsten Bootstrapping Capa-

bility aus. Zus¨

atzlich m¨

ussen diese Knoten ¨

uber eine h¨

ohere Bootstrapping Ca-

pability als der lokale Peer verf¨

ugen. Damit verhindern wir ein Weiterleiten einer

Anfrage an Peers mit einer geringen Vernetzung, ausgehend von der Vernetzung

des eigenen Peers.

Algorithmus. Algorithmus 2 zeigt den TopBootstrapping Algorithmus. Analog

zum TopGreedy Algorithmus w¨

ahlt er f¨

ur eine Anfrage die top-k Bootstrapping

Shortcuts aus. Der Algorithmus beginnt mit der Auswahl von Shortcut mit der

Algorithm 2 TopBootstrapping

Require: Set index,int k,int local bo

1: topShortcuts ← {}

2: s tmp ←index

3: while (s tmp is not empty) ∧(k>0) do

4: Next ←maxBC(s tmp)

5: s tmp ←s tmp −(Next)

6: if (Next routes not to a peer in topShortcuts)then

7: if (Next.GetBo() >local bo)then

8: topShortcuts ←topShortcuts +Next

9: k←k−1

10: end if

11: end if

12: end while

13: Return topShortcuts

h¨

ochsten Bootstrapping Capability, deren Bootstrapping Capability gr¨

osser ist, als

der lokale Wert (Zeile 4). Dabei vermeidet der Algorithmus ¨

uberlappende Short-

cuts, beispielsweise zwei gew¨

ahlte Shortcuts, die zu dem gleichen Peer f¨

uhren

(Zeile 6-8). Der Algorithmus bricht ab, wenn bereits alle Shortcuts gepr¨

uft oder

top-k Shortcuts ausgew¨

ahlt wurden (Zeile 3).



6.2. Dynamisches Routing Modell

6.2.3 Firework Query Routing

Strategie und Ziel. Die Autoren in [KNS04, NS02] verwenden in ihren Arbei-

ten das Fireworks Query Model. Eine Anfrage wird mit einer top-k Strategie an

ausgew¨

ahlte Peers durch das Netzwerk geleitet, bis Peers gefunden werden, deren

Shortcuts exakt zur Anfrage passen. In diesem Fall wird die Anfrage an alle Peers

geleitet. Die Autoren folgen der Idee, das eine Anfrage mit hoher Wahrscheinlich-

keit einen Cluster erreicht hat, der viele Peers umfasst, die Interesse am Thema der

Anfrage haben. Im INGA Netzwerk wird eine Anfrage ¨

uber alle Content Provider

Shortcuts geleitet, die eine exakte ¨

Ubereinstimmung mit der Anfrage aufweisen.

Andernfalls wird die Anfrage ¨

uber eine Greedy-, Bootstrapping- oder Serendipity

Routing Strategie geleitet.

Algorithmus. Algorithmus 3 zeigt den FireWorks Algorithmus, der alle Content

Provider ausw¨

ahlt, die exakt zur Anfrage passen (Zeile 4). Analog zu TopGreedy

Algorithm 3 Fireworks

Require: Query q,Set index

1: fwShortcuts ← {}

2: s tmp ←index.getContentProviderShortcuts()

3: while (s tmp is not empty) do

4: Next ←exactSimT opic(q, s tmp)

5: s tmp ←s tmp −(Next)

6: if (Next routes not to a peer in fwShortcuts)then

7: fwShortcuts ←fwShortcuts +Next

8: end if

9: end while

10: Return fwShortcuts

und TopBootstrapping vermeidet der Algorithmus ¨

uberlappende Shortcuts (Zeile

6-8). Der Algorithmus bricht ab, wenn bereits alle Content Provider Shortcuts ge-

pr¨

uft wurden (Zeile 3).

6.2.4 Serendipity Routing

Strategie und Ziel. Analog zu den lokalen Suchalgorithmen f¨

ur die Ant Coloni-

zation Optimization tritt bei der Verwendung einer Greedy Routing Strategie das

Shortcut Problem [SHB97, DG89] auf:



6.2. Dynamisches Routing Modell

Definition 6.2.2 (Shortcut Problem). Wird eine Anfrage nur ¨

uber bereits regi-

strierte Shortcuts geleitet, werden Peers die dem Netzwerk neu beitreten und bereits

registrierte Peers nicht ber¨

ucksichtigt. ♣

Wir implementieren eine adaptive Anpassung der Shortcuts ¨

uber zwei Funktiona-

lit¨

aten:

1. Ein Peer l¨

oscht Shortcuts, die in der Vergangenheit eine schlechte Perfor-

manz aufwiesen. Dazu verwenden wir die in Abschnitt 6.3 vorgestellten In-

dex Management Strategien.

2. Wir leiten eine bestimmten Anteil der Anfragen ¨

uber zuf¨

allig ausgew¨

ahl-

te Verbindungen. Im INGA Netzwerk erfolgt ein Routing mit einer Wahr-

scheinlichkeit von (1 −f)¨

uber einen Shortcut aus dem Bootstrapping, Con-

tent Provider oder Recommender Overlay und einer Wahrscheinlichkeit von

f¨

uber den Default Network Overlay. [MSZ03, TSW04] haben den Effekt ei-

nes unerwarteten Zufalls (Serendipity) in ihren Versuchen in Shortcut Netz-

werken nachgewiesen.

Algorithmus. Algorithmus 4 zeigt den Serendipity Algorithmus, der eine be-

stimmte, durch den Parameter f|f∈[0,1] ∧f∈ R definierte, Anzahl zuf¨

alliger

Shortcuts mit einer Menge bereits ausgew¨

ahlten Shortcuts austauscht. Zuerst pr¨

uft

der Algorithmus, ob der Auswahl von Shortcuts noch mehr zuf¨

allige Shortcuts hin-

zugef¨

ugt werden m¨

ussen, als durch den Parameter fbestimmt wurde (Zeile 2). Ist

das nicht der Fall entscheidet der Algorithmus durch eine gleichf¨

ormige Zufallsver-

teilung, ob ein bereits ausgew¨

ahlter Shortcut durch einen Shortcut aus dem Default

Network Overlay ausgetauscht wird. Fehlende Shortcuts werden durch Shortcuts

aus dem Default Overlay Network erg¨

anzt (Zeile 12-15).

6.2.5 Dynamische Auswahl der Strategie

Strategie und Ziel. Die Aufgabe der Routing Komponente eines INGA Peers ist

die besten Shortcuts f¨

ur eine Anfrage zu finden. Dieser Prozess erfolgt dynamisch

in Abh¨

angigkeit von dem im lokalen Index f¨

ur die Anfrage verf¨

ugbaren anfrage-

abh¨

angigen und anfrageunabh¨

angigen Shortcuts. Entsprechend den in Abschnitt

4.2.2 vorgestellten sozialen Metaphern definieren wir folgende Heuristiken f¨

ur die

Auswahl von Routing Algorithmen:

1. Zuerst sucht ein Peer nach Content Provider Shortcuts, die mit der Anfrage

exakt ¨

ubereinstimmen und die Anfrage unmittelbar zu einem Peer schicken,

der passende Dokumente hat.



6.2. Dynamisches Routing Modell

Algorithm 4 Serendipity

Require: Set preSelected,Set defaultNetWorkShortcuts,int f,int k

1: Set postSelected ← {}

2: if (k−|preSelected|

k< f)then

3: while (preSelected is not empty) do

4: Next ←next(preSelected)

5: preSelected ←preSelected −(Next)

6: if (rand(0,1) > f)then

7: postSelected ←postSelected +Next

8: end if

9: end while

10: end if

11: k←k− |postselected|

12: while k > 0do

13: postSelected ←postSelected +next(defaultNetworkShortcuts)

14: k←k−1

15: end while

16: Return postSelected

2. Werden nur ungen¨

ugend exakt passende Content Provider Shortcuts gefun-

den, versucht ein Peer zu einer Anfrage ¨

ahnliche Content Provider- und Re-

commender Shortcuts zu finden.

3. Hat ein Peer ungen¨

ugend anfrageabh¨

angige Shortcuts gefunden, die eine mi-

nimale ¨

Ahnlichkeit mit der Anfrage aufweisen, versucht der Peer die Anfra-

ge an Peers mit einer besonders guten Vernetzung weiter zu leiten.

4. Hat ein Peer keine Shortcuts mit den vorhergehenden Strategien finden k¨

on-

nen, sendet er die Anfrage an seine durch die initiale Netzwerk Struktur vor-

gegebenen Nachbarn. Um f¨

ur eine Anfrage zus¨

atzliche Peers kennenzuler-

nen und ein Verharren in einem m¨

oglichen lokalen Maximum bei der Ver-

wendung einer Greedy Strategie vorzubeugen, tauschen wir bereits bewußt

gew¨

ahlte Shortcuts mit einigen zuf¨

allig gew¨

ahlten Shortcuts aus.

Algorithmus. Algorithmus Dynamic wird in Algorithmus 5 gezeigt. Er w¨

ahlt

f¨

ur eine Anfrage die top-k Shortcuts aus. Der Algorithmus pr¨

uft, ob eine Anfrage

bereits die maximale Anzahl von Hops erreicht hat. Entsprechend unseren Heu-

ristiken ruft der Algorithmus zuerst eine Fireworks Strategie auf. Vor dem Aufruf

weiterer Routing Strategien pr¨

uft der Algorithmus, ob die gew¨

unschte Anzahl von



6.3. Index Management

Algorithm 5 Dynamic

Require: Query q,int k,int tGreedy

Ensure: T T Lq<maxTTL

1: s← {}

2: s←Fireworks(q,index)

3: if (|s|< k)then

4: s←TopGreedy(q,index,(k− |s|),tGreedy)

5: end if

6: if (|s|< k)then

7: s←TopBootStrapping(index,(k− |s|))

8: end if

9: s←Serendipity(s,defaultNetworkShortcuts,f,k)

10: Return s.

Shortcuts bereits erreicht wurde. Zuletzt werden einige bereits gew¨

ahlte Shortcuts

durch zuf¨

allige Shortcuts ausgetauscht.

6.3 Index Management

Mit zunehmender Anzahl der eigenen Anfragen und der weitergeleiteten Anfragen

anderer Peers, wird der Content Provider, Recommender und Bootstrapping In-

dex wachsen. Entsprechend den in Abschnitt 4.2.2 definierten sozialen Metaphern

und in Abschnitt 4.1 vorgestellten Designentscheidungen wird ein Peer nur eine

begrenzte Anzahl von Shortcuts verwalten. F¨

ur die Begrenzung des Index identifi-

zieren wir folgende Ursachen:

1. Die Anzahl der registrierten Peers ist durch den lokal verf¨

ugbaren Platten-

platz, Hauptspeicher und die Prozessorleistung begrenzt.

2. Ein Peer verwaltet ’egoistisch’ nur die Peers, die f¨

ur seine eigenen Anfragen

relevante Dokumente publizieren (Content Provider), relevante Peers emp-

fehlen k¨

onnen (Recommender) oder gut vernetzt sind (Bootstrapping Peers).

3. Um ein ¨

Uberfluten des Netzwerkes zu vermeiden, wird eine Anfrage nur an

die ’besten’ lokal bekannten Peers weitergeleitet. Es ist nur n¨

otig, die besten

Peers f¨

ur ein Thema im Index zu verwalten.

Um zu entscheiden, welcher Shortcut nicht mehr im Index verbleibt, ordnen wir lo-

kal die Content und Recommender Shortcuts. Dazu berechnen wir f¨

ur jeden Short-

cut eine Relevanz. Die Shortcuts mit der geringsten Relevanz werden gel¨

oscht.



6.3. Index Management

Strategie und Ziel. Unsere Strategie basiert darauf, das ein Peer der in der Ver-

gangenheit viele unserer Anfragen erfolgreich beantworten konnte, auch in der

Zukunft ¨

uber passende Shortcuts bzw. Dokumente f¨

ur unsere Anfragen verf¨

ugt.

Weiterhin ber¨

ucksichtigen wir die semantische N¨

ahe der uns bekannten Anfragen

eines entfernten Peers zu unseren eigenen Anfragen. Schließlich ber¨

ucksichtigen

wir noch die wechselnde Interessen der Peers. Dazu f¨

uhren wir folgende drei Lo-

kalit¨

aten ein:

Community-Lokalit¨

at. Wir untersuchen, wie nahe ein lokal gespeicherter Re-

commender oder Content Provider Shortcut uns zu dem gew¨

unschten Doku-

ment f¨

uhrt und welches Wissen wir ¨

uber die Erstellung des Shortcuts haben.

Dazu f¨

uhren wir einen Wichtungsfaktor type f¨

ur den Shortcut Typ ein. Con-

tent Provider Shortcuts, die im Index mit einem ’c’ markiert sind, ben¨

otigen

einen Hop um eine Anfrage zu einem Peer weiter zuleiten, der ein passendes

Dokument speichert. Wir vermuten weiterhin, das diese Peers besonders an

diesem Thema interessiert sind und das auch ihre Bereitschaft Plattenplatz

und Bandbreite f¨

ur bestimmte Themen zur Verf¨

ugung zu stellen h¨

oher ist, als

bei anderen Peers, wir setzen type = 1. Bei einem Recommender Shortcut

betr¨

agt die Entfernung zu einem Dokument zwei Hops. Zus¨

atzlich wissen

wir bei aktiven Recommender Shortcuts nicht, von welchem Typ der Short-

cut vom Recommender zum Content Provider ist, beispielsweise kann der

Recommender den Shortcut nur zuf¨

allig aufgebaut haben und nicht auf der

Basis eigener Anfragen. Wir setzen type = 0.5

Zeitliche Lokalit¨

at. Interessen eines Peers k¨

onnen ’langfristig’ wechseln [All96].

Wir verwenden eine Least Recently Used (LRU) Strategie, die bereits im

Buffer Management von Datenbanken [ADU71] und im Cache Manage-

ment f¨

ur Webbrowser [MT02] erfolgreich zur Modellierung der Interessen

der Nutzer und der Popularit¨

at verf¨

ugbarer Objekte verwendet wird. Sie er-

setzt die Objekte im Cache, die am l¨

angsten nicht benutzt wurden. Analog

verfahren wir mit Shortcuts im Index: Jeder Shortcut verf¨

ugt ¨

uber das Attri-

but Update, das den Zeitpunkt seiner Erzeugung beschreibt. Wird ein Short-

cut erfolgreich von einem lokalen Peer benutzt, so aktualisieren wir Update

mit der aktuellen Zeit. Dadurch werden nicht benutze Shortcuts gel¨

oscht,

w¨

ahrend h¨

aufig benutze Shortcuts im Index verbleiben. Wir berechnen die

Relevanz eines Shortcuts sc abh¨

angig von der Zeit entsprechend Gleichung

6.1:

updatenorm(sc) = 1 −CurrentT ime −Update(sc)

CurrentT ime −OldestUpdate (6.1)



6.3. Index Management

wobei CurrentTime die aktuelle Zeit, Update(sc)den Zeitpunkt der Ak-

tualisierung f¨

ur einen Shortcut sc und OldestUpdate den Zeitpunkt der Ak-

tualisierung f¨

ur den Shortcut mit der l¨

angsten Differenz zwischen seiner letz-

ten Aktualisierung und der aktuellen Zeit bezeichnet.

Beispiel 6.3.1 (Zeitliche Lokalit¨

at der Shortcuts). Wir zeigen die Aktua-

lisierung von updatenormalized am Beispiel eines Index mit zwei Content

Provider Shortcuts. Zu Vereinfachung nehmen wir an, das alle Shortcuts in

der selben Stunde erstellt wurden:

Shortcut PID QH Type Update updatenorm

/Education/UML 4 23 c 210405103800 1−39−38

39−12 =0.963

/Education/UML 6 20 c 210405101200 1−39−12

39−12 =0

Tabelle 6.1: Berechnung von updatenorm zum Zeitpunkt 210405103900

Semantische Lokalit¨

at. Ein Peer speichert in seinem Index alle passiven Recom-

mender Shortcuts, die er durch Anfragen entfernter Peers kennenlernt. Durch

diese Strategie lernt ein Peer schnell neue Peers ¨

uber deren Anfragen kennen.

H¨

aufig stimmt jedoch nur ein kleiner Teil der Shortcuts mit den Interessen

des eigenen lokalen Peers ¨

uberein. Wir untersuchen die semantische N¨

ahe

passive Recommender Shortcuts zu unserem eigenen Interessen-Profil. In

dieser Arbeit nehmen wir an, das ein solches Profil bereits gegeben ist. Al-

ternativ kann das Interessen-Profil aus den Anfragen des lokalen Nutzers

modelliert, aus den publizierten Dokumenten abgeleitet oder durch den Nut-

zer durch Metadaten manuell beschrieben werden. Zur Messung der seman-

tischen ¨

Ahnlichkeit verwenden wir Gleichung 6.2.1. Wir vergleichen jeden

Shortcut mit dem Interessenprofil und speichern die maximal erreichte ¨

Ahn-

lichkeit in maxsim(sc). Shortcuts, die mit unseren Interessen ¨

ahnlich oder

gleich sind, verbleiben im Index.

Wir vermuten, das die Lokalit¨

aten unterschiedlich stark Einfluss auf den Rang ei-

nes Shortcuts im Index aus¨

uben und gewichten jede der Lokalit¨

aten mit einem

Faktor. Gleichung 6.2 beschreibt die Relevanz relevance(sc)∈[0,1] eines Short-

cuts im Index. Zur Gewichtung der unterschiedlichen Lokalit¨

aten verwenden wir

den Weighted moving average.

relevance(sc) = a∗maxsim(sc)++b∗updatenorm(sc) + c∗type(sc)

a+b+c(6.2)

In Abschnitt 7.3 untersuchen wir den Einfluss der Gewichtungsfaktoren auf die

Effizienz des Netzwerkes.



6.4. Verwandte Arbeiten

Algorithmus. Algorithmus 6 wird aufgerufen, wenn ein neuer Recommender

oder Content Provider Shortcut erstellt wird. Zuerst f¨

ugen wir den neuen Shortcut

dem Index hinzu und berechnen seinen Relevanz entsprechend Gleichung 6.2. Hat

der Index mit dem Shortcut seine maximale Gr¨

oße ¨

uberschritten(Zeile 1) pr¨

ufen

wir, ob der Shortcut sc eine h¨

oheren Relevanz aufweist, als der Shortcut lowest sc

im Index mit dem geringsten Relevanz (Zeile 3). Ist das der Fall, l¨

oschen wir

lowest sc und f¨

ugen sc in den Index ein (Zeile 4,5).

Algorithm 6 InsertQueryDependentShortcut

Require: Shortcut sc, LocalIndex index,int maxIndexSize

1: if index.getSize() =maxIndexSize then

2: Shortcut lowest sc=index.getShortcutWithLowestRelevance()

3: if (relevance(lowest sc)<relevance(sc)) then

4: index.remove(lowest sc)

5: index.insert(sc,relevance(sc))

6: end if

7: end if

6.4 Verwandte Arbeiten

Ahnliche Arbeiten zu Index- und Routing Strategien wurden im Bereich der Daten-

banken, der Analyse sozialer Netzwerke und im Bereich der Suche in Peer-to-Peer

Netzwerken durchgef¨

uhrt.

6.4.1 Index Management

Folgende Ans¨

atze beinhalten Index Strategien, die ein Clustern von Peers auf der

Basis gemeinsamer Interessen unterst¨

utzen:

•Die Autoren in [SMZ03] verwenden eine Metrik zur Messung des Erfolgs

von Content Provider Shortcuts. Die Metrik definiert die success rate als

das Verh¨

altnis zwischen der Anzahl der erfolgreichen Versuche und der An-

zahl aller Versuche ¨

uber einen Shortcut eine Anfrage zu leiten. Der Ansatz

gewichtet stark bereits gefundene Shortcuts und gewichtet schwach die zu

einem sp¨

ateren Zeitpunkt gefundene Shortcuts.

•Die Autoren von [VKMvS04] untersuchen in ihren Arbeiten neben der LRU

Strategie zwei weitere Verfahren f¨

ur das Index Management von Content

Provider Shortcuts:



6.4. Verwandte Arbeiten

History Based Indexing. Dieser Ansatz bewertet Peers h¨

oher, die gleiche

Interessen wie der anfragende Peer aufweisen. Dazu enth¨

alt der Index

alle Peers mit denen ein lokaler Peer in Kontakt getreten ist. Jeder Peer

verf¨

ugt zus¨

atzlich ¨

uber einen Z¨

ahler. Kann ein Peer eine Anfrage er-

folgreich beantworten, so wird der Z¨

ahler erh¨

oht. Der Ansatz hat zwei

Nachteile: Erstens kann der Index kann beliebig gross werden. Zwei-

tens, passt sich der Index nur langsam an neue Interessen der Nutzer

an. Die Autoren verwenden den Ansatz als Vergleichswert in ihren Ar-

beiten.

Popularity based Indexing. Dieser Ansatz bewertet, wie h¨

aufig ein Peer

innerhalb eines Zeitintervalls erfolgreich eine Anfrage beantworten konn-

te. Peers verbleiben im Index, die innerhalb eines Zeitintervalls die

meisten Anfragen beantworten konnten. Dadurch werden Peers h¨

oher

bewertet, die popul¨

are Anfragen beantworten konnten. Leider geben

die Autoren keine Hinweise f¨

ur die Wahl des Zeitintervalls an.

Die Ergebnisse der Autoren zeigen, das bei allen drei Ans¨

atzen Peers mit

gleichen Interessen im Index des anfragenden Peers gespeichert werden. Un-

terschiede ergeben sich in der Anzahl der Verwendung des Index, die bei der

’History’ Strategie am h¨

ochsten ist.

•Die Autoren in [CFB04] vergleichen die LRU Strategie mit der Most Of-

ten Used (MOU) Strategie. Peers werden h¨

oher bewertet, die entweder eine

Anfrage beantwortet haben oder die eine Anfrage zu einem antwortenden

Peer weitergeleitet haben. Jeder Peer im Pfad zum antwortenden Peer erh¨

alt

einen Wert. Der antwortende Peer erh¨

alt den h¨

ochsten Wert, f¨

ur nachfolgen-

de Peers sinkt der Wert exponentiell. Beide Strategien ben¨

otigen ungef¨

ahr

die gleiche Anzahl von Hops. Die Vorteile der MOU Strategie liegen in der

Bildung einer stabileren Netzwerk Struktur nach einer geringen Anzahl von

Anfragen.

6.4.2 Routing Ans¨

atze

Soziale Netzwerke. Suchstrategien f¨

ur soziale Netzwerke wurden k¨

urzlich von

verschiedenen Autoren f¨

ur Peer-to-Peer Systeme untersucht. Die Autoren

von [CFB04] schlagen eine Strategie vor, die eine hohe ¨

Uberlappung in ih-

ren Anfragen haben und einem gemeinsamen Cluster zugeordnet werden.

Zur Speicherung der erfolgreichen Anfragen analysieren sie verschiedene

Indexstrategien. Im Gegensatz zu INGA ber¨

ucksichtigen sie f¨

ur die Bildung

der Cluster keine Themen und keine semantischen Beziehungen zwischen



6.4. Verwandte Arbeiten

den Themen. Die Autoren von [TSW04] untersuchen Strategien f¨

ur das se-

mantische Weiterleiten von Anfragen. Peers und Anfragen sind durch eine

Themen-Hierarchie klassifiziert. Die Autoren verwenden jedoch nur Con-

tent Provider Shortcuts, die in einem unbegrenzten gespeichert werden und

optimieren den Ansatz nicht in einem dynamischen Netzwerk. In [AA04]

untersuchen die Autoren verschiedene Strategien f¨

ur die Suche in sozialen

Netzwerken, wie dem E-Mail Verkehr in einem Forschungslabor. Sie zeigen,

das eine High Degree Strategie sich bedingt eignet und mit einer Greedy

Strategie effizient eine Suche erfolgt. Sie kombinieren nicht die Strategien

und zeigen keine Strategien f¨

ur das Index Management und die Bildung von

Shortcuts auf.

Gossiping. Gossiping ist ein Verfahren, um in einem Netzwerk eine Information

an alle Peers eines Netzwerkes zu verschicken. Hierzu werden Nachrichten

an (zuf¨

allig) ermittelte Adressaten gesandt [DGH+87]. Im Gegensatz zu ei-

ner Suche in einem Peer-to-Peer Netzwerk liegt der Schwerpunkt auf einer

effizienten Verteilung von Informationen an m¨

oglichst alle Peers, ohne das

eine zentrale Instanz vorliegt und mit einer m¨

oglichst gleichm¨

aßiger Bela-

stung aller Peers [CAPMN02, GBL+03].

Die Autoren von [ACMH02] bezeichnen Semantic Gossiping als das Er-

lernen von Shortcuts zwischen entfernten Peers mit ¨

ahnlichen Schemata in

Mapping Netzwerken. Zur Messung der ¨

Ahnlichkeit analysieren sie die syn-

taktische ¨

Ahnlichkeit einer Anfrage, nachdem sie ¨

uber mehrere Peers weiter-

geleitet wurde. Zur Feststellung der semantische ¨

Ahnlichkeit nutzen die Au-

toren Zyklen in Mapping-Netzwerken und untersuchen den Informationsver-

lust mit Hilfe der Maximum Likely-Hood Approximation. Zus¨

atzlich wird

uberpr¨

uft, ob die Resultate mit semantisch ¨

ahnlichen Metadaten annotiert

wurden. Die Autoren zeigen in Versuchen, das ein Peer nach einer Lernpha-

se des Systems nur noch Anfragen an Peers stellt, die eine hohe semantische

Ahnlichkeit aufweisen. Wir vermuten, das der Semantic Gossiping Ansatz

mit dem INGA Ansatz kombiniert werden kann. Ein gemeinsamer Ansatz

profitiert vom INGA Netzwerk von Konzepten zur Erstellung von Short-

cuts und der dynamischen Auswahl von Routingstrategien und vom Seman-

tic Gossiping Ansatz durch die ¨

Uberbr¨

uckung semantischer Heterogenit¨

aten

durch die Analyse der Anfrage und Resultate. Wir erwarten, das die Com-

munity sich diesem Thema in ihrer zuk¨

unftigen Forschung annehmen wird.



6.5. Zusammenfassung

6.5 Zusammenfassung

Dieses Kapitel stellt drei Beitr¨

age vor: Ein Ablaufmodell f¨

ur die Interaktionen ei-

nes Peers in einem Shortcut Netzwerk, Index Strategien f¨

ur die Aktualisierung be-

reits registrierter Shortcuts und die Kombination von Routing Strategien abh¨

angig

von den bereits an einem Peer registrierten Shortcuts.

Wir er¨

ortern den Zusammenhang zwischen Index- und Routing Strategien in

unserem Ablaufmodell. Durch jede von einem Peer selbst gestellte oder weiter-

geleitete Anfrage lernt der Peer neue Shortcuts zu anderen Peers kennen. Da der

Shortcut Index an einem Peer begrenzt ist, werden beim Registrieren neuer Short-

cuts bereits existierende Shortcuts zu Peers gel¨

oscht, die in der Vergangenheit nur

wenige Dokumente f¨

ur eine Anfrage geliefert haben oder in der Vergangenheit nur

auf wenige Anfragen antworten konnten oder zu Peers, die schlechter vernetzt sind.

Ausgehend von den registrierten Shortcuts im Index w¨

ahlt ein Peer die be-

sten Shortcuts f¨

ur eine Anfrage aus. Wir pr¨

asentieren einen Algorithmus, der zwi-

schen einer Fireworks, Greedy und High Out-Degree Strategie entscheidet. Zus¨

atz-

lich ber¨

ucksichtigt der Algorithmus in einer Serendipity Routing Strategie zuf¨

allig

gew¨

ahlte Peers, damit eine Anfrage auch an neu im Netzwerk registrierte Peers

gesendet werden kann.



Simulation und Evaluierung

Zur empirischen Auswertung der Algorithmen simulieren wir in einem rundenba-

sierten Simulator das Verhalten von INGA . Als realen Datensatz f¨

ur die Interessen-

Profile der Nutzer verwenden wir das Open Directory (DMOZ). Wir untersuchen

das Verhalten der einzelnen Shortcut Overlays und der Parameter des Index in ei-

nem statischen und dynamischen Netzwerk und vergleichen INGA gegen¨

uber der

naiven Strategie von Gnutella und einem aktuellen Ansatz auf der Basis von Short-

cuts.

7.1 Modellierung des Systems

In diesem Abschnitt stellen wir kurz die Eigenschaften unser Simulationsumge-

bung, wie die Verteilung und Dynamik der Themen und Anfragen, sowie den Auf-

bau und die Dynamik des Default Netzwerkes, vor.

7.1.1 Initiale Struktur des Netzwerkes

Ahnlich wie Gnutella modellieren wir das Default Netzwerk (siehe Abschnitt 4.2.3),

indem wir die Peers in einem Overlay Netzwerk anordnen. Jeder Peer verf¨

ugt

uber eine Menge von Nachbarn, mit denen er Nachrichten austauschen kann. Die

Verbindungen eines Peers zu seinen Nachbarn sind uni-direktional. Aufgrund der

Ausrichtung der Arbeit auf die Analyse von Anfragen, die gegen¨

uber den eigent-

lichen Dokumenten ein geringes Volumen aufweisen, ber¨

ucksichtigen wir nicht



7.1. Modellierung des Systems

die verf¨

ugbare Bandbreite f¨

ur eine Verbindung bzw. die Netzwerk Verz¨

ogerung

(Latency). Stattdessen beschr¨

anken wir uns auf das Messen der Anzahl der Nach-

richten f¨

ur eine Anfrage und der Anzahl der daf¨

ur ben¨

otigten Hops.

Zu Beginn einer Simulation verf¨

ugt jeder Peer nur ¨

uber die Nachbarn des Default

Networks, die wir f¨

ur die Simulation eines statischen Netzwerkes nicht ver¨

andern.

Verschiedene Studien [IRF04, ALPH01] haben gezeigt, das auch die initiale Ver-

teilung der Verbindungen zwischen Peers in File Sharing Netzwerken einer Power

Law Verteilung folgt und Small World Eigenschaften aufweist. In der Simulation

verwenden wir zur Generierung des Default Netzwerkes einen Small World Gene-

rator aus dem Java Universal Network/Graph Framework (JUNG) 1. Er generiert

ein Small World Netzwerk entsprechend dem Modell von Kleinberg [Kle00a], bei

der jeder Peer vier ’Short Range’ Verbindungen und einer ’Long Range’ Verbin-

dung aufweist. Die Wahrscheinlichkeit einer solchen Verbindung wird durch den

Clustering Exponent αausgedr¨

uckt, in unseren Versuchen verwenden wir α= 2.1.

Wir generieren 1024 Peers, von denen jeder ¨

uber genau f¨

unf ausgehende Verbin-

dungen zu benachbarten Peers und ’unbegrenzt’ eingehende Verbindungen verf¨

ugt.

7.1.2 Verteilung der Anfragen und Themen

Analog zu [SCK03, CGM02b, CFB04] nehmen wir an, das jeder Peer nur an

bestimmten Themen ein Interesse aufweist. Zur m¨

oglichst realistischen Model-

lierung der Anfragen und Themen pro Peer verwenden wir das Open Directory

(ODP)[DMO]. Es verf¨

ugt ¨

uber eine Sammlung und Kategorisierung von ca. f¨

unf

Millionen Webseiten in ca. 500.000 Kategorien, die Kategorisierung erfolgt durch

ca. 50.000 menschliche Autoren.2Wir verwenden f¨

ur unsere Simulation einen

Ausschnitt des Open Directories mit 1648 Kategorien der oberen f¨

unf Hierarchie-

Ebenen. Aus den 1624 unterschiedlichen Autoren w¨

ahlen wir zuf¨

allig 1024 Au-

toren aus, die jeweils einen Peer repr¨

asentieren. F¨

ur unsere Simulation weist das

ODP folgende interessante Eigenschaften auf:

•Semantische Beziehungen. Das ODP enth¨

alt ein kontrolliertes Vokabular,

d.h. eindeutige Benennungen (Deskriptoren ¨

uber eine Pfad-Angabe) f¨

ur je-

den Thema. Themen stehen in hierarchischen Relationen zueinander in Be-

zug. Landesspezifische Schreibweisen, Synonyme bzw. als gleichbedeutend

behandelte Quasi-Synonyme, Abk¨

urzungen, ¨

Ubersetzungen etc. werden durch

Aquivalenzrelationen miteinander in Beziehung gesetzt. Themen werden au-

ßerdem durch Assoziationsrelationen und hierarchische Relationen vernetzt.

1Java Klasse: edu.uci.ics.jung.random.generators.KleinbergSmallWorldGenerator

2Stand April 2004



7.1. Modellierung des Systems

Autoren 1 2 3 4 5 6 7 8 9 10 11 12 13 14 20 25 Σ

Themen 1217 274 80 30 14 10 3 8 1 2 2 1 1 1 1 1 1648

Abbildung 7.1: Verteilung der Autoren ¨

uber die Themen (Popularit¨

at der Themen).

Themen 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 18 20 22 Σ

Autoren 991 295 128 96 45 21 18 9 5 6 3 1 1 1 1 1 1 1 1624

Abbildung 7.2: Verteilung der Themen ¨

uber die Autoren

F¨

ur diese Arbeit verwenden wir ausschließlich die hierarchische Relationen

der Form Generalisierung/Spezialiserung.

•Zuordnung von Interessen zu Personen und Gruppen. Die Zuweisung von

Dokumenten zu Kategorien erfolgt durch menschliche Autoren, die ¨

uber

einen eindeutigen Schl¨

ussel identifiziert werden k¨

onnen. Wir modellieren

die Interessen eines Peers, indem wir die Themen eines Autors einem Peer

gleichsetzen.

Verteilung der Themen und Autoren. Die Popularit¨

at einzelner Themen ist im

Open Directory stark Zipf verteilt. Grafik 7.1 verdeutlicht diesen Zusammenhang:

1217 Themen werden jeweils von einem Autor bearbeitet, 274 von zwei Autoren

... 25 Autoren bearbeiten zusammen ein Thema. ¨

Ahnlich verh¨

alt sich die Anzahl

der Themen, die pro Autor bearbeitet werden, siehe auch Grafik 7.2: 991 Autoren

bearbeiten genau ein Thema, 295 Autoren bearbeiten zwei Themen, 128 Autoren

drei Themen ... ein Autor bearbeitet 22 Themen.

Ahnlich den Projektgruppen in einem Unternehmen entstehen Gruppen von

Peers, die sich gemeinsam f¨

ur ein Thema interessieren. Die maximale Anzahl der

Teilnehmer einer Gruppe betr¨

agt 24 Peers. Vergleichbar den Sachbearbeitern in

einem Unternehmen ist der Mehrzahl der Themen genau einem Peer zugeordnet.

Ahnlich verh¨

alt es sich mit der Anzahl der Themen an einem Peer. Wenige Peers

interessieren sich f¨

ur viele Themen, w¨

ahren die Mehrzahl der Peers sich f¨

ur genau

ein Thema interessiert.

Verteilung der Anfragen. Im INGA Netzwerk werden Recommender Shortcuts

und der Bootstrapping Index in Abh¨

angigkeit von den Anfragen aufgebaut und ver-

wendet. Um die Leistungsf¨

ahigkeit der Algorithmen besser beurteilen zu k¨

onnen,

untersuchen wir das Verhalten bei einer Gleichverteilung von Anfragen ¨

uber alle

Themen. F¨

ur die Indexing- und Routing Strategien ist eine gleiche Verteilung der

Popularit¨

at aller Themen besonders ung¨

unstig, da Anfragen f¨

ur ein Thema sich

nur selten wiederholen und bereits erstellte Shortcuts im Gegensatz zu einer Zipf



7.2. Methodik der Simulation

Verteilung, besonders wenig f¨

ur Anfragen von anderen Peers verwendet werden

k¨

onnen.

Eine weitere Verteilung der Anfragen wird in [VKMvS04] vorgeschlagen. Ein

Peer fragt ¨

uberwiegend Themen an, f¨

ur die er sich selbst interessiert. Zus¨

atzlich

fragt er zu einem kleineren Anteil zuf¨

allige Themen. Mit dem vorliegenden Da-

tensatz ergibt eine solche Verteilung einen unrealistisch hohen Recall, da f¨

ur viele

Themen genau nur der anfragende Peer Dokumente publiziert. Wir haben auf die

Darstellung dieses Szenarios verzichtet.

7.1.3 Modellierung von Dynamik

Verschiedene Studien [SGG03, CLL04, Mar02] zeigen, das Peer-to-Peer Netz-

werke eine hohe Volatilit¨

at aufweisen. ¨

Uberraschenderweise gibt es jedoch bis-

her keine Untersuchungen des Verhaltens von Shortcut-Ans¨

atzen in einem dyna-

mischen Netzwerk. Zur Simulation eines dynamischen Netzwerkes haben wir die

Verf¨

ugbarkeit der Peers auf der Basis der Studie von [SGG03] implementiert. Die

Studie untersucht das Verhalten von Peers in einem Gnutella und Napster Netz-

werk ¨

uber einen Zeitraum von zw¨

olf Stunden. W¨

ahrend dieser Zeit betr¨

agt die

durchschnittliche Verf¨

ugbarkeit eines Peers im Netzwerk ca. 60 Minuten. Ein Peer

startet alle 240 Sekunden eine Anfrage, was nach [LCC+02] einer QueryJoinRa-

tio von ca 15 entspricht. In unserer Simulation zeigen wir einen Zeitraum von 30

Anfragen pro Peer, was einer Simulation von zwei Stunden entspricht. Grafik 7.3

zeigt die kummulierte Verteilung (CDF) der Verf¨

ugbarkeit f¨

ur diesen Zeitraum.

Das Netzwerk ist durch eine hohe Anzahl von relativ dynamisch verf¨

ugbaren Peers

gekennzeichnet, 40% der Peers weisen eine maximale Verf¨

ugbarkeit von ca. 28%

auf. Aufgrund der durchschnittlichen Verf¨

ugbarkeit von einer Stunde weisen 26%

der Peers eine Verf¨

ugbarkeit von mehr als 90% auf. Wird ein l¨

angerer Zeitraum als

30 Anfragen oder zwei Stunden betrachtet, verringert sich der Anteil der Peers, die

eine hohe Verf¨

ugbarkeit aufweisen, weiter.

7.2 Methodik der Simulation

Wir simulieren das Verhalten der Peers auf der Basis eines runden-basierten Mo-

dels [SCK03, CFB04]. Tabelle 7.4 zeigt die Parameter der Simulation. F¨

ur jede

Runde werden 42 Peers zuf¨

allig ausgew¨

ahlt. Um eine Anfrage zu formulieren, wird

f¨

ur jeden gew¨

ahlten Peer das Thema der Anfrage bestimmt. Analog zu Gnutella

sendet der Peer die Anfrage an kNachbarn mit k= 2 ¨

uber bereits existierende

Shortcuts mit einer begrenzten TTL. Erh¨

alt ein Peer eine Anfrage zum ersten Mal,

vermindern wir die TTL der Anfrage und leiten die Anfrage an dessen ausgew¨

ahlte



7.2. Methodik der Simulation

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

0 102030405060708090100

Percentage

Peer Availability

Abbildung 7.3: Verteilung der Verf¨

ugbarkeit

Nachbarn weiter.

Die Auswahl der Shortcuts f¨

ur eine Anfrage erfolgt dynamisch auf Basis der

bereits im lokalen Index gespeicherten Shortcuts (siehe auch Algorithmus 5 in Ab-

schnitt 6.2). Ist noch kein Shortcut im Index vorhanden, sendet ein Peer eine An-

frage, indem er aus den verf¨

ugbaren f¨

unf benachbarten Peers des Default Network

Layers zwei Peers zuf¨

allig ausw¨

ahlt. Ist der gew¨

ahlte Peer bereits im Message Pfad

der Anfrage enthalten, tauschen wir diese mit einem anderen der f¨

unf Peers aus.

Wir simulieren insgesamt einen Zeitraum von 30.000 Anfragen ¨

uber 715 Run-

den, die f¨

ur insgesamt 1646 Themen gestellt werden. Um auch eine Dynamik der

Interessen zu simulieren, wird den Peers in der ersten Phase eine H¨

alfte der The-

men und in der zweiten Phase die zweiten H¨

alfte der Themen zugewiesen. Dadurch

beobachten wir, in wieweit die Aktualisierung der Indizes im Netzwerk nach der

Einf¨

uhrung neuer Themen erfolgt.

7.2.1 Metriken

Durch die Simulation wollen wir Erkenntnisse sammeln, wie sich INGA im Ver-

gleich zu anderen Ans¨

atzen verh¨

alt, welchen Einfluss die Parameter f¨

ur die Ge-



7.2. Methodik der Simulation

Parameter Wert

Simulierte Peers 1024

Durchl¨

aufe der Simulation 6

Auswahl Peers Pro Runde 42

Simulierte Runden 715

Themen 1646

Erste Phase 823

Zweite Phase 823

Anfragen 30.000

Anfragen pro Peer (gleichverteilt) 29

TTL der Anfrage 6

Ausgew¨

ahlte Peers pro Anfrage Peers (k) 2

Schranke f¨

ur Greedy Suche (tGreedy) 15 %

Zuf¨

allige Shortcuts (f) 20 %

Maximale Anzahl von Shortcuts im Index 40

Abbildung 7.4: In der Simulation verwendete Parameter

wichtung des Index und dessen Gr¨

oße und welchen Beitrag die einzelnen Layer

haben. Zur Messung der der Effizienz unserer Algorithmen verwenden wir folgen-

de Metriken:

•Query Recall. Wir verwenden den Recall um die Leistungsf¨

ahigkeit der Al-

gorithmen zu messen, z. B., in welchem Mass ein Peer Dokumente nur auf

der Basis von lokalem Wissen ¨

uber andere Peers finden kann.

Definition 7.2.1 (Query Recall). Der Query Recall definiert das Verh¨

altnis

der f¨

ur die Anfrage gefundenen, relevanten Dokumente gegen¨

uber der An-

zahl aller f¨

ur die Anfrage relevanten Dokumente. ♣

•Messages. Wir repr¨

asentieren die ben¨

otigten Kosten durch die Anzahl der

daf¨

ur ben¨

otigten Nachrichten. Die Anzahl der Nachrichten definiert eben-

falls indirekt ein Mass zur Ableitung der Skalierbarkeit des Systems.

Definition 7.2.2 (Messages). Wir z¨

ahlen alle Query Messages (siehe Defi-

nition 4.3.2) und alle Result Messages (siehe Definition 4.3.3). Deren Summe

bestimmt die Kosten f¨

ur die Anfrage. ♣

•Message Gain. ¨

Ahnlich dem Return on Investment (ROI) f¨

uhren wir den

Message Gain ein. Er beschreibt das Verh¨

altnis zwischen dem Recall f¨

eine Anfrage und der daf¨

ur ben¨

otigen Anzahl von Nachrichten.



7.2. Methodik der Simulation

Definition 7.2.3 (Message Gain). Wir definieren den Message Gain als den

Anteil der ben¨

otigten Nachrichten einer Anfrage im Verh¨

altnis zum erreich-

ten Recall.

MessageGain =#gefundene relevanteDokumente

#alle relevantenDokumente ×#Messages(7.1)

.♣

•Average Path Length. Analog zu Definition 4.2.1 messen wir die durch-

schnittlich k¨

urzeste Entfernung zwischen zwei Peers im Shortcut Overlay

Netzwerk. Eine kurze Average Path Length bedeutet einen schnellen, m¨

oglichst

direkten Informationsfluss. Sie erm¨

oglicht ein gezieltes Verteilen einer An-

frage mit einer geringen Anzahl von Hops, und damit geringere Netzwerk-

kosten, in einer geringen Zeit.

Definition 7.2.4 (Average Path Length). Sei G= (SC,P) ein Graph, der ein

Shortcut Netzwerk repr¨

asentiert. In Ggibt es NPeers Pmit |P|=N,

die ¨

uber Shortcuts SC miteinander verbunden sind. D(i, j)repr¨

asentiert

die L¨

ange in Hops des k¨

urzesten Pfades zwischen zwei Peers iund jmit

i, j ∈P. Die durchschnittliche k¨

urzeste Anzahl von Hops in G, bezeichnet

als AverageP athLength(G), wird definiert als:

AverageP athLength(G) = 1

2!X

i6=j

D(i, j)(7.2) ♣

7.2.2 Implementierung ¨

ahnlicher Systeme

In unseren Experimenten wollen wir uns ebenfalls mit existierenden Ans¨

atzen ver-

gleichen. Wir haben in der Simulation folgende zwei Strategien f¨

ur das Routing

implementiert:

Gnutella. Die Simulation verh¨

alt sich analog der Flutungsstrategie von Gnutel-

la 0.4 [Gnu04]. Jede Anfrage enth¨

alt die maximale Anzahl der Hops, die

sie weitergeleitet werden kann. Eine Anfrage wird an die, durch das Default

Netzwerk definierten, zuf¨

allig ausgesuchten Nachbarn weitergeleitet. Die Si-

mulation beinhaltet ebenfalls die Gnutella Duplicate Detection zur Erken-

nung von Peers, die bereits die Anfrage erhalten haben, so das diese die

Anfrage nicht erneut erhalten. Dazu wird einerseits der Query Message Path

analysiert und es werden in einem lokalem Cache die letzten Anfragen zwi-

schengespeichert.



7.3. Evaluierung

Interest-based Locality (IBL). Die Autoren von [SMZ03] verwenden ebenfalls

das Konzept der Interest-based locality um logische Overlays und Interessen-

basierte Shortcuts zu erzeugen. Ein Shortcut wird nach jeder erfolgreichen

Anfrage an einem Peer lokal gespeichert. Das Konzept ist analog zu Content

Provider Shortcuts. Die IBL-Suchstrategie unterscheidet sich jedoch von IN-

GA , da ein Shortcut nur f¨

ur das Routing ausgew¨

ahlt wird, wenn dieser exakt

mit der Anfrage ¨

ubereinstimmt. Andernfalls wird die Nachricht im Netzwerk

mit dem naiven Ansatz weitergeleitet. Als Index Strategie verwendet der An-

satz eine LRU Strategie [ADU71].

7.3 Evaluierung

7.3.1 Verhalten in einem statischen Netzwerk

Zur Simulation von Gnutella,IBL und INGA verwenden wir die in Tabelle 7.4

aufgef¨

uhrten Parameter. Wir simulieren zuerst ein statisches Netzwerk, bei dem

die Anfragen gleich verteilt sind.

Recall. Wir beobachten in Grafik 7.5 das INGA einen h¨

oheren Recall als die bei-

den anderen Ans¨

atze aufweist. W¨

ahrend der Recall der naiven Strategie wei-

testgehend konstant bleibt, steigt der Recall f¨

ur IBL und f¨

ur INGA , da ein

Peer Informationen ¨

uber anderen Peers in seinem lokalen Index speichert

und f¨

ur weitere Anfragen verwendet. Der gesteigerte Recall von INGA ge-

gen¨

uber IBL kann darauf zur¨

uckgef¨

uhrt werden, das einerseits mehr Short-

cuts innerhalb k¨

urzerer Zeit gespeichert werden und durch die dynamische

Auswahl der Routing Strategie deutlich weniger auf den Default Network

Layer zur¨

uckgegriffen werden muss. Nachdem zur H¨

alfte der Simulation

die Themen ausgetauscht werden, sinkt der Recall bei beiden Ans¨

atzen, da

die bereits gefunden Shortcuts nicht mehr den neuen Themen eines Peers

entsprechen. W¨

ahrend der Recall von IBL fast auf das Niveau des naiven

Ansatzes zur¨

uckf¨

allt, profitiert INGA vom Einsatz der Bootstrapping Peers.

Average Path Length. Grafik 7.6 zeigt die durchschnittliche Anzahl von Hops

zwischen zwei beliebigen Peers. W¨

ahrend der naive Ansatz eine statische

Netzwerk Struktur besitzt und ¨

uber eine konstante Anzahl von ca. sieben

Hops verf¨

ugt, verringert sich bei den beiden Shortcut Ans¨

atzen die Anzahl

der Hops mit der Anzahl der im Cache registrierten Shortcuts und stabilisiert

sich dann. Durch INGAs vier verschiedenen M¨

oglichkeiten, Shortcuts (Con-

tent, Aktive und passive Recommender, Bootstrapping und Default Short-

cuts) im lokalen Index zu registrieren, werden einerseits deutlich schneller



7.3. Evaluierung

0,05

0,1

0,15

0,2

0,25

0,3

0,35

0,4

0,45

0 5000 10000 15000 20000 25000 30000

Queries

Recall

INGA-40

IBL LRU-40

Naive

Abbildung 7.5: Recall: Statisches Netzwerk

und auch deutlich mehr Shortcuts zu unterschiedlichen Peers gewonnen, als

im Ansatz von IBL. Das ist darauf zur¨

uckzuf¨

uhren, das die Anzahl der be-

nachbarten Peers in INGA gr¨

oßer ist als in IBL. Sind die bei IBL ausgew¨

ahl-

ten besten Peers bereits im Message Pfad der Anfrage enthalten, sendet der

Ansatz die Anfrage immer an die gleichen Nachbarn. Im Gegensatz sucht

INGA in diesem Fall zus¨

atzlich Peers aus dem Recommender Layer und

dem Bootstrapping Layer aus. Dadurch stabilisiert sich die Anzahl der Hops

in INGA nach bereits f¨

unf Anfragen pro Peer auf durchschnittlich 35% und

in IBL nach 15 Anfragen auf ca 55 % des des naiven Ansatzes.

Messages. Die Verringerung der Pfadl¨

ange l¨

asst jedoch nur indirekte R¨

uckschl¨

usse

auf die Anzahl der Nachrichten pro Anfrage zu. Die Anzahl der Nachrichten

ist bestimmt durch die Anzahl kder Peers an die eine Anfrage lokal wei-

tergeleitet wird und durch die T T L der Nachricht. Beide Parameter sind in

allen Ans¨

atzen mit k= 2 und T T L = 6 identisch.

Die Anzahl der Nachrichten wird weiterhin bestimmt durch die entstehen-

de Netzwerk Struktur. Stehen weniger als zwei Peers f¨

ur die Auswahl zur

Verf¨

ugung wird im naiven Ansatz die Nachricht nur an einen oder gar keinen



7.3. Evaluierung

0 5000 10000 15000 20000 25000 30000

Queries

Average Path Length

INGA -40 IBL LRU-40 Naive

Abbildung 7.6: K¨

urzester Pfad: Statisches Netzwerk

Peer gesendet. In IBL wird eine Nachricht sowohl ¨

uber den Content Layer als

auch ¨

uber den Default Layer weitergeleitet, wodurch potentiell eine h¨

ohere

Wahrscheinlichkeit existiert, das zwei Peers f¨

ur eine Nachricht ausgew¨

ahlt

werden k¨

onnen. In INGA wird diese Wahrscheinlichkeit durch den Recom-

mender Layer, die Similarity Selection und den Bootstrapping Layer noch

weiter erh¨

oht. Bei beiden Shortcut Ans¨

atzen steigt die Anzahl der Nachrich-

ten zun¨

achst ¨

uber den naiven Ansatz an.

Grafik 7.7 zeigt das Verhalten der Nachrichten f¨

ur alle drei Ans¨

atze. Ein

Weiterleiten der Nachricht an benachbarte Peers wird in allen Ans¨

atzen be-

grenzt, da die Nachricht nicht an Peers weitergeleitet wird, die bereits im

Pfad der Query Message enthalten sind und die Nachricht bereits erhalten

haben. Die Wahrscheinlichkeit f¨

ur einen noch nicht angefragten Peer steigt

mit der Anzahl der im lokalen Index gespeicherten Shortcuts. Aufgrund der

verschiedenen Strategien f¨

ur die Erzeugung von Shortcuts werden im INGA

Netzwerk schneller Shortcuts gewonnen. Das bedeutet, dass eine Anfrage

mit einer hohen Wahrscheinlichkeit bereits zu den f¨

ur die Anfrage relevan-

ten Peers geleitet wurde. Der INGA Ansatz versucht in diesem Fall Boot-



7.3. Evaluierung

100

0 5000 10000 15000 20000 25000 30000

Queries

Messages

INGA-40 IBL LRU-40 Naive

Abbildung 7.7: Nachrichten: Statisches Netzwerk

strapping Peers auszuw¨

ahlen. Dadurch fokussieren sich die Anfragen auf

eine kleine Anzahl von Bootstrapping Peers, wodurch die Nachrichten auf

ca 75% des Niveaus der anderen beiden Ans¨

atze reduziert werden.

Die Strategie von IBL erzeugt zun¨

achst mehr Nachrichten, da die einzelnen

Peers untereinander Shortcuts aufbauen m¨

ussen. Da jeder Peer Shortcuts zu

verschiedenen Themen speichert, hat eine Anfrage eine geringe Wahrschein-

lichkeit zu einem Peer weitergeleitet zu werden, der die Anfrage bereits er-

halten hat. Nachdem jedoch gen¨

ugend Shortcuts gesammelt wurden, stabi-

lisiert sich die Anzahl der Nachrichten bei IBL auf das Niveau des naiven

Ansatzes. Das bedeutet, dass nach ca. 10 Anfragen pro Peer INGA geringe-

re Kosten f¨

ur eine Anfrage ben¨

otigt als IBL.

Message Gain. INGA verringert die Anzahl der Nachrichten und erm¨

oglicht einen

deutlichen h¨

oheren Recall. Grafik 7.8 quantifiziert die Leistungsf¨

ahigkeit des

Ansatzes gegen¨

uber der naiven und der Strategie von IBL durch das Verh¨

alt-

nis der aufgewendeten Nachrichten f¨

ur die Erh¨

ohung des Recalls (Message

Gain). Aufgrund der statischen Struktur des Netzwerkes bleibt der Messa-

ge Gain der naiven Strategie ¨

uber alle Anfragen auf dem gleichen Niveau,



7.3. Evaluierung

0,001

0,002

0,003

0,004

0,005

0,006

0,007

0 5000 10000 15000 20000 25000 30000

Queries

Message Gain

INGA-40 IBL LRU-40 Naive

Abbildung 7.8: Message Gain: Statisches Netzwerk

w¨

ahrend er f¨

ur die beiden Ans¨

atze mit Shortcuts steigt. Nach der H¨

alfte der

Anfragen steigt INGA aufgrund der reduzierten Nachrichten und des ge-

steigerten Recalls auf das sechsfache Niveau der naiven Strategie, w¨

ahrend

IBL nur etwas mehr als das zweifache Niveau erreicht. Beide Ans¨

atze fallen

bei der Aktualisierung der Themen stark ab und beginnen neue Shortcuts zu

sammeln. Dieser Prozess verh¨

alt sich ¨

ahnlich der ersten Phase, jedoch wer-

den neue Shortcuts langsamer gewonnen, da nicht mehr passende Shortcuts

lokal identifiziert und aus dem Index gel¨

oscht werden m¨

ussen.

7.3.2 Verhalten in einem dynamischen Netzwerk

Analog zum statischen Netzwerk vergleichen wir INGA mit der Strategie von

[SMZ03] und der naiven Strategie in einem dynamischen Netzwerk. Wir verwen-

den eine Index Gr¨

oße von 40 Eintr¨

agen und eine LRU Strategie. Ebenfalls verglei-

chen wir uns mit dem naiven Ansatz. Wir verwenden die bereits f¨

ur die statische

Simulation beschriebenen Parameter aus Tabelle 7.4 und verteilen die Anfragen

uniform.



7.3. Evaluierung

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0 5000 10000 15000 20000 25000 30000

Queries

Recall

Maximum Possible INGA-40 IBL LRU-40 Naive

Abbildung 7.9: Recall: Dynamisches Netzwerk

Recall. In einem dynamischen Netzwerk ist der maximal erreichbare Recall abh¨

angig

von den zum Zeitpunkt der Anfrage verf¨

ugbaren Dokumenten. In Grafik 7.9

bezeichnet der Graph Maximum Possible den maximal erreichbaren Recall

zum Zeitpunkt des Sendens einer Anfrage. Er liegt bei ca 55%. W¨

ahrend die

naiven Strategie sich nach 15 Anfragen pro Peer auf einen Recall von ca.

10% stabilisiert, w¨

achst bei IBL LRU-40 der Recall auf 17% und bei INGA

auf ca 25%. Der maximal erreichbare Recall zu diesem Zeitpunkt betr¨

agt

54%. Nach Einf¨

uhren neuer Anfragen f¨

ur alle Peers sinkt IBL LRU-40 auf

6% Recall ab, w¨

ahrend INGA auf 10% abf¨

allt. Zum Ende der zweiten Phase

der Simulation erreicht INGA wieder einen Recall von ca. 18%, IBL LRU-

40 von ca 13% und die naive Stratege 11 %. Das Anwachsen des Recalls in

der zweiten Phase der Simulation bei INGA wird durch den vollen Index zu

Beginn der zweiten Phase gebremst. Im Gegensatz zu Beginn der ersten Pha-

se muss jeder Peer in seinem Index unn¨

otige Eintr¨

age f¨

ur Shortcuts l¨

oschen

bevor neue Shortcuts gewonnen werden k¨

onnen.

Nachrichten. In Grafik 7.10 k¨

onnen wir beobachten, das der naiven Ansatz sich

bei 108 Nachrichten im dynamischen Netzwerk stabilisiert, w¨

ahrend im sta-



7.3. Evaluierung

100

120

0 5000 10000 15000 20000 25000 30000

Queries

Messages

INGA-40 IBL LRU-40 Naive

Abbildung 7.10: Nachrichten: Dynamisches Netzwerk

tischen Netzwerk (Grafik 7.7) nur 73 Nachrichten ben¨

otigt wurden. Analog

dem statischen Netzwerk ist auch im dynamischen Netzwerk die Anzahl der

Nachrichten durch die TTL und die Anzahl kder ausgew¨

ahlten Nachbarn

f¨

ur das Weiterleiten einer Nachricht bestimmt. F¨

ur TTL = 6 und k= 2

ergibt sich eine theoretisch m¨

ogliche Anzahl von P6

i=1 2i= 27−1 =

127 Nachrichten. Ebenfalls analog zum statischen Ansatz wird eine Anfra-

ge nicht mehr an Nachbarn weitergeleitet, die bereits im Pfad der Anfrage

enthalten sind und die Anfrage bereits erhalten haben. Im Gegensatz zum

statischen Netzwerk ver¨

andern sich jedoch die Nachbarn eines Peers im nai-

ven Ansatz und im Default Netzwerk durch die Volatilit¨

at der Peers im dyna-

mischen Netzwerk. Dadurch sind potentiell mehr Peers f¨

ur das Weiterleiten

einer Anfrage lokal w¨

ahlbar, wodurch die Anzahl der Nachrichten steigt.

Wir beobachten auch bei IBL LRU-40 einen Anstieg der Nachrichten im dy-

namischen (96 Nachrichten) gegen¨

uber dem statischen Netzwerk (72 Nach-

richten). Wir erkl¨

aren diese Steigerung mit demselben Effekt wie beim nai-

ven Ansatz. IBL LRU-40 baut jedoch zus¨

atzlich adaptive Shortcuts auf, wo-

durch Duplikate im Pfad der Anfrage auftreten k¨

onnen und eine Anfrage



7.3. Evaluierung

0,0005

0,001

0,0015

0,002

0,0025

0,003

0,0035

0,004

0,0045

0,005

0 5000 10000 15000 20000 25000 30000

Queries

Message Gain

INGA-40 IBS LRU-40 Naive

Abbildung 7.11: Message Gain: Dynamisches Netzwerk

nicht mehr weitergeleitet wird. Dadurch reduzieren sich die Nachrichten ge-

ringf¨

ugig gegen¨

uber dem naiven Ansatz.

Im Gegensatz zu dem naiven Ansatz und IBL LRU-40 reduziert INGA deut-

lich die Anzahl der Nachrichten, sowohl im statischen (58 Nachrichten)

und im dynamischen Netzwerk (59 Nachrichten). Diesen Effekt f¨

uhren wir

auf die unterschiedlichen Overlays, besonders auf den Bootstrapping Layer,

zur¨

uck. Durch die Fokussierung auf wenige Peers bei der Weiterleitung der

Anfragen ben¨

otigt INGA deutlich weniger Nachrichten, und damit Netz-

werkkosten, gegen¨

uber dem naiven Ansatz und IBL LRU-40.

Message Gain. ¨

Ahnlich dem statischen Netzwerk verringert INGA deutlich die

Anzahl der Nachrichten und erh¨

oht den Recall gegen¨

uber dem naiven An-

satz und IBL LRU-40. Grafik 7.11 zeigt den Leistungsgewinn f¨

ur alle drei

Ans¨

atze. W¨

ahrend f¨

ur den naiven Ansatz der Message Gain weitestgehend

konstant ist, steigt er f¨

ur IBL LRU-40 und INGA mit zunehmender Anzahl

von Anfragen an. INGA erreicht dabei etwas mehr als den zweifachen Wert

von IBL LRU-40 und eine ca. vierfache Steigerung gegen¨

uber dem naiven

Ansatz.



7.3. Evaluierung

100

120

0 5000 10000 15000 20000 25000 30000

Queries

Message

Content-40 Content-Recommender-40 INGA-40 Default

Abbildung 7.12: Message: Beitrag einzelner Layer im dynamischen Netzwerk

7.3.3 Beitrag der Layer und Einfluss der Index Parameter

Wir vermuten, das die Leistung von INGA von den verwendeten Overlays und von

der Index-Gr¨

oße und den Gewichtungen der einzelnen Index-Parameter abh¨

angt.

Im eine optimale Kombination zu bestimmen, untersuchen wir in diesem Abschnitt

das Verhalten von INGA in Simulationen mit verschiedenen Parametern.

Layer tragen unterschiedlich zur Leistungssteigerung bei. Im ersten Expe-

riment betrachten wir die Leistungsf¨

ahigkeit der einzelnen Overlays. Grafik 7.12

zeigt den Verbrauch von Nachrichten im Vergleich zum Default Layer. Content-40

verwendet dieselbe Strategie zum Erzeugen von Shortcuts wie IBL LRU-40 und

ben¨

otigt die meisten Nachrichten (ca. 92 Nachrichten). Content-Recommender 40

ben¨

otigt nur 63 Nachrichten, der Verbrauch steigt im Verlauf der Simulation auf

79 Nachrichten an. Wir erkl¨

aren diesen Effekt dadurch, das zuerst wenige Peers,

die besonders lange online sind, Recommender und Content Provider Shortcuts

aufbauen. Dadurch fokussieren sich die Anfragen auf wenige Peers. Durch die Du-

plikaterkennung im Pfad der Anfrage wird eine Anfrage nicht mehr weitergeleitet.

Mit weiteren Anfragen bauen auch Peers mit einer kurzen Sessiondauer Content-



7.3. Evaluierung

0,05

0,1

0,15

0,2

0,25

0,3

0,35

0 5000 10000 15000 20000 25000 30000

Queries

Recall

Content-40 Content-Recommender-40 INGA-40 Default

Abbildung 7.13: Recall: Beitrag einzelner Layer im dynamischen Netzwerk

und Recommender Shortcuts auf. Dadurch sinkt die Wahrscheinlichkeit, das ein lo-

kal ausgew¨

ahlter Peer bereits im Pfad der Anfrage enthalten ist und die Anzahl der

verbrauchten Nachrichten stabilisiert sich. In INGA -40 werden die Anfragen, f¨

die keine Content oder Recommender Shortcuts gefunden werden k¨

onnen, auf we-

nige Bootstrapping Peers fokussiert. Dadurch werden oft lokal Peers ausgew¨

ahlt,

die bereits im Pfad der Anfrage enthalten sind. Die Anfrage wird in diesem Fall

nicht weitergeleitet.

Grafik 7.13 zeigt den Recall f¨

ur jeden einzelnen Overlay. F¨

ur die Erh¨

ohung des

Recalls sind zwei Einflussgr¨

ossen ausschlaggebend: Die Fokussierung der Anfra-

gen auf wenige Peers senkt den Recall und die Menge von Shortcuts, die ein Peer

pro Anfrage ermittelt. Content-Recommender 40 hat den h¨

ochsten Recall. In die-

sem Layer tritt nur zu Anfang eine Fokussierung der Anfragen zu Peers mit einer

hohen Verf¨

ugbarkeit auf. Ein Peer ermittelt pro aktiver Anfrage zwei Shortcuts zu

zwei unterschiedlichen Peers und ermittelt zus¨

atzlich aus den Anfragen der ande-

ren Peers weitere Recommender Shortcuts. INGA -40 verwendet auch die passive

Recommender Strategie zur Registrierung von Shortcuts im Index. Einem h¨

oheren

Recall steht die Fokussierung der Anfragen auf Peers im Bootstrapping Netzwerk



7.3. Evaluierung

0,0005

0,001

0,0015

0,002

0,0025

0,003

0,0035

0,004

0,0045

0,005

0 5000 10000 15000 20000 25000 30000

Queries

Message Gain

Content-40 Content-Recommender-40 INGA-40 Default

Abbildung 7.14: Message Gain: Beitrag einzelner Layer im dynamischen Netz-

werk

entgegen. Dadurch werden potentiell weniger Nachrichten verschickt und auch we-

niger Peers angefragt. Content-40 verwendet keine Recommender Shortcuts. Ein

Peer registriert nur bei einer eigenen Anfrage Shortcuts zu Content Providern im

Index. Der Ansatz hat den Nachteil, das der Peer einerseits weniger Shortcuts ¨

uber

die Zeit ermittelt und der Ansatz tr¨

ager auf eine Volatilit¨

at im Netzwerk regiert,

da bereits registrierte Shortcuts erst identifiziert werden m¨

ussen und und dann

gel¨

oscht werden k¨

onnen.

Zwischen dem zu erreichenden Recall und dem Verbrauch von Nachrichten

muss ein Kompromiss eingegangen werden. Grafik 7.14 zeigt den Message Gain

als Mass f¨

ur den Kompromiss f¨

ur den Content Provider Overlay, den Content Pro-

vider und Recommender Overlay und INGA-40 im Vergleich mit dem naiven An-

satz, der durch den Default Layer dargestellt wird. Alle drei Shortcut Layer ver-

bessern deutlich den Message Gain mit der Anzahl der Anfragen. Deutlich erzielt

INGA die h¨

ochste Leistungssteigerung gegen¨

uber allen anderen Ans¨

atzen.



7.3. Evaluierung

0,001

0,002

0,003

0,004

0,005

0 5000 10000 15000 20000 25000 30000

Queries

Message Gain

INGA-100 INGA-20 INGA-40 INGA-All

Abbildung 7.15: Vergleich der Indexgr¨

osse im dynamischen Netzwerk

INGA arbeitet effizient mit einem kleiner Index-Gr¨

oße. Im folgenden Expe-

riment interessiert uns der Einfluss der Gr¨

oße des Index auf den Message Gain.

Dazu simulieren wir INGA mit einem unbegrenzten Index und mit einem Index

von 100, 40, 20 Shortcuts. Unsere Experimente zeigen, das ein begrenzter Index

sich analog einen unbegrenzten Index verh¨

alt. In Grafik 7.15 k¨

onnen wir beobach-

ten, das ein unbegrenzter Index zun¨

achst deutlich schneller einen hohen Message

Gain erreicht als ein begrenzter Index. Nach ca. 15 Anfragen erreichen der unbe-

grenzte Index und der Index mit 100 bzw. 40 Shortcuts ungef¨

ahr denselben Recall,

w¨

ahrend der zu stark begrenzte Index mit 20 Shortcuts nur ca. 75% des Message

Gains der anderen Graphen erreicht. In der zweiten Phase der Simulation steigt der

Message Gain des auf 100 und 40 Shortcuts begrenzten Index analog dem unbe-

grenzten Index an. Alle drei Indizes erreichen ungef¨

ahr den selben Message Gain

nach 30 Anfragen pro Peer.

Kombinierte Gewichtung der Index-Parameter ist ideal. In einer weiteren Si-

mulation untersuchen wir den Einfluss der Parameter f¨

ur den Index. Dazu haben

wir mehrere Simulationen mit verschiedenen, teilweise extremen, Gewichtungen



7.3. Evaluierung

0,0005

0,001

0,0015

0,002

0,0025

0,003

0,0035

0,004

0,0045

0,005

0 5000 10000 15000 20000 25000 30000

Queries

Message Gain

Community-40 Semantic-40 LRU-40

INGA-40 Equal-40

Abbildung 7.16: Vergleich der Indexewichtung

f¨

ur die in Abschnitt 6.3 vorgestellten Lokalit¨

aten durchgef¨

uhrt. In allen Versuchen

wurde eine Indexgr¨

osse von 40 Eintr¨

agen verwendet. Tabelle 7.1 zeigt die Index-

Parameter der einzelnen Simulationen. In Grafik 7.16 beobachten wir, dass nur

Simulation ID Semantisch Zeitlich Community

Community-40 0 0 10

Semantic-40 10 0 0

LRU-40 0 10 0

Equal-40 3 3 4

INGA -40 1 1 8

Tabelle 7.1: Index-Parameter und zugeordnete Simulationen

bei Community-40 und INGA -40 eine Steigerung des Message Gains erfolgt. Die

Autoren von [SMZ03] und [VKMvS04] schlagen den Einsatz einer LRU Strategie

f¨

ur Shortcut Netzwerke vor. Wir konnten diese Hypothse nicht best¨

atigen. Unse-

re Versuche zeigen, dass bei ausschließlicher Gewichtung der zeitlichen Lokalit¨



7.4. Zusammenfassung

LRU-40, der semantischen Lokalit¨

at Semantic-40 und bei gleicher Gewichtung al-

ler Lokalit¨

aten Equal-40 keine Steigerung des Message Gains zu beobachten ist.

Nur bei einer starken Gewichtung der Community Lokalit¨

at und einer geringf¨

ugi-

ge Gewichtung der semantischen und zeitlichen Lokalit¨

at steigt der Message Gain

an.

7.4 Zusammenfassung

Unser Hauptinteresse in diesem Kapitel galt der Identifikation einer effizienten

Routing Strategie auf der Basis lokalen Wissens und dem Vergleich unseres An-

satzes mit ¨

ahnlichen Arbeiten. Unsere Versuche zeigen, dass die Anwendung von

sozialen Metaphern auf das Routing in semantischen Peer-to-Peer Netzwerken er-

folgversprechend ist. Der Einsatz verschiedener Shortcut Indizes und Routing Stra-

tegien in INGA erm¨

oglicht ein effizienteres Routing von Nachrichten gegen¨

uber

der naiven Strategie und dem IBL Ansatz von [SMZ03]. Wir konnten in einem sta-

tischen und einem dynamischen Netzwerk sowohl den Recall deutlich steigern, als

auch die Anzahl der Nachrichten drastisch senken.

Ein weiterer wichtiger Aspekt unserer Versuche war die Identifikation von fol-

genden Prinzipien f¨

ur das Software Engineering von Shortcut Netzwerken:

Bootstrapping senkt Messages. Durch den Einsatz von Bootstrapping Shortcuts

werden Anfragen auf wenige Peers fokussiert. Dadurch sinkt der Verbrauch

von Nachrichten deutlich, aber auch geringf¨

ugig der Recall. Typische Sze-

nerien f¨

ur den Einsatz von Bootstrapping Shortcuts weisen eine hohe Red-

undanz der gesuchten Objekte und eine geringe verf¨

ugbare Bandbreite, wie

in Musik-Sharing Netzwerken, auf. F¨

ur die Desktop Suche innerhalb eines

Unternehmens oder zwischen virtuellen Organisationen mit gen¨

ugend vor-

handener Bandbreite sollten Bootstrapping Shortcuts nur bedingt eingesetzt

werden, da in diesen Szenarien ein hoher Recall ben¨

otigt wird und eine hohe

verf¨

ugbare Bandbreite vorausgesetzt werden kann.

Passive Recommender Shortcuts. Ein Peer sollte alle eingehenden Anfragen un-

tersuchen und passive Recommender Shortcuts speichern, auch wenn diese

nicht zu den zentralen Interessen des Peers geh¨

oren. Dadurch bildet sich

schnell ein Shortcut Netzwerk, von dem auch andere Peers profitieren. Durch

die Index Strategie werden zu einem sp¨

ateren Zeitpunkt unpassende Short-

cuts entfernt.

Analyse der Message Pfade. Aus dem Pfad der Anfrage gewinnen wir Informa-

tionen, wer die Anfrage gestellt hat und welche Peers bereits die Anfrage



7.4. Zusammenfassung

weitergeleitet haben. Kann ein lokaler Peer nur noch Shortcuts zu Peer aus-

suchen, die eine Anfrage bereits erhalten haben, wird die Anfrage nicht mehr

weitergeleitet. Dadurch sinkt der Verbrauch von Nachrichten im Netzwerk

drastisch.

Anfragespezifisch Shortcuts w¨

ahlen. Entsprechend [Mil67, Kle00a] w¨

ahlen wir

Shortcuts aus, die der Anfrage exakt entsprechen oder Shortcuts, die der An-

frage ¨

ahnlich sind. Finden wir in unserem lokalen Index keine passenden

anfragespezifischen Shortcuts, w¨

ahlen wir Shortcuts zu Peers, die gut ver-

netzt sind.

Community Lokalit¨

at zur Begrenzung des Index. Wir speichern vorwiegend Re-

commender Shortcuts zu einer breiten Anzahl von Themen, bis der Index

seine maximale Gr¨

oße erreicht hat. Dann konzentrieren wir uns vorwiegend

auf Shortcuts f¨

ur unsere eigenen Anfragen (Content Provider Shortcuts) und

entfernen Shortcuts zu entfernten Themen oder Recommender Peers. Die

Community eines Peers, seine direkten Nachbarn, bilden zu einem großen

Anteil die Peers, die in der Vergangenheit erfolgreich Dokumente f¨

ur eine

Anfrage liefern konnten.

Zusammenfassend k¨

onnen wir feststellen, das Shortcut zus¨

atzliche Overlays ¨

uber

dem Default Netzwerk Overlay abbilden. In diesen Overlay Netzwerken werden

Peers mit gleichen oder ¨

ahnlichen Interessen als Nachbarn gruppiert. Die entste-

henden Overlay Netzwerke sind adaptiv, das heißt Nachbarn werden bei wech-

selnden eigenen Interessen und ver¨

anderter Verf¨

ugbarkeit durch den INGA Algo-

rithmus ausgetauscht. Wir konnten zeigen, das Anfragen entlang der interessen-

spezifischen und adaptiven Overlays effizient in statischen und dynamischen Netz-

werken weitergeleitet werden k¨

onnen.



Teil III

Diskussion



Zusammenfassende Diskussion

In der vorliegenden Arbeit entwickelten wir drei Ans¨

atze, die eine effiziente Suche

mittels adaptiver Overlay Strukturen in Peer-to-Peer Netzwerken erm¨

oglichen und

technologisch praktikabel sind. Nach einer Zusammenfassung der Beitr¨

age dieser

Arbeit schließen wir mit einem Ausblick auf weitere interessante Forschungspro-

bleme.

8.1 Zusammenfassung

Der Beitrag dieser Arbeit war die Entwicklung einer Technologie f¨

ur die effiziente

Suche von Dokumenten in Peer-to-Peer Netzwerken. Die Charakteristiken dieser

Zielplattform erforderten die Entwicklung einer vollst¨

andig verteilten Technolo-

gie, die wechselnden Interessen und die Volatilit¨

at der Teilnehmer des Netzwerkes

toleriert und trotzdem mit hoher Effizienz und m¨

oglichst geringem Aufwand f¨

den einzelnen Nutzer die besten Peers f¨

ur eine Anfrage ausw¨

ahlt. Wir greifen kurz

die in der Einleitung formulierten Probleme auf und wiederholen ihre L¨

osungen,

wie sie in dieser Arbeit dargestellt wurden.

Architekturmodelle f¨

ur Overlay Netzwerken. Wir identifizierten in Kapitel 2 ty-

pische Charakteristiken potentieller Anwendungen der Informationssuche in

Peer-to-Peer Netzwerken. Exemplarisch analysierten wir die Anwendungs-

gebiete Legale Musiktauschb¨

orse und Semantisch vernetzte Arbeitspl¨

atze an-

hand der gefundenen Merkmale. Wir klassifizierten Peer-to-Peer Architek-



8.1. Zusammenfassung

turen f¨

ur die Informationssuche nach dem Grad der Zentralisierung und der

Struktur der Overlays. Wir ordneten die in dieser Arbeit vorgestellten Sy-

steme Edutella und TOPICS den Super-Peer basierten Systemen mit einem

strukturierten, globalen Index und das System INGA den semi-strukturierten

Systemen mit lokalen Indizes zu.

Ans¨

atze f¨

ur globale Indexstrukturen. In Kapitel 3 stellen wir Edutella und TO-

PICS als Beispiele f¨

ur strukturierte Overlay Netzwerke vor. Beide Ans¨

atze

verwenden einen globalen, vollst¨

andig verteilten Index zur Registrierung

der Profile einzelner Peers. Zur Verringerung der Nachrichten f¨

ur die Re-

gistrierung und f¨

ur Anfragen von Peers identifizierten wir in Edutella drei

Konzepte: statische Super-Peers, den HyperCup Broadcast Algorithmus und

einen zweigeteilten Routing-Index. Der TOPICS Ansatz verwendet zur Re-

duzierung der Nachrichten ebenfalls eine Super-Peer basierte Index Struktur.

Zur Abbildung und effizienten Anfrage der semantischen Beziehungen einer

Themen-Hierarchie speichern wir Konzepte als Schl¨

ussel und Beziehungen

als Objekte in einer verteilten Hashtabelle. Abschließend diskutieren wir

Nachteile strukturierter Overlays und stellen aktuelle Verfahren zur Lastver-

teilung vor.

Metaphern f¨

ur Interessen-basierte Overlays. In Overlay-Netzwerken mit einem

globalen Index wird das Profil des Nutzers an einem entfernten Peer regi-

striert. Der Nutzer verliert dadurch die Kontrolle ¨

uber sein Profil. Zus¨

atzlich

entstehen in volatilen Netzwerken hohe Kosten f¨

ur eine Aktualisierung des

Profils. Wir l¨

osten dieses Problem durch die Einf¨

uhrung lokaler Shortcut

Indizes. Zur Erstellung der Shortcuts definierten wir in Kapitel 4 folgende

soziale Metaphern: Eine Anfrage wird an eine Person gestellt, die diese An-

frage in der Vergangenheit bereits korrekt beantwortet hat (Content Provi-

der). Kennen wir keine Person, die eine ¨

ahnliche Anfrage in der Vergangen-

heit beantwortet hat, suchen wir nach Personen, die eine ¨

ahnliche Anfrage

in der Vergangenheit gestellt hat (Recommender). Kennen wir keine solchen

Personen, schicken wir die Anfrage zu einer Person, die bereits ein ’brei-

tes’ soziales Netzwerk zu anderen Personen entwickelt hat (Bootstrapping

Peer). Um neue Personen f¨

ur bereits bekannte Anfragen zu ermitteln, leiten

wir eine Anfrage zu einem geringen Anteil auch an die durch die initiale

Netzwerk Struktur vorgegebenen Nachbarn (Default Network) weiter. Wir

verwendeten diese Nachbarn ebenfalls, wenn wir noch keine Shortcuts auf-

gebaut haben.

Peer-to-Peer Architektur f¨

ur lokale Indexstrukturen. Auf der Basis unstruktu-

rierter Overlay Netzwerke definierten wir in Kapitel 4 eine neue Infrastruk-



8.1. Zusammenfassung

tur:INGA. In ihr repr¨

asentiert jeder Peer eine Person. Entsprechend den so-

zialen Metaphern speichert jeder Peer lokal Shortcuts, die abh¨

angig oder un-

abh¨

angig von dem konkreten Thema der Anfrage erzeugt werden. Zur ersten

Kategorie geh¨

oren Shortcuts zu Peers, die eine Antwort auf eine Anfrage ge-

ben konnten, Shortcuts zu Peers, die eine Nachricht weitergeleitet haben und

Shortcuts zu Peers, die eine Anfrage zu diesem Thema bereits in der Vergan-

genheit gestellt haben. Zur letzteren Kategorie geh¨

oren Shortcuts zu Peers,

die gut vernetzt sind, als auch Shortcuts zu zuf¨

allig ausgew¨

ahlten Peers.

Die verschiedenen Shortcuts in INGA repr¨

asentieren vier unterschiedliche

Typen von Overlay Netzwerken. F¨

ur jedes Overlay Netzwerk definierten wir

formal in Kapitel 4 die Struktur eines Shortcuts und die korrespondierende

Index Struktur.

Erzeugen von Overlay Netzwerken auf der Basis von Shortcuts. In Kapitel 5 ent-

wickelten wir neue Konzepte zur Erstellung von Recommender und Boot-

strapping Shortcuts. Unser Ziel war das vollst¨

andig automatisierte Finden

von relevanten Shortcuts ohne zus¨

atzlichen Aufwand f¨

ur den Nutzer. Wir

l¨

osten dieses Problem durch die Analyse der Resultate eigener Anfragen,

des transitiven Weges dieser Anfragen ¨

uber entfernte Peers sowie durch be-

obachten von Anfragen entfernter Peers, die durch den lokalen Peer weiter-

geleitet wurden.

Shortcuts werden in zwei lokalen Indizes gespeichert: ein Index f¨

ur Short-

cuts zum Default Network Layer, der den ’Index’ momentan existierender

unstrukturierter Netzwerke abbildet und ein erweiterter Index, der Content-,

Recommender- und Bootstrapping Shortcuts abbildet.

Algorithmen zur Auswahl der besten Shortcuts. Zur vollst¨

andig automatischen

Auswahl der besten Shortcuts f¨

ur eine Anfrage entwickelten wir in Kapitel

6 eine v¨

ollig neue Familie von Algorithmen. F¨

ur jeden der vier Typen von

Overlay Netzwerken entwickelten wir einen eigenen Algorithmus zur Aus-

wahl der besten Shortcuts f¨

ur eine Anfrage: Fireworks, TopGreedy, Top Boot,

Serendipity.

Zur Berechnung des Bootstrapping Rank entwickelten wir eine v¨

ollig neue

Metrik. Dazu ber¨

ucksichtigten wir die aktuelle Vernetzung eines Peers und

ermittelten den Bootstrapping Wert aus dem lokalen Shortcut Index.

Basierend auf den sozialen Metaphern entwickelten wir den ersten Algo-

rithmus, der f¨

ur eine Anfrage dynamisch den passenden Routing Algorith-

mus ausw¨

ahlt. Der Algorithmus Dynamic bevorzugt Routing Strategien die,

gezielt f¨

ur das Thema der Anfrage, exakt ¨

ubereinstimmende oder ¨

ahnliche



8.1. Zusammenfassung

Content Provider und Recommender Shortcuts ausw¨

ahlen. Wird kein pas-

sender Shortcut gefunden, greift der Algorithmus auf Bootstrapping Short-

cuts und zuletzt auf die Nachbarn des initialen Netzwerkes zur¨

uck.

Algorithmen f¨

ur die Pflege der lokalen Indizes. Die Auswahl von Shortcuts f¨

eine Anfrage und das L¨

oschen bereits registrierter Shortcuts beeinflussen

sich gegenseitig. Um zu entscheiden, welcher Shortcut nicht mehr im Index

verbleibt, entwickelten wir in Kapitel 6 eine neue Index-Strategie f¨

ur volati-

le Shortcut Netzwerke. Sie ordnet die Content und Recommender Shortcuts

und berechnet f¨

ur jeden Shortcut eine Relevanz. Die Shortcuts mit der ge-

ringsten Relevanz werden gel¨

oscht. F¨

ur die Berechnung der Relevanz ver-

wendeten wir drei Parameter: Wir untersuchten den Typ des Shortcuts und

gewichteten Content Provider Shortcuts doppelt so hoch wie Recommender

Shortcuts. Weiterhin ber¨

ucksichtigten wir die semantische ¨

Ahnlichkeit der

gefundenen Recommender Shortcuts zu unseren eigenen Anfragen. Schließ-

lich verwendeten wir den Zeitpunkt der letzten Aktualisierung eines Short-

cuts. Wir aktualisierten einen Shortcut, wenn wir ihn erfolgreich f¨

ur unsere

eigene Anfrage verwendeten.

Quantifizierung der Effizienz und Simulation volatiler Netzwerke. In Kapitel 7

simulierten wir INGA in einem dynamischen und einem statischen Netz-

werk. Wir erzeugten Volatilit¨

at sowohl durch wechselnde Interessen als auch

durch die unterschiedliche Verf¨

ugbarkeit der einzelnen Peers. Wir konnten

zeigen, dass der Einsatz verschiedener Shortcut Indizes und Routing Strate-

gien in INGA sowohl in einem statischen als auch einem dynamischen Netz-

werk eine drastische Steigerung des Recall und eine deutliche Senkung der

Anzahl der Nachrichten gegen¨

uber State-of-the-Art Ans¨

atzen erm¨

oglichte.

Durch zahlreiche Simulationen identifizierten wir f¨

ur das Software Enginee-

ring zuk¨

unftiger Applikationen auf der Basis von Shortcut Netzwerken fol-

gende grundlegende Prinzipien:

•Bootstrapping Shortcuts fokussieren die Anfragen und senken die Nach-

richten.

•Passive Recommender Shortcuts erlauben einen schnellen Aufbau des

Index und vermeiden dadurch einen cold start effect.

•Ein dynamisches Ausw¨

ahlen von Routing Strategien reduziert deutlich

Nachrichten.

•Eine LRU Index-Strategie allein ist ungeeignet f¨

ur Shortcut Netzwer-

ke und muss mit anderen Strategien wie Similarity oder Community



8.2. Perspektiven zuk¨

unftiger Forschung

kombiniert werden. Der Index sollte langfristig deutlich mehr Content

Provider Shortcuts als Recommender Shortcuts beinhalten.

Zusammenfassend k¨

onnen wir feststellen, das unsere L¨

osung der beschriebenen

Probleme eine einfache und robuste Technologie f¨

ur eine effiziente Suche in Peer-

to-Peer Netzwerken erm¨

oglicht. Unser Konzept der adaptiven Shortcut Overlays

erlaubt eine vollst¨

andig automatische Identifikation von Nachbarn im Netzwerk

mit ¨

ahnlichen oder gleichen Interessen und erfolgt nur auf Basis beobachteter An-

fragen. Der Vorteil gegen¨

uber existierenden Ans¨

atzen mit einem globalen Index

ist, dass kein zus¨

atzlicher Aufwand zur Publikation des Profils eines Peers ben¨

otigt

wird, da die Profile lokal beim Nutzer in einem Index gespeichert werden. Die

Profile entfernter Peers werden durch Beobachtung identifiziert und Peers mit ¨

ahn-

lichen Profilen im Overlay Netzwerk als Nachbarn angeordnet. Die von uns ent-

wickelten Algorithmen und Technologien tolerieren wechselnde Interessen und ei-

ne hohe Volatilit¨

at der einzelnen Peers. Trotzdem erm¨

oglichen sie ein effizientes

Routing von Anfragen. Obwohl das Problem bereits in einigen anderen Arbeiten

identifiziert wurde, stellt diese Arbeit die erste umfassende L¨

osung f¨

ur die Identifi-

kation von adaptiven Shortcut Overlays, deren Erstellung, deren Management und

dem effizienten Routing entlang von Shortcut Overlays zur Verf¨

ugung.

8.2 Perspektiven zuk¨

unftiger Forschung

Die in dieser Arbeit vorgestellten Methoden und Algorithmen bilden eine leistungs-

starke Basis zur Entwicklung von Peer-to-Peer Applikationen auf der Basis von ad-

aptiven Shortcut Overlays. Dennoch konnten wir in dieser Arbeit nicht alle Proble-

me dieser Applikationsdom¨

ane adressieren. Wir stellen kurz ausgew¨

ahlte zus¨

atzli-

che Problemstellungen vor und skizzieren potentielle Ansatzpunkte f¨

ur die weitere

Forschung.

Ausdrucksm¨

achtigkeit der Anfragen. Zuk¨

unftige Shortcut Overlays sollten die

Auswahl der ’besten’ Peers auch f¨

ur komplexe Anfragen unterst¨

utzen. Bei-

spielsweise m¨

ussen f¨

ur eine konjunktive Anfrage mit mehreren Termen Peers

ausgew¨

ahlt werden, die m¨

oglichst alle Terme der Anfrage unterst¨

utzen. Lo-

kale Indexstrukturen verf¨

ugen jedoch nur in Ausnahmef¨

allen ¨

uber alle daf¨

ben¨

otigten Informationen. Fehlt in der lokalen Indexstruktur die Zuordnung

eines Terms zu einem Peer bedeutet das entweder, dass der Peer keine Do-

kumente f¨

ur diesen Term bereith¨

alt oder aber, die wahrscheinlichere Annah-

me, dass bisher f¨

ur diesen Term an den Peer keine Anfrage gestellt wurde.

Es wird eine probabilistische Funktion ben¨

otigt, die trotz unzureichender

lokaler Informationen die besten Peers f¨

ur eine Anfrage ausw¨

ahlt. Derarti-



8.2. Perspektiven zuk¨

unftiger Forschung

ge Funktionen wurden bisher unzureichend f¨

ur Shortcut Netzwerke unter-

sucht, und sind Schwerpunkt aktueller Forschung. Arbeiten von [BMWZ05,

BMT+05, Coo04, CAPMN02] sammeln lokal Daten ¨

uber die Gewichtung

und Korrelation der Terme im Netzwerk und wenden Maße aus dem Infor-

mation Retrieval, wie CORI und Gloss, an.

Emergent Semantics. Zuk¨

unftige Peer-to-Peer Systemen werden entweder aus-

schließlich ¨

uber lokale oder ¨

uber globale und lokale Interpretationen von An-

fragen und Dokumenten verf¨

ugen. Durch unterschiedliche lokalen Interpre-

tationen m¨

ussen jedoch zus¨

atzliches semantische Vereinbarungen zwischen

dem anfragenden und dem antwortenden Peer vereinbart werden. Durch die

hohe Volatilit¨

at in einem Peer-to-Peer Netzwerk und der Autonomie der

einzelnen Peers ¨

andern sich diese Vereinbarungen zudem h¨

aufig. Dadurch

unterscheiden sich diese Systeme grunds¨

atzlich von Systemen mit vorde-

finierten Semantiken, bei denen die Interoperabilit¨

at durch eine statische

Komponente, wie eine globale Ontologie, fest beschrieben wird. Stattdessen

werden neu auftauchende semantische Vereinbarungen (emergent semanti-

cs) [ACMO+04] in einem Bottom-Up Konsens zwischen einzelnen Peers

gebildet. Dieser Prozess basiert auf den Interaktionen des Menschen mit der

Maschine und definiert iterativ neue semantische Vereinbarungen. Aktuel-

le Ans¨

atze dieses hochaktuellen Forschungsgebiets, wie [ACMH02], nutzen

den Pfad der Anfrage aus und beobachten die Resultate und Antworten f¨

eine Anfrage.

Personalisierung der Suchstrategien. Aktuelle Applikationen f¨

ur die Peer-to-Peer

Suche verwenden eine fest programmierte Strategie zur Suche. Viele Nut-

zer profitieren von der vordefinierten Prozess-Logik der Suche. Ein Nach-

teil dieses Ansatzes ist jedoch die schlechte Personalisierbarkeit des Such-

prozesses. Erfahrenere Nutzer wenden, zur Erh¨

ohung des Recalls oder der

Precision f¨

ur eine Anfrage, komplexe Sucheprozesse an, die mehrere unter-

schiedliche Anfragen beinhalten. Eine interessante Weiterentwicklung w¨

are

eine Komponente, die das Suchverhalten des Nutzers beobachtet und erken-

nen kann. In einem zweiten Schritt simuliert die Komponente zu einer An-

frage den nutzerspezifischen Suchprozess und schl¨

agt bei unzureichenden

Resultaten neue Anfragen vor, bzw. stellt diese automatisiert. Alternativ soll

die Komponente besonders erfolgreiche Suchstrategien anderer Peers dem

Nutzer vorschlagen bzw. anwenden.

Expertensuche in virtuellen Organisationen. INGA erlaubt die Identifizierung

’passender’ Peers f¨

ur eine Anfrage auf der Basis bereits beobachteter In-

teraktionen. Aufgrund der Un¨

ubersichtlichkeit und Un¨

uberschaubarkeit glo-



8.2. Perspektiven zuk¨

unftiger Forschung

bal agierender Unternehmen und virtueller Organisationen existiert dort das

Problem der Suche von geeigneten Personen f¨

ur eine Anfrage. In INGA

wird jeder Peer einer Person zugeordnet. Eine interessante Erweiterung w¨

are

die Optimierung der bestehender Methoden zur Identifikation von Peers, der

Auswahl von Peers bzw. der Verwaltung des Index mit dem Ziel einer An-

wendung, die Dokumente und passende Experten f¨

ur eine Anfrage identifi-

ziert.

Privacy Enhancement Technologien. Der Ansatz von INGA basiert auf einem

Netzwerk, bei dem jeder Peer Daten ¨

uber andere Peers sammelt. So beob-

achtet ein Peer sowohl die eigenen, als auch Anfragen und Resultate entfern-

ter Peers. Diese Informationen werden in einem lokalen Index gespeichert,

der wiederum von entfernten Peers gelesen werden kann. Sie erm¨

oglichen

eine Zuordnung von Peers zu Interessen und verbessern die Effizienz des

Routings. Auf der anderen Seite lassen sich diese pers¨

onlichen Daten auch

missbr¨

auchlich verwenden, beispielsweise zur Profilbildung der Peers und

deren Auswertung f¨

ur Spam Mails. Die Akzeptanz von Shortcut Netzwer-

ken in Unternehmen h¨

angt unter anderem von der Wahrung der Privatsph¨

are

ab. Zuk¨

unftige Technologien sollten einerseits die Privatsph¨

are eines Peers

bewahren und trotzdem die Effizienz des Netzwerkes nicht deutlich senken,

bzw. einen Kompromiss erlauben. INGA weist bereits mit der Lokalit¨

at der

Daten ein n¨

utzliches Designmerkmal auf. Der Ansatz erlaubt jedem Nutzer

lokal die Sicherheit der eigenen Shortcuts und Dokumente zu gew¨

ahrleisten

und erlaubt deren L¨

oschung aus dem Index ohne auf einen zentralen Server

zugreifen zu m¨

ussen. Zuk¨

unftige Technologien k¨

onnen diesen Prozess auto-

matisieren, die Identit¨

at des Peers anonymisieren oder lokale Shortcuts und

Dokumente nur ausgew¨

ahlten Peers zug¨

anglich machen.



Literaturverzeichnis

[AA04] Lada Adamic and Eytan Adar. How to search a social network.

Technical report, HP Labs, 1501 Page Mill RoadPalo Alto, CA

94304, 2004.

[Abe01] Karl Aberer. P-grid: A self-organizing access structure for p2p infor-

mation systems. In Sixth International Conference on Cooperative

Information Systems (CoopIS), Trento, Italy, 2001.

[ACMH02] Karl Aberer, Philippe Cudre-Mauroux, and Manfred Hauswirth. A

framework for semantic gossiping. SIGMOD Rec., 31(4):48–53,

2002.

[ACMO+04] Karl Aberer, Philippe Cudr´

e-Mauroux, Aris M. Ouksel, Tiziana

Catarci Mohand-Said Hacid, Arantza Illarramendi, Vipul Kashyap,

Massimo Mecella, Eduardo Mena, Erich J. Neuhold, Olga De Troy-

er, Thomas Risse, Monica Scannapieco, F`

elix Saltor, Luca de Santis,

Stefano Spaccapietra, Steffen Staab, and Rudi Studer. Emergent se-

mantics principles and issues. In 9th International Conference on

Database Systems for Advanced Applications (DASFAA), 2004.

[ADU71] Alfred V. Aho, Peter J. Denning, and Jeffrey D. Ullman. Principles

of optimal page replacement. J. ACM, 18(1):80–93, 1971.

[AGS02] Roberto J. Bayardo Jr.and Rakesh Agrawal, Daniel Gruhl, and Amit

Somani. Youserv: a web-hosting and content sharing tool for the

masses. In Proc. of the World Wide Web Conference, pages 345–

354, 2002.

[All96] James Allan. Incremental relevance feedback for information filte-

ring. In SIGIR ’96: Proceedings of the 19th annual international

ACM SIGIR conference on Research and development in informa-

tion retrieval, pages 270–278, New York, NY, USA, 1996. ACM

Press.



Literaturverzeichnis

[ALPH01] Lada A. Adamic, Rajan M. Lukose, Amit R. Puniyani, and Bernar-

do A. Huberman. Search in Power-law Networks. In Physical Re-

view E, 64 46135, 2001.

[ATS04] Stephanos Androutsellis-Theotokis and Diomidis Spinellis. A sur-

vey of peer-to-peer content distribution technologies. ACM Comput.

Surv., 36(4):335–371, 2004.

[BBK02] Magdalena Balazinska, Hari Balakrishnan, and David Karger. In-

s/twine: A scalable peer-to-peer architecture for intentional resource

discovery. In M. Balazinska, H. Balakrishnan, and D. Karger. In

Proceedings of Pervasive 2002., 2002.

[BCAA04] Marcelo Werneck Barbosa, Melissa Morgado Costa, Jussara M. Al-

meida, and Virglio A. F. Almeida. Using locality of reference to

improve performance of peer-to-peer applications. In WOSP ’04:

Proceedings of the fourth international workshop on Software and

performance, pages 216–227. ACM Press, 2004.

[BG03] D. Brickley and R. V. Guha. Resource Description Framework

(RDF) Schema Specification 1.0, 2003. http://www.w3.org/

TR/rdf-schema.

[BGK+02] Philip A. Bernstein, Fausto Giunchiglia, Anastasios Kementsietsi-

dis, John Mylopoulos, Luciano Serafini, and Ilya Zaihrayeu. Data

management for peer-to-peer computing: A vision. In Fifth Interna-

tional Workshop on the Web and Databases, Madison, Wisconsin,

June 2002.

[BKvH02] J. Broekstra, A. Kampman, and F. van Harmelen. Sesame: A generic

architecture for storing and querying RDF and RDF schema. In The

Semantic Web - ISWC 2002, volume 2342 of LNCS, pages 54–64.

Springer, 2002.

[Blo70] Burton H. Bloom. Space/time trade-offs in hash coding with allo-

wable errors. Commun. ACM, 13(7):422–426, 1970.

[BMB02] Dave Beckett, Eric Miller, and Dan Brickley. Expressing simple

dublin core in RDF/XML. Technical report, Dublin Core Metada-

ta Initiative, 2002. http://dublincore.org/documents/

2002/07/31/dcmes-xml/.



Literaturverzeichnis

[BMT+05] Matthias Bender, Sebastian Michel, Peter Triantafillou, Gerhard

Weikum, and Christian Zimmer. Improving collection selection with

overlap-awareness. In 28th Annual International ACM SIGIR Con-

ference on Research and Development in Information Retrieval (SI-

GIR05), pages –, Salvador, Brazil, 2005. ACM.

[BMWZ05] Matthias Bender, Sebastian Michel, Gerhard Weikum, and Chri-

stian Zimmer. The MINERVA project: Database selection in the

context of P2P search. In Gottfried Vossen, Frank Leymann, Pe-

ter Lockemann, and Wolffried Stucky, editors, Datenbanksysteme in

Business, Technologie und Web (BTW2005; 11. Fachtagung des GI-

Fachbereichs Datenbanken und Informationssysteme (DBIS)), volu-

me P-65 of Lecture Notes in Informatics, pages 125–144, Karlsruhe,

Germany, March 2005. Gesellschaft f¨

ur Informatik.

[CAPMN02] Francisco Matias Cuenca-Acuna, Christopher Peery, Richard P.

Martin, and Thu D. Nguyen. PlanetP: Using Gossiping to Build

Content Addressable Peer-to-Peer Information Sharing Communi-

ties. Technical Report DCS-TR-487, Department of Computer

Science, Rutgers University, September 2002.

[CFB04] Vicent Cholvi, Pascal Felber, and Ernst Biersack. Efficient search in

unstructured peer-to-peer networks. European Transactions on Te-

lecommunications: Special Issue on P2P Networking and P2P Ser-

vices, (15):535–548, November 2004.

[CGM02a] Arturo Crespo and Hector Garcia-Molina. Routing indices for peer-

to-peer systems. In International Conference on Distributed Com-

puting Systems, july 2002.

[CGM02b] Arturo Crespo and Hector Garcia-Molina. Semantic Overlay Net-

works for P2P Systems. Technical report, Computer Science De-

partment, Stanford University, 2002.

[CK01] E. Cohen and H. Kaplan. Refreshment policies for web content ca-

ches. In Proceedings of IEEE Infocom, 2001.

[CLL04] Jacky Chu, Kevin Labonte, and Brian Neil Levine. Availability and

popularity measurements of peer-to-peer file systems, technical re-

port. Technical report, University of Massachusetts, June 2004.



Literaturverzeichnis

[CMH+02] Ian Clarke, Scott G. Miller, Theodore W. Hong, Oskar Sandberg, and

Brandon Wiley. Protecting Free Expression Online with Freenet.

IEEE Internet Computing, 6(1):40–49, 2002.

[Coo04] Brian Cooper. Guiding queries to information sources with infobe-

acons. In ACM/IFIP/USENIX 5th International Middleware Confe-

rence, Toronto, 2004.

[Coo05] Microsft Cooperation. Microsoft Solutions for Small and Medium

Business- Peer-to-Peer Networking with Windows XP. Technical

report, 02/2005.

[CRB+03] Yatin Chawathe, Sylvia Ratnasamy, Lee Breslau, Nick Lanham, and

Scott Shenker. Making gnutella-like P2P systems scalable. In SIG-

COMM ’03: Conference on Applications, technologies, architectu-

res, and protocols for computer communications, pages 407–418.

ACM Press, 2003.

[CW04] Hailong Cai and Jun Wang. Foreseer: A Novel, Locality-Aware

Peer-to-Peer System Architecture for Keyword Searches. In ACM/I-

FIP/USENIX International Middleware Conference, volume 3231

of LNCS, 2004.

[DADA96] R. Dolin, D. Agrawal, L. Dillon, and A. El Abbadi. Pharos: A sca-

lable distributed architecture for locating heterogeneous information

sources. Technical Report TRCS96-05, 16, 1996.

[DF04] Stefan Decker and Martin Frank. The networked semantic desktop.

In WWW2004 Workshop Application Design, Development and Im-

plementation Issues in the Semantic Web, 2004.

[DFA00] R. DingleDine, M. Freedman, and D. Andmolnar. The FreeHaven

project: Distributed anonymous storage service. In International

Workshop on Design Issues in Anonymity and Unobservability. 67-

95, volume 2009 of Lecture Notes in Computer Science, 2000.

[DG89] J. L. Deneubourg and C. Gross. Collective patterns and decision

making. Ethology, Ecology, and Evolution, 1, 1989.

[DGH+87] Alan Demers, Dan Greene, Carl Hauser, Wes Irish, John Larson,

Scott Shenker, Howard Sturgis, Dan Swinehart, and Doug Terry.

Epidemic algorithms for replicated database maintenance. In PODC

’87: Proceedings of the sixth annual ACM Symposium on Principles

of distributed computing, pages 1–12. ACM Press, 1987.



Literaturverzeichnis

[DMO] The Open Directory Catalog. http://www.dmoz.org.

[DZW04] B. D. Davison, W. Zhang, and B. Wu. Lessons from a gnutella-

web gateway. In Thirteenth International World Wide Web Con-

ference Alternate Track Papers and Posters, pages 502–503, New

York, 2004. ACM Press.

[Exc04] Care Date Exchange. Company webseite.

http://www.carescience.com, 2004.

[FFK04] Andr´

e K¨

ohler Frank Fuchs-Kittwoski. Knowledge creating commu-

nities in the context of work processes. ACM SIGGROUP Bulletin,

23(3), 2004.

[FHKM04] F. Le Fessant, S. Handurukande, A.-M. Kermarrec, and L. Massou-

lie. Clustering in Peer-to-Peer File Sharing Workloads. In 3rd. IT-

PTS Workshop, 2004.

[FPV+98] James C. French, Allison L. Powell, Charles L. Viles, Travis Emmitt,

and Kevin J. Prey. Evaluating database selection techniques: A test-

bed and experiment. In Research and Development in Information

Retrieval, pages 121–129, 1998.

[GBL+03] Indranil Gupta, Ken Birman, Prakash Linga, Al Demers, and Rob-

bert van Renesse. Kelips: Building an efficient and stable P2P DHT

through increased memory and background overhead. In Procee-

dings of the 2nd International Workshop on Peer-to-Peer Systems

(IPTPS ’03), 2003.

[GBL+04] Godfrey, Brighten, Karthik Lakshminarayanan, Sonesh Surana, Ri-

chard Karp, and Ion Stoica. Load balancing in dynamic structured

p2p systems. In Proceedings of IEEE Infocom, Hong Kong, 2004.

[GDS+03] Krishna P. Gummadi, Richard J. Dunn, Stefan Saroiu, Steven D.

Gribble, Henry M. Levy, and John Zahorjan. Measurement, mode-

ling, and analysis of a peer-to-peer file-sharing workload. In SOSP

’03: Nineteenth ACM symposium on Operating systems principles,

pages 314–329. ACM Press, 2003.

[GGM95] Luis Gravano and H´

ector Garc´

ıa-Molina. Generalizing GlOSS to

vector-space databases and broker hierarchies. In International Con-

ference on Very Large Databases, VLDB, pages 78–89, 1995.



Literaturverzeichnis

[GMY02] Hector Garcia-Molina and Bervely Yang. Efficient search in peer-to-

peer networks. In International Conference on Distributed Comp-

ting Systems (ICDCS), 2002.

[Gnu04] The gnutella developer forum, http://rfc-gnutella.sourceforge.net,

2004.

[Gon01] Li Gong. Project jxta: A technology overview. Technical report, Sun

Microsystems Inc., 2001.

[GWJD03] Leonidas Galanis, Yuan Wang, Shawn R. Jeffery, and David J. De-

Witt. Locating Data Sources in Large Distributed Systems. In 29th

Conference on Very Large Data Bases (VLDB), 2003.

[HBM+04] P. Haase, J. Broekstra, M.Ehrig, M. Menken, P.Mika, M. Plechaw-

ski, P. Pyszlak, B. Schnizler, R. Siebes, S. Staab, and C. Tempich.

Bibster - a semantics-based bibliographic peer-to-peer system. In

Proceedings of the International Semantic Web Conference (ISWC),

2004.

[HIMT03] Alon Y. Halevy, Zachary G. Ives, Peter Mork, and Igor Tatari-

nov. Piazza: Data management infrastructure for semantic web ap-

plications. In Twelfth International World Wide Web Conference

(WWW2003), Budapest, Hungary, May 2003.

[HMSB87] Michael N. Huhns, Uttam Mukhopadhyay, Larry M. Stephens, and

Ronald D. Bonnell. Distributed Artificial Intelligence, chapter DAI

for document retrieval: The MINDS project, pages 249–283. Pit-

man/Morgan Kaufmann, 1987.

[IEE02] IEEE P1484.12 Learning Object Metadata Working Group.

Draft standard for learning object metadata. Technical re-

port, IEEE Learning Technology Standards Committee (LTSC),

2002. http://ltsc.ieee.org/doc/wg12/LOM_1484_

12_1_v1_Final_Draft.pdf.

[IF99] C. Kesselmann I. Foster. The Grid: Blueprint for a New Computing

Infrastructure. Morgan Kaufman Publishers, Inc. San Francisco, Ca-

lifornia, 1999.

[Ini04] Dublin Core Meta Data Initiative. Dcmi metadata terms. Technical

Report 2004-12-20, DCMI Usage Board, 2004.



Literaturverzeichnis

[IRF04] Adriana Iamnitchi, Matei Ripeanu, and Ian Foster. Small-World

File-Sharing Communities. In 23th. IEEE InfoCom HongKong,

2004.

[KAD+04] Pradnya Karbhari, Mostafa Ammar, Amogh Dhamdhere, Himanshu

Raj, George Riley, and El len Zegura. Bootstrapping in Gnutella: A

Measurement Study. In The 5th anuual Passive and Active Measu-

rement Workshop (PAM), LNCS, 2004.

[Kan99] Gene Kan. Peer-to-Peer: Harnessing the Power of Disruptive Tech-

nologies, chapter Gnutella, pages 94–122. O’Reilly, 1999.

[KBS02] Peter J. Keleher, Bobby Bhattacharjee, and Bujor D. Silaghi. Are

virtualized overlay networks too much of a good thing? In IPTPS

’01: Revised Papers from the First International Workshop on Peer-

to-Peer Systems, pages 225–231. Springer-Verlag, 2002.

[Kle98] Jon M. Kleinberg. Authoritative sources in a hyperlinked environ-

ment. In SODA ’98: Proceedings of the ninth annual ACM-SIAM

symposium on Discrete algorithms, pages 668–677, Philadelphia,

PA, USA, 1998. Society for Industrial and Applied Mathematics.

[Kle00a] John Kleinberg. Navigation in a small world. Nature, (406):845,

2000.

[Kle00b] Jon Kleinberg. The Small-World Phenomenon: An Algorithmic Per-

spective. In Proceedings of the 32nd ACM Symposium on Theory of

Computing, 2000.

[KNS04] Irwin King, Cheuk Hang Ng, and Ka Cheung Sia. Distributed

content-based visual information retrieval system on peer-to-peer

networks. ACM Trans. Inf. Syst., 22(3):477–501, 2004.

[KSS97] Henry Kautz, Bart Selman, and Mehul Shah. Referral Web: Combi-

ning social networks and collaborative filtering. Communications of

the ACM, 40(3):63–65, 1997.

[LBM03] Y. Li, Z.A. Bandar, and D. McLean. An Approach for messuring

semantic similarity between words using semantic multiple infor-

mation sources. In IEEE Transactions on Knowledge and Data En-

gineering, volume 15, 2003.



Literaturverzeichnis

[LCC+02] Qin Lv, Pei Cao, Edith Cohen, Kai Li, and Scott Shenker. Search and

replication in unstructured peer-to-peer networks. In ICS ’02: 16th

international conference on Supercomputing, pages 84–95. ACM

Press, 2002.

[LGH02] Alexander L¨

oser, Christian Grune, and Marcus Hoffmann. A didac-

tic model, definition of learning objects and selection of metadata

for an online curriculum. In International Workshop on Interactice

Computer Aided Learning (ICT), Villach, Austria, September 2002.

[LHH+04] B. Loo, J. Hellerstein, R. Huebsch, S. Shenker, and I. Stoica. En-

hancing p2p file-sharing with an internet-scale query processor. In

In Proc. of Int. Conf. on Very Large Databases (VLDB), Toronto,

2004.

[LNS+03] Alexander L¨

oser, Felix Naumann, Wolf Siberski, Wolfgang Nejdl,

and Uwe Thaden. Semantic Overlay Clusters in Super-Peer Net-

works. In International Workshop on Databases, Information Sy-

stems and Peer-to-Peer Computing in Conjunction with the 29th

VLDB, Berlin, Germany, 2003.

[LNWS03] Alexander L¨

oser, Wolfgang Nejdl, Martin Wolpers, and Wolf Si-

berski. Information Integration in Schema-Based Peer-To-Peer Net-

works. In 15th International Conference of Advanced Information

Systems Engieering (CAiSE 03), Klagenfurt, June 2003.

[LS99] O. Lassila and R. Swick. W3C Resource Description framework

(RDF) Model and Syntax Specification, 1999. http://www.w3.

org/TR/REC-rdf-syntax/.

[L¨

os04a] Alexander L¨

oser. Data Source Discovery in Educational P2P Net-

works. In Wladimir Uskov, editor, Proceedings of the IASTED Intl.

Conference on Web-Based Education (WBE). ACTA Press, 2004.

[L¨

os04b] Alexander L¨

oser. Towards Taxonomy-based Routing in P2P Net-

works. In The Second Workshop on Semantics in Peer-to-Peer and

Grid Computing at the 13. WWW Conference, New York, 2004.

[LST05] Alexander L¨

oser, Steffen Staab, and Christoph Tempich. Semantic

Methods for P2P Query Routing. In 3rd. German Conference on

Multi Agent Technologies (MATES), volume 3550 of LNAI. Springer,

2005.



Literaturverzeichnis

[LSZ04] Alexander L¨

oser, Kai Schubert, and Frederik Zimmer. Taxonomy-

Based Routing Overlays in P2P Networks. In 8th International Da-

tabase Engineering and Applications Symposium (IDEAS 2004), IE-

EE Computer Society, 2004.

[LT05] Alexander L¨

oser and Christoph Tempich. On Ranking Peers in Se-

mantic Overlay Networks. In 3rd Conference on Professional Know-

ledge Management, PAIKM’05 Workshop, 2005.

[LTQ+05] Alexander L¨

oser, Christoph Tempich, Bastian Quilitz, Wolf-Tilo

Balke, Steffen Staab, and Wolfgang Nejdl. Searching dynamic com-

munities with personal indexes. In 3rd. International Semantic Web

Conference (ISWC) Galway, 2005.

[LWSN03] Alexander L¨

oser, Martin Wolpers, Wolf Siberski, and Wolfgang Ne-

jdl. Efficient data store discovery in a scientific P2P network. In In-

terntl. Workshop on Semantic Web Technologies for Searching and

Retrieving Scientific Data, International Semantic Web Conference

(ISWC 2003), Sunibel Island, Florida, USA, October 2003.

[Mar02] Evangelos P. Markatos. Tracing a large-scale peer to peer system:

an hour in the life of gnutella. In 2nd IEEE/ACM International Sym-

posium on Cluster Computing and the Grid, 2002.

[MCR03] Manuel Costa Miguel Castro and Antony Rowstron. Should we

build Gnutella on a structured overlay? In 2nd Workshop on Hot

Topics in Networks (HotNets-II) Workshop Program. ACM SIG-

COMM, 2003.

[Mil67] Stanlay Milgram. The small world problem. Psychology Today,

67(1), 1967.

[MKL+02] Dejan S. Milojicic, Vana Kalogeraki, Rajan Lukose, Kiran Nagaraja,

Jim Pruyne, Bruno Richard, Sami Rollins, and Zhichen Xu. Peer-

to-peer computing. Technical report, HP Laboratories Palo Alto,

Technical Report HPL-2002-57, 2002.

[MSZ03] Shashidhar Merugu, Sridhar Srinivasan, and Ellen Zegura. Adding

Structure to Unstructured Peer-to-Peer Networks: The Role of Over-

lay Topology. In Group Communications and Charges: Technology

and Business Models. ICQT 2003 Proceedings, volume 2816. Sprin-

ger Verlag, 2003.



Literaturverzeichnis

[MT02] Vijay S. Mookerjee and Yong Tan. Analysis of a least recently used

cache management policy for web browsers. Oper. Res., 50(2):345–

357, 2002.

[Nap03] Napster. Napster company website. http://www.napster.com, 2003.

[Net04] Groove Networks. Groove Company Website.

http://www.groove.net, 2004.

[NS02] C. Ng and K. Sia. Peer clustering and firework query model. In

Poster Proceedings of 11th World Wide Web Conference, May 2002.

ACM Press, 2002.

[NT95] I. Nonaka and H. Takuechi. The Knowledge Creating Company.

Oxford University Press, 1995.

[NWQ+02] W. Nejdl, B. Wolf, C. Qu, S. Decker, M. Sintek, A. Naeve, M. Nils-

son, M. Palm´

er, and T. Risch. EDUTELLA: a P2P Networking In-

frastructure based on RDF. In Eleventh International World Wide

Web Conference (WWW2002), Hawaii, USA, May 2002.

[NWS+03] Wolfgang Nejdl, Martin Wolpers, Wolf Siberski, Alexander L¨

oser,

Ingo Bruckhorst, Mario Schlosser, and Christoph Schmitz. Super-

Peer-Based Routing and Clustering Strategies for RDF-Based Peer-

To-Peer Networks. In Twelfth International World Wide Web Confe-

rence (WWW2003), Budapest, Hungary, May 2003.

[NWS+04] Wolfgang Nejdl, Martin Wolpers, Wolf Siberski, Chrispoph

Schmitz, Mario Schlosser, Ingo Brunkhorst, and Alexander L¨

oser.

Super-Peer-Based Routing Strategies for RDF-Based Peer-to-Peer

Networks. In Elsevier’s Journal of Web Semantics, 2004.

[OCW03] MIT OpenCourseWare a free, open, publication of MIT Course Ma-

terials., 2003. http://ocw.mit.edu/index.html.

[OMA04] Open Mobile Alliance OMA. DRM Architecture Version 2.0. Tech-

nical report, July 2004.

[Ora01] Andy Oram, editor. Peer-to-Peer: Harnessing the Benefits of a Dis-

ruptive Technology. O´Reilly, Sebastopol (CA), 2001.

[RB03] M. Roussopoulos and M. Baker. Cup: Controlled update propaga-

tion in peer to peer networks. In Proceedings of the 2003 USENIX

Annual Technical Conference, June 2003.



Literaturverzeichnis

[RBR+04] Mema Roussopoulos, Mary Baker, David S. H. Rosenthal, Pe-

tros Maniatis TJ Giuli an, and Jeff Mogul. 2 p2p or not 2 p2p?

In Proceedings of the Third International Workshop on Peer-to-Peer

Systems, , San Diego, CA, USA, February 2004.

[RD01] Antony Rowstron and Peter Druschel. Pastry: Scalable, decentrali-

zed object location, and routing for large-scale peer-to-peer systems.

Lecture Notes in Computer Science, 2218:329–350, 2001.

[RFH+01] Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, and

Scott Shenker. A scalable content addressable network. In Confe-

rence on applications, technologies, architectures, and protocols for

computer communications. ACM Press New York, NY, USA, 2001.

[Rit01] Jordan Ritter. Why gnutella can’t scale. Technical report, Darkridge,

Inc., 2001.

[RKCD01] Antony I. T. Rowstron, Anne-Marie Kermarrec, Miguel Castro, and

Peter Druschel. SCRIBE: The design of a large-scale event notifi-

cation infrastructure. In Networked Group Communication, pages

30–43, 2001.

[RLS+03] Ananth Rao, Karthik Lakshminarayanan, Sonesh Surana, Richard

Karp, and Ion Stoica. Load balancing in structured p2p systems. In

International Workshop on Peer-to-Peer Systems (IPTPS), 2003.

[Sau03] Leo Sauermann. The Gnowsis, Using Semantic Web Technologies

to build a Semantic Desktop. Diplomarbeit, Technische Univerist¨

Wien, 2003.

[SCK03] Mario T. Schlosser, Tyson E. Condie, and Sepandar D. Kamvar. Si-

mulating a File-Sharing P2P Network. In First Workshop on Seman-

tics in P2P and Grid Computing, 12th. WWW Conference, Budapest,

2003.

[SGG03] S. Saroiu, P. K. Gummadi, and S. D. Gribble. A measurement study

of peer-to-peer file sharing systems. Multimedia Systems, 9(2), 2003.

[SHB97] Ruud Schoonderwoerd, Owen Holland, and Janet Bruten. Ant-

like agents for load balancing in telecommunications networks. In

AGENTS ’97: Proceedings of the first international conference on

Autonomous agents, pages 209–216. ACM Press, 1997.



Literaturverzeichnis

[SMK+01] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and

Hari Balakrishnan. Chord: A scalable peer-to-peer lookup service

for internet applications. In SIGCOMM ’01: Conference on Ap-

plications, technologies, architectures, and protocols for computer

communications, pages 149–160. ACM Press, 2001.

[SMZ03] Kunwadee Sripanidkulchai, Bruc Maggs, and Hui Zhang. Efficient

Content Location Using Interest Based Locality in Peer-to-Peer Sy-

stem. In Infocom. IEEE, 2003.

[Sri01] Kunwadee Sripanidkulchai. The popularity of gnutella queries and

its implications on scalability. Technical report, Technical Report,

Carnegie Mellon University, February 2001.

[SSDN02] Mario Schlosser, Michael Sintek, Stefan Decker, and Wolfgang Ne-

jdl. HyperCuP—Hypercubes, Ontologies and Efficient Search on

P2P Networks. In International Workshop on Agents and Peer-to-

Peer Computing, Bologna, Italy, July 2002.

[TAA+03] Bernard Traversat, Ahkil Arora, Mohamed Abdelaziz, Mike Dui-

gou, Carl Haywood, Jean-Christophe Hugly, Eric Pouyoul, and Bill

Yeager. Project JXTA 2.0 Super-Peer Virtual Network. Technical

report, Sun Microsystems Inc., 2003.

[TEF+04] Christoph Tempich, Marc Ehrig, Christiaan Fluit, Peter Haase, Este-

ve Llado Marti, Michal Plechawski, and Steffen Staab. Xarop:

A midterm report in introducing a decentralized semantics-based

knowledge sharing application. In Practical Aspects of Knowledge

Management: 5th International Conference, PAKM 2004, Vienna,

Austria, number 3336 in Lecture Notes in Computer Science, 2004.

[tPW05] SnoCap Peer to Peer Website. http://www.snocap.com/, 2005.

[Tra04] Bernard Traversat. JXTA Technology: Creating Connected Commu-

nities. Technical report, Sun Microsystems, Inc., 2004.

[TSW04] Christoph Tempich, Steffen Staab, and Adrian Wranik. REMIN-

DIN:Semantic Query Routing in Peer-to-Peer Networks based on

Social Metaphers. In Proceedings of the 13th WWW Conference

New York. ACM, 2004.

[VKMvS04] Spyros Voulgaris, Anne-Marie Kermarrec, Laurent Massoulie, and

Maarten van Steen. Exploiting semantic proximity in peer-to-peer



Literaturverzeichnis

content searching. In International Workshop on Future Trends in

Distributed Computing Systems (FTDCS), 2004.

[Vz99] P. Valduriez and M. ¨

Ozsu. Principles of distributed database sy-

stems. Prentice Hall, 2nd edition edition, 1999.

[W3C03] W3C. Xpath definition, technical report.

http://www.w3c.org/TR/xpath, 2003.

[Wat03] Duncan J. Watts. Six Degrees - The Science of a Connected Age.

Norton and Company, 2003.

[Web04] Herbert Weber. Future net. Informatik Spektrum, 27(1), 2004.

[YGM03] Beverly Yang and Hector Garcia-Molina. Designing a super-peer

network. In International Conference on Data Engineering (ICDE),

March 2003.

[YRS02] Y.Chawathe, S. Ratnasamy, and S. Shenker. Can heterogeneity ma-

ke gnutella scale? http://research.att.com/ yatin/publications/, May

2002.

[Zim04] Frederick Zimmer. Effziente Routingstrategien f¨

ur Semantic Over-

lay Cluster. Master’s thesis, CIS, Technische Universit¨

at Berlin,

2004.

[Zip49] G. K. Zipf. Human Behaviour and the Principle of Least Effort.

Addison-Wesley Press, 1949.

[ZKJ01] B. Zhao, J. Kubiatowicz, and A. Joseph. Tapestry: An infrastruc-

ture for fault-tolerant wide-area location and routing. Technical Re-

port UCB/CSD-01-1141, Computer Science Division, U. C. Berke-

ley, April 2001.

