Distributed Behaviors in Distributed Simulations 

Presented at the Virtual Reality Systems Conference, 
New York City, 21 October 1993.  

Copyright (c) 1993, Mark D. Pesce.  All rights reserved. 

Introduction

Distribution of behaviors across an internetwork simulation is one of 
the most important issues in the development of simulation systems.  
An implementation of simulation behaviors which lacks the features 
of interoperability, cross-platform execution, and retrieval-upon-
demand would need to be completely rewritten when extended into a 
networked simulation environment.   This paper outlines some of 
the more essential issues involved in the design of such systems.

Behaviors ARE Objects

Over the course of the development of simulation systems, a 
semantic differentiation has been made between objects and the 
behaviors they possess.  This is a false distinction.  
Programmatically, objects can only be known by their behaviors, 
that is:  What is the shape?  What does it intersect?  What does it do 
when I poke it?  How do I render it?  In this sense, objects in the 
virtual world fully conform to the OOP methodology of data + 
methods = object.  Since the behaviors are methods, and since 
the only way we can "know" anything about the object is through an 
inquiry of its methods, it is correct to say that objects are verbs, that 
is, active entities, rather than nouns, or passive entities.  Therefore, 
in the context of the current work, the terms object and behavior will 
be used interchangably.

A worst-case scenario of distributed behaviors 

When designing "thought experiments" for networked systems, it is 
always useful to use the "worst-case scenario" as a design guide.  
What is this worst case scenario?  A network of hundreds of 
thousands, perhaps millions of hosts, some acting as clients, others 
as servers, others as both, all collaborating to create a distributed 
simulation.  These nodes are connected through an arbitrary 
topology which,  like a cellular telephone network, also has a 
dynamic topology.  That is, the arrangement of nodes is not static, 
as it would be in a TCP/IP internetwork, but can change, in a "plug-
and-play" fashion, like AppleTalk.  This represents the "outer 
limits" of networking.  A general solution for this case will serve as 
a specific solution for almost any network.

Virtual Blockbuster

The author is about to describe an extreme example of the kind of 
capabilities that users will be demanding from distributed simulation 
systems.  At the same time, this example defines exactly what the 
market is going to need over the next three to five years.  

IBM and Blockbuster Video have signed an agreement to develop 
"servers" which will allow video delivery into the home.  
Blockbuster understands that with the widespread acceptance of 
video-on-demand technology, video rental stores will become 
unnecessary before the turn of the century.  They have teamed with 
IBM to establish a technical infrastructure to support video-on-
demand products and services.  Blockbuster is not alone; 
TimeWarner, with its own library of content for distribution, and 
Viacom, equally well equipped, also have similar systems on the 
drawing boards.  Silicon Graphics has recently introduced the 
"Challenger" product line of video servers, which could become the 
backbone hosts of such systems, and others will surely follow.

With a distributed simulation database of this media and an effective 
user interface, the application developer might be able to create a 
simulation "space" with a "virtual" Blockbuster Video outlet, 
providing a catalog of thousands or tens of thousands of titles.  The 
user might then be able to "wander" through the outlet, browsing the 
titles, just as in a "real" Blockbuster, calling up promotional clips for 
the films, reviewing cast and directorial information, and might then 
make a selection for delivery through the video-on-demand system.  
This is definitely preferable to a menu-based interface, where the 
user could spend a few frustrating hours trying to track down a title 
which he doesn't know how to find.

The major issue here is not the hardware infrastructure, but rather, 
the network software infrastructure to support video-on-demand.  
This issue breaks down into two separate areas; distributing the data 
across an internetwork, so that each local service office doesn't need 
to contain a complete copy of the video library; and the development 
of effective user interfaces for "browsing" and examination.  Each 
of these are intimately related to the other.

It is possible and desirable to implement a suite of protocols and 
network services which would allow for the creation of a "unified" 
data space, that is, where multiple hosts contribute their specific data 
sets (such as a movie or CD) to the overall environment.  As far as 
the user is concerned, the data exists in one place; but it can be as 
geographically dispersed as desired.  This manner of data 
representation is frequently called cyberspace.  

Suppose a developer wants to write an application which could 
create a "virtual" Blockbuster Video, one which existed only on a 
computer internetwork, and drew from all of the hosts serving video 
for Blockbuster on that internetwork.  The developer would need a 
well-defined set of tools to talk to the network, or, ideally, would 
not even be aware of the network at all.  This is the function the 
application's program interface, or API, which provides services for 
the application developer in a consistent manner, irrespective of the 
type of network, type of data, etc.  The API also provides a sense of 
"place" within the simulation, a "place" where data is represented.  

ISO/OSI and Distributed Simulations

In the framework of the ISO/OSI protocol stack, which defines 
seven "layers" or interfaces between an application on one host and 
an application on another host, we can determine that protocol 
support for distributed simulations, such as the Virtual Blockbuster, 
needs to be provided on the upper three layers of the protocol stack, 
that is, the session, presentation, and application layers.  These three 
layers answer the three "W"s of simulation, "where", "what", and 
"why".  

The following illustration outlines how existing networking 
technology fits into this model.

(Imagine a nice picture here...)                                    

The session layer, layer 5, answers the "where" question by 
providing a methodology for determining the "hard" location (host 
address, file name, position in file, etc.) of an object based upon its 
location in the simulation space.  This function, the "heart" of any 
cyberspace system, binds an arbitrary network topology to a regular 
spatial topology.

