A list of features you'd like in a new chess server

[sje]

For authors:

What would you like to see in a new chess server designed from the start to be friendly to chess programs?

Some ideas:

1) Do not use telnet protocol; use raw TCP/IP instead.

2) Do not design for raw human text input or output; use a subset of standard XML instead and rely on an appropriate program at the client end.

3) Full open source example interface code, possibly including glue code for existing GUI clients; assume that the client has a typical event loop.

4) Have all who/finger/history/formula/seek/match/etc functionality be available to a connected client; also, sample code for engines to access this functionality for autonomous, exploratory seek and match.

5) Allow the server to try to establish a connection with a logged out client.

6) Fully automated tournaments with absolutely no need for human intervention.

7) Support for common chess variants.

8) Support for some other board games including those with a variable number of players.

9) Full implementation of FIDE rules including the "I'm going to repeat the position, claim a draw, and here's the unplayed move" rule.

10) Facilities for webcasting kibitz and other commentary data including log files.

11) A unique serial number for each game that can be used as a key for database access; other simple database retrieval operations to be supported.

12) Support for extremely long time controls without need for a persistent connection.

13) Multiple simultaneous games per player/connection.

14) Multiple connections per player.

15) Automatically generated periodic newsletters posted to the web.

[Edmund]

I think a big problem is the management of latency and all the cheating protection involved.

Some more general ideas not so much concerned with being friendly to chess programs:

Shared human analysis:
colorable squares, draw/write on the board, etc

chat functionality:
Rooms, whisper, etc

[sje]

More ideas:

16) Millisecond time resolution. Also, multi-segment time controls.

17) Server uses UTC timezone only; clients are responsible for their own time zone settings and adjustments.

18) At least one terabyte of database space capability; this should be good for several decades of game history.

19) Player database clearly distinguishes among general humans, authors, one-per-author designated programs, clones, cyborgs, dedicated machines (hope to have some manufacturer support here), guests, etc.; also, player location data for regional events.

20) Option of auto opponent selection and matching based on priority formula.

21) Option of thematic openings and endgame initial positions.

22) Support for browser based web chat.

23) Eventual support for audio chat; someday even video chat.

24) Uniform standards for extended program hardware specification; data can be used for seek/match operations.

25) Option for distributed computing support; program players can volunteer time for various analysis projects.

26) Support for move analysis score reporting for White POV, Black POV, Engine POV, etc. by defining a standard analysis format.

27) Support for time odds games to better match programs with disparate hardware.

28) Support for non-ASCII data for player database entries.

29) Scheduled down time announced in a standard format (XML, like everything else).

30) Separate ratings by time control and also by opponent class (human, program, cyborg) to help prevent rating abuse.

[sje]

Some more general ideas not so much concerned with being friendly to chess programs:

Shared human analysis:
colorable squares, draw/write on the board, etc

chat functionality:
Rooms, whisper, etc

A lot of this will have to be done by a client, The sever will have to support the needed uniform data exchange, but the client is the one to handle a GUI. I would hope that much of a client can be realized by local HTML I/O with a local browser.

[bob]

For authors:

What would you like to see in a new chess server designed from the start to be friendly to chess programs?

Some ideas:

1) Do not use telnet protocol; use raw TCP/IP instead.

I do not know what that means. "telnet" is not really a protocol. My custom ICS interface uses pure TCP/IP, creating a socket, using connect() to connect to a remote socket, and then read/write to exchange data.

2) Do not design for raw human text input or output; use a subset of standard XML instead and rely on an appropriate program at the client end.

3) Full open source example interface code, possibly including glue code for existing GUI clients; assume that the client has a typical event loop.

4) Have all who/finger/history/formula/seek/match/etc functionality be available to a connected client; also, sample code for engines to access this functionality for autonomous, exploratory seek and match.

Is this not already the case on ICC?

5) Allow the server to try to establish a connection with a logged out client.

Pointless. For many reasons. 1. most clients use a random port to connect to a server, the server learns the port # when the connection is established. (2) Clients don't generally create a passive socket to accept connections, and create an active socket to connect to the server as well. (3) most people sit behind some sort of router/wireless-router that uses NAT to communicate with remote machines. You can't reverse-connect thru such a router easily, you can set up port forwarding if you want, but then you open up pandora's box with respect to attacks; (4) most firewalls won't pass through the incoming connection unless disabled, which defeats the firewall's purpose. (5) if the client dies, no connection is possible anyway. (6) if the client doesn't die, it only gets disconnected via a network failure, which would suggest that it is pointless for the server to attempt to connect back. In the classic client-server model, the server waits for connections, the client initiates connections. Doing otherwise would _really_ make the client code messy, with no benefit I can think of.

6) Fully automated tournaments with absolutely no need for human intervention.

We have this on ICC and it works well. It is nice to really automate things.

7) Support for common chess variants.

8) Support for some other board games including those with a variable number of players.

9) Full implementation of FIDE rules including the "I'm going to repeat the position, claim a draw, and here's the unplayed move" rule.

Couldn't agree more. The current approach works, but is a kludge on top of a kludge.

10) Facilities for webcasting kibitz and other commentary data including log files.

11) A unique serial number for each game that can be used as a key for database access; other simple database retrieval operations to be supported.

