Communication between Client and Server

The communication between a participant's client program and our server took place in XML. We made this decision for two reasons: The first is that parsing the messages into an easily managed format was trivial for all parties involved—many solid XML parsers exist in the public domain. The second is that bandwidth was not a great concern—as mentioned in the previous section, most participants ran their clients on the machine that hosted the server. While it is true that excessively large messages can take up valuable processing time, in our specific case those large messages corresponded to large state spaces, which took somewhat longer to process altogether, and the XML parsing was not the limiting factor.

When a client connected to a server, it would request a certain problem to run. The server would then lead the client through running that problem 30 times, sending the state of the problem, receiving the client's action, and then creating a new state from the old state and the action, and sending it back again. Figure 4 gives a schematic illustration of the conversation between the client and server. The specific format of each XML element is described in Appendix B.

Figure 4: The interaction between client (planners) and server (environment) in our evaluation system.
\begin{figure}\begin{tabbing} xxx \= xxx \= xxx \= xxx \kill \\ {\bf client}: $... ... {\bf server}: $\langle$\textit{end-session}$\rangle$ \end{tabbing} \end{figure}

Prior to the competition, an example client was written in C++ and distributed to the participants to minimize difficulties in dealing with the nuts and bolts of the protocol, allowing them to instead focus on the design of their algorithms.

Håkan L. S. Younes
2005-12-06