Miniature/Development/Phase 2.0: Real-time P2P Miniature/P2P-Protocol - Revision history

imported_>amigadave: categorise

2010-04-19T09:06:43Z

categorise

← Older revision		Revision as of 09:06, 19 April 2010
Line 1:		Line 1:
	Protocol draft for Miniature-P2P		[[Category:Miniature]]

			Protocol draft for Miniature-P2P
	================================		================================

imported_>mikhas at 18:25, 15 April 2010

2010-04-15T18:25:28Z

← Older revision		Revision as of 18:25, 15 April 2010
Line 2:		Line 2:
	================================		================================

	We will assume that P1 and P2 have already found each other and are able to		We will assume that P1 and P2 have already found each other, use a Miniature
	chat ("match nick" in FICS).		client** 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<<~~

			(**) 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		A Chat
	======		======
Line 23:		Line 21:
	* This command is the only one that will work in every situation, without		* This command is the only one that will work in every situation, without
	exception. It does not change the current game state.		exception. It does not change the current game state.


	B Game mode negotiation		B Game mode negotiation
	=======================		=======================
Line 58:		Line 56:
	B P1 ignores seek: → 1		B P1 ignores seek: → 1
	2 game starts (http://www.freechess.org/Help/HelpFiles/play.html)		2 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		* A seek is accepted by sending the same seek back (with the exception of color
	choosing, where "any" always matches).		choosing, where "any" always matches).

	>>jukey>>		>>jukey>>
	There is possible a special situation if you opponent is not using		There is possible a special situation if you opponent is not using
Line 90:		Line 88:
	<<jukey<<		<<jukey<<


	C Moves		C Moves
	=======		=======
Line 123:		Line 121:
	<<mikhas<<		<<mikhas<<
	<<jukey<<		<<jukey<<


	D Takeback		D Takeback
	==========		==========
Line 149:		Line 148:

	* A takeback request can be simply ignored without further actions.		* A takeback request can be simply ignored without further actions.


	E Draw		E Draw
	======		======
Line 167:		Line 166:
	turn, also, same conflict resolution as in takeback: draw confirmation wins		turn, also, same conflict resolution as in takeback: draw confirmation wins
	over P1's move, and P2 is free to ignore the move).		over P1's move, and P2 is free to ignore the move).


	F Resign		F Resign
	========		========
Line 175:		Line 174:
	* Players can resign at any time, I guess? No confirmation by other player		* Players can resign at any time, I guess? No confirmation by other player
	needed, game ends.		needed, game ends.


	G Adjourn		G Adjourn
	=========		=========

imported_>mikhas at 18:21, 15 April 2010

2010-04-15T18:21:40Z

← Older revision		Revision as of 18:21, 15 April 2010
Line 59:		Line 59:
	2 game starts (http://www.freechess.org/Help/HelpFiles/play.html)		2 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		* A seek is accepted by sending the same seek back (with the exception of color
	choosing, where "any" always matches).		choosing, where "any" always matches).

	>>jukey>>		>>jukey>>

imported_>mikhas at 18:21, 15 April 2010

2010-04-15T18:21:07Z

← Older revision		Revision as of 18:21, 15 April 2010
Line 34:		Line 34:
	to send/parse this:		to send/parse this:

	"seek [time inc] [rated\|unrated] [white\|black]"		"seek [time inc] [rated\|unrated] [white\|black\|any]"

	~~>>jukey>> It makes sense to make~~ the ~~[white\|black] value optional~~. ~~If it's not~~		* If the seeker offers "any" colors it means he his indifferent wrt. color choice.
	~~available~~ the game can be accepted by people who had choosen black, white or		Such games the game can be accepted by people who had choosen black, white or
	~~nothing. I personally like the possibility to play "random colored" games~~.		any.
	~~<<jukey<<~~

	* Examples:		* Examples:
Line 45:		Line 44:
	"seek 5 0 rated white": same as above,		"seek 5 0 rated white": same as above,
	"seek 2 10 u b": 2 minutes, 10s incr, unrated, seeker wants black		"seek 2 10 u b": 2 minutes, 10s incr, unrated, seeker wants black
	~~>>jukey>>~~		"seek 2 12 r a": 2 minutes, 12s incr, rated, seeker wants black or white
	"seek 2 12 r": 2 minutes, 12s incr, rated, seeker wants black or white
	~~<<jukey<<~~


