CECP ('WB protocol') specs

[hgm]

I made a draft for a new specification document of CECP, attempting to get rid of anything that is general programming advice on how to implement pipe I/O, and stuff that only describes XBoard peculiarities. I do not consider it 100% finished, but except for very rare or never-implemented stuff, most should be there now.

I would like to have some feedback on whether this is indeed a step in the right direction, or what else could be done to improve the presentation.

[mar]

I quickly went throught the specs and so far I have to say it seems much more compact than the original specs, I will go through it once more in detail.

I have one question about ping.
Currently I report feature ping=0, according to comments in my code, ping caused connection stalls with cutechess
(this is some ancient comment though so it's well possible that it was due to some engine bug).
I used to handle ping by responding immediately (I thought ping is used as both keepalive and to tell the GUI the engine is ready to receive commands, i.e. something similar to UCI isready).
I wonder what's the point in delaying pong reply until search is complete? This requires to buffer ping(s) - what happens if I get 10 pings during search, should I then pong all of them or just the most recent one?
Also, since the engine always replies with a move when search is done, I wonder why it's necessary to delay ping reply at all. What am I missing?

[F. Bluemers]

DEPTH SCORE TIME NODES PV
DEPTH SCORE TIME NODES SELECTIVEDEPTH SPEED TABLEBASEHITS<Tab>PV
-----snipped------

GUIs that are not aware of this protocol extension will consider these extra parameters the initial part of the PV, an print them in the PV field, so be sure to use spaces and tabs to format them nicely.

Why is the extra info format not turned into "feature",seems to me feature is just the right thing for this?
Best
Fonzy

[hgm]

XBoard uses ping only rarely, but the most important usage is for determining at the start of a new game in a match whether an incoming move belongs to the new game, or is a left-over from the previous game. (When an opponent moved just before resigning the move get transferred and set it engine thinking, and immediately after that the game ends because of the resign, but the engine might not be sensitive to the 'result' command telling him that before it finished thinking and moved. At which time the GUI already started the next game, sending 'new' and 'go' commands that all queue up behind 'result' in the pipe.) So after 'result' XBoard sends a 'ping', and any move that comes in before the corresponding 'pong' is then taken to be a result of the previous search that the 'result' (or accompanying 'force') intended to abort, while moves that come after that 'pong' must be responses to the 'new' and 'go' sent after the 'ping'. This would be totally broken if you allow the 'pong' to overtake the move.

So 'thinking' (as opposed to pondering or analyzing) should be considered as an integral part of processing the command that triggered the thinking (a 'go' or 'usermove'), and that processing only finishes with the printing of the 'move' command that reported the result of the 'think', or the decision to abort the search without printing a move (which could happen after receiving a 'force' while thinking).

If you receive 10 pings while thinking, you should print the corresponding pongs only after you moved. No know GUI would do this, however; 'ping' is not suitable as a method to probe if an engine is still responsive or has crashed. In the example protocol driver of appendix C I used the method of examining only a single incoming command during thinking, and then either backlogging it, and not examining any more commands before the thinking terminates for timing reasons, or process that command during search, and remain receptive to new ones without backlogging anything. This should be good enough, as a GUI has no business sending commands to a thinking engine that cannot be processed immediately. It should only send commands that can be processed without disturbing the search (like turning thinking output on or off), or commands that would abort the search. Other commands it could postpone itself.

[hgm]

Why is the extra info format not turned into "feature",seems to me feature is just the right thing for this?

I did not see the benefit of a feature here. Features are useful to have the GUI refrain from sending commands to an engine that doesn't know them, and thus might choke on them. But that doesn't apply to engine->GUI traffic. Features can also be used to probe if a GUI supports something, by paying attention to the accepted/rejected reply, and refrain from sending stuff to the GUI it might choke on. But in this case engines are supposed to use this output even to GUIs that do not support it, as the format itself is backward compatible with the old format, where the extra info would be considered part of the PV (which is defined as free-format text), and printed by such a GUI in the PV field.

The only difference I see a feature could make is to tell the GUI there is no extra info, and yet start the PV with 3 numbers and a Tab, so that these numbers and tab will be printed in the PV field even in GUIs that support the new format. This does not seem useful.

[Evert]

I wonder what's the point in delaying pong reply until search is complete? This requires to buffer ping(s) - what happens if I get 10 pings during search, should I then pong all of them or just the most recent one?
Also, since the engine always replies with a move when search is done, I wonder why it's necessary to delay ping reply at all. What am I missing?

I think the point is that "pong x" implies that all commands prior to "ping x" have been processed and completed. This includes (implicit) commands to search.

[mar]

I see, in my case, I always abort search when receiving force/new/result without printing the move. I guess this is fine and rules out potential problems.
However it aborts any search; no matter if thinking/pondering/analyzing.
I guess this isn't a real problem either as I assume the GUI won't send new while analyzing (not before exit).

So I will either put ping back on and buffer the requests or leave it as is ( if the GUI won't break on "ping=0" and if the engine reacts to result/new/force by aborting search, it might actually work well)
Hmm, technically speaking, since I abort where appropriate replying to ping immediately should be theoretically fine (since I run search in separate thread I can process commands anytime)

I'd like to support include/exclude moves as well (since I already support UCI searchmoves it shouldn't be a big deal) and I should probably also support the dot command in analyze mode
(or just ignore it; at the moment I report "Error (unknown command): .", which is probably not ideal)

[Evert]

DEPTH SCORE TIME NODES PV
DEPTH SCORE TIME NODES SELECTIVEDEPTH SPEED TABLEBASEHITS<Tab>PV
-----snipped------

GUIs that are not aware of this protocol extension will consider these extra parameters the initial part of the PV, an print them in the PV field, so be sure to use spaces and tabs to format them nicely.

Why is the extra info format not turned into "feature",seems to me feature is just the right thing for this?

I agree that this is cleaner, even if it is arguably a different use of the feature command than the old format. I think adding magical markers (in this case tab) to the output to denote a special format isn't particularly "clean".

[Evert]

I think what would help the document is an example session that shows typical engine GUI communication, a bit similar to what the UCI document has. This helped me get an impression for what to expect when getting started.

[hgm]

Off-topic @Evert: did you see the PM I sent you?