[Standards-JIG] New version of chess game protocol
mridul at sun.com
Thu Oct 5 18:48:16 UTC 2006
Please see inline.
Michal vorner Vaner wrote:
> On Tue, Oct 03, 2006 at 04:36:44AM +0530, Mridul wrote:
>> Michal vorner Vaner wrote:
>>> there is a new version of the chess game protocol in the inbox.
>>> If you want to have a look, I would be delighted to hear opinions.
>>> Thank you
>> Some thoughts on this proto-jep , and also on gamesessions (in the
>> context of this proposal).
>> gamesessions :
>> 1) Who creates the gid ?
>> If it is the responsibility of the client , then how can it be expected
>> to be unique ?
>> From my understanding , gid will identify a game to which others could
>> potentially connect - so shouldn't this not be assigned by the server ?
> It is created by the one who first needs to put one there.
> Well, it is created by the client. But as mentioned in the JEP (I hope I
> did mention it somewhere), it SHOULD contain full JID of the creator and
> a timestamp or some kind of hash of this, so it will not happen someone
> just asks you again with the same ID. The client could then mismatch
> the 2 games.
Section 5 talks about game list as though it is centrally hosted by some
server/component : in which case uniqueness can be gaurenteed only at
the server side.
That is the ambigous part of the spec : it is not very clear as to what
needs to be done by a client , what is to be done at the server side.
Some of the part's are mentioned as client side in one instance and for
a slightly different case , gets pushed to the server : spectating is an
example of this.
It might make sense to clearly demarcate both.
In the context of spectating , I have more comments below.
>> 2) "One to one game, with spectators" - In the context of chess games ,
>> which is essentially falling under this category :
>> Are the client's supposed to take care of it ?
> Under "normal" match, you usually do not want people to watch, so you do
> not need it. And even if you want some friend of you to watch, you have
> this mirroring better (it seems to me) than negotiating for a server
> component, which actually does not exist, you have to discover it, which
> is error-prone (see actual state of file transfer proxies).
Is it the intention that a single game gets treated seperately for one
to one , and same game gets treated differently when there are > 2
participants or spectators also involved ?
It is logically possible - consider the analogy of a one to one chat
becoming a muc when there are > 2 participants.
If this is the intention , then it is fine (though this is not mentioned
in the spec) - when I was going through it, at different spots , I felt
that it should be handled differently.
>> Or do the spectators
>> connect to the component/server and view a game ?
>> It would be heavy if the client has to manage spectating - imagine
>> kasparov vs anand game :-)
> Hm, it would need some kind of "man-in-the-middle" component. Maybe I
> should not it there. It goes to TODO.
Yep , two client's managing a 1 to 1 game is fine as long as it will
remain 1 to 1.
Else , we need a muc style component in the middle which manages things.
Actually even a 1 to 1 game has issues of rule validation , timing , etc
- which would typically require some sort of server side support.
>> Also , how about acl's for this ? (tutor session/class similar to muc , etc)
>> Actually , I did not see anything about how a client would initiate a
>> spectating session for a game in the proposal.
> There is whole section 8 about creating spectator session.
I was talking w.r.t gamesessions here.
Btw , this would be the first spec I have seen (unless I am forgetting
something) , which is expecting the client to do routing of messages :-)
>> Typically , spectating involves side chatter : some of which is also
>> visible to the players , and some of which are not : makes all the more
>> sense to move it out of the control of the client.
> But where?
To the server side ofcourse - where else !
The general philosophy , from what I see , in xmpp is to have a tradeoff
as to make the clients lighter ... sometimes at the cost of making the
servers more 'heavy'.
>> chess :
>> 1) Time related attributes.
>> There are a whole series of timing considerations in chess games : sec
>> per move , fischer time control , primary/secondary/etc time controls of
>> time per x moves , etc : and different UI's support different subsets of
> Hm, I must admit I'm not really good in time and chess. I play chess
> sometimes and I wanted jabber-based client, so I started writing one.
> And when describing the protocol, I added some time measuring. Maybe I
> will look at that.
>> 2) There are variations of chess where more than 2 players play - this
>> is not handled by the spec I believe (refer to 3).
>> 3) There are a large number of variants of chess - refer here for a
>> small list : http://www.chessclub.com/helpcenter/tips/wild.html
>> There should be some way to negotiate this.
> Well, these is not chess as is, you just can expect normal clients to
> support this. So if you create special client for lets say 3-people
> chess, you need to define new protocol, which may reuse this one as the
> core and extend it.
The way it stands , it is not really possible to extend the jep to
support other varients.
Like for example , bughouse (4 player).
Also , the spec makes assumptions about the game itself - and expects
well behaved clients from a chess point of view.
I have seen a lot of such efforts going down when there was inadequate
server side support on rule validation ... and in an aborted chess
server effort that I did with a friend long time back, it became very
obvious that you totally need server side support on rule validation.
Rule validation , time management and gamestate management are the most
critical aspects - rest are just features.
Need not be built into the xmpp server - could be an external server
>> 4) Considering that you already have (3) above , I think the ruleset
>> attribute could be modified for this - the current rules mentioned are
>> not really very useful imo ...
>> 5) There is a standard way to represent chess positions : FEN
>> (http://en.wikipedia.org/wiki/Forsyth-Edwards_Notation) for normal chess
>> , X-FEN(http://en.wikipedia.org/wiki/X-FEN) and shredder FEN for fischer
>> random chess - not sure about other variants.
>> Similarly , for communicating games , there is a PGN standard format.
>> It would make sense not to invent another format - all UI's I know
>> support FEN already.
>> Btw , the 'piece' attribute could be considered broken from a chess
>> point of view actually.
> Will have a look there.
>> 6) Maybe I did not get this point ... but who manages a game ?
>> The gamesessions seems to indicate that 1 to 1 games would be managed by
>> the players themselves ... in which case , time synchronization ,
>> checking of rules , etc have to be managed by the client ?
>> If not , then how are the errors , timeouts , etc to be sent ?
> It is done by the clients. If one client "catches" the other while
> cheating (or playing over time), it accuses the other one of it and
Most cases , this would not work - you would end up with cases where
both sides claim a win on time.
There have been cases of buggy clients claiming illegal move (one after
other - especially in varients) when things were valid , vice versa , etc.
The number of combinations here are hairy , and frankly I am not really
sure of the full intent of the spec.
If the intention is that we allows users to play a game of chess from
their client using xmpp as the transport , then it becomes important
that we end up defining the spec of a server side component.
You query the chess component , 'seek' a game or initiate a match
against a specific user , have the component manage your games (time ,
game state , etc) , etc - becomes something akin to muc in some respects.
If the idea is to allow any arbitrary clients to initiate a one to one
game (similar to 1-1 chat) and restrict ourselves to that : then it is
much more simpler , but severely limited.
>> 7) Might be useful to add a move number to gameflow. Also , it does not
>> consider extra semantics necessary for (3) above ...
> Can't you just count in your client? No-one sends how many messages did
> you sent already with chat, do you?
Hmm , in chat , out of order delivery , though rare when it does happen
, is not a severe error.
Btw , you need not start a game from the begining of an opening position
- but could be an adjourned game , or a game continuing from a well
known position - or if you allow examining moves , you will have a
series of make/unmake moves (by multiple people).
These are just real world problems in writing a chess server ...
>> 8) I am not very sure of the client's managing spectating ... might make
>> more sense for the server or external component to manage this (I
>> mention this under gamesessions actually).
> Yes, I will try to think about the game component, which might be as
> well used for the middle spectator. But I want simple (1 to 1) games to
> be possible to play without any server support.
>> 9) Other ideas which are currently available in most online chess server :
>> a) Adjournment of game ?
>> b) Retrieving a move list to continue a previously adjourned game
>> c) Browsing game history.
> No need for protocol for this one, if you need a chat history you keep
> it. If you need game history, you keep it.
Agreed about game history - could be an additional feature for specific
Adjourned games are typically kept at the server - else both clients
could end up tampering with the games and making it go out of sync.
>> d) Examine a game (could have multiple users modifying the board).
> Well, I would not like to overcomplicate it, I want to be able to make a
> simple client that allows 'only' to play chess.
Just as an aside : examining games is the logical extension of playing
chess for even moderately serious chess players.
You lose a game , you examine it with friends/master's to understand
your game better.
Ofcourse , like I mention above - either we can define a more complete
protocol or limit it to a simple case.
I have seen a lot of client protocol and also server side efforts come
to a stop in the chess world just cos it is not supporting essential and
People tend to be very serious about the games (you should check out one
of those online multicasts in action :-) ) , and designing something
which makes assumptions about the 'goodwill' of the participants maynot
become widely adopted (the cheating will drive people away).
If we do define a spec in this space for xmpp , when game programmers
try to use xmpp as a middleware for online servers (yep , some are
seriously considering this already) , it should not lead them to
insecure implementations 'cos of our simplifying assumptions : just as
it would be good if they did use these xep's for their requirements.
>> If I am not wrong , the protocol's of most of the online chess servers
>> are public (a search showed me icc format :
>> ftp://ftp.chessclub.com/pub/icc/formats/formats.txt , I am sure fics ,
>> others will also have their formats out there somewhere)... so it would
>> help us to take a look at what they support and what they allow.
>> We may not want to model all of it , but should be reasonably flexible
>> to allow the jep to be used for supporting these as required.
>> Wanted to comment only about the time thingy ... but became a much
>> bigger mail than I expected :-)
More information about the Standards