2.2 Kommunikation

Das folgende Diagramm (vrml.org 97 (2)) gibt einen Überblick über die Kommunikation zwischen Objekten auf zwei über ein Netzwerk verbundenen Rechnern. Auf beiden Rechnern sind sowohl lokale als auch verteilte Objekte vorhanden, wobei die lokalen Objekte nur lokal (sic) miteinander und mit den verteilten Objekten auf demselben Rechner kommunizieren können, während sich die verteilten Objekte auch über das Netz mit verteilten Objekten auf dem anderen Rechner austauschen. Die verteilten Objekte sind jeweils in eine Zone gruppiert.

Hierbei sollte zunächst dem Eindruck entgegengewirkt werden, daß es sich hier um eine zentralisierte Client-Server Struktur handelt. Dies ist zwar bei entsprechender Implementation der MUtech durchaus machbar, ist aber grundsätzlich nicht vorgesehen. Der Standard schlägt vielmehr eine Implementation vor, in der eine MUtech-Komponente auf jedem einzelnen beteiligten Rechner besteht, wobei die einzelnen MUtechs untereinander Daten austauschen. Die obige Abbildung ist also nicht so zu verstehen, daß die Objekte von beiden Rechnern aus dieselbe MUtech zugreifen, vielmehr symbolisiert der eine orangene Kasten, daß von beiden Rechnern aus auf die eigene Instanz derselben MUtech-Implementation zugegriffen wird.

Bei der Kommunikation von verteilten Objekten über mehrere Rechner wie sie oben dargestellt ist stellt sich nun ein grundlegendes Problem. Um allen beteiligten Benutzern dieselbe Szene zeigen zu können, müssen auf jedem Rechner Instanzen aller in der Szene vorhandenen (verteilten) Objekte vorliegen. Wie aber, das heißt, von wo aus wird nun aber ein spezielles Objekt kontrolliert? Würde man unmittelbare Veränderungen an einem Objekt an jeder Instanz zulassen, wäre ein konsistentes Verhalten dieses Objekts, gerade bei längeren Verzögerungszeiten auf dem Netz, nicht zu garantieren. Daher gibt es für jedes Objekt zu jedem Zeitpunkt immer nur eine Instanz auf einem der beteiligten Rechner, bei der die Kontrolle liegt. Daß dies nicht bedeutet, daß ein Objekt immer nur von von einem Benutzer manipuliert werden kann (was die ganze Sache mit der Verteilung ad absurdum führen würde), wird deutlich, wenn man das Konzept von Pilot und Drone betrachtet.

2.2.1 Pilot / Drone
In einer Menge von verteilten Instanzen eines Objekts gibt es immer genau eine steuernde, kontrollierende Instanz. Diese wird als Pilot bezeichnet, alle anderen als Dronen. Für jede Zustandsänderung des Objekts oder für die Ausführung einer Handlung ist es der Pilot, der die Änderung emittiert, und alle seine Dronen replizieren sie (vrml.org 97 (1)).
Auf welchem Rechner liegt nun die Kontrolle über ein bestimmtes Objekt, wo also liegt der Pilot?
Einfach ist diese Frage zu beantworten bei einem Avatar (s.u.). Da ein Avatar die Repräsentation eines Benutzers in der Szene darstellt, kann der Pilot konzeptionell nur auf dem Rechner liegen, von dem aus der jeweilige Benutzer sich durch die Szene bewegt. Anders liegt der Fall bei anderen Objekten. Man betrachte beispielsweise den Fall des Würfels in dem Monopolyspiel aus dem Szenario. Hier liegt 'reell' die Kontrolle über das Objekt (den Würfel) immer bei dem, der gerade mit Würfeln dran ist, der den Würfel in der Hand hält. Die Kontrolle ist also nicht fest einem Benutzer (und damit einer Objektinstanz) zugeordnet, sondern wechselt im Zeitablauf. Tatsächlich ist die Zuordnung von Pilot und Drone in Living Worlds nicht statisch. Der Status eines Piloten kann je nach Bedarf von einer Instanz auf eine andere übergehen. Um die Konsistenz zu wahren ist jedoch garantiert, daß zu keinem Zeitpunkt mehr als eine Instanz eines Objekts in einer Zone Pilot ist.

An dieser Stelle lohnt es sich, noch einmal einen Blick auf das obige Diagramm zu werfen, um den genauen Fluß von Informationen durch die Objektinstanzen zu verstehen.
In diesem Beispiel gibt es genau zwei verteilte Objekte, SO#1 und SO#2. Der Pilot von SO#1 liegt auf Client A, der von SO#2 auf Client B.
Man stelle sich nun der Einfachheit halber vor, SO#1 und SO#2 seien die Avatare der Benutzer von Client A und Client B, die miteinander kommunizieren möchten.
Wenn nun SO#1 eine Nachricht an SO#2 schickt (z.B. "Hallo Benutzer B"), so geschieht folgendes: Der Pilot von SO#1 auf Client A gibt die Nachricht an die Drone von SO#2 auf demselben Client. Diese repliziert die erhaltene Nachricht an ihren Piloten, d.h. die Nachricht wird von der MUtech über das Netzwerk an die Pilotinstanz von SO#2 auf Client B weitergereicht (um so einen identischen Informationsstand von allen Instanzen des Objekts zu sichern). Der Pilot von SO#2 (auf Client B) kann nun entscheiden, ob er auf diese Nachricht in irgendeiner Form reagieren möchte. Tut er dies in Form einer Antwortnachricht, so läuft diese über denselben Mechanismus, jetzt über die Drone von SO#1 auf Client B, zurück. Tut er dies in Form einer Änderung des eigenen Zustands (z.B. der Veränderung des Gesichts hin zu einem Lächeln), so ändert er seinen Zustand entsprechend, die Änderung wird zur Drone auf Client A repliziert, wo sie schließlich vom Pilot von SO#1 beobachtet und wahrgenommen werden kann.

Der Vollständigkeit halber seien nun noch kurz die Begriffe Avatar und Bot definiert.

2.2.2 Avatar / Bot
Ein Avatar ist, wie schon erwähnt, die Repräsentation eines Benutzers in einer Szene. Der Benutzer selbst sieht seinen Avatar typischerweise nicht (es sei denn, für sein Zimmer hat jemand einen Spiegel entwickelt), er ist aber natürlich sichtbar für andere Benutzer in der Szene. Der Avatar wird unmittelbar durch den Benutzer kontrolliert, jede seiner Bewegungen in der virtuellen Welt sind Aktionen des Avatars.
Ein Bot ist wie ein Avatar ein aktives Objekt. Anders als ein Avatar wird ein Bot aber nicht von einem Benutzer direkt gesteuert, sondern typischerweise durch ein Skript. Ein klassischer Roboter wäre also ein Bot, ebenso ist aber auch der BirdBot im Szenario ein solcher.

Nachdem diese Grundlagen gelegt sind, kann sich der folgenden Abschnitt nun endlich mit der zentralen Komponente für die Kommunikation zwischen verteilten Objekten in Living Worlds beschäftigen.