Entity Identifiers

In a single simulation there may be hundreds or more of entities. These are items that can be moved by a DIS simulation. The central problem is tying the entities to a unique ID that the game can use.

A simulation may have hundreds or even thousands of entities in one virtual world. As a practical matter we need a way to uniquely identify each entity in the world. Before we can inform an entity that its position has been updated we need a way to uniquely identify the entity.

When DIS was designed a goal was for it to not have a central server. Simulations had to work out identifier issues among themselves, in a distributed way, in the best way possible. The solution hit upon was to use a collection of three unsigned shorts that would, together, uniquely identify an entity. These three numbers are the site ID, application ID, and entity ID.

The simulation manager can during the planning phase assign identifiers for the site and application. For example, the simulation manager can specify these values for sites:

Site	ID
Norfolk	17
29 Palms	23
China Lake	42

The numbers are arbitrary, but need to be agreed upon by all simulation participants. Likewise, the simulation manager can define some arbitrary values for applications:

Application	ID
JCATS	82
OneSAF	1337
VBS3	101

The final value of the Entity ID triplet is the entity value.

For example, a JCATS simulation at Norfolk that creates an entity may have an entity ID of (17, 82, 4576). A VBS3 simulator at China Lake may have an entity ID of (42, 101, 8472).

Site	Application	Entity
42	101	8472
17	82	4576

This algorithm minimizes the conflicts that may occur. Instead of selecting from a large, single ID space, simulations only need to deconflict IDs at a single site, within a single application. The final value of the triplet, the entity number, is often selected randomly within the range of 1 to the maximum unsigned short value, 65535. Often simply a random selection from such a large ID space is good enough to prevent conflicts. More careful programmers can check to see if that full record entity ID has already been selected by another application. They can simply listen to see if the entity ID is currently being used by any other simulator. Or they could have clients only at China Lake and have VBS3 installed talk to a server that assigns unused numbers.

A number of programmers take the use of examining the list of entities. They listen to traffic, and see if anyone has taken it. If not, they start using it.

This algorithm relies in part on consistent application of site and application IDs. For a single application at a single site that is not set up as global, coordinating site and application IDs is not as difficult.

At the time DIS was designed servers were still somewhat exotic software. In this day and age it is easy to set up a web server that can provide the service of handing out unique IDs. A designer replicating DIS today might choose this technique because web architecture is so widespread. The installed base today is what it is.