JHU / CS / 600.120: Intermediate Programming

Assignment 8: Serious Networking

Out on: March 31, 2008
Due by: April 7, 2008, 3:00 pm (before lecture)
Collaboration: Pairs
Grading: Packaging 10%, Design 20%, Style 10%, Performance 10%, Functionality 50%

Overview

The eighth assignment asks you to collaboratively improve the simple network simulation each one of you implemented for the last assignment. There will be various new options to implement, both for the simulation itself and the routing algorithms used by hosts. Since you are working as a pair again, it's important that you coordinate your schedules and stay in touch during the week! Working together in lab or at a laptop in a cafe somewhere is highly encouraged. After the assignment is over, each of you will be asked to evaluate the contribution your partner and yourself made to the assignment.

Problem 0: Code Review (10%)

Your first task is doing a code review again! You have a new partner, and each of you (hopefully) has an implementation from last week. Somehow you must decide whose code you're going to work on for this assignment, and what better way is there than a thrilling code review?

Since this is your first C++ code review, you should do it in some detail again, similar to the first C code review you did. Follow the procedure outlined in class before the first code review: Exchange the code, read it independently, mark it up with questions/comments, then meet and discuss things in person. Afterwards, write up your impressions, both good and bad stuff, for each implementation in your README file; also write up your decision about whose code you're going to use and why.

I strongly recommend being done with the code review by Thursday at the latest! You'll need time to actually work on the remaining problems.

Problem 1: Modeling Links (30%)

Your second task is to model links in addition to hosts and hops, which you already modeled last week. The idea is to assign transfer speeds to links and sizes to messages, which will enable us to estimate how long it takes to transfer a message from its source to its destination. Obviously we need to extend the input format to accomodate the additional information:

NETWORK
  Speed
HOSTS
  Eins
  Zwei
  Drei
  Vier
LINKS
  Eins TO Zwei SPEED 9600
  Eins TO Drei SPEED 2400
  Drei TO Eins SPEED 9600
  Eins TO Vier SPEED 300
  Zwei TO Vier SPEED 19200
MESSAGES
  Eins TO Vier SIZE 1024
  Drei TO Vier SIZE 49152
END

As you can see, we need to specify the speed of each link; the unit is bytes/second. We also need to specify the size of each message; the unit is in bytes. For each message, you should compute how long it took to get it from source to destination; you'll print that information in the statistics shown at the end of the simulation. For example, sending a message of 32768 bytes across a link with 9600 bytes/second takes about 3.42 seconds.

Note that if the SPEED specification is missing, you should assume a default speed of 9600 bytes/second; if the SIZE specification is missing, you should assume a default size of 10240 bytes.

Also, note that this extension still doesn't require a separate Link class, you could just as well store the capacity of each outgoing link inside the host. This is not 100% accurate from a software modeling perspective, but since it'll work fine... Your call! :-)

Problem 2: Routing Algorithms (30%)

Your third task is to implement two new routing algorithms in addition to random routing which you did last week. You'll need to use inheritance to do this, here's how to get started: Refactor your old Host class into a pure abstract base class called Host that defines the interface for all hosts and a concrete subclass called RandomHost that inherits from Host and performs random routing like last week. Make sure you get everything to compile again, you'll need to adapt all places in your program where Host objects were created previously (it may be a good idea to write a function that creates RandomHost objects for you so you can make the change in one place instead of many).

Once you're done with this first part, you need to implement two more subclasses, ResendHost and LearningHost that implement alternate routing algorithms as follows:

