HW7 Notes from class on how 2-player Pong can use a DB to communicate

Schema: ids are generated, and are the table PKs
pong_match: (id, max_x, max_y, player_count, move_count)
           gen'd 600    400       1 or 2      0, 1, 2, ...

pong_move: (id, match_id, index,   end,   paddle_y, status)
          gen'd   FK      
  (match_id, index) is unique (business key)
  index = 0, 1, 2, ...   move number for this game
  end = 'A' or 'B' for player who made move
  paddle_y = paddle y when ball reaches the "bounce surface" (see Pong3's Extrapolator)
  status = 'INIT', "BOUNCE', 'EXIT', 'INTERMEDIATE' (optional), possibly others if you need them

First player to run PlayGame turns out to be A, second is B.
1. A player starts a match with PongGame sending a "startMatch1" message, which does the following to the database:
a. Check for any single-player matches (this will fail for A)
b. If none, insert a new row in pong_match with player_count = 1
This new row (PongMatch object) is returned to PongGame, which determines it is the A end, and what the match_id is (it is the A end because player_count = 1, not 2).

2. A sends a startMatch2 message which does the following with the DB:
a. read the match_id row and return it.  If this returned row has player_count = 2, then return it to PongGame
b. repeat a. (in a new transaction, after a delay)

While 2. is waiting, the second player starts a game
3. A player starts a match with PongGame sending a "startMatch1" message, which does the following to the database:
a. Check for any single-player matches (this will succeed for B)
b. Update the playerCount from 1 to 2 in that row and return it.
This new row is returned to PongGame, which determines it is the B end, and what the match_id is (it is the B end because player_count = 2).

Now 2. returns for A to PongGame. Both PongGame ends know the match_id and their end A/B.

4. A's PongGame starts the ball and sends an INIT move, and in the DB code, inserts a move with index = 0, end = 'A', paddle_y = 0, status = 'INIT', and updating the move_count. As soon as this is done, A's DB support starts reading the match row to check for increases in move_count, with delays between checks.

5. At the same time as 4., B's PongGame sends a request and its DB code starts reading the match row to detect when the move_count increases. When it does, it returns the row to PongGame, which starts the ball.

6. B's player moves the paddle to bounce the ball. What is crucial is the paddleY at the moment the ball reaches the bounce surface: this is reported back to the database by PongGame sending a request to the DB code to insert a new row in pong_move, with index = 1, end = 'B', paddle_y = y at bounce/miss, status = 'BOUNCE' or 'EXIT'. Then B's DB code starts checking move_count.

7. A's database support sees the increase in move_count and returns the corresponding move to A's PongGame. This tells the A end what the B end player did. PongGame displays the move. Since the ball will already be past the bounce surface at this point if nothing special is done, you probably want to let it bounce against the bounce surface and fix up the picture in the case that B missed the ball (or just hide the ball as soon as you find out.)

8. A sends the next move, and starts checking...

9. ...