The University of Queensland School of Electrical Engineering and Computer Science CSSE2310 – Semester 2, 2024 Assignment 4 (Version 1.0) Marks: 75 Weighting: 15% Due: 3:00pm Friday 25 October, 2024 This specification was created for the use of Jiaxiang LIANG (s4568784) only. Do not share this document. Sharing this document may result in a misconduct penalty. Introduction 1 The goal of this assignment is to further develop your C programming skills, and to demonstrate your under- 2 standing of networking and multithreaded programming. You are to create a server program (uqchessserver) 3 that supports multiple simultaneously connected clients playing chess against another client or against a chess 4 engine (Stockfish). The server will maintain pipe connections to and from a single chess engine process and 5 mediate client requests for the engine’s services. You should also create a client program (uqchessclient) that 6 can send requests to the server and show responses. 3226 7 Communication between the clients and uqchessserver is over TCP using a text based protocol defined 8 later in this specification. 9 The assignment will also test your ability to code to a particular programming style guide and to use a 10 revision control system appropriately. 11 It is not necessary that you know how to play chess to undertake this assignment, though knowledge of 12 how pieces can move on a chess board may be useful in testing (i.e. knowing which moves are valid). See 13 https://en.wikipedia.org/wiki/Chess#Rules to learn more about the rules of chess if you are interested. 3226 14 Student Conduct 15 This section is unchanged from assignments one and three – but you should remind yourself of the referencing requirements. Remember that you can’t copy code from websites and if you learn about how to use a library function from a resource other than course-provided material then you must reference it. 16 This is an individual assignment. You should feel free to discuss general aspects of C programming and 17 the assignment specification with fellow students, including on the discussion forum. In general, questions like 18 “How should the program behave if 〈this happens〉?” would be safe, if they are seeking clarification on the 19 specification. 20 You must not actively help (or seek help from) other students or other people with the actual design, structure 21 and/or coding of your assignment solution. It is cheating to look at another person’s assignment code 22 and it is cheating to allow your code to be seen or shared in printed or electronic form by others. 23 All submitted code will be subject to automated checks for plagiarism and collusion. If we detect plagiarism or 24 collusion, formal misconduct actions will be initiated against you, and those you cheated with. That’s right, if 25 you share your code with a friend, even inadvertently, then both of you are in trouble. Do not post your 26 code to a public place such as the course discussion forum or a public code repository. (Code in private posts 27 to the discussion forum is permitted.) You must assume that some students in the course may have very long 28 extensions so do not post your code to any public repository until at least three months after the result release 29 date for the course (or check with the course coordinator if you wish to post it sooner). Do not allow others to 30 access your computer – you must keep your code secure. Never leave your work unattended. 31 You must follow the following code usage and referencing rules for all code committed to your SVN 32 repository (not just the version that you submit): 33 © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 1 Version 1.0 Document generated 2024-10-05 10:47 Code Origin Usage/Referencing Code provided by teaching staff this semester Code provided to you in writing this semester by CSSE2310 teaching staff (e.g., code hosted on Blackboard, found in /local/courses/csse2310/resources on moss, posted on the discussion forum by teaching staff, provided in Ed Lessons, or shown in class). Permitted May be used freely without reference. (You must be able to point to the source if queried about it – so you may find it easier to reference the code.) Code you wrote this semester for this course Code you have personally written this semester for CSSE2310 (e.g. code written for A1 reused in A3) – pro- vided you have not shared or published it. Permitted May be used freely without reference. (This assumes that no reference was required for the original use.) Unpublished code you wrote earlier Code you have personally written in a previous enrolment in this course or in another UQ course or for other reasons and where that code has not been shared with any other person or published in any way. Conditions apply, references required May be used provided you understand the code AND the source of the code is referenced in a comment adjacent to that code (in the required format – see the style guide). If such code is used without appropriate referencing then this will be considered misconduct.Code from man pages on moss Code examples found in man pages on moss. (This does not apply to code from man pages found on other systems or websites unless that code is also in the moss man page.) Code and learning from AI tools Code written by, modified by, debugged by, explained by, obtained from, or based on the output of, an artificial intelligence tool or other code generation tool that you alone personally have interacted with, without the assis- tance of another person. This includes code you wrote yourself but then modified or debugged because of your interaction with such a tool. It also includes code you wrote where you learned about the concepts or library functions etc. because of your interaction with such a tool. It also includes where comments are written by such a tool – comments are part of your code. Conditions apply, references & documentation req’d May be used provided you understand the code AND the source of the code or learning is referenced in a com- ment adjacent to that code (in the required format – see the style guide) AND an ASCII text file (named toolHistory.txt) is included in your repository and with your submission that describes in detail how the tool was used. (All of your interactions with the tool must be captured.) The file must be committed to the reposi- tory at the same time as any code derived from such a tool. If such code is used without appropriate referencing and without inclusion of the toolHistory.txt file then this will be considered misconduct. See the detailed AI tool use documentation requirements on Blackboard – this tells you what must be in the toolHistory.txt file. Code copied from sources not mentioned above Code, in any programming language: • copied from any website or forum (including Stack- Overflow and CSDN); • copied from any public or private repositories; • copied from textbooks, publications, videos, apps; • copied from code provided by teaching staff only in a previous offering of this course (e.g. previous assignment one solution); • written by or partially written by someone else or written with the assistance of someone else (other than a teaching staff member); • written by an AI tool that you did not personally and solely interact with; • written by you and available to other students; or • from any other source besides those mentioned in earlier table rows above. Prohibited May not be used. If the source of the code is referenced adjacent to the code then this will be considered code without academic merit (not misconduct) and will be re- moved from your assignment prior to marking (which may cause compilation to fail and zero marks to be awarded). Copied code without adjacent referencing will be consid- ered misconduct and action will be taken. This prohibition includes code written in other program- ming languages that has been converted to C. Code that you have learned from Examples, websites, discussions, videos, code (in any pro- gramming language), etc. that you have learned from or that you have taken inspiration from or based any part of your code on but have not copied or just converted from another programming language. This includes learning about the existence of and behaviour of library functions and system calls that are not covered in class. Conditions apply, references required May be used provided you do not directly copy code AND you understand the code AND the source of the code or inspiration or learning is referenced in a comment adjacent to that code (in the required format – see the style guide). If such code is used without appropriate referencing then this will be considered misconduct. © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 2 Version 1.0 Document generated 2024-10-05 10:47 You must not share this assignment specification with any person (other than course staff), organ- 34 isation, website, etc. Uploading or otherwise providing the assignment specification or part of it to a third 35 party including online tutorial and contract cheating websites is considered misconduct. The university is aware 36 of many of these sites and many cooperate with us in misconduct investigations. You are permitted to post 37 small extracts of this document to the course Ed Discussion forum for the purposes of seeking or providing 38 clarification on this specification. 39 In short – Don’t risk it! If you’re having trouble, seek help early from a member of the teaching staff. 40 Don’t be tempted to copy another student’s code or to use an online cheating service. Don’t help another 41 CSSE2310/7231 student with their code no matter how desperate they may be and no matter how close your 42 relationship. You should read and understand the statements on student misconduct in the course profile and 43 on the school website: https://eecs.uq.edu.au/current-students/guidelines-and-policies-students/ 44 student-conduct. 45 Specification - uqchessclient 46 The uqchessclient program provides a command line interface that allows you to interact with the server 47 (uqchessserver) as a client – connecting for a session, playing one or more games in that session and then 48 exiting. Because your client will need to listen for incoming messages on both stdin and the network connection, 49 it will require two threads. Alternatively, you can implement your client using multiplexed IO as demonstrated 50 in class.3226 51 Command Line Arguments 52 Your uqchessclient program is to accept command line arguments as follows: 53 ./uqchessclient port [--col white|black] [--versus person|comp] 54 The square brackets ([]) indicate optional arguments. The pipe symbol (|) indicates a choice. Italics 55 indicate a placeholder for a user-supplied arguments. The port argument must always be the first argument. 56 Option arguments can be in any order after the port argument. 57 Some examples of how the program might be run include the following1: 58 ./uqchessclient 1234 59 ./uqchessclient 3456 --versus comp 60 ./uqchessclient mysql --col black 61 ./uqchessclient 8978 --col white --versus person 62 The meaning of the arguments is as follows:3226 63 • port – this mandatory argument specifies which localhost port the server is listening on – either numerical 64 or the name of a service. 65 • --versus – if specified, this option is followed by either the string comp or person and indicates that, 66 by default, the user wishes to play against the computer (i.e. the chess engine) or a “human” player 67 respectively. If this argument is not specified, then the default is to play against the computer. 3226 68 • --col – if specified, this option argument is followed by either the string white or black and indicates 69 the colour (white or black) that the user wishes to be. If this argument is not specified, then the default 70 is play white against a computer opponent and either colour against the first available human opponent. 71 Note that white always plays first in chess.3226 72 Prior to doing anything else, your program must check the command line arguments for validity. If the 73 program receives an invalid command line then it must print the (single line) message: 74 Usage: uqchessclient port [--col white|black] [--versus person|comp] 75 to standard error (with a following newline), and exit with an exit status of 9. 76 Invalid command lines include (but may not be limited to) any of the following: 77 • No arguments are present (i.e. there is no port argument) 78 • An option argument is present but is not followed by a valid option value 79 1This is not an exhaustive list and does not show all possible combinations of arguments. The examples also assume that a uqchessserver server is running on the listed ports. © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 3 Version 1.0 Document generated 2024-10-05 10:47 • Any of the option arguments is listed more than once. 80 • An unexpected argument is present.3226 81 • Any argument is the empty string. 82 Checking whether the port is a valid port or service name is not part of the usage checking (other than 83 checking that the value is not empty). The validity of the port or service name is checked after command line 84 validity as described next. 85 Client Port Checking 86 If uqchessclient is unable to create a socket and connect to the server on the specified port (or service name) 87 of host localhost, it shall print the following message (terminated by a newline) to stderr and exit with exit 88 status 5: 89 uqchessclient: unable to make connection to port "N " 90 where N should be replaced by the argument given on the command line. (This may be a non-numerical string.) 91 The double quotes must be present.3226 92 Client Runtime Behaviour 93 Assuming that the checks above are passed and your uqchessclient can successfully connect to the server, 94 then your uqchessclient must print and flush the following message to stdout (terminated by a newline): 95 Welcome to UQChessClient - written by s4568784 96 Once this message is printed, the client will act as if a newgame command has been entered by the user as 97 described below (i.e. send a “start” message to the server with appropriate argument(s)) and must then read 98 lines of input from the user (via stdin) and respond to them as described below (e.g. usually by sending a 99 message to the server), and will simultaneously read lines received from the server (via the connected socket) 100 and respond to them as described below. Often the messages from the server will be responses to requests 101 sent by the client but this is not always the case. Communication is asynchronous – either party can send a 102 message at any time – so your client must be implemented to support this. You can do this by using two threads 103 (one reading from stdin and one reading from the connected network socket) or by using multiplexed IO as 104 demonstrated in class.3226 105 Note that uqchessclient does not have to understand chess or know the current position of pieces, etc. 106 The server will keep track of the game state. The client must however keep track of whether a game is currently 107 in progress or not and whose turn it currently is (the user or the opponent) and what colour the user is playing. 108 3226 109 Client – Handling Standard Input 110 The user can enter the following commands on stdin. Commands are to be terminated by a single newline. 111 No leading or trailing spaces are to be accepted. If an invalid command is entered, then uqchessclient must 112 print the following message to stderr (terminated by a newline):3226 113 Try again - command invalid 114 Valid commands are listed below. In most cases, these will result in a message being sent to the server. 115 See the Communication Protocol section on page 6 for details for how those messages are formatted and which 116 arguments are mandatory and which are optional. 117 • newgame 118 This command indicates that the user wishes to start a new game and will result in a “start” message 119 being sent to the server (with appropriate argument(s)). This command is valid even if a current game is 120 in progress (no matter whose turn it is). 121 • print 122 This command this indicates that the user wishes to have the current state of the board printed out. If a 123 game is in progress or has finished then the command will result in a “board” message being sent to the 124 server. (The client does not keep track of the board state – it must ask the server for this.) If the first 125 game has not been started yet then an error message must be printed (see below)2.3226 126 2The only situation in which this error should happen is if the client wishes to play a human and no human opponent has yet been assigned. © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 4 Version 1.0 Document generated 2024-10-05 10:47 • hint 127 This command indicates that the user wishes to receive a hint from the server’s chess engine about the 128 best move to make next. If a game is in progress and it is the user’s turn then the command will result 129 in the “hint best” message being sent to the server. Otherwise, an error message must be printed (see 130 below). 131 • possible 132 This command indicates that the user wishes to know all possible moves that they could make given the 133 current game state. If a game is in progress and it is the user’s turn then the command will result in the 134 “hint all” message being sent to the server. Otherwise, an error message must be printed (see below). 135 • move movestring 136 This command indicates that the user wishes to make the indicated move. The command “move” must be 137 followed by a single space and then by 4 or 5 alphanumeric characters before the newline (the movestring ) 138 to be considered valid. This associated movestring argument is a chess move expressed in standard chess 139 long algebraic notation as used by the Universal Chess Interface (UCI), e.g. e2e4 indicates that the piece on 140 square e2 should be moved to square e43. See https://en.wikipedia.org/wiki/Algebraic_notation_ 141 (chess) for details on chess notations. If the command is invalid then a message must be printed as 142 described above. If the command is valid and a game is in progress and it is the user’s turn then this will 143 result in a “move” message being sent to the server. Otherwise, an error message must be printed (see 144 below). (Note that a valid command may not contain a valid chess move. The server will report this if 145 needed – it is not the client’s job to know which moves are valid on the game board or not.)3226 146 • resign 147 This command indicates that the user wishes to resign from the current game. If a game is in progress 148 then this will result in a “resign” message being sent to the server. Otherwise, an error message must be 149 printed (see below). A user can resign at any time in the game, not just when it is their turn.3226 150 • quit 151 This command indicates that the user wishes to exit the program. The uqchessclient program should 152 exit immediately, without sending anything to the server. The same behaviour is expected if the stdin 153 of uqchessclient is closed even if the user has entered part of a command (e.g. stdin will be closed if 154 a terminal user presses Ctrl-D at the start of a line or Ctrl-D Ctrl-D part way through a line). Partially 155 entered lines are to be ignored. Your client must exit with status 0. 156 If a valid command above is entered (i.e. the line matches the syntax outlined above) but no action can be 157 taken because a game is not in progress or hasn’t started yet, then uqchessclient must print a message to 158 stderr (with a terminating newline): 159 Command not valid - game not in progress 160 The client should consider a game to be in progress from the time it receives an “ok” response in reply to a 161 “start” message through until the time it receives a “gameover” message. 162 If a game is in progress, but a valid command can’t be acted on because it is not the user’s turn, then 163 uqchessclient must print a message to stderr (with a terminating newline):3226 164 Invalid command - not your turn 165 No messages are to be sent to the server in either of these cases. The user can enter another command if 166 desired. 167 Client – Handling Messages from Server 168 The client may receive messages from the server at any time. These messages will have the form outlined in 169 the Communication Protocol section below. 170 The client must just print all lines of text received from the server to the client’s stdout, with the exception 171 of the startboard and endboard lines that surround the depiction of the game board. (The lines between these 172 keywords will be output – including any blank lines.) All messages must be flushed to stdout upon receipt4. 173 There is no need for the client to check that messages comply with the protocol – they can just be output as 174 described.3226 175 The client must also use the content of the messages (e.g. “gameover” messages and others) to keep track 176 of the game state, specifically, whether a game is currently in progress, and if so, whether it is the client’s turn 177 3A movestring may be 5 characters for a pawn promotion move, e.g. g7g8q indicates a pawn moving to the final rank and being promoted to a queen. 4uqchessclient can not assume that stdout is line buffered. © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 5 Version 1.0 Document generated 2024-10-05 10:47 to play or not. Specifically, a game will be in progress from when the client receives a “started” message from 178 the server until it receives a “gameover” message. The player whose turn it is will change every time an “ok” 179 or “moved” message is received from the server. 180 Note that a well implemented client should almost never receive some error responses from the server – it 181 should never send an invalid command and it should never send commands that assume a game is in progress 182 if it is not. It may receive an error message if the chess engine fails or if a move is invalid. Rarely, a game-not- 183 in-progess error will be received in the event that a game-ending race condition occurs5. error messages from 184 the server should just be printed to the client’s stdout like other messages from the server. 185 Other Client Requirements 186 If your client detects that the connection to the server has been closed then it should print the following message 187 to stderr (terminated by a newline): 188 uqchessclient: lost communication with server 189 and exit with status 20. 190 There is no requirement that uqchessclient free all memory before exiting. 3226 191 Your client must not exit due to SIGPIPE. 192 Communication Protocol 193 This section describes the incoming and outgoing messages that will be supported by uqchessserver. All 194 messages are to be terminated with a single newline (\n) and no leading or trailing spaces are permitted. Each 195 message is a command word that may be followed by arguments as described below. If a message accepts 196 arguments then arguments must be separated using a single space character. In the messages below, square 197 brackets ([]) indicate optional arguments, and italics indicate placeholders for specified values.3226 198 See the Specification - uqchessserver section below for precise details of how the server should behave. 199 Messages to server 200 The following incoming messages must be supported by uqchessserver. 201 • start against colour 202 – A “start” message indicates to the server that the client is starting a new game. The argument 203 against must be either “computer” or “human” (without the quotes) and indicates to the server 204 which type of opponent the client will play against. The argument colour must be one of “either”, 205 “black” or “white” (without the quotes) and indicates the colour of pieces that the client will use. 206 The “either” option will only matter if the client is playing against a human. If this option is specified 207 with a “computer” opponent, then the client will be playing white pieces. See the Specification - 208 uqchessserver section for details of how the server assigns colours to human players if “either” is 209 specified.3226 210 – The server’s response to this message will be a “started” message – see below. This may take some 211 time to come back if the client is requesting to play a human and no other player has connected to 212 the server. This “started” response will specify which colour that this client will be playing (which 213 will match the colour specified by this client if black or white was specified). 214 – If a game is in progress for this client when this message is sent, then the server must treat this 215 as a resignation and send a “gameover” response as described below, before sending the “started” 216 message.3226 217 – If the client is playing the “computer” and has chosen to be black, then the server (playing white) 218 will also send a “moved” message to indicate the computer’s first move in the game. 219 • board 220 – This message asks the server to return the current game board or the game board of a game that 221 has just finished (anytime before a “start” request is made). If a game is in progress or has just 222 finished, the server will respond with a multi-line response starting with startboard and finishing 223 5A race condition can occur if the client believes that a game is in progress and sends a message on this basis, but the server has just received a resignation from their human opponent so finishes the game, but receives the client’s message before sending out the gameover message to the client – followed by an error 3 message in response to the client’s message because the game is no longer in progress. © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 6 Version 1.0 Document generated 2024-10-05 10:47 with endboard - see below. If the first game has not started yet, the server will respond with an 224 error response. 225 • hint best|all 226 – Either “best” or “all” (without the quotes) must be given as an argument to the “hint” command.3226 227 – With the “best” argument, this message asks the server to return a hint to the client about the next 228 move that the client can make. If a game is in progress and it is this client’s turn then the server 229 will respond with a moves response (see below), otherwise the server will respond with an error 230 response. 231 – With the “all” argument, this message asks the server to return a list of all the possible moves a 232 client can make. If a game is in progress and it is this client’s turn then the server will respond with 233 a moves response (see below), otherwise the server will respond with an error response. 234 • move move-to-make 235 – This message indicates the move that the client wishes to make. The required argument move-to-make 236 must be a 4 or 5 character alphanumeric string that indicates the move in long chess algebraic no- 237 tation (e.g. e2e46). The server will respond with either an “ok” or “error” response depending on 238 whether the move is valid in the current game state or not. 3226 239 – If the move was accepted (“ok” response received) then the message might also be followed by a 240 “check” or “gameover” response from the server if the move resulted in check or checkmate or 241 stalemate. (See the Specification - uqchessserver section for details.) 242 – If the client is playing the “computer” (and the client’s move did not finish the game) then the server 243 will also send a moved message to indicate the move that the “computer” is making. 244 • resign 245 – This message indicates that the client is resigning from the current game. The server will respond 246 with either a gameover or error response – see below. 247 Messages from server to client 248 The following messages may be sent by uqchessserver.3226 249 • started colour 250 – The server will send this response to a “start” message, when the game can be started. 251 – The argument colour confirms the colour that the client will be playing. (This will match the colour 252 the user requested, but is present for those situations where the user requested either colour against 253 a human opponent.) 254 • ok 255 – The server will send this response to a “move” message if the move is a valid move on the game 256 board. 257 • error reason 258 – The server will send this response to the client when it can not accept or process a message sent by 259 the client or some other error has happened. The required argument (reason ) will be a single word 260 and must be one of:3226 261 – engine 262 Chess engine failure. If the chess engine fails (terminates for some reason) then the message 263 “error engine” must be sent to all clients before the server exits. See the Specification - 264 uqchessserver section for more details. 265 – command 266 Invalid command – the server does not understand this command (which could include invalid 267 formatting, e.g. unknown command, additional characters, etc.). A properly implemented client 268 will never send invalid commands but a server must handle them gracefully if received. 269 – game 270 Game not in progress – this command can not be accepted because no game is currently in 271 progress.3226 272 6Castling can be represented by showing the movement of the king, e.g. e1g1. Pawn promotion can be indicated by appending a letter indicating which piece the pawn is promoted to, e.g. h7h8q. © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 7 Version 1.0 Document generated 2024-10-05 10:47 – turn 273 Not your turn – this command can not be accepted because it is not currently the client’s turn 274 to play (but a game currently is in progress). 275 – move 276 Invalid move – the attempted move is not valid for this game 277 • startboard 278 lines of text 279 endboard 280 – This multiline message returns the current state of the game board. The lines between the startboard 281 line and the endboard line will contain an ASCII art representation of the board. These lines may 282 contain spaces and blank lines.3226 283 • moves move-details [...] 284 – This message will be sent in response to a valid “hint” message and will contain one or more moves 285 (each 4 or 5 character alphanumeric strings), space separated, each in chess long algebraic notation 286 (e.g. e2e4). Only one move will be sent in response to a “hint best” message. One or more moves 287 will be sent in response to a “hint all” message.3226 288 • moved move-made 289 – This message will tell the client the move made by their opponent (human or computer). The 290 move-made argument will be a 4 or 5 character alphanumeric string in chess long algebraic notation 291 (e.g. e7e5). 3226 292 • check 293 – This message will be sent by the server when it detects that the most recent move has resulted in a 294 king being in a “check” position. This message will be sent in response to a move message from the 295 client to the server in place of an ok message if the client’s move has resulted in the opponent’s king 296 being in check (but not checkmate). It will immediately follow a moved message from the server to 297 the client if the opponent’s move has resulted in the client’s king being in check.3226 298 • gameover how [winner] 299 – This message tells the client that the current game is now over. The required argument how is one 300 of “checkmate” or “stalemate” or “resignation” (without the quotes). If the how argument is 301 “checkmate” or “resignation” then the winner argument must also be supplied and will be either 302 “white” or “black” (without the quotes) – indicating which colour won the game. This message will 303 be sent in place of an “ok” message if the client’s move has resulted in checkmate or stalemate. This 304 message may arrive to a client at any time if their human opponent resigns (the “computer” never 305 resigns). If two clients are playing (i.e. two humans) then the same message is sent to both clients. 306 Specification - uqchessserver 307 uqchessserver is a networked, multithreaded server that manages chess games for connected clients. It will 308 start and communicate with a single chess engine process (Stockfish) and use that engine to support all of the 309 games that are in progress. Games can be between one client and another client or between a client and the 310 “computer” (i.e. the chess engine).3226 311 All communication between clients and the server is via a ASCII text line-based protocol over TCP. See the 312 Communication Protocol section on 6 for details.3226 313 Command Line Arguments 314 Your uqchessserver program is to accept command line arguments as follows: 315 ./uqchessserver [--port portnum ] 316 The square brackets ([]) indicate optional arguments. Italics indicate a placeholder for a user-supplied 317 argument. The option argument may be absent or present at most once. 318 Some examples of how the program might be run include the following7: 319 ./uqchessserver 320 7This is not an exhaustive list and does not show all possible combinations of arguments. © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 8 Version 1.0 Document generated 2024-10-05 10:47 ./uqchessserver --port 2310 321 The meaning of the arguments is as follows:3226 322 • --port – if specified, this option argument is followed by a string which specifies which localhost port 323 the server is to listen on. This can be either numerical or the name of a service. If this is zero or this 324 argument pair is absent, then uqchessserver is to use an ephemeral port.3226 325 Prior to doing anything else, your program must check the command line arguments for validity. If the 326 program receives an invalid command line then it must print the (single line) message:3226 327 Usage: ./uqchessserver [--port portnum] 328 to standard error (with a following newline), and exit with an exit status of 19. 329 Invalid command lines include (but may not be limited to) any of the following: 330 • The --port option argument is given but it is not followed by a non-empty string argument 331 • An unexpected argument is present.3226 332 • Any argument is the empty string. 333 Checking whether the portnum argument is a valid port or service name is not part of the usage checking 334 (other than checking that the value is not empty). The validity of this value is checked after command line 335 validity as described below. 336 Port Checking 337 If uqchessserver is unable to listen on the given port (or service name) of localhost, it shall output the 338 following message (terminated by a newline) to stderr and exit with status 8: 339 uqchessserver: unable to start listening on port "N " 340 where N should be replaced by the argument given on the command line. (This may be a non-numerical string.) 341 The double quotes must be present. Being “unable to listen on a given port” includes the cases where the socket 342 can’t be created, the port string is invalid, the socket can’t be bound to the address, and the socket can’t be 343 listened on. Note that we will not test the situation where uqchessserver is unable to listen on an ephemeral 344 port.3226 345 Starting the Chess Engine 346 If the checks above succeed, then uqchessserver is to start the chess engine (Stockfish). A single chess engine 347 is used by uqchessserver no matter how many clients are being serviced. Stockfish (which is run using the 348 stockfish executable on moss) is a Universal Chess Interface (UCI) compliant chess engine8 which means that 349 it listens for text commands on its stdin and provides text responses on its stdout. Details of UCI can be 350 found at https://backscattering.de/chess/uci/, however, the necessary information for this assignment 351 can be found in this specification in the UCI – Universal Chess Interface section below.3226 352 To start the chess engine, your uqchessserver program must: 353 • create two pipes – one will be for uqchessserver to write to the Stockfish process’s stdin and one will 354 be for the server to read from the Stockfish process’s stdout; 355 • fork to create a child process;3226 356 • redirect/close file descriptors as appropriate; 357 • in the child process, run the program stockfish – which is to be found in the user’s path (no command 358 line arguments are to be provided); 359 • send the “isready” message to stockfish and wait for the “readyok” response (another line will be sent 360 before this also – this can be ignored); and 361 • after the “readyok” response has been received, send the “uci” message to stockfish and wait for the 362 “uciok” response (other lines will be sent before this also – these can be ignored). 363 8Stockfish has some additional functionality beyond that required in UCI. We take advantage of that in this assignment, e.g. the presence of the “d” command. © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 9 Version 1.0 Document generated 2024-10-05 10:47 Note that stockfish’s stderr should just be inherited from that of uqchessserver. 364 If uqchessserver is unable to start the Stockfish process, e.g. SIGPIPE or EPIPE or other error is detected 365 when writing to stockfish or EOF is detected when reading from stockfish then uqchessserver must print 366 the following message to stderr (with a terminating newline):3226 367 uqchessserver: can’t start communication with chess engine 368 and exit with status 6. No client connections are ever to be accepted. 369 Your server can assume that the chess engine is well behaved, i.e., that if you are expecting a response in 370 accordance with the UCI protocol then that response will be forthcoming, i.e. reads from stockfish looking 371 for that response won’t block forever.3226 372 If, after starting the chess engine (the first readyok and uciok responses are received) your uqchessserver 373 ever detects that the Stockfish process has exited (e.g. by detecting an error when writing to stockfish, or 374 detecting EOF when reading the pipe from stockfish), then the server must reap the child process, send 375 an error message to all connected clients (if any) (see the Communication Protocol) section), and print the 376 following message to stderr (with a terminating newline): 377 uqchessserver: chess engine exited unexpectedly 378 and then exit with exit status 9. 379 This is the only circumstance under which the server is expected to exit after it has completed the start-up 380 checks (on the command line arguments and whether it can listen and whether it can start the chess engine). 381 It is not necessary for the server to free all memory when it exits (under this or any circumstance). 382 Runtime Behaviour 383 Once the port is opened for listening and the chess engine started, uqchessserver shall print to stderr the 384 port number that it is listening on (not the service name) followed by a single newline character and then flush 385 the output. In the case of ephemeral ports, the actual port number obtained shall be printed, not 386 zero.3226 387 Upon receiving an incoming client connection on the port, uqchessserver shall spawn a new thread to 388 handle that client (see below for client thread handling).3226 389 The uqchessserver program should not terminate under normal circumstances (unless the chess engine 390 terminates – see above), nor should it block or otherwise attempt to handle SIGINT. 391 Note that your uqchessserver must be able to deal with any clients, not just the client programs specified 392 for the assignment. Testing with netcat is highly recommended.3226 393 Client handling threads 394 A single client handler thread is spawned for each incoming connection. This client thread must then wait for a 395 message from the client, and act on it – which in many cases will involve sending a message to the chess engine, 396 awaiting a response and then sending a response to the client. The exact format of client requests is described 397 in the Communication Protocol section on page 6. 398 Due to the simultaneous nature of multiple client connections, your uqchessserver will need to ensure 399 mutual exclusion around accesses to any shared data structure(s) and resources (e.g. the chess engine) so as to 400 ensure that data/messages do not get corrupted.3226 401 Once a client disconnects or there is a communication error on the socket (e.g. a read() or equivalent from 402 the client returns EOF, or a write() or equivalent fails) then the client handler thread is to close the connection, 403 clean up as appropriate (e.g. send a “gameover” message to a human opponent) and terminate. Other client 404 threads and the uqchessserver program itself must continue uninterrupted. uqchessserver must not exit in 405 response to a SIGPIPE.3226 406 Managing Chess Games 407 Your client thread must handle messages from the client as described in the Communication Protocol section. 408 Additional information on server behaviour in response to each message type is provided below. Note that each 409 client message will result in the specified behaviour, usually resulting in a response to the client. Once the 410 specified behaviour is undertaken (and a response sent to the client if appropriate), then the client thread must 411 await the next message from the client. Note that if messages must be sent to the chess engine, they will need 412 to be preceded by other messages that specify the game state - see the UCI – Universal Chess Interface section 413 below (page 13). 414 © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 10 Version 1.0 Document generated 2024-10-05 10:47 • start against colour 415 When the server receives a “start” message from a client, it must do the following: 416 – Conclude any game in progress as if a resignation message had been received. 417 – If the client wishes to play against a computer opponent, start the game and send back an appropriate 418 “started” response. If the computer is playing white, then the server must also generate a move 419 (see below) and send back a “moved” response. 420 – If the client wishes to play against a human opponent, then check to see if another client is awaiting 421 a human opponent and their colour choices are compatible (i.e. white with black or a specified colour 422 preference with no colour preference or both have no colour preference). If neither has a colour 423 preference then the first client waiting will be assigned the white pieces (i.e. the client that sent 424 the “start” message will be assigned black). If multiple clients are waiting with a particular colour 425 preference then the one which was the first to connect must be chosen. Appropriate “started” 426 messages must be sent to both clients9. If there is no colour-compatible human opponent waiting to 427 play, then this will be noted (so that if a colour-compatible client does connect then a game can be 428 started – by the other client’s thread). The client thread does not send a response to the client in 429 this case, but will wait for further messages from the client. 430 • board 431 When the server receives a “board” message from the client, it must do the following: 432 – If this client has never started a game (no “start” request has been received) or a “start” request 433 to play a human has been received and no colour compatible opponent is available, then the client 434 must send a game-not-in-progress “error” response. 435 – If a game is in progress (even if no moves have been made yet) then the server must issue a “d” 436 UCI request to the engine and return the current game board to the client between startboard and 437 endboard messages (see details of the “d” message in the UCI – Universal Chess Interface section). 438 – If a game is not in progress but one has been played (i.e. it is over) and no new “start” request has 439 been received, then the server must must issue a “d” UCI request to the engine and return the last 440 state of the game board (i.e. as it was when the last game finished) to the client between startboard 441 and endboard messages.3226 442 • hint [best|all] 443 When the server receives a “hint” message from the client, it must do the following: 444 – If a game is not in progress or it is not the client’s turn then issue an appropriate “error” response. 445 – If it is a “hint best” message, then the client thread must issue the UCI command “go movetime 446 500 depth 15” to the chess engine and await a “bestmove” line in the response. (This request 447 will limit the move search to 500 milliseconds or a depth of 15 moves, whichever happens sooner.). 448 The client thread must then send a moves response to the client with the move extracted from the 449 “bestmove” response from the chess engine. Other lines of text emitted by the chess engine (info 450 lines) are to be ignored. 3226 451 – If it is a “hint all” message, then the client thread must issue the UCI command “go perft 1” to 452 the chess engine and collect the moves in the response (over multiple lines). The client thread must 453 then send a “moves” response to the client with the moves extracted from the response. Other lines 454 of text emitted by the chess engine (“info” lines, blank lines and the count of “Nodes searched”) are 455 to be ignored. 3226 456 • move move-to-make 457 When the server receives a “move” message from the client, it must do the following: 458 – If a game is not in progress or it is not the client’s turn then issue an appropriate “error” response. 459 – If it is the client’s turn, then the client thread must issue a “position” UCI command with the 460 current board state (see below) and this specified move. Following this it must issue a “d” command 461 to get the board state to determine the outcome of the move. 462 – If the board state has not changed (the “Fen” line in the response is the same as before the 463 attempted move) then the move is not valid and the client thread must send the appropriate 464 “error” response to the client.3226 465 – If the board state has changed (the move was accepted) then an “ok” response must be sent to 466 the client. If the opponent is human then the “moved” message must be sent to the client of the 467 opponent. 468 9Note that this one client thread will be sending messages to two different connected clients. © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 11 Version 1.0 Document generated 2024-10-05 10:47 – If the move was accepted, the client thread must also send the “go perft 1” command to 469 the chess engine (to determine the number of valid moves for the opponent – from the “Nodes 470 searched” line in the response) and use the output of this and the output of the “d” command 471 to determine the consequences of the move as outlined next. 472 – If the move was accepted and the “Checkers” line in the “d” response is not empty then the 473 player is in check or checkmate. If there are zero possible moves for the opponent then this is 474 checkmate and the game is over. The client thread must send a “gameover” message to the 475 client (and the opponent’s client if the opponent is human). If there are possible moves then the 476 move has resulted in a check position and the client thread must send a “check” message to the 477 client (and the opponent’s client if the opponent is human). 3226 478 – If the move was accepted and the “Checkers” line in the “d” response was empty and there 479 are no valid moves for the opponent then this is a stalemate (the game is over, but no player 480 wins). The client thread must send an appropriate “gameover” message to the client (and the 481 opponent’s client if the opponent is human). 482 – If the opponent is the “computer” and the game was not finished by the provided move, then the 483 server must do the following: 484 – Generate a move that the computer will make in response. It does this is the same way that 485 hints are generated (see above), by sending the UCI command “go movetime 500 depth 15” 486 to the chess engine and waiting for the “bestmove” line (the last line) in the response. The best 487 move is then sent to the client with a “moved” message. 488 – Check whether the computer’s move resulted in check, checkmate or stalemate – using the same 489 approach described above. If so, this will result in the server sending a “check” or “gameover” 490 message to the client following the “moved” message. 3226 491 • resign 492 When the server receives a “resign” message from the client, it must do the following: 493 – If a game is not in progress then issue an appropriate “error” response.3226 494 – If a game is in progress, then this indicates that this client has resigned (i.e. lost the game). The 495 client thread must send an appropriate “gameover” message back to the client. If the opponent is 496 human, then an appropriate “gameover” message must be sent the opponent’s client also. 497 Game State 498 For each game, uqchessserver must maintain some game state: 499 • whether the game is in progress or finished; 500 • who is playing white (i.e. which client, or the computer); 501 • who is playing black (i.e. which client, or the computer – noting that at least one of the colours must be 502 played by a client); and3226 503 • the current or last game board state – maintained as a FEN string (provided by the chess engine – see 504 below). This string includes information about whose turn it is to play next. 505 Note that recording which client is playing which colour does not involve recording which thread is managing 506 that client – more likely it will involve recording the file descriptor or FILE* handle(s) associated with the client 507 so that messages can be sent to the client.3226 508 Note that the state of completed games must be maintained until the client(s) who played the game has/have 509 started another game or disconnected from the server. This is so that an appropriate response can be given to 510 a “board” message, i.e. what the board looked like at the end of the game. 511 Other Requirements 512 Other than the listening port number, and error messages, uqchessserver is not to emit any output to stdout 513 or stderr. 514 Your server must not leak memory. Your server is never expected to exit after startup (unless the chess 515 engine terminates for some reason) so your program never has to free all memory but it’s memory consumption 516 should not grow significantly over time. It is expected that the memory consumption of your program will be the 517 same after a client disconnects as it was just before the client connected (assuming no other clients connected 518 and remained connected in that time).3226 519 © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 12 Version 1.0 Document generated 2024-10-05 10:47 Your server must not busy wait. If a thread has nothing to do then it must be blocking, e.g. in accept() 520 or a reading call (such as read(), fread(), fgets(), or getline()), and not sleeping or busy waiting. 521 We will not test for unexpected system call or library failures in an otherwise correctly-implemented program 522 (e.g. if fork(), malloc(), pipe(), pthread_create(), etc. fails due to insufficient available resources). Your 523 program can behave however it likes in these cases, including crashing. 524 UCI – Universal Chess Interface 525 Full details about how Stockfish implements the Universal Chess Interface (UCI) can be found at 526 https://github.com/official-stockfish/Stockfish/wiki/UCI-&-Commands. Descriptions of the commands 527 you need to send to Stockfish, and the expected responses, are found below. In the examples below, green text 528 indicates commands sent to Stockfish via its stdin. Black text indicates response text from Stockfish via its 529 stdout. Commands and responses are terminated by a single newline.3226 530 • isready 531 This command must be sent prior to any other communication with the chess engine to check whether the 532 engine is ready or not. No other commands should be sent until the engine responds with a “readyok” 533 Example 1: Example interaction with Stockfish showing the isready command and response 1 Stockfish dev-20240917-60351b9d by the Stockfish developers (see AUTHORS file) 2 isready 3 readyok • uci 534 This command tells the engine to use UCI (Universal Chess Interface). The engine will return a number of 535 id and option lines identifying the engine and which options it supports, concluded by a uciok message. 536 None of the commands below should be sent until after this uciok response is received. 537 Example 2: Example interaction with Stockfish showing the uci command and response 1 uci 2 id name Stockfish dev-20240917-60351b9d 3 id author the Stockfish developers (see AUTHORS file) 4 5 option name Debug Log File type string default

