There is a bug in the project a submit instructions where the example says to use
submit -user csci551 -tag proj1 file1 [ file2 ... ]This should be:
submit -user csci551 -tag proja file1 [ file2 ... ](proj1 will not work).
Is the DV message format defined in project specification the physical data format transferred between two routers, or it is just a protocol format which both UDP sides agree on?I treated it as a protocol level format and have my own data structures for its fields (like struct, bit field ). However since struct might have their own paddings, the actual packets sent over the UDP might not have the exact format like the one defined in DV Message ( like the # of total bytes might be different).
Consequently, the printout for "last-dv-msg-sent" might not be the same as the sample output depending on implementation details.
Answer: It is a required physical format.
Using your own data structures does not meet this requirement if they do not result in exactly the same physical format (padding, etc). Not meeting this format will cost you some points.
(Motivation: network protocols in the real-world have pre-specified formats that must be followed to interoperate. This part of the assignment is meant to capture that requirement.)
Several students asked things like:
In the messages-received , should it also include the ACKs received ? Also should the messages sent include the retransmitted messages if any ?Answer: All messages sent of any type should be counted as messages sent. All messages received of any type should be counted as messages received, except for ones that you immediately drop due to packet loss.
23-Mar-03: A student asked
I have some confusion when implementing the routing core of Project A. As I understand, the Internet addresses and prefixes represent "interfaces" but not locations. But in our project we assign one prefix to each router. It seems to me that the physical meaning of this prefix isn't very clear here. Would you clarify that? Is this realistic in practice?
Answer: You can think about the prefix as prepresenting a network that is attached to the router, but not simulated in the assignment. In reality, the scenario would be more complicated, with addresses assigned to interfaces AND prefixes representing LANs (see the Stewart book fro some discussion about this). Simulating that level of detail does not seem warrented in this assignment.
All stages together (sample_output.tar.gz, sample_output.zip).
ALSO, you should not just stop with these sample inputs, but you should consider other scenarios that you may need to evaluate.
Finally, of course these are just sample outputs. Your actual outputs will vary (for example, the process IDs in s1.out will change every time you run the program, and the message ordering or losses in stages 2 and 3 will also change from run to run).
The grader prepared these pictures of the topologies:
(with sample output)
(with initial routes)
(with initial routes)
(no routes shown)
Also, keep in mind that students cannot reuse code or libraries done by other people without first consulting with the professor or the TA (exceptions are listed in the project assignment). This includes code from last year's projects.
(Credit for Timer API instruction and description: Alefiya
Hussain.)
Timer API : This is a small example
program that demonstrates how to manage multiple timers in the
project using a simple event-based queue.
Instructions:
Download the tar file, and extract the files using
tar -xvf timer-api.tar
Compile the code by typing make at the command line
Execute the test application by typing ./test-app at the command line.
Operation:
The test application defines two timers: one that fires every 3
seconds and the other that fires every 10 seconds. The program
demonstrates how event queues can be used to keep track of multiple
timers using a single select call.
The program can be terminated using Ctrl+C
There is a C language binding to the Timer API. To run the test
application using the C language binding type ./test-app-c
Files included in the tar ball:
Test Application using C-language binding: test-app-c.c
Test Application in C++ : test-app.cc,test-app.hh
Timer Functionsbinding in C : timers-c.cc, timers-c.h
Timer Functions : timers.cc timers.hh
Helper Functions : tools.cc tools.hh
If you want to test your code on a little-endian machine (Intel etc), you need to compile your code in that platform and run it. The department does not provide an easy platform (linux) to do this. You can either use the windows workstations and use VC++ etc to test your code or run the code in your own Intel linux machine. Alternative approach is to reason through your code and to convince yourself that the code works in any platform. If you want to make your code cross-platform, you should make sure it compiles cleanly on aludra or