There are several objectives to this assignment. The first is for you to acquire some of the skills needed to develop an application layer protocol. These skills will help you later on in the work related to your project. Second, this assignment will help you realize the real complexity involved in developing protocols. A protocol feature that sounds easy to add, turns out to be quite a challenge to implement. Finally, you will have a general skeleton or ideas that you may reuse for the project.
The goal of this assignment is to implement an application layer protocol, RTRP (Remote Text Repository Protocol), working over TCP. You can use either C or Java for this assignment. The basic idea behind this protocol is for different users to store their local data on a remote server. For simplicity, each user will have a single text file on the server on which he/she can perform different operations. The three operations are to ADD text to a file, VIEW (or download) contents of a file and DELETE the file from the server. Users will be able to create accounts (if they are new users), login (returning user), add to, view/download or delete their text file on the server. You will implement a client and server that will communicate using RTRP.
The basic features of the system are shown both in the client state diagram as well as in the protocol definition. You will then be required to implement two additional features to the protocol. The first additional feature is to be chosen from a list of possible extra protocol features (provided to you later on). The second feature is for extra credit (10 points), where you implement a header checksum for error detection and use the 16-bit field checksum header for this functionality. The way you detect and handle these errors is up to you.
NOTE: For the basic operation, the checksum field will just be set to 1's. Also, how you implement these additional features is totally up to you. However, you cannot modify the header format, and cannot exceed the size of the reserved fields to implement these functions. You can use the reserved header bits, or other new protocol types in your added features as you wish.
Important points not clear in the state diagram or protocol definition:
- The client side should have both a simple user interface through which the user performs basic operations, and an internal engine that will translate these user commands (preferably through a menu) to the proper protocol format to communicate with the server.
- It does not matter how the interface/menu is implemented, what matters are the messages that get generated on both the client and server side. These messages should carefully follow the protocol definition and format.
- The client must locally verify the password when a user tries to create a new account on the server. The client only sends the username and password for the new account AFTER it has verified the password twice from the user.
- The client locally verifies a delete request from the user before sending the delete packet to the server.
- The server is the engine which will always be up and ready to handle client requests and accounts. It will be listening to client TCP connections on port 40,000. (NOTE: when you are testing/running your servers on lab machines, use other random ports (ex: last 5 digits of your perm no.) so that you don't clash with someone else who might already be using the port.)
- The server maintains a database text file. Each line in that file contains the following:
<username><space><password><space><IP:port (of last login)><space><date and time of login (format it anyway you like)>
EX: kharras secretPass 128.111.52.110:5433 Mon 10/8/2005 19:34
- The server will maintain a list of text files each named with the username of a given user. Each user can have only ONE text file at any point in time. When a new user creates an account, this file is created and is simply empty. The server will allow the user to add text to it, delete the whole file, or download this file at any point when they are logged in. If the user requests to delete a file, ONLY the contents are deleted, but the file remains on the server.
- The server should handle simultaneous connections from multiple clients. Communication with each client should be done through a separate thread. Don't forget to synchronize access to the database file.
- The server should not allow add, view or delete operations unless the user is logged in. Remember to keep the state of each user at any point in time when they have a connection established.
NOTES: For the basic portion of this assignment, you can assume normal operation. Handling error conditions, unexpected behavior other than those explicitly listed in the basic functions are not required. Some of these are a part of the extra functions you might choose to implement. Finally, you can test your basic operation with other clients and servers implemented by others in the class to ensure interoperability. However, you may not copy or see their code under any circumstances. Additional features do not need to be compatible with others, they only need to work among your client and server since you will be graded based for your design as well.
|
Protocol name: |
RTRP. |
|
Type: |
Application layer protocol. |
|
Port: |
40,000 (TCP). |
|
00 |
01 |
02 |
03 |
04 |
05 |
06 |
07 |
08 |
09 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
|
Type |
Code |
Length |
|||||||||||||||||||||||||||||
|
Source Port |
Header Checksum |
||||||||||||||||||||||||||||||
|
Source IP |
|||||||||||||||||||||||||||||||
|
Reserved |
|||||||||||||||||||||||||||||||
|
Data ::: (Variable Length) |
|||||||||||||||||||||||||||||||
Type. 8 bits (Ascii character). RTRP packet type. Different packet types shown in the following table.
Code. 8 bits (unsigned integer). Further qualifies the RTRP packet type.
|
Code |
Description |
|
|
A |
10 |
Client requesting new user account. Data contains username and password as consecutive null terminated strings. Data Format: <username'\0'><password'\0'> |
|
|
|
|
|
B |
20 |
Client logging in, providing username. Data contains username and password as consecutive null terminated strings. Data: <username'\0'><password'\0'> |
|
|
|
|
|
C |
30 |
Client requesting to add text to server file. Data is the file size in bytes (32-bit unsigned integer) |
|
|
31 |
Client requesting to view (download) server file. Data is empty |
|
|
32 |
Client requesting to delete file at server. Data is empty |
|
|
33 |
Client sending upload data. Data contains text (or portion of text) read from client file. |
|
|
|
|
|
T |
40 |
Client will terminate connection message to server. Data is empty. |
|
|
|
|
|
X |
110 |
Server accepts NEW username, and confirms account creation. Data is empty. |
|
|
|
|
|
Y |
120 |
Server accepts username, and password. Confirms Login. Data is empty |
|
|
|
|
|
Z |
130 |
Server confirms add request. Data confirms total file size received (After whole file is received) |
|
|
131 |
Server responds to view (download) file. Data is the file size in bytes (32-bit unsigned integer) |
|
|
132 |
Server confirms deleting file. |
|
|
133 |
Server sending download data. Data contains text (or portion of text) read from server file |
|
|
|
|
|
E |
201 |
Server error: Username Taken |
|
|
202 |
Server error: Invalid Username or Password |
|
|
|
|
Length. 16 bits (unsigned integer). Contains the length of the whole packet in bytes. The minimum value for it is 16 bytes (header size with empty data)
Source Port. 16 bits (unsigned integer).
Source IP. 32 bits (4 unsigned integer).
Header Checksum. 16 bits (unsigned integer). Will be set to 1's and ignored in the basic operation. Can be used to implement header error checking for the extra 10 point credit. Hint: One complement header checksum in RFC 1071.
Reserved. 32 bits. For protocol expansion later on.
NOTE: The types mentioned in between parenthesis are only general types to show the expected format of the field. In other words, you are required to figure out how to implement it in either C or Java.
The following shows who creates the packet, along with the type:code of this packet. It is only an Example:
- Client -> A:10, new account creation with username and confirmed password
- Server-> E:201, username taken
- Client -> A:10, new account creation with new username and confirmed password (obtained from user)
- Server -> X:110, confirms account creation, adds entry to database file, and creates empty file: <username>.txt
- Client -> B:20, login with username and password
- Server -> E:202, invalid username or password
- Client -> B:20, login with username or password
- Server -> Y:120, login successful, records last login information in database file.
- Client -> C:30, request to add file of size 100KB
- Client -> C:33, first chunk of data (server automatically appends to users local file, counts data received)
- Client -> C:33, second chunk of data (server automatically appends to users local file, counts data received)
- Server -> Z:130, confirm data added of size 100KB
- Client -> C:31, file view/download request.
- Server -> Z:131, file of size 100KB will be on its way
- Server -> Z:133, first chunk of data (client automatically writes data to a local file, counts data received)
- Server -> Z:133, second chunk of data (client automatically writes data to a local file, counts data received)
- Client -> C:32, request file deletion
- Server -> Z:132, file has been deleted (only the contents, file <username>.txt still exists, but is empty)
- Client -> T:40, user wants to exit. Connection terminated, Server closes connection.
The state diagram of the Client is to help you better understand the "acceptable" flow of messages. For example, a user obviously cannot add, delete or view a file unless they are logged in.
After implementing the basic functions previously described, you are now to design and implement only ONE of the following features:
Security 1: Encryption. Currently all packets are clear text. Provide a layer of encryption and decryption (a very simple one). Will you use keys? How will you exchange them?
Security 2: Disabling simultaneous logins. There should be only one user accessing his/her account at any point in time. How do you ensure that? How do you handle these cases?
Security 3: Prevent intruders listening to the connection and injecting malicious packets. That is, how do you make sure that a delete packet you receive in the middle of a connection is really from the user who logged in? Should you keep track of the source of the packet and make sure it is consistent with the login machine (IP and port for example).
Irregular behavior handling: What happens if a connection is simply terminated in the middle of sending data? How do you handle an unexpected packet that has either a type code that does not exist? How do you handle improper sequence of packets (e.g. receiving an add request before a proper login!). Server restart?
Administrative functions: Create and administrative account where he/she can perform different functions. Some examples include, but are not limited to, creating user quotas, downloading the database file…..etc.
Timeouts: Currently, if the client is idle for a while, the connection remains established. This way you may be wasting sockets or someone might have simply left the account open and left the machine. How do you handle these cases?
After implementing one of these features, you can work on implementing a checksum for detecting and handling errors in the header for an extra 10 point credit. You can only use the checksum field in the protocol for this feature.
You will choose either Java or C for this assignment. In either case, you must turn in two programs (all headers, etc. should be included in each of the two files), as well as a README file. The README file should contain information on how to compile your program, with all necessary links you may need for included libraries. If you are using C, the programs should be:
For Java, the program names should be:
NOTE: Pay attention to all of these directions carefully. An automated checker will be used and if there are any deviations, you will lose points!
The assignment should be submitted as an email attachment. The email should be sent to kharras@cs.ucsb.edu with a subject of "276 hw2" (without quotes). The attachment should be a single gziped and tarred file called "<username>.tar.gz". Untaring the file should create a subdirectory named "username" and should include the exact set of files described above.
- There will be a 10 minute demo required from each of you to show what you did. The timeslots available are shown here. Send Khaled an email to reserve a timeslot for your demo, and the timeslots page will be updated accordingly, on a first send first reserve base, so that you can keep track of which times are taken.
- Demos will be in the GSL lab. Make sure to have everything prepared and ready for the demo. You have EXACTLY ten minutes, so make sure you have one or more scenarios that show that your protocol is working (the "running sample" shown here is a good start). Also, make sure that you have any tools you need to use (ethereal or tcpdump...etc) ready so that you don't waste your precious demo time finding them.
- The Demos are a MUST. Failure to deliver a demo will result in a loss of 10 points.
- Make sure to give a demo, even if you do not have everything working. Show me what you have working, and how much you have accomplished in what you don't have working.
Below is a breakdown of points for this assignment. In addition to correctness, part of the points count towards how well code is written and documented. NOTE: good code/documentation does not imply that more is better. The goal is to be efficient, elegant and succinct!
This assignment is to be done individually. Cheating will
not be tolerated. Please read the
UCSB Academic Code of Conduct to find out more about Student Conduct
and Discipline. Of particular relevance to this assignment is the need to
properly cite material you have used. Failure to do so constitutes plagiarism.