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