Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due

INFO1112 - Assignment 2 - Tic-Tac-Toe

3 Protocol

In order to support playing the game over the network, your programs will need to implement a custom application-layer protocol as described here in order to facilitate client and server interactions.

All communications will use TCP, and you should use sockets  to communicate over the network. 

More details about sockets are available from the documentation of Python’s socket module.  A how-to guide for getting started with using TCP sockets is available on Python’s website, and some material will be included in the lab content to help explain how to create and interact with TCP sockets.

A couple of general notes about the protocol:

•  Like many application-layer protocols (e.g. HTTP, SMTP), the protocol is text based, and specifically, uses ASCII encoding for all data.

• When sending data over the network, you will need to ensure you  encode  data into bytes to send it over a network socket, and when receiving data, you will need to ensure you decode the received data to interpret this as a string.

– Hint 1: use the str.encode method to encode a string into bytes with a specified encoding.

– Hint 2: use the bytes.decode method to decode bytes to a string.

• You may assume that no message will ever exceed a buffer size of 8192 bytes.

•  The majority of protocol messages require the user to be authenticated  (after a  LOGIN message) in order for a client to be able to successfully interact with the server.  If a category of messages (one of the subheadings below) requires authentication, the subheading will have (authentication required) written next to it to indicate this.

Attempting to send a message from a client requiring authentication without being logged in will result in a BADAUTH message being sent from the server to the client in response to the sent message (see below).

3.1 Authentication-related Messages

3.1.1 LOGIN::

This message is sent from the client to the server, and is used to authenticate a user account in order to be able to play and/or watchgames hosted by the server.

The client will send over the username of the user who is attempting to authenticate themselves, and a plaintext password.

When the server receives this message, it will inspect the user database to check if the user with the given  exists, and if so, checks that the sent  matches the password hash of the user in the user database, which has been encrypted with the bcrypt algorithm (see Allowed Modules for installing the bcrypt Python library on your local device).

If the username exists in the user database, and the password provided matches the password hash in the user database, the user will be considered to be successfully authenticated, meaning:

– the server should associate the client socket object of the user which sent the message with the user account as actively authenticated, meaning the user has permission to interact with all messages requiring authentication.

*  multiple clients logging in to the same user account will not be assessed – you are free to handle this how you see fit.

– the server should respond to the client with a LOGIN:ACKSTATUS:0 message, indicating a suc- cessful authentication.

– the client should print the message Welcome   to stdout after having received the above message from the server.

• If the username cannot be found in the user database:

– the server should respond to the client with a LOGIN:ACKSTATUS:1 message.

– the client should print Error:    User    not  found message to stderr after having received the message above

• If the username was found in the database, but the password sent did not match the password hash in the database:

– the server should respond to the client with a LOGIN:ACKSTATUS:2 message.

– the client should print Error:    Wrong  password  for  user   to stderr after hav- ing received the above message from the server.

•  If a LOGIN message was sent with an invalid format, i.e.  0 or 1 arguments:

– the server should respond to the client with a LOGIN:ACKSTATUS:3 message.

– NOTE: Since your client program should be correct, it should never send an invalid LOGIN message like this, and so there is no error message the client should print in this case. 

However, this error message is included to help ensure robustness for the server handling such messages, such as if you were to use a program such as netcat/nc to directly send messages to the server.

Sequence Diagram

3.1.2 REGISTER::

This message is sent from the client to the server, and is used to create a new user account in order to be able to play and view games.

The client will send over the username and password of the user who is attempting to register themselves.

When the server receives this message, it will inspect the user database to ensure the user with the given  exists does not exist, and will then perform an appropriate action described below:

•  If the username does not  exist in the user database, the user may be successfully created, meaning:

– the server should create a new user record in the user database, containing:

* the username of the new user.

*  a password  hash for the password for the new user  account,  hashed  using  the  bcrypt algorithm.

— once the user record is created, the server is required to immediately write to and update the user database file with the new information for the user.

* you should either open and close the file for writing to do this, or altenatively, call the flush method to immediately write the contents of the file to the disk – either is acceptable, as long as no data is lost.

– the server should respond to the client with a REGISTER:ACKSTATUS:0 message, indicating a successful user account creation.

– the client should print the message  Successfully  created  user  account   to stdout after having received the above message from the server.

– NOTE: the user will not be logged in immediately after registration – the client needs to send a separate LOGIN message to authenticate the user.

