Project

The class standards page is here. Note that there may be posted requirements on the class standards page that supercede the requirements listed below. Most content on the class standards page is password protected, the id and password will be shared in class.

For your semester project you will develop a standard for an application layer protocol for "local chat" whereby you can chat directly with a nearby user and implement it in a Windows, Linux, or Android application program. A chat server must not be required. Furthermore, to ensure that your messages are not wiresharked and read by someone else, you will include lightweight encryption and decryption of messages as an option in your standard.

For this document, we will refer to this new application layer protocol as LocalChat.

Definitions

• Chat session - A series of messages between a sending and receiving peer with no more than 30 seconds between any messages.
• Deliver - The condition of a sent message being received by a peer.
• Key - A secret key shared by users for symmetrical encryption and decryption of messages.
• Message - A maximum of 140 character alphanumeric (ASCII) string where all ASCII characters are displayable.
• Online - A peer that is present with the local Wifi hotspot or Ethernet domain and is running the LocalChat application program.
• Peer - A computer running the LocalChat program and associated with a given user.
• User - A human user of LocalChat associated with an IP address of a peer.
• User name - An alphanumeric (ASCII) identifier upto 32 characters for a user associated with a given peer.

Assumptions

1. Peer IP addresses are not fixed, but they will not change during a chat session.
2. All user names are unique.
3. Users that wish to send and receive encrypted message have shared a common secret key (e.g., by some offline mechanism) before chatting.

Requirements

1. A peer must be able to determine which peers by user name are online at any given time.
2. A peer must be able to determine the IP address of any given online peer by user name.
3. A peer must be able to send a message to any other peer that is online.
   1. If the receiving peer is present, the message should be delivered with high probability.
   2. A peer must be able to know if the message delivery failed.
4. A peer must be able to receive and display a properly formatted message sent by any other peer.
5. Messages can be optionally encrypted at the sending peer using the key associated with the receiving peer.
6. Messages that are encrypted must be decrypted at the receiving peer using the key associated with the sending peer.

Developing the standard

We will discuss standards creation in class. We (that is, the entire class) will also establish deadlines for the completion of the standard.

Project deliverables

1. A working and standards compliant peer application that can run on Windows and/or Linux and/or Android.
2. A report describing deficiencies found in the standard and suggestions for improvements. Two kinds of deficiencies may be noted, 1) those related to the class standard, and 2) those related to the requirements.

Project grading

1. 90 points - Meets all requirements (passes test script that is to be defined)
2. 5 points - Deficiency report
3. 5 points - Showing interoperability with at least 5 other implementations (interoperability testing to be defined)
4. 3 points extra - Presentation at "standards meeting"
5. 5 points extra - Serving as standards editor

Notes on project grading

1. You will demo your implementation to the TA at the end of the semester for a grade. The TA will have a scripted sequence of user discovery, and message send and receive (both plain text and encrypted). The TA will wireshark your messages to ensure correct (to the standard) message format. You will be allowed three attempts for your demo. A program "crash" (a situation where the program needs to be re-started) will cost 5 points off the possible maximum. Any violations of the standard will cost points off. Finally, failure to comply with class code style guidelines (see here) will cost points off.
2. A test script will be defined as the project progresses. The script will be made available for everyone to test their own implementation before a final test for a grade.
3. Early ship bonus is 110% multiplier for delivery on 11/29/10, 105% multiplier for 12/01/10, and 100% multiplier for 12/03/10 (due date). The last time of delivery on each date is 5pm. No late submissions will be accepted - the TA doing the grading will "go home" at 5pm on my instructions.
4. Extra credit is possible by designing and implementing extra functionality. This must be reviewed and approved by the instructor before the project start.

Remarks

1. If the requirements are incomplete or inconsistent, fix them. Send the fixed requirements to me and I will post them for the entire class to review.
2. This is not a user interface class, so the simplest possible command prompt interface is more than acceptable. The requirements, nor the protocol standard to be developed in class, will make any statements on the user interface.
3. You may use open source code if appropriate. Any code that is not yours must be clearly marked as such and all open source licence agreements must be followed.
4. You may choose to work in any language that you think is best suited for this project. The use of "C" or Java is, however, recommended.
5. You may work together within your team of two students. In the end submitted code will be compared for copied code.
6. If and when in doubt, ask a question.
7. Have fun! In past semesters students who have been actively involved in the full process have had a great time, and have been able to list their experience on their resumes -- leadership, team work, design, and etc. ... all "good stuff". As with all things, this project is what you make of it .