delete : delete a reservation for during time for day quit: server updates file reservations.txt and quits The server should implement checks to ensure that requests are sensible. For example, a reserve request can only be made for a valid room, timeslot, and day, and should not conflict with an already existing reservation. Similarly, deleting a reservation should result in an error message to the user if such a reservation does not exist. Running the Server Assuming your server implementation is stored in a file Server.py, you will run the server by executing the following command: Python Server.py post where port is the port number the server listens on. Remember that you have to pick a port number greater than 1024, because only processes running with root (administrator) privilege can bind to ports less than 1024. The Client You should write a client that basically works as the user interface to the application. The client allows a user to enter commands, sends them to the server, receives the replies, and displays the results to the user. As such, in this assignment, the client is probably simpler than the server. Assuming your client is implemented in a file Client.py, then as mentioned above, you should write the client so that it starts with the following command: Python Client.py heat post where host is the name of the computer the server is running on and port is the port number it is listening to. Note that you can run the client and server either on different machines or on the same machine. When running the client and server on the same machine, you can use either the IP address assigned to the PC or use the generic loopback IP address 127.0.0.1. The primary task of the client is to establish and manage the connection to the server. One of the error cases to worry about in a client-server application is the loss of messages over the network or the partial failure of one component. How to deal with these errors depends on the type of sockets you choose to use. For datagram sockets, using UDP as the underlying transport layer protocol, the client has a bit more work to do explicitly than with streaming sockets. Because UDP is an unreliable protocol, some of the packets sent to the server may be lost, or some of the packets sent from server to client may be lost. For this reason, the client cannot wait indefinitely for a reply to a message. You should have the client wait up to one second for a reply; if no reply is received, then the client should assume that the packet was lost during transmission across the network. You will need to research the API for DatagramSocket to find out how to set the timeout value on a datagram socket (see also Lab 1). When developing your code, you should run the server on your machine, and test your client by sending packets to localhost (or 127.0.0.1). After you have fully debugged your code, you should see how your application communicates across the network with a server run on a separate computer, across a network (if you have access to more than one PC in your location).