EduStream Technical Architecture
For use with Assignments 1 and 2 Page 1
A SHORT OVERVIEW OF THE TECHNICAL ARCHITECTURE
This document provides a simplified description of the technical architecture developed for
the EduStream system. This architecture is illustrated in Figure 1.
Figure 1: EduStream Simplified Technical Architecture
As shown in this diagram, there is a requirement for the development of a client application (shown in
the blue box), and the creation of three Pilot Content Delivery Network (CDN) nodes (shown as the
yellow boxes). As explained in the Assignment 1 Information Sheet, these Pilot nodes will be located
in Perth, Sydney and Melbourne. The key elements of the architecture that you need to consider are:
(1) CDN Nodes. Each of these nodes will be positioned in a Tier 3 co-located (Colo) Datacentre
(see this web page for a simple synopsis of Tier 3: https://www.colocationamerica.com/datacenter/tier-standards-overview.htm). All of the equipment shown would be standard 19 inch
(482.6 mm) rack-mounted units. The systems required in each node will be:
a. Web Servers. The web servers will form the front-end of the system, which will be
accessible to the clients. These will require a friendly and intuitive user application, so the
people using the system can find and download their game or video easily. Additionally,
the web servers will require appropriate hardware. For the web server system to run
effectively, it will need to be able to interface with the Client Database (DB) system, and
also draw directly from the OCA and games server catalogues, so they can show what
content (videos/games) is available.
b. Client Database (DB). The Client DB will store the users’ information. This should
include data like their names, age (so their access to content can be defined), addresses,
billing information, credit card details (so their monthly fees can be debited automatically),
type of license, client equipment/environment information, what content they have
watched (so recommendations on viewing content can be presented through the web
server), and what games they have tokens to play (so they cannot play games if they do
not have the appropriate software tokens). The development of this system will require:

CLIENTS
Client Application
(CODEC & send requests & control)
Redundancy & Load Sharing

EduStream Technical Architecture
For use with Assignments 1 and 2 Page 2
need to determine exactly what elements of this environment we actually require, as
this will make a big difference to pricing);

will also be required (including table / cell level encryption – as discussed below).
c. Open Connect Appliance (OCA). As illustrated in the recommended videos (links for
these are provided within the Assignment 1 Information Sheet), the OCA is a video
streaming server. This will require:
i. A hardware system that can store the video that will be available through the
EduStream system. In practical terms, this will be a specialised type of rackmounted server, which has been developed by Netflix. It is possible that they may
provide this to us at low cost, but we would need to negotiate this with them.

RTSP control interfaces, and apply a data compression engine (in this case we are
aiming to use HEVC/H.265).

HEVC compression to work optimally. The conversion is not a small task, so it
would need to be built into your WBS.
iv. An interface will be required between the OCA and Client Database, which is shown
in Figure 1. Additionally, it will be important to create a direct interface to
the web servers from the OCA, to make it easier to show the latest content
that is available (this is not explicitly shown in the diagram, but this is
inferred)
d. Games Server. The Games Server will be a streaming engine for the available educational
games. To implement this system the following will be required:

(which is shown in Figure 1). This interface will check the tokens(1) stored within
the Client DB for that user, with the ones listed against specific software. These
will be used in the client software, to determine whether the game can be played or
not (e.g. if they have not paid their membership fee, or do not have the rights, they
will not be able to access the game even if it is downloaded to their client).
1. A token in this context is an encrypted number that must be found by the software so it can be
run. A range of different approaches can be used to implement this, and for the purpose of this
assignment the actual solution to be applied will not be pertinent. Therefore, just refer to this in
your materials, and only go deeper if you really want to learn more for yourself.
EduStream Technical Architecture
For use with Assignments 1 and 2 Page 3
iv. Existing and new games will need to be modified appropriately, so they apply a
token, which means that the client cannot play the game if the user’s monthly fees
have not been paid or they do not have the appropriate access. This could be a fairly
complex task depending on the inventory of games currently held and whether they
are black-box, grey-box, or white-box (e.g. how much access do we have to the
underlying code).
e. System Health Management. System Health Management requires hardware and a
tailored application to monitor activity within the CDN nodes. For example, it should
monitor aspects such as network utilisation, disk access loads, server CPU loads, etc. This
element will be essential to allow load sharing to be implemented (see the Netflix
description video recommended in the Assignment 1 Information Sheet).
(2) Client. The client refers to a downloadable application that will be able to run on Android/Apple
(Phones, Tablets, etc.), Apple/PC hardware, smart TVs, or TVs using standard network access
boxes. As there will be a range of operating systems, we will need to develop different versions
of the App that will run in these environments. Therefore, although we will not be providing the
user hardware, we will need to provide the different types of hardware/environments that will be
used by clients within our Test Environment (so we can test the systems properly). Additionally,
this client software will need to have the RTSP control interfaces, CODECs and a thin-client
application that interacts with the appropriate web server. Please note that when load sharing
occurs (see below), the client may need to point seamlessly toward another node Web
Server/OCA (without the user knowing about the shift – it should be transparent).
(3) Network. For this system to run effectively, it will need access to consistent high-volume
network connections. These connections will need to support TCP-IP, which will be used to
implement the interconnectivity between clients and CDN nodes. Typically, these will be
available within a Colo datacentre. This is particularly true if we are using a Tier 3 Datacentre,
as these have to provide multiple/redundant network connections to achieve this rating.
(4) Security. This system will need to be secure. In practice, this would apply a Defence-in-Depth
approach that will include physical security (unauthorised people cannot gain physical access to
the servers/OCAs in the Datacentres), wide area network security (WAN secure network
connectivity is secure), local area network security (LAN connection between the node
elements); application security (for the client, web server, Client DB, Games Server, OCA,
System Health Management, etc.), Database (table/cell level controls/encryption), etc. The key
is that this needs to be fundamentally built into the design. Therefore, it will require hardware
(e.g. firewalls, although you will also use the Datacentre firewalls), software (e.g. virus
management software), application protections (built-in during development) and database
controls (to protect user data).
These are the elements that will need to be implemented for the Pilot 1 solution. This Pilot will be
introduced in Perth. The Pilot system will then be tested extensively to find any bugs and other
problems (which will invariably be there). Consequently, there will be an extensive testing program
implemented prior to deploying the second Pilot Site.
In parallel with this activity, the following capabilities will be implemented, and then tested extensively
once the second Pilot site also is set to work:
(1) Load Sharing. This system will leverage the System Health Management (SHM) capability.
When components are under pressure (e.g. they are being used a lot), the SHM will find another
node within the network that is under lower load (e.g. will provide less latency/delays to the
client). The client will then be pointed to another node to load balance across the entire system.
EduStream Technical Architecture
For use with Assignments 1 and 2 Page 4
(2) Batch Updates. The idea is that all of the nodes will have the same content all the time. However,
shifting large games and video files will use up bandwidth, which could then reduce the users’
ability to access the content. Therefore, batch updates are typically done during periods of low
utilisation. A system will need to be developed to manage this.
(3) DB Replication. It will be essential that the data held in the Client Databases is the same in all
nodes. Consequently, a technique known as replication is used. Once data is changed in one
database, this replicates into the databases in the other nodes. Systems like Oracle provide quite
a powerful replication system with relatively little development/tailoring required.
Once the final CDN node is implemented, a range of tests will be needed to ensure that the multi-node
architecture will work.
This broad approach is known as creating ‘cookie-cutter’ solutions. In practice, it means that once all
the bugs/problems are fixed, EdMI can simply deploy the same mix of software/hardware systems into
new nodes (e.g. other appropriate Datacentres) as necessary to expand the system.