For the last half of the semester, you'll work on a large programming project: implementing a simplified 802.11 link layer atop the broadcast RF services you used for the last assignment. (The details of the system you must implement are found in the 802.11~ Specification document.) Our 802.11~ has simplified many aspects of 802.11 to limit the project's complexity, but it is still a large and complex project and it is essential that you think clearly about the design of your implementation before starting to write code. To make sure that you don't skip the design phase, I'm requiring that you turn in a description of your design before starting. This handout describes several design issues that need to be addressed and tells you what to turn in for inspection. As you work through this assignment, keep in mind that the more detailed you are, the more input you can get from me on your design.
Luckily, you're all now masters of the threaded universe! You can use threads to run any 802.11~ code that needs to execute indepenently from the application. You can start one or more threads when your 802.11~ layer is initialized and have them watch for incoming packets and carry out whatever other housekeeping chores need to be performed. Note, however, that the code implementing a given interface routine might be split between code that runs immediately as a result of the call, and code running in a thread. For example, if the layer above calls your 802.11~ layer's recv(), it immediately invokes a method in your code. If there is no data awaiting receipt, the call must block until data arrives — but the arriving data is likely to be noticed and processed by a separate thread watching for incoming data. How does the code in the thread interact with the code in the recv() call? How does the receive call know when it's ok to return? How do they manage the accesses to the shared data structures that hold incoming frames?
There are additional issues involved in implementing the MAC logic and timing. The process starts when the layer above calls send(), but then what? The send call should return immediately, regardless of the state of the shared channel, so how does your implementation keep track of where it is in the logic flow chart? If the channel's busy, how does your implementation wait for it to become idle? How does it wait for DIFS to elapse? How does it count down slots in the contention window, while still watching the state of the channel? How does it know to wait for an ACK, and what does it do if no ACK arrives? So many questions!
The easiest way to address the last group of questions is to devise a finite state diagram representing the status of your MAC layer, and transition between states as appropriate. (The book shows some state diagrams — Figure 3.11 on page 211, for example.) Nodes in a state diagram denote states where a system waits for something. Edges represent transitions between states, and are labelled with the condition that caused the move. State diagrams can help clarify a design and ease implementation — you can build the states and transitions directly into your implementation.
send() and recv() functions. Make it clear which activities are being carried out in threads, and which are done immediately once the function is called.
I'd appreciate electronic submissions on this one, even though there are diagrams involved. Either find an application that lets you draw the necessary diagrams, or do them by hand and scan or photograph them to get an electronic image. Please put your writeup, as a PDF, and your diagram in a folder, zip it up, and submit via Canvas.