Editing Miniature/Development/Phase 2.0: Real-time P2P Miniature/P2P-Protocol

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

Protocol draft for Miniature-P2P
 ================================
 
 We will assume that P1 and P2 have already found each other and are able to
 chat ("match nick" in FICS).
 
 >>jukey>>
 We also should assume that both players are using Miniature. One
 example what happens if not is described in one of my comments below
 (automatc/manual acceptance of games).
 <<jukey<<
 
 A Chat
 ======
 
 * "tell [nick|#channel] msg"
   Why nick and #channel? Because later we migt want observers in P2P (so
   there'd be a channel #obs, because you dont want the players so see the chat
   of kibitzs).
 
 * http://www.freechess.org/Help/HelpFiles/tell.html
 
 * This command is the *only* one that will work in every situation, without
   exception. It does not change the current game state.
 
 
 B Game mode negotiation
 =======================
 
 * Both of the players can now propose a game mode, similar to
   http://www.freechess.org/Help/HelpFiles/seek.html
 
 * We can skip the parameters we dont support yet, so we need at least be able
   to send/parse this:
 
   "seek [time inc] [rated|unrated] [white|black]"
 
 >>jukey>> It makes sense to make the [white|black] value optional. If it's not
 available the game can be accepted by people who had choosen black, white or
 nothing. I personally like the possibility to play "random colored" games.
 <<jukey<<
 
 * Examples:
   "seek 5 0 r w":         5 minutes, no incr, rated, seeker wants white,
   "seek 5 0 rated white": same as above,
   "seek 2 10 u b":        2 minutes, 10s incr, unrated, seeker wants black
 >>jukey>>
   "seek 2 12 r":	2 minutes, 12s incr, rated, seeker wants black or white
 <<jukey<<
 
 
 * When the other player receives a seek, he can either accept the offer or
   ignore it. Both players could propose game modes sending as many seeks as
   they want, and at any time! But that would be silly in our case, so let's
   simplify this dramatically:
 
   1 host player (P1) sends seek,
     A client player (P2) accepts seek: send "play" → 2
     B P2 ignores seek: P2 can now send a seek
       A P1 accepts seek: send "play" → 2
       B P1 ignores seek: → 1
   2 game starts (http://www.freechess.org/Help/HelpFiles/play.html)
 
 >>jukey>>
 There is possible a special situation if you opponent is not using
 Miniature (which not allows the players to choose if they want to start the game
 manually or automaticly) and don't automaticly accept games. See fourth
 paragraph in http://www.freechess.org/Help/HelpFiles/play.html :
 "If the ad calls
 for a manual start, the other user will be notified that you are challenging
 him/her to a match; he/she then can accept or decline your offer to play that
 match."
 In this case the description above changes into:
   1 host player (P1) sends seek,
     A client player (P2) accepts seek: send "play" → 2
     B P2 ignores seek: P2 can now send a seek
       A P1 accepts seek: send "play" → 2
       	A P2 using manual as seek parameter accepts the offer to play from P1 → 2
       	B P2 using manual as seek parameter declines the offer to play from P1 → 1
       	C P2 using manual as seek parameter accepts the offer to play from P1
 						 but P1 is no more available (for example in an other game) → 3
       B P1 ignores seek: → 1
   2 game starts (http://www.freechess.org/Help/HelpFiles/play.html)
   3 P1 is shown as not ready to play
 <<jukey<< 
 
 
 C Moves
 =======
 
 * In FICS, once it is your turn, it is sufficient to enter "e2-e4" to move your
   pawn, for example.
 
 * FICS sends the new position to each player, obviously this simplifies sync
   issues. So I think we should send sth like "move e2-e4; fen
   rnbqkbnr/pppppppp/8/8/4/P/3/8/PPPP1PPP/RNBQKBNR b". The FEN position string
   can be seen as checksum for the move, so we are able to always detect sync
   issues.  In case of an sync issue, the FEN position *overrides* the move, and
   the error is logged (maybe even send "sync error" back to sender, so both
   peers are aware). How to handle that beyond logging the error, I do not know.
   Let's see if it really happens first. The more general approach is to have
   the receiving peer always confirm a move with a checksum, based on the
   position info it was able to compute, and the sending peer then compares this
   checksum, and complains.
 
 * The peers compute the status (check, checkmate, ...) themselves, based on the
   position info send
 
 * Move requests that are sent when it is not the player's turn should
   be silently discarded.
 >>jukey>>
 Maybe the client also should not be able to send a request if it is
 the opponents move.
 <<jukey<<
 
 D Takeback
 ==========
 * FICS is a bit funny here, showing its age wrt verbose & racy protocol
   implementation "takeback 2 - accept - withdraw", note how accept and withdraw
   can happen at the same time.
   http://www.freechess.org/Help/HelpFiles/takeback.html
 
 * Again, let's simplify:
   "takeback n", request to take back n moves, answered by "takeback n" (the
   same n) to accept. Now it doesn't even matter who sends it first.
   1 P1 sends "takeback n",
     A P2 accepts: send "takeback n" → 2
     B P2 declines: nothing happens → 3.
   2 N half-moves are taken back.
   3 P2 or P1 sends his next move (notice how this can clash with a "takeback n"
     confirmation in case it was P1's turn, in which case the takeback
     confirmation should win, as P2 is free to ignore P1's move after confirming
     the takeback).
 
 * Same as with moves, we send: "takeback n; fen current/fen/pos/ w|b", so that
   the fen position is the one to be expected after takeback n would be
   performed (assuming we go without the general approach of sending checksums
   after every position change).
 
 * A takeback request can be simply ignored without further actions.
 
 
 E Draw
 ======
 * http://www.freechess.org/Help/HelpFiles/draw.html
 
 * We don't support claiming a draw yet, but that will be easy to implement:
   before the other peer gets chance to say ok, "draw", we query the logic
   analyzer, which is entitled to enforce a technical "draw".
 
 * Otherwise, same as in takeback, without position sending:
   1 P1 sends "draw",
     A P2 accepts: send "draw" → 2
     B P2 declines: nothing happens → 3.
   2 Game ends in draw.
   3 P1 sends his next move (P2 is not allowed to demand a draw if it is not his
     turn, also, same conflict resolution as in takeback: draw confirmation wins
     over P1's move, and P2 is free to ignore the move).
 
 
 F Resign
 ========
 * http://www.freechess.org/Help/HelpFiles/resign.html
 
 * Players can resign at any time, I guess? No confirmation by other player
   needed, game ends.
 
 
 G Adjourn
 =========
 * http://www.freechess.org/Help/HelpFiles/adjourn.html
 
 * I like the 2 cases presented on FICS, esp. the courtesy adjourn which handles
   time-outs gracefully.
 
 * Similar to draw and takeback:
   1 P1 ran out of time, unresponsive
     A P2 sends "adjourn" → 3
     (B P2 claims the win, not important yet for our case)
   2 P1 sends "adjourn"
     A P2 accepts: send "adjourn" → 3
     B P2 declines: nothing happens
   3 Game is adjourned, both sides save the current position locally, game ends.

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "https://wiki.maemo.org/Miniature/Development/Phase_2.0:_Real-time_P2P_Miniature/P2P-Protocol"

Personal tools

Navigation

Views

Editing Miniature/Development/Phase 2.0: Real-time P2P Miniature/P2P-Protocol

@@ Line 1: / Line 1: @@
-[[Category:Miniature]]
+ Protocol draft for Miniature-P2P
-Protocol draft for Miniature-P2P
   ================================
-  We will assume that P1 and P2 have already found each other, use a Miniature
+  We will assume that P1 and P2 have already found each other and are able to
- client** and are able to chat ("match nick" in FICS).
+ chat ("match nick" in FICS).
+ >>jukey>>
+ We also should assume that both players are using Miniature. One
+ example what happens if not is described in one of my comments below
+ (automatc/manual acceptance of games).
+ <<jukey<<
- (**) For now. We will want to lift this restriction and offer Miniature/Telepathy-Chess
- plugins for other applications (in the far distant future, that is).
   A Chat
   ======
@@ Line 23: / Line 23: @@
   * This command is the *only* one that will work in every situation, without
     exception. It does not change the current game state.
   B Game mode negotiation
   =======================
@@ Line 34: / Line 34: @@
     to send/parse this:
-    "seek [time inc] [rated|unrated] [white|black|any]"
+    "seek [time inc] [rated|unrated] [white|black]"
-  * If the seeker offers "any" colors it means he his indifferent wrt. color choice.
+  >>jukey>> It makes sense to make the [white|black] value optional. If it's not
-   Such games the game can be accepted by people who had choosen black, white or
+ available the game can be accepted by people who had choosen black, white or
-   any.
+ nothing. I personally like the possibility to play "random colored" games.
+ <<jukey<<
   * Examples:
@@ Line 44: / Line 45: @@
     "seek 5 0 rated white": same as above,
     "seek 2 10 u b":        2 minutes, 10s incr, unrated, seeker wants black
-    "seek 2 12 r a":	2 minutes, 12s incr, rated, seeker wants black or white
+ >>jukey>>
+    "seek 2 12 r":	2 minutes, 12s incr, rated, seeker wants black or white
+ <<jukey<<
@@ Line 58: / Line 61: @@
         B P1 ignores seek: → 1
 game starts (http://www.freechess.org/Help/HelpFiles/play.html)
- * A seek is accepted by sending the same seek back (with the exception of color
-   choosing, where "any" always matches).
   >>jukey>>
@@ Line 83: / Line 83: @@
 game starts (http://www.freechess.org/Help/HelpFiles/play.html)
 P1 is shown as not ready to play
- >>mikhas>>
- telepathy has the concept of channels and resources. one channel would be the
- one of available players, and you would probably set your availibility much like in
- normal jabber chats if I understood that part correctly.
- <<mikhas<<
   <<jukey<<
-  C Moves
+ C Moves
   =======
@@ Line 117: / Line 112: @@
   Maybe the client also should not be able to send a request if it is
   the opponents move.
- >>mikhas>>
- Not really needed, and one should not rely on that because of the inherent raciness.
- It is better to mostly define the protocol from the "what data should I accept in
- which state" point of view.
- <<mikhas<<
   <<jukey<<
   D Takeback
   ==========
@@ Line 150: / Line 139: @@
   * A takeback request can be simply ignored without further actions.
   E Draw
   ======
@@ Line 168: / Line 157: @@
       turn, also, same conflict resolution as in takeback: draw confirmation wins
       over P1's move, and P2 is free to ignore the move).
   F Resign
   ========
@@ Line 176: / Line 165: @@
   * Players can resign at any time, I guess? No confirmation by other player
     needed, game ends.
   G Adjourn
   =========