Hi, > On 28 May 2026, at 14:11, Frank Berger <[email protected]> wrote: > > Hi, > >> I actually think we need to think this through.... I actually think we need >> two kinds of protocols. One protocol for connecting a bot to a Graphic User >> Interface and another protocol to head-to-head matching. >> >> From my experience - if the protocol is "stateless", i.e. the board state is >> passed at every new situation, a head-to-head match becomes very slow. Not >> only does the messages passed become unnecessarily long, but there is also a >> lot of waste in parsing the board position into the bot's internal >> representation and so on. This is part of what kills the performance when >> doing head-to-head matching. > > I agree that stateless makes things easier. I disagree that it make a > protocol slow. Even parsing the cli output of GnuBG was fast enough and only > in the “move-analysis” window where about 70 requests had to be sent is only > a slight pause perceivable compared to the included AI. A binary protocol > (with ASCCI mode for debugging) will be pretty fast. I tend to suggest > "protocol buffers” because it is battle proved, it supports many languages > and the serializing code is generated. But I’m open to suggestions, e.g. I > read cursory about Apache Fory yesterday which allows to use the native > objects and don’t need transfer objects and has more advantages but it is not > that widespread used as Protocol Buffers. But if anyone else says e.g.: > should be JSON or whatever, I’m not dogmatic.
In chess, you have two competing protocols, UCI and XBoard/WinBoard. Both protocols follow the telnet-style command-response approach. That is nice for humans but bad for software, because everybody has to implement the protocol or use a library. And there is no generally accepted library for this. Stateless vs. stateful: I’m not very familiar with XBoard. But UCI has both approaches. You can specify the current position with one string (FEN, Forsyth-Edwards Notation) or you can pass a starting position and then all following moves that lead to the current position. In practice, everybody uses the second approach but this is specific to chess with its three-fold repetition rule. That rule can only be honoured when the engine knows all previous positions. Separate protocol for UI connection and connection to servers and tournament managers? Why? Both chess protocol are used for both purposes. And no chess engine that I know can play directly against another engine. They all need a separate application (cutechess-cli, fastchess, BanksiaGUI, …) that connects them. For connection to a servier, there are a couple of Python programs that can run bots. I also don’t think that a stateless protocol is significantly faster. Even with pipes or unix domain sockets, the I/O will probably be more expensive than the parsing. Always passing the entire game history has the additional advantage that an engine could also give estimates for luck and skill. I think that the serialisation format doesn’t have to be part of the core protocol. It is easy to support multiple formats. Honestly, I don’t think that the mini payloads that a backgammon protocol requires, make protocol buffers the preferred choice. Regards, Guido
