Python代写-COMP3234A
时间:2021-04-05
Pa
ge
1

COMP3234A Computer and Communication Networks
Programming Project
Total 18 points
Version 1.0

Part 2 Due Date: 5pm April 7, 2021
Part 3 Due Date: 5pm May 3, 2021
Hand-in the assignment via the Moodle System.
Stop-and-Wait (rdt3.0) ARQ
and
Extended Stop-and-Wait (rdt4.0) ARQ

Overview
In this project, you are going to design and implement two reliable data transfer layers, one is based on
the Stop-and-Wait (rdt3.0) protocol and the other is based on the extended Stop-and-Wait (rdt 4.0)
protocol. Both RDT protocols support connectionless reliable duplex data transfer on top of unreliable
UDP. You can view the communication system has three layers. They are the Application layer, Reliable
data transfer layer, and Unreliable layer.

Sender
file transfer Application layer
rdt3.0 / rdt4.0 Reliable data transfer layer
UDP Unreliable layer

Receiver
Application layer file transfer
Reliable data transfer layer rdt3.0 / rdt4.0
Unreliable layer UDP



The Application layer invokes the service primitives provided by the RDT layer in order to send/receive
messages to/from remote application processes. Upon receiving a message from the Application layer,
the RDT layer encapsulates the application message with control header to form a packet and passes the
packet to Unreliable layer by invoking the service primitives exported by the Unreliable layer. The
Unreliable layer is responsible for sending the packets to the Unreliable layer of a remote peer process
by means of UDP packets. To simulate transmission errors, the Unreliable layer may randomly discard or
corrupt packets.

Objectives
1. An assessment task related to ILO4 [Implementation] – “be able to demonstrate knowledge in
using Socket Interface to design and implement a reliable data transfer protocol”.
2. A learning activity to support ILO1, ILO2a, & ILO4.
3. The goals of this programming project are:
• to get better understanding of the principles behind Stop-and-Wait protocol;
• to gain hands-on experience in implementing a reliable protocol;
Pa
ge
2

• to understand the performance difference between a pipelined protocol and the Stop-and-
Wait protocol;
• to gain experience in using socket functions to implement a real-life protocol.
Specification
This programming project consists of three parts:
• Part 1 [Warm up & no submission is required] – Assume UDP is reliable (i.e., the Unreliable layer is
indeed “reliable”), you are going to practice how to implement the RDT layer (rdt1.0) directly on top
of UDP with the wrapper functions __udt_send() and __udt_recv(). It is true UDP is reliable when
running the application within the local machine or in local area network .
• Part 2 [Submission] – Assume UDP is unreliable, which suffers with packet losses and transmission
errors. You are going to implement the RDT layer using Stop-and-Wait protocol (rdt3.0) on top of
the Unreliable layer but uses the wrapper function __udt_send() to simulate the loss and corruption
of UDP packet.
• Part 3 [Submission] – To improve the performance, you are going to implement a pipelined protocol
- Extended Stop-and-Wait (rdt4.0) protocol in the RDT layer (that replaces previous rdt3.0 protocol),
which works on top of the Unreliable layer.
PART 1 – NO SUBMISSION IS REQUIRED
The objective of Part 1 is to help you to get familiar with the RDT API. Please download the compressed
file – Part1.zip from the course web site at moodle.hku.hk. This zip file contains six files:
1. A python module file – rdt1.py, which implements all the functions provided by the RDT layer to the
application layer.
There are six functions in the API. They are:
rdt_socket() Application process calls this function to create the RDT socket.
rdt_bind() Application process calls this function to specify the IP address and port number
used by itself and binds them to the RDT socket.
rdt_peer() Application process calls this function to specify the IP address and port number
used by the remote peer.
rdt_send() Application process calls this function to transmit a message (up to a limit of
PAYLOAD bytes) to the targeted remote peer through the RDT socket; when
returned from this function, the caller can assume that the message has been
successfully delivered to the remote process.
rdt_recv() Application process calls this function to wait for a message from the targeted
remote peer; the caller will be blocked waiting for the arrival of the message. Upon
arrival of a message (of maximum size PAYLOAD bytes), the RDT layer will
immediately return the message to the caller.
rdt_close() Application process calls this function to close the RDT socket.
As we assume UDP is reliable, we do not need to implement any reliable protocol in this part; thus,
we simply complete most of the functions by using standard socket functions except rdt_send() and
rdt_recv(). To simulate the underlying unreliable layer, two internal functions are provided:
__udt_send() and __udt_recv(). They will be used by rdt_send() and rdt_recv() for sending and
receiving messages.
2. A pair of test files – test-client1.py and test-server1.py. These two programs require the rdt1.py
module file to compile and work correctly. This is the driver application of your RDT protocol as they
Pa
ge
3