12) Support for extremely long time controls without need for a persistent connection.

13) Multiple simultaneous games per player/connection.

This is already present for "simul" type events. I am not sure about the idea of really playing multiple games at the same time, however, as that becomes a major program issue, not just the interface. Now your client has to be able to talk to several different nodes to have an instance of the engine running on each.

14) Multiple connections per player.

15) Automatically generated periodic newsletters posted to the web.

I would add "elimination of all race conditions" by using some sort of "I am done" sentinel, so that I can send a move, followed by a draw claim, without having the server relay the move before it sees the draw claim. In FIDE events, pressing my clock ends my turn to move

[bob]

More ideas:

16) Millisecond time resolution. Also, multi-segment time controls.

17) Server uses UTC timezone only; clients are responsible for their own time zone settings and adjustments.

18) At least one terabyte of database space capability; this should be good for several decades of game history.

19) Player database clearly distinguishes among general humans, authors, one-per-author designated programs, clones, cyborgs, dedicated machines (hope to have some manufacturer support here), guests, etc.; also, player location data for regional events.

20) Option of auto opponent selection and matching based on priority formula.

21) Option of thematic openings and endgame initial positions.

ICC has had this almost forever. You can start a game from any position you want. It is a wild variant.

22) Support for browser based web chat.

23) Eventual support for audio chat; someday even video chat.

24) Uniform standards for extended program hardware specification; data can be used for seek/match operations.

25) Option for distributed computing support; program players can volunteer time for various analysis projects.

26) Support for move analysis score reporting for White POV, Black POV, Engine POV, etc. by defining a standard analysis format.

27) Support for time odds games to better match programs with disparate hardware.

28) Support for non-ASCII data for player database entries.

29) Scheduled down time announced in a standard format (XML, like everything else).

30) Separate ratings by time control and also by opponent class (human, program, cyborg) to help prevent rating abuse.

[kranium]

I do not know what that means. "telnet" is not really a protocol. My custom ICS interface uses pure TCP/IP, creating a socket, using connect() to connect to a remote socket, and then read/write to exchange data.

Bob, in all due respect, i think you got this one wrong...telnet is indeed a real protocol. it's one of the protocols that make up the IP suite...which includes http, ftp, smtp, and many others...

it's recognized by IANA, and has uses well-known ports: 20 (data) and 21 (control).
telnet is one of the the oldest and most fundamental protocols that exist, upon which many other TCP/IP protocols have been built...

my understanding is that most/all of these chess servers (freechess.org, icc), etc. communicate using telnet as the underlying protocol...
but use port 5000, or some other unassigned port instead of the well-known.

[Dann Corbit]

1. Open source, portable to Windows, Linux, Solaris, etc.
2. Public protocol, spelled out like an RFC (and, indeed, if an internet communication application, why not an RFC)
3. Accepts Winboard & UCI protocols along with human friendly interface like Winboard.
4. Retains all the capabilities of current servers like FICS

[bob]

I do not know what that means. "telnet" is not really a protocol. My custom ICS interface uses pure TCP/IP, creating a socket, using connect() to connect to a remote socket, and then read/write to exchange data.

Bob, in all due respect, i think you got this one wrong...telnet is indeed a real protocol. it's one of the protocols that make up the TCP/IP suite...which includes http, ftp, smtp, and many others etc...

it's well-known ports are 20/21
telnet is one of the the oldest and most fundamental protocols that exist, upon which many have been built...

What I am talking about is that there is no "protocol" associated with how data is sent. My custom interface connects to ICC on port 5000 where they are running a telnetd application. But there is no forced exchange of data. There are some cute telnet commands that you can use while connected. But the data transmission is pure TCP/IP, as I mentioned. Xboard connects to a telnet port that is _not_ 20/21. When you use port 20/21 you are saying "I want to create a new connection, get a login process started, and then have to enter a username and password. but you don't have to do that. On ICC for example, when you connect in, you do not get a "login process" your connection is handled directly by the server code.

So my point is that what we are already doing is based on TCP/IP, which has absolutely nothing to do with telnet. We are not using the traditional telnet ports. We don't get a traditional login process to authenticate us before execv'ing to a shell of our choice, etc. There's not one scintilla of "telnet" in ICC's connectivity. The fact that you can use a telnet client just shows that the telnet "protocol" is really non-existant for a very specific definition, since you can use a telnet client to connect to ICC, or you can use a client that knows nothing about telnet at all, and _still_ connect and work just fine.

There's no "telnet" in ICC...

BTW I don't know what I was thinking about, but ports 20/21 are ftp ports, _not_ telnet. Telnet uses port 23 only. And it does work just as I said. On ICC there is no telnet functionality whatsoever other than sending text data back and forth.

[wgarvin]

There is no reason to use XML for anything. Use plain text like the existing chess-related protocols do (ICS, winboard, uci). Just make sure it is clearly and unambiguously specified, make sure it is easy to parse at both ends, and make sure it is easy to extend the protocol in the future if that turns out to be necessary.

XML would not only make the protocol contents ugly as sin (which is annoying for people who have to read logs of it or debug it), it would make proper parsing and handling way more complicated and cumbersome than it needs to be.