The presentation layer, layer 6, answers the "what" question by 
providing the details of the object's construction (data + methods) 
once its location has been resolved by the session layer.

Finally, the application layer, layer 7, answers the "why" by 
providing an event and I/O framework for the simulation.  The 
application layer "makes sense" of the simulation database of objects 
gathered by the presentation layer, and uses it to construct the 
simulation.

Rhetorically, the client-application's process of gathering the 
information necessary to create a simulation can be stated as follows: 
"Is anything out there?  What is it?  How does it behave in the 
context of this simulation?"

In order to create a workable protocol implementation of a 
cyberspace, that is, an internetwork of distributed hosts with 
distributed behaviors that collaborate to create a unified simulation, 
several guiding principles need to be observed.  These are principles 
are identified in the following sections.

Virtual Egocenters

Much of the work in distributed simulation has been done for 
military battle-field readiness simulation trainers, such as SIMNET.  
From the experience of these implementors the concept of the virtual 
egocenter has evolved.  The virtual egocenter is the "self" within the 
simulation, that is, the locus of user-initiated events.  Within any 
simulation, especially a distributed simulation, the location of the 
virtual egocenter is a powerful determinant of the content of the 
simulation.

In SIMNET, each host collaborating within the simulation contains a 
complete copy of the simulation database.  This, however, is 
impossible to achieve in either larger or more general-purpose 
simulation environments.  There's too much data to give every 
participant a copy of the database, especially if this database is 
highly dynamic.  This necessitates the development of another 
methodology for distributed simulation.

"You only care about what you care about"

General purpose implementations of cyberspace will follow another 
rule, which can be deduced from Benedikt's Law - the content of the 
database is determined by the "intent" of the virtual egocenter.  That 
is, those things which "interest" the virtual egocenter are present in 
the local simulation database.  Objects which are of no interest need 
not be present in the local simulation database, even if they exist 
within the scope of the entire simulation.  This can be paraphrased 
as "you only care about what you care about."

Proximal Space

The primary determinant of "intent" in a virtual egocenter is 
proximity.  Those objects which are nearer to the virtual egocenter 
are intrinsically more "interesting", in the context of the simulation, 
than objects that are distant or obscured.

Almost all simulations contain the concept of proximal ordering 
within their simulation databases, even if it's something as simple as 
Z-buffering or range buffering.  However, if this model is extended 
to a host with limited memory and computing resources (something 
like a 3DO or SGI set-top box), proximal ordering becomes much 
more important, since a luxurious cache of objects would quickly 
exhaust the available resources.  Thus, the concept of "proximal 
space" must be implemented in any general-purpose cyberspace.  
This proximal space is highly dynamic, and, ideally, highly adaptive 
to the user's needs in any simulation situation, even "thinking 
ahead" to request objects across the internetwork, from another 
host, before such a request is made by the user.

Holographic Databases

The "holographic" model of storage is a useful guide in the 
implementation of proximal space algorithms in distributed 
simulation applications.  In a holographic photograph, each grain 
"contains" the entire image, but the image preserved within that 
grain is skewed, reflecting most clearly the portion of the image 
which "maps" most directly to the location of the grain.  Proceeding 
away from that center, the image loses resolution, eventually 
becoming almost inseparable from noise.

If the virtual egocenter of a host executing a distributed simulation is 
considered as a "grain" in a holographic photograph, the analogy 
becomes clear.  Those objects in the immediate vicinity of the virtual 
egocenter are well resolved.  Those objects slightly further away are 
still "seen", but in less detail.  Distant objects, if known at all, are 
only vague outlines of their actual essences.

A methodology for clients of distributed simulations must be 
developed which reflects the essence of this analogy. This 
methodology should, ideally, be invisible to the client application, 
handled by the client's interface to the simulation.  The client 
application should not concern itself with which objects are 
proximally important; this information can be derived from the 
requests made to the simulation database.  Thus, algorithms to create 
a "holographic" simulation database should be placed within the 
presentation layer of the simulation application.

The Cyberspace Project

The author has been working on the architecture of the system 
outlined above for almost two years, and has been able to 
incorporate all of these principles into a relatively small 
implementation. It is designed for efficiency, both in terms of 
network bandwidth and available processing power, and is portable 
to any platform with an ANSI-standard 'C++' compiler.

First developed on the Macintosh under AppleTalk, this library has 
recently been ported to SunOS 4.1, using TCP/IP, and is now 
employing the RPC/XDR mechanism for client/server 
communication.  As TIRPC (Transport-Independent RPC) becomes 
widely available, it will be ported to that environment.

A demonstration of the cyberspace server will be available to those 
with Internet access within the next month, and later this year the 
library will become available for license to interested parties.  

Conclusions

Distributed simulation will play an increasingly important role in the 
entire field of simulation systems design.  Before this decade is 
over, it is reasonable to assume that distributed simulations will be 
the norm, and single-host simulations the anomaly.  Current designs 
for simulation systems are not easily extensible into a multi-host, 
internetworked environment.  Therefore, the simulation industry 
will pass through a retooling phase, as its design methodologies are 
adapted to the requirements of distributed simulation.  This retooling 
phase will, most likely, be led by the entertainment industry, which 
will be developing interactive entertainment applications capable of 
managing hundreds, if not thousands of simultaneous users.  The 
hardware infrastructure to support this is already in place; we must 
now adopt a development methodology for simulation software 
which can leverage this infrastructure into useful applications.