In this assignment, you will write two complete programs in any programming language supported on our Linux CSE machines to support a client/server model using Linux sockets for a UDP "ping" utility, similar to the ping utility already available on our CSE machines.
Server
The server program will be called with one command-line argument, the port number being used, such as ./pingsvr 8001. If the user calls the server program with too few or too many arguments, you will print out a usage statement and terminate the program.
The server will set up a UDP socket on the Internet (i.e., INET) domain and then wait in an infinite loop listening for incoming UDP packets, specifically PING messages from a client. Your server should be able to support multiple clients at the same time (though no extra work is expected to support this requirement).
Packet Loss: UDP provides applications with an unreliable transport service. Messages may get lost in the network due to a variety of reasons. Since packet loss is rare or even non-existent in typical campus networks for small amounts of data, including Local the server in this project will inject artificial loss to simulate the effects of network packet loss. The server will simulate 30% packet loss through generation of a seeded, randomized integer that will determine whether a particular incoming PING message is lost or not.
When a PING message comes in from a client and if the packet is not lost, the server will print the client message to the terminal and then send a PONG message back to the client. If the packet is determined to be lost (based on the seeded, random integer that was generated), the server will print an appropriate message to the terminal and simply "eat" the message by not responding to the client.
The server will remain "always on" until a user enters Ctrl-C (^C) to send an interrupt signal to the program to terminate.
Client
The client program will be called with two command-line arguments, the hostname of the server and the port number being used, such as ./pingcli cse06 8001. If the user calls the client program with too few or too many arguments, you will print out a usage statement and terminate the program.
The client will send 10 automated PING messages to the server using a UDP socket, where automated means the message is built in the code, not entered from the keyboard. Because UDP is an unreliable protocol, a packet sent from the client to the server may be lost in the network. For this reason, the client cannot wait indefinitely for a reply to a PING message. You should have 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.
Specifically, for each of the 10 PING messages, your client program should:
send the PING message using the UDP socket and print a status message;
if the response message is received from the server, calculate and print the round trip time (RTT) in milliseconds for each message; otherwise, print a status message that it timed out.
After all of the PING messages have been sent (and responses received or timed out), the client program should report the following and then terminate:
the number of messages sent, the number of messages received, and the message loss rate (as a percentage);
the minimum, maximum, and average RTTs for all of the PING messages in milliseconds.
Your program should run on the INET domain using SOCK_DGRAM (i.e., UDP) sockets so that the server and the client execute on a different CSE machine.
Given the randomness of what messages get dropped, it could be that less than or greater than 30% of the messages are dropped. Notice, however, in the SAMPLE OUTPUT that the server did indeed receive 10 PING messages, but "dropped" a few of the messages through our Packet Loss simulation.
You will also need to make sure you are able to handle any error cases.
SAMPLE OUTPUT (user input shown in bold):
==> SERVER on cse06 $ ./pingsvr usage: ./pingsvr $ ./pingsvr 8001 [server]: ready to accept data... [client]: PING [server]: dropped packet [client]: PING [client]: PING [client]: PING
It is not our intention to break the school's academic policy. Posted solutions are meant to be used as a reference
and should not be submitted as is. We are not held liable for any misuse of the solutions.
Please see the frequently asked questions page
for further questions and inquiries.
Kindly complete the form.
Please provide a valid email address and we will get back to you within 24 hours.
Payment is through PayPal, Buy me a Coffee
or Cryptocurrency.
We are a nonprofit organization however we need funds to keep this organization operating
and to be able to complete our research and development projects.
