Freie Universit¨at Berlin
Fachbereich Mathematik und Informatik Institut f¨ur Informatik
Takustr. 9 D-14195 Berlin
Seminararbeit
Eine skalierende Lindaimplementation basierend auf Schw¨ armen:
Swarm-Linda
Riad Djemili
djemili@inf.fu-berlin.de
Minh Tuan Nguyen
mtnguyen@inf.fu-berlin.de
SoSe 2003
betreut durch Prof. Robert Tolksdorf
Inhaltsverzeichnis
1 Einf¨uhrung 3
2 Lindasysteme 4
2.1 Tupelr¨aume als Middleware . . . 4
2.2 Operationen . . . 5
3 Implementationsarchitekturen 7 3.1 Zentralisierung . . . 7
3.2 Partitionierung . . . 7
3.3 Replikation . . . 8
3.4 Intermediate Replication . . . 9
4 Swarm-Linda 9 4.1 Swarm Intelligence . . . 10
4.2 Swarm-Linda Algorithmen . . . 11
4.2.1 Tupelsuche . . . 11
4.2.2 Verteilungsalgorithmus . . . 14
4.2.3 Anpassung an die Umwelt . . . 16
4.2.4 Aktive und passive Ameisen . . . 17
5 Bewertung 21 5.1 Skalierbarkeit . . . 22
5.2 Anpassungsf¨ahigkeit und Fehlertoleranz . . . 22
5.3 Lastverteilung . . . 22
6 Konklusion 22
Tupelr¨aume in Lindasystemen haben sich als einfaches und m¨achtiges Bin- deglied f¨ur Komponenten verteilter Anwendungen erwiesen. Dennoch bleibt vorallem das Problem der Skalierbarkeit nur unbefriedigend gel¨ost. Swarm Intelligence hat in den letzten Jahren als Teildisziplin der k¨unstlichen Intel- ligenz zunehmends an Bedeutung gewonnen. Schwarmbasierte Algorithmen gelten als flexibel und hochskalierend. Wir betrachten in dieser Abeit des- halb, basierend auf einer Arbeit von Menezes und Tolksdorf [5], wie sie sich zur Entwicklung einer neuen Lindaimplementation, genannt Swarm-Linda, nutzen lassen.
1 Einf¨ uhrung
Das Internet hat massiv dazu beigetragen, dass die Bedeutung verteilter Programme in der modernen Informatik stark zugenommen hat. Dabei ist abzusehen, dass sowohl die Komplexit¨at, als auch die Gr¨osse dieser Systeme weiter stark anwachsen wird. Lindasys- teme haben sich hier bereits als einfaches und doch m¨achtiges Paradigma zur Abstrakti- on der Kommunikationsebene etabliert. Allerdings bleibt der Aspekt der Skalierbarkeit nicht befriedigend gel¨ost. Zuk¨unftige Systeme erforden hochskalierendes Verhalten, dem heutige Lindasysteme nicht gewachsen scheinen.
Ein neuer Ansatz k¨onnte sich aus der Swarm Intelligence ergeben. Die Forschung in diesem Gebiet deutet auf Algorithmen mit hoch interessanten Eigenschaften, vorallem bzgl. der Skalierbarkeit hin. Menezes und Tolksdorf nutzen diese Erkenntnise, um in ihrer Arbeit [5] Vorschl¨age zur Entwicklung einer skalierenden Lindaimplementation zu machen. Ihre Ans¨atze sollen in dieser Arbeit widergegeben werden.
Im folgenden geben wir in Abschnitt 2 zun¨achst eine allgemeine Einf¨uhrung zu Lin- dasystemen. In Abschnitt 2.1 erw¨agen wir dazu das allgemeine Paradigma von Linda im Einsatz als Middleware und betrachten in Abschnitt 2.2 die genaue Interaktion mit Tupelr¨aumen.
Danach benennen wir in Abschnitt 3 vier klassische Implementationsarchitekturen ¨ubli- cher Lindaimplementation, die von Meneszes und Tolksdorf ausgemacht wurden und weisen auf deren Nachteile, vorallem im Bereich der Skalierbarkeit hin.
Anschliessend betrachten wir in Abschnit 4 einleitend allgemeine Erkenntnisse aus dem Forschungsbereich der Swarm Intelligence, um dann schließlich im Abschnitt 4.2 die Algorithmen von Menezes und Toksdorf darzulegen. Dies soll der Hauptaspekt dieser Arbeit sein.
Wir schließen mit einer Bewertung (Abschnitt 5) und Konklusion (Abschnitt 6) ab.
2 Lindasysteme
Linda wurde von der Linda Yale Group entworfen und ist eine gezielt einfache Kom- munikationssprache, die C und Fortran um Befehle zur Interaktion mit einem globalen virtuellen Speicher erweitert [1]. Dieser Speicher, genannt Tupelraum (Tuple Space), dient als Beh¨alter f¨ur Tupel, die hier analog zur mathematischen Entsprechung als Liste von getypten Feldern definiert sind und stellt den Mittelpunkt jedes Lindasystems dar.
2.1 Tupelr¨aume als Middleware
In ¨ublichen verteilten Applikationen kommunizieren die Komponenten direkt ¨uber soge- nannte Remote-Procedure-Calls (RPC’s) oder andere standardisierte entfernte Aufrufe, wie zB. Webdienste. Dies erfordert, dass alle Komponenten, die miteinandern interagie- ren wollen, voneinander auch unmittelbar Kenntnis haben m¨ussen. Ein entsprechendes Kommunikationsprotkoll erfordert einen hohen und komplexen Verwaltungsaufwand.
F¨ur diese Systeme stellen Tupelr¨aume, durch ihre synchronisierten Zugriffsmechanismen, eine Alternative dar, indem er als Bindeglied zwischen den Komponenten fungiert und deren Kommunikation stark vereinfacht.
Der Einsatz von Linda alsMiddleware besitzt die folgenden Hauptvorteile.
Abbildung 1: Tupelraum als Alternative ¨ublicher Fernaufrufe.
• Tupelr¨aume erleichtern die r¨aumliche Entkopplung, indem sie den Komponenten eine gemeinsame standardisierte Schnittstelle anbietet. Wie in Abbildung 1 darge- stellt, wird die direkte Kommunikation durch eine Indirekte ersetzt. Komponenten brauchen hier nur Kenntnis ¨uber den gemeinsamen Tupelraum zu haben.
Dadurch kann der Tupelraum einen Grossteil der n¨otigen Kommunikationslogik kapseln und erlaubt dem Entwickler eine h¨ohere sprachliche Perspektive bei der Programmierung.
• Tupelr¨aume erleichtern einezeitliche Entkopplung, die bei ¨ublichen Kommunikati- onssystemen keine native Entsprechung hat. Die Nutzung ¨ublicher Fernaufrufe er- fordert eine gleichzeitige Verf¨ugbarkeit der beteiligten Komponenten. Tupelr¨aume
bieten hier als zwischengelagerter Speicher eine nat¨urliche Pufferung, denn Kom- munikationsinhalte werden solange persistent gehalten, bis sie von einer Kompo- nente selbstst¨andig abgerufen werden. Die Zeitpunkte des Senden und Empfangen einer Tupelnachricht k¨onnen so zeitlich beliebig auseinander liegen.
Das Tupelraum-Paradigma hat seit seiner Entstehung eine Vielzahl von Implementa- tionen f¨ur Sprachen hervorgebracht, die das Konzept umsetzen oder sogar erweiterten.
So existieren auch aktuelle Umsetzungen, wie JavaSpaces [7], dass statt Tupeln, Java- Objekte als Datentyp einsetzt oder TSpaces [8], dass XML-Dokumente nutzt.
Auch wenn wir im folgenden konkrett nur Lindasysteme betrachten, ist es denkbar, dass einige der folgenden Beobachtungen oder Algorithmen sich direkt oder mit ¨Anderungen, auch auf andere Tupelraum-basierte Systeme, anwenden lassen. So lassen sich beispiels- weise Java-Objekte leicht als Tupel codieren, bei denen das erste Feld den Klassennamen und die weiteren Feldern die Instanzvariablen angeben.
2.2 Operationen
Tupel sind Listen mit einem oder mehr getypten Feldern. Das erste Feld wird dabei auch als Schl¨ussel bezeichnet.
(’stadt’,’berlin’,’deutschland’) (’angebot’, ’bohnen’, 100, 50)
Der lesende und schreibende Zugriff auf den Tupelraum gestaltet sich anhand gezielt einfacher atomarer Operationen.
Schreiben von Tupeln Die Operation Out <tuple> schreibt das angegebene Tupel in den Tupelraum.
out (’preis’, ’produkt’, 2.99)
out (’Student’, ’Informatik’, 35519324)
Die Operation eval <tupel> erlaubt zudem das Schreiben von nebenl¨aufig zu berechnenden Tupeln. Da diese Operation zum Verst¨andnis von Lindasystem un- erheblich ist, verzichten wir an dieser Stelle auf eine n¨ahere Erl¨auterung. In mo- derneren Implementationen wird zudem oft auf sie verzichtet.
Lesen von Tupeln: Tupelr¨aume sindassoziative Speicher, denn ihre Tupel besitzen nicht, wie in ¨ublichen Speichersystemen, klare logische Speicheradressen. Ihre Eintr¨age werden anonym und einzig ¨uber ihre Eigenschaften, das heisst die Inhalte ihrer Felder referenziert.
Dementsprechend gestaltet sich das Lesen eines Tupels als Suche anhand einer Mustervorlage (Template). Diese entsprechen speziellen Tupelangaben, in denen die Felder die Kriterien f¨ur das zu findende Tupel bilden. Ihre Felder k¨onnen zwei Formen annehmen.
• Aktuelle Felder(Actuals) sind statische Werte, die in dem zu findenden Tupel in diesem Feld genau so vorkommen m¨ussen.
• Formalle Felder(Formals) sind freie Feldangaben (auch genannt ’Wildcards’), die in dem zu findenden Tupel in diesem Feld, auf beliebige Werten abgebil- det werden. In Linda werden diese Felder durch ein f¨uhrendes Fragezeichen notiert.
Die Operation in <template> nimmt ein Tupel aus dem Tupelraum, dass dem Muster entspricht. Die Operationread <template>liest ebenfalls das Tupel, bel¨asst es aber im Tupelraum.
Passen mehrere Tupel auf ein Muster so kann nicht vorhergesagt werden, welches dieser Tupel von den Operationen zur¨uckgeliefert wird.
So k¨onnte ein Aufruf von
in(’stadt’,’?ort’,’deutschland’)
jedes der folgenden Resultate liefern (unter der Annahme, dass diese im Tupelraum vorlagen).
(’stadt’,’berlin’,’deutschland’) (’stadt’,’hamburg’,’deutschland’)
Wird kein passender Tupel gefunden, so blockiert der aufrufende Prozess solange, bis ein passendes Tupel gefunden wird. Somit ist es ausgeschlossen, dass auf eine Leseoperation kein Tupel geliefert wird. Neuere Implementationen erweitern die- ses Verhalten mit optionalen Benachrichtigungsmechanismen oder Angaben einer maximalen Wartezeit f¨ur Leseoperationen.
Tupelr¨aume werden zudem als generischer Speicher bezeichnet, da Tupel keinem Prozess zugeh¨orig sind. Sobald Tupel geschrieben wurden, sind sie offen verf¨ugbar und k¨onnen von jedem anderem Teilnehmer manipuliert werden.
Lindasysteme stellen eine sehr kleine, jedoch ausreichend m¨achtige Menge von Operatio- nen zur Verf¨ugung. Komplexere Interaktionen m¨ussen aus diesen primitiven Operationen zusammengesetzt werden.
Beispiel 1 Das Aktualiseren eines Tupels, muss ¨uber eine in-Operation gefolgt von einer entsprechenden out-Operation realisert werden.
3 Implementationsarchitekturen
Mit den M¨oglichkeiten der Berechnung und Konnektivit¨at w¨achst auch die Komplexit¨at der verteilten Programme. Das Internet erm¨oglicht ganze Anwendungsgebiete, mit einer immensen Anzahl potentieller Teilnehmer an einem Lindanetz. Im Gegensatz zu bis- herigen typischen Anwendungen, die innerhalb einer LAN oder eines r¨aumlich kleinen Serverclusters operierten, nimmt somit auch die Bedeutung der internen Transport- und Verteilungsmechanismen zu.
Es gibt verschiedene Ans¨atze zur Implementation eines Lindasystem, die eine Vielzahl von M¨oglichkeiten einsetzen um die Verteilung der Tupel zu gew¨ahrleisten. Es folgt eine Ubersicht ¨¨ uber gebr¨auchliche Architekturen von Lindasystemen.
3.1 Zentralisierung
Zentralisierung verwirklicht den Tupelraum als zentralen Server (siehe Abbildung 2), an dem die verteilten Komponenten ihre Operationen durchf¨uhren. Dieses System ist einfach zu implementieren und da sich alle Tupel an einem Ort befinden, die Suche entsprechend schnell.
Abbildung 2: Lindasystem mit einem zentralen Server.
Allerdings widerspricht dieser Ansatz dem allgemeinen Paradigma der verteilten Pro- grammierung in dessen Rahmen Linda als Koordinationssprache eingesetzt werden soll.
Der Aspekt der Verteilung bezieht sich hier nur auf die Teilnehmer und hat daher vor- allem unter zwei ¨ublichen Nachteilen von Zentralisierung zu leiden.
1. Hohe Fehleranf¨alligkeit, da dass gesamte System von einer einzelnen Instanz (’point of failure’) abh¨angig wird.
2. Skalierbarkeit kann nur durch Verbessern des zentralen Servers erreicht werden.
Mit der erforderlichen Leistung steigen die Kosten jedoch ¨uberproportional zur neu gewonnenen Leistung. In Systemen mit zentralen Servern neigen diese daher zu einem Flaschenhals zu werden.
3.2 Partitionierung
Partitionierung teilt den Tupelraum auf mehrere Server auf (siehe Abbildung 3). ¨Ubli- cherweise kommt hier eine Hashfunktion zur Anwendung, die Tupel auf die verschiedenen Server abbildet.
Abbildung 3: Lindasystem mit partitioniertem Tupelraum.
Im Gegensatz zur Zentralisierung ist das System nicht mehr abh¨angig von einer ein- zelnen Instanz und daher fehlertoleranter. Zudem wird die Nebenl¨aufigkeit und damit Skalierbarkeit erh¨oht.
Nachteilhaft ist jedoch der komplexe Hashing-Mechanismus. Von dieser h¨angt die Qua- lit¨at dieses Ansatzes im hohem Masse ab, da eine unbedachte Hashfunktion zu unba- lancierten Serverausnutzungen f¨uhren kann. Vorallem aber ist das flexible Reagieren auf Serverzug¨ange (Skalierbarkeit) und Serverabg¨ange (Fehlertoleranz) nur durch ¨Andern der Hashfunktion zu realisieren. Die Konsistenzmechanismen, zur Erhaltung der richti- gen Abbildung der Tupel auf die Server, sind komplex und verhindern eine hohe Effizienz.
3.3 Replikation
Replikation konzentriert sich vorallem auf den Aspekt der Fehlertoleranz, indem durch eine der Tupelraum ¨uber mehrere Server gespiegelt wird (siehe Abbildung 4). Das Aus- fallen von einzelnen Servern ¨andert hier nichts an der Gesamtmenge der Tupel. Da die Daten zudem auf jedem Server vollst¨andig verf¨ugbar sind, gestaltet sich das Suchen von Tupeln einfach und schnell.
Abbildung 4: Repikation spiegelt alle Daten ¨uber all Server.
Die Effizienz leidet bei diesem Ansatz jedoch unter der n¨otigen Konsistenzeigenschaft der Server. Bei jedem Schreiben und L¨oschen m¨ussen die Daten auf allen Servern abgeglichen werden, um nicht mehrmaliges Entnehmen eines einzelnen Tupels zu erlauben. Dies erfordert Sperrsynchronisation von Tupeln und ist nur mit komplexen Mechanismen zu realisieren.
Insbesondere skaliert der Ansatz schlecht, denn um grosse Systeme zu realisieren, muss
auch die Anzahl der Server vergr¨oßert werden, will man sich nicht den besprochenen Nachteilen der Zentralisierung aussetzen. Der dann n¨otige Kommunikationsaufwand steigt jedoch ¨uberproportional zu den neuen Resourcen.
3.4 Intermediate Replication
”Intermediate Replication“ verbindet die Aspekte der Zentralisierung und der Partitio- nierung. Das Servernetz stellt sich als rechteckiges Feld dar, bei dem in horizontaler Dimension eine Spiegelung und in vertikaler Dimension eine Partitionierung der Daten stattfinden (siehe Abbildung 5).
Zum Schreiben eines Tupels wird der Tupel auf einen horizontalen outbus abgebildet, der dann auf allen Servern in horizontaler Linie die Inhalte spiegelt. Zum Lesen dient derinbus, der auf vertikaler Linie alle Server untersucht und somit alle Partitionen des gesamten Tupelraums betrachten kann.
Abbildung 5: Intermediate Replication, ber¨ucksichtigt Replikation und Partitionierung Zwar ist diese Architektur fortgeschrittener, als die bisherigen Alternativen, jedoch er- scheint die Skalierbarkeit auch hier noch unbefriedigend, da die nur zwei Felddimensionen f¨ur Skalierungen, den Anforderungen zuk¨unftiger sehr grosser Systeme nicht gewachsen scheinen.
4 Swarm-Linda
In den letzten Jahren hat die Swarm Intelligence [3] in der Informatik stark an Bedeu- tung zugenommen. So werden beispielsweise Schwarm Abstraktionen dazu verwendet, Methoden zu entwickeln, die Lastverteilung in Netzen effizienter gestalten [6].
In dieser Arbeit soll eine Methodik vorgestellt werden, ein herk¨ommliches Lindasystem durch Anwendung von Swarm Intelligence Techniken in Bezug auf Skalierbarheit und Effizienz zu verbessern. Dieses neue Modell soll dann Swarm-Linda genannt werden.
In [5] wurde dazu zun¨achst das Skalierungsproblem von Lindasystemen untersucht. Im
n¨achsten Schritt war es dann die Aufgabe, durch Hinzunahme von Modellen aus der Biologie, wie zum Beispiel Ameisen Kolonien, die Skalierbarkeit zu optimieren. Amei- sen sind in der Lage ein vollst¨andiges Netzwerk, das den Ameisenh¨ugel zu Futterquellen verbindet, effizient, d.h mit (ann¨ahernd) k¨urzesten Wegen [2], zu erzeugen. Der daraus resultierende minimale Spannbaum reduziert die Wege vom Nest zur Futterquelle er- heblich. Dabei verwenden Ameisen keineswegs ¨ubliche Algorithmen zum Ermitteln des minimalen Spannbaums. Die Struktur wird durch einfache Aktionen der einzelnen Amei- sen vollzogen.
Im folgenden soll nun dargestellt werden, wie ein Implementierungsansatz f¨ur Swarm- Linda aussehen soll. Dazu werden die Kernalgorithmen des Lindasystems mit dem Ver- halten von Ameisen bei der Futtersuche, beim
”brood sorting“ [2] sowie dem Verhalten als Einheiten im Kollektivsystem kombiniert. Im Kern soll es dabei darum gehen, anhand von haupts¨achlich lokalen Entscheidungen und einfachen Regeln das Gesamtsystem so einfach wie m¨oglich zu halten und dadurch u.a. eine bessere Skalierung des Systems zu erm¨oglichen.
Wir werden noch sehen, dass durch diese ameisenbasierte Optimierung Ver¨anderungen in der Struktur des Systems dynamisch erfasst werden k¨onnen. Ausserdem gibt es keine globale Kontrolle f¨ur das Kollektiv. Entscheidungen werden auf der Grundlage lokaler Informationen getroffen.
4.1 Swarm Intelligence
Um die genannten Vorteile auch erzielen zu k¨onnen, muss Swarm-Linda einige Prinzipien realisieren, die man bei Schw¨armen in der Natur beobachten kann [2]. Diese Prinzipien erm¨oglichen erst, dass die Aktivit¨aten der Schw¨arme, vor allem die Koordination des Kollektivs, erfolgreich in die Tat umgesetzt werden k¨onnen und die Systeme sehr gross werden k¨onnen (Skalierbarkeit).
B Einfachheit: Schwarm Individuen sind einfache Gesch¨opfe, die simple Aufgaben er- ledigen. Sie halten sich an einfache Verhaltensregel. Die Ausf¨uhrung dieser Re- geln f¨uhrt bei Schw¨armen zu einem sehr komplexen Verhalten des Gesamtsystems.
Ausserdem ist zu beachten, dass auch der Verbrauch von Ressourcen der aktiven Einheiten ebenfalls m¨oglichst gering gehalten werden muss.
B Dynamik: Schw¨arme leben in einer sich st¨andig ¨anderenden Umwelt und sind denoch in der Lage sich stets anzupassen. In einem offenen verteilten System ¨andern sich die Konfigurationen mit der Zeit und viel ist vom aktuellen Zustand der Syste- mumwelt abh¨angig. So kann man keine Aussagen ¨uber m¨ogliche Zukunftereignisse machen, auch wenn bestimmte Ereignisse bereits eingetreten sind. Was momentan gilt, kann sich schon im n¨achsten Moment drastisch ver¨andert haben. Die Aufgabe soll sein, sich diesen ¨Anderungen dynamisch anpassen zu k¨onnen.
B Lokalit¨at: Schwarmindividuen beobachten ihre direkte Nachbarschaft. Ausschliesslich auf dieser (eingeschr¨ankten) lokalen Sicht basierend, werden dann Entscheidungen
getroffen. Ausschlaggebend f¨ur die Skalierbarkeit des Systems ist dabei die Tatsa- che, dass die aktiven Einheiten Anfragen nur an unmittelbare Nachbarn richten und sich auf lokale Informationen st¨utzen.
Um diese Prinzipien auf vern¨unftige Weise verwenden zu k¨onnen, m¨ussen die Begriffe der Swarm Intelligence f¨ur das Lindasystem abstrahiert werden. Dazu werden folgende Begriffe eingef¨uhrt:
Individuen (individuals) sind aktive Einheiten, die in der Lage sind, ihre Nachbarschaft zu beobachten, sich in der Umwelt zu bewegen, und den Zustand der Umwelt zu ver¨andern.
Umwelt (environment) ist der Zusammenhang, in dem die Individuen arbeiten und den sie beobachten.
Zustand (state). Der Zustand ist eine Charakteristik der Umwelt, die von den Indivi- duen beobachtet und ver¨andert werden kann.
Je nachdem welcher Algorithmus verwendet wird, k¨onnen diese Abstraktionen verschie- dene Lindakonzepte darstellen.
Beispiel 2 Bei der Tupelsuche stellen Individuen Muster (templates) dar, die sich zwischen den Servern bewegen und nach Tupel suchen. Soll jedoch die Anpassung an die Umwelt beschrieben werden, stellen Individuen dagegen Tupel dar, die sich auf der Basis semi-randomisierter Entscheidungsprozesse von Ort zu Ort bewegen.
4.2 Swarm-Linda Algorithmen
Nach der allgemeinen Swarm-Linda Beschreibung k¨onnen wir jetzt konkret definieren was Umwelt, Zustand und Individuen darstellen sollen. Dies soll anhand von f¨ur Linda bedeutenden Algorithmen verdeutlicht werden. Diese Algorithmen sind Abstraktionen von Multi-Agent Systemen, vor allem des Verhaltens von Ameisen, wie es auch von Parunak [2] beschrieben wird.
4.2.1 Tupelsuche
Prinzip: Bei der Tupelsuche wird ein Verfahren angewandt, welches Ameisen norma- lerweise bei der Futtersuche verwenden. Dabei halten sie sich an folgende Regeln [5]:
Die Suche erfolgt in N¨ahe des Ameisenh¨ugels.
Nach der erfolgreichen Suche wird das Futter zum Ameisenh¨ugel gebracht. Es wird eine Spur vom Fundort zum Ameisenh¨ugel hinterlassen (Markierung), damit folgende Ameisen den Weg zur Futterstelle finden k¨onnen.
Ameisen finden zum Ameisenh¨ugel zur¨uck, weil sie sich ihre letzten paar Schritte merken k¨onnen, und zum andern verstreut der Ameisenh¨ugel einen unverwechsel- baren Duft, der von den Ameisen zur¨uckverfolgt werden kann.
Dieses Verhalten wollen wir im Tupelraum anwenden. Dazu sehen wir Tupel als Futter an. Die Muster (Templates) betrachten wir als Ameisen, die sich auf der Suche nach Tupeln zwischen den Orten (Servern) bewegen. Die Orte, an denen die Tupel gespei- chert werden, k¨onnen wiederum als Gesamtgebiet, im dem sich die Ameisen bewegen, betrachtet werden. Der Ameisenh¨ugel stellt dann den Prozess dar, der die Operation durchf¨uhrt.
Algorithmus: F¨ur den Algorithmus stellen die aktiven Individuen Musterameisen dar, die Umwelt besteht aus Tupelraum Servern, deren Zustand sich aus den gelagerten Tu- peln, sowie den D¨uften der unterschiedlichen Musterarten zusammensetzen. Diese D¨ufte weisen die Wahrscheinlichkeit auf, dass ¨Ubereinstimmungen zu einem bestimmten Mus- ter sich an diesem Ort befinden. Diese D¨ufte sind nicht dauerhaft, sondern l¨osen sich nach einer bestimmten Zeit auf. Die Musterameise sollte sich an folgenden Regeln ori- entieren:
• Im ersten Schritt sollte die Ameise den Duft des Prozesses auf dem Server, mit dem sie verbunden ist, und auf den benachbarten Servern verstreuen. Dieser charakte- ristische Duft wird von den Ameisen sp¨ater auf dem R¨uckweg zum Ameisenh¨ugel zur¨uckverfolgt.
Abbildung 6: Schritt 1: Duft verstreuen
• Bei jedem aktuellen Server wird ¨uberpr¨uft, ob eine ¨Ubereinstimmung (match) exis- tiert. Falls dies der Fall ist, kehrt die Ameise zum Ursprungsort zur¨uck und hin- terl¨asst bei jedem Schritt einen Duft f¨ur das ¨ubereinstimmende Muster. Durch Zur¨uckverfolgen des Prozessduftes kann die Ameise den Weg zur¨uck finden. Wird keine ¨Ubereinstimmung entdeckt, so wird die Nachbarschaft ¨uberpr¨uft.
Abbildung 7: Match auf Server suchen
• Ist kein passender Duft am aktuellen Ort, so w¨ahlt die Ameise f¨ur die weitere Suche zuf¨allig eine Richtung auf dem Serverraster aus.
• Ist ein Duft, der auf eine Richtung f¨ur den n¨achsten Schritt (¨ubereinstimmender Duft) hinweist, so geht die Ameise einen Schritt in Richtung dieses Duftes und wiederholt den Untersuchungsvorgang. Swarm-Linda soll sowohl die Anpassung (adaptability) an Ver¨anderungen in der Umwelt f¨ordern, als auch einen Nichtde- terminismus f¨ur die Tupelsuche enthalten. Aus diesem Grund wird beispielsweise ein Zufallsfaktor im Intervall [−ξ, ξ] f¨ur jeden Duft eingef¨uhrt. Auf diese Weise k¨onnen neue Pfade (nicht unbedingt Pfade mit dem intensivsten Duft) entdeckt werden [5].
• Die T¨atigkeiten der Ameise werden noch eingeschr¨ankt, um sicherzustellen, dass sie beispielsweise nicht nach Tupel sucht, die noch gar nicht produziert wurden, z.B. durch endloses Umherirren, ohne einen passenden Duft zu finden. So soll die Ameise nach jedem erfolglosen Schritt, d.h. ohne ¨Ubereinstimmungen, mit einer Wahrscheinlichkeit von γ stoppen. Dieser Faktor ist zu Beginn 0 und erh¨oht sich mit jedem erfolglosen Schritt um Γ. Γ selbst erh¨oht sich mit der Zeit. Entscheidet sich die Ameise f¨ur einen Stopp, so ergeben sich folgende drei Aktionsm¨oglichkeiten:
1. Die Ameise
”schl¨aft“ eine Weile und nimmt die Suche erneut auf. Dies soll lediglich eine Aktivit¨atseinschr¨ankung darstellen. Gelangt die Ameise an einen Ort, wo lange Zeit keine ¨ubereinstimmenden Tupel produziert wurden, so wird die Ameise es schwer haben aus diesem Ort wegzukommen. Die Pause soll der Umwelt Zeit geben, sich zu ver¨andern. M¨oglicherweise wird dadurch ein Zustand erreicht, in dem Tupel an diesem Ort gefunden werden k¨onnen.
2. Die Ameise
”stirbt“ und wird nach einer bestimmten Zeit am Ursprungsort
”wiedergeboren“, an dem die Suche neu gestartet werden kann.
3. Die Ameise taucht an einem zuf¨allig anderen Ort auf und sucht dort weiter.
Auf diese Weise wird m¨oglicherweise eine ¨Ubereinstimmung gefunden, der op- timale Pfad vom Ursprungsort zum Tupel wird dadurch jedoch nicht erreicht.
Die Spuren, die von diesem Ort zum Tupel hinterlassen werden, sind jedoch f¨ur die anderen Musterameisen, die in dieser Region arbeiten markiert. F¨ur diese kann es hilfreich sein, optimale Pfade vom Tupel zu ihrem Ursprungsort zu finden.
Die Auswahl der jeweiligen Aktion h¨angt vom Alter der Ameise ab. In der Regel werden bei den ersten Stopps erst ein paar Pausen eingelegt (Aktion 1). Nachdem dies einige Male erfolglos war, wird die Ameise ein paar mal wiedergeboren (Akti- on 2). Sollte auch dies mehrmals fehlschlagen, versucht sie woanders aufzutauchen, um dort die Suche weiterzuf¨uhren (Aktion 3).
Dieses Verfahren bildet Pfade zwischen Tupelproduzenten und -konsumenten. Dadurch, dass D¨ufte mit der Zeit schw¨acher werden, passen sich die Pfade den Ver¨anderungen im System an. Die Anwendung dieses Verfahrens f¨uhrt dazu, dass beispielsweise der m¨ogliche Ausfall eines Servers lediglich als ¨Anderung in der Umwelt interpretiert wird.
Somit erh¨oht sich auch die Fehlertoleranz bei m¨oglichen Ausf¨allen. Anders als beispiels- weise beim Hashing, bei dem solche Ausf¨alle durch zus¨atzliche Massnahmen behoben werden m¨ussen [5], orientieren sich die Ameisen hier an den aktuellen Zust¨anden in der Umwelt und entscheiden nur auf der Grundlage ihrer Beobachtungen der Nachbarschaft (Lokalit¨at).
4.2.2 Verteilungsalgorithmus
Swarm Intelligence kann auch bei der Verteilung der Tupel zwischen den Servern eine wichtige Rolle spielen. In Swarm-Linda kann die Partitionierung des Tupelraums mit dem Konzept des
”Brood Sorting“ dynamisch erfolgen. Nach Parunak [2] sind im Ameisenh¨ugel eine Vielzahl von Dingen gelagert, wie z.B. Eier, Larven etc. Diese Dinge werden nicht vermischt gelagert, sondern sind strikt nach Typ sortiert, obwohl Amei- sen niemals einen konkreten Suchalgorithmus durchf¨uhren. Die Ameisen handeln nach folgenden Prinzipien [2]:
(i.) Die Bewegung im Nest erfolgt zuf¨allig.
(ii.) Sich in der N¨ahe befindende Objekte k¨onnen gesp¨urt werden. Es existiert ein Ged¨achtnis f¨ur was in den letzten paar Schritten gesehen wurde.
(iii.) Tr¨agt die Ameise nichts mit sich, wenn sie auf ein Objekt st¨osst, dann wirdzuf¨allig entschieden, ob das Objekt mitgenommen wird oder nicht. Die Wahrscheinlich- keit das Objekt mitzunehmen sinkt, falls die Ameise k¨urzlich (in den letzten paar Schritten) ¨ahnlichen Objekten begegnet ist.
(iv.) Tr¨agt die Ameise etwas mit sich, wird in jedem Schritt stochastisch entschieden, ob das Objekt abgelegt wird oder nicht. Die Wahrscheinlichkeit, dass das Objekt ab- gelegt wird, steigt dabei, falls die Ameise k¨urzlich ¨ahnlichen Objekten begegnet ist.
Dadurch, dass das Mitnehmen und das Ablegen von Objekten stochastisch erfolgt, k¨onnen mehrere H¨aufungspunkte schliesslich zusammengelegt werden, da Ameisen gele- gentlich Objekte von einem H¨aufungspunkt mitnehmen und zu einem anderen transpor- tieren.
Dieses Verhalten soll nun f¨ur Swarm-Linda modelliert werden. Die agierenden Individuen sind hierbei Tupelameisen. Die Umwelt bleibt wie oben beschrieben. Der Zustand ist die Menge der Tupel, die aktuell gelagert sind.
Algorithmus: Tupel k¨onnen einfach nach Mustern gruppiert werden. Dies f¨uhrt zu einer Bildung von Tupelclustern. Bei diesem Verfahren stellen Tupel das Futter dar, w¨ahrend die Ameise die aktive Komponente darstellt, die denout-Befehl repr¨asentiert.
1. Mit der Ausf¨uhrung des out-Befehls werden die Server untersucht.
Abbildung 8: Schritt 1: Untersuchen der Server
2. Die Tupelarten, die auf den Servern gelagert sind, werden untersucht. Jeder out- Prozess sollte ¨uber einen begrenzten Speicher verf¨ugen, damit nicht die Informa- tionen aller Server des Servernetzes memorisiert werden, sondern nur die letzten paar. Auf diese Weise wird sichergestellt, dass Entscheidungen ausschliesslich auf lokalen Informationen basieren.
3. Das Tupel wird auf dem Server abgelegt, falls nahegelegene Server Tupel lagern, die mit demselben Muster ¨ubereinstimmen. Auch hier arbeitet man mit einem Zufallswert [−ξ, ξ], um den Nichtdeterminismus sicherzustellen, der (siehe oben) wiederum f¨ur das dynamische Verhalten des Systems relevant ist.
4. Sind in der N¨ahe keine ¨ahnlichen Tupel, dann wird mit Hilfe eines Zufallswertes entschieden, ob das Tupel abgelegt wird, oder ob zum n¨achsten Server ¨ubergegan- gen werden soll.
Abbildung 9: Entscheidung (mit [−ξ, ξ]), ob Tupel abgelegt wird
Bei diesem Verfahren muss noch sichergestellt werden, dass der out-Prozess auf jeden Fall irgendwann das Tupel ablegen wird. Dazu soll der Zufallswert jedes Mal, wenn der Prozess entscheidet, das Tupel nicht zu speichern, zu ξ tendieren. Dies erh¨oht die Wahrscheinlichkeit des Ablegens im n¨achsten Schritt. Ausserdem ist die Wahrscheinlich- keit, ein Tupel abzulegen stark von den zuletzt gesammelten Informationen abh¨angig:
je mehr Objekte im Speicher dem Tupel ¨ahneln, desto h¨oher ist die Wahrscheinlichkeit des Ablegens im n¨achsten Schritt.
Bei diesem Verfahren f¨uhrt es nicht zu Problemen, wenn etwa neue Server hinzugef¨ugt oder alte Server entfernt werden. Anders als beispielsweise beim Hashing, wo zus¨atzliche L¨osungen f¨ur Serverausf¨alle in Betracht gezogen werden m¨ussen, passen sich die Ameisen bei Swarm-Linda Ver¨anderungen allm¨ahlich an [5]. Somit ist auch eine Verbesserung der Skalierbarkeit gegeben. Dies wird noch durch die Tatsache verbessert, dass der Speicher der Tupelameisen beschr¨ankt ist. Dies hat zur Folge, dass die Ameisen sich auf lokale Informationen beschr¨anken m¨ussen.
Wichtig ist noch anzumerken, dass sich in Swarm-Linda Tupel, die zum selben Muster passen eigentlich dazu tendieren, nahe beieinander zu bleiben. Werden diese Tupel jedoch mit ausreichendem Abstand voneinander erzeugt, d.h. werden sie an unterschiedlichen Orten erzeugt, die weit genug auseinander liegen, kann dadurch eine lokale Trennung dieser ¨ahnlichen Tupel erfolgen. Das Ergebnis ist die erw¨ahnte Clusterbildung. Dadurch werden Engp¨asse, die durch Flaschenhalsbildung (z.B. wenn mehrere Prozesse Tupel mit selbem Muster ben¨otigen) zustande kommen, verhindert. Es erfolgt eine bessere Lastverteilung, weil die n¨achstgelegenen (vom Ursprung aus gesehen) Tupel gefunden werden [5].
4.2.3 Anpassung an die Umwelt
Schw¨arme sind sehr anspassungsf¨ahig und reagieren gut auf Ver¨anderungen in der Um- welt. In Swarm-Linda soll solch ein Verhalten f¨ur eine Menge von ¨ahnlichen Tupeln realisierbar sein. Dazu werden wieder Tupleameisen als Individuen verwendet. Die Um- welt ist wieder ein Serverraster, welches als Zustand bestimmte D¨ufte hat.
In der Natur finden Ameisen den Ameisenh¨ugel durch einen speziellen Duft, der den H¨ugel eindeutig identifiziert. Dieser Duft sorgt daf¨ur, dass die Ameisen im Ameisenh¨ugel zusammenbleiben.
Algorithmus: In Swarm-Linda wollen wir, dass Tupel, die mit demselben Muster ¨uber- einstimmen zusammengelagert werden. Der Ort soll aber nicht festgelegt sein. Vielmehr soll er sich dynamisch mit den Ver¨anderungen in der Umwelt ergeben.
Ahnlich wie in der Natur brauchen wir auch bei Swarm-Linda eine eindeutige Identi-¨ fikation durch D¨ufte. Hierf¨ur wird eine Funktion Sc : T −→ S auf Muster und Tupel definiert, die einen bestimmten Duft liefert. Ebenso gibt es eine Relation C :S×S auf D¨ufte, die die ¨Ahnlichkeit zwischen zwei D¨uften definiert [5].
Beispiel 3 Mit der Relation C kann beispielsweise festgestellt werden, ob ein Musterte und ein Tupel tu ¨ubereinstimmen. Dazu muss lediglich gepr¨uft werden, ob
(Sc(te), Sc(te))∈C gilt.
F¨ur das Anpassungsverhalten gelten nun folgende Regeln:
1. Eine neue Tupelameise, die ein Tupel tu transportiert verbreitetSc(tu) an ihrem Ursprungsort aus. Gleiches gilt f¨ur Musterameisen.
2. Musterameisen bleiben an dieser Stelle und bewegen sich nicht.
3. Tupelameisen nehmen D¨ufte in der Umwelt wahr, dieSc(tu) ¨ahneln. Existiert ein solcher Duft, dann sind andere Tupel- oder Musterameisen in der N¨ahe.
4. Abh¨angig von der Intensit¨at des wahrgenommenen Duftes und des Zufallswertes [−ξ, ξ] entscheidet die Tupelameise, ob sie sich in diese Richtung bewegt oder an der aktuellen Stelle verbleibt.
Dieses Verhalten sorgt daf¨ur, dass Tupel sich dort ansammeln, wo ¨ahnliche Tupel ge- braucht werden, oder wo gerade welche produziert werden [5]. Dies schliesst die M¨oglich- keit ein, dass sich die Ameisen von einem Server zum anderen bewegen m¨ussen. Dieses Verhalten hat auch Auswirkungen auf die Verteilung der Tupel (siehe Abschnitt 4.2.2).
Beim Lagerungsprozess werden die D¨ufte, die von fr¨uherenin undout-Befehlen verbrei- tet wurden, in Betracht gezogen, um zu entscheiden, ob ein Tupel auf dem aktuellen Server gelassen wird oder ob ein anderer Server gew¨ahlt wird, d.h ob die Ameise weiter- zieht, um einen geeigneten Server ausfindig zu machen.
4.2.4 Aktive und passive Ameisen
Motivation In den bisher betrachteten Algorithmen haben wir gezielt einzelne Opera- tionen betrachtet, sind als von eher willk¨urlichen out- und in-Operationskombinationen
ausgegangen. In verteilten Systemen lassen sich tats¨achlich jedoch wiederkehrende und klassische Konfigurationen von Rollenverteilungen ausmachen, die bei dem Entwurf einer Lindasystems herangezogen werden sollten.
Zur Erl¨auterung dieses Algorithmuses betrachten wir eine exemplarische Anwendung f¨ur Tupelr¨aume, in der das klasische Meister-Arbeiter-Entwurfsmuster [4] (Master-worker- pattern) genutzt wird. Anhand dieses wesentlichen Entwurfsmusters f¨ur verteilte Syste- me soll die Motivation des n¨achsten Algorithmus klar werden.
Eine zentrale Meisterentit¨at unterteilt hier ein Gesamtproblem in diskrete und vonein- ander unabh¨angig l¨osbare Teilprobleme, die an sogenannte Arbeiterinstanzen ¨ubergeben werden. Jeder Arbeiter l¨ost selbst¨andig, die ihm zugewiesen Aufgaben und liefert dann sein Resultat zur¨uck. Die Gesamtzahl der L¨osungen kann schließlich vom Meister zu einer L¨osung des Gesamtproblem zusammengesetzt werden.
Das Muster hat vorallem folgende Vorteile, die zu seiner weiten Verbreitung beigetragen haben.
• Da die Arbeiterinstanzen selbstst¨andig ihren eigenen Rechenresourcen nach ar- beiten, kommt es zu einer nat¨urlichen Lastverteilung. Arbeiter mit schw¨acherer Arbeitsleistung holen sich nur so viele Aufgaben aus dem Tupelraum, wie sie abar- beiten k¨onnen, w¨ahrend rechenst¨arkere Arbeiterinstanzen selbstst¨andig mehr Auf- gabentupel abarbeiten k¨onnen.
• Das System skaliert sehr gut, da die Rechenleistung des Systems einfach durch neue selbstst¨andige Arbeiter verst¨arkt werden kann. Da die Arbeiter von der Meisteren- tit¨at entkoppelt sind, k¨onnen Arbeiter einfach hinzugef¨ugt oder entfernt werden.
Im folgenden betrachten wir nun die zwei wesentliche Phasen, f¨ur unsere Betrachtung einer Lindaimplementation basierend auf Schw¨armen.
Aufgabenverteilung. Anfangs werden von der zentralen Meisterinstanz eine Vielzahl von Aufgabentupeln produziert, die die unabh¨angigen Teilaufgaben zur L¨osung des Gesamtproblems repr¨asentieren. Nach den bisher betrachteten Algorithmen agieren diese Tupelameisen mehr oder minder passiv und ordnen sich nur m¨oglichst in Clustern an. Wie in Abbildung 10 schematisch dargestellt, f¨ugen die Arbeiter ihrerseits Musterameisen in den Tupelraum ein, die aktiv nach den Aufgabentupeln suchen.
In dieser Situation ist die Meisterinstanz Produzent von Tupeln, w¨ahrend die Ar- beiter Konsumenten dieser sind. Da hier alle Aufgabentupel nur von einem pro- duzierenden Feld abgegeben werden, bilden sich schnell Cluster von Tupeln. Die Ausbildung von kurzen Suchwegen wird beg¨unstigt.
Resultatempfang. Nach der Berechnung ihrer durch die Tupel kodierten Aufgaben, pro- duzieren die Arbeiter ihrerseits Tupel mit den Resultaten der Teilprobleme. Wie in Abbildung 11 dargestellt, kehrt sich die Produzent-Konsument-Relation nun um.
Abbildung 10: Die Meisterentit¨at teilt das Gesamtproblem.
Behalten wir das gerade noch g¨unstige Ameisenverhalten weiter, so kommt es nun zu einem uneffizienten Verhalten. Die Meisterinstanz muss nun Musterameisen aus- schicken, um die stark verteilten Resultattupel zu finden. Die schnelle Ausbildung von gr¨osseren Clustern und damit auch k¨urzesten Wegen hat schlechte Aussichten.
Abbildung 11: Die Arbeiter liefern ihre Resultate.
Auch wenn die bisher betrachteten Algorithmen bereits eine m¨oglichst gute Vertei- lung der Tupel bewirken sollen, so w¨urde das einfache Umkehren des Suchmecha- nismus deutlich bessere Voraussetzungen bringen. Anstatt einen einzigen Konsu- mentan nach vielen verteilten Produzenten suchen zu lassen, sollten die Produzen- ten selbstst¨andig ihre Resultate dem Verbraucher zuweisen. Die gleichen g¨unstigen Vorraussetzungen wie bei der Aufgabenverteilung, w¨urden dann auch hier gelten.
Algorithmus Im folgenden betrachten wir einen Algorithmus, der den wechselnden Verh¨altnissen gerecht werden soll. Dazu ¨uberarbeiten wir die uns bekannten Ameisen und f¨uhren neue Pheromone ein, die das Erkennen der aktuellen Produzent-Konsument- Konfiguration erlauben, um dynamisch zu einem g¨unstigen Systemverhalten zu gelangen.
Wir kennen wieder zwei Ameisenarten. Tupelameisen stellen die von Out-Operationen erzeugten Tupel dar, w¨ahrend Musterameisen die Muster von in-Operationen repr¨asen- tieren. Zus¨atzlich unterscheiden wir nun aber zwischen zwei Verhaltensweisen. Soge- nannte aktive Ameisen suchen selbstst¨andig ihr Gegenst¨uck, d.h. aktive Tupelameisen
suchen nach Musterameisen und analog aktive Muster- nach Tupelameisen. Die Su- che gestaltet sich wie in Abschnitt 4.2.1 beschrieben. Passive Ameisen dagegen suchen nicht selbstst¨andig, sondern warten darauf von einer aktiven Ameise gefunden zu wer- den. Ob sie dabei einfach stehen bleiben oder eine g¨unstige Verteilung anstreben, wie in Abschnitt 4.2.2 und 4.2.3 beschrieben, bleibt der spezifischen Implementation von Swarm-Linda ¨uberlassen und soll an dieser Stelle nicht weiter erwogen werden.
Durch die Trennung von Ameisenart und -verhalten kann das System, durch die Wahl welche Ameisen produziert werden, das Suchverhalten entsprechend der aktuellen Situa- tion anpassen. Die Analyse der aktuellen Konfiguration vollzieht sich dabei ¨uber zwei D¨ufte, die zus¨atzlich den Zustand jedes Feldes definieren. Der Besucherduft dient als In- dikator f¨ur die allgemeine Attraktivit¨at eines Feldes. Je mehr Tupel- oder Musterameisen auf einem Feld durch ihr Gegenst¨uck gefunden werden, desto st¨arker soll die allgemei- ne Attraktivit¨at und damit der Besucherduft des Feldes sein. Felder mit schwachem Besucherduft gelten analog als Aussenseiter.
Formal handelt es sich dabei um die Gleichung:
dBesucher = (ntupel+nmuster)∗δ
n sei hier die Anzahl der auf diesem Feld jeweils erfolgreichen Ameisen. Als erfolgreich gelten Ameisen, die ihr Ziel gefunden haben, d.h. Tupelameisen, die eine passende Mus- terameise finden bzw. Musterameisen, die eine passende Tupelameise finden.
Die Attraktivit¨at eines Feldes gibt noch nicht Aufschluss, ob auf diesem Feld eher Tupel- oder Mustersuchameisen erfolgreich sind. Dazu dient der speziellere Produzent- Konsument-Duft. Er ist auf das Intervall [−, ] beschr¨ankt.
Die Gleichung ist formal:
dP roduzent−Konsument= (ntupel−nmuster)∗δ
n sei hier die Anzahl der auf diesem Feld erzeugten und erfolgreichen Ameisen. Als erfolgreich gelten Ameisen, die ihr Ziel gefunden haben, d.h. Tupelameisen, die eine pas- sende Musterameise finden bzw. Musterameisen, die eine passende Tupelameise finden.
Der Duft w¨achst mit jeder erzeugten oder erfolgreich gefundenen Tupelameise und sinkt mit jeder erzeugten oder gefundenen Musterameise.
Zur Entscheidung welche Arten von Ameisen erzeugt werden, werden nun die beiden D¨ufte herangezogen. F¨ur eine optimale Ameisenerzeugung gehen wir nun bei einerout- Operation von folgender Tabelle aus.
Produzent Verbraucher
Attraktion Passive Tupelameise Aktive/Passive Tupelameise Aussenseiter Aktive Tupelameise Passive Tupelameise
Das Verhalten bei einerin-Operation findet sich analog in der folgenden Tabelle.
Abbildung 12: Die verbesserte Situation.
Produzent Verbraucher
Attraktion Passive/Aktive Musterameise Passive Musterameise Aussenseiter Passive Musterameise Aktive Musterameise
Die in Abschnitt 4.2.4 gemachten Beobachtungen haben zu dem neuen Suchverhalten gef¨uhrt. Kehren wir zu der Situation in Abbildung 11 zur¨uck und wenden unsere neuen Erkenntnisse an, so ergibt sich die Situation, die in Abbildung 12 dargestellt sei. Die Gruppierung von gleichartigen Daten wird nun beg¨unstig und somit die Sucheffizienz stark gesteigert.
5 Bewertung
Betrachtet man all die vorgestellten Algorithmen, so kann man sicherlich einige m¨ogli- chen Verbesserungen gegen¨uber dem
”normalen“ Lindasystem beobachten. Man kann sich leicht vorstellen, dass das Fehlen einer globalen Kontrolle und die Einschr¨ankungen der Entscheidungen auf lokale Informationen den Nachrichtenaustausch im System be- tr¨achtlich reduziert. So k¨onnen Anfragen direkt an die Stelle gerichtet werden, wo ein Match erwartet wird, anstatt das gesamte System beispielsweise per Broadcast
”auszu- fragen“. Die Auslastung und Skalierbarkeit wird verbessert. Der Anpassungsmechanis- mus (siehe Abschnitte 4.2.1 und 4.2.2), der Ver¨anderungen in der Umwelt erfassen kann und das System bef¨ahigt, sich dementsprechend anzupassen, erh¨oht die Fehlertoleranz bei optimalem Verhalten betr¨achtlich, ohne dass wie beim Hashing zus¨atzliche Metho- den implementiert werden m¨ussen.
Auf der Grundlage der dargestellten Algorithmen und Konzepte sehen Menezes und Tolksdorf [5] eine potentielle Effizienzverbesserung gegen¨uber herk¨ommlichen Lindasys- temen. Darin scheinen Skalierbarkeit, Anpassungsf¨ahigkeit, Fehlertoleranz und Lastver- teilung im Zusammenhang mit Swarm-Linda besonders attraktiv.
5.1 Skalierbarkeit
Wie bereits mehrfach angesprochen basieren s¨amtliche Entscheidungen auf lokalen Be- obachtungen (Aktionen in der unmittelbaren Umgebung). Das gesamte System hat keine globale Kontrolle, und somit ist auch der Algorithmus unabh¨angig von der Anzahl ope- rierender Ameisen.
5.2 Anpassungsf¨ahigkeit und Fehlertoleranz
Der Zustand der Umwelt bestimmt die Aktionen der aktiven Einheiten (Ameisen). Er wird durch das Streuen unterschiedlicher D¨ufte ver¨andert. Dies erfolgt auf der Grund- lage von Entscheidungen der Individuen. Fr¨uhere Entscheidungen verlieren mit der Zeit an Einfluss im System, da die D¨ufte mit der Zeit an Intensit¨at verlieren. In diesem Sin- ne spiegelt der Zustand die aktuelle Konfiguration des Systems (Momentaufnahme) in Bezug auf Tupelproduktion und Tupelkonsumption wider. Die Ameisen passen ihr Ver- halten der ver¨andernden Umwelt an.
Mit diesem Anpassungsmechanismus wirken sich aber auch Fehlentscheidungen nicht dauerhaft negativ auf das System ein. In Swarm-Linda umgeht dieser Anpassungsmecha- nismus solche Fehler, denn Fehler werden einfach als Zustands¨anderungen der Umwelt, d.h. ¨Anderungen der Systemkonfigurationen angesehen.
5.3 Lastverteilung
Die Anpassung an die Systemkonfiguration erzielt eine dynamische Verteilung der Last (Aktivit¨aten der Ameisen) durch lokale Entscheidungen (siehe Abschnitte 4.2.2 und 4.2.3).
Dadurch werden Systemengp¨asse, wie die Entstehung eines
”Flaschenhalses“, vermieden.
6 Konklusion
Swarm Intelligence Prinzipien liefern in der Natur beeindruckende Resultate [3]. In dieser Ausarbeitung haben wir gesehen, dass durch die Anwendung einiger einfacher Prinzipi- en, die an das Verhalten von Ameisen in der Natur angelehnt sind, ein herk¨ommliches Lindasystem so weit um ein dynamisches Verhalten erweitert wird, dass es auf flexiblere Weise in der Lage sein kann, sich Umstrukturierungen des Systems anzupassen. Zu die- sen Umstrukturierungen z¨ahlen auch Fehler im System, wie etwa ein m¨oglicher Ausfall eines Servers. Ausserdem ist es deutlich geworden, dass allein durch die Tatsache, dass Entscheidungen auf lokalen Informationen basieren, die Skalierbarkeit optimiert werden kann.
Literatur
[1] D. Gelernter. Generative communication in linda. ACM Transactions on Program- ming Languages and Systems., 7(1):80–112, 1985.
[2] H. Van Dyke Parunak. Go to the ant: Engineering principles from natural multi-agent systems. Annals of Operations Research, 75:69–101, 1997.
[3] J. Kennedy and R.C. Eberhart. Swarm Intelligence. Morgan Kaufmann, 2001.
[4] Z. Maraikar and D. N. Ranasinghe. From linda to javaspaces - a review of the tuple space paradigm.
[5] Ronaldo Menezes and Robert Tolksdorf. A new approach to scalable linda-systems based on swarms. ACM SAC, 2003.
[6] Ruud Schoonderwoerd and Owen Holland and Janet Bruten and Leon Rothkrantz.
Ant-based load balancing in telecomunications networks. HPL-96-97, 1996.
[7] Sun Microsystems. JavaSpaces Service Specification, 2003.
[8] P. Wyckoff. Tspaces. IBM Systems Journal, AUG 1998.
