[SOLVED] Comp 416 projects #1 to 3 solution

Introduction and Motivation:
This project work is about the application layer of the network protocol stack. It involves
application layer software development, client/server protocol, application layer protocol
principles, socket programming, and multithreading.
Through this project, you are going to develop a weather reporting network application
(WeatNet) by interacting with the application layer abstract programming interface (API)
of OpenWeatherMap (openweathermap.org). The project will require you to work with
the following APIs for information extraction from the OWM web server:
1. Current Weather forecast
2. Daily forecast for 7 days
3. Basic Weather maps
4. Minute forecast for 1 hour
5. Historical Weather for 5 days
This API provides you access to the weather data which will be subsequently accessed
by the clients.
Project Overview:
In this project, you are asked to develop a weather reporting network application based
on the client/server model. WeatNet server provides two types of TCP connections to
interact with the clients: One connection for exchanging the protocol commands, and
one for data transfers. Fig.1 shows connections for a sample WeatNet server and client
interactions. As shown in this figure, the WeatNet server also takes the responsibility of
interacting with a OpenWeatherNet web server using the OpenWeatherMap API.
Figure 1. The OWM Client/Server connections.
Implementation Details:
The WeatNet reporting application has three main components:
● Interaction of the OpenWeatherMap (OWM) and the server
● Server side of the application
● Client side of the application
It is pertinent to note that the free subscription for OWM allows for up to 60 API calls per
minute and a total of 1 million calls in a month. The developed application and testing
including for demonstration must keep these limits in perspective.
Phases:
This project has two phases: Authentication phase, and querying phase. During the
authentication phase, the client provides its username and answers a series of secret
questions to prove its identity. The protocol (the message flow, message types and their
formats) is provided in the “Authentication” section. The groups need only to implement
the provided protocol. During the querying phase, the authenticated clients
communicate with the server to retrieve weather information conforming to the
specifications that will be explained in the following sections. Unlike the authentication
phase, we do not provide you a protocol but expect you to design your own. This will be
a part of your report. You may use the authentication protocol as a starting point and
build from there.
City List:
The WeatNet reporting will be done for the following cities:
1. {‘id’: 745044, ‘name’: ‘Istanbul’, ‘state’: ”, ‘country’: ‘TR’, ‘coord’: {‘lon’: 28.949659, ‘lat’:
41.01384}}
2. {‘id’: 740264, ‘name’: ‘Samsun’, ‘state’: ”, ‘country’: ‘TR’, ‘coord’: {‘lon’: 36.330002, ‘lat’:
41.286671}}
3. {‘id’: 315201, ‘name’: ‘Eskişehir’, ‘state’: ”, ‘country’: ‘TR’, ‘coord’: {‘lon’: 31.16667, ‘lat’:
39.666672}}
4. {‘id’: 323784, ‘name’: ‘Ankara’, ‘state’: ”, ‘country’: ‘TR’, ‘coord’: {‘lon’: 32.833328, ‘lat’:
39.916672}}
5. {‘id’: 304919, ‘name’: ‘Malatya’, ‘state’: ”, ‘country’: ‘TR’, ‘coord’: {‘lon’: 38.0, ‘lat’: 38.5}}
6. {‘id’: 750268, ‘name’: ‘Bursa’, ‘state’: ”, ‘country’: ‘TR’, ‘coord’: {‘lon’: 29.08333, ‘lat’:
40.166672}}
7. {‘id’: 311044, ‘name’: ‘İzmir’, ‘state’: ”, ‘country’: ‘TR’, ‘coord’: {‘lon’: 27.092291, ‘lat’:
38.462189}}
You can find the entire list of cities supported by OWM here. Please note that OWM may use
multiple coordinates within the same city. The developed application must ensure that even if
the names may be duplicated, the coordinates must be for the cities provided for the list. In this
case, the city IDs will be useful when using the OWM API.
WeatNet Server side overview:
The server for the WeatNet application should:
1) Establish a connection with the OpenWeatherMap (OWM) web server using the API and
download the specified weather metrics for all the cities specified for this project.
2) Authenticate any client before initiating any data exchange.
3) Allow multiple clients to connect using multi-threading with the same functionality.
4) Add a timestamp in each file before sending to any client while providing hashes of the
files for error detection purposes..
The metrics categories for which the OWM API will be used are:
1. Current weather forecast
2. Weather triggers
3. Basic weather maps
4. Minute forecast for 1 hour
6. Historical weather for 5 days
All these metrics except the weather maps are to be downloaded in the JSON format as
separate files whereas the basic maps will be downloaded as images (.jpg, .png etc.).
API Interactions:
For the interactions to take place, the client will pass the name/ID of the city and/or the
weather triggers. All this information shall be conveyed between the client and the
server on the Command socket (the socket allocated to the client after acceptance and
validation).
Based on this input, the server will parse the client input and use the API to extract the
relevant information from the web server. This information will then be passed to the
client in the form of a JSON/image file over the Data Socket. The server will be
responsible for generating a hash value of each file before transmitting to the client and
this will also be sent to the client for file verification over the Command Socket
The process at server side would be:
1) Create welcoming socket
2) Accept incoming client connections at the welcoming socket, simultaneously if needed
using multi-threading.
3) Authenticate any incoming client connection requests after acceptance. Create an
additional Data socket with the client if authenticated. Terminate connection if
authentication fails. (Demonstration should present both scenarios in which clients are
validated as well as rejected).
4) Decipher the requests coming in from the clients and download the required files from
the web server. (The protocol for forwarding requests has to be developed by the groups
themselves and explained in their reports. A similar format is provided in the
Authentication part).
5) Generate the hash values of the file requested by the client.
6) Send the hash value of the required file over the Command socket.
7) Send the requisite file over the Data socket.
8) Terminate connection if a “file received” acknowledgment message is received from the
client and no other files are requested within timeout duration.
The exact implementation of Data Socket is left to the choice of the groups. It can be a
single socket shared by the clients through multi-threading or a dedicated socket for
each client. The initiation of the Data Socket and the exact nature of how the parameters
are passed to the client are also to be decided by the groups. The parameters of the Data
socket are also to be conveyed over the Command socket if required.
Weatnet Client Side Overview:
This weather application envisions multiple clients interacting with a single server. For this
application, the clients should:
1) Confirm its authenticity with the server
2) Be able to submit requests to the server.
3) Be able to receive data in form of JSON/image files from the server over the Data
socket.
4) Verify the file based on its digital signature.
5) Display the JSON data in tabular form or display the image on the client side
Client-Server Interaction
The client side must take care of the parameters to be passed once requesting any metric.
The process at the client side will follow the given steps:
1) Initiate connection with the server over Command Socket
2) Authenticate based on the server requirements.
3) Receive the parameters for Data Socket and connect to that after authentication.
4) Pass the requests to the server
5) Receive the hash value of the file on the Command socket
6) Receive the files over the Data socket
7) Confirm if the hash value corresponds to the file
8) Request retransmit from the server if mismatch between hash value and file or failure to
receive file (Relevant String should be displayed in terminal). A scenario for this step
may be specifically designed for demonstration purposes.)
9) Display the files in the appropriate manner.
10) Terminate the connection in case an appropriate file is received and no other request
forwarded within the timeout duration. (Appropriate tests for demonstration purposes
should be developed.)
Authentication Phase
In our implementation, the server does not share the weather information with everyone.
The client needs to be authenticated in order to be able to query the server, which will
be done by a series of “challenges” (i.e., secret questions) instead of simple
password-based authentication. After the authentication is done, the client will receive a
“token” from the server. The token will act as a “proof” of the authenticity of the client.
From that point on, the client will need to append this token to its requests, and once the
server receives a request, it responds only if the token is valid. Please note that the
authenticated clients are authorized to perform all possible weather queries, so we do
not distinguish between authentication and authorization for the sake of simplicity.
Fig. 2. The message flows for the authentication phase.
First, the client will send its username to request to be authenticated (i.e., acquire a
token). Then, the server will authenticate the client by requesting the answers for a
series of secret questions that are included in Auth_Challenge messages. After
receiving a question, the client will prompt the user, the user will enter the answer
through standard input, and the client will send the answer by including it into an
Auth_Request message. Some example questions and answers:
– “What is your favorite color?” – “red”
– “What is the first name of your favorite author?” – “kadri”
– “In which city you were born?” – “istanbul”
– “What is the last name of your best friend?” – “zorlu”
– “What is your goal in this course?” – “to get an A”
The server decides how many questions the client should answer, and the questions
will be chosen from a pool of possible questions. The correct answers to these
questions for the particular user will be known by the server. If all the questions were
answered correctly by the client, the server will send back an Auth_Success, including
a unique token for the client. If the client answers a question incorrectly, the server will
immediately respond with an Auth_Fail with the reason of failure message as “Incorrect
answer”. Please note that the server may also send back an Auth_Fail when the first
Auth_Request includes a nonexistent username. In this case, the reason for failure
should be “User does not exist”.
Figure 1 illustrates the intended message flow, where qi denotes the i
th question and ai
denotes the client’s answer to qi
.
a. Message format
In protocol design, (1) the message types, and (2) the format & the meaning of the
values in each type of message must be clearly specified. The client and the server will
handle the received messages according to their types. Similarly, they will construct the
messages adhering to the protocol.
Message types
During the authentication phase, the client is able to send only Auth_Request
messages, and the server is able to send Auth_Challenge, Auth_Fail and
Auth_Success messages.
Message type Value Payload
Auth_Request 0 Username/Answer (String)
Auth_Challenge 1 Question (String)
Auth_Fail 2 Reason of failure (String)
Auth_Success 3 Token (String)
Deconstructing the TCP data
The TCP data received from the socket must be deconstructed correctly. The first six
bytes are designated as the application header, where the first byte represents the
“phase” (either the authentication (0) or querying (1) phase.), and the second byte
represents the “type” of the message. If the “phase” byte is set to 0, then the messages
will be handled by the authentication module of our implementation. Otherwise, your
implementation should hand over the handling of the request to the weather querying
module. The remaining four bytes of the header are designated as an integer (4 bytes)
denoting the length of the payload in bytes. Your application should use this value to
read the correct number of bytes from the TCP stream as the payload, since we do not
know the length of the payload beforehand. Figure 2 shows the deconstruction of an
authentication message.
Here are some useful links:
https://docs.oracle.com/javase/7/docs/api/java/io/DataInputStream.html
https://docs.oracle.com/javase/7/docs/api/java/io/DataOutputStream.html
https://docs.oracle.com/javase/7/docs/api/java/io/FilterOutputStream.html
Fig. 3. Deconstructing the TCP data.
b. Timeout mechanism
You also need to handle the cases where the client is unresponsive to a question. After
sending a challenge, the server should wait only for a predetermined amount of time
(e.g. 10 seconds) before sending an Auth_Fail to the client with the appropriate reason
message and closing the connection.
c. Implementation details
Storing users, questions, and answers
For simplicity, you may want to keep all the users, questions and answers in an easily
parsable text file. Figure 3 illustrates an example of such a file, where we have two
users – “ali” and “veli” with different questions and answers.
Fig. 4. An example of a text file storing users, questions and answers.
The token
The token should be unique for each session. Ideally, they should be constructed
on-the-fly. You can construct a token by performing a hash on the concatenation of the
username and a random number. Then, the token will be the first n (e.g., 6) characters
of the output. After that, you should save the token along with the corresponding client
IP + port and username, so that the server can verify the token in the future during the
querying phase.
Architecture
While architecturing your application, it may be beneficial to separate it into
modules/layers so that different group members can independently work on a single
module. For example, the authentication module of the server and client would
communicate with each other (through the command socket) to agree on a token in the
authentication phase. In the querying phase, the only responsibility of the authentication
module would be as following:
– At the client: Append the token to the message received from the weather
module before sending the message through TCP to the server.
– At the server: Verify the received token appended to the received message from
the TCP before supplying it to the weather module. Then, the weather module
could simply focus on communicating with the OWM API.
Figure 4 shows an example of how the modules in your project may interact. The top
section represents the authentication phase, while the bottom section represents an
authenticated client sending a request to the server.
Fig. 5. The interaction of the different modules of WeatNet.
Execution Scenario
Due to the fact that the classes are being conducted online, the client and server are
expected to reside on a single machine for simplicity of both execution and
demonstration. However, any group preferring connection to a Remote device is free to
do so albeit with necessary consideration given to the overall execution and
demonstration scenarios.
The project envisions the groups to implement at least five unique clients and one
server.
Project deliverables:
You should submit your source code and project report (in a single .rar or .zip file) via
Blackboard.
Report
The report should start with a very brief description of the project. This should be
followed by an explanation of the philosophies especially post-authentication
server-client protocol. This should be followed by an overview of the programming of the
client and the server side including the initial authentication, connection with the API,
the file transfer mechanism and the file verification. Instead of attaching complete code,
it is strongly recommended to attach code Snippets and images of the results of their
execution. The report should explicitly describe the test routines developed to
evaluate the full range of features required for the WeatNet.
Source Code: A .zip or .rar file that contains your implementation in a single Eclipse or
Intellij IDEA. If you aim to implement your project in any IDE rather than the mentioned
one, you should first consult with TA and get confirmation.
● Source Code: A .zip or .rar file that contains your implementation in a single
Eclipse or Intellij IDEA. If you aim to implement your project in any IDE rather
than the mentioned one, you should first consult with TA and get
confirmation.
● The report is an important part of your project presentation, which should be
submitted as both a .pdf and Word file. Your report should show the step by step
OWM configuration and connection with your code. As well as your server-client
communication initiation. Report acts as a proof of work for you to assert
your contributions to this project. Everyone who reads your report should be
able to reproduce the parts we asked to document without hard effort and any
other external resource. If you need to put the code in your report, segment it as
small as possible (i.e. just the parts you need to explain) and clarify each
segment before heading to the next segment. For codes, you should be taking
screenshot instead of copy/pasting the direct code. Strictly avoid replicating
the code as whole in the report, or leaving code unexplained. You are expected
to provide detailed explanations of the following clearly in your report:
Demonstration:
You are required to demonstrate the execution of WeatNet Application for the defined
requirements. Your demo sessions will be announced by the TAs. Attending the demo
session is required for your project to be graded. All group members are supposed to
be available during the demo session. The on time attendance of all group members
to the demo session is considered as a grading criteria.
During your demonstration of the authentication phase, you will be asked to
demonstrate two clients being authenticated at the same time. You can assume that all
the clients will present different usernames. You need to make sure that all the users
have different correct answers for each of the possible questions. The clients and the
servers will be running on the same machine, so different clients should be running at
different ports. In this vein, the server will differentiate the clients not only by their IP
address, but also with their port number. For the demonstration, the server should send
three different questions before authenticating the user. First, you will need to show an
unsuccessful authentication, then you will need to show a successful authentication.
During the demonstration, the group will be asked to display all the operations of the
application starting from initiating client connections and authentication to passing
requests for the listed metrics. It is strongly recommended that the appropriate test
routines may be developed to present an effective demonstration and display the full
range of features as defined for WeatNet application.
The groups have the creative freedom to present any additional features they have built
into their application in any way they deem feasible. However, please note that you will
be given 10-15 minutes for your demonstration.
Following is a detailed but not exhaustive list of the test routines the groups should
develop to aid them in testing and demonstration:
1. Client creation. The application should be designed with client scalability in mind
even though the testing would be done with max 5 clients.
2. Single client connection with the server
3. Multiple clients simultaneously connecting with the server
4. Authentication procedure for a single randomly chosen client
5. The process from initiating a request by the client side to the final verification of
the received file at the client side and file display.
6. Process in case of a mismatch between received file and received hash.
Suggested task distribution:
We recommend you work in a group of 3 students, and suggest the following task distribution
accordingly:
● Student 1: Client-side programming and Authentication.
● Student 2: Server-side programming and multi-threading.
● Student 3: OpenWeatherMap API programming and file transfer mechanism.
● All members of the group to perform integration, tests and report.
The groups should be clear on the task distribution and the relevant questions will be directed
towards the student responsible for the task.
Good Luck!