make use of the functions provided by the RDT layer. The task of this driver application is to upload
a file from the client program to the server program and store the file at a pre-fixed storage location
(“Store”) at the server side.
The client program accepts two arguments:
python3 test-client1.py ‘server hostname’ ‘filename’
The server program accepts one argument
python3 test-server1.py ‘client hostname’
Before executing the server program, you should create the directory “Store” under the same
directory of the server program. The server program won’t start up if this directory is missing.
3. Three script files – (1) run-simulation1.bat for Windows, (2) run-simulation1-OSX.sh for Mac OSX,
and (3) run-simulation1-Ubuntu.sh for Ubuntu. By running the script file on corresponding platform,
the system creates two terminals for you and starts running the server and client programs in each
terminal for you. For example, to run the simulation on Windows, on a terminal, type: run-
simulation1.bat ‘filename’ (where the filename is the file to be transferred). For OSX, you may have
to set the execution bit of the shell program before running the shell: chmod 0755 run-simulation1-
OSX.sh.

Testing
Test the programs with three different file sizes: (i) small file (around 30 KB), (ii) moderate size (around
500 KB), and (iii) large file (around 10 MB).


PART 2 (9 POINTS) – SUBMISSION DEADLINE: APRIL 7 17:00
You are going to implement the RDT3.0 protocol in this part. Download the compressed file – Part2-
template.zip from the course web site at moodle.hku.hk. This zip file contains seven files:
1. Two test program files for part 2 – test-client2.py and test-server2.py. They are similar to the part 1
testing set except a few minor differences. They require rdt3.py module file to work correctly.
The client program accepts three arguments:
python3 test-client2.py ‘server hostname’ ‘filename’ ‘packet loss rate’ ‘packet error rate’
The server program accepts two arguments:
python3 test-server2.py ‘client hostname’ ‘packet loss rate’ ‘packet error rate’
2. Three script files – one for Windows, one for Mac OSX, and one for Ubuntu.
To start the simulation, you have to run the script with 3 arguments. For example, on the Windows
terminal, type: run-simulation2.bat ‘filename’ ‘packet loss rate’ ‘packet error rate’.
The packet loss rate and packet error rate are used by the __udt_send() function to control the
degree of packet loss and corruption respectively. If these two variables are set to 0.0; thus, the
system does not experience any loss or corruption. If their values are set to be greater than 0, this
means we want to simulate the loss and corruption. The higher the number, the higher the chance
of the errors / losses.
3. The module file – rdt3.py, which defines all functions provided by the RDT3.0 layer to the
application layer as well as three internal functions – __udt_send(), __udt_recv() and __IntChksum(),
and a few global variables. However, rdt3.py file is not completed. Your task in this part is to
complete rdt3.py file.
Same as rdt1.py, the service interface consists of seven functions: rdt_network_init(), rdt_socket(),
rdt_bind(), rdt_peer(), rdt_send(), rdt_recv() and rdt_close(). However, we have already completed
Pa
ge
4

the rdt_network_init() function. You are going to implement the Stop-and-Wait (rdt3.0) reliable
logic in these functions.
rdt_socket() Application process calls this function to create the RDT socket.
rdt_bind() Application process calls this function to specify the IP address and port
number used by itself and assigns them to the RDT socket.
rdt_peer() Application process calls this function to specify the IP address and port
number used by the remote peer.
rdt_send() Application process calls this function to transmit a message (up to a limit of
PAYLOAD bytes) to the targeted remote peer through the RDT socket. This
function will return only when it knows that the application message has been
successfully delivered to the remote peer.
rdt_recv() Application process calls this function to wait for a message from the targeted
remote peer; the caller will be blocked waiting for the arrival of the message.
Upon arrival of a message (of maximum size PAYLOAD bytes), the RDT layer will
immediately return the message to the caller.
rdt_close() Application process calls this function to close the RDT socket. However, before
closing the RDT socket, the reliable layer needs to wait for TWAIT time units
before closing the socket.

