Assignment Task
You are required to take your UDP-based chat client and server and solve two key challenges with it. First, clients have no proper way of handling a server disappearing unexpectedly, or not being there in the
first place. They would send off a message to the server and wait indefinitely for a reply that is never coming. Second, keeping track of all of the addresses for all of the different rooms is painful for both
players and for the rooms. As the game world gets larger, this becomes a bigger and bigger problem.
Copyright By PowCoder代写 加微信 powcoder
To solve the first challenge, you will add timeouts to the player client. That way, if it does not hear from the server after a decent amount of time, it can report an error and exit appropriately. No more
waiting around forever!
To solve the second challenge, you will build a simple discovery service for rooms. When a room server starts, it registers its name and address with the discovery service. Later, when player clients or other
room servers need to connect with it, they can lookup the address for the server by querying the discovery service. This way, the various parts of the game need only identify themselves by name, and the
discovery service handles the yucky part of keeping track of all of the corresponding addresses. Convenient!
Some Particulars – Adding Timeouts
Here are some specific requirements and other important notes:
• When your player client sends a message to a room server and waits for a response, it should employ a timeout. If the server does not respond in the indicated amount of time, the player client should
report an error to the user and terminate as cleanly as possible. The timeout should be set to 5 seconds using a constant.
To implement a timeout, you have a few options. One is the settimeout0) function provided for sockets. The other is by specifying a timeout when using selectors. It is likely easier to use the settimeout()
function, but you do have experience with selectors too.
Some Particulars – Discovery Service
Here are some specific requirements and other important notes:
The discovery service you create will map room names into server addresses of the form room://host:port, the same format used in previous assignments.
• Before starting any room servers or player clients, your discovery service would be started. It will listen on a fixed UP port for incoming requests. This port number will be stored as a constant in the
discovery service, as well as the player client and room service. The player client and room service will also have the host address for the discovery service stored in a constant. (Ordinarily, we would use
broadcasting to find the discovery service, but the university would likely not like all of us broadcasting around quite so much …)
The discovery server must support the following messages:
• REGISTER room://host:port name
Registers a server, with host giving the name of your server, port giving its port number, and name being the name of the room, given as a parameter to the room server on the command line
o DEREGISTER name
Deletes the registration for the server registered under the given name.
LOOKUP name
Attempts to lookup the address of a server with the given name.
In response to messages, the discovery service will return the following responses:
• OK result
The request was successful; result contains the optional results of the request. (Nothing for REGISTER/DEREGISTER, the address for the server with LOOKUP.)
• NOTOK msg
The request was not successful; msg contains an error message describing the result.
• When a room server starts, it no longer takes a port number as a command line parameter. Instead, the server will ask the system to allocate it an available port number. The server will then register with
the discovery service by sending it a REGISTER request. When receiving a REGISTER request, the discovery service will record the name to address mapping for the incoming server if they are unique,
sending an OK response back to the server. If the name or the address have been previously registered, the discovery service will send a NOTOK response with an appropriate error message. In such a
case, the room server reports the error to the user and terminates.
• When a room server terminates, it sends the discovery service a DEREGISTER request. When receiving a DEREGISTER request, the discovery service will attempt to remove the registration for the named
server from its records. If the record existed and was removed, it sends an Ok response back to the server. Otherwise, it sends a NOTOK response back to the server. (In practice, this shouldn’t happen,
but should things should handle errors appropriately.)
Connections to other rooms are still specified on the command line when starting a room server using the -n, -s, -e, -W, -u, and -d parameters. This time, however, instead of specifying these connections
using the addresses of the corresponding servers, you would simply use the name of the server instead. For example, if a room is connected to the Foyer to its north, you would indicate this by passing the
parameters “-n Foyer” to the server on startup, instead of specifying the address of the other server.
When a player client starts, it no longer takes a server address as a parameter on its command line. Instead, it takes the name of room to start in. For example, if player Alice wants to start in the Foyer,
they would invoke their client by executing: “python3 player.py ”
• In the process of joining a room, the player client first determines the address of the server hosting the room by issuing a LOOKUP request to the discovery service. On receiving a LOOKUP request, the
discovery service will attempt to find the named server in its records. On success, it returns an OK response to the requesting client, sending along the address of the server in room://host:port format to
the client. If the named room does not exist in its records, the discovery service instead returns a NOTOK response along with an error message. In such a case, the receiving client would print the error
message to the user and terminate.
Similarly, whenever the player moves from room to room, these new joins will follow a similar process, with a LOOKUP request to the discovery service providing the address of the new room service.
• If a room server needs to connect to another server, for example to transfer inventories of moving players if the inventories were stored server-side instead of client-side, the server will similarly use a
LOOKUP request to the discovery service to get the address it needs to send it its message.
Final Notes
You are to provide all of the Python code for this assignment yourself, except for code used from the Assignment #3 implementation provided to you. You are not allowed to use Python functions to execute
other programs for you, nor are you allowed to use any libraries that haven’t been explicitly allowed. (If there is a particular library you would like to use/import, other than those listed above and things like
socket, os, or sys, you must check first. You cannot use things like socketserver, for example.) Your server should be called room. py and your client should be called player.py. The discovery service should
be called discovery.py. You may name any other files you create for your program in some other appropriate way (though you likely don’t need any others). All of these files must be submitted with your
assignment.
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com