This project is about the transport layer of the network protocol stack. The focus is on the SSL, TCP and UDP protocols. For this purpose, you are asked to modify the provided SSL client/server codes as specified below, experiment with TCP and UDP features and implement a Stop-and-Wait ARQ protocol. You are asked to use the WireShark network protocol analyzer tool to answer transport layer related questions. WireShark is the world’s foremost network protocol analyzer, and is the de facto standard across many industries and educational institutions. It can be downloaded freely at https://www.wireshark.org/download.html. WireShark allows users to trace the network activity by capturing all the packets that hit your network interface. It tags the information of each layer by parsing the given byte stream according to the corresponding protocol. You should read this project document carefully before starting your tasks. Part 1 – SSL Implementation and Experiments: Figure 1 illustrates an overview of SSL protocol. Recall that, you are provided an SSL client/server code that performs echoe on top of an SSL socket. The corresponding SSL practical content codes and slides are available through the course web site. Figure 1. SSL Protocol Overview As presented in the figure, the certificate is sent by the server to the user at the start of the session. The user adds this certificate to the local key store and uses it for authentication. The code is provided to add the certificate to the local key store, but the part where the server sends the certificate to the user is missing. In this part, you are asked to modify the provided code as follows: ▪ Set up a TCP connection on which the certificate will be transferred to the client. TCP connection can listen to any port. The server should ask for client verification before the certificate is transferred to the client. You can keep an already known users file on the server side and use them for login. ▪ Use the certificate to connect to the server through SSL. You should keep the certificate in the right directory. ▪ SSL connection at the server side should listen to the port with your KUSIS-ID + DD from your date of birth (DDMMYY) number (look at the first question). You may handle the case where the number becomes larger than the available ports by any mathematical manipulation and explain the answer in the report. ▪ After SSL connection is established, your client should receive your KUSIS-username (e.g. abcdef18) + KUSIS-ID character by character in separate messages in a non-persistent manner. Then, the KUSIS-username + KUSIS-ID should be printed at the client side. Important Notes: – Your modified SSL codes must be submitted along with your project report. In your project report, you should explain your answers and provide your WireShark outputs for each question, in order to get credit. – On Windows, you might not be able to capture the Loopback interface, which is the traffic inside your operating system. When you run your server and client software in a single operating system, in order to capture incoming and outgoing packets, you need to capture the Loopback interface. To solve this problem, you can run one of the applications (client or server) in a separate machine. After running your code, answer the following questions: 1. Locate the SSL Server IP address and port number, client IP address and port number through which these agents are communicating by using Wireshark. 2. Locate the data containing TCP segments. What is written in the data field? Compare it with the data you exchanged between the client and server. Why do you think is this the case? 3. How many TCP segments are transmitted in total while your KUSIS username + KUSIS ID is exchanged one by one with non-persistent connections? 4. What difference did you see in the payload of SSL and TCP? Can you locate the login name and password entered by the user? Can you locate the email information? Part 2 – TCP Experiments: Before beginning the exploration of TCP, you need to use Wireshark to obtain a packet trace of the TCP transfer of a file from your computer to a remote server. You need to run Wireshark before starting this process to obtain the trace of the TCP segments sent and received from your computer. You are asked to do so by accessing a Web page that will allow you to enter the name of a file stored on your computer (which contains the ASCII text of Alice in Wonderland), and then transfer the file to a Web server using the HTTP POST method. We are using the POST method rather than the GET method as we would like to transfer a large amount of data from your computer to another computer. Perform the following: ▪ Run Wireshark and start capturing the traffic. ▪ Start up your web browser. Go the https://gaia.cs.umass.edu/wireshark-labs/alice.txt and retrieve an ASCII copy of Alice in Wonderland. Store this file somewhere on your computer. ▪ Next go to https://gaia.cs.umass.edu/wireshark-labs/TCP-wireshark-file1.html ▪ You should see a screen that looks like: ▪ Use the Browse button in this form to enter the name of the file (full path name) on your computer containing Alice in Wonderland (or do so manually). Don’t yet press the “Upload alice.txt file” button. ▪ Now start up Wireshark and begin packet capture (Capture->Start) and then press OK on the Wireshark Packet Capture Options screen (we will not need to select any options here). ▪ Returning to your browser, press the “Upload alice.txt file” button to upload the file to the gaia.cs.umass.edu.server. Once the file has been uploaded, a short congratulations message will be displayed in your browser window. ▪ Stop Wireshark packet capture. Answer the following questions for the TCP segments: 5. Obtain the Flow Graph of the TCP communication. What is the significance of the various IP addresses shown in the Flow Graph? Using the flow graph, identify the three-way handshake and terminating handshake messages for the TCP connection. Provide screenshots for each explanation. 6. What are the sequence numbers (which appear in the Wireshark program) of the segments used for the 3-way handshake protocol that initiates the first TCP connection? What are the sequence numbers of those segments and the port numbers used on client and server sides? 7. What is the sequence number of the SYNACK segment sent by gaia.cs.umass.edu to the client computer in reply to the SYN? 8. What is the value of the Acknowledgement field in the SYNACK segment? How did gaia.cs.umass.edu determine that value? What is it in the segment that identifies the segment as a SYNACK segment? 9. What is the sequence number of the TCP segment containing the HTTP POST command? Note that in order to find the POST command, you’ll need to dig into the packet content field at the bottom of the Wireshark window, looking for a segment with a “POST” within its DATA field. 10.Consider the TCP segments containing the HTTP POST as the last segment in the TCP connection. What are the sequence numbers of the first six segments in the TCP connection? At what time was each segment sent? When was the ACK for each segment received? Given the difference between when each TCP segment was sent, and when its acknowledgement was received, what is the RTT value for each of the six segments? What is the EstimatedRTT value (see Section 3.5.3 in the textbook) after the receipt of each ACK? Assume that the value of the EstimatedRTT is equal to the measured RTT for the first segment, and then is computed using the EstimatedRTT equation (Section 3.5.3 in the textbook) for all subsequent segments. Note: Wireshark has a nice feature that allows you to plot the RTT for each of the TCP segments sent. Select a TCP segment in the “listing of captured packets” window that is being sent from the client to the gaia.cs.umass.edu server. Then select: Statistics->TCP Stream Graph- >Round Trip Time Graph. Part 3 – UDP Experiments: In this part, you are assigned a unique URL to work with. The list is provided in file Project2_URL_List.pdf, and you must use the URL assigned you. You should provide the appropriate screenshots and work on the correct domain, in order to get credit. nslookup command works as an IP address resolver. When you provide a domain name as argument, it will return the IP address of that domain. Now, take the following steps provided and answer the questions accordingly. ▪ Start your Wireshark software and start capturing packets from the appropriate interface. ▪ Use nslookup command in order to resolve the IP address of the URL that is assigned to you. ▪ Stop packet capturing in the Wireshark. ▪ Apply an appropriate display filter. 11.What display filter did you apply in order to see appropriate packets? 12.Which application layer and transport layer protocol do nslookup work on? What is the reason that transport layer protocol is chosen? 13.Can you derive the local DNS server you connected work in iterative or recursive manner? If you can or cannot please provide a detailed explanation. Please also briefly explain the advantages and disadvantages of iterative and recursive approach over each other. 14.What are the header lengths of application layer protocol and transport layer protocol that nslookup works on? 15.How many checksums does an UDP segment have in the checksum field? Why? Part 4.a – Stop-and-Wait ARQ Protocol Recall the Stop-and-Wait ARQ protocols you have seen in the lectures. For this part, you are to implement a Stop-and-Wait ARQ protocol at the transport layer. We have already given you a base code in Java. You must implement your methods over this code. After your implementation is complete, you can run the main method of Main.java under the main package to see whether your code passes the tests. If you are having problems, you may set Main.DEBUG to true to see some more information on what is happening behind the scenes. You should see the following output when your implementation is completed successfully: Fig 1. The output you should be getting. You only need to implement two methods residing in Transport.java under the transport package: ● void sendWithARQ(Packet[] packets) Used by the sender. Gets an ordered list of message packets and sends them one by one to the receiver, using Stop and Wait ARQ. ● Packet[] receiveWithARQ() Used by the receiver. Receives the message packets sent by the sender using Stop and Wait ARQ and returns them as an array. While implementing your methods, you will need to use the methods and classes that are already provided to you. First, take a look at Packet.java under the network package. A packet can either be a message packet or an acknowledgement packet. Here are the important fields that you should be familiar with in your implementation: ack, lastPacket, sequenceNumber, characters, timedOut. The methods that you should be using are in the Transport.java under the transport package. Here are the explanations: ● Packet receivePacket(int timeout) Receives a packet from the other process. If the timeout parameter is given as > 0, the process waits timeout milliseconds for a packet before failing. Upon timeout failure, this method will return an empty packet with its timedOut flag set to true. If the timeout parameter is given as ≤ 0, this method blocks infinitely. ● void sendMsgPacket(int sequenceNumber, boolean lastPacket, Packet packet) Sends a single message packet to the other process. The sequenceNumber parameter is either 0 or 1, and it denotes the sequence number of the message packet that you are sending. The lastPacket parameter should be set to true only when you are sending the last message packet to the receiver. The packet parameter is the actual message packet you are trying to send. ● void sendAckPacket(int sequenceNumber, boolean lastAck) Sends an acknowledgement packet to the other process. The sequenceNumber parameter is either 0 or 1, denoting the sequence number of the acknowledgement packet. The lastAck parameter should be set to true only when this acknowledgement message is being sent in response to the last message packet received from the sender. In conclusion, your implementation should do the following: ● At the sender (i.e., sendWithARQ method): 1. Sender must send each message packet using sendMsgPacket, setting the arguments correctly. 2. After a packet is sent, the sender must wait for an acknowledgement from the receiver using receivePacket with a reasonable timeout of your choice. 3. If the acknowledgement is not received within this duration, the sender must retransmit the packet. 4. If the acknowledgement was received within this duration and the sequence number is as expected, the sender must proceed to send the next packet. ● At the receiver receiveWithARQ: 1. Receiver must wait for packets using receivePacket. 2. Once a packet is received, the receiver should check the sequence number (using Packet.sequenceNumber) and discard the packet or save it depending on its sequence number. 3. Receiver should also check Packet.lastPacket field of the received message packet. ▪ If the received packet is not the last message packet: The receiver must send a single acknowledgement packet with the correct sequence number using sendAck, and then wait for the next message packet. ▪ If the received packet is the last message packet: If this is the last packet, we will send our last acknowledgement using sendAck and break out of our loop. Part 4.b – Analyzing Your Implementation After your implementation is complete, please answer the following questions in your report. 16.Start listening on your Loopback interface with Wireshark and run your code. How many retransmissions have occurred from the sender to the receiver? Explain. 17.Attach a screenshot of the first packet sent by the sender and the last packet received by the receiver. How long did it take to transfer all the packets? Consider the timeout period that you have chosen and the amount of retransmissions. Does this result make sense? Why or why not? Note: You will not see the “lost packets” on Wireshark. Project Deliverables: Important Note: You are expected to submit a project report, in PDF format, that documents and explains all the steps you have performed in order to achieve the assigned tasks of the project. A full grade report is one that clearly details and illustrates the execution of the project. Anyone who follows your report should be able to reproduce your performed tasks without effort. Use screenshots to illustrate the steps and provide clear and precise textual descriptions as well. All reports would be analyzed for plagiarism. Please be aware of the KU Statement on Academic Honesty. The name of your project .zip file must be -.zip You should turn in a single .zip file including: ▪ Source codes: Containing the source codes of client and server, and also your completed version of part 4 code. ▪ Project.pdf file (Your report, should include answers and the corresponding Wireshark screenshots) ▪ Saved capture files from the Wireshark. Figures in your report should be scaled to be visible and clear enough. All figures should have captions, should be numbered according to their order of appearance in the report, and should be referenced and described clearly in your text. All pages should be numbered, and have headers the same as your file naming criteria. If you employ any (online) resources in this project, you must reference them in your report. There is no page limit for your report, and no specific requirements on the design. Good Luck!