4. Part2-sample-output.pdf – We suggest you generating an output statement whenever the RDT layer
sends out or receives a packet (include the packet type and some control information in the output).
In addition, you can generate an output statement whenever the RDT layer detects or experiences
an expected event or unexpected event or error situation. Please refer this document for the sample
output.

Simulate Packet Losses and Corruptions
Although UDP is an unreliable transport service, we hardly encounter packet losses within a local
network. To test whether your rdt3.0 implementation is working correctly under erroneous situations,
we have to randomly generate loss or error events when transmitting UDP packets. One simple method
to simulate that is to use a wrapper function __udt_send(), which in turn, calls the sendto() function
with some probability of packet loss or corruption. In your implementation of rdt3.py, you are required
to use __udt_send() and __udt_recv() for sending and receiving messages in the rdt_send(), rdt_recv(),
and rdt_close() functions.

Checksum Calculation
As transmissions may suffer from corruption, you need to use an error detection method to detect
transmission errors. The Internet checksum algorithm is a good candidate for this exercise. We have
implemented the algorithm as an internal function – __IntChksum() for the project. Before transmitting
a packet, the system passes the packet to the checksum function to calculate a checksum value; then it
stores the checksum value in the packet’s header (no need to apply network-byte order conversion for
the checksum value). After receiving the packet, the system passes the packet to the checksum function
to determine whether it is corrupted or not. Please be remembered that the payload and the header of
the packet can be corrupted.

Stop-and-Wait (rdt3.0) protocol
The rdt_send() and rdt_recv() are the two functions that support reliable data transfer between the two
ends. Below diagrams show the finite state machines of the sender and receiver. In principle, you
implement the sender logic in rdt_send() function and the receiver logic in rdt_recv() function. However,
Pa
ge
5

please be aware that the sender and receiver may encounter events that are not covered in its FSM ;
e.g., a sender, while waiting for the ACK, may receive a data packet from its peer, or vice versa.

FSM of rdt3.0 Receiver











FSM of rdt3.0 Sender























Instead of passing application data directly to UDP using __udt_send() function, your protocol layer
needs to encapsulate application data by the RDT header to form the PDU of the reliable protocol.
Below diagram shows the message format of the reliable protocol.

Pa
ge
6

The protocol header consists of 4 fields: Type (size: 1 byte), Sequence no. (size: 1 byte), Checksum (size:
2 bytes), and Payload length (size: 2 bytes) (need network-order conversion). There are two types of
packets – data packets and ACK packets. Data packets carry application data in the Payload field, while
ACK packets do not have any payload. To differentiate between the two types, we use the Type field in
the header. This is the suggested setting of the Header fields:

Type ACK = 11, Data = 12
Sequence no. 0 or 1
Checksum Use __IntChksum() to calculate the checksum for the whole packet (Header + Payload)
Payload length 0 to 1000

Implementing rdt_close()
Our RDT layer is a connectionless reliable layer; thus, we don’t need to implement any connection set-
up procedure. However, a peer cannot close the RDT socket immediately after it finished all data
transfer; this is crucial to the sender. This is because the last ACK sent by a receiver may be lost or
corrupted; if a receiver closes its socket and leaves, nobody is going to handle the retransmitted packet
from the sender and the sender is forced to hang there forever.
We suggest that before a peer closes it RDT socket, the peer stays in the TIME_WAIT state for TWAIT
time units before closing the socket. In the TIME_WAIT state, the peer reacts to the retransmitted
packet by returning an ACK packet and then re-enters the TIME_WAIT state again. Only until the peer
does not receive any packets within TWAIT time units, it quits the TIME_WAIT state and closes the
socket.

Implementing Timeout
The sender needs to wait for the acknowledgment after it sent out a packet. The sender invokes
__udt_recv() function to wait for the acknowledgment; however, this function invokes the blocking
recvfrom() function call, which blocks the calling process until a message arrived. If the sender is
blocked, how can it react to the timeout event? A simple method is to use the socket timeout mode or
select.select() function. Although recvfrom() is a blocking function, by setting the socket with the
timeout mode, the function is set to block waiting for a fixed duration; thus, you can set this duration as
the timeout duration. Please refer to Workshop 2 worksheet on how to use the socket timeout mode or
select.select() function.

Testing
Test your programs with two different file sizes on any platform installed with Python 3: (i) small file
(around 30 KB), and (ii) large file (around 10 MB) with different combinations of packet loss rate and
packet error rate:
PACKET LOSS RATE PACKET ERROR RATE
0.0 0.0
0.2 0.0
0.0 0.2
0.2 0.2
0.3 0.3


