Technical proposal to server issues - Architecture Document
The server seems to spas out when there are more than 21 (twenty) users on it:
After discussion with the technical team, we have arrived at the following:
1. Limiting the no. of users to 19 (allowing for a 'floater' user to be allowed in. The identity of the floater will never be revealed, they are special.)
2. Implementing a Web Based Ticketing system to allow users in a queue access to E2
There are 2 ticketing systems models which require a decision matrix to decide upon the favoured solution.
Ticket system #1 : "The Deli"
- Users take tickets in turn and wait to be allowed in. They must remain in the locality.
Ticket system #2 : "What they have in British Airways offices"
- Users are given web-based bleepers which notify them when it's their turn. The advantages over the Deli model is that they can go somewhere else but still keep their turn.
Potential Issues:
#1 "The greedy noder"
- The noder who takes tickets for later without needing them. This is more of an issue with the British Airways model as the users are not forced to stay in one area.
#2 "The noder who fucks off"
- There must be in place a defined timeout period whereby a ticket that has been called must be used. The unused tickets are allocated to the next user (i +1).
#3 "The problem of the waiting area"
- The max. no. of users in the waiting area is thought to be in the region of 21. This presents additional problems and could favour a recursive series of waiting rooms linked together through a backbone. The backbone uses message queuing to store and forward ticket requests/ allocation.
#4 "The backbone problem"
- The max. no. of rooms a backbone can support is thought to be in the region of 21. A potential solution could be the introduction of a "Super backbone" - this as yet unrealised technology could support up to 21 backbones in parallel. This allows for growth if we see that a Super Backbone could hold (21 ^ 3) users.
#5 The theoretcial Superbackbone Problem
- This has been flagged as a problem for someone else to deal with after everyone involved in this has died.
I welcome any suggestions, improvements to this document. Please remember, this is just in the planning stage at the moment.
After discussion with the technical team, we have arrived at the following:
1. Limiting the no. of users to 19 (allowing for a 'floater' user to be allowed in. The identity of the floater will never be revealed, they are special.)
2. Implementing a Web Based Ticketing system to allow users in a queue access to E2
There are 2 ticketing systems models which require a decision matrix to decide upon the favoured solution.
Ticket system #1 : "The Deli"
- Users take tickets in turn and wait to be allowed in. They must remain in the locality.
Ticket system #2 : "What they have in British Airways offices"
- Users are given web-based bleepers which notify them when it's their turn. The advantages over the Deli model is that they can go somewhere else but still keep their turn.
Potential Issues:
#1 "The greedy noder"
- The noder who takes tickets for later without needing them. This is more of an issue with the British Airways model as the users are not forced to stay in one area.
#2 "The noder who fucks off"
- There must be in place a defined timeout period whereby a ticket that has been called must be used. The unused tickets are allocated to the next user (i +1).
#3 "The problem of the waiting area"
- The max. no. of users in the waiting area is thought to be in the region of 21. This presents additional problems and could favour a recursive series of waiting rooms linked together through a backbone. The backbone uses message queuing to store and forward ticket requests/ allocation.
#4 "The backbone problem"
- The max. no. of rooms a backbone can support is thought to be in the region of 21. A potential solution could be the introduction of a "Super backbone" - this as yet unrealised technology could support up to 21 backbones in parallel. This allows for growth if we see that a Super Backbone could hold (21 ^ 3) users.
#5 The theoretcial Superbackbone Problem
- This has been flagged as a problem for someone else to deal with after everyone involved in this has died.
I welcome any suggestions, improvements to this document. Please remember, this is just in the planning stage at the moment.