program 编程代做、代写 c++/java，Python 编程
- 首页 >> Python编程 1. Goal
For this assignment, you are to implement a reliable transport protocol over the UDP protocol. We will refer to the reliable transport protocol that you will be implementing 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 - 3.5.6 of the text Computer Networking by Kurose and Ross (7th or 8th ed.) or equivalent parts from the Week 4/5 lecture notes. Examples of these features include timeout, ACK, sequence numbers, sliding window, 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 a 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 multimedia delivery services on the Internet, where they have implemented their own proprietary transport protocol over UDP. QUIC, a newly proposed transport protocol also runs over UDP and implements additional functionalities such as reliability.
Recall that UDP provides point-to-point, unreliable datagram service between a pair of hosts. In this programming assignment, you will develop a more structured protocol, STP, which ensures reliable, end-to-end delivery of data in the face of packet loss. STP provides a byte-stream abstraction like TCP and sends pipelined data segments using a sliding window. However, STP does not implement congestion control or flow control. Finally, whereas TCP allows fully bidirectional communication, your implementation of STP will be asymmetric. There will be two distinct STP endpoints, "sender" and "receiver", respectively. Data packets will only flow in the "forward" direction from the sender to the receiver, while acknowledgments will only flow in the "reverse" direction from the receiver back to the sender. To support reliability in a protocol like STP, state must be maintained at both endpoints. Thus, as in TCP, connection set-up and connection teardown phases will be an integral part of the protocol. STP should implement a sliding window protocol wherein multiple segments can be sent by the sender in a pipelined manner. Like TCP, STP will include some elements of both Go- Back-N (GBN) and Selective Repeat (SR). You will use your STP protocol to transfer a text file (examples provided on the assignment webpage) from the sender to the receiver.
The sender program must also emulate the behaviour of an unreliable communication channel between the sender and receiver. Even though UDP segments can get lost, the likelihood of such losses is virtually zero in our test environment, where the sender and receiver will be executed on the same machine. Further, to properly test the implementation of your sender program, we would like to control the unreliable behaviour of the underlying channel. The sender program should emulate loss of STP segments in both directions – (i) DATA, SYN, and FIN segments in the forward direction and (ii) ACK segments in the reverse direction. You may assume that the underlying channel will never reorder or corrupt STP segments (in both directions).
Note that it is mandatory that you implement STP over UDP. Do not use TCP sockets. You will not receive any marks for this assignment if you use TCP sockets.
2. Specification
STP should be implemented as two separate programs: sender and receiver. You should 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. The sender and receiver programs will be run from different terminals on the same machine, so you can use localhost, i.e., 127.0.0.1 as the IP address for the sender and receiver in your program. 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.
1
You will find it useful to review Sections 3.5.4 - 3.5.6 of the text (or the relevant parts from the Week 5 lecture notes). It may also be useful to review the basic concepts of reliable data transfer from Section 3.4 (or relevant parts from the Week 4 lecture notes). Section 3.5 of the textbook which covers the bulk of the discussion on TCP is available to download on the assignment page.
Figure 1: This depicts the assignment setup. A file is to be transferred from the Sender to the Receiver, both running on the same machine. Data segments will flow from the sender to receiver, while ACK segments will flow from the receiver to sender.
2.1 File Names
The main code for the sender should be contained in the following files: sender.c, or Sender.java, or sender.py. You may create additional files such as header files or other class files and name them as you wish.
The sender should accept the following seven arguments:
1. sender_port: the UDP port number to be used by the sender to send STP segments to the receiver. The sender will receive ACK segments from the receiver through this same port. We recommend using a random port number between 49152 to 65535 (dynamic port number range) for the sender and receiver ports.
2. receiver_port: the UDP port number on which receiver is expecting to receive STP segments from the sender. The receiver should send ACK segments to the sender through this same port. We recommend using a random port number in the same range noted above.
3. txt_file_to_send: the name of the text file that must 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 “read” access permissions set (execute “chmod +r txt_file_to_send” at the terminal in the directory containing the file, where txt_file_to_send is set to the actual name of the file).
4. max_win: the maximum window size in bytes for the sender window. This should be an unsigned integer. Effectively, this is the maximum number of data bytes that the sender can transmit in a pipelined manner and for which ACKs are outstanding. max_win must be greater than or equal to 1000 bytes (MSS) and does not include STP headers. When max_win is set to 1000 bytes, STP will effectively behave as a stop-and-wait protocol, wherein the sender transmits one data segment at any given time and waits for the corresponding ACK segment. While testing, we will ensure that max_win is a multiple of 1000 bytes (e.g., 5000 bytes).
5. rto: the value of the retransmission timer in milliseconds. This should be an unsigned integer.
6. flp:forwardlossprobability,whichistheprobabilitythatanysegmentintheforwarddirection (DATA, FIN, SYN) is lost. This should be a float value between 0 and 1 (inclusive). If flp is 0.1, then the sender will drop approximately 10% of the segments that it intends to send to the receiver.
2
7. rlp: reverse loss probability, which is the probability of a segment in the reverse direction (i.e., ACKs) being lost. This should be a float value between 0 and 1 (inclusive). If rlp is 0.05, then the sender will drop approximately 5% of the ACK segments received.
The sender should be initiated as follows: If you use Java:
java Sender sender_port receiver_port txt_file_to_send max_win rto flp rlp
If you use C:
./sender sender_port receiver_port txt_file_to_send max_win rto flp rlp
If you use Python:
python3 sender.py sender_port receiver_port txt_file_to_send max_win rto flp rlp
During testing, we will ensure that the 7 arguments provided are in the correct format. We will not test for erroneous arguments, missing arguments, etc. That said, it is good programming practice to check for such input errors.
The main code for the receiver should be contained in the following files: receiver.c, or Receiver.java, or receiver.py. You may create additional files such as header files or other class files and name them as you wish.
The receiver should accept the following four arguments:
1. receiver_port: the UDP port number to be used by the receiver to receive STP segments from the sender. This argument should match the second argument for the sender.
2. sender_port: the UDP port number to be used by the sender to send STP segments to the receiver. This argument should match the first argument for the sender.
3. txt_file_received: the name of the text file into which the data sent by the sender should be stored (this is the file that is being transferred from sender to receiver). You may assume that the receiver program will have permission to create files in its working directory (execute “chmod +w .” at the terminal to allow the creation of files in the working directory), and that a file with this name does not exist in the working directory or may be overwritten.
4. max_win: the receive window size. This argument should match the fourth argument for the sender. It is provided to the receiver to ensure that the receiver can initialise a buffer sufficient to hold all the data that the sender can transmit in a pipelined manner.
The receiver should be initiated as follows: If you use Java:
java Receiver receiver_port sender_port txt_file_received max_win
If you use C:
./receiver receiver_port sender_port txt_file_received max_win
If you use Python:
python3 receiver.py receiver_port sender_port txt_file_received max_win
During testing, we will ensure that the 4 arguments provided are in the correct format. We will not test for erroneous arguments, missing arguments, etc. That said, it is good programming practice to check for such input errors.
3
The receiver must be initiated before initiating the sender. The two programs will be executed on the same machine. Pay attention to the order of the port numbers to be specified in the arguments for the two programs as they are in reverse order (sender port is first for the sender while receiver port is first for the receiver). If you receive an error that one or both port numbers are in use, then choose different values from the dynamic port number range (49152 to 65535) and try again.
The sender and receiver should exit after the file transfer is complete and the required information, as stated in the subsequent sections of this document, is written to the sender and receiver log files.
2.2 Segment Format
STP segments must have 2 *two*-byte fields: "type" and "seqno" headers. Each of these store unsigned integer values in network byte order, i.e., big-endian.
The "type" field takes on 4 possible values. DATA = 0, ACK = 1, SYN = 2, FIN = 3.
Unlike TCP, in which multiple types can be set simultaneously, STP segments must be of exactly one of the types specified above.
The "seqno" field indicates the sequence number of the segment. This field is used in all segments. For DATA segments, the sequence number increases by the size (in bytes) of each segment (excluding headers). For ACK segments, the sequence number acts as a cumulative acknowledgment, and indicates the number of the next byte expected by the receiver. For SYN segments, the sequence number is the initial sequence number (ISN), which should be a randomly chosen integer from 0 to 2^16 - 1, which is the maximum sequence number. The sequence number of the first DATA segment of the connection should thus be ISN+1. For FIN segments, the sequence number is one larger than the sequence number of the last byte of the last data segment of the connection. The Maximum Segment Size (MSS) (excluding headers) for STP segment is 1000 bytes. A DATA segment can thus be up to 1004 bytes long. The last DATA segment for the file being transferred may contain less than 1000 bytes as the file size may not be a multiple of 1000 bytes. All segments excluding DATA segments should only contain the headers and must thus be exactly 4 bytes long.
The logic for determining the sequence number and ack number in STP is like TCP. However, STP does not use a separate ack number header field. Rather, the “seqno” field contains the ack number for the ACK segments.
2.3 State Diagram
The asymmetry between sender and receiver leads to somewhat different state diagrams for the two endpoints. The state diagram for STP is shown below, which depicts the normal behaviour for both end points.
4
Figure 2: State diagram depicting the normal behaviour of STP.
The receiver can be in four possible states: CLOSED, LISTEN, ESTABLISHED and TIME_WAIT. Initially, it is in the CLOSED state. Upon issuing a passive open, it enters the LISTEN state. Note that the receiver is the passive host in our protocol and is initiated first, while the sender is initiated next and actively opens the connection. While in the LISTEN state, the receiver waits for a SYN segment to arrive on the correct port number. When it does, it responds with an ACK, and moves to the ESTABLISHED state. Should a duplicate SYN arrive while the receiver is in the ESTABLISHED state, it reissues the ACK and remains in the ESTABLISHED state. The ACKs sent by the receiver are cumulative (like TCP). After the sender has reliably transmitted all data (and received acknowledgments), it will send a FIN segment to the receiver. Upon receipt of the FIN, the receiver moves to the TIME_WAIT state. As in TCP, it remains in TIME_WAIT for two maximum segment lifetimes (MSLs) before re-entering the CLOSED state. This is to ensure that the receiver can respond to potentially retransmitted FIN segments from the sender. You may assume that the MSL is 1 seconds. In other words, the receiver should remain in TIME_WAIT for 2 seconds and then transition to CLOSED.
The sender can be in five possible states: CLOSED, SYN_SENT, ESTABLISHED, CLOSING and FIN_WAIT. Like the receiver, the sender starts in the CLOSED state. It then issues an active open by sending a SYN segment (to the receiver's port), thus entering the SYN_SENT state. This SYN transmission also includes the initial sequence number (ISN) of the conversation. The ISN should be chosen at random from the valid range of possible sequence numbers (0 to 2^16 – 1). If a corresponding ACK is not received within rto msec, the sender should retransmit the SYN segment. In the common case in which the SYN is acknowledged correctly (the ACK must have the correct sequence number = ISN + 1), the sender enters the ESTABLISHED state and starts transmitting DATA segments. The sender maintains a single timer (for rto msec) for the oldest unacknowledged packet and only retransmits this packet if the timer expires. Once all DATA segments have been transmitted the sender enters the CLOSING state. At this point, the sender must still ensure that any buffered data arrives at the receiver reliably. Upon verification of successful transmission, the sender sends a FIN segment with the appropriate sequence number (1 greater than the sequence number of the last data byte) and enters the FIN_WAIT state. Once the FIN segment is acknowledged, the sender re-enters the CLOSED state. If an ACK is not received before the timer (rto msec) expires, the sender should retransmit the FIN segment.
Strictly speaking, you don’t have to implement the CLOSED state at the start for the sender. Your sender program when executed can immediately send the SYN segment and enter the SYN_SENT state. Also, when the sender is in the FIN_WAIT state and receives the ACK for the FIN segment, the program can simply exit. This is because the sender only transmits a single file in one execution and quits following the reliable file transfer.
5
Unlike TCP which follows a three-way handshake (SYN, SYN/ACK, ACK) for connection setup and independent connection closures (FIN, ACK) in each direction, STP follows a two-way connection setup (SYN, ACK) and one directional connection closure (FIN, ACK) process. The setup and closure are always initiated by the sender.
If one end point detects behaviour that is unexpected, it should simply print a message to the terminal indicating that the connection is being reset, and then terminate. For example, if the receiver receives a DATA segment while it is in the LISTEN state (where it is expecting a SYN segment). The state transition diagram on the previous page does not capture such erroneous scenarios. You are free to specify the format of the message that is printed. Note that, we will NOT be rigorously testing your code for such unexpected behaviour.
2.4 List of features to be implemented by the sender.
You are required to implement the following features in the sender (and equivalent functionality in the receiver).
1. The sender should first open a UDP socket on sender_port and initiate a two-way handshake (SYN, ACK) for the connection establishment. The sender sends a SYN segment, and the receiver responds with an ACK. This is different to the three-way handshake implemented by TCP. If the ACK is not received before a timeout (rto msec), the sender should retransmit the SYN.
2. The sender must choose a random initial sequence number (ISN) between 0 and 216 – 1.
Remember to perform sequence number arithmetic modulo 216. The sequence numbers should cycle back to zero after reaching 216 – 1.
3. A one-directional (forward) connection termination (FIN, ACK). The sender will initiate the connection close once the entire file has been reliably transmitted by sending the FIN segment and the receiver will respond with an ACK. This is different to the bi-directional close implemented by TCP.IftheACKisnotreceivedbeforeatimeout(rtomsec),thesendershouldretransmittheFIN. The sender should terminate after connection closure.
4.STP implements a sliding window protocol like TCP, whereby multiple segments can be transmitted by the sender in a pipelined manner. The sender should maintain a buffer to store all unacknowledged segments. The total amount of data that the sender can transmit in a pipelined manner and for which acknowledgments are pending is limited by max_win. Similar to TCP, as the sender receives ACK segments, the left edge of the window can slide forward, and the sender can transmit the next DATA segments (if there is pending data to be sent).
5. Each STP segment transmitted by the sender (including DATA, SYN, FIN) must be encapsulated in a UDP segment and transmitted through the UDP socket.
6. The sender must maintain a single timer for retransmission of data segments (Section 3.5.4 of the text). The value of the timeout will be supplied as a command-line argument to the sender program (rto msec). This timer is for the oldest unacknowledged data segment. In the event of a timeout, only the oldest unacknowledged data segment should be retransmitted (like TCP). The sender should not retransmit all unacknowledged segments. Remember that you are NOT implementing Go-Back-N.
7. The sender should implement all the features mentioned in Section 3.5.4 of the text, except for doubling the timeout interval. You are expected to implement the functionality of the simplified TCP sender (Figure 3.33 of the text) and fast retransmit (i.e., the sender should retransmit the oldest unacknowledged data segment on three duplicate ACKs) (pages 247-248).
8. The use of the “seqno” field was outlined in Section 3.2. For DATA segments, the sequence number increases by the size (in bytes) of each segment (excluding headers). For ACK segments, the
6
sequence number acts as a cumulative acknowledgment, and indicates the number of the next byte expected by the receiver. The logic is thus like TCP, except that STP does not use a separate ACK header field. The ACK segments use the seqno header field to indicate the ACK numbers.
9. The sender will receive each ACK segment from the receiver through the same socket which the sender uses to transmit data. The ACK segment will be encapsulated in a UDP segment. The sender must first extract the ACK segment from the UDP segment and then process it as per the operation of the STP protocol. ACK segments have the same format as DATA segments but do not contain any data.
10. The sender program should emulate the behaviour of an unreliable communication channel between the sender and receiver. UDP segments can occasionally experience loss in a network, but the likelihood is very low when the sender and receiver are executed on the same machine. Moreover, to properly test the implementation of your sender program, we would like to control the unreliable behaviour of the underlying channel. The sender emulates loss of STP segments in both directions which can be controlled through two command line argument: (i) flp: determines the probability of a DATA, SYN, or FIN segment created by the sender being dropped. In other words, each such segment created by the sender will be dropped with a probability flp. If the segment is not dropped, then it will be transmitted through the socket to the receiver. (ii) rlp: determines the probability of an ACK segment in the reverse direction from the sender being dropped. In other words, each ACK segment arriving at the sender socket will be dropped with a probability rlp. If the segment is not dropped, then it will be processed as per the STP protocol.
7
Note about Random Number Generation
You will need to generate random numbers to establish an initial sequence number (ISN) and implement segment loss. If you have not learnt about the principles behind random number generators, you need to know that random numbers are in fact generated by a deterministic formula by a computer program. Therefore, strictly speaking, random number generators are called pseudorandom number generators because the numbers are not truly random. The deterministic formula for random number generation in Python, Java and C use an input parameter called a seed. If a fixed seed is used, then the same sequence of random numbers will be produced, each time the program is executed. This will thus likely generate the same ISN and the same sequence of segment loss in each execution of the sender. While this may be useful for debugging purposes, it is not a realistic representation of an unreliable channel. Thus, you must ensure that you do not use a fixed seed in your submitted program. A simple way to use a different seed for each execution is to base the seed on the system time.
The following code fragments in Python, Java and C generate random numbers between 0 and 1 with a different seed in each execution.
• In Python, you initialise a random number generator by using random.seed(). By default, the random number generator uses the current system time. After that you can generate a random floating point number between (0,1) by using random.random().
• In Java, you initialise a random number generator by using Random random = new Random(). This constructor sets the seed of the random number generator to a value very likely to be distinct from any other invocation of this constructor. After that, you can generate a random floating point number between (0,1) by using float x = random.nextFloat().
• In C, you initialise a random number generator by using srand(time(NULL)). 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.
11. The sender should maintain a log file named sender_log.txt where it records the information about each segment that it sends and receives. Information about dropped segments should also be included. You may assume that the sender program will have permission to create files in its current working directory. If the file already exists, then it should be overwritten. Start each entry on a new line. The format should be as follows:
For this assignment, you are to implement a reliable transport protocol over the UDP protocol. We will refer to the reliable transport protocol that you will be implementing 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 - 3.5.6 of the text Computer Networking by Kurose and Ross (7th or 8th ed.) or equivalent parts from the Week 4/5 lecture notes. Examples of these features include timeout, ACK, sequence numbers, sliding window, 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 a 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 multimedia delivery services on the Internet, where they have implemented their own proprietary transport protocol over UDP. QUIC, a newly proposed transport protocol also runs over UDP and implements additional functionalities such as reliability.
Recall that UDP provides point-to-point, unreliable datagram service between a pair of hosts. In this programming assignment, you will develop a more structured protocol, STP, which ensures reliable, end-to-end delivery of data in the face of packet loss. STP provides a byte-stream abstraction like TCP and sends pipelined data segments using a sliding window. However, STP does not implement congestion control or flow control. Finally, whereas TCP allows fully bidirectional communication, your implementation of STP will be asymmetric. There will be two distinct STP endpoints, "sender" and "receiver", respectively. Data packets will only flow in the "forward" direction from the sender to the receiver, while acknowledgments will only flow in the "reverse" direction from the receiver back to the sender. To support reliability in a protocol like STP, state must be maintained at both endpoints. Thus, as in TCP, connection set-up and connection teardown phases will be an integral part of the protocol. STP should implement a sliding window protocol wherein multiple segments can be sent by the sender in a pipelined manner. Like TCP, STP will include some elements of both Go- Back-N (GBN) and Selective Repeat (SR). You will use your STP protocol to transfer a text file (examples provided on the assignment webpage) from the sender to the receiver.
The sender program must also emulate the behaviour of an unreliable communication channel between the sender and receiver. Even though UDP segments can get lost, the likelihood of such losses is virtually zero in our test environment, where the sender and receiver will be executed on the same machine. Further, to properly test the implementation of your sender program, we would like to control the unreliable behaviour of the underlying channel. The sender program should emulate loss of STP segments in both directions – (i) DATA, SYN, and FIN segments in the forward direction and (ii) ACK segments in the reverse direction. You may assume that the underlying channel will never reorder or corrupt STP segments (in both directions).
Note that it is mandatory that you implement STP over UDP. Do not use TCP sockets. You will not receive any marks for this assignment if you use TCP sockets.
2. Specification
STP should be implemented as two separate programs: sender and receiver. You should 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. The sender and receiver programs will be run from different terminals on the same machine, so you can use localhost, i.e., 127.0.0.1 as the IP address for the sender and receiver in your program. 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.
1
You will find it useful to review Sections 3.5.4 - 3.5.6 of the text (or the relevant parts from the Week 5 lecture notes). It may also be useful to review the basic concepts of reliable data transfer from Section 3.4 (or relevant parts from the Week 4 lecture notes). Section 3.5 of the textbook which covers the bulk of the discussion on TCP is available to download on the assignment page.
Figure 1: This depicts the assignment setup. A file is to be transferred from the Sender to the Receiver, both running on the same machine. Data segments will flow from the sender to receiver, while ACK segments will flow from the receiver to sender.
2.1 File Names
The main code for the sender should be contained in the following files: sender.c, or Sender.java, or sender.py. You may create additional files such as header files or other class files and name them as you wish.
The sender should accept the following seven arguments:
1. sender_port: the UDP port number to be used by the sender to send STP segments to the receiver. The sender will receive ACK segments from the receiver through this same port. We recommend using a random port number between 49152 to 65535 (dynamic port number range) for the sender and receiver ports.
2. receiver_port: the UDP port number on which receiver is expecting to receive STP segments from the sender. The receiver should send ACK segments to the sender through this same port. We recommend using a random port number in the same range noted above.
3. txt_file_to_send: the name of the text file that must 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 “read” access permissions set (execute “chmod +r txt_file_to_send” at the terminal in the directory containing the file, where txt_file_to_send is set to the actual name of the file).
4. max_win: the maximum window size in bytes for the sender window. This should be an unsigned integer. Effectively, this is the maximum number of data bytes that the sender can transmit in a pipelined manner and for which ACKs are outstanding. max_win must be greater than or equal to 1000 bytes (MSS) and does not include STP headers. When max_win is set to 1000 bytes, STP will effectively behave as a stop-and-wait protocol, wherein the sender transmits one data segment at any given time and waits for the corresponding ACK segment. While testing, we will ensure that max_win is a multiple of 1000 bytes (e.g., 5000 bytes).
5. rto: the value of the retransmission timer in milliseconds. This should be an unsigned integer.
6. flp:forwardlossprobability,whichistheprobabilitythatanysegmentintheforwarddirection (DATA, FIN, SYN) is lost. This should be a float value between 0 and 1 (inclusive). If flp is 0.1, then the sender will drop approximately 10% of the segments that it intends to send to the receiver.
2
7. rlp: reverse loss probability, which is the probability of a segment in the reverse direction (i.e., ACKs) being lost. This should be a float value between 0 and 1 (inclusive). If rlp is 0.05, then the sender will drop approximately 5% of the ACK segments received.
The sender should be initiated as follows: If you use Java:
java Sender sender_port receiver_port txt_file_to_send max_win rto flp rlp
If you use C:
./sender sender_port receiver_port txt_file_to_send max_win rto flp rlp
If you use Python:
python3 sender.py sender_port receiver_port txt_file_to_send max_win rto flp rlp
During testing, we will ensure that the 7 arguments provided are in the correct format. We will not test for erroneous arguments, missing arguments, etc. That said, it is good programming practice to check for such input errors.
The main code for the receiver should be contained in the following files: receiver.c, or Receiver.java, or receiver.py. You may create additional files such as header files or other class files and name them as you wish.
The receiver should accept the following four arguments:
1. receiver_port: the UDP port number to be used by the receiver to receive STP segments from the sender. This argument should match the second argument for the sender.
2. sender_port: the UDP port number to be used by the sender to send STP segments to the receiver. This argument should match the first argument for the sender.
3. txt_file_received: the name of the text file into which the data sent by the sender should be stored (this is the file that is being transferred from sender to receiver). You may assume that the receiver program will have permission to create files in its working directory (execute “chmod +w .” at the terminal to allow the creation of files in the working directory), and that a file with this name does not exist in the working directory or may be overwritten.
4. max_win: the receive window size. This argument should match the fourth argument for the sender. It is provided to the receiver to ensure that the receiver can initialise a buffer sufficient to hold all the data that the sender can transmit in a pipelined manner.
The receiver should be initiated as follows: If you use Java:
java Receiver receiver_port sender_port txt_file_received max_win
If you use C:
./receiver receiver_port sender_port txt_file_received max_win
If you use Python:
python3 receiver.py receiver_port sender_port txt_file_received max_win
During testing, we will ensure that the 4 arguments provided are in the correct format. We will not test for erroneous arguments, missing arguments, etc. That said, it is good programming practice to check for such input errors.
3
The receiver must be initiated before initiating the sender. The two programs will be executed on the same machine. Pay attention to the order of the port numbers to be specified in the arguments for the two programs as they are in reverse order (sender port is first for the sender while receiver port is first for the receiver). If you receive an error that one or both port numbers are in use, then choose different values from the dynamic port number range (49152 to 65535) and try again.
The sender and receiver should exit after the file transfer is complete and the required information, as stated in the subsequent sections of this document, is written to the sender and receiver log files.
2.2 Segment Format
STP segments must have 2 *two*-byte fields: "type" and "seqno" headers. Each of these store unsigned integer values in network byte order, i.e., big-endian.
The "type" field takes on 4 possible values. DATA = 0, ACK = 1, SYN = 2, FIN = 3.
Unlike TCP, in which multiple types can be set simultaneously, STP segments must be of exactly one of the types specified above.
The "seqno" field indicates the sequence number of the segment. This field is used in all segments. For DATA segments, the sequence number increases by the size (in bytes) of each segment (excluding headers). For ACK segments, the sequence number acts as a cumulative acknowledgment, and indicates the number of the next byte expected by the receiver. For SYN segments, the sequence number is the initial sequence number (ISN), which should be a randomly chosen integer from 0 to 2^16 - 1, which is the maximum sequence number. The sequence number of the first DATA segment of the connection should thus be ISN+1. For FIN segments, the sequence number is one larger than the sequence number of the last byte of the last data segment of the connection. The Maximum Segment Size (MSS) (excluding headers) for STP segment is 1000 bytes. A DATA segment can thus be up to 1004 bytes long. The last DATA segment for the file being transferred may contain less than 1000 bytes as the file size may not be a multiple of 1000 bytes. All segments excluding DATA segments should only contain the headers and must thus be exactly 4 bytes long.
The logic for determining the sequence number and ack number in STP is like TCP. However, STP does not use a separate ack number header field. Rather, the “seqno” field contains the ack number for the ACK segments.
2.3 State Diagram
The asymmetry between sender and receiver leads to somewhat different state diagrams for the two endpoints. The state diagram for STP is shown below, which depicts the normal behaviour for both end points.
4
Figure 2: State diagram depicting the normal behaviour of STP.
The receiver can be in four possible states: CLOSED, LISTEN, ESTABLISHED and TIME_WAIT. Initially, it is in the CLOSED state. Upon issuing a passive open, it enters the LISTEN state. Note that the receiver is the passive host in our protocol and is initiated first, while the sender is initiated next and actively opens the connection. While in the LISTEN state, the receiver waits for a SYN segment to arrive on the correct port number. When it does, it responds with an ACK, and moves to the ESTABLISHED state. Should a duplicate SYN arrive while the receiver is in the ESTABLISHED state, it reissues the ACK and remains in the ESTABLISHED state. The ACKs sent by the receiver are cumulative (like TCP). After the sender has reliably transmitted all data (and received acknowledgments), it will send a FIN segment to the receiver. Upon receipt of the FIN, the receiver moves to the TIME_WAIT state. As in TCP, it remains in TIME_WAIT for two maximum segment lifetimes (MSLs) before re-entering the CLOSED state. This is to ensure that the receiver can respond to potentially retransmitted FIN segments from the sender. You may assume that the MSL is 1 seconds. In other words, the receiver should remain in TIME_WAIT for 2 seconds and then transition to CLOSED.
The sender can be in five possible states: CLOSED, SYN_SENT, ESTABLISHED, CLOSING and FIN_WAIT. Like the receiver, the sender starts in the CLOSED state. It then issues an active open by sending a SYN segment (to the receiver's port), thus entering the SYN_SENT state. This SYN transmission also includes the initial sequence number (ISN) of the conversation. The ISN should be chosen at random from the valid range of possible sequence numbers (0 to 2^16 – 1). If a corresponding ACK is not received within rto msec, the sender should retransmit the SYN segment. In the common case in which the SYN is acknowledged correctly (the ACK must have the correct sequence number = ISN + 1), the sender enters the ESTABLISHED state and starts transmitting DATA segments. The sender maintains a single timer (for rto msec) for the oldest unacknowledged packet and only retransmits this packet if the timer expires. Once all DATA segments have been transmitted the sender enters the CLOSING state. At this point, the sender must still ensure that any buffered data arrives at the receiver reliably. Upon verification of successful transmission, the sender sends a FIN segment with the appropriate sequence number (1 greater than the sequence number of the last data byte) and enters the FIN_WAIT state. Once the FIN segment is acknowledged, the sender re-enters the CLOSED state. If an ACK is not received before the timer (rto msec) expires, the sender should retransmit the FIN segment.
Strictly speaking, you don’t have to implement the CLOSED state at the start for the sender. Your sender program when executed can immediately send the SYN segment and enter the SYN_SENT state. Also, when the sender is in the FIN_WAIT state and receives the ACK for the FIN segment, the program can simply exit. This is because the sender only transmits a single file in one execution and quits following the reliable file transfer.
5
Unlike TCP which follows a three-way handshake (SYN, SYN/ACK, ACK) for connection setup and independent connection closures (FIN, ACK) in each direction, STP follows a two-way connection setup (SYN, ACK) and one directional connection closure (FIN, ACK) process. The setup and closure are always initiated by the sender.
If one end point detects behaviour that is unexpected, it should simply print a message to the terminal indicating that the connection is being reset, and then terminate. For example, if the receiver receives a DATA segment while it is in the LISTEN state (where it is expecting a SYN segment). The state transition diagram on the previous page does not capture such erroneous scenarios. You are free to specify the format of the message that is printed. Note that, we will NOT be rigorously testing your code for such unexpected behaviour.
2.4 List of features to be implemented by the sender.
You are required to implement the following features in the sender (and equivalent functionality in the receiver).
1. The sender should first open a UDP socket on sender_port and initiate a two-way handshake (SYN, ACK) for the connection establishment. The sender sends a SYN segment, and the receiver responds with an ACK. This is different to the three-way handshake implemented by TCP. If the ACK is not received before a timeout (rto msec), the sender should retransmit the SYN.
2. The sender must choose a random initial sequence number (ISN) between 0 and 216 – 1.
Remember to perform sequence number arithmetic modulo 216. The sequence numbers should cycle back to zero after reaching 216 – 1.
3. A one-directional (forward) connection termination (FIN, ACK). The sender will initiate the connection close once the entire file has been reliably transmitted by sending the FIN segment and the receiver will respond with an ACK. This is different to the bi-directional close implemented by TCP.IftheACKisnotreceivedbeforeatimeout(rtomsec),thesendershouldretransmittheFIN. The sender should terminate after connection closure.
4.STP implements a sliding window protocol like TCP, whereby multiple segments can be transmitted by the sender in a pipelined manner. The sender should maintain a buffer to store all unacknowledged segments. The total amount of data that the sender can transmit in a pipelined manner and for which acknowledgments are pending is limited by max_win. Similar to TCP, as the sender receives ACK segments, the left edge of the window can slide forward, and the sender can transmit the next DATA segments (if there is pending data to be sent).
5. Each STP segment transmitted by the sender (including DATA, SYN, FIN) must be encapsulated in a UDP segment and transmitted through the UDP socket.
6. The sender must maintain a single timer for retransmission of data segments (Section 3.5.4 of the text). The value of the timeout will be supplied as a command-line argument to the sender program (rto msec). This timer is for the oldest unacknowledged data segment. In the event of a timeout, only the oldest unacknowledged data segment should be retransmitted (like TCP). The sender should not retransmit all unacknowledged segments. Remember that you are NOT implementing Go-Back-N.
7. The sender should implement all the features mentioned in Section 3.5.4 of the text, except for doubling the timeout interval. You are expected to implement the functionality of the simplified TCP sender (Figure 3.33 of the text) and fast retransmit (i.e., the sender should retransmit the oldest unacknowledged data segment on three duplicate ACKs) (pages 247-248).
8. The use of the “seqno” field was outlined in Section 3.2. For DATA segments, the sequence number increases by the size (in bytes) of each segment (excluding headers). For ACK segments, the
6
sequence number acts as a cumulative acknowledgment, and indicates the number of the next byte expected by the receiver. The logic is thus like TCP, except that STP does not use a separate ACK header field. The ACK segments use the seqno header field to indicate the ACK numbers.
9. The sender will receive each ACK segment from the receiver through the same socket which the sender uses to transmit data. The ACK segment will be encapsulated in a UDP segment. The sender must first extract the ACK segment from the UDP segment and then process it as per the operation of the STP protocol. ACK segments have the same format as DATA segments but do not contain any data.
10. The sender program should emulate the behaviour of an unreliable communication channel between the sender and receiver. UDP segments can occasionally experience loss in a network, but the likelihood is very low when the sender and receiver are executed on the same machine. Moreover, to properly test the implementation of your sender program, we would like to control the unreliable behaviour of the underlying channel. The sender emulates loss of STP segments in both directions which can be controlled through two command line argument: (i) flp: determines the probability of a DATA, SYN, or FIN segment created by the sender being dropped. In other words, each such segment created by the sender will be dropped with a probability flp. If the segment is not dropped, then it will be transmitted through the socket to the receiver. (ii) rlp: determines the probability of an ACK segment in the reverse direction from the sender being dropped. In other words, each ACK segment arriving at the sender socket will be dropped with a probability rlp. If the segment is not dropped, then it will be processed as per the STP protocol.
7
Note about Random Number Generation
You will need to generate random numbers to establish an initial sequence number (ISN) and implement segment loss. If you have not learnt about the principles behind random number generators, you need to know that random numbers are in fact generated by a deterministic formula by a computer program. Therefore, strictly speaking, random number generators are called pseudorandom number generators because the numbers are not truly random. The deterministic formula for random number generation in Python, Java and C use an input parameter called a seed. If a fixed seed is used, then the same sequence of random numbers will be produced, each time the program is executed. This will thus likely generate the same ISN and the same sequence of segment loss in each execution of the sender. While this may be useful for debugging purposes, it is not a realistic representation of an unreliable channel. Thus, you must ensure that you do not use a fixed seed in your submitted program. A simple way to use a different seed for each execution is to base the seed on the system time.
The following code fragments in Python, Java and C generate random numbers between 0 and 1 with a different seed in each execution.
• In Python, you initialise a random number generator by using random.seed(). By default, the random number generator uses the current system time. After that you can generate a random floating point number between (0,1) by using random.random().
• In Java, you initialise a random number generator by using Random random = new Random(). This constructor sets the seed of the random number generator to a value very likely to be distinct from any other invocation of this constructor. After that, you can generate a random floating point number between (0,1) by using float x = random.nextFloat().
• In C, you initialise a random number generator by using srand(time(NULL)). 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.
11. The sender should maintain a log file named sender_log.txt where it records the information about each segment that it sends and receives. Information about dropped segments should also be included. You may assume that the sender program will have permission to create files in its current working directory. If the file already exists, then it should be overwritten. Start each entry on a new line. The format should be as follows: