Interested in a PLAGIARISM-FREE paper based on these particular instructions?...with 100% confidentiality?

Order Now

School of Information Technology and Electrical Engineering Semester Two, 2017 CSSE2310 / CSSE7231 – Assignment 4 Due: 11:10pm 27th October, 2017 Marks: 50 Weighting: 25% of your overall assignment mark (CSSE2310) Revision 4.2 Introduction In this assignment, you will write C99 programs (described below) to run and play the game from Assignment 3 using client server networking. This assignment will use pthreads not fork(). Your programs must not create any files on disk not mentioned in this specification or in command line arguments. Your assignment submission must comply with the C style guide (version 2.0.4) available on the course blackboard area. This is an individual assignment. You should feel free to discuss aspects of C programming and the assignment specification with fellow students. You should not actively help (or seek help from) other students with the actual coding of your assignment solution. It is cheating to look at another student’s code and it is cheating to allow your code to be seen or shared in printed or electronic form. You should note that all submitted code may be subject to automated checks for plagiarism and collusion. If we detect plagiarism or collusion, formal misconduct proceedings will be initiated against you. A likely penalty for a first offence would be a mark of 0 for the assignment. Don’t risk it! If you’re having trouble, seek help from a member of the teaching staff. Don’t be tempted to copy another student’s code. You should read and understand the statements on student misconduct in the course profile and on the school web-site: http://www.itee.uq.edu.au/itee-student-misconduct-including-plagiarism As with Assignment 1, we will use the subversion (svn) system to deal with assignment submissions. Do not commit any code to your repository unless it is your own work or it was given to you by teaching staff. If you have questions about this, please ask. You are permitted to use sample code supplied by teaching staff this year in this course. Code supplied for other courses or other offerings of this course is off limits — it may be deemed to be without academic merit and removed from your program before testing. The game The game being played is the same as with Assignment 3. The initial distribution of loot and players will be as specified in Assignment 3. Note that the communication protocol has had some changes. You will be provided with library code and associated headers to deal with game logic. Use of this library code is compulsory. Programs This assignment consists of the following programs: • train-job — The server program which players will connect to (takes the same coordination role that the hub had in Assignment 3). • train-scores — A client program which connects to the server and displays score table information. • train-mal — A client program which interacts with the user to determine which actions should be taken on each turn. 3422256-29492-35515391 Prepared for s4406318. Do not distribute. • train-jayne — A client which plays using the “spoiler” behaviour rules from Assignment 3. Invocation – train-job The server will require clients connecting to it to supply a pass-char. This character will be read from a file specified as a commandline parameter. The parameters to start the server are (in order): • keyfile — read the first character and use as the pass-char for player connections. • seed — seed for all games. • timeout — number of seconds to wait for a reconnect if a player disconnects early. If this is zero, then do not wait at all. • port — port to listen on. If this is given as ’-’, then let the OS choose a port. • additional ports — listen for clıent connections as well. For example: ./train-job mykey 55 2 – – Would have the server listen on two ports of the OS’s chosing. Invocation – train-scores • keyfile — read the first character and use it as the pass-char. • port — port to connect to. For example: ./train-score mykey 9001 Invocation – train-jayne/train-mal client keyfile port player_name game_name OR client keyfile port reconnect reconn_id • keyfile – file to read the pass-char from • port — port to connect to • player name — Name to be used to describe this player in text output (in messages, the letters used in Assignment 3 will still be used). • game name — Name of game to connect to • “reconnect” — If this parameter is supplied, the player should attempt to reconnect to a previous game. 3422256-29492-35515392 Prepared for s4406318. Do not distribute. • reconn id — an integer used to reconnect the player with the correct game. There is no restriction on multiple players connecting and using the same name (even in the same game). The game name parameter, will be used to place players in games. Names will take the form: %u-%u-%s Where the first value is the number of players in the game. The second value is the number of carriages in the game. The string can be any sequence of letters and numbers. When the server has filled a game with the required number of players, it will start that game. If additional players ask to join a game of the same name, a new game with the same parameters will be created. Score table behaviour The train-scores client will connect to the specified port, send %cscore\n where %c is the pass-char. It will then output whatever the server sends until the server disconnects. The server will maintain a score table and output it in lexicographic order by player name. This table is to be updated each time the server executes an action for any player in any game and when a game completes. For cases where the action requires additional information from a player, this means once the player has replied with acceptable information. Each row consists of the following information (comma separated). • player name • games won • total loot gathered (loot which is dropped later still counts) • total hits received • hits given • hits missed (ie long with no target). Player connection behaviour When a player connects, they should first send %cplay\n where %c is the pass-char. It will then wait for the server to reply with yes (in which case they continue) or no (in which case they disconnect). Next the player will send their player name and game name (single newline separated). Then wait for the servers approval (disconnect on no). When the game is full, the server will send game information to all players followed by a round message. The game information will contain the following: reconn_id width,player_count,your_id player0_name player0_loot,player0_hits player1_name player1_loot,player1_hits … carriage0_lower_loot,carriage0_upper_loot … Where 3422256-29492-35515393 Prepared for s4406318. Do not distribute. • reconn id is an integer used for possible reconnection to this game (if you have not implemented this functionality yet, this can be 1). • width, player count, your id same information as in Assignment 3. • the next block of rows describe the name and stats for each player • the remaining rows (one for each carriage) list the amount of loot on each level of the carriage. New messages This assignment adds two new messages to the normal flow: yes and no. As well as being used as a response to the the pass char and the names on connection, they are now also used in the execute phase. When a player sends a response to a server’s question, the server will respond with yes if the response is acceptable and with no. If no is sent, the client is expected to provide another response. (This will continue until the clıent provides an acceptable response). There are also two more end of game messages. disco%c — is sent to all (connected) players in a game if the game is being ended because a player disconnected (and did not reconnect). badmsg%c — is sent to all players in a game if the game is being ended because one of the players sent an illegal message. In this Assignment, only messages which are badly formatted qualify here. Non-existant players, moving off the edge etc can be dealt with via no. In both of these, the character indicates which player disconnected or sent the bad message. Reconnection If a single player in a game disconnects when input is still expected from them, the server will give them time to reconnect. Clients doing this will send: recon instead of play on the first line. If the server sends yes, then they will send their reconn id. If the ID is incorrect, the server will send no and will close the connection, otherwise it will send yes. The server will then send game information followed by: round or execute. Following this, the server will re-pose the question it expected an answer to. If the time limit is reached, the game is ended early with a gameover message. The winners will be determined based on the scores at the time. If a reconnection attempt is made while the server believes the player is still connected, the server should treat the attempt as an invalid reconn id. Server output When the server starts up and has succeeded in listening on the required ports, it should print the ports it is using (in commandline order) separated by newlines. The server will produce no other output to stdout. The server will produce the following messages to stderr (with associated exit statii). 3 422256-29492-35515394 Prepared for s4406318. Do not distribute. Condition stderr status Incorrect number of arguments Usage: train-job keyfile seed timeout port {port} 1 Can’t get valid pass-char Can’t get pass-char 2 Invalid seed (unsigned int) Bad seed 3 Invalid timeout (unsigned int) Bad timeout 4 Numerically invalid port Bad port 5 Couldn’t listen on port Failed listen 6 Output — players The following applies to both player types Both When the player recieves game information (and at the end of each round), will print a game summary to stdout: A: playername: $=?,h=? B: playername: $=?,h=? … Carriage 0: $=?,$=? Carriage 1: $=?,$=? … At the end of the game, output the winner(s): Winner(s): followed by a comma separated list of winners names (in lexicographic order). The following exit messages are sent to stderr. Condition stderr status Game over / Normal exit 0 incorrect number of args Incorrect number of args 1 Can’t get valid pass-char Bad get passchar 2 Can’t connect Connect failed 3 Can’t Authenticate Auth failed 4 Name or Game rejected Not allowed 5 Reconnect failed Bad reconnect 6 Server disconnected Server disconnect 7 Other client disconnected Client disconnected 8 Communication error (server sent you a bad message) Coms error 9 Communication error by other client Client coms error 10 3 422256-29492-35515395 Prepared for s4406318. Do not distribute. The exits above the blank line also apply to the scores client. Output — train-jayne This client will not produce any additional output. If this player has any of its moves rejected with no, it should treat that as a communication error. Output — train-mal Message Response ordered ? Ordered ? (Fill in with player name and h,v,s,l,$) hmove and vmove ? moved to X/Y (Fill in with player name) looted ? looted OR ? failed to loot short ? shorted ? OR ? missed long ? long ? OR ? missed driedout ? dried out For the following messages, display the prompt and wait for one of the permitted responses. Once a response is given, send the relevant reponse message to the server. If the server responds with no, then reprompt. For target and movement direction selection, even if the option is not legal, send it to the server and let the server reject it. Message Prompt Valid responses yourturn move: h,v,l,s,$ h? hmove: l,r (for left and right) s?/l? target: player letter Compilation Your code must compile (on a clean checkout) with the command: make Each individual file must compile with at least -Wall -pedantic -std=gnu99. You may of course use additional flags but you must not use them to try to disable or hide warnings. You must also not use pragmas to achieve the same goal. Your code must be compiled with the gcc compiler. If the make command does not produce one or more of the required programs, then those programs will not be marked. If none of the required programs are produced, then you will receive 0 marks for functionality. Any code without academic merit will be removed from your program before compilation is attempted [This will be done even if it prevents the code from compiling]. If your code produces warnings (as opposed to errors), then you will lose style marks (see later). Your solution must not invoke other programs. Your solution must not use non-standard or non-provided headers/libraries. 3422256-29492-35515396 Prepared for s4406318. Do not distribute. Submission Submission must be made electronically by committing using subversion. In order to mark your assignment, the markers will check out /trunk/ass4/ from your repository on source.eait.uq.edu.au 1. Code checked in to any other part of your repository will not be marked. The due date for this assignment is given on the front page of this specification. (Only the contents of the trunk/ass4 directory at the deadline will be marked). Test scripts will be provided to test the code on the trunk. Students are strongly advised to make use of this facility after committing. Note: Any .h or .c files in your trunk/ass4 directory will be marked for style even if they are not linked by the makefile. If you need help moving/removing files in svn, then ask. Consult the style guide for other restrictions. You must submit a Makefile or we will not be able to compile your assignment. Remember that your assignment will be marked electronically and strict adherance to the specification is critical. Marks Marks will be awarded for both functionality and style. Functionality (44 marks) Provided that your code compiles (see above), you will earn functionality marks based on the number of features your program correctly implements, as outlined below. Partial marks may be awarded for partially meeting the functionality requirements. Not all features are of equal difficulty. If your program does not allow a feature to be tested then you will receive 0 marks for that feature, even if you claim to have implemented it. For example, if your program can never open a file, we can not determine if your program would have loaded input from it. The markers will make no alterations to your code (other than to remove code without academic merit). Your programs should not crash or lock up/loop indefinitely. Your programs should not run for unreasonably long times. • For train-scores client – Argument checking (1 mark) – Correctly report score table (1 mark) • train-jayne – Argument checking (1 mark) – Correctly handle connection sequence (1 mark) – Play games (4 marks) • train-mal – Argument checking (1 mark) – Play games (5 marks) • train-job (server) – Argument checking (1 mark) 1That is, https://source.eait.uq.edu.au/svn/csse2310-$USER/trunk/ass3 3 422256-29492-35515397 Prepared for s4406318. Do not distribute. – Play single game (6 marks) – Play multiple games on single port (5 marks) – Play multiple games on multiple ports (4 marks) – Working scores support for the above (6 marks) • Restart support (clients and server) (4 marks) • No server memory leaks (4* marks) The marks for no server memory leaks will only be awarded if the submission has at least 3 marks in the “Play single game” catgeory and none of the leak tests fail. Style (6 marks) Style marks will be calculated as follows: Let A be the number of style violations detected by simpatico plus the number of build warnings. Let H be the number of style violations detected by human markers. Let F be the functionality mark for your assignment. • If A > 10, then your style mark will be zero and M will not be calculated. • Otherwise, let MA = 3 × 0.8A and MH = MA − 0.5 × H your style mark S will be MA + max{0,MH}. Your total mark for the assignment will be F + min{F, S}. Late Penalties Late penalties will apply as outlined in the course profile. Specification Updates It is possible that this specification contains errors or inconsistencies or missing information. It is possible that clarifications will be issued via the course website. Any such clarifications posted 5 days (120 hours) or more before the due date will form part of the assignment specification. If you find any inconsistencies or omissions, please notify the teaching staff. Test Data Test data and scripts for this assignment will be made available. (testa4.sh, reptesta4.sh) The idea is to help clarify some areas of the specification and to provide a basic sanity check of code which you have committed. They are not guaranteed to check all possible problems nor are they guaranteed to resemble the tests which will be used to mark your assignments. Testing that your assignment complies with this specification is still your responsibility. Notes and Addenda: 1. Start early. 2. Write simple programs to try out pthread and threadsafety functions. 3422256-29492-35515398 Prepared for s4406318. Do not distribute. 3. Be sure to test on moss. 4. You should not assume that system calls always succeed. 5. You are not permitted to use any of the following functions in this assignment. • system(), fork(), popen(), prctl(), setjmp() 6. You may not use any #pragma in this assignment. 7. No program should assume that any other will be well behaved. That is, if the server sends a valid message, you may believe it. However, if any component sends an invalid message, no other component should crash. 8. You will need to do something with SIGPIPE. 9. Valid messages contain no leading, trailing or embedded spaces. Messages must be exactly the correct length. 10. structs and enums are your friends use them. 11. All components detect the loss of other components by read failure. Write failures will be silently ignored. 12. valgrind may be helpful in checking memory leaks. 3422256-29492-35515399

