EECS 122 project assignment (fall 1999)

Students will work in teams to implement a transport layer that provides reliable one-way bytestream service on top of an unreliable packet service.

Due date: transport.c is due by 3pm on 1999-Dec-17-Fri via email to both TAs: Hakan Dogan <dogan@cory.eecs.berkeley.edu> and Socrates Vamvakos <sokratis@eecs.berkeley.edu>. In addition, if you'd like confirmation that we have received it, you can send a third copy to <eecs122@arwen.cs.berkeley.edu> and view a summary of all messages stored in that mailbox. Be sure to put the names of all team members in comments near the top of the file. Be sure it uses only standard C, no operating system features or compiler extensions. There will be a 5% penalty for each hour (or partial hour) of lateness, so plan to send them early.

The TAs originally planned to interview each team, but instead the teams will answer a short questionaire asking the same sort of questions they would have been asked in the interview. The questionaire is designed to replace a 15 or 20 minute interview, so it should not take much time to answer. Mail the questionaire to the same addresses you mail transport.c (but in a separate message).

Each team may have from one to four members. Each project will be graded without regard to team size, and every member of the team will receive the same grade.

We provide C interfaces between the network and transport layers, and between the transport layer and the upper layers. In real life, there is an interface between the transport layer and the operating system, and between the user applications and the operating system, but we will use a simulation framework that simulates just enough of the upper layers to drive the transport layer. Source code appears below. Although only transport.c will be turned in, teams should write a variety of network layers and application layers to test their transport layer.

There are a basic project assignment and three optional extra-credit extensions. Each team may elect to do none of the extensions, or any combination of them. The extensions will be graded separately from the basic project. Final course grades will be initially assigned without including the extensions, then adjusted upward to include any extra credit.

Important advice: Make sure you get something working that satisfies the requirements of the basic project before worrying too much about the extensions. If you run out of time, it's best to turn in something that at least gets all the bytes across.

basic project (15%)
The transport layer must provide a one-way reliable bytestream connection. Only one connection will be open at a time, though after it is closed another may be opened. The transport layer need not perform connection setup; both endpoints will be told the identity of the other endpoint.

extension: flow control and efficiency (10%)
The connection must be flow-controlled, meaning that the source must not send data that the sink cannot acknowledge for lack of buffer space. The source and sink will both be told the maximum amount of application data that they are allowed to buffer for the connection.

The protocol must also be reasonably efficient, meaning that in the absence of transmission errors, and given fast application layers, it should transfer at close to the theoretical maximum rate, which is B per round-trip, where B is the lesser of the source's and sink's buffer limits.

extension: multiplexing (5%)
The transport layer must support multiple simultaneous one-way connections between the same pair of hosts, and between one host and several other hosts.

extension: congestion control (10%)
The transport source must adapt its rate to the available network capacity (which can vary over the lifetime of the connection) to avoid excessive packet drops. If multiple connections are contending for the same network resources, they should divide the resources fairly, meaning they should all get roughly the same share of bandwidth, or roughly the same share of storage, or somewhere in between. (Even if a team does not do the multiplexing extension, we'll probably have a way of running their code multiple times concurrently to make it compete with itself.) We understand that adding congestion control may cause a protocol's efficiency to drop by a factor of two or so.

Source code

all in one file: source.tar.gz

individual files:
Overview:
README 0.2.1 (1999-Dec-05-Sun)

Interface you must implement (do not change this):
transport.h 0.4.1 (1999-Dec-15-Wed)

Interfaces that transport.c can depend on (do not change these):
bytestream.h 0.2.0 (1999-Nov-13-Sat)
crc32.h 0.0.0 (1999-Oct-17-Thu)
integer.h 0.0.0 (1999-Oct-17-Sun)
network.h 0.2.2 (1999-Dec-05-Sun)
random.h 0.0.0 (1999-Oct-13-Wed)
timer.h 0.2.0 (1999-Nov-13-Sat)
warnf.h 5.0.0 (1999-Oct-02-Sat)

Code we will link with transport.c (do not change these):
crc32.c 0.0.0 (1999-Oct-17-Thu)
integer.c 0.0.0 (1999-Oct-17-Sun)
random.c 0.0.2 (1999-Dec-07-Tue)
warnf.c 5.0.2 (1999-Dec-06-Mon)

Example code (use it, change it, or ignore it, but transport.c must not depend on it):
deliver_packet.h 0.0.0 (1999-Nov-12-Fri)
event.c 0.2.0 (1999-Dec-16-Thu)
main.c 0.0.1 (1999-Nov-28-Sun)
Makefile 0.4.1 (1999-Dec-18-Sat)
network.c 0.2.5 (1999-Dec-19-Sun)
network_config.h 0.2.0 (1999-Dec-19-Sun)
runtest.c 0.3.5 (1999-Dec-20-Mon)
streamers.c 0.3.0 (1999-Dec-18-Sat)
streamers.h 0.3.0 (1999-Dec-18-Sat)
test 0.1.8 (1999-Dec-20-Mon)
tester.c 0.0.0 (1999-Dec-16-Thu)
timer_expire.h 0.1.0 (1999-Dec-16-Thu)
transport.c 0.4.0 (1999-Dec-09-Thu)

[AMC]  Prepared by Adam M. Costello
 Last modified: 1999-Dec-21-Tue 20:15:07 GMT
[Any Browser]