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

[sje]

Client side programming examples (C++):

(For sake of discussion; let's call the proposed server protocol "Banjo".)

Code: Select all

// Initialize the thread that forms the Banjo client interface.
// The parameter is the name of the local event receiving function.
// The receiver gets called with a new Banjo event whenever the interface
// has something to say.

Banjo *bptr = new Banjo(LocalBanjoEventReceiver);

// Identify self and log in to the server using pointers to the
// server identification and the client (engine) identification.

assert(bptr->PostEvent(new BanjoEvent(EkLogin, ServerID, ClientID)));

// Start a game

assert(bptr->PostEvent(new BanjoEvent(EkMatch, OpponentID, GameParameters)));

// Send a move

assert(bptr->PostEvent(new BanjoEvent(EkMove, SANMoveString)));

// Send a rep draw claim

assert(bptr->PostEvent(new BanjoEvent(EkRepDraw, SANMoveString)));

// Resign

assert(bptr->PostEvent(new BanjoEvent(EkResign)));

// Logout

assert(bptr->PostEvent(new BanjoEvent(EkLogout)));

// Conclude the Banjo interface.

delete bptr;

// Local event receiver code

void LocalBanjoEventReceiver(const BanjoEvent *beptr)
{
  switch (beptr->Ek)
  {
    case EkMatch:   HandleIncomingMatch(beptr->OpponentID); break;
    case EkMove:    HandleIncomingMove(beptr->SANMoveString); break;
    case EkRepDraw: HandleIncomingRepDraw(beptr->SANMoveString); break;
    case EkResign:  HandleIncomingResign(); break;
    ...
  };
}

[hgm]

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.

What you describe is just a special kind of tournament manager. Like mamer is for Swiss or round-robins.

People could simply express their willingness to be paired by sending a message though:

tell matchmaker 5 0 u w28

and the matchmaker would then automatically start an unrated shatranj blitz game with approximately a 5+0 TC. Or give a response to explain why it cannot be done, or how long you would likely have to wait (e.g. until other shatranj players it paired before have finished their 10+6 game).

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

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.

Well yes, this is correct of course that UDP is datagram. There is not a single reason to not use TCP/IP. For online internet server software i'd fire anyone who would use something else than TCP.

It's the only thing out there that's well debugged on the internet and safe.

With UDP you simply do not have a garantuee that the data arrives and bandwidthwise seen it's not a big deal either.

Not speaking about earlier NOVELL here of course nor special highend networks.

Note even those they push to tcp/ip nowadays with real expensive network cards.

[diep]

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.

a) factor 20 is understatement. The GUI is overwhelming important.

Note that i was about to make a new GUI, cross platform, no commercial ambitions for it at the moment. Connecting it to my oldie serverside code will be an interesting challenge.

Note it is multithreaded as opposed to ICS protocol which is a polling model and obviously has as big disadvantage that it is a total single core protocol not possible to use several NIC's to give one example. It has a limit of around 2000-3000 users. If these join all together a few kibitzes of tournaments, ICC is nearly hung. They limit kibitzing everywhere in such cases and have kicked out about most computer accounts some years ago, thereby really saving on bandwidth.

FICS and ICC have a few major disadvantages which have nothing to do with chess engines indeed other than that both will not want too many chess engines there as that would eat too much bandwidth.

ICC has a number of services real nice.

Chessbase only has their own GUI, not really a textmode protocol option to connect to it.

You can write a protocol and build a server of course, but in the end it's all about the client.

Making a good protocol is important, yet i'm not sure Steven has experience here.

KISS is most important and Steven is the opposite of KISS.
A minimal non-complicated and total trivial manner of connecting
should be possible and it should not be far away from how ICS works.

Maybe it is possible to join forces somehow.

Note without GUI's such server is total doomed and would be yet another crap server.

So far i didn't hear him about whether something would be commercial or non-commercial. Any discussion here is futile when it is a commercial project of course.

Vincent

[sje]

Ideas on open and closed source for an ICS:

1) The entire specification of the protocol has to be open, in part because of the need to encourage third party client creation and maintenance. Likewise, the data formats for HTML content of server generated reports and newsletters would be open, too.

2) The entire client side programming API and the supporting common client side source should be open as well in order to make third party client creation and maintenance as fast and easy as possible.

3) The server code does not need to be open source, but it could be deployed that way. My thought is that the source could be licensed for free to any non-commercial entity that wants to run a server.

4) The server code would not be GPL code, but any GPL database code used would of course remain open. Because any GPL code would run as a separate process and not be integrated with the server, GPL terms would not apply to the server. There would be a design firewall between the server and its database access that would allow substitution of one database manager for another.

5) Commercial entities that want to make money using the server would be expected pay for its creation and maintenance.

[diep]

Ideas on open and closed source for an ICS:

1) The entire specification of the protocol has to be open, in part because of the need to encourage third party client creation and maintenance. Likewise, the data formats for HTML content of server generated reports and newsletters would be open, too.

2) The entire client side programming API and the supporting common client side source should be open as well in order to make third party client creation and maintenance as fast and easy as possible.

3) The server code does not need to be open source, but it could be deployed that way. My thought is that the source could be licensed for free to any non-commercial entity that wants to run a server.

4) The server code would not be GPL code, but any GPL database code used would of course remain open. Because any GPL code would run as a separate process and not be integrated with the server, GPL terms would not apply to the server. There would be a design firewall between the server and its database access that would allow substitution of one database manager for another.

5) Commercial entities that want to make money using the server would be expected pay for its creation and maintenance.

Would you accept strategic concept changes proposed by others?

Vincent

[diep]

Ideas on open and closed source for an ICS:

1) The entire specification of the protocol has to be open, in part because of the need to encourage third party client creation and maintenance. Likewise, the data formats for HTML content of server generated reports and newsletters would be open, too.

2) The entire client side programming API and the supporting common client side source should be open as well in order to make third party client creation and maintenance as fast and easy as possible.

3) The server code does not need to be open source, but it could be deployed that way. My thought is that the source could be licensed for free to any non-commercial entity that wants to run a server.

4) The server code would not be GPL code, but any GPL database code used would of course remain open. Because any GPL code would run as a separate process and not be integrated with the server, GPL terms would not apply to the server. There would be a design firewall between the server and its database access that would allow substitution of one database manager for another.

5) Commercial entities that want to make money using the server would be expected pay for its creation and maintenance.

programming API open source?

Are you not living in reality and only accepting clients for linux and not windows?

Vincent

[sje]

Would you accept strategic concept changes proposed by others?

Everything useful would be considered, but not necessarily accepted.

[sje]

programming API open source?

Are you not living in reality and only accepting clients for linux and not windows?

Yeah, I'm pretty sure I'm living in reality; the sky is blue, the sun is bright, my taxes are high, and the local gravitational acceleration is 9.80 m/s.

Where did I say that the server wouldn't accept Windows clients? The last time I checked, Windows applications can be written in C++ and can use TCP/IP. I've only implied that others will have to write Windows clients; I'll help as much as I reasonably can.

[diep]

Would you accept strategic concept changes proposed by others?

Everything useful would be considered, but not necessarily accepted.

Do you think you are the best person to take decisions regarding protocol for such server?

Vincent