Douglas E. Comer

Computer Science Department
Purdue University
West Lafayette, IN 47907

webmaster: W. David Laverell

Companion Topics

Home

Book Information

Purpose of Site

Getting Started

Students

Faculty

"What's New"

"Coming Attractions"

"C Pointers"

Acknowledgements

Chapter 8: Protocol Design Experiments

Of all the programming experiments in Douglas E. Comers Hands-On Networking with Internet Technologies, the most daunting is found in Chapter 8, Protocol Design Exeriments. The complete project requires three pieces of UDP software: a gateway (which is actually a server), a server (which is actually a client), and a client which really is a client. The gateway opens a socket for communication with the client and server, and henceforth executes a loop with a select statement followed by a recvfrom. In simple terms, if it comes from the client it goes to the server and vice versa.

Now the client sends the name of a file to the gateway, which, of course, gets passed to the server. The server responds by sending that file in small chuncks through the gateway to the client.

The fun starts when the gateway starts dropping, reordering, corrupting, and duplicating packets. The goal is to build a reliable software suite using UDP, and it is a lot of fun to do. The sliding window protocol enters into the mixture as do sequence numbers, acknowledgments, and all kinds of fun things.

Now at first blush, this would seem to have nothing to do with Emulab. After all, you can do it on a single machine. However, there is reality to deal with. In something like 10 years that I have been giving this assignment, I have never had a student complete it. (That is partly because they just do not realized how difficult it is to do, and so they get started too late.) The last time around I formed teams, and these teams were all successful, in part because I gave them the gateway! When students who think gdb is from the stone age have to be working with three independent programs, and they are not sure which one is acting up, frustrations can easily set in. Come to think of it, the same could be said for a faculty member producing the solutions for this chapter.

Enter Emulab which easily provides a link that drops packets. Now you only have to write two pieces of software. You place your software on users.emulab.calvin.edu (or wherever), begin your experiment, and test away. No gateway to worry about.

You give something up, but you get something back. Emulab, as far as I can tell will not deliberately corrupt, duplicate, or reorder packets, so you have only to deal with missing data. However, it would not be difficult to have your server perform those unpleasant tasks. There is one complication that you do have to deal with (assuming that you have a kindly prof). When I wrote the gateway, I made sure it would not drop the first several packets so that the file name and initial sequence numbers would get through. Not so with the Emulab approach.

An advantage of the Emulab approach is in the extensibility of this experiment. Number 14 of Experiment 8.1 asks that we simulate congestion by varying the delay over time. In my solution I modified the gateway program to respond to keystrokes. Being a vi person, hitting the j key increased the rate at which packets were dropped while hitting the k lowered that rate. It was a blast to see the sliding window respond. In the Emulab environment one could one could get your file transfer suite going, and then fire up a competing UDP file transfer suite over the same link. If you have not seen this, you owe it to yourself to do it. UDP will clobber TCP.

You could also get competing TCP sessions going and compare the rusults when using DropTail or RED. This experiment leads in several interesting directions.