In
this programming assignment you would build a connection-oriented reliable
transport protocol (UTCP, User-level TCP) on top of the standard Universal
Datagram Protocol (UDP). This
assignment would also be done in groups of exactly 2 people. You are
however free to change your partners from the previous assignment. This programming assignment would be done in
C language on Unix Operating System using the socket API. This we believe would give a real flavor of
network programming.
The
basic requirements that need to be satisfied by UTCP are the following.
1. Connection
Orientation: Applications using the UTCP should be able open persistent
connections between two entities specified by port number and IP address.
2. Reliable Message
Delivery: Messages sent by the
application must be delivered at the other end.
3. In-Order
Delivery: Messages sent must be delivered in the same order at the
destination.
4. Duplicate
Suppression: No message may be delivered more than once to the destination.
5. Flow Control:
The message stream from the sender to the receiver should be controlled so that
the receiver is not bombarded by messages.
Basically,
this assignment involves building a reliable connection on top of an unreliable
datagram protocol (UDP J).
The underlying channel can corrupt packets, drop packets, arbitrarily delay
some packets and might produce duplicate copies of the same packet. The protocol you design must be robust
enough to handle each of these problems.
Satisfying these requirements would involve implementation of a sliding-window protocol. You are free to design any suitable protocol to guarantee these requirements. However, we expect that your protocol would involve pipelining to improve throughput. You would be using unreliable datagram sockets as the underlying layer. For an introduction to socket programming see Unix Network Programming by Richard Stevens. In addition, you would also need other mechanisms such as asynchronous I/O.
Please note that we would continuously add to this page any updates so as to clarify the requirements of this assignment. However, the specifications would not be altered so you can start working on this assignment at the earliest.
In
order make it easier for the graders; we expect that you export a specific
interface to the application. This
interface is completely defined in the file “utcp.h”. The required interface includes 8 functions and 1 macro
definition. Robustness of the
implementation is very important. Appropriate intimation of errors and recovery
from errors, graceful termination of the program, etc. are important and would
also carry points.
For
the sake of making your work easier and the grader’s work lighter, we are
providing you with a set of utility files.
The following is a synopsis of these tools. For a detailed view, see the
documentation associated with these tools.
Sample Application:
The files “sampleServer.c” and “sampleClient.c” give example client-server
programs that use the interface specified in “utcp.h”. This sample application is a simple client
server program where the client sends keyboard inputs to the server and prints
out the server response and the server merely echoes back the messages sent by
the client.
Event Timer: This is a tool that helps you set timed
events. That is, you can define events
to be called in the future (example timeout).
The events are defined as a function that would be called at the time
specified by a delay factor. You can
also specify argument to be called to that function at the time of
invocation. We strongly recommend and
require that you use this tool for setting retransmission timers.
Evil Channel: This is a
tool that is built to mimic an unreliable channel at the user level. This tool
corrupts packets, drops packets, introduces arbitrary delay for certain packets
and creates duplicate copies of packets.
The evil channel can be invoked by replacing the socket sendto with
the evilsendto function defined by this tool. This makes it very flexible as you can work with UDP sockets and
finally use this tool for testing. The file “evil.config” specifies the
parameters for the evil channel.
Check Sum: A simple function to
compute checksum on a packet is also included.
utcp.c: This file provides a
dummy implementation of the interface specified above using datagram sockets.
The sample application can be successfully tested using this dummy implementation
as long as the channel is not evil.
Directly modifying this program would be a good starting point. The utcp.h file has a sample packet
definition that goes with this dummy implementation. You are free to redefine
appropriately.
Also for your convenience, we have included a “headers.h” that includes most commonly used header files for network programming.
The
utility imitating an evil channel should be very useful to test the robustness
of your protocol. You can use this tool
to introduce selected errors in the channel by varying the parameters in
“evil.config”. The graders would also
be using the same tool at the time of testing.
So please do not alter the implementation of evil channel. In addition, the graders would also build a
test application to test the integrity of the program. This test application
would also use the same interface specified before.
In
addition to the specified requirements you can attempt to provide the following
additional functionalities for extra credit.
However, the extra credit will be considered only if your assignment
already satisfies the basic requirements.
Compliance to the interface is obligatory! Before submission make sure that the sample client-server can successfully execute with no changes, at least when there are no packet loss in the channel. Any additional interface exported would be ignored. You would be expected to submit the following files before the due date.
1. Program Files: These files (.h, .c) would contain the code for the various functions defined in the interface in addition to the helper files provided.
2. README.txt: This file would specify the names and netids of the partners and give brief compile and execute instructions and a brief list of unfixed bugs. Also list all the features that deserve extra credit. The graders would not notice this (of course they would notice the bugs J) unless you specify them here.
3. DESIGN.txt: In this file please explain concisely the approach of your design to satisfy each of the requirements. If you are using well-described methods, then please provide only the name and a reference in the textbook.
As
specified in the section on testing, we would write a short application, in
addition to the sample application, based on the interface defined in “utcp.h”
to grade your programs. The evilSend
tool would be used to simulate an unreliable channel. The graders prefer to grade the programs by using test
applications rather than looking at the code.
Hence, a correctly functioning stop-wait protocol may be awarded more
points than a broken go-back-n protocol.
Therefore please make sure that the required features are correctly
implemented before attempting implementation of new features. Also, points would be awarded for
robustness of the implementation.
Please take care to handle exceptions and terminations gracefully.
The programs supplemented with this assignment have been extensively tested. Yet, there could be undiscovered bugs in the program. So please report any bugs promptly to the course staff. The following updates have been made to the helpfiles.
03/28/02 2:40 p.m.
· “utcp.c”: The return type of function utcpAccept is changed to connIdType (earlier it was bindIdType). The definition in “utcp.h” is correct.
· “sampleServer.c”: The calls to utcpClose(bindId) have been deleted in all its occurrences.
04/04/02 8:20 p.m.
· “eventTimer.c”: The problem with eventTimerQuit function has been fixed.
04/04/02 11:40 p.m.
· “eventTimer.c”: A minor bug when NULL args is passed to setEvent has been fixed.
· “cksum.c”: This function was has been modified slightly to reflect standard variable names. The core functionality and interface remains the same.
04/05/02 12:40 p.m.
· “evil.c”: In the function evilSend, sigblock(SIGALRM) changed to sigblock(sigmask(SIGALRM)).
04/10/02 2:20 a.m.
· “eventTimer.c”: In the function handleSigAlrm, macro call to TIMECMP is changed.
· “eventTimer.c”: In the function handleSigAlrm, definition of ‘handler’ variable is changed.
· “cksum.c”: In the function in_cksum, definition and use of ‘ptr’ variable corrected.
04/10/02 5:00 p.m.
· “eventTimer.c”: In the function handleSigAlrm, assert (eventQ.next != null) is changed to return without doing anything.
· “eventTimer.c”: The above update also applies to thread-safe eventTimer.c.
04/11/02 4:40 p.m.
· “evil.c”: In the function evilsendto, msg[randomByte] = ~msg[randomByte] is added after sending corrupted packet.
· “evil.c”: The above update also applies to thread-safe evil.c.
The following links provide some information about the socket programming interface and other useful functions.
ftp://gaia.cs.umass.edu/cs653_1996/sock.ps
http://www.ecst.csuchico.edu/~chafey/prog/sockets/
http://www.mcsr.olemiss.edu/unixhelp/
http://www.kohala.com/start/unpv12e.html
(contains source code for sample programs in Steven’s)
However,
the best help would be to look up the man pages of specific functions. An
Internet search on any function would provide its manual page.