See the assignment turn-in page (last modified on 4 March 2002) for instructions on turning in your assignment.
Here is an example game between Amy and Brian (the traditional Dots and Boxes players) on a 2-by-2 board:
The lower-left dot has coordinate (0, 0); x coordinates grow moving to the right and y coordinates grow moving up.
/export/home/class/cs-537/dab.h. The structure of the rest of the message depends on the message tag.
play- The play message tag.
game- The game message tag.
Both C and R must be greater than 1.
turn- The turn message tag.
The x coordinates must be in the range 0 to C inclusive; The Y coordinates must be in the range 0 to R inclusive. Coordinates outside their respective ranges are invalid.
move- The move message tag.
win- The win message tag.
The sum A + B must be equal to the product R*C; A and B are invalid if they don't sum to R*C. In case of a tie, A and B will be equal.
lose- The lose message tag.
The sum A + B must be equal to the product R*C, and A must not equal B; A and B are invalid if they don't sum to R*C or if they are equal.
exit- The exit message tag.
'' ''(ASCII value 32 decimal) to
'~'value 126 decimal) inclusive. Characters outside this range are invalid.
gives a general idea of the way in which clients and servers interact. More specifically, the interaction between client and server can be broken up into three phases: set-up, play, and shut-down.
Upon receiving a play message from the connecting client, the server pairs the playing client with a waiting client and starts a game of Dots and Boxes between the two clients. If there is no waiting client, the playing client becomes the waiting client. A waiting client may wait an arbitrarily long time.
Note that the server can have at most one waiting client, but can have an arbitrary number of clients that are connected but are still missing their play messages.
The playing client receiving a turn message from the server has somewhere around 30 seconds to respond with a move message. The playing client can reset the 30 second clock by sending a move message with n equal to zero back to the server; the client then has another 30 seconds or so to send another move message.
When the server receives a non-empty move message from the client, it adjusts the board according to the moves given in the move message. If the game is over, the server shuts the game down; otherwise, it sends a turn message to the other client in the game.
When the server receives an empty move message, it resets its move-response time-out clock for that game. A client can send at most 10 consecutive empty move messages during its turn. If the client fails to send any moves after 10 consecutive empty move messages, the server should disconnect the client and declare the other playing client the winner.
If a game ends in a tie, both clients receive a win message and both remain connected to the server; whether they play each other again depends on the server and whether or not there's a client waiting to play. If there is, then the server may pick one of the winners to play the waiter, while the other winner becomes the new waiter. If there's no waiting client, then the two winners must play each other again.
A client may withdraw from the server at any time by sending an exit message, possibly with an explanatory message. If a game is in progress, the server declares the other client the winner, sending it a win message (this means a client may receive a win message before the game is over). If a client disconnects from the server without sending an exit message, the servers should behave as if it had sent an exit message with no error message.
The receiver of an exit message should assume the connection over which the message arrived has been closed (this means the receiver should not try to send an exit message back when it receives a faulty exit message). The receiver should print the error message (if any) to std-err and close the connection. What happens next depends on the receiver; a client should probably halt, a server should clean-up the connection and continue.
Exit messages can be sent at any time, even at times when no error has been detected by the sender. The receiver's response to an exit message, however, should always be as described in the previous paragraph.
Erroneous behavior includes receiving undefined messages, receiving incorrectly formatted messages, receiving messages with bad values, receiving messages out of expected order, failure to interact within a reasonable amount of time, and unexpected connection terminations.
-pcommand-line options to specify the server's host IP address and listening-port number, respectively. The server should support the
-pcommand-line option to pick specific listening-port number.
Your client should play the game itself; it should not prompt the user for moves. And remember, you're supposed to be learning about clients and servers, not about Dots and Boxes; just have the client generate random moves. After you get everything working, you can go back and soup up your game-playing algorithm.
This page last modified on 2 March 2002.