solve the assignment
COMS3200/7201 Assignment 1 Due: 20th April 2020, 20:00 100 marks total (20% weight for the final grade (100%)) Part A (20 marks total) Answer each of the following questions in the associated quiz on blackboard, following the specified instructions. All questions will be automatically marked. A client requests a webpage from a remote server on a remote island via a slow satellite link above the earth in geostationary orbit. The goal of this exercise is to use the following information to calculate the time for the request to be completed. The scenario is in no way intended to be realistic. There is a client (C), a server (V), and a DNS server (D). These are connected by three switches (S1, S2, and S3) and five transmission links (L1 to L5) where L2 is the satellite link. The following tables provide further information about the network (bps == bits per second, 1 kbps == 103 bps, 1 Mbps == 106 bps). Transmission Links Link Name Connected to Connected to Transmission Rate Length Propagation Speed L1 C S1 100Mbps 300m 2 × 108 m/s L2 S1 S2 5kbps 36,000km 3 × 108 m/s L3 S2 V 100Mbps 75m 2 × 108 m/s L4 S2 S3 100Mbps 3,000km 2 × 108 m/s L5 S3 D 100Mbps 600m 2 × 108 m/s Switches Switch Links on Ports Processing Delay S1 L1, L2 1ms S2 L2, L3, L4 1ms S3 L4, L5 250µs The basic network topology is as below: Assumptions You may make the following assumptions about the network: • The network is packet-switched • The network starts with no other packets in queues - only packets that are a part of this question • Each link is bidirectional and can concurrently handle bits travelling in opposite directions • All required records are stored in the DNS server • C, D, and V have no processing delays (while this is unrealistic, this simplifies calculations) • DNS packets and TCP SYN, ACK, FIN, SYN/ACK, and FIN/ACK packets are 100 bytes long, including all headers, preamble, etc • HTTP GET and HTTP response packets are 1000 bytes long, including all headers, preamble, etc Scenario At time t = 0, a program on the client (C), starts the process of retrieving a webpage from the server (V). The following events happen sequentially: 1. C sends a DNS request to D 2. D sends a response with V’s IP address to C 3. C sends a TCP request (SYN) to open a connection to V 4. V acknowledges (SYN/ACK) the TCP request and opens the connections 5. C sends a HTTP GET request to V (which includes the ACK back to V for its SYN) 6. V sends the web page to C, which requires 5 packets, which includes the HTTP response plus the HTML file. 7. After receiving each data packet, C sends an ACK message back to V. Note that V does not need to wait for an ACK before sending the next data packet. 8. After receiving the last data packet acknowledgement, V sends a TCP FIN packet to close the connection. 9. After receiving FIN, C sends one FIN/ACK packet back to V. 10. After receiving FIN/ACK, V sends a final ACK packet back to C. 11. When this final ACK packet is received at C, the connection is finally closed. Questions Answer each of the following questions in the associated quiz on blackboard, following the specified instructions. All answers should be in milliseconds(ms) rounded to four decimal places. 1. At what time does D receive the DNS request from Client C? (2 marks) 2. At what time does C receive the DNS response from D? (2 marks) 3. At what time does V receive the TCP SYN request from Client C? (2 marks) 4. At what time does C receive the TCP SYN/ACK acknowledgement from Server V? (2 marks) 5. At what time does V receive the HTTP GET packet from Client C? (2 marks) 6. At what time does C receive the first packet of the HTTP response from Server V? (3 marks) 7. At what time does C receive the fifth (last) packet of the HTTP response from Server V? (3 marks) 8. At what time is the connection between Client C and Server V closed? (4 marks) HINT: Make sure you correctly convert between units Part B (25 marks) This question requires you to analyse the Wireshark file Assignment1b.pcap. This packet capture shows a client downloading a javascript resource file from a server, using TCP as a transport layer protocol. You will need to read some of the relevant IETF RFCs to understand some of the following questions. In particular: • RFC793 is the base TCP spec • RFC 791 describes the IP TTL option • RFC2018 describes the TCP SACK option • RFC7323 describes the Window Scale option Answer each of the following questions in the associated quiz on blackboard, following the specified instructions. All questions will be automatically marked. 1. What is the web browser being used by the sender? (1mark) 2. What is the web server software being used in the remote server? (1 mark) 3. Is protocol offloading being used at the client ? (1 mark) 4. How many routers are there between the client and server? (1 mark) Recall that Wireshark displays TCP sequence numbers as a value relative to the first sequence number. You will need to disable this to answer any questions that ask for a raw sequence number. It is highly recommended that you turn of TCP reassembly to understand the order of packet transmission. 5. What is the raw TCP sequence number of a. the packet initiating the TCP connection. (1 mark) b. the acknowledgement from the server for the above packet? (1 mark) Frame 4 shows a HTTP GET request from the client to the server. Questions 6 and 7 focus on this frame. 6. What are the values of the 8 TCP flags (CWR to FIN) as a single 8-digit binary number? For example, if FIN was set and the others unset, you would write 00000001. (2 marks) 7. The GET request is for a javascript file resource. What is the address of the web page that requested this javascript file resource? (1 mark) 8. How long should the received javascript file be considered fresh (in seconds) ? (1 mark) The following questions relate to window scaling. You should read RFC7323 before attempting these questions. 9. What is the initial value of the window scale shift count indicated by a. the client? (1 mark) b. the server? (1 mark) 10. The GET packet from the client to the server has an advertised window size of 46. What is the true window size in bytes? (3 marks) In packet 30, some data is lost. Questions 11-13 focus on these lost frames. 11. How many bytes are lost? (4 marks) 12. How many duplicate acknowledgments are sent by the client regarding the missing bytes? (2 marks) 13. In which frame is the lost frame retransmitted? (2 marks) 14. In which frame does the receiver indicate that all missing frames have been received? (2 marks) Part C (55 marks) The RUSH2 protocol (Reliable UDP Substitute for HTTP version 2) is a HTTP-like stop-and-wait protocol that uses UDP in conjunction with the RDT rules. You have recently been hired by the multinational tech giant COMS3200 Inc, who have identified your deep knowledge in the field of secure transport-layer protocols. You have been tasked to develop a network server capable of sending RUSH2 messages to a client. It is expected that the RUSH2 protocol is able to handle packet corruption, loss and encryption. Your server program must be written in Python, Java, C, or C++. NOTE: The RUSH2 protocol is not a real networking protocol. It has been created purely for this assignment. Program Invocation Your program should be able to be invoked from a UNIX command line as follows. It is expected that any Python programs can run with version 3.6, and any Java programs can run with version 8. Python C/C++ Java Python3 RUSH2Svr.py make ./RUSH2Svr make java RUSH2Svr IMPORTANT: As the assignment is auto marked, it is important that the filenames and command line syntax exactly matches the specification. Specification adherence is critical for passing. RUSH2 Packet Structure A RUSH2 packet can be expressed as the following structure (|| is concatenation): IP-header || UDP-header || RUSH2-header || ASCII-payload The data segment of the packet is a string of ASCII plaintext. Single RUSH2 packets must be no longer than 1500 bytes, including the IP and UDP headers (i.e. the maximum length of the data section is 1464 bytes). Packets that are smaller than 1500 bytes should be padded with 0 bits up to that size. The following table describes the header structure of a RUSH2 packet: Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 Sequence Number 16 Acknowledgement Number 32 Checksum (all 0, if not used) 48 1 Flags Reserved (should be 0) RUSH2 version code (1) The following sections describe each header in this packet further. Sequence and Acknowledgement Numbers Sequence numbers are independently maintained by the client and server. The first packet sent by either endpoint should have a sequence number of 1, and subsequent packets should have a sequence number of 1 higher than the previous packet (note that unlike TCP, RUSH2 sequence numbers are based on the number of packets as opposed to the number of bytes). When the ACK flag is set, the acknowledgement number should contain the sequence number of the packet that is being acknowledged. When a packet is retransmitted, it should use the original sequence number of