P2P-MagicMap
aus Nomads, der freien Wissensdatenbank
Inhaltsverzeichnis |
Idee
Bisher benötigt die Verteilung der Daten unter den Knoten (Signalstärke-Messwerte, Positionsberechnungen bzw. Referenzmessungen) mit MagicMap einen Server. Ist kein Server erreichbar, können auch keine Daten ausgetausch werden. Eine autonome Positionsbestimmung gelingt zwar mit dem "lokalen Server", dieser speichert die Daten allerdings nur lokal, ohne sie mit anderen Knoten auszutauschen. Es können also keine neuen Umgebungsinformationen geladen werden, wenn man den Bereich der lokal vorhandenen Referenmessungen verläßt. Um nun auch in infrastrukturlosen Umgebungen, in denen die permanenten Verfügbarkeit eines MagicMap-Servers nicht gewähleistet ist, Messungen und Position mit anderen Knoten auszutauschen, verteilen wird die Daten in Peer-to-Peer-Manier. Dazu übernehmen einige der verfügbaren mobilen Knoten jeweils spontan die Rolle von "Verteilern". Allerdings kann nicht jedes ressourcenschwache Gerät diese Rolle übernehmen, wenn die zu erwartende Last zu hoch ist.
Konzept
Es gibt zwei Arten von MagicMap-Knoten, normale Clienten und "Server" (pibach: vielleicht "Mediator"?). Die Rolle eines solchen Servers kann von jedem Knoten übernommen werden. Die Entscheidung ob ein Knoten als Server oder nur als einfacher Client agiert, soll dabei automatisch erfolgen - vorausgesetzt der Benutzer hat diese Rollenzuteilung vorher entsprechend erlaubt. Damit MagicMap effizient funktioniert, müssen einerseits die Messwerte und Positionen schnell verbreitet werden. Andererseits müssen langfristigere Informationen, wie etwa Karten und Referenzpunkte, dauerhaft verfügbar sein. Ein P2P-Shared-Memory-System wie Daedalus kommt folglich nur für langfristige Daten in frage (pibach: besser: sollten dies berücksichtigen). Kurzfristige Daten sollten direkt an die Knoten gesendet werden, die diese Daten benötigen. Dazu muss jeder Client wissen, welche Knoten an seinen Messungen interessiert sind.
siehe auch MagicMapPosSync
Client-Server-Kommunikation
Um den Clienten die Aufgabe abzunehmen, die tatsächlichen Empfänger von Messwerten zu bestimmen, werde diese an einen Server gesendet. Der Server sollte möglichst im gleichen Subnet sein, um den Routingaufwand zu reduzieren. In diesem Fall ist darüber hinaus auch in der Regel davon auszugehen, dass sich dieser Server für die Messwerte interessiert. Um einen Server nun zu finden, bieten sich eine Reihe von möglichkeiten an:
- der Client sendet ein Broadcast im Subnet aus, das von dem Server beantwortet wird
- der Client kennt einen Server irgenwo und bittet ihn den Richtigen Server für diese Gegend zu finden
Die Gegend in der Sich ein Client aufhält kann wiederrum auf verschiedene Art ermittelt werden:
- der Nutzer gibt sie vor
- der Client übermittelt seine MAC-Adresse, anhand derer Server feststellen können, ob sie Messwerte für dieses Gerät kennen
- der Client misst andere Geräte und übermittelt diese Daten, anhand der Position der anderen kann dann auf die des neuen Clientens gefolgert werden.
JXTA-Kommunikation
Damit die Server untereinander Kommunizieren können, sind sie mit dem JXTA-Netzwerk verbunden. Dieses Netzwerk ermöglicht es einfach Multicasts zu versenden. Dadurch ist es möglich Positionsdaten zu Versenden ohne sich um die Knoten zu kümmern, die die Daten empfangen sollen. Diese Knoten können einfach selbst sich einem Kommunikationskanal abonieren. Ähnlich können auch Suchanfragen nach einem geeigneten Server für eine Position durchgeführt werden. Alle MagicMap-Server haben einen Kanal aboniert, in dem Suchanfragen veröffentlicht werden.
Daedalus
Es sind nicht nur kurzfristige Daten zu übertragen, wie die Positionsinformationen oder Suchanfragen, vielmehr sind Informationen wie Referenzmessungen sehr weichtig. Diese Daten müssen auch dann erhalten bleiben, wenn die Knoten, die diese Daten brauchen für eine Weile nicht an MagicMap teilnehmen können. Dazu werden sie in einem P2P-Shared-Memory-System gespeichert. Dieses sorgt dafür das die Daten unabhängig von den Urspungsknoten gespeichert werden können.
Virtuelle Hierarchie
Für viele Anwendungen ist es Sinnvoll eine Gegend eindeutig beschreiben zu können. Damit dies in MagicMap möglich ist, wird die Welt hierarchisch aufgeteilt. So beschreibt der Sting "Germany.Berlin.Adlershof" die Gegend Adlershof in Berlin. Eine wirklich hierarchische Struktur, wie sie etwa im DNS verwendet wird, ist jedoch Problematisch, da sie keinen ausreichenden Schutz vor Ausfällen bietet. Stattdessen wird die Rolle der einzelnen Knoten in dem hierarchischen Baum nicht von Geräten, sondern von JXTA-Kommunikationskanälen übernommen. Dadurch kann auch im Falle eines Ausfalls ein Vorgestand der Struktur gewährleistet werden.
Architektur
Ein grafische Darstellung ist unter [1] zu finden.
Neuer Ansatz
Es gibt zwei Modelltypen; ein Objektmodell und ein Positionsmodell. Im Objektmodell werden Objekte und ihre Struktur gespeichert. Z.B. werden hier Karten, Agenten, Access Points, Clients und Informationsknoten sowie deren Relationen gespeichert. Im Positionsmodell werden die Positionen von Knoten bezüglich einer Karte verwaltet. Zu jeder Karte gibt es ein Positionsmodell. Die Positionen beschreiben dann welche Koordinaten ein Knoten auf einer Karte hat und wer diese Position berechnet (oder gesetzt) hat. Durch die Trennung von Knoten und Positionen ist es möglich das ein Knoten mehrere Positionen haben kann. Dies ist wichtig da ein Knoten auf mehreren Karten seien kann und verschiedene Teilnehmer verschiedene Positionen berechnen können.
Alle Objekte, Positionen, Knoten und Relationen haben folgende Attribute:
- Typ: Jedes Objekt hat einen Typen.
- ID: Jedes Objekt hat eine Eindeutige ID. Die ID hängt vom Typ des Objektes ab. WLan-Geräte bekommen ihre MAC als ID (oder den MD5 davon), Informationsobjekte bekommen ihre URL als ID.
- Zeitstempel: Jedes Objekt hat einen Zeitstempel. Dies ist der letzte Zeitpunkt einer Aktualisierung des Objektes.
- Lease: Jedes Objekt hat eine Gültigkeitsdauer. Wird diese überschritten kann das Objekt gelöscht werden. -1 heißt das Objekt wird nie automatisch gelöscht.
Knoten:
Knoten beschreiben Ressourcen. Diese können physisch oder informatorisch sein. Das Basismodell kennt folgende Knoten:
- MagicMacDevice
- MagicAgent
- MagicMap
- ...
Relationen:
Relationen verbinden Knoten. Zusätzlich können Relationen auch eigene Attribute besitzen. Relationen beschreiben semantische Beziehungen zwischen Knoten. (Die Semantik ist aber impliziet?)
Positionen:
Positionen beschreiben die Koordinaten die ein Agent berechnet oder gesetzt hat eines Knotens auf einer Karte. Positionen werden von einem Agenten angelegt und gehören diesem. So kann jeder Teilnehmer wählen welche Positionen er benutzen möchte (und es ist möglich in späteren Versionen die Berechnung der eigenen Position zu delegieren).
Alle Objekte werden als Tupel in einer Art Tuple Space gespeichert. Dieser wird für unsere Zwecke angepasst. Alle Objekte werden als Tuple folgender Form gespeichert (an das JSON Format angelehnt):
{type:<TYP>, ID:<ID>, expiration:<LONG>, lastWrite:<LONG>, attributes:[<ATTRIBUTE>*]}
TYPE := <ALPHANUM> | <ALPAHNUM>.*<ALPHANUM>
ATTRIBUTE := {name:<ALPAHNUM>, time:<LONG>, value:'<STRING>'}
Peers benutzen den Objektraum als gemeinsamen Speicher. Sie können Tuple anlegen, ändern und löschen. Konflikte werden bewusst nicht vom System aufgelöst, es wird immer die Aktion mit dem aktuellsten Datum ausgeführt (TODO: Uhrenabgleich der Peers ist dann wichtig!). Die Peers kommunizieren indem sie sich einen oder mehrere Objekträume teilen. Es gibt einen Objektraum für alle Knoten und Relationen und ein Objektraum pro Karte für die Positionen. Plugins etc können weitere Räume anlegen um z.B. Interessengruppen oder Chat etc zu implementieren.
