CSCI 551 TA page, Project A related announcements

Hi, my name is Omprakash Gnawali. I am a TA for John Heidemann's CSCI551 in Spring 2003. On this page, you will find hints and announcements related to homeworks, exams, and the course. Please make a habit of checking this page before you email me with your questions.


Thursday, March 27 2003

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).
24-Mar-03 a student asked:
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.


The grader prepared these pictures of the topologies:

(with sample output)

(with initial routes)

(with initial routes)

(no routes shown)


March 18, 2003

For project A, your README should clearly specify how many stages of your project are working completely and how many stages work partially, this way they can be graded consistently

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.


March 8, 2003

The PA2 configuration will be syntactically correct. This means, for example, you will have an integer in a field when you expect an integer. We also won't have an inconsistent or non-sensical input file. I.e., saying there are 5 routers but having config info for only 4, or having disconnected routers. Or having a drop rate that is negative or more than 100%. However, you may find it is helpful in debugging to add some code to sanity check your inputs.
February 22, 2003
Makefile in the Timer API fixed for Linux. Download the new code: Timer API
February 17, 2003

(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


February 5, 2003

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