Banjo and the GUI

[sje]

Banjo and the GUI

There are a number of operation modes for a combination of the Banjo chess server, a chess engine, and a GUI.


Mode one: Headless operation (no GUI)

A chess engine, using the Banjo client library or its equivalent, can connect directly to a Banjo server. This is the operation mode with the least overhead and is also the simplest. The main drawback is that there is no graphical display unless the engine provides such.


Mode two: Auxiliary GUI

In the auxiliary mode, the GUI is attached only to the engine and does not process Banjo events. The engine is wholly responsible for communicating with the GUI and the Banjo client library and the Banjo server are not involved with any GUI functions. From the viewpoint of the Banjo server and the Banjo event stream, this mode is the same as the headless operation mode.


Mode three: Instream native GUI

With the instream native mode, the GUI is positioned between the engine and the Banjo server. The GUI sends and receives Banjo events both with the Banjo server and the engine. The event stream may be modified by the GUI to allow user I/O data to also be communicated.


Mode four: Instream translating GUI

The instream translating mode places the GUI between the Banjo server and the engine as with the instream native mode. While communicating with the server using Banjo events, the GUI in this case translates Banjo events to and from whatever event set is used by the engine. This mode is used to allow legacy engines to connect to a Banjo server although not all Banjo functionality may be present.


Mode five: Instream reverse translating GUI

The instream reverse translating mode places the GUI between a non-Banjo server and Banjo event engine. The GUI maps events accordingly to support a new style engine with a legacy server.

[sje]

"Bar Room Blitz" is the name of a song by the 1980s metal band Krokus and is an inspiration for a possible chess server tournament mode.

In Bar Room Blitz:

1) Blitz time control.

2) No rounds; instead near continuous play.

3) Identities (names, ratings, etc.) of players in a game are masked from each other until the end of the game or the end of the event. One result is that there's a lessened benefit from opponent specific opening preparation and contempt factors.

4) Pairing is done somewhat randomly except for a slight bias against pairing two players who have just concluded a game against each other.

5) Players that get knocked down too frequently (scoring one point or less in four consecutive games) are ejected from the event.

6) Disconnection results in an immediate ejection.

[Aleks Peshkov]

http://en.wikipedia.org/wiki/Vaporware

[sje]

Здравствуйте камрад Алекс! Где я определил дату поставки? Я идеи так, что другие будут мочь прокомментировать на проекте. Пожалуйста, выучьте быть терпеливейш.

[Don]

Steven,

This is a partical description of my go server and I think it would work well in chess. There are some differences from your description of this mode:

1. Fast time control but not blitz.

2. No explicit rounds.

3. Identities are published by I considered not doing this.

4. Pairings are somewhat random but there is a probabilistic tendency to prefer players closer in rating. But any two players have a chance of being paired.

5. Nobody gets knocked out - the server is 24/7 and you can play all night and day.

6. You can disconnect, but this doesn't stop your clock. The game is over when you run out of time, whether you are connected or not. If you accidentally get disconnected you can reconnect and the server will catch you up with the current state of the game.

These decisions were based on a simple (unwritten) constitution:

1. A place to get evaluated in a FAIR way.
2. Players (or authors) do not decide who they will play or not play.
3. You cannot disconnect, analyse the position and then reconnect.
4. Should not be subject to too many mismatches, but you should get a lot of variety too.
5. Simply to administer - no dispute resolution - the server does it all.

"Bar Room Blitz" is the name of a song by the 1980s metal band Krokus and is an inspiration for a possible chess server tournament mode.

In Bar Room Blitz:

1) Blitz time control.

2) No rounds; instead near continuous play.

3) Identities (names, ratings, etc.) of players in a game are masked from each other until the end of the game or the end of the event. One result is that there's a lessened benefit from opponent specific opening preparation and contempt factors.

4) Pairing is done somewhat randomly except for a slight bias against pairing two players who have just concluded a game against each other.

5) Players that get knocked down too frequently (scoring one point or less in four consecutive games) are ejected from the event.

6) Disconnection results in an immediate ejection.

[sje]

6. You can disconnect, but this doesn't stop your clock. The game is over when you run out of time, whether you are connected or not. If you accidentally get disconnected you can reconnect and the server will catch you up with the current state of the game.

This sounds like a good idea. Nearly everyone has a sufficiently reliable Internet connection, although the story might have been different ten or twenty years ago.

Program crash resistance is just another aspect of playing strength. Keeping the clock running during a disconnection would encourage authors to improve engine reliability. Perhaps this should have been made a general policy long ago.