代做COMP3331 9331 Lab Exercise 2: HTTP & Socket Programming代做Java程序

日期：2024-09-25 05:44

COMP3331 9331 Computer Networks and Applications

Lab Exercise 2: HTTP & Socket Programming

· Specification

· Make Submission

· Check Submission

· Collect Submission

Objectives:

· Gain insights into the operation of HTTP.

· Get familiar with basic socket programming.

· Preparation for programming assignment.

Prerequisites:

· Week 2 Lectures

· Relevant Parts of Chapter 2 of the textbook (Sections 2.2 on HTTP and 2.7 on Socket Programming)

· Basic understanding of Linux. A good resource is here , but there are several other resources online.

· Several socket programming resources and sample codes for all three programming languages are available on this page .

· PingServer.java

· http-wireshark-trace-1

· http-wireshark-trace-2

Marks: 10 marks

· This lab comprises several exercises. Please note that not all the exercises for this lab are marked. You have to submit a report containing answers to selected exercises only.

· Please attend the lab in your allocated lab time slot.

· We expect the students to go through as many lab exercises as possible at home and come to the lab to clarify any doubts about the procedure/specifications.

Deadline:

10:00 am Tuesday 01 /10/2024 . You can submit as many times as you wish before the deadline. A later submission will override the earlier submission, so make sure you submit the correct file. Do not leave until the last moment to submit, as there may be technical or communications errors, and you will not have time to rectify them.

ELP (Equitable Learning Plan) Arrangements : If you have submitted ELP documentation and wish to avail of your conditions, you must contact cs3331@cse.unsw.edu.au .

Late Report Submission Penalty:

A late penalty will be applied as follows:

· up to 24 hours after the deadline: 5% reduction

· more than 24 hours and less than 48 hours after the deadline: 10% reduction

· more than 48 hours after the deadline: NOT accepted

Note that the above penalty is applied to your final mark in the report. For example, if you submit your lab report 2 days late and your score on the lab is 8, then your final mark will be 8 - 0.8 (10% penalty) = 7.2.

No submissions will be accepted after 10 :00 am Thursday, 03/10/2024.

Submission Instructions:

Prepare a PDF document, Lab2.pdf, with answers to all questions for all exercises and PingClient.py or PingClient.java or PingClient.c (Depending on your pogramming language of choice) . Submit the report/code files using the give or WebCMS interface. You can submit it from a lab machine or SSH into the CSE login server. Instructions to ssh into CSE login servers are here .

1. Save your report as Lab2.pdf and codes

2. Next, type: give cs3331 Lab2 Lab2.pdf PingClient.py (For python code)

If you want to include other supporting documents along with the report, create a tar archive of all the files called Lab2.tar.

1. Put all your files (e.g., Lab2.pdf, PingClient.py, output.txt) in a directory lab2.

2. Type “tar -cvf Lab2.tar lab2”

3. Next, type: give cs3331 Lab2 Lab2.tar (Or use WebCMS interface)

· Please make sure that the tar archive is not corrupted. You can untar (use tar -xvf Lab2.tar) the created archive to check that all the files are intact.

· The maximum file size for submission is 25 MB .

· COMP9331 students should also use 'give cs3331'

Original Work Only:

You are strongly encouraged to discuss the questions with other students in your lab. However, each student must submit his or her own work. You may need to refer to the material indicated above (particularly socket programming links) and conduct your own research to answer the questions.

System Compatibility (Very Important):

We will test your code on CSE machines via the command-line interface. Note that CSE machines support gcc version 12.2, Java ( openjdk 17.0.10 ), Python 3.11. Thus, you must test your code on CSE machines before submitting it. This is particularly important if you write your code on your own machine and use an IDE. Before submitting, you MUST test your code on CSE machines (via the command line). If we cannot get your code to work on CSE machines, then we can't mark it, and unfortunately, you won't receive any marks. This point is also relevant to the assignment.

Exercise 1: Using Telnet to interact with a Web Server (Unmarked, not to be included in the report)

Follow the steps described below.

Step 1: Open an xterm window. Enlarge the size of your xterm window so that it is reasonably large and covers almost the entire screen.

Step 2: Telnet to the vision.ucla.edu web server by typing:

$telnet vision.ucla.edu 80

Note that the port number for all web servers is “80”.

Step 3: Retrieve the main webpage by typing:

GET / HTTP/1.1

host: www.vision.ucla.edu

Important Note : Press the carriage return twice after typing the last line.

Question 1: What is the content type of the response? What is the size of the response? When was the webpage last modified? Do you see an "Accept-Ranges" header field? What may this be used for?

Step 4: Now execute the HEAD method. When a server receives a request with the HEAD method, it responds with only the message header lines (i.e. the response to the GET method minus the actual requested object).

