EXTENDING TUPLE SPACES TOWARDS A MIDDLEWARE FOR

ANALYSE UND KONZEPTION VON
TUPLE SPACES IM HINBLICK AUF
SKALIERBARKEIT
Philipp Obreiter
Telecooperation Office (TecO)
Universitaet Karlsruhe
Betreuer: Guntram
Gräf, Martin Gaedke
Ziele
Skalierbarer Tuple Space
– ohne zusätzliche Beschränkungen
– minimale Zahl zusätzlicher Informationen
Vorgehen:
• Formalisierung/Klassifikation von Tupeln
• Analyse bisheriger Indexverfahren
• Herleitung eines neuen Indexverfahrens
• Konzeption der Architektur/Implementierung
eines skalierbaren Tuple Spaces
Fieldhierarchie (F,matchF)
F
int
1234
string
5678
“Hello“
“World“
Tupelhierarchie (,match)

(int,F)
(int,(int,int))
(F, string)
(int,string)
(1234,(56,78))
(1234,string)
(F,“Hello“)
(int,“Hello“)
(5678,“Hello“)
Taxonomie von Schemata
• Freiheitsgrade:
(A) Klassenhierarchie
(B) Instanzhierarchie
(C) Semantische Tupel
(D) Verschachtelte Tupel
(E) Tupelhierarchie
• Schema ABCDE schränkt Freiheitsgrade ein
Linda Schema: 23111
A
0
1
B
0
E
2
1
2
3
1
1
C
0
0
1
0
D
TSpaces/JavaSpaces Schema: 00110
A
0
1
B
0
E
2
1
2
3
1
1
C
0
0
1
0
D
Verteilungsmodell
• Menge von p Servern {1,...,p}
• Verteilung (W,R) für Tupel t
– schreibt auf W(t) {1,...,p}
– liest von R(t) {1,...,p}
1
2
3
R
 Korrektheitsbedingung
match(t1,t2)  W(t2)  R(t1)  
4
W
5
6
Konzeption einer Verteilung
W(t)
t
t
R(t)
direkt
abstrakte
Darstellung
W(t)
R(t)
indirekt
Abstrakte Darstellung
– entkoppelt Abstraktionsvorgang und Anpassung an p
– ist effiziente Datenstruktur
Hashindizierung (I)
{1,...,p}

