COMP S362F Final Individual Project
Question paper
In this project, you build a JSON web service server, called the “project server” in this paper. In addition
to the server program, you also develop associated tests and documentation. There is no standalone client
program to develop, but your test cases would make client requests to the project server.
Compulsory rules
You are required to observe and obey the following rules. Violation of any of the rules would result in
zero mark or severe penalty in the project.
• You must develop the project, including all programs and documents, solely by yourself. Work and
contents generated by AI or tools, or from others, must not be incorporated in part or in whole
into your project’s outcomes.
• Python 3.11.x and Flask 3.0.x must be used to develop the project server. Other third-party libraries
may be used but must be documented clearly (see R7 below).
• When the project server is executed according to your documented instructions (see R7), it must
be started successfully and there must be no errors such as invalid syntax, undefined names, missing
libraries, and so on.
• Submission must be made in OLE. In particular, submission, re-submission, or supplementary
submission by email is not accepted. Incomplete submission, such as saved but not submitted work
in OLE, or a corrupted ZIP file, is not accepted.
• Re-submission in OLE before the deadline, within the limitations of the OLE multiple submission
function, is allowed.
• Late submission is penalized by 20% reduction of score per day. Less than a day is counted as a
whole day. For example, a submission that is 24 hours and 1 second late after the deadline will have
the score reduced by 40%. All submitted files and submission times are considered as recorded in
OLE.
You are encouraged to submit at least one day before the deadline, so that you have sufficient time to deal
with submission problems and other unexpected issues. After submission, please re-enter the submission
page to verify the submission status again.
1
Overview
The figure below shows an overview of the project server. Detailed requirements are described subsequently.
The project server supplies two JSON web services to its clients, and works with a quote server. The quote
server is provided to you in the quote_server.py program. The project server runs on localhost TCP
port 5000, while the quote server runs on localhost TCP and UDP ports 1700.
Requirements
The functional requirements (R1 to R4) and non-functional requirements (R5 to R8) of the project are
described in the following.
R1. User information in web service requests
Check user information on all web service requests.
All web service requests to the project server are required to contain user name and password in the request
JSON data. The requirement and error handling on these data are described in the following table.
Data field Key Value data type and format Error handling
User name
(required)
"username" A string of 4 digits, e.g. "0000",
"0123", "3721". (Some invalid
examples are 1352, "a123",
"12345".)
If the key is missing or the value
is invalid, return response code
401 and an error message of
"user info error".
Password
(required)
"password" A string containing the user
name followed by “-pw”,
e.g. "0123-pw" for the user
name "0123".
If the key is missing or the value
is invalid, return response code
401 and an error message of
"user info error".
When a request arrives, the project server first checks the user information. If the user information is invalid, the project server returns the response JSON data with a "error" key and an error message value:
2
{ "error": "user info error" }
If the user information is valid, the project server updates the request statistics (see R2), and proceeds to
process the request (see R3 and R4).
Note that there is no need to store the user names and passwords in a file or database. Their processing
and validation are implemented in code and logic in the program.
R2. Statistics persistence and concurrency access
Keep track of and persist web service request statistics. The statistics include the users who have made
requests and the numbers of requests made; users who haven’t made a request are not included.
The project server maintains and persists these request statistics, which are saved in storage and remain
when the project server restarts. These statistics can be saved in a database, or in a file in plain text format
or Python pickle format etc. In case you choose to use a database, use the built-in SQLite only. Design
the format of a record/line, which contains the user name (a string of 4 digits) and the number of requests
made (an integer greater than 0).
Implement mutual exclusion to avoid race conditions when updating the request statistics. Do this for
data kept both in any program variables and in storage. You are required to implement mutual exclusion
in your code, and assume the database system and file system provide no concurrency facility.
R3. The pi web service
Design and implement the pi web service. The project server supplies the pi JSON web service at the
URL pattern "/pi"with the HTTP POST method. This web service performs Monte Carlo simulations
to calculate the value of 𝜋. See Lab 1 solution for an explanation of calculating 𝜋 using Monte Carlo
simulations.
The request JSON data of the pi web service contains the following fields (for details of user name and
password, see R1):
Data field Key
Value data type
and format Error handling
User name – see R1
Password – see R1
Number of simulations
(required)
"simulations" An integer from
100 to
100,000,000,
both inclusive.
If the key is missing or the value is
invalid, return response code 400
and an error message of "missing
field simulations" or
"invalid field simulations",
respectively.
Level of concurrency
(optional, default to 1)
"concurrency" An integer from 1
to 8, both
inclusive.
If the value is invalid, return
response code 400 and an error
message of "invalid field
concurrency".
3
The level of concurrency specifies the client’s desired number of threads or processes used for fulfilling
the request. You are required to design, implement, and document a concurrency solution suitable for
the task, such as whether to use threads or processes, which Python API to use, and so on.
The response JSON data contains the following list of data. You are required to design, implement, and
document (in the README file, see R7) the data fields, such as the JSON keys, value data types and
formats, and so on.
• Number of simulations, same data from the request
• Level of concurrency, same data from the request
• Calculated value of 𝜋
• Measured time for processing the request
• (Any other relevant fields you consider necessary)
R4. The quote web service
Design and implement quote web service. The project server supplies the quote JSON web service at the
URL pattern "/quote" with the HTTP POST method. This web service retrieves multiple quotes from
a quote server, the provided quote_server.py program, and returns the quotes to the client.
Note that the quote server works like a daytime server, except that it returns text lines of quotes instead
of server times. It serves both TCP and UDP clients: when a TCP client connects, it returns a text
line of quote and closes the connection; when a UDP packet arrives where the packet source address
is the client address, it sends a packet to the client containing a text line of quote. Do not modify the
quote_server.py program.
The request JSON data of the quote web service contains the following fields (for details of user name and
password, see the table in R1):
Data field Key
Value data type
and format Error handling
User name – see R1
Password – see R1
Protocol (required) "protocol" A string, either
"tcp" or "udp"
If the key is missing or the value is
invalid, return response code 400
and an error message of "missing
field protocol" or "invalid
field protocol", respectively.
Level of concurrency
(optional, default to 1)
"concurrency" An integer from 1
to 8, both
inclusive.
If the value is invalid, return
response code 400 and an error
message of "invalid field
concurrency".
The protocol specifies whether TCP or UDP is used by the project server to communicate to the quote
server.
4
The level of concurrency specifies the client’s desired number of threads or processes used for fulfilling
the request. You are required to design, implement, and document a concurrency solution suitable for
the task, such as whether to use threads or processes, which Python API to use, and so on.
Note that in this web service the level of concurrency equals the number of quotes in the response. For
example, to serve a client request with protocol TCP and level of concurrency 4, the project server makes
4 concurrent TCP connections to the quote server to obtain 4 quotes, combines the 4 quotes, and sends
them in the response to the client.
The response JSON data contains the following list of data. You are required to design, implement, and
document (in the README file, see R7) the data fields, such as the JSON keys, value data types and
formats, and so on.
• Protocol, same data from the request
• Level of concurrency, same data from the request
• Quotes (1 to 8)
• Measured time for processing the request
• (Any other relevant fields you consider necessary)
R5. Testing the project server
Implement automated integration/system testing, in one or more testing programs, to show that the
project server fulfills the functional requirements.
Some testing items are described below. You are required to write one or more test cases for each of these
items, and to add other suitable testing items of your own.
• When the user information is missing or invalid in a request, the server returns the 401 status code
with a proper error message.
• The pi web service returns an approximate value of 𝜋.
• The quote web service returns the requested number of quotes.
• For the pi web service, a higher level of concurrency generally has a smaller processing time than a
lower level of concurrency.
• For both the pi and quote web services, when a field is missing or invalid in a request, the server
returns the 400 status code with a proper error message.
R6. Code style, comments, and organization
Maintain good programming style in your code. For example, use proper and meaningful names for
variables and functions, set a proper line length e.g. 78, adopt tidy consistent format and indentation,
remove unnecessary code, and so on.
Write appropriate comments. Remember that lengthy unfocused trivial outdated comments are as bad
as the lack of comments.
Organize the code within a program file or into multiple program files as appropriate.
5
R7. Documentation and submission format
Create a README file that documents the project beyond code comments. It may be either .txt file or
a .docx file, with the file name s12345678readme.txt or s12345678readme.docx, where 12345678 is
your student number. The contents of the README file include the following:
• Your full name and 8-digit student number
• A list of file names and brief descriptions of the submitted files
• Instructions for setting up and executing the project server
• Instructions for setting up and executing the tests
• JSON formats of requests and responses, preferably in table format (see R2, R3, R4)
• Description and justification of the concurrency solutions in the two web services (see R3, R4)
• Discussion of adopting advanced technologies (see R8)
• (Any other relevant topics you like to include)
For the instructions for setting up and executing the project server and tests, describe what third-party
libraries and their versions are used, how to install them, what data files are required, how to initialize the
data files, the command to execute the project server and tests, and so on.
Put your document, program, and data files into a ZIP file called s12345678final.zipwhere 12345678
is your student number. Do not put third-party libraries in the ZIP file. Submit only that one ZIP file to
OLE.
R8. Discussion of adopting advanced technologies
Select two technologies (or techniques) covered in units 11 to 13 (message queues, async programming,
high-performance computing) and discuss their adoption in the project server. Specifically, describe the
benefits, new or improved functionality, and high-level implementation of adopting the technologies to
the project server. You may consider a scaled-up version of the project server in the discussion, such as
having more web service operations, higher level of concurrency, higher transaction volumes, and the
like.
Try to provide your own unique opinions and discussion that pinpoints the specifics of the project. Common and general views would not be sufficient for a high score in this discussion.
Write the discussion in the README file. You may include code segments in the discussion in the
README file. Do not actually modify the code of the project server program files for this discussion.
Scoring
It is easy to get a passing score but not so easy to get a high score. The 8 requirement items, R1 to R8, are
worth 10% to 20% each.
❦❦❦
6