Simulation Concurrency.

Client-server, server side
Per server side frame:
  Server gathers pending position/orientation and commands like "shoot gun"
  Commands are checked against game rules and conflicts with other commands.
    Conflicting parties are notified about the conflict and server decision.
  At periodic update rate:
    Server applies accumulated updates and commands in a way that does not have ordering bias.
    Run one simulation step (e.g. apply physics, dead reckoning)
    Distributes updates based on the last acknowledgment of each client.
    Server counts time in server frames.
 
Client-server, client side
Per rendering frame:
  Get input from user.
  Get updates from server.
  Commands are checked against game rules and conflicts with other commands.
    In the event of a conflict, the server "wins".
  Apply accumulated commands in a way that is order independent
  Run one simulation step (e.g. apply physics, dead reckoning)
  Render frame.
  Client counts time in rendering frames.
Per server side frame:
  Client responds to server update with acknowledgment 
    and sends position/orientation/other pending commands to server
    (no advantage gained by sending more often)


Pure peer-to-peer
Per peer frame:
  Get input from user.
  Get broadcasts.
  Commands are checked against game rules and conflicts with other commands.
    In the event of a conflict, need to have deterministic way of breaking ties
      or rolling back events that all nodes follow
  Apply accumulated commands in a way that is order independent
  Run one simulation step (e.g. apply physics, dead reckoning)
  Render frame.
  Peer counts time in rendering frames.
Per broadcast frame:
  Time server sends out "tick"
  Peers respond with position/orientation and other commands