Department of
Computer Science
 
[ Home | Description | Lectures | Labs | Programming | Piazza ]
Spring 2020
CSCI 353
Programming Assignment #5
(100 points total)
Network of Servers in C/C++, Part 2 – Transport Layer and Application Layer
Due 11:45PM 5/1/2020 (firm)
IMPORTANT: This assignment depends on a working PA4 code base. We will ABSOLUTELY NOT give you a solution to PA4 to start this assignment! If you don’t have a working PA4, you will most likely not be able to get any partial credit for this assignment.
IMPORTANT: Lab 12, Lab 13, and Lab 14 are designed to get you going on this assignment. It’s highly recommended that you finish those labs as early as possible. When you are done with all these labs, you just need to run your code through the grading guidelines to make sure you can get all the points and you are done!
Introduction
In PA4, your nodes were able to hold hands with their neighbors tightly and were able to agree on the topology of the 353NET. Now we are ready to route messages in the 353NET and have 353NET applications exchange messages with each other. The type of application messages we will support in this assignment are unicast messages, i.e., one sender (or source node) sends a message to a single receiver (or destination/target node).
In this assignment, you will first finish building the Network Layer (layer 3) of the 353NET to add functionality to our nodes so they can also act like routers to deliver unicast messages. We will add a Transport Layer (layer 4) on top of it to carry application messages from one node to another node in the network. Finally, we will add a couple of networking applications to use the Transport Layer services.
Electronic submissions only.
Disclaimer: The 353NET is a toy network. It’s not terribly efficient. It’s designed as a programming exercise in an introductory networking class.
Compiling
You must use a Makefile so that when the grader simply enters:
make pa5
(or simply “make”), an executable named pa5 is created and the compiler command that gets run must start with “g++ -g -Wall -std=c++11”. Please make sure that your submission conforms to the general compilation requirements and README requirements.
The grader will be using the above command to create your executable on a standard 32-bit Ubuntu 16.04 system running inside VirtualBox as mentioned in the general compilation requirements.
Commandline Syntax
The commandline syntax (also known as “usage information”) for pa5 is as follows:
pa5 CONFIGFILE
The CONFIGFILE is a PA4 configuration file that contains all the information your node needs in order to function in the 353NET. Some parameters in a PA4 configuration file were not used in PA4. For this assignment, you will need to utilize more configuration parameters as specified in this spec (and the specs for Lab 12, Lab 13, and Lab 14).
Unless otherwise specified, output of your program must go to stdout/cout and error messages must go to stderr/cerr.
Transport Layer Services
Transport layer services such as UDP and TCP were covered in Chapter 3 of the textbook. Two main differences between UDP and TCP are, (1) UDP has a packet abstraction while TCP has a byte stream abstraction, and (2) UDP does not guarantee packet delivery while TCP guarantee byte stream delivery. TCP is a bit too complex to implement in this assignment. We will focus on the byte streamm and reliability aspects of TCP by implementing an Alternating Bit Protocol, which was presented as RDT-3.0 in Section (3.4) of the textbook on the Principles of Reliable Data Transfer. In the textbook, RDT-3.0 runs on top of UDT (unreliable data transfer) and UDT has the characteristics of UDP. Therefore, we will be implementing UDT and RDT-3.0 in this assignment.
Application Layer
You will need to implement three applications in this assignment. The traceroute applicaiton runs on top of UDT. The echo client/app and the echo server runs on top of RDT-3.0. Please see the lab specs for details about these 353NET applications.
Message Routing
Message routing is done via the use of the forwarding table stored at a node. The forwarding table is constructed using either BFS or Dijkstra’s Shortest Path algorithm using the link state information maintained within a node. (Since the edge cost is 1 for every edge in the graph, you can use the Breadth-First-Search Algorithm instead.) The link state information is maintained as a hard state in the 353NET.
353NET Protocol Message Format
Since this assignment needs to be built on top of PA4, we will use exactly the same messages as PA4. You did not have to implement the UCASTAPP message in PA4 since PA4 doesn’t use that message type. For this assignment, you must implement the UCASTAPP message type. Each UCASTAPP message will carry an UDT message (i.e., the entire message body of an UCASTAPP message is an UDT message). Here is a summary of the types of UDT messages that must be supported in this assignment:
• 353UDT/1.0 PING SESID – a single-line UDT message used by the traceroute application
• 353UDT/1.0 PONG SESID – a single-line UDT message used by the traceroute application
• 353UDT/1.0 TTLZERO SESID – a single-line UDT message used by the traceroute application
• 353UDT/1.0 RDTACK SEQNUM APPNUM – a single-line UDT message used in RDT-3.0
• 353UDT/1.0 RDTDATA – a multi-line UDT message used in RDT-3.0 to deliver a single character for an RDT application
Please see the respective lab specs for details.
User Console
In additional to all the PA4 console commands, you must implement the following console commands in this assignment:
Name
Arguments
Description
forwarding
Please see Lab 12 for details.
traceroute
target
Please see Lab 13 for details.
rdtsend
target message
Please see Lab 14 for details.
echoapp
target
Please see Lab 14 for details.
If the command entered by the user is not a valid command, you must print the following:
[BC: fixed 4/24/2020]
Command not recognized. Valid commands are:\n
\techoapp target\n
\tforwarding\n
\tlinkdown neighbor\n
\tlinkup neighbor\n
\tlistdownlinks\n
\tneighbors\n
\tnetgraph\n
\trdtsend target message\n
\ttraceroute target\n
\tquit\n
If a particular command is malformed (such as wrong number of arguments), please give the correct usage information for that command.
Logging
As in PA4, it’s very important to perform logging correctly since grading depends on it. For this assignment, you must log all UCASTAPP messages to cout and log all SAYHELLO and LSUPDATE messages to the log file (since we will not be checking the log files for grading in this assignment, there is no need to log SAYHELLO and LSUPDATE messages).
We will keep the same log message format as in PA4. For an UCASTAPP message, it would look like the following:
[BC: typo fixed 4/28/2020]
[TIMESTAMP] {r|i|f} UCASTAPP NEIGHBOR TTL 0 CONTENT_LENGTH msg-dependent-data
For the UDT message types that must be supported in this assignment, please see the following table regarding what to log for the msg-dependent-data part of a log entry:
UDT MSGTYPE
Description
msg-dependent-data
PING
PING
MSGID SRC_NODEID DEST_NODEID 1 UDTMSGBODY
PONG
PONG
MSGID SRC_NODEID DEST_NODEID 1 UDTMSGBODY
TTLZERO
TTLZERO
MSGID SRC_NODEID DEST_NODEID 1 UDTMSGBODY
TTLZERO
RDTACK
MSGID SRC_NODEID DEST_NODEID 1 UDTMSGBODY
RDTDATA
RDTDATA
MSGID SRC_NODEID DEST_NODEID 2 SEQNUM APPNUM CLENGTH RDTMSGBODY
You are welcome to use the short-hand notation for log messages.
Input and Output Examples
Please download pa5data.tar.gz and put it in the same directory of your pa5 executable file. Then cd (change directory) into that directory and type:
gunzip pa5data.tar.gz
tar xvf pa5data.tar
This should create a subdirectory called “pa5data” with a bunch of files in it.
Please see Lab 12, Lab 13, and Lab 14 for examples. Please also see the Lab 12 lecture slides, Lab 13 lecture slides, and Lab 14 lecture slides, for more examples (although there may be overlaps).
Grading Guidelines
The grading guidelines has been made available. Please understand that the grading guidelines is part of the spec and the grader will stick to it when grading. It is possible that there are bugs in the guidelines. If you find bugs, please let the instructor know as soon as possible so they can be fixed.
The grading guidelines is the only grading procedure we will use to grade your program and the grader must grade your submission on a standard 32-bit Ubuntu 16.04 system running inside VirtualBox. No other grading procedure will be used. If your program only runs on some other platform, you will get no credit for it. Therefore, it’s imperative that you run your code through the grading guidelines on a standard 32-bit Ubuntu 16.04 system running inside VirtualBox. To make sure that you didn’t hard-code anything so that your code would only work with what’s explicitly and exactly mentioned in the grading guidelines, we will change the testing data (including file names and commandline arguments) when grading. We will try our test to keep the basic commands the same (although we may make minor changes if we discover bugs in the script or things that we forgot to test.) Finally, please understand that for the same mistake in your code, you may get points deducted over and over again (i.e., do expect “double jeopardy”, “triple jeopardy”, etc.).
To save typing all those commands in the grading guidelines, you can use tmux. Below are scripts that uses tmux so you can easily start with the configuration in each section of the grading guidelines.
tmux-pa5-A.txt
tmux-pa5-B.txt
tmux-pa5-C.txt
tmux-pa5-D.txt
tmux-pa5-E.txt
Plesae note that they are provided for your convenience (i.e., to save typing) and it may not be exactly the same as the grading guidelines.
Before you run these tmux scripts, please read the comment section in the script regarding how to set it up and run it. Please see PA2 FAQ regarding tmux installation instructions.
Miscellaneous Requirements and Hints
• Please take this spec and the grading guidelines very seriously. Please understand that graders must follow the grading guidelines when grading and they are not permitted to use a different grading procedure to grade your submission (due to our fairness policy). Please understand that you won’t get credit for simply coding, i.e., we cannot give you any partial credit for your “effort”. We can also give you credit for “results”. It is also imperative that you test your code against the grading guidelines on a standard 32-bit Ubuntu 16.04 system running inside VirtualBox. Even if your code runs perfectly on some other platform, we cannot take that into consideration for grading.
• Please read the programming FAQ if you need a refresher on C/C++ file I/O and bit/byte manipulications.
• You must not look at, copy, or share any code fragments from your classmates or previous semesters to implement this assignment.
• When you perform numerical calculation, please make sure that you never use or print any value that’s “NaN” (not-a-number). If you see a “NaN” on the screen at any time, you have a bug in your code and you must get it fixed!
• It’s important that every byte of your data is read and written correctly. You will lose a lot of points if one byte of data is generated incorrectly! The grading of this assignment will be harsh and you must make your code work according to the spec and the posted grading guidelines.
• If you are programming in C, I/O functions such as fgets(), scanf(), and printf() are really meant for inputing/outputing ASCII strings. Do not use them to input/output binary data!
• Start working on this early! This assignment is tedious and it would take quite a bit of time to get it done correctly.
Submission
All assignments are to be submitted electronically (including the required “README” file). To submit your work, you must first tar all the files you want to submit into a “tarball” and gzip it to create a gzipped tarfile named “pa5.tar.gz”. Then you upload “pa5.tar.gz” to the Bistro system. The command you can use to create a gzipped tarfile is:
tar cvzf pa5.tar.gz MYLISTOFFILES
ls -l pa5.tar.gz
Where MYLISTOFFILES is a list of file names that you are submitting (you can also use wildcard characters if you are sure that it will pick up only the right files). DO NOT submit your compiled code, just your source code and README file. Two point will be deducted for each binary file included in your submission (e.g., pa5, .o, .gch, core, etc.). The last command shows you how big the created “pa5.tar.gz” file is. If “pa5.tar.gz” is larger than 1MB in size, the submission server will not accept it.
Please note that the 2nd commandline argument of the tar command above is the output filename of the tar command. So, if you omit pa5.tar.gz above, you may accidentally replace one of your files with the output of the tar command and there is no way to recover the lost file (unless you have made a backup copy). So, please make sure that the first commandline argument is cvzf and the 2nd commandline argument is pa5.tar.gz.
A pa5-README.txt template file is provided here. You must save it as your “pa5-README.txt” file and follow the instructions in it to fill it out with appropriate information and include it in your submission. Please make sure that you satisfy all the README requirements.
Here is an example commands for creating your pa5.tar.gz file:
tar cvzf pa5.tar.gz Makefile *.c* *.h pa5-README.txt
If you use an IDE, the IDE may put your source code in subdirectories. In that case, you need to modify the commands above so that you include ALL the necessary source files and subdirectories (and don’t include any binary files) and make sure you have not forgotten to include a necessary file in order for the grader to compile your code on a “clean” system using just your Makefile (please remember that the grader is not permitted to use an IDE to compile or run your code).
You should read the output of the above commands carefully to make sure that “pa5.tar.gz” is created properly. If you don’t understand the output of the above commands, you need to learn how to read it! It’s your responsibility to ensure that “pa5.tar.gz” is created properly.
To check the body of “pa5.tar.gz”, you can use the following command:
tar tvf pa5.tar.gz
Please read the output of the above command carefully to see what files were included in “pa5.tar.gz” and what are their file sizes and make sure that they make sense.
Please enter your USC e-mail address and your submission PIN below. Then click on the Browse button and locate and select your submission file (i.e., “pa5.tar.gz”). Then click on the Upload button to submit your “pa5.tar.gz”. (Be careful what you click! Do NOT submit the wrong file!) If you see an error message, please read the dialogbox carefully and fix what needs to be fixed and repeat the procedure. If you don’t know your submission PIN, please visit this web site to have your PIN e-mailed to your USC e-mail address.
USC E-mail:
@usc.edu
Submission PIN:
Event ID (read-only):
merlot.usc.edu_80_1557931083_35
Submission File Full Path:
If the command is executed successfully and if everything checks out, a ticket will be issued to you to let you know “what” and “when” your submission made it to the Bistro server. The next web page you see would display such a ticket and the ticket should look like the sample shown in the submission web page (of course, the actual text would be different, but the format should be similar). Also, an e-mail (showing the ticket) will be sent to your USC e-mail address. Please read the ticket carefully to know exactly “what” and “when” your submission made it to the Bistro server. If there are problems, please contact the instructor.
It is extreme important that you also verify your submission after you have submitted “pa5.tar.gz” electronically to make sure that every you have submitted is everything you wanted us to grade. If you don’t verify your submission and you ended up submit the wrong files, please understand that due to our fairness policy, there’s absolutely nothing we can do.
Finally, please be familiar with the Electronic Submission Guidelines and information on the bsubmit web page.
[Last updated Tue Apr 28 2020] [Please see copyright regarding copying.]
[ Home | Description | Lectures | Labs | Programming | Piazza ]