4.3 Frequent State State Regeneration Regeneration 4.3 Frequent - - PDF document

Special Course on Networked Virtual Environments February 6, 2004 Jouni Smed 1

§4.3 Frequent §4.3 Frequent State State Regeneration Regeneration

• Many NVEs cannot afford the communications and processor

Many NVEs cannot afford the communications and processor

• verhead required to support absolute consistency through a
• verhead required to support absolute consistency through a

centralized repository centralized repository

• Many NVEs do not require high level consistency

Many NVEs do not require high level consistency

• Limited and temporary error is

Limited and temporary error is allowable allowable

• Smooth interface vs. absolute consistency

Smooth interface vs. absolute consistency

• Replace the distributed consistency protocol with a more

Replace the distributed consistency protocol with a more aggressive state update notification system aggressive state update notification system

Frequent State Frequent State Regeneration (cont’d) Regeneration (cont’d)

• Source host does not

Source host does not care care what state information is cached or what state information is cached or available to other hosts available to other hosts

• Each update contains whole entity state, whether or not it has

Each update contains whole entity state, whether or not it has changed changed

• The owner of information uses

The owner of information uses blind broadcast blind broadcast

• asynchronously and unreliably

asynchronously and unreliably

• at

at a regular a regular interval interval

• forward to

forward to all participants all participants

• The receiver does not acknowledge packets

The receiver does not acknowledge packets

• Assumption: high

Assumption: high transmission rate will make inconsistencies transmission rate will make inconsistencies relatively unnoticeable relatively unnoticeable

• Even with moderate packet loss, blind broadcast can typically

Even with moderate packet loss, blind broadcast can typically deliver more packets than shared database due to its overhead deliver more packets than shared database due to its overhead

Special Course on Networked Virtual Environments February 6, 2004 Jouni Smed 2

Entity Entity Ownership: Ownership: Background Background

• Blind broadcasting sacrifices absolute consistency, and reduces

Blind broadcasting sacrifices absolute consistency, and reduces some flexibility that centralized repositories offer some flexibility that centralized repositories offer

• In a

In a centralized repository system centralized repository system

• any host can modify any entity

any host can modify any entity

• reliable

reliable and order and order-

• preserving updates

preserving updates

• With frequent state regeneration systems, ensure that multiple

With frequent state regeneration systems, ensure that multiple hosts hosts do not attempt to update do not attempt to update an an entity at the same time entity at the same time

Problem: Who’s Got the Ball Now? (Part II) Problem: Who’s Got the Ball Now? (Part II)

A A B B

Special Course on Networked Virtual Environments February 6, 2004 Jouni Smed 3

Explicit Entity Ownership Explicit Entity Ownership

• Ensure that shared state can only be updated by one host at a

Ensure that shared state can only be updated by one host at a time time

• exactly

exactly one host has

• ne host has the ownership

the ownership of the state

• f the state
• the owner

the owner periodically periodically broadcasts broadcasts the value of the state the value of the state

• Typically

Typically user’s own user’s own representation (avatar) representation (avatar) is owned by is owned by that that user user

• Locks on other entities are managed by

Locks on other entities are managed by a lock a lock manager server manager server

• clients

clients query to obtain ownership and contact to release it query to obtain ownership and contact to release it

• the

the server ensures that each entity has only one owner server ensures that each entity has only one owner

• the

the server owns the entity if no one else does server owns the entity if no one else does

• failure

failure recovery recovery

Lock Lock Manager: Example Manager: Example

A A B B

Lock Manager Lock Manager Grant Grant Lock Lock Request Request Lock Lock Request Request Lock Lock Reject Reject Lock Lock Update State Update State

Special Course on Networked Virtual Environments February 6, 2004 Jouni Smed 4

Proxy Update Proxy Update

A A B B

Update Position (A) Update Position (A) Request Update Position Request Update Position Update Position (B) Update Position (B)

• Non

Non-

• owner
• wner sends

sends an update request to the an update request to the owner of the state

• wner of the state
• The owner

The owner decides whether it accepts decides whether it accepts the the update update

• The owner serves as a proxy

The owner serves as a proxy

• Generates an

Generates an extra message on each extra message on each non non-

• owner
• wner update

update

• Suitable when

Suitable when non non-

• owner
• wner updates are rare or many

updates are rare or many hosts hosts want want to update the to update the state state

Ownership Transfer Ownership Transfer

A A B B

Lock Manager Lock Manager Update Position (A) Update Position (A) Request Ownership Request Ownership Notify Lock Notify Lock Transfer Transfer Acknowledge Acknowledge Lock Transfer Lock Transfer Grant Ownership Grant Ownership Update Position (B) Update Position (B)

Special Course on Networked Virtual Environments February 6, 2004 Jouni Smed 5

Ownership Transfer Ownership Transfer (cont’d) (cont’d)

• The lock manager has the lock information at all times

The lock manager has the lock information at all times

• If the host fails, the lock manager defines the current lock

If the host fails, the lock manager defines the current lock

• wnership state
• wnership state
• Lock ownership transfer incurs extra message overhead

Lock ownership transfer incurs extra message overhead

• Suitable when a single host is going to make a series of

Suitable when a single host is going to make a series of updates and there is little contention among hosts wishing to updates and there is little contention among hosts wishing to make updates make updates

Reducing Broadcast Scope Reducing Broadcast Scope

• In a

In a frequent state regeneration system, each host sends frequent state regeneration system, each host sends updates to all participants updates to all participants

