MIT OpenCourseWarehttp://ocw.mit.edu 6.033 Computer System Engineering Spring 2009 For information about citing these materials or our Terms of Use, visit: http://ocw.mit.edu/terms.6.033 2009 Design Project 2 I. Due dates You will do Design Project Two in teams of three students who share the same recitation instructor. There are four deliverables: 1. A list of team members emailed to your recitation instructor by Recitation 17. 2. One copy of a design proposal not exceeding 1,200 words, due by Recitation 20. 3. One copy of a design report not exceeding 5,000 words, due by Recitation 24. 4. An in-class presentation in Recitation 25. In consultation with the chair of the faculty we have determined that the assignment follows the spirit of the end-of-term rules. This assignment is under-specified, and part of your job is to complete the specification sensibly, given the project requirements. Your interpretation of the specifications may need some adjustment as you flesh out your design. Start early to give yourself time to think about your design and revise it. A good design will likely take more than a few days. II. Introduction You and your team are the founders of a new start-up company, called Chatter. The basic idea is to allow users to distribute short text messages to each other using hand-held wireless devices. A typical use scenario is a stadium full of sports fans exchanging comments about the game. Another is students attending a lecture, exchanging questions or feedback. Students might also use Chatter to help organize their social lives, to find nearby friends at meal-times or to find out about campus events. In principle all users should be able to see all messages, though in practice your design will need to restrict distribution to conform with the requirements in the next section. III. System requirements You and your investors agree that Chatter must meet the following requirements: • It should take the form of software running on a hand-held PDA-like device called the ChatterBox. The ChatterBox has a large touch-sensitive screen, a small keyboard, a WiFi wireless network interface, and a GPS receiver. The ChatterBox is not a cell phone. • Users should see each message within seconds of when it is sent, if possible. • Chatter should work reasonably well at extremes of scale: in a stadium with tens of thousands of users, as well as in much sparser environments. • Chatter should provide users with tools to restrict which messages they see, perhaps seeing only messages from particular individuals, or from friends, or on particular topics, or from particular geographic areas. • The ChatterBox's WiFi radio has a range of only about 50 feet.• If a ChatterBox is in range of a WiFi access point that is on the Internet, the ChatterBox may use TCP/IP to talk to servers on the Internet. The access point will allocate it a temporary IP address for this communication. A ChatterBox does not have a permanent IP address. • Chatter should be as functional as possible even when a ChatterBox is not in range of a WiFi access point. The ChatterBox WiFi interface allows sending of "ad-hoc" packets to nearby ChatterBoxes, as if they were on an Ethernet. These ad-hoc packets are link-layer broadcasts; an ad-hoc transmission is received by the ChatterBoxes within radio range. • If a ChatterBox is not in range of a WiFi access point, it will not have an IP address. This means that your design must describe all protocols above the link layer for any ad-hoc communication that Chatter uses. Each ChatterBox has a unique 128-bit serial number accessible to the software. • It will probably be too hard to ensure that every ChatterBox sees every message; it is acceptable if your design does not guarantee delivery. For example, if there is no path in the underlying network from one ChatterBox to another (no path through other ChatterBoxes and/or the Internet), it is acceptable for Chatter to not deliver messages from one to the other, or to delay delivery. • You can assume that each user has exactly one ChatterBox and uses only that ChatterBox. • In addition to supporting distribution of messages to many users, one user should be able to send a message to a specific single other user. • Chatter should try to present messages to the user in a sensible order. For example, one possible scheme might have the following behavior: suppose user U1 sends a message M1. User U2 reads M1 and then sends M2. If user U3's ChatterBox receives M2 first, it will display M2 to the user immediately. If it then receives M1, it will indicate to the user that M1 was sent before M2. • It is fine for Chatter to use one or more servers on the Internet, though the design must cope with the likelihood that many ChatterBoxes will not be in range of a WiFi access point. Your design need not include security mechanisms. IV. Your job Your job is to design the Chatter system, focusing on the algorithms and network protocols that the ChatterBoxes use to fulfill the requirements in Section III. If your design includes servers on the Internet, then you should also design the services those servers provide. Your design should also include any aspects of the Chatter user interface on the ChatterBox that are important in fulfilling the requirements. Here are some questions that your design should answer (and that we will expect to read about in your report): • What happens when a user sends a message from his/her ChatterBox? • How does Chatter cause nearby users to see each message? What is your design's definition of "nearby"? • How does Chatter ensure that messages do not loop? • How does Chatter cause users to see messages from other users who are not in direct radio range?• How does Chatter cope with lost packets? With changes in radio connectivity as users move? • How does Chatter arrange to show messages to the user in a sensible order? • How does Chatter support a user sending a message to just a specific other user? • How do Chatter's protocols differ (if at all) in the cases where a ChatterBox is and is not connected to a WiFi access point that's on the Internet? • How does Chatter allow users to control and limit the messages that they see, to help them cope with large numbers of nearby users? What are the default settings, and why do they make sense? • How would your design cope with success: what would happen if millions of
View Full Document
Unlocking...