Special Course on Networked Virtual February 6, 2004 Environments §4.3 Frequent State State Regeneration Regeneration §4.3 Frequent � � Many NVEs cannot afford the communications and processor Many NVEs cannot afford the communications and processor overhead required to support absolute consistency through a overhead 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 Regeneration (cont’d) Regeneration (cont’d) Frequent State � 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 Jouni Smed 1
Special Course on Networked Virtual February 6, 2004 Environments Entity Ownership: Ownership: Background Background Entity � 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 do not attempt to update do not attempt to update an an entity at the same time entity at the same time hosts Problem: Who’s Got the Ball Now? (Part II) Problem: Who’s Got the Ball Now? (Part II) A B A B Jouni Smed 2
Special Course on Networked Virtual February 6, 2004 Environments 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 one host has the ownership the ownership of the state of 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 Manager: Example Manager: Example Lock Lock Manager Lock Manager Request Request Request Request Lock Lock Lock Lock Grant Grant Reject Reject Lock Lock Lock Lock A B A B Update State Update State Jouni Smed 3
Special Course on Networked Virtual February 6, 2004 Environments Proxy Update Proxy Update Update Position (A) Update Position (A) Request Update Position Request Update Position A B A B Update Position (B) Update Position (B) � Non Non- -owner owner sends sends an update request to the an update request to the owner of the state owner 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 owner update update � � � Suitable when Suitable when non non- -owner owner 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 Lock Manager Lock Manager Notify Lock Notify Lock Transfer Transfer Acknowledge Acknowledge Lock Transfer Lock Transfer Update Position (A) Update Position (A) Request Ownership Request Ownership A B A B Grant Ownership Grant Ownership Update Position (B) Update Position (B) Jouni Smed 4
Special Course on Networked Virtual February 6, 2004 Environments Ownership Transfer (cont’d) (cont’d) Ownership Transfer � 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 � ownership state ownership 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 of- -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 Jouni Smed 5
Special Course on Networked Virtual February 6, 2004 Environments Frequent State Regeneration: Frequent State Regeneration: Advantages and Drawbacks and Drawbacks Advantages � � 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 Dynamic Shared State Dynamic Shared State Flashback: Maintaining 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 The Trade The Trade- -off off Spectrum Spectrum High High Absolute Absolute update rate update rate consistency consistency Centralized Centralized Frequent Frequent Dead Dead information state reckoning information state reckoning repositories regeneration repositories regeneration Jouni Smed 6
Recommend
More recommend