• causes

causes hosts to receive lots of extraneous information hosts to receive lots of extraneous information

• Multicast and

Multicast and area area-

• of
• f-
• interest

interest techniques techniques

• filter

filter the updates before they get sent to inappropriate recipients the updates before they get sent to inappropriate recipients

• Who should do

Who should do the the filtering? filtering?

• the host itself?

the host itself?

• a server?

a server?

• We shall return to this in §6

We shall return to this in §6

Special Course on Networked Virtual Environments February 6, 2004 Jouni Smed 6

Frequent State Regeneration: Frequent State Regeneration: Advantages Advantages and Drawbacks and Drawbacks

• Adds

Adds multi multi-

• user

user capabilities to existing single capabilities to existing single-

• user

user applications applications

• Blind broadcasting does not require

Blind broadcasting does not require a server a server, consistency , consistency protocol nor protocol nor a lock manager (in most cases) a lock manager (in most cases)

• Offers support

Offers support for a large number of users for a large number of users

• Exhibits better

Exhibits better interactive interactive behaviour behaviour

• Requires considerable

Requires considerable network network bandwidth bandwidth

• Susceptible to network

Susceptible to network latency latency

• jitter = variation

jitter = variation in network latency from one packet to the next in network latency from one packet to the next

• Assumes

Assumes that all hosts are broadcasting at the same rate that all hosts are broadcasting at the same rate

Flashback: Maintaining Flashback: Maintaining Dynamic Shared State Dynamic Shared State

Three basic approaches to maintain dynamic shared state: Three basic approaches to maintain dynamic shared state:

• shared

shared repositories repositories

• frequent

frequent broadcast broadcast

• state

state prediction prediction

Absolute Absolute consistency consistency High High update rate update rate Dead Dead reckoning reckoning Centralized Centralized information information repositories repositories Frequent Frequent state state regeneration regeneration

The The Trade Trade-

• off
• ff Spectrum

Spectrum

Special Course on Networked Virtual Environments February 6, 2004 Jouni Smed 7

§4.4 Dead §4.4 Dead Reckoning Reckoning of

• f Shared State

Shared State

• Transmit

Transmit state update packets less frequently state update packets less frequently

• Use received information to

Use received information to approximate approximate the true shared state the true shared state

• In between updates, each host predicts the state of the entities

In between updates, each host predicts the state of the entities

Dead Dead Reckoning: Example Reckoning: Example

Time 3.5: Time 3.5: Position ( Position (5.5, 6 5.5, 6) ) Predicted Path Predicted Path Time 3: Time 3: Position ( Position (4, 5 4, 5) ) Velocity ( Velocity (3, 2 3, 2) )

Transmit Transmit Remote Prediction Remote Prediction

Special Course on Networked Virtual Environments February 6, 2004 Jouni Smed 8

Dead Reckoning Protocol Dead Reckoning Protocol

DR protocol DR protocol consists of two elements: consists of two elements:

• prediction technique

prediction technique

• how the entity’s current state is computed based on

how the entity’s current state is computed based on previously received update packets previously received update packets

• convergence technique

convergence technique

• how to correct the

how to correct the state state information when an update is information when an update is received received

Prediction and Convergence Prediction and Convergence

Time 4: Time 4: Position ( Position (7, 7 7, 7) ) Current Predicted Path Current Predicted Path Time 4: Time 4: Position ( Position (6, 3 6, 3) ) Velocity ( Velocity (6, 3 6, 3) ) New Predicted Path New Predicted Path Time 3: Time 3: Position ( Position (4, 5 4, 5) ) Velocity ( Velocity (3, 2 3, 2) )

Special Course on Networked Virtual Environments February 6, 2004 Jouni Smed 9

Prediction Using Derivative Polynomials Prediction Using Derivative Polynomials

• The most common DR protocols use derivative polynomials

The most common DR protocols use derivative polynomials

• Involves various derivatives of the entity’s current position

Involves various derivatives of the entity’s current position

• Derivatives of

Derivatives of position position

1. 1.

velocity velocity

2. 2.

acceleration acceleration

3. 3.

jerk jerk

Zero Zero-

• Order and First

Order and First-

• Order Polynomials

Order Polynomials

• Zero

Zero-

• order polynomial
• rder polynomial
• position

position p p

• the

the object’s instantaneous position, no derivative information

• bject’s instantaneous position, no derivative information
• predicted position after

predicted position after t t seconds = seconds = p p

⇒ ⇒The state regeneration technique The state regeneration technique

• First

First-

• order polynomial
• rder polynomial
• velocity

velocity v v

• predicted position after

predicted position after t t seconds seconds = = vt + p vt + p

• update packet provides current position and velocity

update packet provides current position and velocity

Special Course on Networked Virtual Environments February 6, 2004 Jouni Smed 10

Second Second-

• Order Polynomials

Order Polynomials

• We can usually

We can usually obtain better prediction by incorporating more

• btain better prediction by incorporating more

derivatives derivatives

• Second

Second-

• order polynomial
• rder polynomial
• acceleration

acceleration a a

• predicted position after

predicted position after t t seconds seconds = = ½ ½at at2

2 +

+ vt vt + + p p

• update packet: current position, velocity, and acceleration

update packet: current position, velocity, and acceleration

• popular and widely used

popular and widely used

• easy to understand and implement

easy to understand and implement

• fast to compute

fast to compute

• relatively good predictions of position

relatively good predictions of position