COMS3200/7201 Assignment 1Due: 20th April 2020, 20:00100 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 specifiedinstructions. 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 earthin geostationary orbit. The goal of this exercise is to use the following information to calculate the time for therequest 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, andS3) and five transmission links (L1 to L5) where L2 is the satellite link. The following tables provide furtherinformation about the network (bps == bits per second, 1 kbps == 103 bps, 1 Mbps == 106 bps).Transmission LinksLink Name Connected to Connected to Transmission Rate Length Propagation SpeedL1 C S1 100Mbps 300m 2 × 108 m/sL2 S1 S2 5kbps 36,000km 3 × 108 m/sL3 S2 V 100Mbps 75m 2 × 108 m/sL4 S2 S3 100Mbps 3,000km 2 × 108 m/sL5 S3 D 100Mbps 600m 2 × 108 m/sSwitchesSwitch Links on Ports Processing DelayS1 L1, L2 1msS2 L2, L3, L4 1msS3 L4, L5 250µsThe basic network topology is as below:AssumptionsYou 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 allheaders, preamble, etc• HTTP GET and HTTP response packets are 1000 bytes long, including all headers, preamble, etcScenarioAt time t = 0, a program on the client (C), starts the process of retrieving a webpage from the server (V). Thefollowing events happen sequentially:1. C sends a DNS request to D2. D sends a response with V’s IP address to C3. C sends a TCP request (SYN) to open a connection to V4. V acknowledges (SYN/ACK) the TCP request and opens the connections5. 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 HTMLfile.7. After receiving each data packet, C sends an ACK message back to V. Note that V does not need to waitfor an ACK before sending the next data packet.8. After receiving the last data packet acknowledgement, V sends a TCP FIN packet to close theconnection.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.QuestionsAnswer each of the following questions in the associated quiz on blackboard, following the specifiedinstructions.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 unitsPart B (25 marks)This question requires you to analyse the Wireshark file Assignment1b.pcap. This packet capture shows aclient downloading a javascript resource file from a server, using TCP as a transport layer protocol. You willneed 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 optionAnswer each of the following questions in the associated quiz on blackboard, following the specifiedinstructions. 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. Youwill need to disable this to answer any questions that ask for a raw sequence number. It is highlyrecommended that you turn of TCP reassembly to understand the order of packet transmission.5. What is the raw TCP sequence number ofa. 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, ifFIN 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 requestedthis 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 thesequestions.9. What is the initial value of the window scale shift count indicated bya. 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 truewindow 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 thatuses UDP in conjunction with the RDT rules. You have recently been hired by the multinational tech giantCOMS3200 Inc, who have identified your deep knowledge in the field of secure transport-layer protocols. Youhave been tasked to develop a network server capable of sending RUSH2 messages to a client. It is expectedthat the RUSH2 protocol is able to handle packet corruption, loss and encryption. Your server program mustbe 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 InvocationYour program should be able to be invoked from a UNIX command line as follows. It is expected that anyPython programs can run with version 3.6, and any Java programs can run with version 8.Python C/C++ JavaPython3RUSH2Svr.pymake./RUSH2Svrmakejava RUSH2SvrIMPORTANT: As the assignment is auto marked, it is important that the filenames and command line syntaxexactly matches the specification. Specification adherence is critical for passing.RUSH2 Packet StructureA RUSH2 packet can be expressed as the following structure (|| is concatenation):IP-header || UDP-header || RUSH2-header || ASCII-payloadThe data segment of the packet is a string of ASCII plaintext. Single RUSH2 packets must be no longer than1500 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 tabledescribes the header structure of a RUSH2 packet:Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 150 Sequence Number16 Acknowledgement Number32 Checksum (all 0, if not used)48 Flags ( 7 flags) Reserved (should be 0, 8 bits) 1RUSH2versioncodeThe following sections describe each header in this packet further.Sequence and Acknowledgement NumbersSequence numbers are independently maintained by the client and server. The first packet sent by eitherendpoint should have a sequence number of 1, and subsequent packets should have a sequence number of 1higher than the previous packet (note that unlike TCP, RUSH2 sequence numbers are based on the number ofpackets as opposed to the number of bytes). When the ACK flag is set, the acknowledgement number shouldcontain the sequence number of the packet that is being acknowledged. When a packet is retransmitted, itshould use the original sequence number of the packet being retransmitted. Any packet that isn’t aretransmission (including NAKs) should increment the sequence number.FlagsThe Flags section of the header is broken down into the following:Bit 0 1 2 3 4 5 60 ACK NAK GET DAT FIN CHK ENCThe purpose of these flags is described in the example below.RUSH2 ExampleThe following situat代写COMS3200/7201作业、代做data留学生作业、c++语言作业代做、c/c++编程作业调试 代做留学生Proion describes a simple RUSH2 communication session. Square brackets denote the flagsthat are set in each step (for example [FIN/ACK] denotes the FIN and ACK flags having the value 1 and the resthaving the value 0). Note that RUSH2, unlike TCP, is not connection-oriented. There is no handshake toinitialise the connection, but there is one to close the connection.1. The client sends a request packet to the server [GET]• The sequence number of this packet will always be 1• The data section of this packet will contain the name of a resource (e.g. file.txt)2. The server transmits the requested resource to the client over (possibly) multiple packets [DAT]• The first packet should have a sequence number of 13. The client acknowledges having received each data packet [DAT/ACK]• The acknowledgement number of this packet should be the sequence number of the packet beingacknowledged4. After receiving the last acknowledgement, the server signals the end of the connection [FIN]5. The client acknowledges the connection termination [FIN/ACK]6. The server acknowledges the client’s acknowledgement and terminates the connection [FIN/ACK]All RUSH2 Servers are capable of checksum and encryption. During the initial [GET], Clients can negotiaterequests for checksum, encryption or both. This is done using [CHK] for checksum and [ENC] for encryptionin the very first [GET] packet. The first [DAT] from the RUSH2 Server will indicate if negotiation wassuccessful by setting the appropriate [CHK], [ENC] flags. Once negotiated, these options are valid for allpackets until a [FIN/ACK] closes the connection.RUSH2 checksum uses the standard Internet checksum on the payload only. As per the RFC, “the checksumfield is the 16-bit ones complement of the ones complement sum of all 16-bit words in the header”. Once[CHK] is negotiated, all packets that have invalid checksums are considered corrupt.The following are two examples of the checksum process.ASCII payload16 bit wordsChecksumabcde0x6261 0x6463 0x650x38d6at 12.300x7461 0x3120 0x2e32 0x30330xfc18RUSH2 uses symmetric-key cryptography based on Caesar cipher with a key of 3. The entire ASCII table isrotated by the key value. This is used to encode the payload when using [ENC]. Note that the padding is notencoded and remains as 0 bits. In order to carry out the encode/decode process, RUSH2 encodes the ASCIIstring, one character at a time.The following are two examples of the encryption outcomes.ASCII payloadEncrypted contentab &cde#)f12.5%4518(The following takes place when [ENC] is negotiated for all packets until [FIN/ACK].1. Client encodes the ASCII plaintext payload2. Client computes and adds the checksum if [CHK] was negotiated3. Client sends the packet4. On receiving a packet, the checksum is checked if [CHK] was negotiated.5. The packet is decoded to obtain the original payloadNote that [CHK] takes precedence over [ENC]. This results in any corrupt packet being discarded early withenhances the RUSH2 performance.Your TaskBasic Server Functionality (5 marks)To receive marks in this section you need to have a program that is able to:• Listen on an unused port for a client’s message• Successfully close the connectionWhen invoked, your program should let the OS choose an unused localhost port and your program shouldlisten on that port. It should output that port as a raw base-10 integer to stdout. For example, if Python wasused and port 54321 was selected, your program invocation would look like this:python3 RUSH2Svr.py54321Any lines in stdout after the port number can be used for debugging. For this section, your program does notneed to respond to the GET request. Upon hearing from a client, your program can immediately signal the endof the connection (as described in the example). Once the FIN handshake has been completed, your programshould terminate.You may always assume that only one client will connect to the server at a time. For this section and the nextyou may also assume that no packets are corrupted or lost during transmission. You need not implement[CHK] or [ENC] for this part.File Transmission (10 marks)To receive marks in this section you need to have a program that is able to:• Perform all features outlined in the above section• Successfully transmit a requested file over one or more packets• Receive (but not handle) ACKs from the client during transmissionWhen your server receives a GET packet, it should locate the file being requested and return the file’s contentsover one or more DAT packets. When complete, the server should close the connection (as in the abovesection). You may assume that the file being requested always exists (it is expected that this file is stored inyour program’s working directory). You need not implement [CHK] or [ENC] for this part.Retransmission (15 marks)To receive marks in this section you need to have a program that is able to:• Perform all features outlined in the above sections• Retransmit any packet on receiving a NAK for that packet• Retransmit any packet that has not been acknowledged within 4 seconds of being sentA client will send a DAT/NAK packet should it receive a corrupted packet or a packet with a sequence numberit wasn’t expecting (the NAK packet’s acknowledgement number will contain the sequence number it wasexpecting). In this case your program should retransmit the packet with that sequence number.If a DAT, FIN, or ACK packet gets lost during transmission your program should retransmit it after 4 secondswithout acknowledgement. If a NAK is received the timer should reset. How you choose to handle timeouts isup to you, however it must work on a UNIX machine (moss). Achieving this through multithreading,multiprocessing, or signals is fine provided if you only use standard libraries. You need not implement [CHK]or [ENC] for this part.Packet integrity (15 marks)RUSH2 is capable of detecting packet corruption using checksums.To receive marks in this section you need to have a program that is able to:• Perform all features outlined in the above sections• Implement the [CHK] mode negotiation and ignore packets with corrupt checksums if CHK mode isin useWhen a packet with incorrect checksum arrives, your program should ignore it and continue to run withouterror. Any retransmission timer should also not stop or reset. You must also ensure that if CHK was negotiatedat the start, all packets must have a valid checksum. You need not implement [ENC] for this part.Secure communication (10 marks)RUSH2 is also capable of packet level encryption.To receive marks in this section you need to have a program that is able to:• Perform all features outlined in the above sections• Implement the [ENC] mode negotiation and encode outgoing and decode incoming packets when ENCmode is in useYou must also ensure that if ENC was negotiated at the start, all packets are to be encoded and decoded.Tips for Success• Revisit the lectures and labs on reliable data transfer and TCP, ensuring you are familiar with thefundamentals• Frequently test your code on moss• Ensure your base functionality is working before attempting the more difficult tasks• Start early - there will be limited help during the mid-semester break so any questions will need to beasked in labs beforehandLibrary Restrictions• The only communication libraries you may use are standard socket libraries which open UDP sockets• You can’t use any libraries that aren’t considered standard for your language (i.e. if you have todownload a library to use it should be considered as non-standard. You will need to implement CHK andENC using standard libs only, writing your own code. Scapy is not permitted)• If you are unsure about whether you may use a certain library, please ask the course staff on PiazzaSubmissionSubmit all files necessary to run your program. At a minimum, you should submit a file namedRUSH2Svr.py, RUSH2Svr.c, RUSH2Svr.cpp or RUSH2Svr.java. If you submit a C/C++ or Javaprogram, you should also submit a makefile to compile your code into a binary named RUSH2Svr or a .classfile named RUSH2Svr.class.IMPORTANT: If you do not adhere to this (e.g. submitting a C/C++/Java program without a Makefile, or a.class file instead of a .java file), you will receive 0 for this part of the assignment.MarkingYour code will be automatically marked on a UNIX machine, so it is essential that your program’sbehaviour is exactly as specified above. Your program should complete all tasks within a reasonable timeframe (for example a single packet should not take more than one second to construct and send) - there willbe timeouts on all tests and it is your responsibility to make sure your code is not overly inefficient. It isexpected that you will receive a small sample of tests and a basic RUSH2 client program before the submissiondeadline.There are no marks for coding style.Academic MisconductStudents are reminded of the University’s policy on student misconduct, including plagiarism. See the courseprofile and the School web page http://www.itee.uq.edu.au/itee-student-misconduct-including-plagiarism.Late Submission and ExtensionsPlease view the ECP for policies on late submissions and extensions as well as updates based on COVID-19situation.Version History24/03/2020 Initial release 1.026/03/2020 Corrected Internet checksum example 1.109/04/2020 Improved RUSH2 header image, added checksum missing values 1.2转自：http://www.daixie0.com/contents/13/4959.html
