Event System Presentation


Published on

An Event System for Server-less Networking

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Event System Presentation

  1. 1. Presenting users with a consistent world without persistent clientsPermanent State in a Serverless Environment
  2. 2. ➲Presenting users with a persistent state is easy if you have apersistent host.➲With a few techniques it can be done without a server, aslong as clients remain in the game.➲Primary benefit is the saving on Server hosting costs. Overview
  3. 3. ➲ Traditional Model : Client/Server➲ Server runs game logic, deciding when events occur.➲ Game clients receive incoming events and process them (deterministically).➲ Late-joiners can receive a snapshot of the world from the host. Server based model
  4. 4. ➲ One of the clients acts as the server.➲ That client drives the others via events.➲ Processes events themselves.➲ The problem is that the server “state” is never transmitted, only the client state.➲ If the integrated server leaves, what do we do. Integrated server
  5. 5. ➲ If we make the server logic “stateless” we can move the server at will.➲ The server is now just code, that runs on one machine. The only thing the server code can do is send events.➲ Server is non-deterministic. Client code deterministic. Integrated server (cont)
  6. 6. ➲ This would suffice if only the host needs to interact with the world, and everyone else just views them.➲ The real problem comes when we allow the clients to interact with the world as well. (clients become peers)➲ Peers actions can overlap, creating race conditions.➲ To resolve these race conditions we could lock resources using the host as a token server. Moving to peer-to-peer
  7. 7. ➲ Tokens are often touted as a solution➲ Peer signal requests for tokens➲ Server grants, or refuses➲ Peer then can control the object➲ What if server migrates after the signal?➲ What if peer leaves after obtaining the token?➲ We cannot reclaim the token until the peer is definitely gone. The problem with tokens
  8. 8. ➲ What if the server, merely re-broadcasts the signals, without any logic.➲ The outgoing broadcasts are ordered, so all the peers see the signals in the same order.➲ Peers smart enough to work out when locks fail, or succeed.➲ Now we can implement complex behaviors.➲ Example, can only get into a vehicle if its empty, or occupied by a team mate. Introducing the reflector
  9. 9. ➲ The reflector is like a server with no state, nor game specific logic.➲ It is a true peer-peer logic, all clients are identical, except for the automatic reflecting of requests.➲ Peers must remember the sent signals. If the host changes, they must resend all signals they have not seen reflected.➲ The Reflector
  10. 10. ➲ Peers send signals and handle events.➲ The reflector reflects the signals. Reflected signals are events, and are in the same order on all machines.➲ Signals have a unique identifier formed from machine ID and count of signals sent.➲ Events also have a unique ID of the reflector and the event count. (also known as the event stream position) Terminology
  11. 11. ➲ The reflect method is exposed on all machines.➲ On any client who is not the reflector, the method does nothing.➲ On the reflector, the event occurs immediately, with the event sent as normal to other clients.➲ Reflect methods must not change state, only generate events. The Reflect Method
  12. 12. ➲ Three common ownership patterns➲ Unique ownership : no-one else can signal, clients can signal whenever they like.➲ Single ownership : State is changed using reflect, effective like the old “server code” pattern.➲ No/Shared Ownership: context never changes, peers signal when they wish to change state. Changes may fail. Ownership analogies
  13. 13. In this example, Peer 1, wants to signalPeer Reflecto Peer something about an object they own.1 r 3 Peer 1 call Signal, which sends a signal to the reflector.Signal The reflector calls the reflect method, and sends the results to all clients, including themselves. Event A use of this pattern might be used for example to allow a player to select their own weapon. Unique ownership pattern
  14. 14. In this example, something must getPeer Reflecto Peer done, once and once only. In this1 r 3 case we poll for the condition on each client. Each client calls the reflect method when required. Only the reflector will do anything when reflect is called, and they will send an event to all clients (including Event themselves). It is important to note, that we cannot guarantee that there is always a reflector, but we can guarantee that one will exist at some point. When a host does exist, they should call the reflect, and the event will get done. This usage pattern also has the lowest latency (for obvious reasons) A good us for this pattern might be to trigger the end of the round. Single ownership pattern
  15. 15. This pattern is identical to the uniquePeer Reflecto Peer ownership pattern, with BIG caveat.1 r 3 No ownership means more than one peerSignal Signal may try and use a resource, creating a race condition. It is the job of the reflector to resolve the Event race condition, by giving definitive ordering to the events. This pattern could be used for example to determine which player gets a weapon pick up. No ownership pattern
  16. 16. ➲ A major problem still exists.➲ The state on the peers may not be up to date (as defined as the state on the server).➲ This means that peers can send signals that are no longer valid when they are reflected.➲ Most obvious is referencing an object that has since been deleted. The context issue
  17. 17. An example of context problem Peer Reflecto Peer • The object is deleted twice. 1 r 3 • The second delete is valid when sent, because the first delete has notDelete object arrived yet. • Could be solved by unique object Delete object identifiers, but... • This is a generic problem. It occurs because the knowledge of the state is perfect, but always lags the reflector. • Three common re-occurring causes. • Game state change. (i.e. BE transition) • Level state change. (i.e. end of round) • Object state, mainly deletion. Example context problem
  18. 18. ➲ Signals are tagged with the event processed last.➲ Provide a number of context markers. Markers are updated with the last event the context changed.➲ Simply compare signal tag with the context marker to see if the context has changed (how to handle left to user).➲ Markers can be deleted when all peers send signals with event IDs greater than the marker. Signal context
  19. 19. ➲ All signals originate from non-deterministic actions (such as user input)➲ Reflection translates into a deterministic flow.➲ Once inside a deterministic event, we may not use the signal method to trigger more non-deterministic behaviour. Determinism barriers
  20. 20. Using signals from events problematic • Event sent to all clientsPeer 1 Reflector Peer 3 • We end up with multiple signals. • Could be solved by detectingSignal multiple events, but... • A better way exists.Signal Signal Signal from event
  21. 21. ➲ A good example of the single ownership pattern.➲ Signaling from inside event handlers, causes the event to be stored as pending, on all machines.➲ Peers use reflect method to cause events which are pending.➲ Events are removed from the store when the event is seen.➲ Pending buffer is a deterministic to non-deterministic barrier. Non Deterministic-Signal buffer
  22. 22. ➲ Non-deterministic code can generate signals, but not change state.➲ Deterministic code can change state, but not generate signals.➲ By splitting code into deterministic and non-deterministic, we can do almost anything, without the need for a server. Summary
  23. 23. ➲ Events are always owned by a single “Type”, but many types can listen to those events.➲ This leads to an ordering problem. If an event constructs an object then the event must be processed first➲ If an event destroys an object, then the listeners must be called first.➲ This is a property of the event, and can be specified on creation.Construction order/destruction order problems
  24. 24. ➲ Define event object .It needs pack/unpack and name.➲ I strongly urge use of PureEvent/IntEvent/etc➲ Inherit from EventOwner➲ Define an event handler➲ Initialise Event handler (with order and determinism flags)➲ Add ReflectionHandler if required Implementing code
  25. 25. ➲ Inherit from EventListner➲ Implement listen function.➲ (remember the header file only needs the event structure name, nothing else) Adding listeners
  26. 26. ➲ We can improve network efficiency by allowing reflection as a translation stage.➲ Signal->Event/Events from user defined handlers.➲ Can also enforce that no invalid context events ever seen (simplifies event handling, allowing designers to write scripted code) Reflection as translation
  27. 27. ➲ The event system provides a general purpose dispatching mechanism which might be of use to non-network related code.➲ Dispatcher, with nice-ish auto-registration➲ Events can be prototyped (not many people seem to realize this)➲ Can be used for delayed (deletion order) problems Code re-use
  28. 28. ➲ How to choose the next reflector?➲ Form voting pools.➲ Majority vote makes host.➲ Perhaps a vote-less algorithm can be found.➲ Ideal would be to use external server (Matchmaking2 lobby messages?) as host voting reflector.➲ Without a server, split games are possible, although merging split games is possible Host Migration