Short presentations are to be given in class on Thursday 4/14/2005.
These presentations are to discuss any implementation and
protocol issues that you are planning on using in your
program. Every group must make a presentation. The whole
group does not have to take part in the presentation.
One member of the group can be
volunteered to give the presentatation
for the entire group.
You may work on this program in groups of upto 4 students.
For this program, you are to create a P2P (Peer-to-Peer) Chat program. When communicating with another peer, your program is to directly communicate with that other peer. Each peer is to maintain a list of other known peers. This "Last Known Location" list is to contain the peer's name, host, port and time of last known login. When trying to connect to another peer the information in its "LKL" list will be used to attempt to connect to the peer for a chat session.
There are two types of communication operations that can occur between two peers: synchronize and chat.
This communication operation will cause two peers to exchange and update information from both LKL lists. The resulting LKL lists are to be identical when this operation finishes. The updating is to occur as follows. If a name only appeared in one of the two LKL lists prior to the synchronization, that name and its host, port and time information are to be in both lists after the synchronization. If a name appears in both LKL list prior to the synchronization, the entry with the most recent times information is to be in both LKL lists after the synchronization. A synchronization operation ends as soon as the LKL lists are updated.
This communication operation will allow 1 to 1 text messaging to be sent between 2 peers. This chat must allow for incoming messages to be instaneously shown to the user. Multiple threads (one for processing the incoming messages and one for processing the outgoing messages) is strongly suggested for this. A peer may have multiple chat sessions going at once. When each chat session is started, a new GUI window should be displayed for that session. This window is to displayA chat operation will be ended when either user indicates that it wishes to end the session by clicking the end chat button.
- the information (name, host, port, and time) of the other peer,
- the incoming and outgoing messages,
- a end chat button.
When peer A attempts a chat session with peer B, information for peer B must be in peer A's LKL list. This information will be used to contact peer B. If peer B is currently running at the location in peer A's LKL list, the two peers will be connected. Once connected, a synchronize operation will occur first followed by a chat operation.
If peer B is not running at the location in peer A's LKL list, it may be running at some other host/port or it may not be currently running. To see if peer B is running at some other host/port, peer A will attempt to connect with all other peers in its LKL list and for each connection perform a synchronize operation. If these synchronization operations cause the information in peer A's LKL list to be updated for peer B, a second attempt to contact peer B is to be made. If no updates are made or the second attempt to contact peer B fails, it will be assumed that peer B is not currently running and a message stating this is to be given to the user.
The primary interface for this program is
When exiting the program, the peer's name, port and LKL list are to be stored in a file that will allow the peer to be restarted without losing its information. The filename should reflect the peer's name.
When starting the program, a file may be specified as a command line argument. This file should contain information that was saved during the exiting of the program. If a command line argument is not given, the user should be prompted to create a new peer or to select an file containing information for an existing peer. When a new peer is to be created, a name and port number is to be given by the user. It will be assumed that a unique name is given. There are no defined specifications if a unique name is not given. You program can do anything reasonable if a non-unique name is given (I don't think a core dump is reasonable, but just about anything else is).
If the port used by the peer is in use when the program starts, the user should be prompted for one of three actions:
One question that I will leave for you to answer is, "When a peer's information is manually added to the LKL list, what time value should it be given?"
Below are some idea that I had regarding the layout of GUI's for this program.
The main window:
Name: A Host: 127.0.0.1 Port: 12345 Last Known Location Information:
A chat window:
Name: Mark Host: ernie.cs.uic.edu Port: 23123 Incoming Messages:
Outgoing Messages:
Submit your program electronically using the "turnin" command from your CS account as follows:
turnin -c cs450 -p mp3 [your project directory]
where the [your project directory] is the directory name under which you have
all your files related to this programming problem. The turnin command will
automatically compress the data under your directory, so there is no need to do
the compression by yourself.
Notice you can only invoke turnin command on the Linux machines in the lab or after logging into the server machine oscar.cs.uic.edu.
If you want to verify that your project was turned in, use the verify option
-v with the turnin command.
For instance for this project, from your CS account you would type:
turnin -c cs450 -p mp3 -v
Note that you can execute turnin as many times as you would like, up until the program deadline when turnin will be disabled for this project. Each time you execute turnin for a project, you overwrite all of what you had turned in previously for that project. Turnin does not allow for incremental submission of your project.