-
Notifications
You must be signed in to change notification settings - Fork 32
Publishing and Removal of Entities
Typically one host publishes information about an entity--perhaps a tank, a ship, or an aircraft. We want to make information about this entity made available to others, which may be a host across the lab or across the continent. How?
In DIS this is done in a simple way, though it may make an inefficient use of bandwidth. Remember, DIS is a peer-to-peer architecture--no central server server is assumed to exist. Hosts learn about entities but not by contacting a central server.
Let's assume a weapon is being simulated in DIS. The tank is controlled by a person at a user control station that allows him to drive and to fire the cannon. How do other hosts, also performing the same simulation, learn about the tank driven by this host?
There are some issues here. For example, what if we've had the full simulation up for an hour, and a new application just started? We can't just grab a list of all the other entities in the simulation; that changes over time, and doesn't tell us whether the application is active. The application joining must also get a full list of the entities of the simulation.
Using the Entity State PDU (ESPDU) makes this fairly straight forward. As you recall, or read about in the ESPDU session, the ESPDU contains information such as the Entity ID.
The entity ID must be unique to each entity in the simulation. Each application maintains a list of all entity IDs from ESPDUs it has seen on the screen. When a new application starts it simply begins sending ESPDUs. All other applications should receive the ESPDU and check to see if the entity is already in the list. If not, it can be added, and in the local application added as a simulation entity.
Of course, a PDU message may be dropped if sent by UDP networks, and that is the recommended DIS transport method. There is no guarantee a UDP message sent will be delivered. One way to prevent this is to send a lot of PDU messages, such as the ESPDU, and to do it frequently. That's what DIS does.
DIS works in a "heartbeat" mode for ESPDUs; the ESPDU with entity information must be sent at least every few seconds. For example, a tank parked in a fighting position and not moving at all must send an ESPDU every 5 seconds, while a minefield is required to send one at least once a minute. The application may choose to send more frequently, but must send at the minimum rate. Even if the first UDP message that contains an ESPDU is dropped, a new message will be send in usually about five seconds.
Other applications add information as ESPDUs arrive. They will decode the ESPDU message and use that information to add the entity to views in their own displays.
What if someone pulls the plug on a computer emitting ESPDUs? We want to discover that elsewhere because we wont be able to interact with the entity. We can accomplish this fairly easily by eliminating the entity ID from local list or database of entities. If we don't hear from the heartbeat for that entity for three or four heartbeat periods, then it is likely the entity application on the other host is dead. We simply remove the entity from our display.
Using the heartbeat method to add and remove entities from the local display is simple and direct. Overall it does add bandwidth use, since a site with many entities will add a lot of traffic every five seconds, but simplicity in simulation can be difficult to find.