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

[bob]

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.

I don't see the reason for this. This is engine specific, and has absolutely nothing to do with how the "player" plays chess by using the serever. We simply need the simplest protocol possible to set up positions either by FEN or by stuffing moves (currently ICC can do either), send moves back and forth, and the biggie is to send offers/claims back and forth which comply with FIDE rules in a clearly defined way.

4. Retains all the capabilities of current servers like FICS

[ilari]

I strongly support any community effort to design a sane protocol for networked chess.

Maybe I'm not even on topic with this, but what I would like is a chess protocol like Xboard or UCI that would be used for communication between the chess server and the client, something better and more thoroughly documented than ICS. The server side would be simple, and it would only use that one communication protocol. It would be up to the developers of the client software to decide what types of players (eg. Human player, XBoard engine, UCI engine) the client supports. That way a lot of the implementation details and features of the clients could be kept out of the protocol specification.

If I recall correctly Tord Romstadt expressed similar thoughts here before. I'd be very interested in designing something like this.

[kranium]

BTW I don't know what I was thinking about, but ports 20/21 are ftp ports, _not_ telnet. Telnet uses port 23 only.

yes you're absolutely right...my bad.

[sje]

I'm seeing some very good comments here, so keep posting.

Some thoughts:

1) All the low level stuff will be hidden behind an appropriate abstraction layer; there's no need to worry about writing an XML generator or parser. Well, you could if you really wanted to, but even then there are public source XML utility routines available.

2) Back about ten years ago, Apple came out with its Mac OS/X based on OpenBSD, At the same time did away with some eight hundred and forty-seven different configuration file formats by adopting XML as the lingua franca for this and other uses. It works, and it works invisibly to all users and most developers.

3) The server will use the traditional server/client TCP/IP socket/listen/connect paradigm. The only real difference will be the use of the more modern pthread_create() instead of the older fork(). Obviously, the maximum thread limit on a host must be sufficiently large to handle the expected client count.

4) The server will run on Posix platforms (Linux, FreeBSD, OpenBSD, etc). It might run under Cygwin, too. But Windows hosting is probably too much to expect; the extra effort needed would be better applied to more and better features.

5) Clients can be written for any platform that supports TCP/IP sockets.

6) The server can fully automate tournaments including pairing and matching with ZERO human involvement. Specifically, an engine operator need not be preset to do a manual "match". This will help with global events were for some rounds and some operators can snooze instead of overdosing on caffeine.

7) Timestamp/timeseal functionality will be present and hopefully more secure than current implementations.

[sje]

While not a part of the design, operational policy issues are also important. My proposal for a new server protocol and design is to put first and foremost the interests of chess program authors -- something not seen at ICC or the various FICS sites.

I would consider implementing a data pipe in the server so that other, different server implementations could observe games. But commercial servers would have to pay for this.

[Dann Corbit]

I'm seeing some very good comments here, so keep posting.

Some thoughts:

1) All the low level stuff will be hidden behind an appropriate abstraction layer; there's no need to worry about writing an XML generator or parser. Well, you could if you really wanted to, but even then there are public source XML utility routines available.

2) Back about ten years ago, Apple came out with its Mac OS/X based on OpenBSD, At the same time did away with some eight hundred and forty-seven different configuration file formats by adopting XML as the lingua franca for this and other uses. It works, and it works invisibly to all users and most developers.

3) The server will use the traditional server/client TCP/IP socket/listen/connect paradigm. The only real difference will be the use of the more modern pthread_create() instead of the older fork(). Obviously, the maximum thread limit on a host must be sufficiently large to handle the expected client count.

Consider ACE, which has lots of threading models (thread pool, one client per thread, etc) and for which the server and client parts are practically written for you:
http://www.cs.wustl.edu/~schmidt/ACE.html
We use it at CONNX and we like it.

4) The server will run on Posix platforms (Linux, FreeBSD, OpenBSD, etc). It might run under Cygwin, too. But Windows hosting is probably too much to expect; the extra effort needed would be better applied to more and better features.

5) Clients can be written for any platform that supports TCP/IP sockets.

6) The server can fully automate tournaments including pairing and matching with ZERO human involvement. Specifically, an engine operator need not be preset to do a manual "match". This will help with global events were for some rounds and some operators can snooze instead of overdosing on caffeine.

7) Timestamp/timeseal functionality will be present and hopefully more secure than current implementations.

[Dann Corbit]

While not a part of the design, operational policy issues are also important. My proposal for a new server protocol and design is to put first and foremost the interests of chess program authors -- something not seen at ICC or the various FICS sites.

I would consider implementing a data pipe in the server so that other, different server implementations could observe games. But commercial servers would have to pay for this.

They will just spoof it then, if they want to. For instance, anyone can get an AOL account that will not appear to be a commercial account. Now what?
I don't see a reason to make them pay anyway.
Are we punishing them for being commercial sites?

[sje]

While not a part of the design, operational policy issues are also important. My proposal for a new server protocol and design is to put first and foremost the interests of chess program authors -- something not seen at ICC or the various FICS sites.

I would consider implementing a data pipe in the server so that other, different server implementations could observe games. But commercial servers would have to pay for this.

They will just spoof it then, if they want to. For instance, anyone can get an AOL account that will not appear to be a commercial account. Now what?
I don't see a reason to make them pay anyway.
Are we punishing them for being commercial sites?

The data pipe will not be available to individual accounts. It will only be available to registered sites.

Costs require payments. If a commercial site collects money from its subscribers, then it is only fair that some of these funds be sent to data providers to cover expenses for value added material.

[sje]

Having a remote start capability enables the server to allow a relaying of a match request to an offline engine. It also could be useful for restarting a hung engine in an automated event. And there's nothing that requires a client interface to support a remotely directed restart; the mechanism can be much simpler.

1) Use a micro-server on the engine host with, say, dynamic DNS and a registered port number of its choice. The micro server has only one task: when it sees an incoming start request, the micro-server authenticates the request and then starts the real client/engine process.

2) If an incoming TCP/IP request is too much to handle, then a different technique like instance messaging or even e-mail would work.

3) There are probably Windows specific ways of handling this that are unknown to me.

[diep]

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.

hi,

Bob is right. You've got 2 manners of connecting over the internet:

a) tcp
b) raw (udp)

For my chess server which was supposed to be free chess server and a lot of code has been written for it, especially around start of 21th century, i used therefore tcp/ip. In those years biggest problem was having infrastructure to host so many connections. It's not like this website which needs relative low volume traffic. A server has a nonstop load, free servers that are popular have really lots of users. No don't start me on FICS, first of all that's not a fully free server, most popular email adresses get blocked and as usual you're always depending upon some total nudnik as an admin, who depending upon whom he likes or doesn't like, kicks out people. Note i never had problems there. Yet they did sell and license their server to USCF, another server which just had commercial intentions. Nothing wrong with commercial intentions of course, yet it has added up in the diaspora bigtime.

For the computerchess community such a split has turned out to be very bad. Some years ago i had really good discussions at ICC with other computerchess authors about algorithms. That all has gone with that diaspora of servers. Half the authors now sit at chessbase to given an example. I don't even have a windows machine on the internet, so no means of logging in there.

TCP/IP is one of the few protocols on this planet very well debugged. Connecting in a raw manner is way more buggy.

Note there do exist projects that try to provide an alternative to TCP.

SSH and telnet are all a form of TCP. SSH is nothing but a tcp connection where you encrypt in a specific manner the information.

At protocol level it's simply TCP.

There is no protocol layer called 'telnet'.

Either something is UDP or it is TCP over the internet and nothing else.

Beginners and hackers use UDP. Unreliable, dirty, fast, and bad debugged. Especially very unpredictable.

So to measure bandwidth of network connections, i wrote a program using UDP of course (yeah bad huh, that everyone tries to roll his own code everywhere instead of use what's known).

At HPC you also have other protocols that get used. Popular nowadays is MPI, which is there in a zillion different incarnations; every manufacturer has a different, yet very similar, MPI protocol. Quadrics also has for example shmem which is more a kind of shared memory model. Within those network cards there is of course a low level manner of programming things, yet for the receiving applications the difference between both protocols is huge.