CS 340 Project Part B Dinda, Winter 2003 Page 1 of 6 TCP for Minet Project Part B Overview In this part of the project, you and your partner will build an implementation of TCP for the Minet TCP/IP stack. You will be provided with all parts of the stack except for the TCP module. You may implement the module in any way that you wish so long as it conforms to the Minet API, and to the reduced TCP standard described here. However, Minet provides a considerable amount of code, in the form of C++ classes, that you may use in your implementation. You may also earn extra credit by implementing additional parts of the TCP standard. The Minet TCP/IP Stack The Minet TCP/IP Stack is documented in a separate technical report. The low-level details of how Minet works, including the classes it makes available to you, the modules out of which the stack is constructed, and how the modules interface with each other is documented there. Of course, it also doesn’t hurt to look at the code. You will be given the source code to all of the Minet modules except for tcp_module and ip_module. You will find udp_module.cc quite helpful to begin. You will also receive binaries for ip_module, reader, and writer. It is vital that you use the driver2.sh script in /usr/local/bin. This program, which lets you send and receive raw Ethernet packets, must be run as root or else it will not work. Because we don’t want to give you root access, we are giving you this sudo script, meaning that when you run it, it runs as root. If you would like to use driver2.sh on a machine outside the TLAB, you will need root privileges on that machine. Your IP Addresses Each project group was assigned 255 IP addresses to use for the rest of the quarter. These address are of the form 10.10.x.y, where x will depend on your group id and y will range from 1 to 255. These addresses are special in that packets sent to them will not be forwarded beyond the local network. In fact, if you are using machines other than the TLAB machines, you will need to add a route so that they actually make it to the local network. Dedicated TLAB Machines You may use any of the TLAB machines, either from the console or remotely via ssh. In fact, you’ll usually want to use two of them simultaneously. We have dedicated TLAB-11 through TLAB-15 to running Linux for the duration of the quarter. These machines should always be available for remote or console login. If they are not, send mail to [email protected] 340 Project Part B Dinda, Winter 2003 Page 2 of 6 TCP Specification The core specification for TCP is RFC 793, which you can and should fetch from www.ietf.org. In general, you will implement TCP as defined in that document, except for the parts listed below. • You only need to implement Go-Back-N • You do not have to support outstanding connections (i.e., an incoming connection queue to support the listen backlog) in a passive open. • You do not have to implement congestion control. • You do not have to implement support for the URG and PSH flags, the urgent pointer, or urgent (out-of-band) data. • You do not have to support TCP options. • You do not have to implement a keep-alive timer • You do not have to implement the Nagle algorithm. • You do not have to implement delayed acknowledgements. • You do not have to generate or handle ICMP errors. • You may assume that simultaneous opens and closes do not occur • You may assume that sock_module only makes valid requests (that is, you do not have to worry about application errors) • You may assume that exceptional conditions such as aborts do not occur. • You should generate IP packets no larger than 576 bytes, and you should set your MSS (maximum [TCP] segment size) accordingly, to 536 bytes. Notice that this is the default MSS that TCP uses if there is no MSS option when a connection is negotiated. Chapter 3 of your textbook also serves as an excellent introduction to TCP concepts and should be read before the RFC. You will also find the TCP chapters in Rick Steven’s book, “TCP/IP Illustrated, Volume1: The Protocols” extremely helpful. They will show you what a working stack behaves like, down to the bytes on the wire. Make sure that you read about and understand the TCP state transition diagram in 18.6. Recommended Approach There are many ways you can approach this project. The only requirements are that you meet the TCP specification detailed above, that your TCP module interfaces correctly to the rest of the Minet stack, and that your code builds and works on the TLAB machines. We recommend, however, that you use C++ and exploit the various classes and source code available in the Minet TCP/IP stack. Furthermore, we recommend you take the roughly the following approach. 1. Read Chapter three of your textbook 2. Skim RFC 793 and the Stevens chapters. 3. Read the “Minet TCP/IP Stack” handout. 4. Fetch, configure, and build Minet if you have not already done so. For this project, build Minet using “make project_b”. It is important that you use /usr/bin/g++.CS 340 Project Part B Dinda, Winter 2003 Page 3 of 6 5. Examine the code in tcp_module.cc and udp_module.cc. The TCP module is simply a stub code that you need to flesh out. It just connects itself into the stack at the right place and runs a typical Minet event loop. UDP module is a bit more fleshed out. It has almost exactly the same interface to the IP multiplexor and to the Sock module as your TCP module will have. 6. Extend the TCP module so that it prints arriving packets and socket requests. You should be able to run the stack with this basic module, send traffic to it from another machine using netcat (nc), and see it arrive at your TCP module. You may find the classes in packet.h, tcp.h, ip.h, and sockint.h to be useful. Now is a good time to familiarize yourself with Minet’s various environment variables. You should check out what the various MINET_DISPLAY options do. 7. Learn how to use MinetGetNextEvent’s timeout feature. You will be using this to implement TCP’s timers. 8. Write a class that represents the state of a connection. Think carefully about what this should contain. Think of a connection as being a finite state machine and consider using the states described in RFC 793. You may find the various classes in constate.h to be helpful here. In particular, your connection should have