Bug in xboard's protover 2 SAN output

[hgm]

I know too little about socket to make a meaningful comment on that. But I would say that f there is anything the World can do without, it is a new GUI-engine communication protocol.

[bob]

I'm starting to think that we need something new here instead of using pipes for communication. There are too many issues of timing and process control that aren't handled well with simple piping, likely because they can't be handled well with simple piping.

How about having a chess program implemented as a typical service daemon and using the typical socket based listen/accept/connect handshake and data transfer protocol? This model works so very well in many contexts and I think it would do fine for chess programs also.

What kind of problems are you having? I've been using pipes forever now. Not much difference in how pipes and sockets work. Sockets introduce a whole new layer of issues, as normal input/output to stdin/stdout doesn't work. Sockets have the identical buffering issues, checking for input issues, etc...

[sje]

What I'm suggesting is consideration of the traditional client/server or peer/peer IP model for socket based communication and control.

A chess program could be configured as a service/daemon and given its own port number. Other programs could connect and play without need of a central server, and the program itself could seek out and challenge similarly configured opponents.

[MattieShoes]

Or you could add a central server, that accepts connections on port 5000, and the server would allow you to see who is available for matches, could keep clocks synched, handle challenges, allow one to look for a specific time control game, and even run tourneys...

[sje]

One of the advantages of taking a new approach is to remove the kruft that's accumulated over the years due to requiring a central server with an interface designed for human play.

We are still too far away from having the capability of running fully automated distributed events. Having a central tournament director, possibly automated, is fine. But having an absolute need for a central server, over which the author community has no control, is not so good.

[hgm]

Well, so why not use my server, over which the author community does have control? (I am an author, and if that is not sufficient, the software is open source and every other author could boot it up just as easily on his own machine if they are ot happy with me...)

[sje]

Chess hobos/hustlers are a common sight in public areas like Cambridge, Massachusetts or Central Park, New York. How about operating a chess program in hobo mode without the need for a central server? Just have the program operate as a service with the usual IP/port model and have other players including other hobo programs connect at will.

Hobo mode would also be useful for authors testing new code and who don't want the test games to be viewed by the public at large or by the server scraper robots. And it would be free with no subscription charges.

I'd like to see something like this for slow time control events that aren't suitable for ICC or a FICS. I don't think anyone has done a CC event with a time control of, say, one game/one week; some really strong chess could result.

[hgm]

It seems to me that you want to incorporate a general interface functionality into the engine, so that every engine would have to contain it, in stead of being able to use a specialized external agent that does it for them, and could be used by all. This seems an ineficient way to organize things.

If you want your engine to be open for outside challenges, just run a daemon that accepts such challenges from over the internet, and let your engine connect to it as well (possibly through a GUI, so that you could watch what it is doing). Such a deamon is called an ICS...

If you dont wantother to be able to see the games, play them as private games.