This project is about the network layer of the Internet protocol stack. The objectives are to examine the network layer data, the principles behind network layer services, and routing (path selection). Through this project, you will practice with Wireshark as well as a simplified network routing simulator. The first part of the project requires you to analyze traffic data at the network layer through Wireshark. ICMP traffic will be monitored resulting from the application of a) ping and b) traceroute commands. The second part of the project involves working with the provided routing simulator and implementing routing strategies to analyze their performance. Part I: ICMP Analysis ICMP is a companion protocol to IP that helps IP to perform its functions by handling various error and test cases. The Internet Control Message Protocol (ICMP) is a supporting protocol in the Internet protocol suite. It is used by network devices, including routers, to send error messages and operational information indicating, for example, that a requested service is not available or that a host or router could not be reached. ICMP differs from transport protocols such as TCP and UDP in that it is not typically used to exchange data between systems, nor is it regularly employed by end-user network applications (with the exception of some diagnostic tools like ping and traceroute). 1.a: Ping Analysis For this part of the project, you will use the ping command to analyze working of ICMP. ping uses the ICMP protocol’s mandatory ECHO_REQUEST datagram to elicit an ICMP ECHO_RESPONSE from a host or gateway. ECHO_REQUEST datagrams (“pings”) have an IP and ICMP header, followed by a struct timeval and then an arbitrary number of “pad” bytes used to fill out the packet. ping works with both IPv4 and IPv6. Using only one of them explicitly can be enforced by specifying -4 or -6. ● Run the Wireshark packet capture. ● Ping the hostname URL assigned to you. ● You are required to send exactly 5 ping messages at 5 different times in a day or duration of the project and share the screenshot of the command prompt with a summary of ping completion and associated statistics. ● After the completion of ping, stop capture and answer the following questions. Remember to attach screenshots with each answer highlighting the relevant area. 1. What are the three layers in the ICMP packet? 2. What is TTL and its significance? Which layer does it reside in and is it constant ( format and no. of bits wise) across IPV4 and IPV6 ping commands? 3. Why is it that an ICMP packet does not have source and destination port numbers? 4. What is the length of the datafied of the ICMP part Type -8? Elaborate on the structure of the datafield citing any correspondingly common and changing parts across various messages? If part of the data field, what do you think is the reason for that? 5. Find the minimum TTL below which the ping messages do not reach your particular URL destination. 6. How do the Identifier and Sequence Number compare for successive echo request packets? 1.b : Traceroute Analysis In this part, you will use traceroute (may need to be installed) to perform the same set of actions as in Part-1.a. Traceroute is implemented in different ways in Unix/Linux/MacOS and in Windows. In Unix/Linux, the source sends a series of UDP packets to the target destination using an unlikely destination port number; in Windows, the source sends a series of ICMP packets to the target destination. For both operating systems, the program sends the first packet with TTL=1, the second packet with TTL=2, and so on. Recall that a router will decrement a packet’s TTL value as the packet passes through the router. When a packet arrives at a router with TTL=1, the router sends an ICMP error packet back to the source. In the following, we’ll use the native Windows tracert program. A shareware version of a much nicer Windows Traceroute program is pingplotter (www.pingplotter.com). The source and destination IP addresses in an IP packet denote the endpoints of an Internet path, not the IP routers on the network path the packet travels from the source to the destination. Traceroute is a utility for discovering this path. It works by eliciting ICMP TTL Exceeded responses from the router 1 hop away from the source towards the destination, then 2 hops away from the source, then 3 hops, and so forth until the destination is reached. The responses will identify the IP address of the router. Since traceroute takes advantage of common router implementations, there is no guarantee that it will work for all routers along the path, and it is usual to see “ * ” responses when it fails for some portions of the path. ● Start up the Wireshark packet sniffer, and begin Wireshark packet capture. ● Use traceroute with the same URL. (Note that on a Windows machine, the command is “tracert” and not “traceroute”.) ● On Linux, force the traceroute command to send ICMP packets instead of the UDP packets. You may look for this information using ‘man traceroute’ and choosing the appropriate flag. ● When the Traceroute program terminates, stop packet capture in Wireshark. At the end of the experiment, your Command Prompt Window should show that for each TTL value, the source program sends three probe packets. Traceroute displays the RTTs for each of the probe packets, as well as the IP address (and possibly the name) of the router that returned the ICMP TTL-exceeded message. 7. How long is the ICMP header of a TTL Exceeded packet? Select different parts of the header in Wireshark to see how they correspond to the bytes in the packet. 8. How does your computer (the source) learn the IP address of a router along the path from a TTL exceeded packet? 9. How many times is each router along the path probed by traceroute? 10. Within the tracert measurements, is there a link whose delay is significantly longer than others? The echo request packets sent by traceroute are probing successively more distant routers along the path. You can look at these packets and see how they differ when they elicit responses from different routers. Part II: Routing Implementation In this part, you are asked to implement greedy routing algorithms at the network control plane and answer related questions. You are provided with a simulator and two topologies. You will need to implement four different algorithms and observe their behavior under the given topologies. The topologies given to you can be visualized as following: Fig 1. Topology 1 visualized. Fig 2. Topology 2 visualized. The numbers on the nodes denote the address of the node (i.e., router), and the numbers on the edges denote the cost of that link. Please note that the graph is undirected. For example, node 2 has a link to node 3 with a cost of 1 and vice-versa. In our simulation, node 1 tries to send a packet to node 4. Simulator Explanation The simulator given to you can be executed by running the Main.java file. The outputs will be helpful to you in your implementation and answering the questions. The expected simulator outputs are given in the “expected_output.txt” file. The algorithms that you need to implement reside at the “algorithms” package. You will only need to implement the selectNeighbors method for each algorithm. Each node stores an instance of an Algorithm and invokes selectNeighbors method when there is a new packet to forward. The output of this method determines to which neighbors the packets will be forwarded to. Briefly, selectNeighbors takes the following parameters: ● Origin: The address of the origin of the packet. ● Destination: The address of the destination of the packet. ● PreviousHop: The address of the previous hop (i.e., the node that the packet was sent from.) ● Neighbors: A list of NeighborInfo instances that contain the neighbors that the node has. Your implementation should select a subset of Neighbors and return them. The node that invoked the algorithm will route the packets to the list of neighbors that you have returned. NaiveFloodingAlgorithm: Go to NaiveFloodingAlgorithm class residing under the “algorithms” package. This algorithm is already given to you as an example. A node using this algorithm simply routes a packet to all of its neighbors (except the previous hop.) Run the simulator and observe the behavior of this algorithm. Then, answer the following questions in your report: 11. See that this algorithm succeeds in topology 1. What does the total communication cost represent, and why is it different from the path cost? 12. See that this algorithm fails in topology 2, and the simulator notes that the protocol does not converge. Why is this the case? FloodingAlgorithm: FloodingAlgorithm is a simple improvement over the NaiveFloodingAlgorithm: Each node in the topology only routes once. You can maintain a state, and return the neighbors only when selectNeighbors is called the first time. Go to FloodingAlgorithm class and implement it. Then, answer the following questions in your report: 13. Consider the path taken by the packet in topology 2 with this algorithm. Is this what you have expected? Why or why not? NaiveMinimumCostAlgorithm: NaiveMinimumCostAlgorithm always chooses the link with the smallest cost. This algorithm only returns a single neighbor (i.e., returns a list with only one neighbor,) as opposed to the flooding algorithms. While finding the appropriate neighbor, make sure that you do not consider the previous hop. Go to NaiveMinimumCostAlgorithm and implement it. Then, answer the following questions in your report: 14. If you implemented the algorithm as specified, it should succeed in topology 1 but fail in topology 2. Why does it fail in topology 2? MinimumCostAlgorithm: MinimumCostAlgorithm is an improvement over NaiveMinimumCostAlgorithm. More specifically, now we only consider the “edges” that were not previously used. This algorithm should maintain an exclusion set, i.e., a set of neighbors that should be excluded from routing to prevent cycles. When choosing the link with the minimum cost, we find the minimum of the neighbors that are not in the exclusion set. If all of the neighbors are already in the exclusion set, we simply choose a random neighbor. Please note that at the end of each call to selectNeighbors, two nodes should be added to the exclusion set: (1) the node that the packet was received from, (2) the node that the packet is being forwarded to. Go to MinimumCostAlgorithm and implement it. 15. List the nodes in the exclusion set of each node at the end of the simulation of topology 2. Demonstration: In the demo session, you are required to demonstrate the working of your Part-II implementation including the executions of the routing algorithms. You are also expected to answer questions on the concepts of Network Layer. The dates and the schedule of the demonstrations will be announced later. Project Deliverables: Important Note: You are expected to submit a project report, in PDF format, that documents and explains all the steps you have performed in order to achieve the assigned tasks of the project. A full grade report is one that clearly details and illustrates the execution of the project. Anyone who follows your report should be able to reproduce your performed tasks without effort. Use screenshots to illustrate the steps and provide clear and precise textual descriptions as well. All reports would be analyzed for plagiarism. Please be aware of the KU Statement on Academic Honesty. The name of your project .zip file must be -.zip You should turn in a single .zip file including: ▪ Source codes: Containing the source codes of your completed version of part-II. ▪ -_P3.pdf titled Project Report. o For Part-I, your report should include the answers to the questions and the corresponding Wireshark screenshots. o For Part-II, a brief explanation of the implementation of the requirements supported by code snippets and answers to questions from this part. ▪ Saved capture files from the Wireshark. Figures in your report should be scaled to be visible and clear enough. All figures should have captions, should be numbered according to their order of appearance in the report, and should be referenced and described clearly in your text. All pages should be numbered, and have headers the same as your file naming criteria. If you employ any (online) resources in this project, you must reference them in your report. There is no page limit for your report. Good Luck!