Project 1 - Distributed TicTacToe

Due Date

For this assignment, you will work alone (except as specifically noted below). Each individual will turn in separate work.

The short assignment is due on Monday, September 24, 2001, at 11:59pm (one minute before midnight). You will turn it in as a text email message to cs290e@csug.rochester.edu

The programming part of the assignment is due on Friday, October 5, 2001, at 11:59pm. The instructions describing what to turnin and how to use the turnin script will be posted to the ur.cs290 newsgroup.

Project Description

You will design and build a distributed two-player tic-tac-toe game where the players are located on two different hosts and use explicit message passing to communicate.

A player is uniquely identified by a host:port combination. For example, player one could be cycle1.csug.rochester.edu:1970 and player two could be cycle2.csug.rochester.edu:1980. Or, to test your application, you can put these two players on the same machine: (cycle1:1970, cycle1:1980).

The basic play of the game will be as follows: Start up two TicTacToe games. They must be running the exact same code. The only difference will be in a command line specifying the port to run on (to start player 1, the command line should be java TicTacToe 1900 and to start player 2, the command line should be java TicTacToe 1910). From one of the games, e.g., Player 1, enter the host:port of the other machine, and request that a game begin with Player 1 being either X's (or Player 1 being O's, let the player 1 make the choice). Player 2 should see the request and then Player 2 can accept or decline the game. The player playing X's will make the first move. Play will alternate until one player wins, or a tie is reached and the board is full (a tie cannot be declared until all 9 squares are filled). This decision is made independently (and automatically) by the code of the two players, and ends the game. To start over, the user should be required to clear the game, and then one of the players can start over by making a new request to start a new game.

Each player should make only one request at a time and only participate in one game at a time. If a player receives a request while it is waiting for a reply to its request, it must decline the new request. If a player receives a request while it is playing a game, it must decline. If a player receives a game move from a player it is not playing with, it should ignore this move. You should prohibit illegal moves (playing on top of another player's token, playing out of turn).

After you have this working, add another module to your project. This module will be very independent from the tic tac toe game. The goal here is to build a tool which discovers other players which are waiting to play by using multicast messages. In other words, assuming you do not know the identity of the other players, this module will give you a list of the available players. You can assume that the multicast address is well known. Be very careful when you get to this point because multicast addresses are not unique. In other words, you may choose to listen on an address which someone else is using. If this happens, choose a new address. You have two choices here: either you can use the multicast message to periodically announce that you want to play, and listen to the multicast message to find a partner to invite. Or you can use the multicast message to request who is out there, and then wait a while to receive unicast replies to this request. Either is acceptable, but in either case you must document and justify your choice. Do not start working on this part until you have a working Tic Tac Toe game. If you do not get this working, be sure to turn in the working Tic Tac Toe game, the parts of this extension which have been completed, and a description of where it fails.

Before turning your project in but after you have a working game, get together with someone else in the class, and try to connect your tic tac toe game to theirs. Did it work? If not, why not? If so, congrats. Think about what might have kept your programs from working together. Report the results in your writeup, including the name of the person(s) with whom you did this test. Let me emphasize, you do not need to make this work! You need only analyze why it did not work (or might not have worked). If you tested at a point when you had the discovery module working, were you able to discover the hosts of your classmate? Why and/or why not?

User interface: This is not a user interface class. You do not need to build a fancy graphical user interface. A text-only interface is acceptable. The only requirement is that your interface be clear. Remember, we will have to test all of your applications, and if we get confused, that may not be good for your grade.

You will be graded partially on your design, so keep it CLEAN. Make sound decisions, and be able to state what decisions you made and why you made them.

Short Assignment

What are the main differences between Socket and DatagramSocket in the java.net package?.
What is the purpose of creating a java.net.ServerSocket?
What happens if you try to create a Socket to a destination host:port which is not listening?
Which class does MulticastSocket extend and why?
What happens if you try to send a packet on a MulticastSocket and there are no hosts listening to this address?

Resources

Message classes: You must use these classes as the types of the message objects which you pass between the players. You may create new message classes if you like, but you must use these for the functionality for which they are intended. To see the intended use, read each file. Briefly, these describe the format for the request, accept, decline, make a move, and sending a note to another player.
Blocking Queue: You may find this useful in working with multiple threads. It is a simple queue. The basic operations are add() and remove(). The difference between this and a regular queue is that if a thread calls queue.remove() and there are no elements in the queue, then the thread is blocked. The thread is only unblocked when an element appears in the queue. How does this element appear? It was inserted by another thread which is not blocked. All the synchronization necessary to manage multiple simultaneous adds is handled within the queue. You are not required to use this, but you may find it useful.
MultThreading example This is an extremely simple muthreaded program. Read the inline documentation to see how it works.
Just about any good Java book will have some chapters on using unicast and multicast sockets, including the books in the labs. For online references, I encourage you to make extensive use of the Java API. (There is also a local version on the lab machines) Another good textbook resource is Bruce Eckel's Thinking In Java. I have made a pdf version available on csug.rochester.edu at /u/cs290e/resources/TIJ2.pdf. You do NOT need to copy the file into your directory in order to use it. Instead, open it with xpdf /u/cs290e/resources/TIJ2.pdf. Alternately, you can download it for your own machine.

Hints

First, do not start at the last minute. If you have never done multi-threaded programming, you will have some reading to do. If you have never done communication between two hosts, you will have some reading to do. You can handle it, but realize that it will take some learning and some thinking.
Do not start by coding madly, building a large, monolithic system. Design your project carefully, so that your development is incremental. Test as you go. As questions if you get stuck. Talk with others, but do not copy code!
If you want to discuss your design before beginning, come talk to either the TA or prof. If you get stuck, send an email.
While testing, do not overload the processors of the lab machines which have displays. You should run additional processes on the cycle servers: cycle1, cycle2, cycle3. If you do not know how to remotely log into these machines and have the display show locally, just ask.