School of Information Technology and Electrical Engineering
Semester Two, 2017
CSSE2310 / CSSE7231 – Assignment 4
Due: 11:10pm 27th October, 2017
Marks: 50
Weighting: 25% of your overall assignment mark (CSSE2310)
Revision 4.2
Introduction
In this assignment, you will write C99 programs (described below) to run and play the game from Assignment 3
using client server networking. This assignment will use pthreads not fork().
Your programs must not create any files on disk not mentioned in this specification or in command line
arguments. Your assignment submission must comply with the C style guide (version 2.0.4) available on the
course blackboard area. This is an individual assignment. You should feel free to discuss aspects of C programming
and the assignment specification with fellow students. You should not actively help (or seek help
from) other students with the actual coding of your assignment solution. It is cheating to look at another
student’s code and it is cheating to allow your code to be seen or shared in printed or electronic form. You
should note that all submitted code may be subject to automated checks for plagiarism and collusion. If we
detect plagiarism or collusion, formal misconduct proceedings will be initiated against you. A likely penalty
for a first offence would be a mark of 0 for the assignment. Don’t risk it! If you’re having trouble, seek
help from a member of the teaching staff. Don’t be tempted to copy another student’s code. You should
read and understand the statements on student misconduct in the course profile and on the school web-site:
http://www.itee.uq.edu.au/itee-student-misconduct-including-plagiarism
As with Assignment 1, we will use the subversion (svn) system to deal with assignment submissions. Do not
commit any code to your repository unless it is your own work or it was given to you by teaching staff. If you
have questions about this, please ask.
You are permitted to use sample code supplied by teaching staff this year in this course. Code
supplied for other courses or other offerings of this course is off limits — it may be deemed to
be without academic merit and removed from your program before testing.
The game
The game being played is the same as with Assignment 3. The initial distribution of loot and players will be as
specified in Assignment 3. Note that the communication protocol has had some changes. You will be provided
with library code and associated headers to deal with game logic. Use of this library code is compulsory.
Programs
This assignment consists of the following programs:
• train-job — The server program which players will connect to (takes the same coordination role that the
hub had in Assignment 3).
• train-scores — A client program which connects to the server and displays score table information.
• train-mal — A client program which interacts with the user to determine which actions should be taken
on each turn.
3422256-29492-35515391
Prepared for s4406318. Do not distribute.
• train-jayne — A client which plays using the “spoiler” behaviour rules from Assignment 3.
Invocation – train-job
The server will require clients connecting to it to supply a pass-char. This character will be read from a file
specified as a commandline parameter.
The parameters to start the server are (in order):
• keyfile — read the first character and use as the pass-char for player connections.
• seed — seed for all games.
• timeout — number of seconds to wait for a reconnect if a player disconnects early. If this is zero, then do
not wait at all.
• port — port to listen on. If this is given as ’-’, then let the OS choose a port.
• additional ports — listen for clıent connections as well.
For example:
./train-job mykey 55 2 – –
Would have the server listen on two ports of the OS’s chosing.
Invocation – train-scores
• keyfile — read the first character and use it as the pass-char.
• port — port to connect to.
For example:
./train-score mykey 9001
Invocation – train-jayne/train-mal
client keyfile port player_name game_name
OR
client keyfile port reconnect reconn_id
• keyfile – file to read the pass-char from
• port — port to connect to
• player name — Name to be used to describe this player in text output (in messages, the letters used in
Assignment 3 will still be used).
• game name — Name of game to connect to
• “reconnect” — If this parameter is supplied, the player should attempt to reconnect to a previous game.
3422256-29492-35515392
Prepared for s4406318. Do not distribute.
• reconn id — an integer used to reconnect the player with the correct game.
There is no restriction on multiple players connecting and using the same name (even in the same game).
The game name parameter, will be used to place players in games. Names will take the form: %u-%u-%s
Where the first value is the number of players in the game. The second value is the number of carriages in the
game. The string can be any sequence of letters and numbers.
When the server has filled a game with the required number of players, it will start that game. If additional
players ask to join a game of the same name, a new game with the same parameters will be created.
Score table behaviour
The train-scores client will connect to the specified port, send %cscore\n where %c is the pass-char. It will
then output whatever the server sends until the server disconnects.
The server will maintain a score table and output it in lexicographic order by player name. This table is to
be updated each time the server executes an action for any player in any game and when a game completes.
For cases where the action requires additional information from a player, this means once the player has replied
with acceptable information. Each row consists of the following information (comma separated).
• player name
• games won
• total loot gathered (loot which is dropped later still counts)
• total hits received
• hits given
• hits missed (ie long with no target).
Player connection behaviour
When a player connects, they should first send %cplay\n where %c is the pass-char. It will then wait for the
server to reply with yes (in which case they continue) or no (in which case they disconnect).
Next the player will send their player name and game name (single newline separated). Then wait for the
servers approval (disconnect on no).
When the game is full, the server will send game information to all players followed by a round message.
The game information will contain the following:
reconn_id
width,player_count,your_id
player0_name
player0_loot,player0_hits
player1_name
player1_loot,player1_hits

carriage0_lower_loot,carriage0_upper_loot

Where
3422256-29492-35515393
Prepared for s4406318. Do not distribute.
• reconn id is an integer used for possible reconnection to this game (if you have not implemented this
functionality yet, this can be 1).
• width, player count, your id same information as in Assignment 3.
• the next block of rows describe the name and stats for each player
• the remaining rows (one for each carriage) list the amount of loot on each level of the carriage.
New messages
This assignment adds two new messages to the normal flow: yes and no. As well as being used as a response
to the the pass char and the names on connection, they are now also used in the execute phase. When a player
sends a response to a server’s question, the server will respond with yes if the response is acceptable and with
no. If no is sent, the client is expected to provide another response. (This will continue until the clıent provides
an acceptable response).
There are also two more end of game messages. disco%c — is sent to all (connected) players in a game if the
game is being ended because a player disconnected (and did not reconnect). badmsg%c — is sent to all players
in a game if the game is being ended because one of the players sent an illegal message. In this Assignment,
only messages which are badly formatted qualify here. Non-existant players, moving off the edge etc can be
dealt with via no. In both of these, the character indicates which player disconnected or sent the bad message.
Reconnection
If a single player in a game disconnects when input is still expected from them, the server will give them time to
reconnect. Clients doing this will send: recon instead of play on the first line. If the server sends yes, then they
will send their reconn id. If the ID is incorrect, the server will send no and will close the connection, otherwise
it will send yes. The server will then send game information followed by: round or execute. Following this,
the server will re-pose the question it expected an answer to.
If the time limit is reached, the game is ended early with a gameover message. The winners will be determined
based on the scores at the time.
If a reconnection attempt is made while the server believes the player is still connected, the server should
treat the attempt as an invalid reconn id.
Server output
When the server starts up and has succeeded in listening on the required ports, it should print the ports it is
using (in commandline order) separated by newlines. The server will produce no other output to stdout.
The server will produce the following messages to stderr (with associated exit statii).
3 422256-29492-35515394
Prepared for s4406318. Do not distribute.
Condition stderr status
Incorrect number of
arguments
Usage: train-job keyfile seed timeout port {port} 1
Can’t get valid
pass-char
Can’t get pass-char 2
Invalid seed
(unsigned int)
Bad seed 3
Invalid timeout
(unsigned int)
Bad timeout 4
Numerically invalid
port
Bad port 5
Couldn’t listen on
port
Failed listen 6
Output — players
The following applies to both player types
Both
When the player recieves game information (and at the end of each round), will print a game summary to
stdout:
A: playername: $=?,h=?
B: playername: $=?,h=?

Carriage 0: $=?,$=?
Carriage 1: $=?,$=?

At the end of the game, output the winner(s):
Winner(s):
followed by a comma separated list of winners names (in lexicographic order).
The following exit messages are sent to stderr.
Condition stderr status
Game over / Normal exit 0
incorrect number of args Incorrect number of args 1
Can’t get valid pass-char Bad get passchar 2
Can’t connect Connect failed 3
Can’t Authenticate Auth failed 4
Name or Game rejected Not allowed 5
Reconnect failed Bad reconnect 6
Server disconnected Server disconnect 7
Other client disconnected Client disconnected 8
Communication error (server
sent you a bad message)
Coms error 9
Communication error by other
client
Client coms error 10
3 422256-29492-35515395
Prepared for s4406318. Do not distribute.
The exits above the blank line also apply to the scores client.
Output — train-jayne
This client will not produce any additional output. If this player has any of its moves rejected with no, it should
treat that as a communication error.
Output — train-mal
Message Response
ordered ? Ordered ? (Fill in with player name
and h,v,s,l,$)
hmove and vmove ? moved to X/Y (Fill in with player
name)
looted ? looted OR ? failed to loot
short ? shorted ? OR ? missed
long ? long ? OR ? missed
driedout ? dried out
For the following messages, display the prompt and wait for one of the permitted responses. Once a response
is given, send the relevant reponse message to the server. If the server responds with no, then reprompt. For
target and movement direction selection, even if the option is not legal, send it to the server and let the server
reject it.
Message Prompt Valid responses
yourturn move: h,v,l,s,$
h? hmove: l,r (for left and right)
s?/l? target: player letter
Compilation
Your code must compile (on a clean checkout) with the command:
make
Each individual file must compile with at least -Wall -pedantic -std=gnu99. You may of course use
additional flags but you must not use them to try to disable or hide warnings. You must also not use pragmas
to achieve the same goal. Your code must be compiled with the gcc compiler.
If the make command does not produce one or more of the required programs, then those programs will not
be marked. If none of the required programs are produced, then you will receive 0 marks for functionality. Any
code without academic merit will be removed from your program before compilation is attempted [This will be
done even if it prevents the code from compiling]. If your code produces warnings (as opposed to errors), then
you will lose style marks (see later).
Your solution must not invoke other programs. Your solution must not use non-standard or non-provided
headers/libraries.
3422256-29492-35515396
Prepared for s4406318. Do not distribute.
Submission
Submission must be made electronically by committing using subversion. In order to mark your assignment,
the markers will check out /trunk/ass4/ from your repository on source.eait.uq.edu.au 1. Code checked
in to any other part of your repository will not be marked.
The due date for this assignment is given on the front page of this specification. (Only the contents of the
trunk/ass4 directory at the deadline will be marked).
Test scripts will be provided to test the code on the trunk. Students are strongly advised to make use of this
facility after committing.
Note: Any .h or .c files in your trunk/ass4 directory will be marked for style even if they are not linked
by the makefile. If you need help moving/removing files in svn, then ask. Consult the style guide for other
restrictions.
You must submit a Makefile or we will not be able to compile your assignment. Remember that your
assignment will be marked electronically and strict adherance to the specification is critical.
Marks
Marks will be awarded for both functionality and style.
Functionality (44 marks)
Provided that your code compiles (see above), you will earn functionality marks based on the number of features
your program correctly implements, as outlined below. Partial marks may be awarded for partially meeting the
functionality requirements. Not all features are of equal difficulty. If your program does not allow a feature to
be tested then you will receive 0 marks for that feature, even if you claim to have implemented it. For example,
if your program can never open a file, we can not determine if your program would have loaded input from it.
The markers will make no alterations to your code (other than to remove code without academic merit). Your
programs should not crash or lock up/loop indefinitely. Your programs should not run for unreasonably long
times.
• For train-scores client
– Argument checking (1 mark)
– Correctly report score table (1 mark)
• train-jayne
– Argument checking (1 mark)
– Correctly handle connection sequence (1 mark)
– Play games (4 marks)
• train-mal
– Argument checking (1 mark)
– Play games (5 marks)
• train-job (server)
– Argument checking (1 mark)
1That is, https://source.eait.uq.edu.au/svn/csse2310-$USER/trunk/ass3
3 422256-29492-35515397
Prepared for s4406318. Do not distribute.
– Play single game (6 marks)
– Play multiple games on single port (5 marks)
– Play multiple games on multiple ports (4 marks)
– Working scores support for the above (6 marks)
• Restart support (clients and server) (4 marks)
• No server memory leaks (4* marks)
The marks for no server memory leaks will only be awarded if the submission has at least 3 marks in the
“Play single game” catgeory and none of the leak tests fail.
Style (6 marks)
Style marks will be calculated as follows:
Let A be the number of style violations detected by simpatico plus the number of build warnings. Let H be the
number of style violations detected by human markers. Let F be the functionality mark for your assignment.
• If A > 10, then your style mark will be zero and M will not be calculated.
• Otherwise, let MA = 3 × 0.8A and MH = MA − 0.5 × H your style mark S will be MA + max{0,MH}.
Your total mark for the assignment will be F + min{F, S}.
Late Penalties
Late penalties will apply as outlined in the course profile.
Specification Updates
It is possible that this specification contains errors or inconsistencies or missing information. It is possible that
clarifications will be issued via the course website. Any such clarifications posted 5 days (120 hours) or more
before the due date will form part of the assignment specification. If you find any inconsistencies or omissions,
please notify the teaching staff.
Test Data
Test data and scripts for this assignment will be made available. (testa4.sh, reptesta4.sh) The idea is to help
clarify some areas of the specification and to provide a basic sanity check of code which you have committed.
They are not guaranteed to check all possible problems nor are they guaranteed to resemble the tests which will
be used to mark your assignments. Testing that your assignment complies with this specification is still your
responsibility.
Notes and Addenda:
1. Start early.
2. Write simple programs to try out pthread and threadsafety functions.
3422256-29492-35515398
Prepared for s4406318. Do not distribute.
3. Be sure to test on moss.
4. You should not assume that system calls always succeed.
5. You are not permitted to use any of the following functions in this assignment.
• system(), fork(), popen(), prctl(), setjmp()
6. You may not use any #pragma in this assignment.
7. No program should assume that any other will be well behaved. That is, if the server sends a valid
message, you may believe it. However, if any component sends an invalid message, no other component
should crash.
8. You will need to do something with SIGPIPE.
9. Valid messages contain no leading, trailing or embedded spaces. Messages must be exactly the correct
length.
10. structs and enums are your friends use them.
11. All components detect the loss of other components by read failure. Write failures will be silently ignored.
12. valgrind may be helpful in checking memory leaks.
3422256-29492-35515399

Interested in a PLAGIARISM-FREE paper based on these particular instructions?...with 100% confidentiality?

Order Now