Author: Steven Edwards
Date: 19:14:04 09/09/03
Go up one level in this thread
On September 09, 2003 at 18:52:39, Russell Reagan wrote: >On September 09, 2003 at 18:33:22, Steven Edwards wrote: >>EPD: There are several items of concern: >>... >>10. Inclusion of progam-to-program comand protocol opcodes. >Could you explain this a little further? I get the impression that this could >somehow be used with (or instead of) protocols like Winboard and UCI to >communicate between two programs. Engine-to-engine communication protocols are >certainly an area that could use some updated and improved standardization. Program to program communication was one of the motivations for EPD, and EPD was used for that purpose from the very beginning, at least in a simple way: test suite performance measurement. A program would be tested againt some EPD suite with the program's EPD output being a copy of the input with each record having seach result data added. Later, a second program would read the output of the first and produce a performance report. That's why EPD has the "acd", "acn", and "acs" opcodes. (This is also a motivation for the "pm" and "pv" opcodes.) Of course, EPD can also be used for connecting two concurrently running chessplaying programs. I did this myself many years ago in an early version of Crafty and a late version of my old program Spector. (Spector lost the 100 game match by a 2 to 1 margin.) This was long before any other protocol existed. A further extension supports connecting a big bunch of programs to a server or referee program. A sort of electronic tournament director, if you will. That can be useful for connecting to a chess server on the net. And naturally, EPD can be the interconnection data layer between a playing program and a graphical user interface. Can EPD do a better job than Winboard / xboard / UCI / auto232 /etc.? Yes, if the additionally needed EPD opcodes are chosen correctly and properly defined. EPD has the advantage of being able to query / report / confirm the entire state of a program in a single atomic operation. This removes the need for dealing with tricky data synchronization issues that might otherwise occur with multiple commands and status data passed between programs. The phrase "stateless" is appropriate here and it's generally a better programming model than having to use a multple message handshake to transfer data. Of course, the applicability of EPD to the interprogram communication task should in no way detract from the contributions made by Winboard / xboard / UCI / auto232. Indeed, it would be a compliment to the other protocols for EPD to utilize the others' best features while eliminating any cruftiness that may have accumulated.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.