Submission
You only need to submit the rdt3.py program. Submit the file to the Assignment Submission page for
Project Part 2 at moodle.hku.hk.
Pa
ge
7


PART 3 (9 POINTS) – SUBMISSION DEADLINE: MAY 3 17:00
You are going to implement the Extended Stop-and-Wait (rdt4.0) protocol in this part. Download the
compressed file – Part3-template.zip from course web site at moodle.hku.hk. Same as Part2-
template.zip, it contains seven files:
1. Two test program files for part 3 – test-client3.py and test-server3.py. They are similar to the parts 1
and 2 testing sets except for a few minor differences. They require rdt4.py module file to work
correctly.
The client program accepts four arguments:
python3 test-client3.py ‘server hostname’ ‘filename’ ‘packet loss rate’ ‘packet error rate’
‘window size’
The server program accepts three arguments:
python3 test-server3.py ‘client hostname’ ‘packet loss rate’ ‘packet error rate’ ‘window size’
2. Three script files – one for Windows, one for Mac OSX, and one for Ubuntu.
To start the simulation, you have to run the script with 4 arguments. For example, on the Windows
terminal, type: run-simulation3.bat ‘filename’ ‘packet loss rate’ ‘packet error rate’ ‘window size’.
The packet loss rate and packet error rate have the same meaning/usage as in Part 2. The window
size, which is an integer, defines the number of packets a sender can send before stop-and-wait for
the acknowledgments to come back.
3. The module file – rdt4.py, which defines all functions provided by the RDT4.0 layer to the
application layer as well as three internal functions – __udt_send(), __udt_recv() and __IntChksum(),
and a few global variables. However, rdt4.py file is not completed. Your task in this part is to
complete rdt4.py file.
Same as rdt3.py, the service interface consists of seven functions: rdt_network_init(), rdt_socket(),
rdt_bind(), rdt_peer(), rdt_send(), rdt_recv() and rdt_close(). We have completed the
rdt_network_init() function. You can reuse your implementation in Part 2 and just modify those
functions to include the Extended Stop-and-Wait (rdt4.0) reliable logic; in particular, rdt_send(),
rdt_recv(), and rdt_close().

rdt_send() Application process calls this function to transmit a message (up to a limit of W ×
PAYLOAD bytes) to the targeted remote peer through the RDT socket. This function
will return only when it knows that the whole message has been successfully
delivered to the remote peer.
rdt_recv() Application process calls this function to wait for a message from the targeted
remote peer; the caller will be blocked waiting for the arrival of the message. Upon
arrival of a message (which is carried in one packet), the RDT layer will immediately
return the message to the caller.
rdt_close() Application process calls this function to close the RDT socket. The behavior of this
function is the same as in part 2 except that a peer may receive retransmitted
packets with different sequence numbers.

4. Part3-sample-output.pdf - We suggest you generating an output statement whenever the RDT4.0
layer sends out or receives a packet (include the packet type and some control information in the
output). In addition, you can generate an output statement whenever the RDT layer detects or
experiences an expected event or unexpected event or error situation. Please refer to this
document for the sample output.
Pa
ge
8


Extended Stop-and-Wait protocol
The rdt3.0 Stop-and-Wait protocol allows only one packet in transit from the sender to the receiver, i.e.,
the sender waits for the acknowledgment before sending the next packet. The extended version of Stop-
and-Wait protocol allows a full window of packets to be in-transited before stop-and-wait for the
acknowledgments. The window size W is defined by the user; we use the rdt_network_init() function to
pass it to the RDT4.0 layer. Strictly speaking, the Extended Stop-and-Wait protocol is a pipelined
protocol, but it is not the traditional sliding window schemes (e.g., Go-Back-N and Selective Repeat)
since its window only slides forward after received all acknowledgments in the current window.

Below diagrams show the finite state machines of the sender and receiver. In principle, you implement
the sender logic in rdt_send() function and the receiver logic in rdt_recv() function. However, please be
aware that the sender and receiver may encounter events that are not covered in its FSM; e.g., a
sender, while waiting for the ACK, may receive a data packet from its peer, or vice versa.

FSM of E-S&W sender


