(comments before the course was taught (Fall, 2000)--course plans.  for post-course comments, see below)
CS 430/594 UNIX Network Programming (Fall, 2004) will be a programming-intensive course focussing on the implementation of a simplified TCP/IP stack. Text: Stevens' UNIX Network Programming volume I. Networking basics, the TCP/IP stack, gateways, routing, etc. We provide a virtual LAN and virtual Internet (implemented through sockets). Students work in small groups and first write a simple IP layer to interact with the virtual network--the IP will call the virtual LAN, passing it the address of a message buffer and the next hop to deliver the message to, etc. Then will come the addition of UDP and TCP layers (IP, UDP, and TCP will be separate threads, same process ID), then applications will be added as separate processes, interacting with the UDP and TCP threads via UNIX domain sockets. Finally, each LAN will have a designated gateway, and thus LANs will be able to communicate with each other. Prerequisites: CS 360 or the equivalent, programming implementations of sockets and threads is assumed.

(for the web page with lab FAQs-->>CS 430/594 UNP

(post-course comments)
We had about 40 students, about 13 groups of 2-4 students each.  Florence Fowler wrote VNET--
this acted like a plug-in network card, such as an Ethernet card.  The students' IP layer interfaced with this
card in almost exactly the same way that the real IP interfaces with a real Ethernet (or FDDI, etc) card.  VNET
delivered packets (reliability could be adjusted) to the VNET "card" on another host.  We specified the IP/VNET
interface protocols, trying to keep these as close to real life as possible.  In effect, a host might have several network
connections to other hosts/several network cards.This became more important when we later added routing.   The
students wrote an IP layer,so that VNET and IP ran as separate threads--this avoided signals, which had caused
some problems previously.  We decided to skip the TCP layer--to do so would have required another
half-semester.  So the students then added a UDP layer--but designed so that a TCP layer could
have been added--we were trying to maintain the functionality of the real TCP/IP suite.  Protocol
Control Blocks were needed here.  The students then had the toughest lab of the semester--adding
a socket layer on top of UDP.  We specified the application/socket interface--keeping very close to
the real UDP socket function calls.  So we specified the application/socket interface and the IP/VNET
interface, but not the socket/UDP or the UDP/IP interfaces, and thus we had a situation not unlike that of dll's for
the PC.  We did, however, require various details in order to keep the development
reasonably close to what goes on with a real TCP/IP implementation.  Students could not, therefore,
swap UDP layers between groups--we considered having carefully specified protocols, but chose
not to do so, and thus we had some interesting variety in the approaches.

We did require that the IP and UDP headers be identical to real-world IP and UDP headers, although
some of the fields were never used (e.g. type of service, fragmentation, etc).  We kept the real-life
UDP protocol number for the IP packet, for example.  For the socket interface, we kept the real UDP
socket calls, but had them starting with a cap--e.g. "Socket" rather than "socket", with the same
fields.  An application with a regular "socket" call would have invoked the real UDP rather than the
students' UDP.  Consequently, underneath the "Socket" call we had UNIX domain sockets which
communicated between the application process and the UDP thread of the "kernel" process in the
students' code.  For application processes, student groups wrote a variety of things--such as a
DNS, TFTP, ping, etc.  Ideally, one group's ping should have been able to work with another group's
TCP/IP suite--mostly this worked OK, but not always.

For routing, each group set up a small system of 5 networks, with 3 routers connecting the networks.
Each IP layer had a routing table--this told VNET which interface/"network" to deliver the packet
on.  We used static routing here.  See the diagram for lab 5 for the topology.  So a TFTP application
on host X would use sockets to go through the UDP layer to IP, and the IP layer would have to refer
to its routing table to see what to tell VNET about delivery--i.e. what host, what network.  The
packet went out across a network to a router--to the IP layer there, back to VNET, etc, until it
reached the destination host.  Lab 6 added dynamic routing--modelled on IGRP--as a distance-
vectored protocol running at the IP layer.  Each network (actually the 5 networks for lab 5) now had
a gateway--the gateway needed to maintain the dynamic routing info. 

So we basically had an
autonomous system (AS) with a border gateway/router.  Each gateway had 3 connections to other
gateways, and we had a topology for all the groups that meant that the D-V advertising grew the
table in an interesting fashion.  We made extensive use of subnets and subnet masks for all the
routing, both static and dynamic.  So ultimately, one could go from a UDP client on group #1's host X
across group 1's AS, out their gateway, through other gateways to group 7's gateway, across their
AS to host Y, and thence to the UDP server on host Y.

About 10 of the 12 groups got things working through dynamic routing.  Code in many cases ran
about 5K lines of C.