6 option name NumaPolicy type string default auto 7 option name Threads type spin default 1 min 1 max 1024 8 option name Hash type spin default 16 min 1 max 33554432 9 option name Clear Hash type button 10 option name Ponder type check default false 11 option name MultiPV type spin default 1 min 1 max 256 12 option name Skill Level type spin default 20 min 0 max 20 13 option name Move Overhead type spin default 10 min 0 max 5000 14 option name nodestime type spin default 0 min 0 max 10000 15 option name UCI_Chess960 type check default false 16 option name UCI_LimitStrength type check default false 17 option name UCI_Elo type spin default 1320 min 1320 max 3190 18 option name UCI_ShowWDL type check default false 19 option name SyzygyPath type string default

20 option name SyzygyProbeDepth type spin default 1 min 1 max 100 21 option name Syzygy50MoveRule type check default true 22 option name SyzygyProbeLimit type spin default 7 min 0 max 7 23 option name EvalFile type string default nn-1111cefa1111.nnue 24 option name EvalFileSmall type string default nn-37f18f62d772.nnue 25 uciok • ucinewgame 538 This command tells the engine that the interactions that follow are associated with a different game. You 539 © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 13 Version 1.0 Document generated 2024-10-05 10:47 can think of this as a context switch – the engine will now be doing calculations for a different game – not 540 necessarily from the starting position. This command must always be followed by an isready command 541 and no further commands should be sent until a readyok response is received. (The engine will not send 542 a response to the ucinewgame command.) 543 Example 3: Example interaction with Stockfish showing the ucinewgame command 1 ucinewgame 2 isready 3 readyok • position startpos 544 position startpos moves movestring 545 position fen fenstring 546 position fen fenstring moves movestring 547 The position command specifies a given game state and optionally a move to make in that game state. 548 The game state can be startpos which indicates a chess board at the start of the game when no moves 549 have been made (white to play first). Alternatively, the game state can be specified as fen fenstring 550 which specifies the game state using a string in Forsyth Edwards Notation (FEN) – with fenstring made 551 up of six space-separated fields. If a move is specified (with the moves keyword), the following movestring 552 is a 4 or 5 character string in long algebraic notation, e.g. e2e4. The engine will not send a response to 553 the position command. Note that the second of six fields in the FEN string (either the letter ‘w’ or ‘b’) 554 indicates the colour of the next player to move. 555 Example 4: Examples of the position command 1 position startpos 2 position startpos moves e2e4 3 position fen rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 4 position fen rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq - 0 1 moves e7e5 • go perft 1 556 go movetime time depth depth 557 The go command specifies that the engine should evaluate the current position (as set with the position 558 command) to calculate a move or possible moves. The first variant, “go perft 1” will list all of the possible 559 moves that can be made from the current position and how many different moves are possible (listed against 560 the heading “Nodes searched:”). The second variant (“go movetime time depth depth ”) searches for 561 the best possible move from the current position. The time value is the maximum search time (in 562 milliseconds). The depth value is the maximum depth of the search (how many moves to look ahead). 563 The line of interest in the output is the “bestmove” line. The “ponder” element (if present) is the move 564 that the engine thinks is most likely in response – this value is ignored.3226 565 Example 5: Examples of the go command. The 20 possible moves are listed on lines 7 to 26. The best move to make is listed on line 50. 1 position startpos 2 go perft 1 3 info string Available processors: 0-11 4 info string Using 1 thread 5 info string NNUE evaluation using nn-1111cefa1111.nnue (133MiB, (22528, 3072, 15, 32, 1)) 6 info string NNUE evaluation using nn-37f18f62d772.nnue (6MiB, (22528, 128, 15, 32, 1)) 7 a2a3: 1 8 b2b3: 1 9 c2c3: 1 10 d2d3: 1 11 e2e3: 1 12 f2f3: 1 13 g2g3: 1 14 h2h3: 1 15 a2a4: 1 © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 14 Version 1.0 Document generated 2024-10-05 10:47 16 b2b4: 1 17 c2c4: 1 18 d2d4: 1 19 e2e4: 1 20 f2f4: 1 21 g2g4: 1 22 h2h4: 1 23 b1a3: 1 24 b1c3: 1 25 g1f3: 1 26 g1h3: 1 27 28 Nodes searched: 20 29 30 go movetime 500 depth 15 31 info string Available processors: 0-11 32 info string Using 1 thread 33 info string NNUE evaluation using nn-1111cefa1111.nnue (133MiB, (22528, 3072, 15, 32, 1)) 34 info string NNUE evaluation using nn-37f18f62d772.nnue (6MiB, (22528, 128, 15, 32, 1)) 35 info depth 1 seldepth 3 multipv 1 score cp 33 nodes 23 nps 23000 hashfull 0 tbhits 0 time 1 pv e2e4 36 info depth 2 seldepth 8 multipv 1 score cp 33 nodes 62 nps 62000 hashfull 0 tbhits 0 time 1 pv e2e4 e7e5 g1f3 d7d5 e4d5 e5e4 37 info depth 3 seldepth 10 multipv 1 score cp 33 nodes 95 nps 47500 hashfull 0 tbhits 0 time 2 pv e2e4 e7e5 g1f3 d7d5 e4d5 e5e4 f3e5 d8d5 38 info depth 4 seldepth 12 multipv 1 score cp 33 nodes 138 nps 69000 hashfull 0 tbhits 0 time 2 pv e2e4 e7e5 g1f3 d7d5 e4d5 e5e4 f3e5 d8d5 e5c4 f8e7 39 info depth 5 seldepth 13 multipv 1 score cp 33 nodes 182 nps 91000 hashfull 0 tbhits 0 time 2 pv e2e4 e7e5 g1f3 d7d5 e4d5 e5e4 f3e5 d8d5 e5c4 f8e7 b1c3 d5c6 40 info depth 6 seldepth 13 multipv 1 score cp 33 nodes 236 nps 118000 hashfull 0 tbhits 0 time 2 pv e2e4 e7e5 g1f3 d7d5 e4d5 e5e4 f3e5 d8d5 e5c4 f8e7 b1c3 d5c6 41 info depth 7 seldepth 13 multipv 1 score cp 33 nodes 292 nps 146000 hashfull 0 tbhits 0 time 2 pv e2e4 e7e5 g1f3 d7d5 e4d5 e5e4 f3e5 d8d5 e5c4 f8e7 b1c3 d5c6 42 info depth 8 seldepth 13 multipv 1 score cp 33 nodes 374 nps 187000 hashfull 0 tbhits 0 time 2 pv e2e4 e7e5 g1f3 d7d5 e4d5 e5e4 f3e5 d8d5 e5c4 f8e7 b1c3 d5c6 43 info depth 9 seldepth 13 multipv 1 score cp 33 nodes 608 nps 304000 hashfull 0 tbhits 0 time 2 pv e2e4 e7e5 g1f3 d7d5 e4d5 e5e4 f3e5 d8d5 e5c4 f8e7 b1c3 d5c6 44 info depth 10 seldepth 17 multipv 1 score cp 32 nodes 2040 nps 408000 hashfull 0 tbhits 0 time 5 pv e2e4 e7e5 g1f3 g8f6 d2d4 d7d5 e4d5 e5d4 f1b5 c7c6 d5c6 b7c6 b5e2 45 info depth 11 seldepth 17 multipv 1 score cp 31 nodes 2846 nps 569200 hashfull 0 tbhits 0 time 5 pv e2e4 e7e5 g1f3 g8f6 d2d4 f6e4 f3e5 d7d5 f1d3 f8d6 e1g1 e8g8 b1c3 e4c3 b2c3 d8h4 46 info depth 12 seldepth 17 multipv 1 score cp 30 nodes 3896 nps 556571 hashfull 0 tbhits 0 time 7 pv e2e4 e7e5 g1f3 b8c6 f1b5 g8f6 d2d4 f6e4 e1g1 47 info depth 13 seldepth 21 multipv 1 score cp 35 nodes 12002 nps 631684 hashfull 4 tbhits 0 time 19 pv e2e4 e7e5 g1f3 g8f6 d2d4 f6e4 f3e5 d7d5 d1f3 c8e6 f1d3 f8d6 d3e4 d5e4 f3e4 48 info depth 14 seldepth 18 multipv 1 score cp 33 nodes 15415 nps 670217 hashfull 5 tbhits 0 time 23 pv e2e4 e7e5 g1f3 g8f6 d2d4 f6e4 f3e5 d7d5 f1d3 b8c6 e1g1 f8d6 f2f4 e8g8 b1c3 49 info depth 15 seldepth 21 multipv 1 score cp 35 nodes 28782 nps 702000 hashfull 9 tbhits 0 time 41 pv e2e4 e7e5 g1f3 b8c6 d2d4 e5d4 f3d4 g8f6 d4c6 b7c6 f1d3 d7d5 e4e5 f6d7 e1g1 d7c5 50 bestmove e2e4 ponder e7e5 • d 566 The d command asks the engine to display details of the current game position and state. This includes an 567 © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 15 Version 1.0 Document generated 2024-10-05 10:47 ASCII art representation of the game board (white pieces are shown with upper case letters, black pieces 568 are shown with lower case letters10). The ASCII art lines, including the blank line immediately before the 569 art and the blank line immediately after the art, are the lines to be sent back to clients when requested 570 (with “startboard” and “endboard” delimiters). The FEN string (in the line with the “Fen:” prefix) 571 will be line saved as part of the game state – this contains full details about the game. The “Checkers:” 572 line lists the positions of all the pieces that have the current player’s king in check.3226 573 Example 6: Examples of the d command. Lines 3 to 22 (inclusive) or lines 28 to 47 (inclusive) would be those sent back in response to a “board” message. 1 position startpos 2 d 3 4 +---+---+---+---+---+---+---+---+ 5 | r | n | b | q | k | b | n | r | 8 6 +---+---+---+---+---+---+---+---+ 7 | p | p | p | p | p | p | p | p | 7 8 +---+---+---+---+---+---+---+---+ 9 | | | | | | | | | 6 10 +---+---+---+---+---+---+---+---+ 11 | | | | | | | | | 5 12 +---+---+---+---+---+---+---+---+ 13 | | | | | | | | | 4 14 +---+---+---+---+---+---+---+---+ 15 | | | | | | | | | 3 16 +---+---+---+---+---+---+---+---+ 17 | P | P | P | P | P | P | P | P | 2 18 +---+---+---+---+---+---+---+---+ 19 | R | N | B | Q | K | B | N | R | 1 20 +---+---+---+---+---+---+---+---+ 21 a b c d e f g h 22 23 Fen: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 24 Key: 8F8F01D4562F59FB 25 Checkers: 26 position fen 8/k7/8/2QK4/8/8/8/8 b - - 4 20 27 d 28 29 +---+---+---+---+---+---+---+---+ 30 | | | | | | | | | 8 31 +---+---+---+---+---+---+---+---+ 32 | k | | | | | | | | 7 33 +---+---+---+---+---+---+---+---+ 34 | | | | | | | | | 6 35 +---+---+---+---+---+---+---+---+ 36 | | | Q | K | | | | | 5 37 +---+---+---+---+---+---+---+---+ 38 | | | | | | | | | 4 39 +---+---+---+---+---+---+---+---+ 40 | | | | | | | | | 3 41 +---+---+---+---+---+---+---+---+ 42 | | | | | | | | | 2 43 +---+---+---+---+---+---+---+---+ 44 | | | | | | | | | 1 45 +---+---+---+---+---+---+---+---+ 46 a b c d e f g h 47 48 Fen: 8/k7/8/2QK4/8/8/8/8 b - - 4 20 10The piece notation used is: k/K = king, q/Q = queen, b/B = bishop, n/N = knight, r/R = rook, p/P = pawn. © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 16 Version 1.0 Document generated 2024-10-05 10:47 49 Key: B7AE661E3C37B0A7 50 Checkers: c5 Provided Libraries 574 libcsse2310a4 575 A split_by_char() function is available to break a string up into multiple parts, e.g. based on spaces. Several 576 functions that operate on Stockfish’s output are also available to simplify the parsing of this output. The 577 functions available in this library are:3226 578 char** split_by_char(char* str, char split, unsigned int maxFields); StockfishGameState* read_stockfish_d_output(FILE* stream); void free_stockfish_game_state(StockfishGameState* state); ChessMoves* read_stockfish_go_perft_1_output(FILE* stream); ChessMoves* read_stockfish_bestmove_output(FILE* stream); void free_chess_moves(ChessMoves* moves); char next_player_from_fen_string(const char* fen); These functions and the associated types are declared in /local/courses/csse2310/include/csse2310a4.h 579 on moss and their behaviour and required compiler flags are described in man pages on moss.3226 580 Testing 581 You are responsible for ensuring that your program operates according to the specification. You are encouraged 582 to test your program on a variety of scenarios. A variety of programs will be provided to help you in testing: 583 • Two demonstration programs (called demo-uqchessserver and demo-uqchessclient) that implement 584 the correct behaviour will be made available on moss. You can test your client with the demo server 585 and vice-versa. You can also use demo-uqchessserver and demo-uqchessclient to check the expected 586 behaviour of the programs if some part of this specification is unclear.3226 587 • Remember that you can use netcat (nc) to do testing also – you can use netcat as a client to communicate 588 with your server, or as a server that your client can communicate with. This will allow you to simulate 589 and capture requests and responses between the server and client.3226 590 • A test script will be provided on moss that will test your programs against a subset of the functionality 591 requirements – approximately 50% of the available functionality marks. The script will be made available 592 about 7 to 10 days before the assignment deadline and can be used to give you some confidence that you’re 593 on the right track. The “public tests” in this test script will not test all functionality and you should be 594 sure to conduct your own tests based on this specification. The “public tests” will be used in marking, 595 along with a set of “private tests” that you will not see.3226 596 • The Gradescope submission site will also be made available about 7 to 10 days prior to the assignment 597 deadline. Gradescope will run the test suite immediately after you submit. When this is complete11 you 598 will be able to see the results of the “public tests”. You should check these test results to make sure 599 your program is working as expected. Behaviour differences between moss and Gradescope may be due to 600 memory initialisation assumptions in your code, so you should allow enough time to check (and possibly 601 fix) any issues after submission.3226 602 11Gradescope marking may take only a few minutes or more than 30 minutes depending on the functionality and efficiency of your code. © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 17 Version 1.0 Document generated 2024-10-05 10:47 Style 603 Your program must follow version 3 of the CSSE2310/CSSE7231 C programming style guide available on the 604 course Blackboard site. Your submission must also comply with the Documentation required for the use of AI 605 tools if applicable. 3226 606 Hints 607 1. The multithreaded network server example from the lectures can form the basis of uqchessserver. 608 2. Review the lectures and sample code related to network clients, threads and synchronisation (semaphores), 609 and multi-threaded network servers. This assignment builds on all of these concepts. You should also 610 review the content on pipes, redirection and forking if this is not fresh in your memory. 611 3. Use the provided library functions (see above).3226 612 4. Remember to fflush() output that you printf() or fprintf() or otherwise output via FILE* streams. 613 Output to network sockets is not newline buffered. (Flushing is not necessary when using write() to 614 output directly to a file descriptor.)3226 615 5. You will need to use appropriate mutual exclusion (e.g. implemented with semaphores) in your server 616 to avoid race conditions when accessing common data structures and shared resources (e.g. the chess 617 engine). 618 6. (Read this in conjunction with the next hint.) Your server will probably need to maintain several types 619 of data structures. For example, each client thread might have an associated Client struct that records 620 details of how to communicate with the client, details of the game in progress (which might be a pointer 621 to a Game struct possibly shared between two clients, which points back to the client(s) involved so that 622 one client thread can send messages to another client). The server will also have to maintain some array 623 or list data structures, e.g. a list of all clients and a list of clients who are awaiting a human opponent 624 with a compatible colour choice. 625 7. The implementation of the server and associated data structures is much simpler when clients can only 626 play the computer and not other clients (humans) – all the game information is specific to one client 627 and not shared between multiple clients and a client thread will only ever communicate with one client. 628 You also don’t have to manage queues of clients waiting for a colour-compatible opponent. It is possible 629 to obtain 60% of the marks for the server with an implementation that only allows clients to play the 630 computer. 631 Possible Approach 632 1. Try implementing uqchessclient first. (The programs are independent so this is not a requirement, but 633 when you test it with demo-uqchessserver it may give you a better understanding of how uqchessserver 634 works.) 635 2. For uqchessserver, start with the multithreaded network server example from the lectures, gradually 636 adding functionality for supported message types and operations. 3226 637 Forbidden functions 638 You must not use any of the following C statements/directives/etc. If you do so, you will get zero (0) marks 639 for the assignment. 640 • goto 641 • #pragma3226 642 • gcc attributes (other than the possible use of __attribute__((unused)) as described in the style guide) 643 You must not use any of the following C functions. If you do so, you will get zero (0) marks for any test 644 case that calls the function. 645 © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 18 Version 1.0 Document generated 2024-10-05 10:47 • longjmp() and equivalent functions 646 • system() 647 • mkfifo() or mkfifoat() 648 • pthread_cancel() 649 • sleep(), usleep(), nanosleep() or any other function that involves a sleep, alarm or timeout. 650 • Functions described in the man page as non standard, e.g. strcasestr(). Standard functions will 651 conform to a POSIX standard – often listed in the “CONFORMING TO” section of a man page. Note 652 that getopt_long() and getopt_long_only() are an exception to this – these functions are permitted 653 if desired. 654 The use of comments to control the behaviour of clang-format and/or clang-tidy (e.g., to disable style 655 checking) will result in zero marks for automatically marked style. 656 Submission 657 Your submission must include all source and any other required files (in particular you must submit a Makefile). 658 Do not submit compiled files (eg .o, compiled programs) or test files.3226 659 Your programs (named uqchessclient and uqchessserver) must build on moss.labs.eait.uq.edu.au 660 and in the Gradescope environment with: 661 make 662 If you only implement one of the programs then it is acceptable for make to just build that program – and 663 we will only test that program. 664 Your program must be compiled with gcc with at least the following options: 665 -Wall -Wextra -pedantic -std=gnu99 666 You are not permitted to disable warnings or use pragmas to hide them. You may not use source files other 667 than .c and .h files as part of the build process – such files will be removed before building your program. 3226 668 If any errors result from the make command (e.g. an executable can not be created) then you will receive 669 zero marks for functionality (see below). Any code without academic merit will be removed from your program 670 before compilation is attempted (and if compilation fails, you will receive zero marks for functionality).3226 671 Your program must not invoke other programs or use non-standard headers/libraries (besides those we have 672 provided for you to use). 673 Your assignment submission must be committed to your Subversion repository under 674 svn+ssh://source.eait.uq.edu.au/csse2310-2024-sem2/csse2310-s4568784/trunk/a4 675 Only files at this top level will be marked so do not put source files in subdirectories. You may create 676 subdirectories for other purposes (e.g. your own test files) but these will not be considered in marking – they 677 will not be checked out of your repository.3226 678 You must ensure that all files needed to compile and use your assignment (including a Makefile) are commit- 679 ted and within the trunk/a4 directory in your repository (and not within a subdirectory) and not just sitting 680 in your working directory. Do not commit compiled files or binaries. You are strongly encouraged to check out 681 a clean copy for testing purposes. 682 To submit your assignment, you must run the command 3226 683 2310createzip a4 684 on moss and then submit the resulting zip file on Blackboard (a GradeScope submission link will be made 685 available in the Assessment area on the CSSE2310/7231 Blackboard site)12. The zip file will be named 686 s4568784_csse2310_a4_timestamp.zip 687 where timestamp is replaced by a timestamp indicating the time that the zip file was created. 688 The 2310createzip tool will check out the latest version of your assignment from the Subversion repository, 689 ensure it builds with the command ‘make’, and if so, will create a zip file that contains those files and your 690 Subversion commit history and a checksum of the zip file contents. You may be asked for your password as 691 part of this process in order to check out your submission from your repository. You will be asked to confirm 692 references in your code and also to confirm your use (or not) of AI tools to help you.3226 693 12You may need to use scp or a graphical equivalent such as WinSCP, Filezilla or Cyberduck in order to download the zip file to your local computer and then upload it to the submission site. © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 19 Version 1.0 Document generated 2024-10-05 10:47 You must not create the zip file using some other mechanism and you must not modify the zip file prior 694 to submission. If you do so, you will receive zero marks. Your submission time will be the time that the file 695 is submitted via GradeScope on Blackboard, and not the time of your last repository commit nor the time of 696 creation of your submission zip file.3226 697 Multiple submissions to Gradescope are permitted. We will mark whichever submission you choose to 698 “activate” – which by default will be your last submission, even if that is after the deadline and you made 699 submissions before the deadline. Any submissions after the deadline13 will incur a late penalty – see the 700 CSSE2310 course profile for details.3226 701 Note that Gradescope will run the test suite immediately after you submit. When complete14 you will be 702 able to see the results of the “public” tests. You should check these test results to make sure your programs are 703 working as expected. 704 Marks 705 Marks will be awarded for functionality and style and documentation. Marks may be reduced if you attend an 706 interview about your assignment and you are unable to adequately respond to questions – see the CSSE2310 Stu- 707 dent Interviews section below. 708 Functionality (60 marks for CSSE2310) 709 Provided your code compiles (see above) and does not use any prohibited statements/functions (see above), and 710 your zip file has been generated correctly and has not been modified prior to submission, then you will earn 711 functionality marks based on the number of features your program correctly implements, as outlined below. 712 Not all features are of equal difficulty. 3226 713 Partial marks will be awarded for partially meeting the functionality requirements. A number of tests will 714 be run for each marking category listed below, testing a variety of scenarios. Your mark in each category will 715 be proportional (or approximately proportional) to the number of tests passed in that category.3226 716 If your program does not allow a feature to be tested then you will receive zero marks for that 717 feature, even if you claim to have implemented it. For example, if your client can never create a connection 718 to a server then we can not determine whether it can send the correct requests or not. If your server cannot 719 establish and use a connection to the chess engine then many tests will fail. 720 Your tests must run in a reasonable time frame, which could be as short as a few seconds for usage checking 721 to many tens of seconds in some cases. If your program takes too long to respond, then it will be terminated 722 and you will earn no marks for the functionality associated with that test.3226 723 Exact text matching of output (stdout and stderr) and communication messages is used for 724 functionality marking. Strict adherence to the formats in this specification is critical to earn 725 functionality marks. 726 The markers will make no alterations to your code (other than to remove code without academic merit). 727 Note that your client and server will be tested independently. 728 Marks will be assigned in the following categories. There are 20 marks for uqchessclient and 40 marks for 729 uqchessserver. 730 1. uqchessclient correctly handles invalid command lines (2 marks) 731 2. uqchessclient connects to server and also handles inability to connect to server (2 marks) 732 3. uqchessclient correctly prints responses received from the server (1.5 marks) 733 4. uqchessclient correctly handles newgame commands (1 mark) 734 5. uqchessclient correctly handles print commands (1.5 marks) 735 6. uqchessclient correctly handles hint commands (1.5 marks) 736 7. uqchessclient correctly handles possible commands (1.5 marks) 737 8. uqchessclient correctly handles move commands, including move commands 738 with invalid arguments (2.5 marks) 739 9. uqchessclient correctly handles resign commands (1.5 marks) 740 13or your extended deadline if you are granted an extension. 14Gradescope marking may take only a few minutes or more than 30 minutes depending on the functionality and efficiency of your code. © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 20 Version 1.0 Document generated 2024-10-05 10:47 10. uqchessclient correctly handles quit commands and EOF on stdin (2 marks) 741 11. uqchessclient correctly handles invalid commands (2 marks) 742 12. uqchessclient correctly handles communication failure with server 743 (includes handling SIGPIPE when writing to the socket) (1 mark) 744 13. uqchessserver correctly handles invalid command lines3226 (2 marks) 745 14. uqchessserver establishes communication with the chess engine and handles failure to do so (2 marks) 746 15. uqchessserver correctly listens for connections and reports the port 747 (including inability to listen for connections) (2 marks) 748 16. uqchessserver correctly handles start requests, including colour matching of 749 human players, and initial move if playing computer as black. (4 marks) 750 17. uqchessserver correctly handles board requests, including in various game states3226 (3 marks) 751 18. uqchessserver correctly handles hint requests, including in various game states (4 marks) 752 19. uqchessserver correctly handles move requests when playing the computer 753 (including invalid move requests, but excluding those that result in check, 754 checkmate or stalemate) (4 marks) 755 20. uqchessserver correctly handles move requests that result in check, checkmate or stalemate 756 when playing the computer (including checking the result of subsequent requests of 757 other types to ensure games are not considered to be in progress, if applicable) (4 marks) 758 21. uqchessserver correctly handles move requests when playing a human 759 (in all scenarios, including checks described in the previous item) (5 marks) 760 22. uqchessserver correctly handles resign requests (3 marks) 761 23. uqchessserver correctly handles disconnecting clients and communication failure 762 (including not exiting due to SIGPIPE) (3 marks) 763 24. uqchessserver handles chess engine failure after startup (2 marks) 764 25. uqchessserver does not leak memory and does not busy wait3226 (2 marks) 765 Some functionality may be assessed in multiple categories. The ability to support multiple simultaneous clients 766 will be covered in multiple categories. Multiple categories will include checks that the correct number of threads 767 are created in handling clients (one additional thread per connected client). Multiple categories will test playing 768 against both humans and computers – these are categories 16 to 18 and 22 to 25. At most 16 marks total will 769 relate to playing against humans. 3226 770 Style Marking 771 Text below this point is unchanged from assignment three (other than any specification updates at the end). You should still make sure that you are familiar with all of the requirements below. 772 Style marking is based on the number of style guide violations, i.e. the number of violations of version 3 of 773 the CSSE2310/CSSE7231 C Programming Style Guide (found on Blackboard). Style marks will be made up of 774 two components – automated style marks and human style marks. These are detailed below. Your style marks 775 can never be more than your functionality mark – this prevents the submission of well styled programs which 776 don’t meet at least a minimum level of required functionality. 777 You should pay particular attention to commenting so that others can understand your code. The marker’s 778 decision with respect to commenting violations is final – it is the marker who has to understand your code. 779 You are encouraged to use the 2310reformat.sh and 2310stylecheck.sh tools installed on moss to cor- 780 rect and/or check your code style before submission. The 2310stylecheck.sh tool does not check all style 781 requirements, but it will determine your automated style mark (see below). Other elements of the style guide 782 are checked by humans. 783 All .c and .h files in your submission will be subject to style marking. This applies whether they are 784 compiled/linked into your executable or not15. 785 15Make sure you remove any unneeded files from your repository, or they will be subject to style marking. © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 21 Version 1.0 Document generated 2024-10-05 10:47 Automated Style Marking (5 marks) 786 Automated style marks will be calculated over all of your .c and .h files as follows. If any of your submitted 787 .c and/or .h files are unable to be compiled by themselves then your automated style mark will be zero (0). If 788 your code uses comments to control the behaviour of clang-format and/or clang-tidy then your automated 789 style mark will be zero. If any of your source files contain C functions longer than 100 lines of code16 then your 790 automated and human style marks will both be zero. If you use any global variables then your automated and 791 human style marks will both be zero. 792 If your code does compile and does not contain any C functions longer than 100 lines and does not use any 793 global variables and does not interfere with the expected behaviour of clang-format and/or clang-tidy then 794 your automated style mark will be determined as follows: Let 795 • W be the total number of distinct compilation warnings recorded when your .c files are individually built 796 (using the correct compiler arguments) 797 • A be the total number of style violations detected by 2310stylecheck.sh when it is run over each of your 798 .c and .h files individually17. 799 Your automated style mark S will be 800 S = 5− (W +A) 801 If W +A ≥ 5 then S will be zero (0) – no negative marks will be awarded. If you believe that 802 2310stylecheck.sh is behaving incorrectly or inconsistently then please bring this to the attention of the 803 course coordinator prior to submission, e.g., it is possible the style checker may report different issues on moss 804 than it does in the Gradescope environment. Your automated style mark can be updated if this is deemed to 805 be appropriate. You can check the result of Gradescope style marking soon after your Gradescope submission 806 – when the test suite completes running. 807 Human Style Marking (5 marks) 808 The human style mark (out of 5 marks) will be based on the criteria/standards below for “comments”, “naming” 809 and “modularity”. Note that if your code contains any functions longer than 100 lines or uses a global variable 810 then your human style mark is zero and the criteria/standards below are not relevant. 811 The meanings of words like appropriate and required are determined by the requirements in the style guide. 812 Comments (3 marks) 813 Mark Description 0 25% or more of the comments that are present are inappropriate AND/OR at least 50% of therequired comments are missing 1 At least 50% of the required comments are present AND the vast majority (75%+) of commentspresent are appropriate AND the requirements for a higher mark are not met 2 All or almost all required comments are present AND all or almost all comments present are appro-priate AND the requirements for a mark of 3 are not met 3 All required comments are present AND all comments present are appropriate AND additionalcomments are present as appropriate to ensure clarity 814 Naming (1 mark) 815 Mark Description 0 At least a few names used are inappropriate 0.5 Almost all names used are appropriate 1 All names used are appropriate 816 16Note that the style guide requires functions to be 50 lines of code or fewer. Code that contains functions whose length is 51 to 100 lines will be penalised somewhat – one style violation (i.e. one mark) per function. Code that contains functions longer than 100 lines will be penalised very heavily – no marks will be awarded for human style or automatically marked style. 17Every .h file in your submission must make sense without reference to any other files, e.g., it must #include any .h files that contain declarations or definitions used in that .h file. You can check that a header file compiles by itself by running gcc -c filename.h – with any other gcc arguments as required. © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 22 Version 1.0 Document generated 2024-10-05 10:47 Modularity (1 mark) 817 Mark Description 0 There are two or more instances of poor modularity (e.g. repeated code blocks) 0.5 There is one instance of poor modularity (e.g. a block of code repeated once) 1 There are no instances of poor modularity 818 SVN Commit History Marking (5 marks) 819 Markers will review your SVN commit history for your assignment up to your zip file creation time. This 820 element will be graded according to the following principles: 821 • Appropriate use and frequency of commits (e.g. a single monolithic commit of your entire assignment will 822 yield a score of zero for this section). Progressive development is expected, i.e., no large commits with 823 multiple features in them. 824 • Appropriate use of log messages to capture the changes represented by each commit. (Meaningful messages 825 explain briefly what has changed in the commit (e.g. in terms of functionality, not in terms of specific 826 numbered test cases in the test suite) and/or why the change has been made and will be usually be more 827 detailed for significant changes.). 828 The standards expected are outlined in the following rubric. The mark awarded will be the highest for which 829 the relevant standard is met. 830 Mark (out of 5) Description 0 Minimal commit history – only one or two commits ORall commit messages are meaningless. 1 Some progressive development evident (three or more commits) ANDat least one commit message is meaningful. 2 Progressive development is evident (multiple commits) ANDat least half the commit messages are meaningful 3 Multiple commits that show progressive development of almost all or all functionality ANDat least two-thirds of the commit messages are meaningful. 4 Multiple commits that show progressive development of ALL functionality ANDmeaningful messages for all but one or two of the commits. 5 Multiple commits that show progressive development of ALL functionality ANDmeaningful messages for ALL commits. 831 Total Mark 832 Let 833 • F be the functionality mark for your assignment (out of 60 for CSSE2310 students). 834 • S be the automated style mark for your assignment (out of 5). 835 • H be the human style mark for your assignment (out of 5). 836 • C be the SVN commit history mark (out of 5). 837 • V be the scaling factor (0 to 1) determined after interview (if applicable – see the CSSE2310 Student 838 Interviews section below) – or 0 if you fail to attend a scheduled interview without having evidence of 839 exceptional circumstances impacting your ability to attend. 840 Your total mark for the assignment will be: 841 M = (F + min{F, S +H} + min{F,C})× V 842 out of 75 (for CSSE2310 students) 843 In other words, you can’t get more marks for style or SVN commit history than you do for functionality. 844 Pretty code that doesn’t work will not be rewarded! 845 © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 23 Version 1.0 Document generated 2024-10-05 10:47 Late Penalties 846 Late penalties will apply as outlined in the course profile. 847 CSSE2310 Student Interviews 848 This section is unchanged from assignments one and three. 849 The teaching staff will conduct interviews with a subset of CSSE2310 students about their sub- 850 missions, for the purposes of establishing genuine authorship. If you write your own code, you have nothing 851 to fear from this process. If you legitimately use code from other sources (following the usage/referencing 852 requirements outlined in this assignment, the style guide, and the AI tool use documentation requirements) 853 then you are expected to understand that code. If you are not able to adequately explain the design of your 854 solution and/or adequately explain your submitted code (and/or earlier versions in your repository) and/or be 855 able to make simple modifications to it as requested at the interview, then your assignment mark will be scaled 856 down based on the level of understanding you are able to demonstrate and/or your submission may be subject 857 to a misconduct investigation where your interview responses form part of the evidence. Failure to attend 858 a scheduled interview will result in zero marks for the assignment unless there are documented exceptional 859 circumstances that prevent you from attending. 860 Students will be selected for interview based on a number of factors that may include (but are not limited 861 to): 862 • Feedback from course staff based on observations in class, on the discussion forum, and during marking; 863 • An unusual commit history (versions and/or messages), e.g. limited evidence of progressive development; 864 • Variation of student performance, code style, etc. over time; 865 • Use of unusual or uncommon code structure/functions etc.; 866 • Referencing, or lack of referencing, present in code; 867 • Use of, or suspicion of undocumented use of, artificial intelligence or other code generation tools; and 868 • Reports from students or others about student work. 869 Specification Updates 870 Any errors or omissions discovered in the assignment specification will be added here, and new versions released 871 with adequate time for students to respond prior to due date.3226 Potential specification errors or omissions can be 872 discussed on the discussion forum. 873 © 2024 The University of Queensland Document created for Jiaxiang LIANG (s4568784) only. 24 Version 1.0 Document generated 2024-10-05 10:47 51作业君版权所有