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

[diep]

Steve i understand your good intentions, yet you forgot the most important thing of a server: it has to be free.

There is already enough good well developed PAID servers.

ICC and chessbase are popular there now.
There is a range more paid servers, i didn't keep up with all of them.

FICS once used to be a free server. Yet it is like all projects, those 'free projects' get hijacked. the timeseal from fics is for example not open source but copyrighted. The latest code of fics, forget about finding it online.

It is not there. they formed years ago a company. i don't know how and what but i was told it's about 7 persons big company. they licensed for money server to uscl, which is a bunch of investors who found some dudes who would be the last i would want to setup a chess server, to be honest.

I claim that projects that can potentially make money, that making open source code for it, is garantueed disaster.

Always greedy people will get into the project, people who are no good for nothing. Note i do not claim those are in any of the above projects.

For a sport like chess, which in some nations is in decline, i claim the decline is because there is no free chess server that is any good.

All servers, even the commercial ones, i have not much complaints myself, but i can give you lists of names of people who are good people, who had a fight with admin X or admin Y. always the same social problems on those servers. Yes even at paid ones.

You must realize yourself which people like to be admin. that's not exactly the ones you preferably have as an admin, the good ones excepted there.

The problem of a server is far more complex than most guess. Most servers get setup with some big bucket of money. Wasn't chess.net setup with half a million or so. wasn't kasparov chess setup with many millions, i even heard amounts of up to 10 million. I mean if just 1 bank wants to claim back a million or 2. I don't know, but everywhere you hear the word 'big money' circulate.

I'm not in it for big money. The code i wrote for a chess server was not intended to make big money at all.

That said, i never judge commercial servers. Setting up a server with commercial intentions is always a good plan of course, a valid one.

Yet if you ask what is really not there, i'd say: there is no good free server there that everyone can use for free. It's something you overlooked.

With a free server i would not only want to let engine play engines, most important is to grab players who hardly can play chess and hardly would play chess. It is this category that is simply at zero servers right now, or the hurdle is too big to get at such a server.

As someone who is in the board of a chessclub for a year or 10 now and who taught chess to several children, of different ages, i do realize that a very big hurdle for those who might get interested in chess, is to learn the game. If you don't learn that game when you're young, the step to learn how to play chess and enjoy it, it is really big.

There is no money to make with such a thing. It just costs money.

"pay 25 dollar". No one is doing that BEFORE he's a total chess addict.

That's why all these servers just target existing chessplayers or some freaks who play weird variations.

Vincent

[sje]

My goal is to have a server, designed with chess program authors' priorities foremost, to be operated free for my fellow authors. I believe that my residential Internet tap along with a well-equipped Core 2 Duo box is vigorous enough to handle the load. Of course, it may be necessary to host the server at a commercial site, but these don't cost too much.

Serious clone operators can help with expenses. Regular, non-author humans can help even more.

I'm not interested in replacing ICC or any FICS site used by the general public. But I wold like to replace these for a playing field for serious chess program authors.

[diep]

My goal is to have a server, designed with chess program authors' priorities foremost, to be operated free for my fellow authors. I believe that my residential Internet tap along with a well-equipped Core 2 Duo box is vigorous enough to handle the load. Of course, it may be necessary to host the server at a commercial site, but these don't cost too much.

Serious clone operators can help with expenses. Regular, non-author humans can help even more.

I'm not interested in replacing ICC or any FICS site used by the general public. But I wold like to replace these for a playing field for serious chess program authors.

Are you going to raise a fee or something
and would the source code of it be open source?

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

I'm not sure what you mean by "raw". TCP/IP is stream-oriented with a connection that is point-to-point. UDP is a packet (actually datagram) oriented protocol with no connection. You can use a single socket to talk to thousands of clients. But provide similar capabilities from my perspective, yet both are different (tcp/ip is reliable, udp requires user-level dropped packet detection as one example).

There is also a newer SCTP protocol that actually merges the two together, so that with SCTP you can do a broadcast (which you can not do in TCP/IP) and then use it as a connectionless (datagram) or connection-based (stream) protocol as you choose. And you can change your mind, and, for example, take a datagram-based communication between a client and server and turn it into a connection-based connection if you choose.

[sje]

My goal is to have a server, designed with chess program authors' priorities foremost, to be operated free for my fellow authors. I believe that my residential Internet tap along with a well-equipped Core 2 Duo box is vigorous enough to handle the load. Of course, it may be necessary to host the server at a commercial site, but these don't cost too much.

Serious clone operators can help with expenses. Regular, non-author humans can help even more.

I'm not interested in replacing ICC or any FICS site used by the general public. But I wold like to replace these for a playing field for serious chess program authors.

Are you going to raise a fee or something
and would the source code of it be open source?

At this very early point in time, I'm only concerned with forming a functional specification that meets the needs of authors far better than existing server implementations.

Much of the rest is undetermined except for the policy of putting authors' interests first.

[diep]

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.

Point 10 is really important.

I really like to see the score of the other engine also. That's one of the reasons to not operate a chess engine myself online. Nearly no one kibitzes. Bob is one of the few still doing that. It really sucks so few kibitz.

Yet is also has a bandwidth implication.

Normal users you hardly feel bandwidth wise. They do very little.
Play few games.

Engines play nonstop and produce loads of text. Most operators just kick on bullet or blitz. Now i don't know what all you want to save, but that's a lot of bandwidth. You can expect 1 0 and 3 0 to be most popular time controls of operators. If i look to diep how big a run is of a few games.

Here is a tiny run against crafty which i stopped after 785 games. It is 350 megabytes.

If you realize each game was 10 seconds a program a game, you'll soon figure out that, even if you take 30 seconds a game (delay added),
this is representing 6 hours of gameplay.

In reality this would be 3 times the bandwidth though, so 1 gigabyte.

That's just a debug run of diep. If we just look to mainlines shipped to and from winboard, the winboard.debug file is 89 MB.

So in a compact form, this generates 200MB of bandwidth.
Just its mainlines. All the other stuff is tiny in comparision.

again it is just 10 second outputs. both crafty and diep reached shallow depths. In 3 0 games of course you generate less games so less outputs in the same timespan, but each move you have 50% the output.

Let's use very rough estimate of 250KB bandwidth a game.

How many games do you want to play, assuming some succes?

Even medium succes servers have a load of 500 users. How many would join playing a server like this 24/24 ?

I don't know. 10? 100? 500?

You tell me.

To me it would be interesting to join.
Probably another 20 people will soon guess the same about diep, say in some months from now.

Let's assume succes.

Diep's getting stronger.
So you'll get 20 diep's online.

When it plays bad just 1, from me.

Add 40 fritz entries, 4 crafties, 30 deepsjengs,
40 times hiarcs, 50 rybka's, 60 shredder's, 10 chessmasters.

The potential is there for 100+ nonstop up to 500.
Especially if you have a hard formulation that it is a free server and that other servers are allowed to follow games freely, this might be the case.

If it would be a succes. A protocol you don't design for 'startup',
but for succes.

Most will just go 1 0 , 3 0 and such. In short that generates a lot of games.

That is a lot of bandwidth. About a terabyte or 4 a month not long after you started.

How do you handle that?

Vincent

[jdart]

It sounds like you are implementing a protocol for communcation, not UCI or xboard? If so, that's not a good idea IMO. Both of the existing ones have flaws (lots in fact) but they are very widely implemented, by over a thousand distinct engines I would guess. Most of these are not going to rapidly implement something else/different and some never will.

--Jon

[Dann Corbit]

It sounds like you are implementing a protocol for communcation, not UCI or xboard? If so, that's not a good idea IMO. Both of the existing ones have flaws (lots in fact) but they are very widely implemented, by over a thousand distinct engines I would guess. Most of these are not going to rapidly implement something else/different and some never will.

--Jon

I think that he is contemplating a replacement for FICS.

[hgm]

I think that he is contemplating a replacement for FICS.

This is also a very, very bad idea.

And as far as I could see, practically without reason. 90%+ of the formulated specs is already met by the Chessd server.

Complaining about the protocol being illogical or non-FIDE compliant, and proposing to replace it by an XML protocol which would be totally unreadable makes no sense at all. If it is non-readable, it will certainly not be perceived as logical or be FIDE compliant. It will only be usable with the aid of a client, which would have to give it those properties in translation. This can just as easily be done with the existing ICS protocol.

Developing an ICS plus required client software will be a huge project, about 20 times as complicated as building a Chess engine. Even maintaining an existing GUI like WinBoard has taken me about 5 times as much effort as building my Xiangqi engine from scratch.

Better use what already exists, and adapt it to iron out the small imperfections. Preferably in such a way that you remain compatible with what already exists, so people could continue to use their favorite clients to connect.

[sje]

A capability that is totally missing from current implementations is the ability to automatically seek out and do battle with suitable opponents. Indeed, some of the data needed to support this is even available at ICC or the various FICS sites.

But a new server and protocol can support a comprehensive player database and automated access. The idea is that a client can specify what kind of opponents it wants to play and have the server perform as a matchmaker. An engine operator could select desired opponent characteristics and game parameters, send these to the server, and then just sit back and watch.