When a ResendHost realizes that a delivery across a randomly chosen link failed, it tries to resend the message across a different link. It chooses randomly among the remaining links (for which delivery of that message hasn't been attempted yet). If there are no more untried links left after a failure, it fails itself. (Note that this kind of host doesn't "learn" over time, it'll make the same mistakes again and again if given a chance; its "memory" disappears after each delivered or failed message.)
Delivery for LearningHost works different again. Each host "remembers" the "best link" to a destination. In other words, the host "learns" over time what link to use to send a message to a given destination. The host must remember how long it took to deliver a message to a given destination across each of the host's outgoing links. If we have not tried all outgoing links for a given destination yet, we try them one at a time (not for the same message, but for a sequence of messages to the same destination). Once we have tried all outgoing links, we know which one delivered the message most quickly, and from then on we always use that link to route to that destination. Note that we can also learn that we cannot reach a given destination at all, in which case we can immediately fail when we're handed a message for that destination.

Obviously there must be a way to select what kinds of hosts to create and simulate. We'll handle this with command line options. If no option is given, we default to RandomHost objects; if the option --resend or -r is given, we use ResendHost instead; if the option --learn or -l is given, we use LearningHost instead. Note that those two options are mutually exclusive, it's an error to supply both when the program is started.

Problem 3: Multiple Messages (30%)

For the last problem, we make another extension to the input specification. It can be tedious to simulate a randomly routing network since we need to send each message a large number of times to find out the overall behavior of the network. Therefore we add another specification, namely the number of times a message should be routed before the statistics for it are computed. Here's what we add to the input specification:

NETWORK
  Times
HOSTS
  Eins
  Zwei
  Drei
  Vier
LINKS
  Eins TO Zwei
  Eins TO Drei
  Drei TO Eins
  Eins TO Vier
  Zwei TO Vier
MESSAGES
  Eins TO Vier TIMES 1000
  Drei TO Vier TIMES 2000
END

This means that the first message should be sent 1000 times while the second message should be sent 2000 times; the relevant information, i.e. number of hops and delivery times etc., should be averaged across those 3000 experiments instead of being computed only once. If no TIMES specification is given, the number of times a message is sent defaults to 1 for backward compatibility. Note that this extension must work with the one defined in Problem 1 above as well. Enjoy. :-)

Hints

Aside from the std::string, std::vector and iostream classes you are free to also use the std::map class.
The specification for the second routing algorithm is not quite clear as you will probably see when you try to implement it. You can ask all kinds of questions about it, but in the end, you'll have to decide what to do and defend your decision in your README file. Lousy specifications are something you need to get used to. Sorry.
Speaking of lousy specifications: There's also no specification for the output. Go figure. Whatever output format you design, make sure you can tell us why it's a good one for people looking to simulate networks and routing algorithms. Yep, your README is the place for this as well.

Deliverables

Please turn in a gzip compressed tarball of your assignment; the filename should be cs120-assign-8-login1-login2.tar.gz with login1 and login2 replaced by your Unix login names on ugradx.cs.jhu.edu. The tarball should contain no derived files whatsoever (i.e. no executable files), but allow building all derived files. Include a README file that briefly explains what your programs do and contains any other notes you want us to check out before grading. Include a Makefile to build your project.

Grading

For reference, here is a short explanation of the grading criteria. Packaging refers to the proper organization of the stuff you hand in, following the guidelines for Deliverables above. Style refers to C++ programming style, including things like consistent indentation, appropriate identifiers, useful comments, suitable documentation, good use of private and const, etc. Simple, clean, readable code is what you should be aiming for. Performance refers to how fast your program can produce the required results compared to other submissions. Design refers to proper modularization (into files and classes) and the proper choice of algorithms and data structures. Functionality refers to your programs being able to do what they should according to the specification given above; if the specification is ambiguous and you had to make a certain choice, defend that choice in your README file.

If your programs cannot be built you will get no points whatsoever. If your programs cannot be built without warnings using g++ -ansi -pedantic -Wall -Wextra -std=c++98 -O -Wabi -Weffc++ -Wctor-dtor-privacy -Wold-style-cast -Woverloaded-virtual -Wno-pmf-conversions -Wsign-promo we will take off 10% (except if you document a very good reason). If your programs cannot be built using make we will take off 10%. If your programs fail miserably even once, i.e. terminate with an exception of any kind or dump core, we will take off 10%. Finally, make sure to include your name and email address in every file you turn in!