(F)
{1,...,p}F,F)
(printer,
{1,...,p}
(F,1200dpi,
F)
{1,...,p}
(printer,1200dpi,
F)
{1}
P1
{5}
P2
{1,...,p} F,F)
(scanner,
{1,...,p}
(scanner,1200dpi,
F)
{1,...,p}
(F,1200dpi,x.x.x.x
)
{6}
P3
{2}
S3
{8}
P4
{3}
P5
{12}
S1
{5}
S2
{7}
S4
{8}
S5
Hashindizierung (II)
{1,...,p}

(F)
{1,...,p}F,F)
(printer,
{1,...,p}
(F,1200dpi,
F)
{3}
(printer,1200dpi,
F)
{3}
P1
{3}
P2
{1,...,p} F,F)
(scanner,
{7}
(scanner,1200dpi,
F)
{1,...,p}
(F,1200dpi,x.x.x.x
)
{3}
P3
{7}
S3
{3}
P4
{3}
P5
{7}
S1
{7}
S2
{7}
S4
{7}
S5
Indizierung durch Hyperquader
• Fields:
– hierarchische Struktur  Intervalle statt Punkte
– Korrektheit: matchF(f1,f2)  F(f2)  F(f1)
• Tupel:
– Tupel komplex  mehrdimensionaler Index
– induziert Trafo  auf Hyperquader
• Verteilung:
– Aufteilung des Hyperraums in Tupeldomänen 1,... p
– (,) zulässig mit (t) := {q | q(t)   }
disjunkte/vollständige
Tupeldomänen
x1
2
5
T6
4
T4
1
3
T5
2
4
1
T1
-1
3
0
1
5
T3
T2
2
3
4
5
x2
überlappende/unvollständige
Tupeldomänen
x1
5
T6
4
T4
3
T5
2
1
3
T3
1
T1
-1
2
T2
0
1
2
3
4
5
x2
Komponenten der Architektur
F -Server
Agentenserver
 -Server
Agent
Agent
Agent
Client
Client
Client
t
(t)
(t)
Tuple
Tuple
Tuple
Tuple
Space
Space
Space
Space
Server
Server
Server
Server
F-Server
Fieldhierarchie nicht a priori bekannt
 Aufgaben des F-Server:
• Bereitstellen der Klassendefinitionen
• Adaptive Trafo von Fields auf Intervalle
– für 12 automatisierbar durch relative Intervalle
? Garbage collection von Indexbereichen
-Server und Tuple Space Server
• Tupeldomänen müssen adaptiv sein
• Überlauf eines TS Servers:
– Teil der Tupel auf freien TS Server verschieben
– Einblenden der neuen Tupeldomänen
• Unterlauf eines TS Servers:
– lokale Vereinigung (mit Buddy)
– Delegation oder Sperren
• Extended k-d tree als Tupeldomänenbaum
Cache-Validation der Agenten
• F-Server:
– Lesecache, also stets gültig
• -Server:
– Unterbäume tragen Sequenznummern
– Cacheeintrag invalidiert, wenn mit veralterter
Sequenznummer auf TS Server zugegriffen
 Extended k-d tree garantiert Korrektheit
SATUS
•
•
•
•
•
Implementierung eines skalierbaren Tuple Spaces
Management Schnittstelle
Erweiterung auf 4-tier Architektur
Eingebaute Standardfields
Validiert hinsichtlich:
– Effizienz der Verteilung
– Effizienz der Tupeldomänenadaption
Adaption der Tupeldomänen
Response time
2.5
2
1.5
1
.5
0
50
100
150
200
250
300
350
400
n
Fazit?
Vorgehen:
• Formalisierung/Klassifikation von Tupeln
• Analyse bisheriger Indexverfahren
• Herleitung eines neuen Indexverfahrens
• Konzeption der Architektur/Implementierung
eines skalierbaren Tuple Spaces
Skalierbarer Tuple Space?
– ohne zusätzliche Beschränkungen?
– minimale Zahl zusätzlicher Informationen?
Fragen?
Verschachtelte Tupel
• Field selber komplex, daher Indizierung nicht
direkt anwendbar
• Bei beschränkter Schachtelungstiefe unnesten
• Aufteilung in mehrere Tupel (Atomizität?)
• Aufnahme komplexer Klassen in die
Fieldhierarchie
Skalierbarkeit
Fünf Dimensionen:
• Größe der Tupel
• Zahl der Tupel im Tuple Space
• Zahl der eingesetzten Tuple Spaces
• Durchsatz des Tuple Spaces
• Zahl der Clients
Fieldhierarchie
F
x modulo y
fraction
x modulo 3 x modulo 5
0
0
1
2
4
1/2
2/4
6/9
4/6
1
3
2
Tupeldomänenbaum
x2 = 0
2
x1 = 2
x1 = 4
x2 = 3
4
5
3
2
Adaptive Trafo
f1
[0,100] z=0.3
[0,30][30,100]
i11
[0,0]
[0,0]
i12
f2
[45,100] z=0
z=1
[30,44][44,44]
[45,45]
[45,100]
size=0.2
[0.1,0.2]
size=0.8
f4
i21
i22
[45,100] z=0.6
[30,37]
[38,42]
[45,78]
[78,100]
size=1
[0,0.5] [0.6,0.9]
[10,20]
[30,44]
f3
Rate
Effizienz der Verteilung
1
.8
pruning
rate
.6
.4
.2
0
50
100
150
200
250 300
350
400
overhead
n
450 500