Implementation overview

and achieving fate-sharing between peer-specific aspects of two associated objects; and

• the poverty of the attribute model (simply corresponding to a get and a set opera- tion) compared with, for example, a distributed database which would include locking and the option of asynchronous notification of changes.

The distribution system and communication libraries were written specifically for MASSIVE-1, however the design could also have been realised in a number of com- mercial or research-oriented distributed systems though with varying degrees of awk- wardness. The exact implementation details have little impact on the work presented in this and the following two chapters. The paper [Greenhalgh, 1994] includes some additional implementation details of MASSIVE-1 and the underlying system while [Greenhalgh, 1996] includes some more general reflections on distribution paradigms and the evolution of MASSIVE-1 and MASSIIVE-2.

4.4. Implementation overview

This final section introduces the overall network software architecture of MASSIVE-1 using the communication model described in the previous section. More detail of the most important aspects of the implementation are presented, with evaluation, in chapters 5 and 6.

Summarising from section 3.2, the background against which the spatial model is defined comprises worlds - which are disjoint spaces within which communication can occur - and objects - which are present within worlds and which are potential pro- ducers and consumers of information (which may represent human participants or computer programs). The key concepts of the spatial model itself are medium, aura, awareness, focus and nimbus (supplemented by adapters and other tools). In the design of MASSIVE-1 these various concepts are mapped onto and realised in terms of two fundamental relationships:

• the relationship between an object and the world in which it is present; and • the relationship between two objects.

The former relationship deals principally with the medium and aura components of the spatial model of interaction, and is explored in detail in chapter 6 from a computa- tional and networking perspective. The latter relationship deals with awareness, focus and nimbus and is dealt with in chapter 5 from a more social and user-based perspec- tive. The remainder of this chapter introduces these two relationships and shows how they fit into the total system.

Figure 11 on page 44 shows an overview of MASSIVE-1’s communication architec- ture, focusing on a single user, A. Each box is a separate process and each interface is labelled with its type (the unlabelled interfaces have a null type).

On the left are the processes which are local to user A: their master client (which must be a text or graphical client); a representative slave client (e.g. an audio client); and a trader process which is a simple attribute-based trading service as found in ODP. Slave clients use the trader to locate the appropriate master client based on the con- trolling user’s name. Each client creates a local traderc (trader client) interface and connects this to the trader’s traders (trader server) interface which has a well-known, preconfigured address. The master client registers interface offers with the trader

4.4. Implementation overview

which are subsequently passed on the slave clients in response to their requests. Each master client has a location interface and a presence interface to which its slave cli- ents connect (via null interfaces). The location interface communicates the user’s cur- rent world, location and orientation to the slave clients while the presence interface conveys information about the user’s current aura, focus and nimbus settings.

On the right are the remote processes: an aura manager process and a representative remote client (e.g. another user’s client process for the same medium). Every client process has its own aura interface with which it connects to an aura manager process (for simplicity A’s slave client’s aura interface is not shown in figure 11 on page 44). Many aura manager processes may exist, each being responsible for a different set of virtual worlds - the process of locating the appropriate aura manager is described in chapter 6. The aura interface includes attributes which describe the client’s spatial model aura to the aura manager. This information includes the name of the world, the medium and the location and size of the aura. The aura manager continuously checks for collisions between auras in the same world and medium, and notifies the processes concerned via their aura interfaces.

When two process have been notified of an aura collision they establish a direct con- nection between the corresponding peer interfaces (the locations of these interface are passed on by the aura manager when the collision occurs). The peer interface includes the core facilities for negotiating awareness. The actual interface used (denoted by

traders

Slave client A

traderc

location

traderc aura aura

Aura Manager Master client A peer+ Client B peer+ Trader traders

Local to user A Remote

Figure 11: overview of MASSIVE-1’s communication architecture focusing on user A

presence

peer+

4.4. Implementation overview

peer+ in figure 11 on page 44) will be a subtype of peer which includes additional

medium-specific operations and attributes (e.g. geometry for the visual medium). The peer processes use this direct connection to negotiate awareness levels and to exchange medium-specific information. As illustrated in the figure the same peer interface may be connected to many other processes as a result of multiple concurrent aura collisions.

To recap, when a user joins a MASSIVE-1 session they begin with a master client. This registers with the local trader and then contacts a well-known aura manager process and passes on (and keeps up to date) its world, medium and aura information. Additional slave clients may also be started, which use the trader to find and attach to the master client, and then contact the aura manager in the same way. All objects (such as user client processes) which are in the same world will be connected to the same aura manager; this performs aura collision tests and notifies them of aura colli- sions as they occur. The objects then establish direct peer connections which they use to negotiate awareness levels and to interact in specific media. In the case of user cli- ents this information is presented to the user as described in section 4.1. When objects move out of aura range the aura manager notifies them of this and they tear down the direct connection, removing the other object from their local view of the environment (in that medium).

The final thing to note about MASSIVE-1 concerns provision of non-user world con- tent such as rooms, gateways, adapters and other tools. Although much of the design of the spatial model and MASSIVE-1 is motivated by consideration of communica- tion between people it is not restricted to this. The model is framed in terms of “objects” which may be user embodiments in the virtual world or could as easily be background scenery, software agents or aspects of an application’s user interface. Aura, awareness, focus and nimbus are still relevant concepts. For example, a chair’s focus might be zero but it still has a nimbus in one or more media which allows other objects (such as users) to be aware of it.

Non-user objects join and interact with the aura manager and with remote peers in exactly the same way as user clients, described above (except that they do not need to make use of the trader). They use the same aura and peer interfaces and maintain the same aura and awareness relationships. To reduce the number of processes required by the system (and the corresponding use of system resources) MASSIVE-1 has a standard world server process which reads a configuration file and creates and main- tains appropriate aura and peer interfaces for a number of objects in the virtual world. The objects created by this process are mainly passive although they all support awareness negotiation. Objects can have representations in all three main media (text, graphics and audio) or a subset of them. Objects can also function as portals or adapt- ers. The only medium-specific behaviours supported by the world server are realtime audio (generated from audio sample files) and selection between a number of graphi- cal appearances, both according to the observer’s awareness of the object. The mes- sage board and text to speech convertor have more complicated behaviours and are implemented as independent processes. However the method of interaction is the same.

This concludes chapter 4 which has introduced MASSIVE-1. The next two chapters examine and evaluate key components of its implementation of the spatial model of interaction. Chapter 5 considers the awareness relationship and the way in which this is presented to the user. Chapter 6 considers the aura relationship, which is formalised

4.4. Implementation overview

as “spatial trading”, and the corresponding network resource requirements. Given the broad scope of this thesis some details of the implementation have been omitted for the sake of brevity. The interested reader can find additional details in [Greenhalgh, 1994]. Alternatively they may wish to contact the author to obtain an (unsupported) version of MASSIVE-1 for SGIs (IRIX-5.x only).