src/networking.txt

   1 * Networking
   2         Don't bother with a client/server relationship (eg freeciv).  This game should
   3         just be peer based.  Just pick some random unused port as a default.
   4         The user should be able pick whatever port he wants, and whatever he
   5         selects should be stored in the .gamazons file.
   6
   7         Hmm, we'll need to have one program listening on a port and another one
   8         trying to make a connection.  Should it listen automatically? or only
   9         upon request?  (Request)
  10
  11         How should each move be transmitted?  Should it be a simple string like
  12         that in the move history?  Then the receiving side would need to break
  13         it down to notify the engine what move was made.  How would this affect
  14         player options?  Should I now have Human, AI, & Remote?  If I leave the
  15         remote player marked as 'Human', the local human could muck w/ the move
  16         and really screw up the state.
  17
  18         What about loading games?  For local games, I'd like to be able to save
  19         a move history, then load either an unfinished game, or reenact a
  20         previously played game.  If I try to finish a networked game, I need to
  21         develop a way for both sides to get in sync (either by both sides
  22         loading the same file, or by one loading it and the other getting its
  23         state from its peer).  On the other hand, if by virtue of connecting to
  24         another peer, a new game is started, the connection protocol is greatly
  25         simplified.  But if I change the protocol later on down the line to
  26         support these features, it may render the clients unable to communicate
  27         properly.  Perhaps I should include the version of the client in the
  28         protocol, so future versions will know what protocol portions are
  29         understood.
  30
  31         Protocol: Specify who is playing what.  If client1's black player is
  32         remote, client2's white player must be remote.  A client cannot have
  33         more than one remote player specified.  Possibly, the clients could
  34         cycle through the list of commands they understand, then the accepted
  35         protocol must be the "lowest common denominator", and what features are
  36         allowed are based on what both understand.
  37
  38         Error recovery: Errors have different degrees of severity.  How should I
  39         deal with recovering from various possible errors?  Should I specify the
  40         severity of the error with the error command?
  41
  42         Protocol Definition:
  43         Command         Arguments                       Example
  44         -------         -------                         --------
  45         MOVE            Move #. From-To, Arrow          "1. d1-d7, g7"
  46         START           P1=TYPE, P2=TYPE                "P1=Human", "P2=Remote"
  47         WIN             Player                          "P1"
  48         QUERY           Command                         "MOVE"
  49         RESPONSE        Command, Value                  "MOVE TRUE" or "MOVE FALSE"
  50         ERROR           ErrID#
  51         MSG             Text message                    "I'm taking you down"
  52         DISCONNECT      None
  53         CONNECT         None
  54
  55         LOAD START
  56         LOAD MOVE
  57         LOAD FINISH
  58
  59         Error types:
  60         Unknown command
  61         Illegal Move
  62         Invalid Parameters
  63         Confused State
  64
  65
  66         Command Behavior:
  67         MOVE    Notifies remote client what the local client just did
  68         START   Verifies both sides have compatible player settings (ie both
  69                 clients aren't trying to be white) and initializes board to
  70                 original state.
  71         WIN     Notifies remote client that the game was just won by which
  72                 player.
  73         QUERY   Asks remote client if it understands a certain command.  It
  74                 builds a list of acceptable commands that both can agree on.
  75         RESPONSE  Replies to a query, notifies asker whether it knows that
  76                 command or not.
  77         ERROR   Notifies remote client an error has occured.