This project is worth 150 points (15% of the course grade) and must be completed and turned in to the handin system before 11:59 PM on Friday, Dec 7, 2018.
1. Assignment Overview
The goal of this assignment is to gain hands-on experience programming with sockets and transport protocols (TCP and UDP). You will implement a simple name guessing game using socket programming in Python to send and receive messages between a client program and a server program.
2. Project Description
The project3_skeleton.zip file is provided to you. It contains:
- pdf (This document)
- py (Don’t modify this)
Your job is to complete the skeleton code in server.py and client.py to successfully play a simple name guessing game. (The game implementation is mostly done for you, so you need to mainly focus on sending messages back and forth using TCP and UDP sockets).
The idea is the client will contact the server by sending a datagram message using UDP announcing itself to the server. The server responds with the TCP port the client should use for further communication. Finally, send game messages back and forth using TCP. The client repeatedly guesses names by sending them to the server. The backend (server) handles the game logic. When a new game is started a random name is generated. The player will try to guess the name. If the name is two high (later alphabetically), the game will say that the guess was too high. If the guess was too low, the game will say that as well. If the guess was too short (too few letters) or too long, the game will say that as well. by checking the guess and indicating of the guess. It also decrements the number of attempts left in the case of an incorrect or already guessed name. The skill level of the game can also be set between 1 and 8. This determines what the maximum number of letters in the name and the number of guesses that are available to the player.
If the guess is wrong, display one of the following messages on the client:
- You are too high and too short!
- You are too high and too long!
- You are too high!
- You are too low and too short!
- You are too low and too long!
- You are too low!
Too high means you are too high alphabetically.
Each message consists of a message type followed by any message parameters. The message type is separated from the parameters by a space character. Each message ends with a newline character. (Remember TCP is a stream protocol and does not have the concept of messages. So the application must define what makes up a message.) The message type will dictate to each program what to do next (this is outlined in Section 6 below). An example exchange of game messages is shown in Figure 1 for your reference.
You should modify the README.txt with your information, the machines you tested your programs on, a list of resources you used, additional comments, and some sample test output from your programs (both client and server).
3. Client Specifications
The client should accept two command line arguments:
- Name of the server host
- UDP Port to be used to contact the server process Example: python client.py arctic.cse.msu.edu 55678
When the client is first started it should prompt the user for their name. After the user has entered their name, the client should send a datagram containing the hello message with the user’s name. It should then wait for a return datagram from the server. This datagram will contain a port TCP message. The client should add a timeout value on the UDP socket so that if a server does not respond to the hello request the client can send the message again. This time out should be set to 30 seconds. If the request times out, the client should retry sending the hello message up to 3 times before giving up. Each time the client retries sending the hello message, it should display the following message to the player:
No Response from the Server, retrying…
If after 3 tries, the server still has not responded, the player should see the following message:
No Response from the Server, please try again later.
Once the client receives the portTCP message from the server, the client should open a TCP socket connecting with the server using its name and the port number contained in the portTCP message. It should then prompt the user and allow them to enter various game playing commands. Note the game playing commands are not necessarily the same as the network message types. While similar there are some differences. The client should support the game commands being entered in any case (upper, lower, or mixed case). The user ends a game command by pressing the enter key. Remember after the initial message exchange all additional communication with the server should be performed using TCP messages to the port provided by the portTCP message.
The player (user) interacts with the client program by entering game playing commands through their keyboard. The client should support the following game playing commands:
- start – Starts a new
- Level – Sets the skill level for the next
- end – Ends the current game. If a game is not already in progress this command has no effect. Sends an end message to the server indicating that the player does not want to make any more guesses. The client can start a new game or
- guess <name> – Used by the user to enter a
- exit – Ends the client
Based on the game playing commands the client program sends the appropriate network message to the server to perform the actual game action. The description of these messages is shown in Section 5. That section also describes the action which should be taken when that message type is received.
4. Server Specifications
The server should accept a single command line argument. This argument should be the port number for the UDP socket the server initially opens. The server will only support one game at a time, but a client can play multiple games one right after another. The client can end a game at any time by sending an end message. The game also ends when the player either accurately guesses the name or uses all their guesses. If the TCP connection from the client is closed at any time while a game is in progress the server should end the game and perform any necessary cleanup so that a new client can connect and start a game.
When started, the server should create a TCP socket to be used for connections from clients. When creating this socket, it should have the system dynamically allocate an available port. To allow clients to know which TCP socket the clients should use the server should also create a UDP socket using the port number given on the command line. If this number is 0 then the system will dynamically assign a port number. If you would like to specify the port number to use you need to pick a port number not already in use. An easy way to do this is to form a number by preceding the last 4 digits of your PID with the digit 5. For example, if one of the
team member’s PID is 12345678 then port 55678 could be specified as the port number when opening the UDP socket. The server should display both the TCP and UDP port numbers that it is using. This is how clients know which port to use when contacting the server.
python server.py 0
python server.py 59999
The server should detect the client closing the TCP connection unexpectedly and perform any cleanup necessary.
Once the connection has been closed the server should be prepared for another client to connect and start a new game.
5. Messages and Message Actions
The following table lists the client and server messages that need to be used for this project. All messages consist of a “message type”, a space separator, followed by message arguments. The client and server can assume that the message type is always in the specified case.
The server should do the following when receiving various message types:
- hello – The server now knows the name of the user. The server should send its TCP port number to the
- new – Indicates to the server program that the client wishes to start a new game at the specified skill level. It should pick a new name and respond with its own new message indicating the currently selected skill
- guess – Includes the name being guessed in its message text. Upon receiving a guess message, the server will use the provided checkGuess() function to update the match, len, and attempts variables. If ending conditions are met:
- guess was correct (match = 0),
- there are no more attempts (attempts = 0)
an end message will be sent with either a win or loss message text. Otherwise, if ending conditions are not met, a stat message will be sent with the updated match, len, and attempts variables.
- end – Ends the current game. The server should respond with a corresponding end message containing a message to the
The client should do the following when receiving various message types:
- portTCP – Extract and store the server program’s provided TCP port number. Then prompt the player for a game
- stat – Decode the meaning of the match, len, and attempts variables displaying the appropriate message text then prompt for a game command from the
- end – Display the message
- na – Display the message text and then prompt for a new game
6. Bonus Points
Modifying the server code to support multiple simultaneous clients will earn extra 20 points. To earn the extra points, you need to provide:
- A separate source file with name py in addition to server.py.
- A document (in txt/word/pdf format) that describes in detail your design and implementation.
- txt showing output from at least 2 clients simultaneously playing the game. You should modify the server output to clearly identify which client the event is coming from.
7. Assignment Deliverables
You should turn in a .zip file to handin containing:
- Names.py (non-modified)
- Other documents specified in the “Bonus Points” section
This file should be named prj3_netid.zip where netid is your MSU network login user name. This is not your last name or your first name or your PID!
本网站支持淘宝 支付宝 微信支付 paypal等等交易。如果不放心可以用淘宝交易！
E-mail: [email protected] 微信:dmxyzl003
本网站支持淘宝 支付宝 微信支付 paypal等等交易。如果不放心可以用淘宝交易！
E-mail: [email protected] 微信:dmxyzl003