Communication Protocol

We adopt an XML-like syntax for the client/server communication protocol. We use the same extended BNF notation as in Appendix A to describe the syntax of protocol messages. The $ \langle$ name$ \rangle$ and $ \langle$ number$ \rangle$ terminals are defined in exactly the same way as for PPDDL. An $ \langle$ integer$ \rangle$ is a nonempty string of numeric characters. A $ \langle$ message$ \rangle$ is an arbitrary character string, possibly empty.

Figure 13 shows the expected sequence of messages. A session starts by the client sending a $ \langle$ session-request$ \rangle$ message to the server. The server replies with a $ \langle$ session-init$ \rangle$ message, which tells the client the number of evaluation rounds that will be run. To start an evaluation round, the client sends a $ \langle$ round-request$ \rangle$ message, to which the server replies with a $ \langle$ round-init$ \rangle$ message. At this point the evaluation round starts. The server sends a $ \langle$ turn-response$ \rangle$ message to the client, which can be a $ \langle$ state$ \rangle$ message or an $ \langle$ end-round$ \rangle$ message. For every $ \langle$ state$ \rangle$ message that the client receives, it sends an $ \langle$ action spec$ \rangle$ message in return. Once the client receives an $ \langle$ end-round$ \rangle$ message, it ends the current evaluation round. The client then starts a new evaluation round with a $ \langle$ round-request$ \rangle$ message to the server, or waits for an $ \langle$ end-session$ \rangle$ message from the server in case all rounds have already been run. The server sends an $ \langle$ error$ \rangle$ message to the client if an error occurs, for example if the server receives an unexpected message from the client.

Figure 13: Successful communication session.

Håkan L. S. Younes