LECTURE 7: November 2, 2009 

----------------------------------------------------------------------
'hour 3' : distributed worlds 

  demo of 'balls across worlds' : 
   $ cd demo
   $ ./xrun 
   $ ./xplayer mitch &
  then stop players by destroying their windows (even the one 
  that is running right now) 

  explain server state window:
  -- sever up
  -- server notices new players 
     -- including 'mitch' 
  -- server notices message arrivals (and re-distributes them)
  -- server notices 'world destruction' 

 QUESTION: how to design universe programs? 

 1. Who are the actors in a universe program? 

    -- a server 
    -- all worlds that make themselves known to the server 

 2. What can happen in a universe program? 

    Events, and we care about these: 
    -- a world joins the universe 
       by making itself known to the server
    -- a world sends a message to the server
    -- the server sends a message to a world 
    -- a world disappears from the universe 
    ... 

    These events are unordered. Once the server runs, 
    these events can happen in an any order because 
    machines run at different speeds, connections are 
    possibly severed, etc. 

    The only thing we are guaranteed is that messages 
    from one actor to another arrive in the order sent, 
    i.e., if actor A sends actor B 3 messages X, Y, and 
    then Z, then these messages arrive at B in the order X, 
    Y, and Z. 

 3. Who knows what at which point? 

    That all depends on the kind of program that's running.

    Example 1: a board game, each world is a player, 
      the server is the referee 

      in this case each player should only reveal 
      the absolute minimum necessary; not even the 
      server knows the player's 'AI' state though of 
      course the server must keep track of all of the 
      players' 'moves' 

    Example 2: a chat room, each world is a 'chatter'
      the server forwards messages as specified 

      each world knows everything it sent out and 
      what it received; only the server knows everyone
      -- one world may communicate to another without 
      the third one knowing anything 

 4. The goal of the design is to coordinate the activities 
    of all participant worlds and to communicate information 
    as needed. 

    We use interaction diagrams to specify the desired and 
    feasible message flow. Three scenarios matter most: 

    STARTUP: each world that joins registers with the server
      and must possibly exchange some information 

    MID-STREAM: the server ensures that only those events 
      become visible that are allowed to be visible. 

      example: in a board game, only the active player may 
      exchange messages with the server 
      
      example: in an action game, all players may act 
      simultaneously and the server must ensure that 
      all players know what they need to know 

      example: in a chat room, all chatters act in parallel 
      and the server must manage the message flow as specified
      in the messages

    SHUT-DOWN: when a world disappears, the server may have
      to inform other worlds, let them know things, re-calculate 
      the game state, etc. 

      DIAGRAMS: prototypical scenarios, representing all 
      three phases
   
      use life lines (vertical) and message arrows (horizontal)
	
      example for demo:

   server 
     *         sam         carl 
     |          *           * 
     | i'm here |           |
     | <======= |           |
     |          | i'm here  |
     | <=================== |           actors can register anytime 
     |          |           |
     |    go!   |           |
     | -------> |           |           actors get 'go!' messages 
     |          | i'm here  |     mitch in order of registration 
     | <=========================== *
     |   done   |           |       |
     | <------- |           |       |   only one actor is active 
     |          |   go!     |       |
     | -------------------> |       |
     |          |  done     |       |
     | <------------------- |       |
     |          |           |  go! |
     | ---------------------------> |
     |          |           |       |               
     |          +           |       |   actors can leave anytime 
     |                      | done  |
     | <--------------------------- |
     |              go!     |       |
     | -------------------> |       |
     |                      +       |   ... including when active 
     |                        go!   |
     | ---------------------------> |   but the band plays on