Ordering in online games Objectives – Understand the ordering requirements of gaming – Realise how ordering may be achieved – Be able to relate ordering.

Slides:



Advertisements
Similar presentations
COS 461 Fall 1997 Group Communication u communicate to a group of processes rather than point-to-point u uses –replicated service –efficient dissemination.
Advertisements

Causality in online gaming Objectives – Understand how online gaming relates to causality research in distributed systems – Be able to apply distributed.
Impossibility of Distributed Consensus with One Faulty Process
CS 542: Topics in Distributed Systems Diganta Goswami.
DISTRIBUTED SYSTEMS II FAULT-TOLERANT BROADCAST Prof Philippas Tsigas Distributed Computing and Systems Research Group.
Interest Management Objectives – –Understand what is meant by the term interest management. –Realise how interest management schemes may be deployed. –Understand.
Dead Reckoning Objectives – –Understand what is meant by the term dead reckoning. –Realize the two major components of a dead reckoning protocol. –Be capable.
6.852: Distributed Algorithms Spring, 2008 Class 7.
Synchronization Chapter clock synchronization * 5.2 logical clocks * 5.3 global state * 5.4 election algorithm * 5.5 mutual exclusion * 5.6 distributed.
Lab 2 Group Communication Andreas Larsson
Virtual Synchrony Jared Cantwell. Review Multicast Causal and total ordering Consistent Cuts Synchronized clocks Impossibility of consensus Distributed.
1 Complexity of Network Synchronization Raeda Naamnieh.
CS 582 / CMPE 481 Distributed Systems
Group Communications Group communication: one source process sending a message to a group of processes: Destination is a group rather than a single process.
Synchronization Clock Synchronization Logical Clocks Global State Election Algorithms Mutual Exclusion.
Group Communication Phuong Hoai Ha & Yi Zhang Introduction to Lab. assignments March 24 th, 2004.
2/23/2009CS50901 Implementing Fault-Tolerant Services Using the State Machine Approach: A Tutorial Fred B. Schneider Presenter: Aly Farahat.
1 Principles of Reliable Distributed Systems Lecture 5: Failure Models, Fault-Tolerant Broadcasts and State-Machine Replication Spring 2005 Dr. Idit Keidar.
EEC 693/793 Special Topics in Electrical Engineering Secure and Dependable Computing Lecture 13 Wenbing Zhao Department of Electrical and Computer Engineering.
Lecture 13 Synchronization (cont). EECE 411: Design of Distributed Software Applications Logistics Last quiz Max: 69 / Median: 52 / Min: 24 In a box outside.
Replication and Consistency CS-4513 D-term Replication and Consistency CS-4513 Distributed Computing Systems (Slides include materials from Operating.
 Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 12: Impossibility.
1 More on Distributed Coordination. 2 Who’s in charge? Let’s have an Election. Many algorithms require a coordinator. What happens when the coordinator.
Lecture 12 Synchronization. EECE 411: Design of Distributed Software Applications Summary so far … A distributed system is: a collection of independent.
Composition Model and its code. bound:=bound+1.
State Machines CS 614 Thursday, Feb 21, 2002 Bill McCloskey.
Time, Clocks, and the Ordering of Events in a Distributed System Leslie Lamport (1978) Presented by: Yoav Kantor.
Networking Components Chad Benedict – LTEC
Chapter 1 The Challenges of Networked Games. Online Gaming Desire for entertainment has pushed the frontiers of computing and networking technologies.
Networked Games - consistency and real-time Objectives – –Understand the problems associated with networked games. –Realize the importance of satisfying.
1 A Modular Approach to Fault-Tolerant Broadcasts and Related Problems Author: Vassos Hadzilacos and Sam Toueg Distributed Systems: 526 U1580 Professor:
Formal Model for Simulations Instructor: DR. Lê Anh Ngọc Presented by – Group 6: 1. Nguyễn Sơn Hùng 2. Lê Văn Hùng 3. Nguyễn Xuân Hậu 4. Nguyễn Xuân Tùng.
Replication & EJB Graham Morgan. EJB goals Ease development of applications –Hide low-level details such as transactions. Provide framework defining the.
Distributed Algorithms – 2g1513 Lecture 9 – by Ali Ghodsi Fault-Tolerance in Distributed Systems.
TOTEM: A FAULT-TOLERANT MULTICAST GROUP COMMUNICATION SYSTEM L. E. Moser, P. M. Melliar Smith, D. A. Agarwal, B. K. Budhia C. A. Lingley-Papadopoulos University.
Reliable Communication in the Presence of Failures Based on the paper by: Kenneth Birman and Thomas A. Joseph Cesar Talledo COEN 317 Fall 05.
Lab 2 Group Communication Farnaz Moradi Based on slides by Andreas Larsson 2012.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Replication with View Synchronous Group Communication Steve Ko Computer Sciences and Engineering.
Consensus and Its Impossibility in Asynchronous Systems.
Farnaz Moradi Based on slides by Andreas Larsson 2013.
Agenda Fail Stop Processors –Problem Definition –Implementation with reliable stable storage –Implementation without reliable stable storage Failure Detection.
Dealing with open groups The view of a process is its current knowledge of the membership. It is important that all processes have identical views. Inconsistent.
Event Ordering Greg Bilodeau CS 5204 November 3, 2009.
Copyright © George Coulouris, Jean Dollimore, Tim Kindberg This material is made available for private study and for direct.
November NC state university Group Communication Specifications Gregory V Chockler, Idit Keidar, Roman Vitenberg Presented by – Jyothish S Varma.
EEC 688/788 Secure and Dependable Computing Lecture 10 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
Networked Games Objectives – –Understand the types of human interaction that a network game may provide and how this influences game play. –Understand.
CSE 60641: Operating Systems Implementing Fault-Tolerant Services Using the State Machine Approach: a tutorial Fred B. Schneider, ACM Computing Surveys.
The Totem Single-Ring Ordering and Membership Protocol Y. Amir, L. E. Moser, P. M Melliar-Smith, D. A. Agarwal, P. Ciarfella.
Building Dependable Distributed Systems, Copyright Wenbing Zhao
Understanding Network Architecture CHAPTER FOUR. The Function of Access Methods The set of rules that defines how a computer puts data onto the network.
Lecture 10: Coordination and Agreement (Chap 12) Haibin Zhu, PhD. Assistant Professor Department of Computer Science Nipissing University © 2002.
Reliable Communication in the Presence of Failures Kenneth P. Birman and Thomas A. Joseph Presented by Gloria Chang.
Relying on Safe Distance to Achieve Strong Partitionable Group Membership in Ad Hoc Networks Authors: Q. Huang, C. Julien, G. Roman Presented By: Jeff.
Fault Tolerance (2). Topics r Reliable Group Communication.
Distributed Systems Lecture 9 Leader election 1. Previous lecture Middleware RPC and RMI – Marshalling 2.
Fundamentals of Fault-Tolerant Distributed Computing In Asynchronous Environments Paper by Felix C. Gartner Graeme Coakley COEN 317 November 23, 2003.
EEC 688/788 Secure and Dependable Computing Lecture 10 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
Reliable multicast Tolerates process crashes. The additional requirements are: Only correct processes will receive multicasts from all correct processes.
Coordination and Agreement
The consensus problem in distributed systems
When Is Agreement Possible
Active replication for fault tolerance
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
Presentation transcript:

Ordering in online games Objectives – Understand the ordering requirements of gaming – Realise how ordering may be achieved – Be able to relate ordering problems to distributed systems research

A simple scenario (again – the same one) Consider a gaming scenario consisting of four players (P 1, P 2, P 3 and P 4 ). The goal of the game is for a player to shoot all other players. The virtual world is constructed from a number of different rooms and players may not shoot beyond the room they are within. – P 2 enters a room (containing P 1, P 3 and P 4 ) and is shot by P 1 while P 4 leaves the room and P 1 and P 3 reload their guns at some point during the gaming scenario. To allow this gaming scenario to proceed there is a need to propagate event notification, that is, different players must be informed when certain events happen so they may react.

Ensuring causality

More ordering Message transit times are greater than zero and may vary for different links in a network. – M 2 1 is delayed and arrives at P 4 after M 4 1 has been sent (no causal relationship exists between E 2 1 and E 4 1 nor their associated messages M 2 1 and M 4 1 ). – Played out in a virtual world, P 1 will witness P 2 enter the room (P 1, P 2, P 3 and P 4 present) then P 4 leave the room (P 1, P 2, and P 3 present). P 3, on the other hand, witnesses P 4 leaving the room (P 1 and P 3 present) before P 2 enters the room (P 1, P 2 and P 3 present). – There is no causal relationship present between E 2 1 and E 4 1 as M 2 1 and M 4 1 arrive at their destinations after E 2 1 and E 4 1 have occurred (indicating that one event could not have caused the other).

Space time representation

Causal ordering not enough Unfortunately, the manifestation of this in the virtual world still provides inconsistencies. This indicates that although some events may not be causally related as they happen simultaneously, in a logical sense, there may still be a need to impose some form of ordering on them to preserve a gaming scenario’s validity. Causal ordering, although important, is not a strong enough ordering guarantee. We require total ordering (ensuring all participants receive messages in the same order)

Fixing the problem with total ordering

Is total ordering sufficient? Total ordering is capable of ensuring that all participants view global events in the same order. – This is not simply a case of ensuring that M 2 1 and M 4 1 are received in the same order at P 1 and P 3, but the order in which all participants (including P 2 and P 4 ) receive M 2 1 and M 4 1 must be the same. – In fact, to ensure the total ordering of global events at all participants the events themselves must gain their ordering from the underlying protocol governing message delivery. – If this was not the case then P 2 ’s view would be that of leaving a room before P 4 entered whereas P 4 ’s view would be that of entering a room with P 2 still present.

Total ordering at work Total ordering is primarily designed to ensure consistency of state for deterministic state machines, particularly useful in replication schemes used in fault-tolerance. – The guarantee that if all replicas receive the same messages in the same order then their states will not deviate (this cannot be guaranteed for non-deterministic state machines). – Therefore, state change events should always be propagated across all replicas to ensure states remain mutually consistent. – If this route was followed in the example here then local events would need to be propagated to ensure all processes maintained a mutually consistent view of the state of a gaming scenario (e.g., E 1 1 ).

Dynamic environments When discussing total ordering a broadcast (message sent to all) was used as the basic message dissemination technique. For practical purposes this is not appropriate as one may expect only a subset of participants to be involved in any one gaming scenario at a time. Therefore, the multicast is a more appropriate message dissemination technique, allowing players to join and leave gaming scenarios as they wish. Multicast introduces the concept of a “group”. – A group identifies the recipient of a multicast message with the membership of a group having the ability to change over time. – In the our example P 2 and P 4 change the membership of the group of players who are “in the room”. The problem of “who is in the room” highlights another problem that requires more than ordering protocols to aid in deriving an appropriate solution. – This problem relates to determining exactly when messages are deliverable in the presence of dynamic group membership. We continue to use the “who is in the room” example to describe the issues that arise.

Who is in the room? P 4 is still receiving messages after they have left the playing area (the room). Therefore, a more appropriate approach would be to restrict multicast messages to include only those inside the room. – We would like participants to install the views of room occupancy as follows: P 1 and P 3 ({P 1, P 3, P 4 } followed by {P 1, P 2, P 3 }); P 2 ({P 2 } followed by {P 1, P 2, P 3 }); P 4 ({P 1, P 3, P 4 } followed by {P 4 }). – Notice how P 2 and P 4 have views that only include themselves at some point to hinder the inappropriate multicasting of messages (we assume there is nobody else outside in neighbouring rooms).

Solving the problem - considerations The ordering of views in a dynamic environment alone is ineffective if we don’t order the event dependent messages with respect to view changes. – For example, we may be able to ensure that all participants provide the same view changes in the same, total, order. However, if the set of messages in such views varies from participant to participant we will not solve the problem highlighted. There needs to be some guarantee to ensure the same set of messages is delivered to all participants in the same view, disallowing message delivery when view changes are being determined. – For example, in our example the view change event occurs at the initial steps of the gaming scenario, therefore, this view change should complete to ensure all participants’ progress with the same messages delivered in the appropriate views. – As with ordering, multiple messages will be required to allow all participants to realise the appropriate group membership changes.

View change

Virtual synchrony Virtual synchrony is the term used to describe the total ordering of view changes with respect to other messages (e.g., the ones responsible for propagating events). – Notice that the definition of virtual synchrony does not impose total order on other messages, just the view changes with respect to all other messages. – Therefore, it is quite conceivable to have a causal ordering with virtual synchronous systems. Does this sound confusing?

Agreement An underlying problem that arises frequently in distributed computing models is that of agreement. – In essence, the previous examples are strongly related to agreement as one may assume that agreement on message ordering and group membership is a requirement that processes must satisfy. The agreement problem assumes that a process has an initial value to share with all other processes in its group (all processes must agree on this value) – Alternatively, all processes may have their own, initial, value and all processes must agree on a single value known as the consensus problem but, for the basic interpretation made here, can be viewed in the same manner as the agreement problem

Impossible!!!!! While considering agreement it is worth realising that it is impossible to implement an agreement protocol in asynchronous environments when in the presence of faulty processes One simple way to visualise this impossibility result is to consider how one may tell the difference between a correct process and a failed one. – Basically, when message and processing delays are unknown, it is impossible to tell if a process is slow or failed; how long will you wait for a response?

Groups (more complications) Software products that provide group communication services have a number of components: – ordering protocols (possibly more than one); failure detectors (based on unreliable failure detectors); group membership protocols (providing dynamic groups); reliable multicast (commonly termed atomic multicast – termed atomic broadcast in the literature as consideration of sub-groups not necessarily considered in the basic problem description) I built one in the 90s (NewTOP) during my PhD This gets more complicated when you allow group members to belong to more than one group at a time.....

Group configurations

Time Not mentioned so far, yet of great importance to modelling gaming scenarios appropriately, is the need for timely progression. So far we have considered a logical view of gaming scenarios with the length of time required to execute events and send messages not considered. – However, virtual worlds are expected to provide players with the illusion of real-time (or at least near real-time) interaction. – Events that appear to occur “too slowly” may destroy such an illusion and render the gaming experience inappropriate: virtual synchrony, total ordering, and failure free environments (if such an environment could be created) will not prevent excessive delays in event propagation from ruining a gaming scenario.

Problems with time It may be possible to implement total ordering and virtual synchrony appropriately, but there is nothing in this logical view of the world preventing P 1 from viewing the leaving of P 2 and the arrival of P 4 before P 3 in (real) global-time. – By not considering time we are not providing a “fair” gaming scenario for players. All observations so far have been made in “logical time”. Synchronous environments provide an opportunity to include timing when describing gaming scenarios. – For example, if one realises that message delays and process delays have a known bound, then synchronisation of local clocks may be achieved with minimal effort. – Once this step has been achieved, then placing timeouts on the expectation of player interaction can be worked into an implementation.

Best effort After acknowledging that erroneous situations will occur with respect to message delivery, a developer must decide how much effort (time/processing) the underlying system expends to progress towards appropriate modelling of a gaming scenario at the expense of real-time requirements. – In the research community primarily concerned with online virtual worlds this has been termed the consistency/throughput trade-off (this term originally concerned itself with the throughput of a network as opposed to additional message passing requirements) – Basically, the consistency referred to is the desire to allow all players to have a mutually consistent view of a gaming scenario. However, in commercial virtual worlds this manifests itself not so much in non- consistency of views but in restrictions on what is and is not possible in gaming scenarios.