Homework 2 50 points. CSE422 Computer Networking Spring 2018

Transcription

1 Homework 2 50 points ATM Application-Level Protocol (10 points) Design and describe an application-level protocol to be used between an automatic teller machine and a bank s centralized computer. Your protocol should allow a user s card and password to be verified, the account balance (which is maintained at the centralized computer) to be queried, and an account withdrawal to be made (that is, money disbursed to the user). Your protocol entities should be able to handle the all-too-common case in which there is not enough money in the account to cover the withdrawal. Specify your protocol by listing the messages exchanged and the action taken by the automatic teller machine or the bank s centralized computer on transmission and receipt of messages. Sketch the operation of your protocol for the case of a simple withdrawal with no errors, using a diagram similar to that in Figure 1.2. Explicitly state the assumptions made by your protocol about the underlying end-to-end transport service. There is no single right answer to this question. Many protocols would do the trick. Here's a simple answer below: Messages from ATM machine to Server Msg name HELO <userid> PASSWD <passwd> BALANCE WITHDRAWL <amount> BYE Purpose Let server know that there is a card in the ATM machine ATM card transmits user ID to Server User enters PIN, which is sent to server User requests balance User asks to withdraw money user all done Messages from Server to ATM machine (display) Msg name Purpose PASSWD Ask user for PIN (password) OK last requested operation (PASSWD, WITHDRAWL) OK ERR last requested operation (PASSWD, WITHDRAWL) in ERROR AMOUNT <amt> sent in response to BALANCE request BYE user done, display welcome screen at ATM

2 Correct operation: client server HELO (userid) > (check if valid userid) < PASSWD PASSWD <passwd> > (check password) < OK (password is OK) BALANCE > < AMOUNT <amt> WITHDRAWL <amt> > check if enough $ to cover withdrawl < OK ATM dispenses $ BYE > < BYE In situation when there's not enough money: client server HELO (userid) > (check if valid userid) < PASSWD PASSWD <passwd> > (check password) < OK (password is OK) BALANCE > < AMOUNT <amt> WITHDRAWL <amt> > check if enough $ to cover withdrawal < ERR (not enough funds) error msg displayed no $ given out BYE > < BYE The HTTP GET message (10 Points) Consider the figure below, where a client is sending an HTTP GET message to a web server, gaia.cs.umass.edu. Suppose the client-to-server HTTP GET message is the following: GET /kurose_ross/interactive/quotation1.htm HTTP/1.1 Host: gaia.cs.umass.edu Accept: text/plain, text/html, image/gif, image/jpeg, audio/basic, audio/vnf.wave, video/mp4, video/wmv, application/*, */* Accept-Language: en-us, en-gb;q=0.5, en;q=0.1, fr, fr-ch, zh, cs If-Modified-Since: Wed, 10 Jan :13:

3 User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Answer the following questions: 1. What is the name of the file that is being retrieved in this GET message? 2. What version of HTTP is the client running? 3. What formats of text, images, audio, and video does the client browser prefer to receive? [Note: for this and the following questions on browser media and language preferences, you will need to do a bit of additional reading on the Web. Here is a good place to start.] 4. What do the strings "application/*" and "*/*" signify in the Accept: header? 5. What languages is the browser indicating that it is willing to accept? [Note: you can look at your own browser preferences to get a listing of language codes.] 6. What is the meaning of the "relative quality factor," q, associated with the various version of English? [Note: Here is a good place to start. See also [RFC 2616].] 7. What is the client's preferred version of English? What is the browser's least preferred version of English? 8. Does the browser sending the HTTP message prefer Swiss French over traditional French? Explain. 9. Does the client already have a (possibly out-of-date) copy of the requested file? Explain. If so, approximately how long ago did the client receive the file, assuming the GET request has just been issued? 10. What is the type of client browser and the client's operating system? [Note: To answer this, you'll need to understand the User Agent: header field. Here is a good place to start.] 1. The file being fetched is /kurose_ross/interactive/quotation1.htm 2. The client is running HTTP version The accepted media types are text/plain (Textual data; defined in RFC 2046 and RFC 3676), text/html (HTML; defined in RFC 2854), image/gif (GIF image; defined in RFC 2045 and RFC 2046), image/jpeg (JPEG image; defined in RFC 2045 and RFC 2046), audio/basic (mulaw audio at 8 khz, 1 channel; defined in RFC 2046), audio/vnf.wave (WAV audio; defined in RFC 2361), video/mp4 (MP4 video; defined in RFC 4337), video/wmv (Windows Media Video; documented in Microsoft KB ) 4. The application/* media type specification indicates the browser will accept all subtypes of the application type, and */* indicates that the browser will accept all media types and subtype, making the application/* a bit redundant. 5. The accepted languages are en-us (American English), en-gb (British English), en (English), fr (French), fr-ch (Swiss French), zh (Chinese), cs (Czech). 6. The relative quality factor, q, "indicate[s] the relative degree of preference for that mediarange, using the qvalue scale from 0 to 1" [RFC 2616]. A smaller value of q indicates that the browser prefers that media subtype less.

4 7. The browser prefers American English, since it has an implicit q value of 1, but will accept either British English or vanilla English. The browser's least preferred version of English is vanilla English, since that has a smaller q value than British English. 8. The browser has no relative preference for vanilla French or Swiss French, as neither has a specified q value. 9. The time indicated in the browser's If-Modified-Since header field is approximately 41 minutes ago, indicating that is has a cached copy. Therefore the server will only send a copy of the requested URL in response to this HTTP GET message if the server-side copy has been changed in the last 41 minutes. 10. The browser's User Agent: header field value of Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ indicates that the browser/os type is Chrome 17.0, Win7 64-bit. The HTTP RESPONSE message (10 Points) Consider the figure below, where the server is sending a HTTP RESPONSE message back the client. Suppose the server-to-client HTTP RESPONSE message is the following: HTTP/ OK Date: Wed, 10 Jan :23: Server: Apache/2.2.3 (CentOS) Last-Modified: Wed, 10 Jan :35: ETag:17dc6-a5c-bf Content-Length: Keep-Alive: timeout=41, max=92 Connection: Keep-alive Content-type: image/html Answer the following questions: 1. Is the response message using HTTP 1.0 or HTTP 1.1? Explain. 2. Was the server able to send the document successfully? Explain 3. At what date and time was this response sent? 4. When was the file last modified on the server?

5 5. How many bytes are there in the document being returned by the server? 6. What is the default mode of connection for HTTP protocol? Is the connection in the reply persistent or non-persistent? Explain. 7. What is the type of file being sent by the server in response? 8. Does the response message use separate keep-alive messages? 9. What is the name of the server and its version? List the advantages of the server used. 10. What is the timeout value for the response message? 1. The server is running HTTP version Yes, the server was able to send the document successfully. The status code 200 OK signifies the successful file transfer. 3. The response was sent at Date: Wed, 10 Jan :23: by the server. 4. The file was last modified at Last-Modified: Wed, 10 Jan :35: on the server. 5. There are bytes in the document being returned by the server. 6. The default mode of connection in HTTP is persistent. It is set as the default mode since it has several advantages which contribute to enhance the HTTP performance. Persistent connection allows less network traffic due to fewer setting up and tearing down of TCP connections. It has reduced latency on subsequent request due to avoidance of initial TCP handshake. It has long lasting connections allowing TCP sufficient time to determine the congestion state of the network, thus to react appropriately. The connection in the reply is persistent which is shown in the Connection: Keep-alive header. 7. The type of file is image/html. 8. The HTTP persistent connections do not use separate keepalive messages, they just allow multiple requests to use a single connection. 9. The server used is Apache/ The timeout value for the response message is 41. DNS and HTTP delays (10 points) Before doing this question, you might want to review sections and on HTTP (in particular the text surrounding Figure 2.7) and the operation of the DNS (in particular the text surrounding Figure 2.19). Suppose within your Web browser you click on a link to obtain a Web page. The IP address for the associated URL is not cached in your local host, so a DNS lookup is necessary to obtain the IP address. Suppose that four DNS servers are visited before your host receives the IP address from DNS. The first DNS server visited is the local DNS cache, with an RTT delay of RTT 0 = 1 msecs. The second, third and fourth DNS servers contacted have RTTs of 31, 47, and 25 msecs, respectively. Initially, let's suppose that the Web page associated with the link contains exactly one object, consisting of a small amount of HTML text. Suppose the RTT between the local host and the Web server containing the object is RTT HTTP = 14 msecs.

6 1. Assuming zero transmission time for the HTML object, how much time elapses from when the client clicks on the link until the client receives the object? 2. Now suppose the HTML object references 7 very small objects on the same web server. Neglecting transmission times, how much time elapses from when the client clicks on the link until the base object and all 7 additional objects are received from web server at the client, assuming non-persistent HTTP and no parallel TCP connections? 3. Repeat 2. above but assume that the client is configured to support a maximum of 5 parallel TCP connections, with non-persistent HTTP. 4. Repeat 2. above but assume that the client is configured to support a maximum of 5 parallel TCP connections, with persistent HTTP. 5. What do you notice about the overall delays (taking into account both DNS and HTTP delays) that you computed in cases 2., 3. and 4. above? 1. The time from when the Web request is made in the browser until the page is displayed in the browser is: RTT 0 + RTT 1 + RTT 2 + RTT 3 + 2*RTT HTTP = *14 = 132 msecs. Note that 2 RTT HTTPs are needed to fetch the HTML object - one RTT HTTP to establish the TCP connection, and then one RTT HTTP to perform the HTTP GET/response over that TCP connection. 2. The time from when the Web request is made in the browser until the page is displayed in the browser is: RTT 0 + RTT 1 + RTT 2 + RTT 3 + 2*RTT HTTP + 2*7*RTT HTTP = *14 + 2*7*14 = 328 msecs. Note that two RTT HTTP delays are needed to fetch the base HTML object - one RTT HTTP to establish the TCP connection, and one RTT HTTP to send the HTTP request, and receive the HTTP reply. Then, serially, for each of the 7 embedded objects, a delay of 2*RTT HTTP is needed - one RTT HTTP to establish the TCP connection and then one RTT HTTP to perform the HTTP GET/response over that TCP connection. 3. The time from when the Web request is made in the browser until the page is displayed in the browser is: RTT 0 + RTT 1 + RTT 2 + RTT 3 + 2*RTT HTTP + 2*RTT HTTP + 2*RTT HTTP = *14 + 2*14 + 2*14 = 188 msecs. As in 2. above, two RTT HTTP delays are needed to fetch the base HTML object - one RTT HTTP to establish the TCP connection, and one RTT HTTP to send the HTTP request, and receive the HTTP reply containing the base HTML object. Once the base object is received at the client, the maximum of five requests can proceed in parallel, each retrieving one of the 7 embedded objects. Each (in parallel) requires two RTT HTTP delays - one RTT HTTP to set up

7 the TCP connection, and one RTT HTTP to perform the HTTP GET/response for an embedded object. Once these first five objects have been retrieved, the remaining 2 embedded objects can be retrieved (in parallel). This second round of HTTP GET/response to retreive the remaining 2 embedded objects takes two more RTT HTTP delays. 4. The time from when the Web request is made in the browser until the page is displayed in the browser is: RTT 0 + RTT 1 + RTT 2 + RTT 3 + 2*RTT HTTP + RTT HTTP + RTT HTTP = * = 160 msecs. As in 2. and 3. above, two RTT HTTP delays are needed to fetch the base HTML object - one RTT HTTP to establish the TCP connection, and one RTT HTTP to send the HTTP request, and receive the HTTP reply containing the base HTML object. However, with persistent HTTP, this TCP connection will remain open for future HTTP requests, which will therefore not incur a TCP establishment delay. Once the base object is received at the client, the maximum of five requests can proceed in parallel, each retrieving one of the 7 embedded objects. Each (in parallel) requires only one RTT HTTP delay performing the HTTP GET/response for an embedded object. Once these first five objects have been retrieved, the remaining 2 embedded objects can be retrieved (in parallel). This second round of HTTP GET/response to retreive the remaining 2 embedded objects takes only one more RTT HTTP delays, since the TCP connection has remained open. 5. The delay in case 4 is less than the delay in case 3, which is less than the delay in case 2. Question: TCP VS UDP Why is it that voice and video traffic is often sent over TCP rather than UDP in today s Internet? (Hint: the answer we are looking for has nothing to do with TCP s congestion-control mechanism.) Since most firewalls are configured to block UDP traffic, using TCP for video and voice traffic lets the traffic though the firewalls. Question: Reliable UDP data transfer (5 points) Is it possible for an application to enjoy reliable data transfer even when the applications run over UDP? If so, how? Yes. The application developer can put reliable data transfer into the application layer protocol. This would require a significant amount of work and debugging, however. Question: NAK-only vs ACK-only (5 points) Consider a reliable data transfer protocol that uses only negative acknowledgments. Suppose the sender sends data only infrequently. Would a NAK-only protocol be preferable to a protocol that uses ACKs? Why? Now suppose the sender has a lot of data to send and the end-to-end connection experiences few losses. In this case, would a NAK-only protocol be preferable to a protocol that uses ACKs? Why? In a NAK only protocol, the loss of packet x is only detected by the receiver when packet x+1 is received. That is, the receiver receives x-1 and then x+1, only when x+1 is received does the receiver realize that x was missed. If there is a long delay between the transmission of x and the transmission of x+1, then it will be a long time until x can be recovered, under a NAK only protocol. On the other hand, if data is being sent often, then recovery under a NAK-only scheme could happen quickly. Moreover, if errors are infrequent, then NAKs are only occasionally sent (when needed), and ACK are never sent a significant reduction in feedback in the NAK-only case over the ACK-only case.