CPSC 471辅导 、讲解 Python语言程序
CPSC 471-05 Assignment
Introduction
At the heart of the communication involving a browser and a server, RFC 2616 defines the fun damental protocol that governs interactions between internet devices. The result was known as
the HTTP protocol. In this assignment, we will capture HTTP traffic using Wireshark packet sniff er and examine various HTTP header information and their applications in details.
HTTP provides a very important feature that enables browser caching mechanism. The results
are improved user’s experiences, significant reduction in communication link bandwidth re quirement and expenses. We will observe HTTP caching mechanism interactions in details.
Finally, the benefit of network architectural design layering approach becomes clear when we
develop internet-enabled applications that seamlessly exchange data between host devices
across the internet using socket programming.
Required Softwares
Wireshark 4.4.0 or newer
Python 3.12.6 or newer.
Submission
Submit in Canvas only. Submission using other methods outside Canvas will not be accepted.
For this assignment, Canvas was set up to only accept .zip file.
Reminders:
Click on your submitted file in Canvas to download it back to your PC, and verify that the
submitted file is not corrupted and that it contains the exact files required from you for
this assignment.
Give yourself plenty of time to accomplish this. Running out of time, or submitting an in correct file, corrupted file will be treated as No Submission.
File Size Limitation
Maximum allowable submission file size is 10MB. A penalty of 10% will be deducted for each 10
MB in excess of the allowed 10 MB limit.
Page 1 of 19
Page 2 of 19
Submission Grace Period
According to our class syllabus you have a 24-hour window after the due-date time to submit
before the assignment closing-date time with a 10% late penalty.
Note: The assignment due date and time, and the assignment closing date and time are clearly
shown on Canvas. Once the assignment is closed you can no longer submit.
What To Submit
Submit one zip file using naming convention fullname.zip in Canvas.
The zip file shall contain all below listed files and must follow the naming convention as shown:
(1) One PDF report file xxReport.pdf.
Note: This must be a Portable Document Format (PDF) file. Word documents are vul nerable to macro viruses and may not be graded.
(2) Wireshark capture file from Part 1a xxP1a.pcapng
(3) Wireshark capture file from Part 1b xxP1b.pcapng
(4) Wireshark capture file from Part 1c xxP1c.pcapng
(5) Wireshark capture file from Part 1d xxP1d.pcapng
(6) Wireshark capture file from Part 1e xxP1e.pcapng
(7) Python UDP client code file from Part 2a xxP2a.py
(8) Python UDP server code file from Part 2b xxP2b.py
(9) Python UDP server code file from Part 2c xxP2c.py
where xx is your first name and last name initials.
Hints: Use the standard compression utility already available from your PC Operating System to
produce the zip file. That way the submitted zip file can be opened for grading using standard
Windows OS built-in uncompress utility.
Page 3 of 19
Part 1: Analyzing HTTP Messages using Wireshark
Part 1a: Basic HTTP GET/response interaction
Let’s begin our exploration of HTTP by downloading a very simple HTML file - one that is very
short and contains no embedded objects. Do the following:
Start up your web browser.
Start up the Wireshark packet sniffer. Enter “http” (just the letters, not the quotation
marks) in the display-filter-specification window, so that only captured HTTP messages
will be displayed later in the packet-listing window.
Wait a bit more than one minute (we’ll see why shortly), and then begin Wireshark
packet capture.
Quickly enter the following to your browser
http://gaia.cs.umass.edu/wireshark-labs/HTTP-wireshark-file1.html
Your browser should display the very simple, one-line HTML file.
Quickly stop Wireshark packet capture and save the Wireshark capture in file
xxP1a.pcapng.
Very Important notes on keeping captured files small:
Start capture only when ready
Stop capture immediately after you got what you wanted
Page 4 of 19
Your Wireshark window should look similar to the window shown in Figure 1.
Figure 1: Wireshark Display after http://gaia.cs.umass.edu/wireshark-labs/ HTTP-wireshark file1.html has been retrieved by your browser.
The example in Figure 1 shows in the packet-listing window that two HTTP messages were cap tured: the GET message (from your browser to the gaia.cs.umass.edu web server) and the re sponse message from the server to your browser. The packet-contents window shows details of
the selected message (in this case the HTTP OK message, which is highlighted in the packet listing window). Recall that since the HTTP message was carried inside a TCP segment, which
was carried inside an IP datagram, which was carried within an Ethernet frame, Wireshark dis plays the Frame, Ethernet, IP, and TCP packet information as well. We want to minimize the
amount of non-HTTP data displayed, so make sure the boxes at the far left of the Frame, Ether net, IP and TCP information have a plus sign or a right-pointing triangle (which means there is
hidden, not displayed information), and the HTTP line has a minus sign or a down-pointing trian gle (which means that all information about the HTTP message is displayed).
(Note: You should ignore any HTTP GET and response for favicon.ico. If you see a reference to this file, it
is your browser automatically asking the server if it (the server) has a small icon file that should be dis played next to the displayed URL in your browser. We’ll ignore references to this pesky file.)
Page 5 of 19
Part 1a Items To Submit
Include the Wireshark capture file xxP1a.pcapng in the submission zip file.
In the PDF file report, create a section called Part 1a – Basic HTTP GET/response interaction.
Include answers for Part 1a questions below.
By looking at the information in the HTTP GET and response messages, answer the following
questions.
When answering each question, you should include the screen capture of the GET and response
messages and graphically circle or highlight to indicate where within the message the requested
information came from.
(1) Is your browser running HTTP version 1.0 or 1.1? What version of HTTP is the server
running?
(2) What languages (if any) does your browser indicate that it can accept to the server?
(3) What is the IP address of your computer? Of the gaia.cs.umass.edu server?
(4) What is the status code returned from the server to your browser?
(5) When was the HTML file that you are retrieving last modified at the server?
(6) How many bytes of content are being returned to your browser?
(7) By inspecting the raw data in the packet content window, do you see any headers within
the data that are not displayed in the packet-listing window? If so, name one.
In your answer to question 5 above, you might have been surprised to find that the document
you just retrieved was last modified within a minute before you downloaded the document.
That’s because (for this particular file), the gaia.cs.umass.edu server is setting the file’s last modified time to be the current time and is doing so once per minute. Thus, if you wait a minute
between accesses, the file will appear to have been recently modified, and hence your browser
will download a “new” copy of the document.
Page 6 of 19
Part 1b: The HTTP CONDITIONAL GET/response interaction
Recall from Section 2.2.5 of the textbook, that most web browsers perform object caching and
thus perform a conditional GET when retrieving an HTTP object. Before performing the steps
below, make sure your browser’s cache is empty by clearing its cache. Now perform the follow ing:
Start up your web browser, and make sure your browser’s cache was cleared, as dis cussed above.
Begin Wireshark capture
Enter the following URL into your browser
http://gaia.cs.umass.edu/wireshark-labs/HTTP-wireshark-file2.html
Your browser should display a very simple five-line HTML file.
Quickly enter the same URL into your browser again (or simply select the refresh button
on your browser)
Stop Wireshark capture and enter “http” in the display-filter-specification window, so
that only captured HTTP messages will be displayed later in the packet-listing window.
Save the Wireshark capture in file xxP1b.pcapng.
Part 1b Items To Submit
Include the Wireshark capture file xxP1b.pcapng in the submission zip file.
In the PDF file report, Create a section called Part 1b: The HTTP CONDITIONAL GET/response
interaction. Include answers for Part 1b questions below:
(1) Inspect the contents of the first HTTP GET request from your browser to the server. Do
you see an “IF-MODIFIED-SINCE” line in the HTTP GET?
(2) Inspect the contents of the server response. Did the server explicitly return the contents
of the file? How can you tell?
(3) Now inspect the contents of the second HTTP GET request from your browser to the
server. Do you see an “IF-MODIFIED-SINCE:” line in the HTTP GET? If so, what infor mation follows the “IF-MODIFIED-SINCE:” header?
(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 contents of the file? Explain.
Part 1c: Retrieving Long Documents
In our examples thus far, the documents retrieved have been simple and short HTML files. Let’s
next see what happens when we download a long HTML file. Do the following:
Start up your web browser, and make sure your browser’s cache is cleared.
Begin Wireshark capture
Enter the following URL into your browser
http://gaia.cs.umass.edu/wireshark-labs/HTTP-wireshark-file3.html
Your browser should display the rather lengthy US Bill of Rights.
Stop Wireshark capture and enter “http” in the display-filter-specification window, so
that only captured HTTP messages will be displayed. Save the capture in file
xxP1c.pcapng
In the packet-listing window, you should see your HTTP GET message, followed by a multiple packet TCP response to your HTTP GET request. This multiple-packet response deserves a bit of
explanation. Recall from Section 2.2 (see Figure 2.9 in the textbook) that the HTTP response
message consists of a status line, followed by header lines, followed by a blank line, followed by
the entity body. In the case of our HTTP GET, the entity body in the response is the entire re quested HTML file. In our case here, the HTML file is rather long, and at 4500 bytes is too large
to fit in one TCP packet. The single HTTP response message is thus broken into several pieces by
TCP, with each piece being contained within a separate TCP segment (see Figure 1.24 in the
textbook). In recent versions of Wireshark, Wireshark indicates each TCP segment as a separate
packet, and the fact that the single HTTP response was fragmented across multiple TCP packets
is indicated by the “TCP segment of a reassembled PDU” in the Info column of the Wireshark
display. Earlier versions of Wireshark used the “Continuation” phrase to indicate that the entire
content of an HTTP message was broken across multiple TCP segments. We stress here that
there is no “Continuation” message in HTTP!
Part 1c Items To Submit
Include the Wireshark capture file xxP1c.pcapng in the submission zip file.
In the PDF file report, Create a section called Part 1c: Retrieving Long Documents. Include an swers for Part 1c questions below.
(1) How many HTTP GET request messages did your browser send? Which packet number
in the trace contains the GET message for the Bill or Rights?
(2) Which packet number in the trace contains the status code and phrase associated with
the response to the HTTP GET request?
(3) What is the status code and phrase in the response?
Page 7 of 19
Page 8 of 19
(4) How many data-containing TCP segments were needed to carry the single HTTP re sponse and the text of the Bill of Rights?
Page 9 of 19
Part 1d: HTML Documents with Embedded Objects
Now that we’ve seen how Wireshark displays the captured packet traffic for large HTML files,
we can look at what happens when your browser downloads a file with embedded objects, i.e.,
a file that includes other objects (in the example below, image files) that are stored on another
server(s).
Perform the following:
Start up your web browser, and make sure your browser’s cache is cleared
Begin Wireshark capture
Enter the following URL into your browser
http://gaia.cs.umass.edu/wireshark-labs/HTTP-wireshark-file4.html
Your browser should display a short HTML file with two images. These two images are
referenced in the base HTML file. That is, the images themselves are not contained in
the HTML; instead, the URLs for the images are contained in the downloaded HTML file.
As discussed in the textbook, your browser will have to retrieve these logos from the in dicated web sites. Our publisher’s logo is retrieved from the gaia.cs.umass.edu web
site. The image of the cover for our 5th edition (one of our favorite covers) is stored at
the caite.cs.umass.edu server. (These are two different web servers inside
cs.umass.edu).
Stop Wireshark capture and enter “http” in the display-filter-specification window, so
that only captured HTTP messages will be displayed. Save the capture in file
xxP1d.pcapng
Part 1d Items To Submit
Include the Wireshark capture file xxP1d.pcapng in the submission zip file.
In the PDF file report, Create a section called Part 1d: HTML Documents with Embedded Ob jects. Include answers for Part 1d questions below.
(1) How many HTTP GET request messages did your browser send? To which Internet ad dresses were these GET requests sent?
(2) Can you tell whether your browser downloaded the two images serially, or whether
they were downloaded from the two web sites in parallel? Explain.
Part 1e: HTTP Authentication
Finally, let’s try visiting a web site that is password-protected and examine the sequence of
HTTP message exchanged for such a site. The URL
http://gaia.cs.umass.edu/wireshark-labs/protected_pages/HTTP-wireshark-file5.html is pass word protected. The username is “wireshark-students” (without the quotes), and the password
is “network” (again, without the quotes). So, let’s access this “secure” password-protected site.
Do the following:
Make sure your browser’s cache is cleared, and close your browser. Then, start up your
browser
Begin Wireshark capture
Enter the following URL into your browser
http://gaia.cs.umass.edu/wireshark-labs/protected_pages/HTTP-wireshark-file5.html
Type the requested username and password into the pop up box.
Stop Wireshark capture and enter “http” in the display-filter-specification window, so
that only captured HTTP messages will be displayed later in the packet-listing window.
Save the capture in file xxP1e.pcapng
Now let’s examine the Wireshark output. You might want to first read up on HTTP authentica tion by reviewing the easy-to-read material on “HTTP Access Authentication Framework” at
http://frontier.userland.com/stories/storyReader$2159
Part 1e Items To Submit
Include the Wireshark capture file xxP1e.pcapng in the submission zip file.
In the PDF file report, Create a section called Part 1e: HTTP Authentication. Include answers for
Part 1e questions below.
(1) What is the server’s response (status code and phrase) in response to the initial HTTP
GET message from your browser?
(2) When your browser’s sends the HTTP GET message for the second time, what new field
is included in the HTTP GET message?
The username (wireshark-students) and password (network) that you entered are encoded in
the string of characters (d2lyZXNoYXJrLXN0dWRlbnRzOm5ldHdvcms=) following the “Author ization: Basic” header in the client’s HTTP GET message. While it may appear that your
username and password are encrypted, they are simply encoded in a format known as Base64
format. The username and password are not encrypted! To see this, go to
http://www.motobit.com/util/base64-decoder-encoder.asp and enter the base64-encoded
Page 10 of 19
Page 11 of 19
string d2lyZXNoYXJrLXN0dWRlbnRz and decode. Voila! You have translated from Base64 en coding to ASCII encoding, and thus should see your username! To view the password, enter the
remainder of the string Om5ldHdvcms= and press decode. Since anyone can download a tool
like Wireshark and sniff packets (not just their own) passing by their network adaptor, and any one can translate from Base64 to ASCII (you just did it!), it should be clear to you that simple
passwords on WWW sites are not secure unless additional measures are taken.
Page 12 of 19
Part 2: Socket Programming
Part 2a: UDP Pinger with No Delay and No Loss
In this portion, you will learn the basics of socket programming for UDP in Python. You will learn
how to send and receive datagram packets using UDP sockets and, how to set a proper socket
timeout. Throughout the lab, you will gain familiarity with a Ping application and its usefulness
in computing statistics such as packet loss rate.
You will first study a simple Internet ping server written in the Python and implement a corre sponding client. The functionality provided by these programs is like the functionality provided
by standard ping programs available in modern operating systems. However, these programs
use a simpler protocol, UDP, rather than the standard Internet Control Message Protocol (ICMP)
to communicate with each other. The ping protocol allows a client machine to send a packet of
data to a remote machine, and have the remote machine return the data back to the client un changed (an action referred to as echoing). Among other uses, the ping protocol allows hosts to
determine round-trip times to other machines.
You are given the complete code for the Ping server in the next subsection. Your task is to write
the UDP Ping client.
Server Code
You are provided with the following code which fully implements a ping server. You need to run
this code before running your client program. Your client code in this portion of the assignment
will be graded using this exact same server code (do not modify it for this portion of the assign ment).
You should study this code carefully, as it will help you write your ping client code.
# udppingserver_no_loss.py
from socket import *
# Create a UDP socket
serverSocket = socket(AF_INET, SOCK_DGRAM)
# Assign IP address and port number to socket
serverSocket.bind(('', 12000))
while True:
# Receive the client packet along with the address it is coming from
message, address = serverSocket.recvfrom(1024)
# The server responds
serverSocket.sendto(message, address)
The server sits in an infinite loop listening for incoming UDP packets. When a packet comes in,
the server simply sends it back to the client.
Page 13 of 19
Client Code
You task is to implement the client program as explained below.
The client should send a specified number of pings to the server. Because UDP is an unreliable
protocol, a packet sent from the client to the server may be lost in the network, or vice versa.
For this reason, the client cannot wait indefinitely for a reply to a ping message. You should get
the client wait up to one second for a reply; if no reply is received within one second, your client
program should assume that the packet was lost during transmission across the network. You
will need to look up the Python documentation to find out how to set the timeout value on a
datagram socket.
Requirements for Client Code
The client program should:
send the ping message using UDP
print the response message from server if any was received
calculate and print the round-trip time (RTT), in milliseconds, of each packet if the server
responses
otherwise, print “Request timed out”
provide a sumAlice report at the end (of all pings) which includes:
o minimum RTT in milliseconds,
o maximum RTT in milliseconds,
o average RTT in milliseconds,
o percentage packet loss rate
You should run the udppingserver_no_loss.py on your machine and test your client by sending
packets to the localhost.
Ping Message Format
The client ping message is a one line, consisting of ASCII characters and must be in the follow ing format:
firstname ping_number date_and_time
where:
firstname is your first name.
ping_number starts at 1 and progresses to total number of pings for each successive ping mes sage sent by the client, and time is the time when the client sends the message.
For example: The following is a sample display from the client program for student Alice.
Alice 1: server reply: Alice 1 Fri Sep 13 09:00:15 2024, RTT = 3.99 ms
Alice 2: server reply: Alice 2 Fri Sep 13 09:00:15 2024, RTT = 0.00 ms
Page 14 of 19
Notes: the blue text represents the response from the server upon receiving the ping message
(which is the message the server received from the client). The other texts are from the client
itself.
Refer to the Appendix section on the last page for samples and required data format.
Part 2a Items To Submit
Include Part 2a Python client code file xxP2a.py in the submission zip file.
In the PDF file report, create a section called Part 2a – UDP Pinger with No Delay and No Loss.
Include the followings:
(1) Describe the operation of your UDP Pinger, for example how it works.
(2) Explain how to specify the timeout value for a datagram socket. Provide an example.
(3) Explain how to run your code, i.e., command line and any applicable parameter(s)
a. Include run-time screen captures for a sequence consists of 10 pings
Refer to the Appendix section on the last page for samples and required data for mat.
(4) Paste the Python client code listing text (must be text, not a screenshot graphic of the
text) in the report. Use consolas font size 10 or equivalent monospace font. The use of
the monospace font is to clearly show indentations in your code.
Page 15 of 19
Part 2b: UDP Pinger with Delays
Delays
Our experiment so far has been on a local host running both server and client programs, and
therefore we saw zero delays. In this portion of the assignment, you are asked to modify the
server code to simulate random RTT delays ranging from 10ms to 20ms.
Hint: Create a variable which holds a randomized integer to determine the delay amount.
Part 2b Items To Submit
Include Part 2b Python server code file xxP2b.py in the submission zip file.
In the PDF file report, create a section called Part 2b – UDP Pinger No Loss, with Delays. Include
the followings:
(1) Describe the operation of your UDP Ping Server and explain how it simulates 10ms to
20ms RTT delays.
(2) Explain how to run your code, i.e., command line and any applicable parameter(s)
a. Include run-time screen captures for a sequence consists of 10 pings
Refer to the Appendix section on the last page for samples and required data
format.
(3) Paste the Python server code listing text (must be text, not a screenshot graphic of the
text) in the report. Use consolas font size 10 or equivalent monospace font. The use of
the monospace font is to clearly show indentations in your code.
Page 16 of 19
Part 2c: UDP Pinger with Delays and Packet Losses
Packet Loss Injection
UDP provides applications an unreliable transport service. Messages may get lost in the network
due to router queue overflows, faulty hardware, or some other reasons. Because packet loss is
rare or even non-existent in typical campus or home networks, you are asked to modify the
server code in this portion of the assignment to inject artificial losses to simulate the effects of
network packet loss.
Hint: Create a variable which holds a randomized integer to determine whether a particular in coming packet is lost or not.
Part 2c Items To Submit
Include Part 2c Python server code file xxP2c.py in the submission zip file.
In the PDF file report, Create a section called Part 2c – UDP Pinger with Delays and Packet Loss es. Include the followings:
(1) Describe the operation of your UDP Ping Server and explain how it simulates delays be tween 10ms and 20ms, with up to 10% packet losses.
(2) Explain how to run your code, i.e., command line and any applicable parameter(s)
a. Include run-time screen captures for a sequence consists of 50 pings
Refer to the Appendix section on the last page for samples and required data
format.
(3) Paste the Python server code listing text (must be text, not a screenshot graphic of the
text) in the report. Use consolas font size 10 or equivalent monospace font. The use of
the monospace font is to clearly show indentations in your code.
Page 17 of 19
Appendix
All examples in this section use an arbitrary student named Alice.
Part 2a: Sequence of 10 Pings with No Delay and No Packet Loss
Alice 1: server reply: Alice 1 Fri Sep 13 09:00:15 2024, RTT = 3.99 ms
Alice 2: server reply: Alice 2 Fri Sep 13 09:00:15 2024, RTT = 0.00 ms
Alice 3: server reply: Alice 3 Fri Sep 13 09:00:15 2024, RTT = 1.00 ms
Alice 4: server reply: Alice 4 Fri Sep 13 09:00:15 2024, RTT = 0.00 ms
Alice 5: server reply: Alice 5 Fri Sep 13 09:00:15 2024, RTT = 1.01 ms
Alice 6: server reply: Alice 6 Fri Sep 13 09:00:15 2024, RTT = 0.00 ms
Alice 7: server reply: Alice 7 Fri Sep 13 09:00:15 2024, RTT = 0.00 ms
Alice 8: server reply: Alice 8 Fri Sep 13 09:00:15 2024, RTT = 1.00 ms
Alice 9: server reply: Alice 9 Fri Sep 13 09:00:15 2024, RTT = 0.00 ms
Alice 10: server reply: Alice 10 Fri Sep 13 09:00:15 2024, RTT = 0.99 ms
Min RTT = 0.00 ms
Max RTT = 3.99 ms
Avg RTT = 0.80 ms
Packet lost = 0.00 %
Page 18 of 19
Part 2b: Sequence of 10 Pings with 10ms-20ms Delays and No Packet Loss
Alice 1: server reply: Alice 1 Fri Sep 13 09:57:59 2024, RTT = 20.76 ms
Alice 2: server reply: Alice 2 Fri Sep 13 09:57:59 2024, RTT = 16.00 ms
Alice 3: server reply: Alice 3 Fri Sep 13 09:57:59 2024, RTT = 16.00 ms
Alice 4: server reply: Alice 4 Fri Sep 13 09:57:59 2024, RTT = 15.88 ms
Alice 5: server reply: Alice 5 Fri Sep 13 09:57:59 2024, RTT = 15.02 ms
Alice 6: server reply: Alice 6 Fri Sep 13 09:57:59 2024, RTT = 15.18 ms
Alice 7: server reply: Alice 7 Fri Sep 13 09:57:59 2024, RTT = 15.29 ms
Alice 8: server reply: Alice 8 Fri Sep 13 09:57:59 2024, RTT = 15.42 ms
Alice 9: server reply: Alice 9 Fri Sep 13 09:57:59 2024, RTT = 15.67 ms
Alice 10: server reply: Alice 10 Fri Sep 13 09:57:59 2024, RTT = 15.74 ms
Min RTT = 15.02 ms
Max RTT = 20.76 ms
Avg RTT = 16.10 ms
Packet lost = 0.00 %
Page 19 of 19
Part 2c: Sequence of 50 Pings with 10ms-20ms Delays and up to 10% Packet Loss
Alice 1: server reply: Alice 1 Fri Sep 13 09:45:50 2024, RTT = 12.01 ms
Alice 2: server reply: Alice 2 Fri Sep 13 09:45:50 2024, RTT = 16.00 ms
Alice 3: timed out, message was lost
Alice 4: server reply: Alice 4 Fri Sep 13 09:45:51 2024, RTT = 15.65 ms
Alice 5: server reply: Alice 5 Fri Sep 13 09:45:51 2024, RTT = 15.46 ms
Alice 6: server reply: Alice 6 Fri Sep 13 09:45:51 2024, RTT = 15.60 ms
Alice 7: server reply: Alice 7 Fri Sep 13 09:45:51 2024, RTT = 15.23 ms
Alice 8: server reply: Alice 8 Fri Sep 13 09:45:51 2024, RTT = 15.20 ms
Alice 9: server reply: Alice 9 Fri Sep 13 09:45:51 2024, RTT = 14.72 ms
Alice 10: server reply: Alice 10 Fri Sep 13 09:45:51 2024, RTT = 15.03 ms
Alice 11: server reply: Alice 11 Fri Sep 13 09:45:51 2024, RTT = 15.26 ms
Alice 12: server reply: Alice 12 Fri Sep 13 09:45:51 2024, RTT = 16.09 ms
Alice 13: server reply: Alice 13 Fri Sep 13 09:45:51 2024, RTT = 15.46 ms
Alice 14: server reply: Alice 14 Fri Sep 13 09:45:51 2024, RTT = 16.05 ms
Alice 15: server reply: Alice 15 Fri Sep 13 09:45:51 2024, RTT = 16.06 ms
Alice 16: server reply: Alice 16 Fri Sep 13 09:45:51 2024, RTT = 15.64 ms
Alice 17: server reply: Alice 17 Fri Sep 13 09:45:51 2024, RTT = 16.26 ms
Alice 18: server reply: Alice 18 Fri Sep 13 09:45:51 2024, RTT = 15.18 ms
Alice 19: server reply: Alice 19 Fri Sep 13 09:45:51 2024, RTT = 16.20 ms
Alice 20: server reply: Alice 20 Fri Sep 13 09:45:51 2024, RTT = 15.36 ms
Alice 21: server reply: Alice 21 Fri Sep 13 09:45:51 2024, RTT = 15.38 ms
Alice 22: server reply: Alice 22 Fri Sep 13 09:45:51 2024, RTT = 15.30 ms
Alice 23: server reply: Alice 23 Fri Sep 13 09:45:51 2024, RTT = 15.55 ms
Alice 24: server reply: Alice 24 Fri Sep 13 09:45:51 2024, RTT = 15.63 ms
Alice 25: timed out, message was lost
Alice 26: server reply: Alice 26 Fri Sep 13 09:45:52 2024, RTT = 15.99 ms
Alice 27: server reply: Alice 27 Fri Sep 13 09:45:52 2024, RTT = 14.50 ms
Alice 28: server reply: Alice 28 Fri Sep 13 09:45:52 2024, RTT = 15.27 ms
Alice 29: server reply: Alice 29 Fri Sep 13 09:45:52 2024, RTT = 15.18 ms
Alice 30: server reply: Alice 30 Fri Sep 13 09:45:52 2024, RTT = 14.89 ms
Alice 31: server reply: Alice 31 Fri Sep 13 09:45:52 2024, RTT = 15.47 ms
Alice 32: server reply: Alice 32 Fri Sep 13 09:45:52 2024, RTT = 15.80 ms
Alice 33: server reply: Alice 33 Fri Sep 13 09:45:53 2024, RTT = 15.19 ms
Alice 34: server reply: Alice 34 Fri Sep 13 09:45:53 2024, RTT = 14.99 ms
Alice 35: server reply: Alice 35 Fri Sep 13 09:45:53 2024, RTT = 15.21 ms
Alice 36: timed out, message was lost
Alice 37: server reply: Alice 37 Fri Sep 13 09:45:54 2024, RTT = 15.75 ms
Alice 38: server reply: Alice 38 Fri Sep 13 09:45:54 2024, RTT = 15.71 ms
Alice 39: server reply: Alice 39 Fri Sep 13 09:45:54 2024, RTT = 14.78 ms
Alice 40: server reply: Alice 40 Fri Sep 13 09:45:54 2024, RTT = 14.87 ms
Alice 41: server reply: Alice 41 Fri Sep 13 09:45:54 2024, RTT = 16.24 ms
Alice 42: server reply: Alice 42 Fri Sep 13 09:45:54 2024, RTT = 15.53 ms
Alice 43: server reply: Alice 43 Fri Sep 13 09:45:54 2024, RTT = 15.66 ms
Alice 44: server reply: Alice 44 Fri Sep 13 09:45:54 2024, RTT = 14.85 ms
Alice 45: server reply: Alice 45 Fri Sep 13 09:45:54 2024, RTT = 15.02 ms
Alice 46: server reply: Alice 46 Fri Sep 13 09:45:54 2024, RTT = 14.34 ms
Alice 47: server reply: Alice 47 Fri Sep 13 09:45:54 2024, RTT = 15.92 ms
Alice 48: server reply: Alice 48 Fri Sep 13 09:45:54 2024, RTT = 16.20 ms
Alice 49: server reply: Alice 49 Fri Sep 13 09:45:54 2024, RTT = 16.01 ms
Alice 50: server reply: Alice 50 Fri Sep 13 09:45:54 2024, RTT = 14.52 ms
Min RTT = 12.01 ms
Max RTT = 16.26 ms
Avg RTT = 15.37 ms
Packet lost = 6.00 %