In this paper a sample of different network-based Virtual Environments and
Virtual-Environment-like applications is presented.
The emphasis is put on the properties of the network protocols employed
and the problems that arise for the specific applications.
The most crucial problem is the limited bandwidth of the Internet,
which claims for highly optimized network protocols.
However, this often leads to domain specific protocols,
making a standardization of the internet difficult.
This paper describes "DIS", the currently most important military/industrial
network protocol for Distributed Virtual Environments, as well as some ad-hoc
protocols usually not mentioned in scientific reports, like the ones
used by "Quake", "Alphaworld" or "CitySpace".
With the boom of the Internet during the last years, the number of Internet
users has grown almost exponentially, as well as the number of available applications.
While at first the Internet was introduced to exchange simple messages,
the usefulness of browsers capable of transmitting graphics and sounds was
discovered very soon. With the development of distributed Virtual-Reality or
Virtual-Environment-applications, where users should be able to navigate avatars
through a virtual world stored on geographically distant sites,
the amount of data to be transmitted over the Internet has grown
to significant proportions. The popularity of network-capacle Virtual-Reality-like games
(e.g. Doom or Quake) also plays a considerable role.
The growing number of network based applications has soon shown the
bandwidth limits of the Internet, leading often to inacceptable delay times.
This underlines the importance of efficient network protocols for the exchange
of data among different sites.
In this paper a sample of Virtual Environments and Virtual-Environment-like
applications will be presented, with emphasis on the network protocols employed
and the difficulties encountered.
One of the most heavily researched network protocols is the
"Distributed Interactive Simulations - protocol",
also called DIS -protocol, approved as IEEE-1278 standard protocol.
2) SIMNET and DIS
The development of the DIS-protocol was initiated in 1989 by the
United States Department of Defense (DoD), as a replacement for the
previously used SIMNET-protocol. The purpose of this protocol is
to allow the connection of geographically distant computer-driven
and human-driven simulators for
- "tactical team training"
- (training of collective skills)
- "combined arms training"
- (dissimilar simulated combat vehicles operate together)
- "combat development"
- to research and develop hypothetical weapon systems,
without having to build full-scale hardware prototypes.
As these simulations are military, the entities (the participating simulators are called
that way) are e.g. tanks, airplanes or air-defense units;
the Environment must have a notion of
"time-of-day" (to simulate dawn- or nighttime missions),
"ambient temperatore" (for 3D spectral rendering), and
"wind directions" for a realistic representation of battlefield smoke.
To meet these requirements, the DIS-Protocol uses a set of specialized
PDUs (Protocol Data Units), the most important being:
- The "Entity-State-PDU":
- it describes the state of an entity and provides
information about the current activity of each entity.
It contains per-class data, valid for all instances of a specific class,
and per-instance data, which contains the parameters for each entity.
Per-class-data are e.g.
Per-instance-data are e.g.
- the entity type (such as.: F-16-aircraft),
- the bounding volume
- geometry desctriptions, such as the number
of articulated parts and how they are linked together.
- linear and angular velocity
- the angular values of the articulated parts.
- The "Fire-PDU"
- is sent when a weapon is triggered (and a munition-entity is on its way),
to inform all other simulators of the event.
- The "Detonation-PDU"
- describes the detonation of a munition or the crash of an entity.
- The "Emission-PDU"
- is used to simulate radar locks or electronic countermeasures
(such as radar jams).
The DIS-protocol follows the so called "distributed-approach", where every simulator
that wants to join the (Virtual) Environment has to locally store a description
of the whole Environment and of every entity present, in its memory.
This is memory consuming, but allows to apply a technique called "dead reckoning":
- In dead reckoning, each site computes the current position and orientation for
its own vehicles based on their simulation algorithms; position and orientation
of the remote vehicles is approximated based on the past position, orientation and
time derivates of position and orientation stored for these entities.
However, such an approximation is also performed for ones own entities, and when the
difference between the appoximated values and the simulation-computed ones exceeds
a certain threshold, an Entity-State-PDU is sent to all other sites, to allow them to
calculate a correct approximation for the vehicles of this site.
Large Scale Distributed Multiuser Virtual Environments.
In 1992, the Advanced Research Project Agency (ARPA) startet a project called
, which is considered the state-of-the-art, to evaluate the old SIMNET and the DIS-protocol.
During the tests recently developed computer-driven and manned simulators were integrated.
- While the limit of the SIMNET protocol were
200 entities, the DIS-protocol
supported up to 5400 entities,
although the goal was to support 8000 entities. Nevertheless (in 1993) this was a world
record for the highest number of entities working in a true Virtual Environment rather
than a simple network loading experiment.
These tests showed that the bulk of the network load consisted of Entity-State PDU's,
as many simulated vehicles were highly dynamic (such as jets) and performed
high speed maneuvers, thus changing state very rapidly and flooting the
Internet with Entity-State PDUs.
Another problem concerned the determinition of munition hitting an entity.
Missiles with a lock on a target had to deal with erroneous positional
information about the targetted vehicle, if it was a remote one, which showed
to be problematic in close air-to-air combat (missiles, which in reality would
have hit, missed the target).
A further problem concerned the "indirect fire", which is weapons fire directed
at no particular entity. While the triggering of a target-locked weapon concerned
only the collisition-detection between the munition and the targetted entity,
the "indirect-fire"-PDU had to be checked against all other entities in order to determine
if the munition hit one of them.
MÄK Industries, a company which decided to become a provider of DIS-Protocol software,
proposed solutions for some of these problems by introducing concepts not
present in DIS:
- "Migratory weapons":
- "Migratory weapons", or better "migratory objects" introduce the concept of
transfering the computational responsibility for a given entity from one
simulator to another: it enables a site, when receiving a Fire-PDU,
to continue the weapon calculations, therefore allowing a precise target following.
- "Geographic filtering":
- "Geographic filtering" was proposed as a technique for load management,
to overcome the problem that a simulator receives PDU's from all remote
entities, even the very distant ones: by applying a sort of refined range
checking on all incoming PDU's, the ones which are too distant to be rendered
are discarded and so the load on the inner loops of the program running
the simulation is diminished.
- Replacement of the Entity-State-PDU by two other PDU-s
(called "Kinematic" and "Query Response" PDU).
- As the Entity-State-PDU constitutes the bulk of network traffic,
the optimization of this PDU was intended to save great part of the bandwidth.
So the Entity-State-PDU was split in a "Kinematic" and a "Query Response"-PDU.
- The KINEMATIC PDU:
- The intent was to spare all the redundant and static information
from the Kinematic PDU, which should contain only the dynamic
information required by the dead reconing-algorithm, such as
- the position,
- angle-values of the articulated parts.
- The QUERY RESPONSE PDU:
- The Query Response PDU contains the static data, such as the
- entity type,
- bounding volume
- information how the articulated parts are connected together.
So the simulator sites need only request the "Query Response"-PDU once;
after it has been stored in local memory, during the simulation the transmission
of the "Kinematic" PDU suffices to update the informations concerning an entity.
This implies a higher memory need, because the sites have to store a
"Query Response" PDU for each entity (in contrast to the DIS-Protocol,
where the Entity-State-PDU contains all the information about an entity,
so the sites need not store it). However, by sending only the smaller "Kinematic PDU"
on each state change of an entity, MAK afferms that in most situations the reduction
of bits transmitted can exceed 50%.
DIS is being adopted by a continuously growing number of companies, so toolkit
libraries to ease the development of Virtual-Environment simulation software have
Just to pick out some examples:
- which is intended to enable vehicle component modules to be mixed and
matched dynamically at run time.
- a machine-independent toolkit library, which has the intent to enhance
portability and to provide mechanisms for network transmission, load management,
(geographic) filtering of incoming PDU's or automatic generation of PDU's, for example.
Another network-protocol that is currently being used by a high number of users
comes from the entertainment domain: it is the protocol used by "Quake",
a Virtual-Reality-like Run-and-Shoot game.
Quake puts the participating users
in a dungeon-like Environment called "map", where they can control a user avatar
to engage in fights against other human-driven avatars. The network protocol
implemented allows users to connect their computers to any server, which sets up such a map,
thus allowing the geographically distant users to play together (or better: fight against
each other) in this common Environment.
The network protocol has the task to provide a fast information exchange between the
server and the connected clients, to allow smooth gaming.
As the number of exchanged messages is very high, efficient data packets are of crucial
The Quake network protocol has two types of messages:
CONTROL-PDUs contain a message-type-identifier,
a variable-length message and the length of the whole PDU.
The message consists of a single-byte code, followed by code-dependent informations.
The most important Control-codes are called:
- "Accept-Connection / Reject-Connection"
These messages are used to exchange the information needed for game initialization.
As they would crash the client if not received correctly, a reliable transmission is needed,
so the recipient must acknowledge the messages received, otherwise the sender retransmits them.
- First the client sends a Connection-Request to the desired Quake-server (standard port: 26000).
- The server responds with an Accept- or Reject-Connection-message.
- If the connection was accepted, the Accept-Connection-PDU contains the client's
personal port number, through which all the following communication between server
and this specific client will be carried out.
The Accept- or Reject-PDU must be acknowledged by the client.
- The server then sends a big message with the map name, as well as precached models and sounds.
(The clients is supposed to send an acknowledgement).
- Next the server sends another big message containing the order to spawn static
sounds and static entities.
- The client responds with a "Give-Player-Information"-PDU, which contains the
desired name of the player, the colors wanted for the shirt and pants, and a "spawn"-flag
which indicates that the user is ready to play.
- Last, the server sends another big message, containing an order to set the light styles,
the start position and orientation for the client, the specification of the used
monsters and secrets and an order to start the 3D-rendering.
- When the client responds with a "begin"-message, the game starts running,
and the client receives a flood of "Game"-messages.
The Request-Server-Information PDU can be sent from the client to a Quake-server
at any moment, even before setting up a connection; the server responds with
a Give-Server-Information message containing e.g. the maximum and current number of players,
the name of the current environment (map), and the name of the host machine.
GAME-PDU: once the game has started, instead of Control-PDUs smaller
Game-PDUs are transmitted in an unreliable mode (UDP), so no acknowledgements
are required. This allows faster interaction between server and client.
Like Control-PDUs, Game-PDUs consist of a message-type-identifier,
the length of the whole PDU and a message; the latter consists of one or more codes,
followed by code-depentent information.
The most important Game-codes are:
- "Keep-Alive" is used to inform the server that the client is idle, but that the connection
should not be dropped (otherwise, if the client has been idle for a certain amount of time,
the server closes the connection).
- "Disconnect" informs the server that the player has left the game and connection should
- The most important message is the "Client-Movement": it is send from client to server
whenever the player tries to move. It contains the heading/pitch/roll - angles and
the front/right/up-speed entered by the player manipulating input devices such us a
joystick or a keyboard. However, the angles and speed are those desired by the player,
but maybe not these that the physics of the world would allow. The server controls
which movements are feasible for the specific client and then sends back an update,
containing the angle and speed information the server allows the client to perform.
The server sends his update message every 20th of second - one message each 50 milliseconds;
if it isn't possible due to network delays, the player is blocked and cannot move.
This happens because of the way velocity information is handled by Quake: the speed
information sent from client to server consists of integers, and indicates a desired
speed in units per second. For example, if the player indicates a +200 forward speed,
a +10 coordinate information is sent per update, (that should happen every 20th of second.).
So in 1 second, after 50 updates, the player has moved 200 coordinate units.
If these coordinate updates are not received by the client, (e.g. because of network delays,
the player is a "sitting duck" (stuck in its actual position).
Resuming: during game, whenever the player moves, an update message
containing the movement order is send to the server, which sends back update
messages containing the movements granted by the server to the client every 50 milliseconds.
Unfortunately, if the distance between server and clients is high,
and many users are connected, the ping times can easily make the game unplayable.
In face, by analyzing the average ping-times reported by Quake-players using a 28.8k modem,
specifications range from 170 to 300 milliseconds; when using a slower connection even
more than 500 milliseconds, up to 1 or 2 seconds. Only by using ISDN or cable-modems,
average ping times ranged between 75 and 100 milliseconds.
Another problem encountered is the number of simultaneously supported
players in one environment; many users reported that often less than
10 of the (theoretical) 16 simultaneous users could be achieved, because of
overloading of the network-manager.
"Alphaworld" and "Cityspace" are other two applications
that want to allow the user to navigate through a Virtual Environment; however they can only be defined
as Virtual-Environment-like applications, because they are a sort of WorldWideWeb-browsers
capable of displaying an "out-of-the-window-view" of a Virtual World.
4) ALPHAWORLD and CITYSPACE
- In "CITYSPACE" users can send their models (consisting of a wire-frame and a texture),
graphics or sound files (by email or FTP) to the provider of Cityspace, which places
them inside the Environment. The 3D-models are required to be DXF, IV or VRML ascii-files,
and the images or textures should be TIF, PICS or GIF binary files.
The CitySpace-browser then allows to move inside the Environment by clicking buttons.
- "ALPHAWORLD" tries to combine 3D graphics, Internet chat and multiuser avatars to build a
"3D WorldWideWeb", consisting of linked 3D worlds. By clicking on URLs embedded in
objects the links are followed to access 2D home pages or email addresses.
It is possible to communicate with other users by typing text which is displayed
in a box at the bottom of the screen; it is planned to incorporate VoxWare's MetaVoice
technology which creates a mathematical model of human speech rather than compressing
the actual audio waveform. Using so called "Voice Fonts", users should be allowed to alter pitch,
tone and character of their voices, needing only one third of the bandwidth necessary
for conventional waveform transmission and working in real time.
Furthermode, users are able to modify the Environment by placing objects of a library
inside the virtual world, using point-and-click commands.
According to "Worlds Inc." publications, actually more than 100.000 people have taken
a so called "citizenship" in the "Web-of-World communities".
It can be seen that the number of applications to access networked Virtual Environments,
or to combine Virtual-Environments and the Internet, is continuously growing
(however the definition of "Virtual Environment" is not very clear and the
distinction between "Virtual Environent"-applications and
"Virtual Environment-like" applications is not well defined).
The increasing number of Internet users has lead to serious bandwidth problems
concerning most of the network applications.Virtual Environments using own,
dedicated networks do not have such serious problems; however the necessity
for using highly application-specific protocols to best exploit the disponible bandwidth
can be stated in most applications.
"Quake" (played over the Internet) and "DIS"-simulators
(usually using dedicated military networks) both use their own,
domain specific protocols that cannot be used for a general
"multi-purpose" Virtual Environment.
Many problems that arise when trying to allow a large number of users
to simultaneously navigate and interact in wide area networks are still being researched,
and only few succesful efforts to make network standards for Virtual Environments
can currently be found.
Nevertheless this is one of the most heavily researched fields in the last years,
and the number of VR network protocols is supposed to grow rapidly.
Have a look at my homepage
DIS and related topics
Zurück zur Virtual Reality Seminar Page.