Line 61:		Line 58:
	B P1 ignores seek: → 1		B P1 ignores seek: → 1
	2 game starts (http://www.freechess.org/Help/HelpFiles/play.html)		2 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>>		>>jukey>>
	There is possible a special situation if you opponent is not using		There is possible a special situation if you opponent is not using
Line 83:		Line 83:
	2 game starts (http://www.freechess.org/Help/HelpFiles/play.html)		2 game starts (http://www.freechess.org/Help/HelpFiles/play.html)
	3 P1 is shown as not ready to play		3 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<<		<<jukey<<


			C Moves
	C Moves
	=======		=======

Line 112:		Line 117:
	Maybe the client also should not be able to send a request if it is		Maybe the client also should not be able to send a request if it is
	the opponents move.		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<<		<<jukey<<

imported_>jukey: My comments to paragaphs A, B and C

2010-04-15T10:04:18Z

My comments to paragaphs A, B and C

← Older revision		Revision as of 10:04, 15 April 2010
Line 1:		Line 1:
	Protocol draft for Miniature-P2P ~~(by Michael Hasselmann)~~		Protocol draft for Miniature-P2P
	================================		================================

Line 5:		Line 5:
	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<<

	A Chat		A Chat
Line 30:		Line 35:

	"seek [time inc] [rated\|unrated] [white\|black]"		"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:		* Examples:
Line 35:		Line 45:
	"seek 5 0 rated white": same as above,		"seek 5 0 rated white": same as above,
	"seek 2 10 u b": 2 minutes, 10s incr, unrated, seeker wants black		"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		* When the other player receives a seek, he can either accept the offer or
Line 42:		Line 56:

	1 host player (P1) sends seek,		1 host player (P1) sends seek,
	A client player (P2) accepts seek: send "play" ? 2		A client player (P2) accepts seek: send "play" → 2
	B P2 ignores seek: P2 can now send a seek		B P2 ignores seek: P2 can now send a seek
	A P1 accepts seek: send "play" ? 2		A P1 accepts seek: send "play" → 2
	B P1 ignores seek: ? 1		B P1 ignores seek: → 1
	2 game starts (http://www.freechess.org/Help/HelpFiles/play.html)		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<<


Line 72:		Line 109:
	* Move requests that are sent when it is not the player's turn should		* Move requests that are sent when it is not the player's turn should
	be silently discarded.		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		D Takeback
Line 85:		Line 125:
	same n) to accept. Now it doesn't even matter who sends it first.		same n) to accept. Now it doesn't even matter who sends it first.
	1 P1 sends "takeback n",		1 P1 sends "takeback n",
	A P2 accepts: send "takeback n" ? 2		A P2 accepts: send "takeback n" → 2
	B P2 declines: nothing happens ? 3.		B P2 declines: nothing happens → 3.
	2 N half-moves are taken back.		2 N half-moves are taken back.
	3 P2 or P1 sends his next move (notice how this can clash with a "takeback n"		3 P2 or P1 sends his next move (notice how this can clash with a "takeback n"
Line 111:		Line 151:
	* Otherwise, same as in takeback, without position sending:		* Otherwise, same as in takeback, without position sending:
	1 P1 sends "draw",		1 P1 sends "draw",
	A P2 accepts: send "draw" ? 2		A P2 accepts: send "draw" → 2
	B P2 declines: nothing happens ? 3.		B P2 declines: nothing happens → 3.
	2 Game ends in draw.		2 Game ends in draw.
	3 P1 sends his next move (P2 is not allowed to demand a draw if it is not his		3 P1 sends his next move (P2 is not allowed to demand a draw if it is not his
Line 136:		Line 176:
	* Similar to draw and takeback:		* Similar to draw and takeback:
	1 P1 ran out of time, unresponsive		1 P1 ran out of time, unresponsive
	A P2 sends "adjourn" ? 3		A P2 sends "adjourn" → 3
	(B P2 claims the win, not important yet for our case)		(B P2 claims the win, not important yet for our case)
	2 P1 sends "adjourn"		2 P1 sends "adjourn"
	A P2 accepts: send "adjourn" ? 3		A P2 accepts: send "adjourn" → 3
	B P2 declines: nothing happens		B P2 declines: nothing happens
	3 Game is adjourned, both sides save the current position locally, game ends.		3 Game is adjourned, both sides save the current position locally, game ends.
	~~----------~~
	~~Initial source: https://garage.maemo.org/pipermail/chess-developer/2010-April/000133.html~~

imported_>jukey: Initial draft: https://garage.maemo.org/pipermail/chess-developer/2010-April/000133.html

2010-04-15T10:00:00Z

Initial draft: https://garage.maemo.org/pipermail/chess-developer/2010-April/000133.html

New page

Protocol draft for Miniature-P2P (by Michael Hasselmann)
================================

We will assume that P1 and P2 have already found each other and are able to
chat ("match nick" in FICS).

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]"

* 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

* 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)

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.

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.
----------
Initial source: https://garage.maemo.org/pipermail/chess-developer/2010-April/000133.html