A significant component of this class is implementing networking software. You are required to implement all of the software in C or C++, to get your C skills sharpened up and to get an understanding of the interface to the OS's networking facilities at a lower level than you might get if you used Java or some other language. The material and support provided for these assignments will assume that you are using the sockets API on Unix (probably Linux) to implement the programs. If you have a problem working on Linux and want to try this on a different OS, like Windows or OS X, the API should be similar enough that this will be possible, and I will allow it. Be aware, however, that neither I nor Anthony is going to be well versed on these alternatives, so you might not get much help if you run into problems.

The following is a brief list of the programming assignments; it will be filled in as the semester progresses. Each entry has a link to a more complete description of the program. Programs and any associated materials should be emailed to Anthony by the end of the day on the due date - end of day means 11:59 PM. Programs will be due on Friday, so that everyone will have an opportunity during a lab session to get some help, if required. I'm going to tell you the same thing all your other CS teachers tell you - don't leave the assignment until the night before. Try to get started on it, so you can take advantage of the opportunities to get assistance from Anthony or myself.

Programming Assignments

#	Topic	Due Date
1	POP3 client	Sep. 16
2	UDP Card Dealer server	Oct. 3
3	TCP Card Dealer server - non-blocking I/O, polling	Oct. 10
4	TCP Card Dealer server - select	Oct. 17
5	TCP Card Dealer server - child processes	Oct. 31
6	TCP Card Dealer server - asynchronous I/O	Nov. 14
7	Using broadcast to locate a server	Nov. 21
8	TCP Card Dealer server - threads	Dec. 9

WARNING: As these programs progress, you will be starting multiple processes and doing some other things that might cause some discomfort to the computer on which they are running if they get out of control. If this computer happens to be esus, this will tend to annoy the other users of the machine. To prevent this, make sure you do NOT run these programs on esus. Use one of the Linux machines in the lab or your own box. If you need to be able to work from off-campus or somewhere else where you don't have a development machine, you should be able to log into esus, then ssh to one of the lab machines. This can be a little problematic - you will need to experiment to find a machine that's booted up in Unix. You can use the command

showmount | grep cslab