HEAD / HTTP/1.1

host: www.vision.ucla.edu

Question 2: What is the content type of the response? What is the size of the response?

Question 3: Using telnet, find a way to get the people.html webpage from vision.ucla.edu

Question 4: Why must the host be included in the GET (and HEAD) HTTP 1.1 request messages?

Exercise 2: Understanding Internet Cookies (unmarked, not to be included in the report)

Question 1. Repeat steps 1-3 in the previous experiment for www.google.com.au . Does the site set a cookie in your browser? How can you tell by purely examining the HTTP response message received using telnet? How about www.vision.ucla.edu? Do you think this site will set a cookie in your browser?

Question 2. Open a web browser (Firefox/IceWeasel/Mozilla preferred). Go to the browser preferences and remove all existing cookies. Access the Google home page and then view the cookies. How many cookies are stored on your machine? Which sites installed the cookies?

Exercise 3: Using Wireshark to understand basic HTTP request/response messages (2.5 marks, include in your report)

We will not be running Wireshark on a live network connection (You are strongly encouraged to try this on your native machine. Pointers are provided at the end of this exercise). The CSE network administrators do not permit live traffic monitoring for security reasons. Instead, for all our lab exercises, we will use several trace files collected by running Wireshark by one of the textbook’s authors. For this particular experiment, download the following trace file: http-wireshark-trace-1

NOTE: IT IS NOT POSSIBLE TO RUN WIRESHARK VIA SSH. IT IS A RESOURCE-INTENSIVE PROGRAM, AND IT WOULD SLOW DOWN THE CSE LOGIN SERVERS. IF YOU WANT TO WORK REMOTELY, THEN MAKE SURE YOU ARE USING VLAB. WIRESHARK IS AVAILABLE ON ALL LAB MACHINES AND IN VLAB. HOWEVER, IT CANNOT BE INVOKED FROM THE COMMAND LINE. INSTEAD, GO TO THE APPLICATION MENU AND SELECT "INTERNET" AND "WIRESHARK". YOU CAN ALSO DOWNLOAD AND INSTALL WIRESHARK ON YOUR PERSONAL MACHINE.

The following indicates the steps involved:

Step 1: Start Wireshark natively on your machine or through VLAB, as noted above.

Step 2: Load the trace file http-wireshark-trace-1 using the File pull-down menu, choosing Open and selecting the appropriate trace file. This trace file captures a simple request/response interaction between a browser and a web server.

Step 3: You will see many packets in the packet listing window. Since we are currently only interested in HTTP, we will filter out all the other packets by typing “http” in lowercase in the Filter field and pressing Enter. You should now see only HTTP packets in the packet-listing window.

Step 4: Select the first HTTP message in the packet-listing window and observe the data in the packet-header detail window. Recall that since each HTTP message is encapsulated inside a TCP segment, which is encapsulated inside an IP datagram, which is encapsulated within an Ethernet frame, Wireshark displays the Frame, Ethernet, IP, and TCP packet information as well. We want to minimize the amount of non-HTTP data displayed (we’re interested in HTTP here and will be investigating these other protocols in later labs), so make sure the boxes at the far left of the Frame, Ethernet, IP and TCP information have a right-pointing arrowhead (which means there is hidden, undisplayed information), and the HTTP line has a down-pointing arrowhead (which means that all information about the HTTP message is displayed).

NOTE: Please neglect the HTTP GET and response for favicon.ico, (the third and fourth HTTP messages in the trace file. Most browsers automatically ask the server if the server has a small icon file that should be displayed next to the displayed URL in the browser. We will ignore references to this pesky file in this lab.)

By looking at the information in the HTTP GET and response messages (the first two messages), answer the following questions:

Question 1: What is the status code and phrase returned from the server to the client browser?

Question 2: When was the HTML file the browser retrieves last modified at the server? Does the response also contain a DATE header? How are these two fields different?

Question 3: Is the connection established between the browser and the server persistent or non-persistent? How can you infer this?

Question 4: How many bytes of content are being returned to the browser?

Question 5: What is the data contained inside the HTTP response packet?

Note: Students are strongly encouraged to use Wireshark to capture real network traffic on their own machines. Check https://www.wireshark.org/download.html for details. Once you have Wireshark installed, do the following. Clear your web browser's cache (Firefox->Tools->Clear Recent History). Launch the Wireshark tool by typing Wireshark in the command line. Start Wireshark capture by clicking on capture -> interfaces -> click Start on the interface eth0. Run the Web browser and enter a URL for a website (e.g. www.bbc.co.uk ). Stop capturing packets when the web page is fully loaded. Examine the captured trace and answer the questions above. This is just for you to try in your own time. You do not have to include this in your report.

