Computer Science Paper 3 Hl Markscheme
Computer Science Paper 3 Hl Markscheme
Markscheme
May 2019
Computer science
Higher level
Paper 3
11 pages
–2– M19/4/COMSC/HP3/ENG/TZ0/XX/M
Additionally, the license tied with this product prohibits commercial use of
any selected files or extracts from this product. Use by third parties,
including but not limited to publishers, private teachers, tutoring or study
services, preparatory schools, vendors operating curriculum mapping
services or teacher resource digital platforms and app developers, is not
permitted and is subject to the IB’s prior written consent via a license. More
information on how to request a license can be obtained from http://
www.ibo.org/contact-the-ib/media-inquiries/for-publishers/guidance-for-
third-party-publishers-and-providers/how-to-apply-for-a-license.
Mark allocation
General
A markscheme often has more specific points worthy of a mark than the total allows. This is intentional.
Do not award more than the maximum marks allowed for that part of a question.
When deciding upon alternative answers by candidates to those given in the markscheme, consider the
following points:
• Each statement worth one point has a separate line and the end is signified by means of
a semi-colon (;).
• An alternative answer or wording is indicated in the markscheme by a “/”; either wording can be
accepted.
• If the candidate’s answer has the same meaning or can be clearly interpreted as being the same as
that in the markscheme then award the mark.
• Mark positively. Give candidates credit for what they have achieved and for what they have got
correct, rather than penalizing them for what they have not achieved or what they have
got wrong.
• Remember that many candidates are writing in a second language; be forgiving of minor linguistic
slips. In this subject effective communication is more important than grammatical accuracy.
• Occasionally, a part of a question may require a calculation whose answer is required for subsequent
parts. If an error is made in the first part then it should be penalized. However, if the incorrect answer
is used correctly in subsequent parts then follow through marks should be awarded. Indicate this
with “FT”.
• Question 4 is marked against markbands. The markbands represent a single holistic criterion applied
to the piece of work. Each markband level descriptor corresponds to a number of marks. When
assessing with markbands, a “best fit” approach is used, with markers making a judgment about
which particular mark to award from the possible range for each level descriptor, according to how
well the candidate’s work fits that descriptor.
–4– M19/4/COMSC/HP3/ENG/TZ0/XX/M
General guidance
Issue Guidance
Answering • In the case of an “identify” question read all answers and mark positively up to the
more than maximum marks. Disregard incorrect answers.
the quantity • In the case of a “describe” question, which asks for a certain number of facts
of responses eg “describe two kinds”, mark the first two correct answers. This could include two
prescribed in descriptions, one description and one identification, or two identifications.
the questions • In the case of an “explain” question, which asks for a specified number of
explanations eg “explain two reasons …”, mark the first two correct answers.
This could include two full explanations, one explanation, one partial explanation
etc.
–5– M19/4/COMSC/HP3/ENG/TZ0/XX/M
Regularly updated;
Therefore, contains fewer errors;
URL Rewriting does not result in anything being saved (e.g. cookies) on the client
side;
Therefore, the privacy of the client cannot be compromised (e.g. By searching
contents of the cookie folder later);
Allows the details of the identification of the user to be recorded in log files;
Which will help for future analysis/reviews/data mining; [4]
–8– M19/4/COMSC/HP3/ENG/TZ0/XX/M
3. Award [6 max].
Award [1] for each point that explains why the use of VPN reduces the effectiveness of
the app up to [6 max].
Definitions:
The source IP hash combines the source and destination IP address to generate a
hash key, which is then assigned to a specific server. The benefit of this approach is
that a client who experiences a dropped connection can be returned to their session
with the same server.
The client-side random load balancing algorithm delivers a list of server IPs to the
client, which then selects a server IP at random.
Security
As Client Side Random allows control of the choice of server to be made by the client it
would leave the system much more vulnerable to DOS/DDOS attacks.
Persistence
If disconnected, Client Side Random may allocate a new server to the client as it will
choose randomly from the list. However, if the IP is the same, then Client-side Hash will
pair the client with the previous server. This may mean that the work being done before
is not lost (e.g. Client continues from where she left of seamlessly).
Cost
Client Side Random is a cheaper solution as it doesn’t require any expensive hardware on
the server side (i.e. the hardware load balancers etc).
Control
When using client side random, Bangbai Government is essentially losing control over the
load balancing process. If for some reason they suddenly want to re-direct all queries away
from certain servers (e.g. It’s been compromised, or the data centre has a fire etc) they
can’t, as they cannot easily/quickly change the algorithm on each of the client devices.
Intelligence/Adaptiveness/Flexibility
Client Side Random may not take into consideration privileged information about the
servers, which it does not have access to. Therefore, it cannot decide which of the servers
is *currently* best suited to handle a specific type Such information may include:
• Server Resources are different (Primary Memory, Secondary Memory,
Processor)
• Deployment of the services to different servers (Server A and B deal with video
reports, Server C with simple text/photo reports etc).
• Current load of each server (Server B has more connections than server A)
• Current Health of each server (Server C just died)
– 10 – M19/4/COMSC/HP3/ENG/TZ0/XX/M
Additional Research
Caching can affect a lot of load balancing algorithms as they use DNS to allocate the next
server. This can skew the allocation of servers, but because Client-side Random uses a
randomly generated server from a simple list, it avoids this problem.
The HTTP/2 specification, which is now supported by every major browser, has built in
support for Client-Side Load Balancing. The citizen reporting app can benefit from this as it
uses HTTP for the REST API.
Overall comparison/evaluation
The main issue with the source IP hash load balancing algorithm is that each change
can redirect EVERYBODY to a different server, which again lags the time of response
for a citizen call in Bangbai.
That is why some good load-balancers have implemented a consistent hashing method
to ensure that if a server fails, for example, only the client connected to this server are
redirected and not all.
The counterpart of consistent hashing is that it doesn’t provide a perfect hash, and so,
in a farm of 3 servers, some may receive more clients than others and this can take a
toll on the time of response to citizen calls.
When a failed server comes back, its users (determined by the hashing done on the
Source IP) will be redirected to it again.
There is no overhead in terms of CPU or memory when using such an algorithm.
Conclusion
A final measured conclusion that links together the various points and recommends
one or both of the algorithms as appropriate for the needs of Bangbai. [12]
– 11 – M19/4/COMSC/HP3/ENG/TZ0/XX/M
[12]
Total: [30]