[Standards-JIG] New version of chess game protocol

Mridul mridul at sun.com
Thu Oct 5 18:48:16 UTC 2006


Hi,

  Please see inline.

Mridul

Michal vorner Vaner wrote:
> On Tue, Oct 03, 2006 at 04:36:44AM +0530, Mridul wrote:
>   
>> Michal vorner Vaner wrote:
>>     
>>> Hello,
>>> there is a new version of the chess game protocol in the inbox.
>>>
>>> http://www.jabber.org/jeps/inbox/chess.html
>>>
>>> If you want to have a look, I would be delighted to hear opinions.
>>>
>>> Thank you
>>>
>>>  
>>>       
>> Hi,
>>
>>  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 
>> these.
>>     
>
> 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 
side component.

>   
>> 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
> terminates.
>   

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 
implementations.
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 
basic requirements.
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.

Regards,
Mridul

>> 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 :-)
>>
>> Regards,
>> Mridul
>>
>>
>>     
>
>   




More information about the Standards mailing list