Die Abkürzung DIVE steht für "Distributed Interactive Virtual
Environment", also "Verteilte Interaktive Virtuelle Umgebung".
In einer solchen Umgebung können sich Nutzer in einer 3D-Welt treffen
und kommunizieren.
Es wurde vom schwedischen Institut für Informatik (SICS) entwickelt.
Das System besteht aus Servern, welche die so genannten "Welten"
und die zugehörigen Nutzer aufbewahren und mit den angebundenen Klienten
über eine IP-Multicast-Adresse kommunizieren.
Die Klienten sind Browser-Programme, die mit einem DIVE-Server verbunden sein
können, und auch Ressourcen (Welten, Bilder, Sound, etc.) vom lokalen
Rechner oder anderen Computern des Internet laden können. Dies geschieht
per HTTP oder FTP. Sobald die Klienten zu einer Gruppe gefunden haben,
kommunizieren sie gegenseitig, also unabhängig vom Server.
Zusätzlich kann noch ein Proxy-Server genutzt werden, der im
Multicast-Netz hängt und mit anderen Klienten Einzelverbindungen
unterhält, die nicht an einem multicast-fähigen Netz angebunden
sind.
Die Welten bestehen aus verschiedenen geometrischen Objekten, aber auch aus
Texturen, Material-Definitionen und Lichtern. Außerdem gibt es
Gateways, die Verbindungen zu anderen Welten darstellen, und so genannte
Billboards, die sich immer nach dem Blick des Nutzers ausrichten.
Jedem Objekt kann zusätzlich ein Verhalten zugeordnet werden. Das ist
ein Tcl-Skript, das andere Objekte oder sich selbst verändern
(verschiebt/unsichtbar macht etc.) oder erzeugen kann. Dies geschieht jeweils
bei Auslösung eines Events oder Ablauf eines Timers.
Eine Welt ist letztlich ein Szenegraph, also eine Hierarchie von Objekten.
Diese wird definiert in Dateien mit DIVE-eigenen Formaten oder auch in
VRML-Dateien.
Eine Welt besteht natürlich auch aus Personen, in der 3D-Welt als
Avatare bezeichnet. Sie bestehen aus geometrischen Objekten und gehören
immer zu je einem DIVE-Klient-Programm. Mit denen bewegt sich ein Nutzer
durch die Welt und kann mit ihr interagieren. Sie können aber auch
unabhängig von einem Nutzer sein. Sie haben eine Schnittstelle und
stellen Dienste bereit.
Beim Start kontaktiert der Klient zuerst den DIVE-Server. Dann holt er sich
die Welt aus einem File oder über einen angegebenen URL.
Wenn die Welt auf dem DIVE-Server schon vorhanden ist, wird er in die
zugehörige Gruppe eingetragen und kann sich die Welt von anderen
Klienten kopieren und dann tauschen sie sich gegenseitig über die
Veränderungen darin aus.
Wenn sie neu ist, wird eine Gruppen-Adresse erzeugt, die Welt erstellt und
der Klient in die Gruppe eingetragen.
Alle Objekte, die zur Welt gehören und verteilt werden können
(sog. Entities) werden zuerst lokal erstellt und eingerichtet. Dann werden
sie mit je einem Befehl verteilt auf die Klienten, die gerade diese Welt
nutzen.
Alle Klienten haben jeweils eine eigene Kopie der Welt und der
zugehörigen Objekte lokal und jede Veränderung muss deshalb auch
allen Klienten mitgeteilt werden. Dies geschieht per Multicast, damit alle
gleichzeitig auf dem neuesten Stand sind. Dafür gibt es spezielle
Befehle mit sonst gleicher Bedeutung und ähnlichen Namen wie die
lokalen Versionen.
Zusätzlich kann jeder Klient den aktuellen Zustand abfragen
("Request") und erhält eine aktuelle Kopie von einem Klienten
("Update") als Antwort.
Über so genannte "Properties" können Klienten Daten
unabhängig von grafischen Objekten verteilen. Klienten können sich
auch gegenseitig Kommandos schicken, die der andere ausführen soll.
Eine Erweiterung dazu ist das "DIVE Client Interface" (DCI). Es
ermöglicht die Kommunikation zwischen DIVE-Applikationen (Klienten und
Server). Dabei schickt ein Klient einen (Tcl)-Befehl an den Server, der dann
die Rückmeldung dazu zurück gibt. Der Server informiert auch
über aufgetretene Fehler bei Ausführung des angegebenen Kommandos
und angefallene Events, für die sich der Klient registriert hat. Der
Server hier ist ein DIVE-Programm und nicht der Gruppenverwalter!
SID2 ist ein verlässliches Multicast-Protokoll zur Kommunikation in
Gruppen über das Internet per UDP/IP. Es basiert auf "negative
acknowledgement" und global eindeutigen Identifikatoren für die
Objekte, die übers Netz gehen. Es wird sehr viel Multicast eingesetzt um
die Netzwerklast zu minimieren.
Darum antwortet immer nur das nächstgelegene Gruppenmitglied mit der
neuesten Version auf eine Anforderung. Der Nächstgelegene wird bestimmt
durch Round-Trip-Time und Timeouts. Die Antwort auf eine Anforderung wird
auch immer per Multicast geschickt, damit die anderen Klienten nicht auch
etwas schicken müssen und um mögliche gleiche Anforderungen in der
Zukunft zu begrenzen.
Der Absender muss die Nachricht nicht speichern bis alle sie bekommen
haben; bei nochmaliger Anforderung wird sie einfach neu erstellt und ist
somit aktuell.
Jede Nachricht, mit der Objekte verschickt werden, besteht aus einem Header mit u.a. folgenden Elementen:
und den Objekt-Daten selber in einem Puffer mit Hashtabelle.
Die Datenrate der Nachrichten wird mit einem Token-Bucket-Algorithmus
geregelt. Die Parameter dazu (Bucket-Größe und Rate) können
eingestellt werden.
Die Flusskontrolle basiert auf "positive acknowledgements" wie
in TCP/IP.
Zur Nutzung von Gruppen gibt es einen Nameserver, mit dem sich jeder Teilnehmer verbindet. Dieser verwaltet die Gruppen anhand von Namen und gibt die Adressen dazu heraus. Er kennt zu jeder Gruppe die zugehörige Welt und die Klienten, die dazu gehören. Jeder Klient kann einer Gruppe beitreten und sie verlassen. Nachdem die Klienten ihre Gruppe kennen, verständigen sie sich ohne Server miteinander. Die Gruppe bleibt solange bestehen, wie es Klienten gibt, die sie nutzen. Auch wenn der Klient, der sie angefangen hat, schon längst ausgetreten ist.
Weiterhin bringt SID ein Callback-Interface mit. Ein Klient kann also eine
Prozedur angeben, die bei ihm ausgelöst wird, sobald woanders ein Event,
Request oder Update auftritt. Bei der Ausführung kann auch ein neuer
Thread innerhalb dieser Applikation gestartet werden.
Zusätzlich zum Callback per Events kann ein Klient auch RPC nutzen. Er
kann remote eine Prozedur aufrufen und auch für eine bestimmte Funktion
einen RPC-Callback eintragen.
Hier verbindet sich ein Klient mit einem Server über eine TCP-Verbindung
mit festem Port. Der Klient schickt dann darüber DIVE/Tcl-Befehle und
bekommt die Ausgabe des Befehls zurück.
Das Paket selber besteht aus einer Magic-Number zur Identifikation des
Protokolls, der Paketlänge, der Kanal-Nummer, jeweils 32 Bit, und dem
String mit dem Kommando oder der Antwort.
Diese Pakettyp enthält einen String mit dem Kommando, abgeschlossen mit einem Enter-Zeichen (Carriage Return). Darin kann man auch eine Prozedur eintragen, die ausgeführt wird bei einem bestimmten Event. Diese Prozedur wird dann mit übertragen.
Bei diesem Pakettyp gibt es drei verschiedene Inhalte ("Kanäle"):
Dieses Antwort-Paket kann auch von einem Objekt in der Welt geschickt werden, das mit dem Klienten Kontakt halten will. Üblicherweise wurde dieses Objekt vom Klienten selber mit einem Tcl-Skript ausgestattet und in die Welt eingefügt.
| Inhalt Vortrag | Letzte Änderung: 24.04.2003 |
| E-Mail: Stefan Ziegler |