Exercise 4: Using Wireshark to understand the HTTP CONDITIONAL GET/response interaction (2.5 marks, include in your report)

For this particular experiment, download the second trace file: http-wireshark-trace-2

The following indicates the steps for this experiment:

Step 1: Start Wireshark natively on your machine or through VLAB, as noted above.

Step 2: Load the trace file http-wireshark-trace-2 using the File pull-down menu, choosing Open and selecting the appropriate trace file. This trace file captures a request-response between a client browser and a web server where the client requests the same file from the server within a few seconds.

Step 3: Filter out all the non-HTTP packets and focus on the HTTP header information in the packet-header detail window.

We will focus on the first two GET requests and the corresponding responses (the first 4 HTTP messages).

Question 1: Inspect the contents of the first HTTP GET request from the browser to the server. Do you see an “IF-MODIFIED-SINCE” line in the HTTP GET?

Question 2: Does the HTTP response from the server indicate the last time the requested file was modified?

Question 3: Now inspect the contents of the second HTTP GET request from the browser to the server. Do you see the “IF-MODIFIED-SINCE:” and “IF-NONE-MATCH” lines in the HTTP GET? If so, what information is contained in these header lines?

Question 4: What is the HTTP status code and phrase returned from the server in response to this second HTTP GET? Did the server explicitly return the file's contents? Explain.

Question 5: What is the value of the Etag field in the 2nd response message, and how is it used? Is the Etag value the same as in the 1 st response?

Exercise 5: Ping Client (5 marks, submit source code as a separate file, include sample output in the report)

Objective:

In this exercise, you will implement a Ping client using UDP, similar to the standard Ping tool, with enhanced functionality. You will calculate Round-Trip Time (RTT) and report additional statistics such as the percentage of packets acknowledged, total transmission time, and jitter. The server, PingServer.java , is provided and simulates network conditions by introducing packet loss and delays.

Ping Server (Provided):

You are given the code for the Ping server ( PingServer.java ). The server listens for UDP packets and responds with the same data it receives. However, the server may drop packets or delay responses based on predefined parameters.

Your Task: Implementing Ping Client

You will implement a client ( PingClient.java, PingClient.c, or PingClient.py ) that performs the following tasks:

1. Send 15 ping requests to the server.

2. Each ping request should include:

o The keyword PING .

o A sequence number starting from a random number between 10,000 and 20,000.

o A timestamp indicating when the message was sent.

3. Wait up to 600 ms for a response from the server. If no response is received within this time, record it as a timeout (packet lost).

4. Report the following statistics:

o RTT for each successful ping.

o Minimum RTT , Maximum RTT , and Average RTT .

o Percentage of packets acknowledged (i.e., received a response).

o Total transmission time (from first sent packet to the last received response or timeout).

o Jitter (variance in RTT between successive packets).

Example Command to Run the Client:

Java

$javac PingClient.java

$java PingClient

C

$gcc -o PingClient PingClient.c

$./PingClient

Python

$python3 PingClient.py

Where  is the IP address of the server (use 127.0.0.1 for localhost) and is the port number on which the server is listening.

Detailed Reporting:

The client must report the following at the end of execution:

· RTT for each ping request (or "timeout" if no response).

· Minimum RTT, Maximum RTT , and Average RTT for the successful pings.

· Percentage of packets acknowledged (i.e., how many responses were received out of 15 pings).

· Total transmission time (time from sending the first ping to receiving the last response).

· Jitter , which measures the variance in RTT values between successive pings. ( Jitter = Sum of (|RTT(n) - RTT(n-1)|) / (Number of packets received - 1))

Ping to 127.0.0.1, seq=10215, rtt=120 ms

Ping to 127.0.0.1, seq=10216, rtt=200 ms

Ping to 127.0.0.1, seq=10217, rtt=timeout

Ping to 127.0.0.1, seq=10218, rtt=150 ms

...

Total packets sent: 15

Packets acknowledged: 12

Packet loss: 20%

Minimum RTT: 50 ms, Maximum RTT: 200 ms, Average RTT: 120 ms

Total transmission time: 2000 ms

Jitter: 25 ms

Marking Criteria (5 Marks):

1. Correct implementation of the ping protocol and handling of packet loss (2.5 marks):

o This includes correct handling of packet transmission, timeout, and managing packet loss as per the server's behavior.

2. Accurate calculation and display of RTT for each successful ping (1.5 marks):

o RTT should be calculated accurately for every ping request that receives a response.

3. Proper reporting of packet acknowledgment percentage, total transmission time, and jitter (1 mark):

o Includes accurate reporting of additional statistics like packet acknowledgment percentage, total transmission time, and jitter.

Resource created about a month ago, last modified 2 days ago.