-
1.) INTRODUCTION
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.
-
2) SIMNET and DIS
One of the most heavily researched network protocols is the
"Distributed Interactive Simulations - protocol",
also called DIS -protocol, approved as IEEE-1278 standard protocol.
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.- 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.
- position,
- orientation,
- 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.
Related publication:
Large Scale Distributed Multiuser Virtual Environments.
In 1992, the Advanced Research Project Agency (ARPA) startet a project called
"WarBreaker"
, 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,
- velocity,
- acceleration
- angle-values of the articulated parts.
- The QUERY RESPONSE PDU:
- The Query Response PDU contains the static data, such as the
- entity type,
- name,
- 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 become available.
Just to pick out some examples:
-
- Dial-a-tank,
- which is intended to enable vehicle component modules to be mixed and matched dynamically at run time.
-
- VR-Link,
- 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.
-
3.) QUAKE
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 importance.
The Quake network protocol has two types of messages:
- "Control"-PDUs
- "Game"-PDUs
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:
- "Connection-Request"
- "Accept-Connection / Reject-Connection"
- "Give-Player-Information"
- "Request-Server-Information"
- "Give-Server-Information"
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"
- "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).
- "Keep-Alive"
- "Disconnect"
- "Disconnect" informs the server that the player has left the game and connection should be dropped.
- "Disconnect"
- "Client-Movement"
- 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.
- "Client-Movement"
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.
-
4) ALPHAWORLD and CITYSPACE
"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.
- 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".
