COMP2017 9017 Assignment 2
Due: 23:59 20 May 2025
This assignment is worth 10% of your final assessment
This assessment is CONFIDENTIAL. © University of Sydney
Contents
1 Assignment 2 - [ZOIT Docs] - 10% 3
2 Introduction 5
3 Task 5
4 Set-up 6
5 Structure 8
6 Client-Server Synchronisation 10
7 Functionality 10
7.1 Part 1: Single Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1.1 Ordered List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2 Part 2: Multiple Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.3 COMP9017 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.4 Rejections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8 Tear Down 17
9 Marking 17
9.1 Markdown Unit Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2 Staff Client-Server Interoperability Tests . . . . . . . . . . . . . . . . . . . . . 18
10 Short Answer Questions 18
1
COMP2017 9017
11 Restrictions 18
Systems Programming Page 2 of 19
COMP2017 9017
1 Assignment 2 - [ZOIT Docs] - 10%
We strongly recommend reading this entire document at least twice. You are encouraged
to ask questions on Ed after you have first searched, and checked for updates of this document.
If the question has not been asked before, make sure your question post is of type "Question"
and is under "Assignment" category→ "P2" . Please follow the staff directions for using the
question template.
Note, your Git commit messages matter. Make sure you enter informative information into
your commit messages as per the accompanying Edstem slide. Also, use .gitignore to
avoid committing garbage files. There is a guide to both on the accompanying Ed slide titled
Git Usage Guideline, with a required formatting guide you must follow.
It is important that you continually back up your assignment files onto your own machine, flash
drives, external hard drives and cloud storage providers (as private). You are encouraged to
submit your assignment regularly while you are in the process of completing it.
Full reproduction steps (seed, description of what you tried) MUST be given if you are enquir-
ing about a test failure or if you believe there is a bug in the marking script.
Academic Integrity and Compliance Statement
This assignment will be submitted in Ed Lessons, under Assignments - P2.
In addition to the Academic Integrity and Compliance statements below, an Academic Decla-
ration appears in your assignment in Ed. All statements apply.
Academic Integrity
While the University is aware that the vast majority of students and staff act ethically and
honestly, it is opposed to and will not tolerate academic integrity breaches and will treat all
allegations seriously.
Further information on academic integrity, and the resources available to all students can be
found on the academic integrity pages on the current students website:
https://sydney.edu.au/students/academic-integrity.html
You may only use generative artificial intelligence (AI) and automated writing tools in assess-
ment tasks if you are permitted to by your unit coordinator. If you do use these tools, you
must acknowledge this in your work, either in a footnote or an acknowledgement section. For
information on acknowledging AI please refer to the guidance in the AI in Education Canvas
site.
We use Turnitin, which includes AI detection, to detect potential instances of plagiarism or
other forms of academic integrity breach. If such matches indicate evidence of plagiarism or
other forms of academic integrity breaches, your teacher is required to report your work for
further investigation.
Further information on research integrity and ethics for postgraduate research students and stu-
Systems Programming Page 3 of 19
COMP2017 9017
dents undertaking research-focused coursework such as Honours and capstone research projects
can also be found on the current students website:
https://sydney.edu.au/students/research-integrity-ethics.html
Compliance Statement
In submitting this work, I acknowledge I have understood the following:
1. I have read and understood the University of Sydney’s Academic Integrity Policy.
2. The work is substantially my own and, where any parts of this work are not my own, I
have indicated this by acknowledging the source of those parts of the work and clearly
indicated any quoted text by quotation marks or indentation according to accepted style
standards.
3. I have acknowledged any assistance provided in preparing the work including the use of
copy-editing, proof-reading, and automated writing and drawing tools (including artifi-
cial intelligence (AI), reference generators, translation software, grammar checkers, but
not spell checkers).
4. The work has not previously been submitted in part or in full for assessment in another
unit unless I have been given permission by my unit of study coordinator to do so.
5. The work will be submitted to similarity detection software (Turnitin) and a copy of the
work will be retained in Turnitin’s paper repository for future similarity checking.
6. Engaging in plagiarism or academic dishonesty in coursework will, if detected, lead to
the University commencing proceedings under the Academic Integrity Policy and the
Academic Integrity Procedures.
7. Engaging in plagiarism or academic dishonesty in research-focused work will lead to
the University commencing proceedings under the Research Code of Conduct and the
Academic Integrity Procedures.
8. Engaging another person to complete part or all of the submitted work will, if detected,
lead to the University commencing proceedings against me for potential student miscon-
duct under the University of Sydney (Student Discipline) Rule.
9. That the School of Computer Science, in assessing this assignment, may reproduce it
entirely, may provide a copy to another member of faculty, and/or communicate a copy of
this assignment to a plagiarism checking service or in-house computer program, and that
a copy of the assignment may be maintained by the service or the School of Computer
Science for the purpose of future plagiarism checking.
You are advised to keep copies of your assignment submission, drafts and any other research
materials as evidence of your research and writing process. If you have used AI in the comple-
tion of your assignment, you should keep copies of the AI outputs.
Systems Programming Page 4 of 19
COMP2017 9017
2 Introduction
We are developing a new service aimed at revolutionising document editing, with the ambitious
goal of outperforming competitors such as Word, Notion and Google Docs. To achieve this,
we must implement a server-client architecture where a central server hosts the document and
coordinates all client interactions. Multiple authorised clients will be able to send commands
to the server to edit the document concurrently.
The document format will be a modified version of Markdown. Content will be stored as plain
text using only ASCII characters, simplifying compatibility and transmission.
The server will always maintain the most up-to-date and accurate version of the document. Note
that if your data structure is a simple character array, inserting characters into the middle of the
document would require shifting all subsequent characters, resulting in inefficiency. Therefore,
you are advised to use a more suitable data structure, such as a linked list, to allow for efficient
editing operations.
The structures and basic operations can be found in the code scaffold You must adhere to the
function signatures for the marking script to correctly assess your code.
3 Task
Implement a simulated collaborative document editing system in C, consisting of two pro-
grams:
1. server — the authoritative document host
• Listens for client connections over named pipes.
• Maintains the document in an efficient in-memory structure.
• Applies editing commands (INSERT, DEL, BOLD...) atomically and in the order
received.
• Broadcasts updates to all connected clients.
• Handles client registration, graceful disconnects, and error reporting.
2. client — a console-based editor
• Connects to the server’s named pipe endpoint.
• Sends user commands to read or modify the document.
• Receives update notifications and applies them to its local view.
Deliverables & Constraints
• Source files: server.c, client.c, plus any helpers.
• Must compile on Edstem Linux environment using with no warnings (-Wall -Wextra).
Systems Programming Page 5 of 19
COMP2017 9017
4 Set-up
Client–Server Connection Protocol
1. Start the server by running it with the following command. is the
time interval in milliseconds at which the versions of the document updates.
./server
2. The server starts and immediately prints its Process ID (PID) to stdout:
Server PID:
3. A client joins by invoking:
./client
4. Upon starting, the client immediately sends SIGRTMIN to the server’s PID and then
blocks, waiting for SIGRTMIN+1. The staff client will timeout after 1 second if no
signal is received12. Student will not need to handle these conditions.
5. On receiving SIGRTMIN, the server:
5.1. Spawns a new POSIX thread to handle that client.
5.2. Within that thread, creates two named FIFOs to establish bi-directional communi-
cation:
• FIFO_C2S_ (Client-to-Server)
• FIFO_S2C_ (Server-to-Client)
• If either already exist, clean them up first and then create them.
5.3. Sends SIGRTMIN+1 back to the client.
6. The client, upon receiving SIGRTMIN+1, opens:
• FIFO_C2S_ for writing, and
• FIFO_S2C_ for reading,
and writes its username into FIFO_C2S_.
1The timeout should not block the server thread, or the server process
2Timeout is approximate
Systems Programming Page 6 of 19
COMP2017 9017
Authorisation and Role Communication
7. After receiving the client’s username (as a newline-terminated ASCII string), the server
must:
(1) Check the provided username against the roles.txt file to determine if the user
is authorised and what permission level they possess.
(2) If the username is found, the server will send the following through FIFO_S2C_
:
• The server must send the user’s role (permission) as a single, lowercase ASCII
string, terminated by exactly one newline character (\n). The role string must
be one of the following exact values: write, or read.
• After sending the role, the server must send the full document contents, fol-
lowed immediately by entering the edit-command loop.
(3) If the username is not found:
• The server must send a rejection message: Reject UNAUTHORISED.
• Wait for 1 second on this thread alone, not blocking the whole process3.
• Then close both FIFOs, unlink them (i.e., delete them from the filesystem), and
terminate the server thread handling that client.
roles.txt Format
The roles.txt file must reside in the same directory as the running server executable. Each
line of the file contains a username followed by a permission level, separated by one or more
spaces or tab characters. The valid permission levels are:
• write — permission to edit the document.
• read — permission to view the document but not modify it.
Example format:
1 bob write
2 eve read
3 ryan write
Leading and trailing whitespace around usernames and roles must be ignored. Comparisons
must be case-sensitive.
Document Transmission Protocol
After sending the role string, the server must transmit the full document contents to the client
over the named pipe FIFO_S2C_, following these rules:
3Wait time is approximate
Systems Programming Page 7 of 19
COMP2017 9017
• The document must be serialised as plain ASCII text, preserving all internal newlines
(‘\n‘) exactly as they exist in the server’s current document state.
• The document’s current version will be sent as a newline terminated number, this is
guaranteed to be smaller than uint64.
• The document length in bytes will be first send as an integer followed by a newline
delimiter. The size of the document in bytes is guaranteed to be smaller than uint64.
• The entire document must be sent as a length prefixed byte stream.
• The document content must be immediately readable by the client.
• Transmission must continue after the entire document content is written to the pipe.
Overall example payload:
write\n // role
0\n // version number
34\n // document length
This is the document.\n
Hello world.
Signal Handling Hints (Optional)
Whilst the following functions are not allocated marks, correct behaviour is marked.
• Use sigaction() to register a handler for SIGRTMIN and use sigqueue() for
sending signals if you want to include additional data (e.g., client PID).
• Use sigemptyset(), sigaddset(), and sigprocmask() to block SIGRTMIN
and SIGRTMIN+1 before creating the thread. This prevents signal loss during handler
setup.
• Use sigwait() in the client to synchronously wait for SIGRTMIN+1—this avoids
race conditions and allows clean blocking until the server responds.
• Realtime signals (like SIGRTMIN) are queued by the kernel and not merged, making
them safer than standard signals (like SIGUSR1) in high-concurrency environments.
5 Structure
Both the server and the client need to store a copy of the document. The server’s copy will
always be the most up-to-date and the "true" state of the document, whilst the client’s copy will
be updated as changes are broadcasted from the server.
This is necessary to prevent constantly transmitting the entire document over the network,
which slows down the app.
Systems Programming Page 8 of 19
COMP2017 9017
The following table contains the formatting that is supported by the document.
Element Markdown Syntax
Heading 1 # H1
Heading 2 ## H2
Heading 3 ### H3
Bold **bold text**
Italic *italicised text*
Blockquote > blockquote
Ordered List 1. First item
2. Second item
3. Third item
Unordered List - First item
- Second item
- Third item
Code `code`
Horizontal Rule ---
Link [title](https://www.example.com)
Table 1: Markdown Syntax Reference
Formatting Notes: Note although the following rules must be adhere to when adding format-
ting, markdown is just plain text and the added formatting will not be treated differently to plain
text.
• Space Requirement for Certain Tags: The following Markdown tags must be followed
by a space character (‘ ‘) immediately after the tag to be correctly parsed:
– Heading markers: #, ##, ###
– Blockquote marker: >
– List item markers: 1., 2., 3., -
If a space is omitted after these tags, the element will not be recognised as correct for-
matting and any of our (hypothetical) markdown renderer would not be able to correctly
render it.
• Block-level Elements: The following elements are classified as block-level:
– Headings (Heading 1, Heading 2, Heading 3)
– Blockquotes
– Ordered Lists
– Unordered Lists
Systems Programming Page 9 of 19
COMP2017 9017
– Horizontal Rules
• Newline Requirements for Block-level Elements: When inserting a block-level ele-
ment, the editor must:
– Ensure there is a newline character (‘\n‘) immediately preceding the inserted block
element, unless it is inserted at the start of the document.
– If the insertion point is not already at the beginning of a line (i.e., the previous
character is not a newline), automatically insert a newline before the block element.
– The horizontal rule must have newline after as well. If one does not exist, automat-
ically insert one.
• Inline Elements: Inline elements — specifically Bold, Italic, Code, and Links — do not
require preceding or trailing newlines. They may appear within an existing line of text
without requiring structural separation.
6 Client-Server Synchronisation
Since both the server and clients maintain a copy of the document state, it is critical to ensure
consistent synchronisation of all changes across the system.
All modifications to the document must originate as requests from clients, sent to the server in
the form of commands.
At intervals, the server will issue a new version of the document. It will broadcast all changes
made since the previous version to all connected clients, ensuring synchronisation.
To maintain consistency, the server will only accept commands that target the current version
of the document. Any command referencing an outdated version will be rejected.
It is guaranteed that no two commands will be received at the EXACT same time and operate
at overlapping cursor positions. Targeting overlapping cursor positions of the same version of
the document is allowed.
7 Functionality
7.1 Part 1: Single Client
Commands are issued by the client and sent to the server for processing. Each command affects
the document and must specify a cursor position, which is defined as the number of characters
from the beginning of the document to the intended location.
To simulate user interaction with a GUI, users may type commands directly into the standard
input of the client or server.
All positions are interpreted on the version they reference, and if valid, changes are reflected in
the next broadcasted version. Once edits are made, future edits will need to have their cursor
positions adjusted if necessary.
Systems Programming Page 10 of 19
COMP2017 9017
Command Format Constraints
All commands transmitted between the client and server must satisfy the following properties:
• The command must be composed exclusively of printable ASCII characters (byte values
32–126), with the exception of the final newline character.
• Each command must be terminated by exactly one newline character ‘\n‘.
• The total size of the command, including the terminating newline character, must not
exceed 256 bytes.
• Commands that do not satisfy these constraints (e.g., missing newline, exceeding 256
bytes, or containing non-ASCII characters) are considered invalid and must be rejected
by the receiving side.
• All command arguments are separated by a single space character.
• For commands with a cursor range, end position should not equal to or precede the start
position.
• The following commands are all also valid terminal commands.
• INSERT and DEL commands that causes formatting errors or broken formatting can
happen but do not need to be handled in any way, you can just accept them.
Example:
0 1 2 3 4 5 6 7 8
D o c u m e n t
Position 0 is before the first character D.
Position 8 is after the last character t.
Editing Commands
• INSERT ; Inserts textual content at the specified cursor position
and document version. Newlines are NOT permitted in this command.
• DEL ; Deletes characters starting from the specified
cursor position. If the deletion flows beyond the end of the document, truncate at the end
of the document.
Systems Programming Page 11 of 19
COMP2017 9017
Formatting Commands
Make sure you adhere to the formatting notes 5!
• NEWLINE ; Inserts newline formatting at the position.
• HEADING ; Inserts a heading of the given level (1 to 3) at the speci-
fied position.
• BOLD ; Applies bold formatting from the start to end
cursor position.
• ITALIC ; Applies italic formatting from the start to end
cursor position.
• BLOCKQUOTE ; Adds blockquote formatting at the specified position.
• ORDERED_LIST ; Adds ordered list formatting at the position. Any surround-
ing list items will be renumbered appropriately (e.g., 1, 2, 3...). For example, if an ordered
list is added to the end, it’ll find the previous number and set the new item to previous
number +1. If an ordered list is added in between existing ordered list blocks, it’ll be the
previous item + 1 and all list items will also be + 1. You must handle newlines which can
break ordered lists into two. Delete that breaks formatting does NOT need to be handled.
• UNORDERED_LIST ; Applies unordered list formatting at the specified loca-
tion.
• CODE ; Applies inline code formatting to the given range.
• HORIZONTAL_RULE ; Inserts a horizontal rule and newline at the cursor posi-
tion.
• LINK ; Wraps the text between positions in
[] and appends the link in () to create a Markdown-style hyperlink.
7.1.1 Ordered List
Consider a list:
1. tomato
2. cheese burger
3. asparagus
If I send a command ORDERED_LIST targeting the cursor position between cheese and burger,
the list becomes:
1. tomato
2. cheese
3. burger
4. asparagus
Systems Programming Page 12 of 19
COMP2017 9017
Also if I send a NEWLINE command to the same cursor position to the original list, it becomes:
1. tomato
2. cheese
burger
1. asparagus
If I send a NEWLINE command to the cursor position between 2 and . to the first list, it
becomes:
1. tomato
2
. cheese burger
1. asparagus
List formatting is guaranteed to not be sent if:
• The target cursor position is at or next to a list formatting 2. or - .
• The target is a list item formatted as a different type. For example sending ORDERED_LIST
between love and gaming - I love gaming.
Nested lists are not allowed and guaranteed to not happen. DELETE that causes formatting
problems do NOT need to be considered.
Also note, ordered list numbering is limited 1 to 9.
Metadata and Other Commands
• DISCONNECT; Disconnects the client from the server.
Client Debugging Commands
• DOC?; Prints the entire document to the client’s terminal.
• PERM?; Requests and displays the client’s current role/permissions from the server.
• LOG?; Outputs a full log of all executed commands in order.
Server Responses
• SUCCESS; Indicates that the client’s command was successfully executed.
• Reject ; Indicates the command was rejected, with a message detailing
the reason. See Section 7.4.
These responses are NOT sent immediately, but only sent as part of the broadcast message.
Systems Programming Page 13 of 19
COMP2017 9017
Server Debugging Commands
• DOC?; Prints the current document state to the server terminal.
• LOG?; Outputs a full log of all executed commands in order.
Output Formatting
If the command required output onto the terminal, print the output after the newline, for exam-
ple:
DOC?
This is the document
This is an example of the LOG? command and its output:
LOG?
VERSION 1
EDIT SUCCESS // first command
EDIT Reject // second command
EDIT SUCCESS // third command
END
VERSION 2
EDIT SUCCESS // first command
EDIT SUCCESS // second command
...
EDIT SUCCESS // nth command
...
END
VERSION
...
END
Not that the message for each version is the same as the message broadcasted to the clients at
that version’s update.
7.2 Part 2: Multiple Client
If your collaborative document contains multiple users, multiple edits may occur simultane-
ously. To handle this, the server spawns a separate thread for each connected client. Commands
are queued within each thread. At the TIME INTERVAL update interval, the main server will
collect all the commands from the thread queues based on timestamp order and process the
changes in order. The server adds the timestamp when a command arrives.
Systems Programming Page 14 of 19
COMP2017 9017
Handling Deleted Text and Cursor Position Adjustments All the edits target the broad-
casted document, i.e. what the client was looking at when sending the command. Generally,
no matter the execution order of the commands queued for a version, the final document will
look the same. However for commands with overlapping cursors, this is not true and executing
the commands in the order of timestamp arrival will be critical.
If a section of text is deleted and a future command (from any client) operating on the same
version is to run at a cursor position within that deleted region, apply the following rules:
• For commands with a single cursor position, replace the cursor position with the loca-
tion where the deletion began.
Example: If positions 3 to 9 were deleted in an earlier command on the same version, an
insertion at position 5 will now occur at position 3.
• For commands requiring starting and ending cursor positions:
– If both positions fall within the deleted region, it’s a DELETED_POSITION error.
– If only one position is within the deleted region, the cursor position within the
deleted region will be adjusted to the closer of the deleted edges to the valid cursor
position.
If a section of text is formatted or inserted and a cursor region which overlaps this change is
deleted by a future command targeting the same version, apply the following rules:
• For insertions, the deleted will deleted the original intended deletion and the new inser-
tion is untouched.
Consider a sentence: "Hello world"
– Insert at cursor position 5: " beautiful"
– Then delete starting at position 0, deleting 100 characters
The final result is:
" beautiful"
• For formatting commands requiring a single cursor position, that formatting change will
be applied and deleted along with the original intended deletion.
• For formatting commands requiring starting and ending cursor positions:
– If both positions fall within the deleted region, that formatting change will applied
and deleted along with the original intended deletion.
– If only one position is within the deleted region, that position is deleted and the
formatting is broken.
Systems Programming Page 15 of 19
COMP2017 9017
Versioning System To address the issue of commands arriving in different orders, a version-
ing system is used. This system keeps track of the user’s originally intended edit position and
adjusts cursor positions accordingly.
• A new broadcast is issued every TIME INTERVAL.
• Version numbers start from 0 and increment by 1.
• Version number only increments if at least one edit was made.
• Even if no changes were made, it’ll broadcast just the version number.
• All of the following messages are newline terminated.
• The payload must be closed with an END message.
• The following message is broadcast to all users when a new document version is issued:
VERSION
EDIT SUCCESS // first command
EDIT Reject // second command
...
EDIT SUCCESS // nth command
END
This ensures every client can sync their local copy of the document to the most up-to-date
version.
Edit Validation The server will only accept edits on the current document version. Any
attempt to edit an older version will be rejected.
7.3 COMP9017
Implement the server such that both edits on version N and N-1 are accepted.
You must document and justify your program’s behaviour in a file named README.md. In
this, you must justify, AND demonstrate with testcases with sufficient complexity (incl. edge
cases), why your implementation is well-defined and makes intuitive sense.
COMP9017 students have their marks scaled by 0.9. This component counts for 10%.
7.4 Rejections
The server may reject a client’s command for several reasons. In such cases, it will respond
with a rejection message in the format:
Reject
Systems Programming Page 16 of 19
COMP2017 9017
Below is a list of possible rejection reasons:
UNAUTHORISED
The client does not have sufficient permissions (i.e., write) to execute the specified
command.
INVALID_POSITION One or more provided cursor positions are outside the bounds of the
current document. For cursor ranges, the end position is equal to or lower than the start
position.
DELETED_POSITION The specified cursor position points to text that has already been deleted.
OUTDATED_VERSION The version targeted by the command is no longer accepted by the
server. Commands must reference either the current (or previous for COMP9017) docu-
ment version.
INVALID_POSITION takes precedence over DELETED_POSITION, so if both are true for an
edit, return INVALID_POSITION.
In your markdown.h functions, use the following return codes.
SUCCESS = 0,
INVALID_CURSOR_POS = -1,
DELETED_POSITION = -2,
OUTDATED_VERSION = -3,
8 Tear Down
If there no clients connected to the server, you can send QUIT via the terminal to the server to
shut it down.
In this case it’ll gracefully close the pipes, clean up all the memory, and free up all related
resources. It’ll also save the document in a doc.md in the same directory. If such a file
already exists, overwrite it.
If any clients are still connected, it’ll print
QUIT rejected, clients still connected.
. Example:
QUIT
QUIT rejected, 3 clients still connected.
9 Marking
Automated marking will be conducted through the following two categories:
Systems Programming Page 17 of 19
COMP2017 9017
9.1 Markdown Unit Tests
• A suite of tests will be run to verify the correctness of all Markdown functionality speci-
fied in Section 7.
• These tests include insertion, deletion, formatting commands (e.g., headings, bold, italic,
blockquotes, lists), and version handling.
• The tests will check for correct document state updates and proper command responses.
• Submissions will also be checked for memory safety to ensure there are no memory leaks.
9.2 Staff Client-Server Interoperability Tests
• A reference staff client and staff server have been implemented to verify
protocol compliance.
• Your server must correctly interoperate with the staff client.
• Your client must correctly interoperate with the staff server.
• Interoperability will be verified using input-output based automated tests.
• Strict adherence to the communication protocol (signals, FIFO creation, document trans-
mission format, command structure) is essential for passing these tests.
10 Short Answer Questions
1. How do you ensure that you do not have to constantly copy and shift large chunks of memory
in your code?
2. If multiple edits are made to the same version of the document, how do you make sure the
cursor positions where any edits are made are what the client originally intended.
3. How did you (or would you) test multiple clients interacting with the server at the same
time? Does your test case(s) target race conditions or concurrency-related edge cases?
4. How did you efficiently ensure that all the formatting of ordered lists were correct? If not,
how did you repair them?
5. How can select or epoll change our implementation? Are threads still necessary?
6. Is our program more efficient or runs better than a single process single process model?
Does non-blocking help? If so in what ways?
11 Restrictions
To successfully complete this assignment you must follow the restrictions below. Submissions
breaking these restrictions will receive a deduction of up to 1 mark per breach.
Systems Programming Page 18 of 19
COMP2017 9017
• The implementation of the server must make use of one POSIX thread per client.
• The code must entirely be written in the C programming language.
• Must use dynamic memory for document.
• Free all dynamic memory that is used.
• POSIX library is needed for POSIX threads, however other libraries such as regex.h
is NOT allowed.
• NOT use any external libraries other than those in libc.
• NOT use VLAs.
• NOT use shared memory.
• NOT use regex
• NOT have unclean repositories. This means no object, executable, or temporary files for
any commit in the latest repository. A clean final commit is NOT good enough. You
SHOULD use .gitignore to avoid committing garbage files.
• Only include header files that contain declarations of functions and extern variables. Do
not define functions within header files.
• Any and all comments, including git commit messages, must be written only in the En-
glish language.
• Must use meaningful commits and meaningful comments on commits. 4
• Other restricted functions may come at a later date.
• NOT manually use return code 42, reserved by ASAN.
4"forcing the seed of a test case" does not count as valid commit. Must cite reason and identified
failure.
Systems Programming Page 19 of 19

学霸联盟