COMP3331编程课程代做、Python编程代写、代写c++,Java程序 帮做R语言编程|调试M

- 首页 >> Java编程
COMP3331/9331 Computer Networks and Applications
Assignment for Term 2, 2021
Version 1.0
Due: 11:59am (noon) Friday, 6 August 2021 (Week 10)
1. Change Log
Version 1.0 released on 21st June 2021.
2. 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 Padawan Transport Protocol (PTP). PTP 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 (7th ed.).
Examples of these features include timeout, ACK, sequence numbers, 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 on the Internet,
where they have implemented their own proprietary transport protocol over UDP.
Note that it is mandatory that you implement PTP over UDP. Do not use TCP sockets. You
will not receive any mark for this assignment if you use TCP sockets.
2.1 Learning Objectives
On completing this assignment, you will gain sufficient expertise in the following skills:
1. Detailed understanding of how reliable transport protocols such as TCP function.
2. Socket programming for UDP transport protocol.
3. Protocol and message design.
Non-CSE Student: The rationale for this option is that students enrolled in a program that does not
include a computer science component have had very limited exposure to programming and in
particular working on complex programming assignments. A Non-CSE student is a student who is
not enrolled in a CSE program (single or double degree). Examples would include students enrolled
exclusively in a single degree program such as Mechatronics or Aerospace or Actuarial Studies or
Law. Students enrolled in dual degree programs that include a CSE program as one of the degrees
do not qualify. Any student who meets this criterion and wishes to avail of this option MUST email
cs3331@cse.unsw.edu.au to seek approval before 5pm, 2nd July (Friday, Week 5). We will
assume by default that all students are attempting the CSE version of the assignment unless they
have sought explicit permission. No exceptions.
Updates to the assignment, including any corrections and clarifications, will be posted on the
subject website. Please make sure that you check the subject website regularly for updates.
2
3. Assignment Specification
As part of this assignment, you will have to implement Padawan Transport Protocol (PTP), a piece
of software that consists of a sender and receiver component that allows reliable unidirectional
data transfer. PTP includes some of the features of the TCP protocol that are described in sections
3.5.4 and 3.5.6 of the textbook (7th edition). You will use your PTP protocol to transfer simple text
(ASCII) files (examples provided on the assignment webpage) from the sender to the receiver. You
should implement PTP 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, PTP 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.
NOTE: Section 3.5 of the textbook which covers the bulk of the discussion on TCP is available to
download on the assignment page.
3.1 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.
3.2 List of features provided by the Sender and Receiver
You are required to implement the following features in the Sender and Receiver:
1. 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 of the text for further details.
2. The four-segment connection termination (FIN, ACK, FIN, ACK). The Sender will initiate the
connection close once the entire file has been successfully transmitted. It is possible for the
Receiver to combine the ACK and FIN in one message. See Section 3.5.6 of the text for further
details. The Sender should terminate after connection closure.
Figure 1: The basic setup of your assignment. A file is to be transferred from the Sender to the Receiver.
Sender will run on the sender side while Receiver will run on the receiver side. Note that data segments will
flow from the sender to receiver, while ACK segments will flow from the receiver to sender.
Data
Ack Sender Receiver
UDP Socket1
Let OS pick the port number
UDP Socket 2
receiver_port specified as argument
3
3. Sender must maintain a single timer for timeout operation (Section 3.5.4 of the text). You must
use a constant timeout in your program. The value of the timeout will be supplied to Sender as an
input argument.
4. Sender should implement all the features mentioned in Section 3.5.4 of the text, with the
exception of doubling the timeout. The PTP 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.
5.Receiver should implement the features mentioned in Section 3.5.4 of the text. However, you do
not need to follow Table 3.2 (of text) for ACK generation. All segments should be immediately
acknowledged, i.e., you do not have to implement delayed ACKs.
6. PTP is a byte-stream oriented protocol. You will need to include sequence number and
acknowledgement number fields in the PTP header for each segment. The meaning of sequence
number and acknowledgment number are the same as TCP.
7. One of the command line arguments, MSS (Maximum segment size) is the maximum number of
bytes of data that your PTP 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. You may safely assume that the MSS will be
smaller than the maximum possible size of a UDP segment (64Kbytes).
8. 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:
LastByteSent – LastByteAcked ≤ MWS
10. Even though you will use UDP since the sender and receiver will mostly be running on the same
physical machine, there will be no real possibility of PTP segments being dropped. In order to test
the reliability of your protocol, it is imperative to introduce artificially induced packet loss. For this
purpose, you must also implement a Packet Loss (PL) Module as part of the Sender program. The
details for this module are explained later in the specification.
4.3 Features excluded
There are a number of transport layer features adopted by TCP that are excluded from this
assignment:
1. You do not need to use a random initial sequence number.
2. You do not need to implement timeout estimation. The timer value is provided as a command
line argument.
3. You do not need to double timeout interval.
4. You do not need to implement any flow nor congestion control.
5. PTP does not have to deal with corrupted packets. Packets will rarely be corrupted when the
sender and receiver are executing on the same machine. In short, it is safe for you to assume
4
that packets are only lost.
6. You do not need to handle abnormal behaviour, i.e., Sender or Receiver program crashing. In
other words, you do not need to implement functionality like RST in TCP.
4.4 Packet header and MSS
In designing the segment header, you only need to include the fields that you think are necessary for
PTP. You can draw inspiration from TCP but the exact format of the PTP 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 PTP
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 PTP headers. You may use the port number and IP address included within the
UDP datagram that encapsulates the PTP segments.
4.5 Sender
This section provides details on the Sender.
The Sender should accept the following eight (8) arguments (note that the last two arguments are
used exclusively by the PL module):
1. receiver_host_ip: the IP address of the host machine on which the Receiver is running.
2. receiver_port: the port number on which Receiver is expecting to receive packets from
the sender. This should match the command line argument of the same name for the Receiver.
3. FileToSend.txt: the name of the text file that has to be transferred from sender to
receiver using your reliable transport protocol. You may assume that the file included in the
argument will be available in the current working directory of the Sender with the correct
access permissions set (read).
4. MWS: the maximum window size used by your PTP protocol in bytes.
5. MSS: Maximum Segment Size which is the maximum amount of data (in bytes) carried in
each PTP segment. NOTE: In our tests we will ensure that MWS is exactly divisible by MSS.
6. timeout: the value of timeout in milliseconds.
The following two arguments are used exclusively by the PL module:
7. pdrop: the probability that a PTP 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 PL.
8. seed: The seed for your random number generator. The use of seed will be explained in
Section 4.5.2 of the specification.
The Sender should be initiated as follows:
If you use Java:
java Sender receiver_host_ip receiver_port FileToSend.txt MWS MSS timeout pdrop
seed
5
If you use C:
./sender receiver_host_ip receiver_port FileToSend.txt MWS MSS timeout pdrop
seed
If you use Python:
python sender.py receiver_host_ip receiver_port FileToSend.txt MWS MSS timeout
pdrop seed
Note that, you should first execute the Receiver before initiating the Sender.
It is very likely that you will be executing the Sender and Receiver on the same machine. In this
case use 127.0.0.1 (localhost) for the receiver_host_ip.
4.5.1 The PL Module
The PL module should be implemented as part of your Sender program. The function of the PL is to
emulate packet loss on the Internet. Even though theoretically UDP datagrams will get lost, in our
test environment these events will occur very rarely. Further to test the reliability of your PTP
protocol we would like to be able to control the percentage of packets being lost. You can assume
that packets will not be delayed or corrupted in the network.
The following describes the sequence of steps that the PL should perform on receiving a PTP
segment:
1. If the PTP segment is for connection establishment or teardown, then pass the segment to
UDP, do not drop it.
Remark: In order to reduce the complexity of connection setup, the connection establishment
and teardown segments from the Sender can bypass the PL module and will not be dropped.
2. If the PTP segment is not for connection establishment or teardown, the PL module must do
one of the following:
(a) with probability pdrop drop the datagram.
(b) With probability (1-pdrop), forward the datagram.
To implement this simply generate a random number between 0 and 1. If the chosen number
is greater than pdrop transmit the packet, else the packet is dropped.
Remark: The file PingServer.java in Lab Exercise 2 contains an example of randomly
dropping packets.
Once the PL is ready to transmit a PTP segment, the Sender should encapsulate the PTP segment in
a UDP datagram (i.e., create a UDP datagram with the PTP segment as the payload). It should then
transmit this datagram to the Receiver through the UDP socket created earlier. (Use the
receiver_host_ip and receiver_port as the destination IP address and port number
respectively). Once the entire text file has been transmitted reliably (i.e., the sender window is
empty and the final ACK is received) the Sender can close the UDP socket and terminate.
Note that the ACK segments from the receiver must completely bypass the PL modules. In other
words, ACK segments are never lost.
4.5.2 Seed for random number generators
In order for us to check your results, we will be asking you to initialise your random number
generator with a specific seed in Section 8 of the spec so that we can repeat your experiments.
If you have not learnt about the principles behind random number generators, you need to know that
6
random numbers are in fact generated by a deterministic formula by a computer program.
Therefore, strictly speaking, random number generators are called pseudo-random number
generators because the numbers are not truly random. The deterministic formula for random
number generation in Python, Java and C uses an input parameter called a seed. If the same seed is
used, then the same sequence of random numbers will be produced.
The following code fragment in Python, Java and C will generate random numbers between 0 and 1
using a supplied seed.
1. In Python, you initialise a random number generator (assuming the seed is 50) by using
random.seed(50);. After that you can generate a random floating point number between
(0,1) by using random.random();
2. In Java, you initalise a random number generator (assuming the seed is 50) by using Random
random = new Random(50);. After that, you can generate a random floating point
number between (0,1) by using float x = random.nextFloat();
3. In C, you initalise a random number generator (assuming the seed is 50) by using
srand(50);. After that, you can generate a random floating point number between (0,1) by
using float x = rand()/((float)(RAND_MAX)+1); Note that, RAND_MAX is the
maximum value returned by the rand() function.
You will find that if you specify different seeds, a different sequence of pseudo-random numbers
will be produced.
4.5.3 Additional requirements for Sender
Your Sender will receive acknowledgements from the Receiver through the same socket, which the
sender uses to transmit data. The Sender must first extract the PTP acknowledgement from the UDP
datagram that it receives and then process it as per the operation of your PTP protocol. The format
of the acknowledgement segments should be exactly the same as the data segments except that they
should not contain any data. Note that these acknowledgements should bypass the PL module.
The sender should maintain a log file titled Sender_log.txt where it records the information
about each segment that it sends and receives. You may assume that the sender program will have
permission to create files in its current working directory. Information about dropped segments
packets should also be included. Start each entry on a new line. The format should be as follows: