Objective:

The objectives of this assignment are:

1. To familiarize you with some of implementation techniques of communication protocols,
2. To help you understand the User Datagram Protocol (UDP),
3. To acquaint you with the unreliability issues of UDP, and
4. To introduce you to some of the simple loss recovery techniques such as timeout.

In this assignment, you will write a client and a server that communicate using a simple UDP protocol called the Simple Drawing Protocol (SDP). The Client has a GUI that is capable of drawing dots, circles, and rectangles.  The server has a set of drawing instructions that are stored in a file. Upon the client's request, the server sends the set of objects to be drawn at the client side.  The server should be multithreaded to allow many SDP clients to connect to it simultaneously. You will be give the client GUI code and the protocol description. You task consists of writing the server and client protocol code

Protocol Description:

1. <NEW> : a request message sent from the client to the server
2. <DIM x, y>: once the server receives the NEW messages, it responds with the DIM messages which sends the size of the canvas that will be used to hold the objects to be drawn.
3. <ACK x, y > : a message sent from the client to the server as an acknowledgement that the DIM message has been received. The server should not send any shape messages before receiving an ACK message.
4. The last message takes different formats depending on the type of object that need to be drawn. We have three possible messages:
   1. <POINT x, y>: to draw a point.
   2. <CIRCLE x, y, r>: draws a circle with radius r at (x, y).
   3. <RECT x, y, w, h>: draws a rectangle starting at (x, y) with width w and height h.

What happens if one of these messages gets lost?

1. If 1) or 2) are lost the client needs to send another NEW message after a timeout of 5 seconds.
2. for message 3), if the dimensions (x, y) received in the ACK message are different from the ones the server sent initially or a timeout of 5 seconds passes by, the server will send a new DIM message.
3. If any shape message (4 in the protocol) is lost, both the client and server are ignorant of the situation under this protocol.

Client GUI Code:

• PA1Canvas.jar
• PA1canvas.readme

Server Sample Drawing File:

As mentioned earlier, the server uses a drawing files where it stores all the objects that will be sent to the client. A typical drawing file will look this:

                10, 10
                POINT 1 1
                CIRCLE 3 2 7
                RECT 5 5 8 7
 

The first line gives the (x, y) dimensions of the canvas. The subsequent lines hold the actual objects with their characteristics. The End of File (EOF) maker marks the ends of the drawing commands.

 All exceptions must be properly handled.

Extensions:

Completion of one of this extensions will result in a better grade; however, groups of more than one person MUST complete this extension to receive a full grade. It should also be noted that, if you have an idea for a different extension, ask either the instructor or TAs for approval:

1. Create a trace log file that tracks the packets transmission between the clients and servers indicating if any transmission was successful or not. The file should show the source and destination IP address, the type of message sent, the number of bytes sent, and if the the transmission was successful or not.
2. Modify the SDP server to support UDP-multicasting in order to contact many SDP clients at once from the server side.
3. The current SDP protocol is faulty because it doesn't guarantee reliability. Modify the current SDP protocol to guarantee reliable drawing.
4. We want to have a " Writable Canvas" that allows the clients to connect to the server and draw different elements. The server will act in this case as a "Collaborative Whiteboard" that accepts client drawing commands. Modify the SDP protocol to support writing drawing commands to the server.
5. Enhance the Client GUI so that it is capable of drawing more interesting figures such as filled rectangles, filled ovals, filled circles, etc. Enhance the server to be a random object generator. In other word the server will not send all the time the same number and set of objects. It should be able to generate different picture sequences of different sizes.

Grading:

Grading will be split in the following way:

• 60% correctness (Does it do what it's supposed to?)
• 20% error handling (Can it easily be crashed?)
• 20% documentation (Is it easy to read and understand the code?)

Submission:

The due date for this project is September 17th, 2002, 11:55pm EST. You should use the assignments drop-off box located at the course's WebCT page. Upload a JAR file containing all the relevant documented Java files, along with a README file describing the project and its usage.

Late submissions:

• 10% penalty for a one-day late submission.
• 25% penalty for up to a three-day late submission.
• Submissions more than 3 days late will not be accepted.