Spring 2006


Design Project Two: Frequently-Asked Questions

An important lesson from the real world is that the customer's specification of the problem is nearly always incomplete and inconsistent: one of the jobs of the system designer is to discover those gaps and inconsistencies and figure out what to do about them. In some cases, the best thing to do is to make a reasonable assumption and proceed. In others, it is better to ask the customer what he or she really intended. But asking the customer doesn't always work: the customer may not have an answer and is hoping that the system designer will just do something appropriate. So please don't be surprised if this FAQ gives some answers that seem vague.

Q: Does the link layer automatically perform CRCs or other validity checks?

A: Yes; you do not need to worry about message corruption.

Q: Can we assume that the three components we must design, along with the existing components described by the DP, are the only resource consumers on the laptop?

A: Yes, your design may use all of the computer's resources for the system that you describe.

Q: How much of the wireless bandwidth can our laptops use for "meta-data" and routing information?

A: As much as you want, as long as your system works. Remember that your applications have actual data to send.

Q: How much of the laptop's disk can my system use for storing "intermediate" data like intermediate packets?

A: As much space as is available. The parameters in the assignment imply that your system cannot devote the entire disk to intermediate storage: some of the disk must store files, both for the local laptop and for remote laptops (as required by the backup application). With the remaining disk space, however, your system may do whatever you, the system designer, want.

April 8, 2006: I noticed that no API was specified for how messages are received by the network layer from the link layer. Shouldn't there be some sort of link layer handler function that my network layer can register?

Good point! We've updated the design project to version 2 and added this API. See Section 3 (Existing Components). We also clarified the description of how the receive interface between applications and the network protocol should work. See the discussion of register_handler in Section 2.1.

Last updated: 2006/04/24