2019 case study: Difference between revisions
Mr. MacKenty (talk | contribs) |
Mr. MacKenty (talk | contribs) |
||
| Line 7: | Line 7: | ||
== The case study == | == The case study == | ||
[[Media:2019 case study.pdf| Click here for the full pdf case study]] | [[Media:2019 case study.pdf | Click here for the full pdf case study]] | ||
== Terms worth deeply understanding == | == Terms worth deeply understanding == | ||
Revision as of 13:17, 29 May 2018
Case study[1]
Introduction[edit]
This page will help you organize and understand the 2019 case study.
The case study[edit]
Click here for the full pdf case study
Terms worth deeply understanding[edit]
These articles have been written by students. Any article with a green checkmark 
has been approved by a teacher and can be used reliably to study.
- Template for student-defined terms
- Application programming interface (API) Client side random
- Cluster
- Cluster of servers
- Commercial software
- Computer aided dispatch (CAD)
- Cookies
- Custom software
- Emergency control centre (ECC)
- Emergency management information system (EMIS) Emergency number
- Failover
- Future-proof
- Global positioning system (GPS)
- HTTP or HTTP/2
- Load balancing algorithm
- Multitier architecture
- Proxy server
- Real-time
- Redundancy
- Representational state transfer (REST)
- Scalability / scalable architecture
- Safety-critical
- Session
- Session IP hash
- Session management
- Socket
- Source IP hash
- Stateful / stateless / maintaining state
- TCP/IP sockets
- Transaction processing system (TPS)
- URL rewriting
- Virtual private network (VPN)
- Voice over internet protocol (VoIP)
- Weighted round robin
- Zero downtime
Previous years case study[edit]
- Click here for 2018 case study wiki-notes
- Click here for 2017 case study wiki-notes
- Click here for the 2017 case study
- Click here for the 2016 case study