Project 4 - Asynchronous Distributed Messaging

Part 1 - Due - Monday, April 19, 2004

Part 2 - Due - Wednesday, April 28, 2004

Part 3 - Due - Monday, May 3, 2004

The goal of this assignment is to give you an understanding of some of the challenges of mobile computing by having you modify and extend your Project 3 program. Your Project 4 program will assume that a sending peer may not be able to reach a receiving peer. If a message is not successfully sent, the sending peer will queue the message and resend it later.

For this assignment, you should continue to work in your Project 3 group. If, for any reason, this is a problem, you need to meet with me immediately to discuss other options.

This program will differ from Project 3 in two main ways:

Sending Functionality

The Sender piece of your program will receive requests to send messages. The Sender should attempt to open a socket to a receiving peer and send a message. However, if the Sender cannot reach the receiving peer, it should queue the unsent message, and try to resend it later. You should note that a sending peer may try to send messages to many different receiving peers. If it cannot reach a particular peer, it should queue the message and try to resend it later -- only to the peer which did not receive it. In other words, you should have a separate queue for each receiving peer.

Hint 1: How do you know that the receiving peer cannot be reached? Recall that when you attempt to open a socket and when you attempt to "writeBytes" to that socket an exception may be thrown. This exception indicates that the message was not successfully sent. Your program should catch this exception. If such an exception is caught, the message should be queued and resent later.

Hint 2: How do you know when to resend the message? There are a number of ways to accomplish this. I would suggest that you use a method similar to the basic testing method described for Project 3. You can put your Sender to sleep and have it wake periodically and try to resend any unsent messages. I would recommend that you implement this functionality in your run method.

If you successfully augment your Sender to queue unsent messages and periodically try to resend, you will receive a maximum of 85%. For full credit, you must also implement a User Interface (described below).

User Interface Functionaltiy

For full credit, you must implement a graphical User Interface which consists of, at minimum, a text field, a button, a list, and a text area. The list should display all known peers. You can display the IP address, or associate an identifier with each IP address and display the identifier. The user should be able to enter a message in the text field, select a peer from the list, and press the button. When the button is pressed, the interface should retrieve the message from the text field and retrieve the receiving peer from the list. It then passes this information to the Sender which will attempt to send the message to the given peer. In the event that the receiving peer cannot be reached, the Sender should behave as described above. When a message is received from another peer, it should be displayed in the text area.

Testing

To test your program, you will need to run your program on two or more iPAQs. One simple test case would be to start the program on both iPAQs and make sure that each can send a message to the other. Now, turn off the wireless interface for one of the iPAQs. During this time, each iPAQ should be queuing any unsent messages. Now, turn the interface back on. Within a few seconds (depending on the sleep interval you used), you should see all of the queued messages appear at the receiving iPAQ.

Part 1 Turnin

For Part 1, you need to turn in:
  1. A skeleton of your revised Sender. You should include the headers for any new methods you will need to implement and algorithms (pseudocode) for new methods and any old methods you will need to revise.
  2. A written design document which describes your program and highlights any changes from your design for Project 3.
The class period on April 19 will be devoted to discussion of the Project. We will discuss any general design and implementation questions as a group for the first few minutes of class. For the remainder of the class period, I will meet with each group individually to make sure you are progressing and ensure that I provide you with any help that you need. Bring a printout of your Sender skelton and your design document.

Part 2 Turnin

For Part 2, you need to turn in:
  1. The current version of your Sender piece. At this point, your Sender should be able to determine if a message was successfully sent and, if not, queue it.
  2. If you intend to implement the User Interface piece, you must also submit a skeleton of your User Interface. The skleton must include all pieces of the UI along with all methods you intend to implement and algorithms (pseudocode) for each method.

Part 3 Turnin

For Part 3, you will demonstrate your completed program. During the class period, each group will demonstrate the workings of their program. In addition, you must submit your completed Java code and a revised, completed design document.
Sami Rollins