Introduction
基于TCP和UDP写一套可靠的网络通信协议，比较考察Linux网络编程的基本功底。
Linux网络编程，虽然网上例子很多，但是基本上没有对各类异常和各种信号的处理，对于编写应用程序来说并不靠谱。
Goal and learning objectives
For this assignment, you will be asked to implement a reliable transport
protocol over the UDP protocol. We will refer to the reliable transport
protocol that you will be programming in this assignment as Simple Transport
Protocol (STP). STP will include most (but not all) of the features that are
described in Sections 3.5.4 and 3.5.6 of the text Computer Networking (6th
ed.). Examples of these features include timeout, ACK, sequence number etc.
Note that these features are commonly found in many transport protocols.
Therefore, this assignment will give you an opportunity to implement some of
these basic features of a transport protocol. In addition, you may have
wondered why the designer of the TCP/IP protocol stack includes such feature-
less transport protocol as UDP. You will find in this assignment that you can
design your own transport protocol and run it over UDP. This is the case for
some existing multimedia delivery services in the Internet, where they have
implemented their own proprietary transport protocol over UDP.
Note that it is mandatory that you implement STP over UDP. Do not use TCP
sockets. You will not receive any mark for this assignment if you use TCP
socket.
Learning Objectives
On completing this assignment you will gain sufficient expertise in the
following skills:
- Detailed understanding of how reliable transport protocols such as TCP function.
- Socket programming for UDP transport protocol.
- Protocol and message design.
Overview
As part of this assignment, you will have to implement Simple Transport
Protocol (STP), a piece of software that consists of a sender and receiver
component that allows reliable unidirectional data transfer. STP includes some
of the features of the TCP protocols that are described in sections 3.5.4 and
3.5.6 of the textbook (6th edition). You will use your STP protocol to
transfer simple text (ASCII) files (examples provided on the assignment
webpage) from the sender to the receiver. You should implement STP as two
separate programs: Sender and Receiver. You only have to implement
unidirectional transfer of data from the Sender to the Receiver. As
illustrated in Figure 1, data segments will flow from Sender to Receiver while
ACK segments will flow from Receiver to Sender. Let us reiterate this, STP
must be implemented on top of UDP. Do not use TCP sockets. If you use TCP you
will not receive any marks for your assignment.
You will find it useful to review sections 3.5.4 and 3.5.6 of the text. It may
also be useful to review the basic concepts of reliable data transfer from
section 3.4.
Assignment Specifications
This section gives detailed specifications of the assignment. There are two
versions of this assignment, a standard version (with a total of 15 marks) and
an extended version (with a total of 17 marks of which 2 marks are bonus
marks). The specifications for the extended version can be found in Section 5
of the specification. Note that the bonus marks may not be proportional to the
amount of extra work that you will have to do. They are there to encourage you
to go beyond the standard assignment. The bonus marks can be used to make up
for lost marks in the lab exercises and the second assignment but NOT for any
of the exams (mid-session and final).
File Names
The main code for the sender and receiver should be contained in the following
files: sender.c, or Sender.java or sender.py, and receiver.c or Receiver.java
or receiver.py. You are free to create additional files such as header files
or other class files and name them as you wish.
List of features provided by the Sender and Receiver
You are required to implement the following features in the Sender and
Receiver:
- A three-way handshake (SYN, SYN+ACK, ACK) for the connection establishment. The ACK sent by the sender to conclude the three-way handshake should not contain any payload (i.e. data). See Section 3.5.6 for further details.
- The four-segment connection termination (FIN, ACK, FIN, ACK). The Sender will initiate the connection close once the entire file has been successfully transmitted. See Section 3.5.6 for further details.
- Sender must maintain a single-timer for timeout operation (Section 3.5.4 of the text).
- Sender should implement all the features mentioned in Section 3.5.4 of the text, with the exception of doubling the timeout. The STP protocol must include the simplified TCP sender (Figure 3.33 of the text) and fast retransmit (pages 247-248). You will need to use a number of concepts that we have discussed in class, e.g., sequence numbers, cumulative acknowledgements, timers, buffers, etc. for implementing your protocol.
- Receiver should implement the features mentioned in Section 3.5.4 of the text. However, you do not need to follow Table 3.2 for ACK generation. All packets should be immediately acknowledged, i.e. you do not have to implement delayed ACKs.
- STP is a byte-stream oriented protocol. You will need to include sequence number and acknowledgement number fields in the STP header for each segment. The meaning of sequence number and acknowledgment number are the same as TCP.
- MSS (Maximum segment size) is the maximum number of bytes of data that your STP segment can contain. In other words, MSS counts data ONLY and does NOT include header. Sender must be able to deal with different values of MSS. The value of MSS will be supplied to Sender as an input argument.
- Another input argument for Sender is Maximum Window Size (MWS). MWS is the maximum number of un-acknowledged bytes that the Sender can have at any time. MWS counts ONLY data. Header length should NOT be counted as part of MWS.
Remarks: Note that TCP does not explicitly define a maximum window size. In
TCP, the maximum number of un-acknowledged bytes is limited by the smaller of
receive window and the congestion control window. Since you will not be
implementing flow or congestion control, you will be limiting the number of
un-acknowledged bytes by using the MWS parameter. In other words, you will
need to ensure that during the lifetime of the connection, the following
condition is satisfied. - Even though you will use UDP since the sender and receiver will mostly be running on machines that are within close proximity of each other (e.g.: on the same Ethernet LAN or even on the same physical machine), there will be no real possibility of datagrams being dropped. In order to test the reliability of your protocol, it is imperative to introduce artificially induced packet loss and delays. For this purpose you must also implement a Packet Loss and Delay (PLD) Module as part of the Sender program. The details for this module are explained later in the specification.
Remarks: For the standard version of the assignment, the PLD module will only
need to drop packets while for extended version, the PLD module will need to
drop and delay packets. For simplicity, I have chosen to call both of them the
PLD module, even though the PLD module for the standard version does not delay
packets. - You must use a constant timeout in your program. The value of the timeout will be supplied to Sender as an input argument. Note that, this requirement applies to the standard version of the assignment. The extended version has a different requirement.
Features excluded
There are a number of transport layer features adopted by TCP that are
excluded from this assignment:
- You do not need to implement timeout estimation unless you want to attempt the extended version of the assignment.
- You do not need to double timeout interval unless you want to attempt the extended version of the assignment.
- You do not need to implement any flow nor congestion control.
- STP does not have to deal with corrupted packets. Packets will very rarely be corrupted in our test topology, if at all. In short, it is safe for you to assume that packets are only lost.
Packet header and MSS
In designing the segment header, you only need to include the fields that you
think are necessary for STP. You can draw inspiration from TCP but the exact
format of the STP packet header is for you to decide. The header portion can
include as many fields as you think are necessary. Two important fields that
will be needed are the sequence number and acknowledgement number. You will
also need a number of flags for connection establishment and teardown.
The data portion must not contain more than MSS bytes of data. You must use
the same STP segment format for data transfer as well as for the
acknowledgements flowing back from the receiver to the sender. The only
difference will be that the acknowledgement segments will not contain any
data. All information that is necessary for the proper functioning of your
protocol must be provided in the STP headers. You should not use any
information from the header of the UDP datagram that will encapsulate the STP
packets.
Sender
This section provides details on the Sender.
For the standard version of the assignment, the Sender should accept the
following eight (8) arguments (note that the last two arguments are used
exclusively by the PLD module):
- receiver_host_ip: the IP address of the host machine on which the Receiver is running.
- receiver_port: the port number on which Receiver is expecting to receive packets from the sender.
- file.txt: the name of the text file that has to be transferred from sender to receiver using your reliable transport protocol.
- MWS: the maximum window size used by your STP protocol in bytes.
- MSS: Maximum Segment Size which is the maximum amount of data (in bytes) carried in each STP segment.
- timeout: the value of timeout in milliseconds. The following two arguments are used exclusively by the PLD module:
- pdrop: the probability that a STP data segment which is ready to be transmitted will be dropped. This value must be between 0 and 1. For example if pdrop = 0.5, it means that 50% of the transmitted packets are dropped by the PLD.
- seed: The seed for your random number generator. The use of seed will be explained in Section 4.5.2 of the specification.
Receiver
The Receiver should accept the following two arguments:
- receiver_port: the port number on which the Receiver will open a UDP socket for receiving datagrams from the Sender.
- file.txt: the name of the text file into which the text sent by the sender should be stored (this is the file that is being transferred from sender to receiver).
The Receiver should generate an ACK immediately after receiving a data
segment. This is the only ACK generation rule you need. You do not need to
follow Table 3.2 of the text. In other words, you do no have to implement
delayed ACKs. The format of the acknowledgement segment must be exactly
similar to the STP data segment. It should however not contain any payload.
The receiver is expected to buffer out-of-order arrival packets.
The receiver should first open a UDP listening socket on receiver_port and
then wait for segments to arrive from the Sender. The first segment to be sent
by the Sender is a SYN segment and the receiver is expected to reply a SYNACK
segment.
After the completion of the three-way handshake, the receiver should create a
new text file called file.txt. All incoming data should be stored in this
file. The Receiver should first extract the STP packet from the arriving UDP
datagrams and then extract the data (i.e. payload) from the STP packet. Note
that, the Receiver is allowed to examine the header of the UDP datagram that
encapsulates the STP Packet to determine the UDP port that the Sender is
using.
The data should be written into file.txt. At the end of the transfer, the
Receiver should have a duplicate of the text file sent by the Sender. You can
verify this by using the diff command on a Linux machine (diff file1.txt
file2.txt).
The Receiver should also maintain a log file titled Receiver_log.txt where it
records the information about each segment that it sends and receives. The
format should be exactly similar to the sender log file as outlined in the
Sender specification.
