Dive Applications

Reference Document
Web site <http://www.sics.se/dive/manual/application.html>

Emmanuel Frécon - <emmanuel@sics.se>
Olof Hagsand - <olof@sics.se>
The Swedish Institute of Computer Science, Stockholm, June 1997

1. Introduction

This document contains a few explanatory notes about the main Dive applications.

2. diva

"diva" is the most useful Dive application. It introduces a new actor which is the virtual representation of a real user, i.e. the one who started "diva". This actor is often called "person actor" or simply "person". The new actor is associated with a body icon, i.e. the virtual body of the user.

Once the actor and the body icon are created, "diva" install in the Dive/Tcl interpreter of the actor specific new Dive/Tcl commands and Tk (see [1]) possibilities. "diva" chooses a script depending on the name used to start it or one of its command line arguments (i.e. -init_script). This script is then run once. It typically contains Tk commands which build the graphical user interface of "diva". By default, "diva" runs "blind_init.tcl", which creates a user interface which do not have any rendering window, but has full access to the Dive/Tcl possibilities. Among other things, "blind_init.tcl" allows the user to communicate with live audio with the other participants and to move from one world to another. When the "diva" binary is called vishnu (for example, by creating a symbolic link to "diva", called "vishnu"), "diva" will choose the script "vishnu_init.tcl", which will add a rendering window, more vehicles, etc. More information on the functionalities of "vishnu" can be found in [2].

Ideally, there would be one script for each kind of application. A Dive viewer to browse the WWW would not have the same user interface than a Dive viewer aimed at being connected to a Head Mounted Display.

3. diveserver

The "diveserver" is the Dive application offering naming services. The "diveserver" listens for requests on a specific multicast address and a UDP port. All Dive applications which will request the "diveserver" for a given name (typically containing a world name and a version number) will get back the same answer, i.e. a multicast group on which all further communication will take place.

The "diveserver" multicast group has recently been extended to an information channel onto which all Dive applications regularly "ping" the different multicast groups that they have joined. Any other application can the join this group and treat this information.

4. proxyserver

Originally, the "proxyserver" was designed as a bridge between a network of multicast capable workstations and some clients missing multicast capabilities. It accepts connections from Dive clients which will send join and leave information to the "proxyserver". On reception of a "join" message, the "proxyserver" will effectively join the multicast group and register which multicast group the client is member of.

Then, all multicast traffic from regular Dive peers will be forwarded to the "proxyserver" clients which have declared being member of that group. Symmetrically, all traffic from one client, destinated to a given group, will be forward to all the other clients that are members of that group and to the multicast group.

Recently, the "proxyserver" has been extended in order to build the DiveBone. A "proxyserver" can connect to another "proxyserver" and all traffic will be symmetrically forwarded between the two proxyservers. By connecting several proxyservers together, isolated islands of multicast capable networks can be connected together and Dive peers situated on those islands can join the same session. The "proxyserver" listens to the "diveserver" control channel in order to detect which multicast groups it should joined. More information on the DiveBone can be found in [3].

The new "proxyserver" can also accept controlling clients, which can be used for real-time network analysis. See the following section for more details.

5. proxy_client.tcl

"proxy_client.tcl" is a front end to the new "proxyserver". It is an application entirely written with Tk (version 4.2, in order to be able to use socket communication). It opens a socket connection with a running "proxyserver" and is able to send commands and receive information from that "proxyserver", including:

• Ask the "proxyserver" to open a new tunnel with another "proxyserver".
• Ask the "proxyserver" to send back its current status.
• Ask the "proxyserver" to send back the different groups it is member of and the different Dive clients directly connected.
• Ask the "proxyserver" to regularly send back statistics with the number of bytes sent and received to and from each group and client. Statistics can be detailed down to each application-level entry.

All information sent back by the "proxyserver" is visualized in a user-friendly way, easing network analysis tasks.

6. mini

"mini" is the minimal Dive application, it joins a world and will live in this world without influencing it. "mini" is only linked with the core Dive libraries, see [4] for more details.

7. divesh

"divesh" is the DCI (Dive Client Interface) shell, see [5] for more details.

References

[1] Tcl and the Tk toolkit, John K. Ousterhout, Addison-Wesley Publishing Co., 1994

[2] Emmanuel Frécon and Olof Hagsand, "A primer to the vishnu Tk interface", <http://www.sics.se/dive/manual/vishnuhelp.html>

[3] Emmanuel Frécon, "An Overview of the DiveBone", <http://www.sics.se/dive/divebone/>

[4] Emmanuel Frécon and Olof Hagsand, "Dive Architecture", <http://www.sics.se/dive/manual/architecture.html>

[5] Emmanuel Frécon, Olof Hagsand, "The Dive Client Interface", <http://www.sics.se/dive/manual/dci.html>