• If the username already exists in the user database:

– the server should respond to the client with a REGISTER:ACKSTATUS:1 message, indicating the user already exists in the user database.

– the client should print the message Error: User already exists to stderr after having received the above message from the server.

•  If a REGISTER message was sent with an invalid format, i.e.  0 or 1 arguments:

– the server should respond to the client with a REGISTER:ACKSTATUS:2 message.

– NOTE: Since your client program should be correct, it should never send an invalid REGISTER message like this, and so there is no error message the client should print in this case. However, this error message is included to help ensure robustness for the server handling such messages, such as if you were to use a program such as netcat/nc to directly send messages to the server.

Sequence Diagram

3.1.3 BADAUTH

This is a special message which will be sent from the server  to the  client  in  response to  any  protocol message which requires authentication to perform – so make sure you check for this message when sending

3.3.1 BEGIN::

This message is sent from the server to a client, used to inform clients about the players which will be versing each other when commencing a game of tic-tac-toe.

is the username of the player who places the first marker  (an ’X’), while  is the username of the player who places the second marker (an ’‘’O’).

When a second player joins a room, the server will send this message to all players and viewers in the current room, informing them that a game is to begin:

• the client who is logged in as player  will be prompted to begin the game and place their first marker.

• the client who is logged in as player  will be prompted to wait until  has placed their first marker (which means that they need to wait until a BOARDSTATUS message has been sent by the server (see below)).

•  any room member’s client end should output the message ”match between  and  will commence, it is currently ’s turn. ’”

This message does not require the client to send anything in response.

Sequence Diagram

3.3.2 INPROGRESS::

This message is sent from the server to a client who joins as a viewer to an in-progress  game, informing them:

• the username of the player who’s turn it currently is ().

• the username of the opposing player who is awaiting their turn ().

When the viewing client receives this message, it should output the message ”Match between  and  is currently in progress, it is ’s turn”

This message does not require the client to send anything in response and players’ client ends are not supposed to receive this message.

Sequence Diagram

3.3.3 BOARDSTATUS:

This message is sent from the server to a client to inform them of the current status of the game board after a move has been made by a player.

Every player and viewer in a room must receive this message after a move has been made.  explainer is a 9-character text string which represents the current state of the 3x3 tic-tac-toe board. There are 3 characters used to represent a space on the tic-tac-toe board:

•  0 – empty space

• 1 – ’X’ marker

•  2 – ’O’ marker

The string is essentially a 1D mapping of the 2D array for tic-tac-toe:  i.e.  each space in the tic-tac-toe board numbered like so:

is mapped to the  string 123456789. For instance, a board of the current status:

would have  equal to 012010020.

Client actions

Any time a client receives this message, they should print the board’s current status to stdout.

Depending on whether the client in the game is a player or viewer, other specific actions will be performed:

• if the client is a player, and:

– has just placed their own marker (having just sent PLACE:: to the server), the client will recognise that it is the opposing player’s turn (who’s username is known from the BEGIN message sent when the game has started), and will output that ”It  is  the  opposing  player’s  turn”, and wait for the opposing player to complete their turn.

– has been waiting for an opposing player 

– if this message is received by the player, it means that the opposing player has placed their marker, and hence, the client should output ”‘It is the current player’s turn’”, and ask the user to input the x-y coordinates of the marker they

wish to place.

•  if the client is a viewer, after having printed the board to stdout, the client should print that it is the next corresponding player’s turn (the client will have the names of all players from either a BEGIN or INPROGRESS message sent prior).

This message does not require the client to send anything in response.

Sequence Diagram

3.3.4 PLACE::

This message is sent from the client to the server, and is used by a player to place a marker on the board when it is the player’s current turn.

and  refer to the coordinates on where the marker should be placed on the game board, using 0-based indexing for the spot.

The server makes the assumption that the client sending this message has already validated that  and  is valid on the client side  (i.e. valid coordinates, not currently occupied, etc.),  and that the  PLACE message will always contain 2 arguments, and hence will simply process the request as is without needing to do any error handling.

(As a rationale for this, imagine that this protocol will only ever by used by our own program implementations)

Once a client has sent a PLACE message to the server, the server will place the marker corresponding to the player appropriately, and send either a BOARDSTATUS message informing the player of the current board’s status as an acknowledgement, or a GAMEEND message (see below), indicating the game has finished.