Basically, the E-S&W sender responds to three types of events:
1. Call by application - invocation of rdt_send(). Based on the length of the message, the sender
determines how many packets (N) it is going to be transmitted in this round, and it is always true that
≤ . Each packet consumes a sequence number so as to uniquely identify a packet. After sent out
all N packets, the sender starts the Timeout timer and waits for all acknowledgments to come back.
2. Receipt of an ACK. In the E-S&W protocol, we adopt the cumulative acknowledgment approach. Each
ACK packet carried a sequence number k, which indicates that all packets with a sequence number up
to and including k have been correctly received by the receiver. Once the sender knows that all N
packets have been correctly received, it clears the Timeout timer and waits for call from above.
Pa
ge
9

3. A timeout event - If a timeout occurs, the sender resends all packets that have been previously sent
in this round but have not yet been acknowledged. One single Timeout timer is used for keeping track
of all N packets. If an ACK is received but there still have pending to be acknowledged packets, the
timer is restarted.

FSM of E-S&W receiver


The behavior of E-S&W receiver closely resembles the behavior of GBN receiver. If a data packet with
sequence number j is received correctly and j is the current expected in-order sequence number, the
receiver sends an ACK packet with sequence number j and delivers the data to the application layer.
Otherwise, the receiver discards that data packet and resends an ACK for the most recently received in-
order packet.

Testing
Test your programs with two different file sizes on any platform installed with Python 3: (i) small file
(around 30 KB), and (ii) large file (around 10 MB) with different combinations of packet loss rate and
packet error rate:
W PACKET LOSS RATE PACKET ERROR RATE
1 0.0 0.0
5 0.0 0.0
9 0.0 0.0
1 0.1 0.1
5 0.1 0.1
9 0.1 0.1
1 0.3 0.3
5 0.3 0.3
9 0.3 0.3



Submission
You only need to submit the rdt4.py program. Submit the file to the Assignment Submission page for
Project Part 3 at moodle.hku.hk.

Pa
ge
1
0

Implementation requirements
DO NOT implement the reliable layer on top of other protocols (e.g. TCP). You must implement the
reliable layer on top of UDP and use the __udt_send() function that we have provided to you to simulate
transmission errors. We will definitely check on this issue, and we will consider implementations that
using other means as a fail case and will receive ZERO mark.

Computer Platform to Use
For this project assignment, you are expected to develop and test your program on any platform installed
with Python 3 or above.

Format for the documentation
1. At the head of the submitted header files, state clearly the
• Student name:
• Student No. :
• Date and version:
• Development platform:
• Python version:
2. Inline comments (try to be detailed so that your code could be understood by others easily)

Grading Policy
As the tutor will check your source code, please write your program with good readability (i.e., with
good code convention and sufficient comments) so that you will not lose marks due to possible
confusions.
Part 2 (9
points)
• The program can transfer data and terminate correctly in an environment
without packet loss and corruption. [2.5/9]
• The program can transfer data and terminate correctly in an environment with
packet loss but no corruption (0.0LOSS0.3, ERROR=0.0). [2/9]
• The program can transfer data and terminate correctly in an environment with
packet corruption but no loss (LOSS=0.0, 0.0ERROR0.3). [2/9]
• The program can transfer data and terminate correctly in an environment with
packet loss and corruption (0.0LOSS0.3, 0.0ERROR0.3). [2/9]
• Documentation [0.5/9]
Include necessary documentation to clearly indicate the logic of the program;
include required student’s info at the beginning of the program
Part 3 (9
points)
• The program can transfer data and terminate correctly with W=1 in an
environment without packet loss and corruption [1/9] and in an environment
with loss and corruption (0.0LOSS0.3, 0.0ERROR0.3) [1.5/9].
• The program can transfer data and terminate correctly with 1W10 in an
environment without packet loss and corruption [2/9] and in an environment
with loss and corruption (0.0LOSS0.3, 0.0ERR0.3) [4/9].
• Documentation [0.5/9]
Include necessary documentation to clearly indicate the logic of the program;
include required student’s info at the beginning of the program

Pa
ge
1
1

Background Readings and Preparation
• Lectures – 03-Transport-S&W.pdf
• Section 3.4 of textbook – Computer Networking: A Top-Down Approach (7th ed.) by J.F. Kurose et. al
• Lecture - Socket Programming in Python and the Workshops
• Project briefing notes

Plagiarism
Plagiarism is a very serious academic offence. Students should understand what constitutes plagiarism,
the consequences of committing an offence of plagiarism, and how to avoid it. Please note that we may
request you to explain to us how your program is functioning as well as we may also make use
software tools to detect software plagiarism.







































































































































































































































































































































































































































































































学霸联盟


essay、essay代写