4003-541-70/4005-741-70 Data Communications and Networks II Undergraduate Programming Project 1 Prof. Alan Kaminsky -- Spring Quarter 2006 Rochester Institute of Technology -- Department of Computer Science Overview Software Requirements Submission Requirements Grading Criteria Late Projects Plagiarism Overview Write a Java program for one node in an overlay network. The program is based on the RIT Overlay Network (RON) Router in the Computer Science Course Library. The program adds the following features to the basic router: The ability to compute routes automatically using a distance vector algorithm. The ability to trace the route from a source to a destination. Software Requirements Requirement 1. The program is called DVR (for "distance vector routing"). The program is run by typing this command:   java DVR <configfile>   where <configfile> is the name of the router configuration file. (Note: This means that the main program class must be named DVR, and this class must not be in a package.) Requirement 2. When the program starts up, it configures a RON Router by reading commands from the configuration file specified on the command line. Each line of the file consists of one of these commands: setAddress <address> -- Set the router's RONP address.   addInterface <intfid> <nearhost> <nearport> <farhost> <farport> -- Add a router interface with the given interface ID, near end host and port, far end host and port, a data rate of 56,000 bps, and a maximum queue length of 1,000. These are the same as the commands for the createManualRouter() method in class edu.rit.ron.RouterFactory, except there are no commands for configuring routes, and each interface's data rate and maximum queue length are fixed constants. Requirement 3. The DVR program uses the distance vector algorithm to compute routes automatically, as described in Comer, Computer Networks and Internets, Chapter 13. The distance metric used is the number of hops. The number of hops along any route is limited to a maximum of 20; any value larger than that is considered to be "infinity." If the distance from Router A to Router B is infinity, it means that B is unreachable from A; in other words, there is no path from A to B. Requirement 4. Each router sends its distance table to each of its neighboring routers in the following situations. A router sends its distance table to each of its neighboring routers when the router first starts up. The router's initial distance table has only one entry, consisting of the router itself at a distance of 0.   A router sends its distance table to each of its neighboring routers when the router's distance table has changed as a result of processing a routing message received from one of the neighboring routers. (If the router processed a routing message and the router's distance table did not change, then the router does not send a message to the neighboring routers.)   A router sends its distance table to each of its neighboring routers periodically, once every 10 seconds.   If a router fails to receive a routing message from a neighbor within 15 seconds from the last routing message (the extra 5 seconds is to provide some leeway), the router concludes that the neighbor is unreachable and recalculates its distance table. If the router's distance table changed, the router sends its distance table to each of its neighboring routers as in Case (b). Requirement 5. Routing messages are transported in RONP packets with a transport protocol ID of 2. The design of the routing messages is up to you. Requirement 6. The DVR program also implements an addition to the RON Control Message Protocol (RCMP). Two new opcodes are added to RCMP: Opcode = 2, Trace Route Request. When the transport layer entity sends a Trace Route Request message, the message initially consists only of the opcode. When a router receives a Trace Route Request message, either from a transport layer entity or from an incoming interface, the router appends the router's own RONP address (four bytes, most significant byte first) to the end of the packet. If the packet is destined for a different router, the router then forwards the packet as usual. If the packet is destined for the router itself, the router turns it into a Trace Route Reply message and sends it back to the original source.   Opcode = 3, Trace Route Reply. The router merely forwards or delivers the Trace Route Reply message as usual. Thus, Trace Route Request messages and Trace Route Reply Messages work similarly to Echo Request and Echo Reply messages. The Trace Route Request message accumulates the sequence of routers (RONP addresses) encountered as the message traverses the network. The Trace Route Reply message returns the list of routers back to the original source. The list consists of the source router, zero or more intermediate routers, and the destination router. Requirement 7. After starting up and configuring the RON Router, the DVR program reads commands from the standard input and processes them. The commands are: send <address> <text> -- Send a message to the given destination address with the given text. When the destination DVR program receives this message, the destination DVR program prints:   Message received from <address>: <text>   ping <address> <text> -- Send an RCMP Echo Request message to the given destination address with the given text. When the RCMP Echo Reply message comes back to the source DVR program, the source DVR program prints:   Echo reply received from <address>: <text>   traceroute <address> -- Send an RCMP Trace Route Request message to the given destination address. When the RCMP Trace Route Reply message comes back to the source DVR program, the source DVR program prints:   Trace route reply received from <address>: <router>-<router>...   giving the list of routers in the Trace Route Reply message separated by hyphens.   quit -- Quit the program. These are the same commands as the edu.rit.ron.test.Test01 program, with the addition of the traceroute command. Requirement 8. Unlike the Test01 program, the DVR program does not print any messages when the router performs internal actions. Submission Requirements Your project submission will consist of a Java archive (JAR) file containing all the Java source files for your project. Each Java source file name must end in ".java".   Each class or interface must include a Javadoc comment describing the overall class or interface.   Each method within each class or interface must include a Javadoc comment describing the overall method, the arguments if any, the return value if any, and the exceptions thrown if any. See my Java source files which we studied in class for the style of Javadoc comments I'm looking for. Put all the source files into a JAR file named "<username>.jar", replacing <username> with the user name from your Computer Science Department account. The command is: jar cvf <username>.jar *.java If your project used classes from the Computer Science Course Library without modifications, you do not need to include the source files for these classes in your submission. If your project used classes from the Computer Science Course Library with modifications, you do need to include the source files for these classes in your submission. Send your JAR file to me by email at ark­@­cs.rit.edu. Include your full name and your computer account name in the email message, and include the JAR file as an attachment. When I get your email message, I will extract the contents of your JAR file into a directory. I will set my Java class path to include the following directories: the directory where I extracted your files, and the Computer Science Course Library directory. I will compile all the Java source files in your submission using the JDK 1.5.0 compiler. I will then send you a reply message acknowledging I received your project and stating whether I was able to compile all the source files. If you have not received a reply within one business day (i.e., not counting weekends), please contact me. Your project is not successfully submitted until I have sent you an acknowledgment stating I was able to compile all the source files. The submission deadline is Tuesday, April 11, 2006 at 11:59pm. The date/time at which your email message arrives in my inbox (not the time when I actually read the message, which will be some time later than when it arrives in my inbox) will determine whether your project meets the deadline. If you submit your project before the deadline, but I do not accept it (e.g. I can't compile all the source files), and you cannot or do not submit your project again before the deadline, the project will be late (see below). I strongly advise you to submit the project several days before the deadline, so there will be time to deal with any problems that may arise in the submission process. Grading Criteria 50% of your project grade will be based on the design of your project as documented in the Javadoc and as implemented in the source code. Your project should: Be designed using object oriented design principles. Make use of reusable software components where appropriate. Be documented using proper Javadoc style as described above. Correctly implement the distance vector routing algorithm. Correctly implement the RCMP Trace Route Request/Reply functionality. 50% of your project grade will be based on test runs of your project, with multiple processes each running the DVR program. The grade for this portion will be based on whether your project produces the correct output as specified in the Software Requirements. Every incorrect output will result in a loss of points. There is one exception: If your application does not run using the command line stated in Requirement 1, you will receive 0 points for this portion of your grade. Any deviation from the requirements will result in loss of points. This includes errors in the output formatting (such as incorrect number of spaces, incorrect capitalization, or incorrect punctuation), misspelled output, and extraneous output not called for in the requirements. The requirements state exactly what the output is supposed to be, and there is no excuse for outputting anything different. If any requirement is unclear, please ask for clarification. Late Projects See the Course Policies for my policy on extensions. I will not accept a late programming project unless you arrange with me for an extension. A late programming project will receive a grade of 0. Plagiarism See the Course Policies for my policy on plagiarism. You may use any resources you wish to do the programming project, including resources discussed in class and resources you find on your own. You may discuss the programming project at a general level with others in the class. However, the programming project you turn in must be entirely your own work. You are not allowed to collaborate with anyone else on the programming project. You are not allowed to use any current or past student's work in any way when working on your programming project. I will not tolerate plagiarism. If in my judgment the programming project is not entirely your own work, you will get a grade of 0 for the programming project. I will also place a report of the plagiarism incident in your permanent file in the Computer Science Department office. Repeated plagiarism incidents will result in disciplinary action in accordance with Computer Science Department policy and RIT policy. There are only two exceptions to the prohibition on plagiarism: You may reuse without modification a source file from the Computer Science Course Library.   You may take a source file from the Computer Science Course Library and add your own modifications, provided you state that you have done so and give credit to the original author. Ad Hoc Networks • 4003-543-01/4005-742-01 • Spring Quarter 2007 Course Page Alan Kaminsky • Department of Computer Science • Rochester Institute of Technology • 4486 + 2220 = 6706 Home Page Copyright © 2006 Alan Kaminsky. All rights reserved. Last updated 28-Mar-2006. Please send comments to ark­@­cs.rit.edu.