System Architecture
It All Starts With The Requirements
- You can't have a good system without a specifying what you need the system to do. The needs of the system can vary from organization to organization, project to project. If you simply "jump in" and try to build a system from scratch without a plan and a vision, you'll end up with a loose collection of scripts that sort of works, and is difficult to extend/expand beyond what it currently can do. I know this from personal experience.
- By committing to paper (or Wiki, in this case) what I needed this system to do, I could build and script without losing sight of my goal, and to maintain a consistent architecture throughout. This approach is mostly for larger projects that have many departments working on it -- but it worked for ME because I had to work so many facets of this entire project.
- Please look at the Specific Requirements section of the Business Requirements Document page. Section 1 talks about System Architecture. In my discussions below, I will attempt to satisfy each of the requirements listed in this document.
Requirements
- REQT-1.01 through REQT-1.03 basically states in many words, that we need a system that can count Residents at numerous locations, and be able to keep track of how many of them there are, and display it somewhere. In order to accomplish this, we need Sensors which detect the Residents, a Server to keep track of them, and a Client to request and display the data. A picture says a thousand words:
Sensors
- The Sensors are placed in various locations, such as at each Orientation Island (now defunct), each Help Island (HI, HI2 - 16, HI201 - HI 240) and Welcome Area / Infohubs. On a periodic basis, they take measurements of the number of Residents it detects around itself and relays that information to the Collection Server.
Collection Server
- The Collection Server receives the inbound data from the Sensors, and stores them in an internal memory structure, updating previous counts with new counts it has just received from a particular sensor. It can discern which region a particular piece of information originated, and store it accordingly. That is, it keeps OI info together, HI info together and WA/IH info together. The collection server produces, upon request, a dump of the stored information to the Relay Servers.
Relay Servers
- The Relay Servers serve as a "multiplication buffer" between the potentially thousands of Endpoint Devices and the very busy Collection Server. Its primary purpose is to ease the load on the Collection Server such that it does not have to be detracted from the job of collecting sensor information. There are multiple Relay Servers, in potentially multiple locations, and the Endpoint Devices connect to any one of those Relay Servers at random.
Endpoint Devices
- These are the terminus of the data flow, from an Occupancy Counter System aspect. Examples of such Endpoint Devices are the Welcome Area and Help Island text displays on SLVEC and the HI/WA Counter HUD. By using the published API, External Systems and Auxiliary Occupancy Systems can retrieve data and use it for their designed purposes.
Product Distribution System
- This is the HI/WA HUD Vendor on SLVEC Kiosk #6. Its primary purpose is to deliver a free copy of the HI/WA HUD to a Mentor that requests it. Its secondary purpose is to respond to the Relay Server's request to deliver a current/up-to-date version of the HUD to a Mentor if the Relay Server receives a request from an outdated HUD.
Communications
- REQT-1.04 states that the system must operate entirely in-world. That is, it must not be dependent upon any system external to Second Life.
- This requirement forms the basis for the rest of the architecture. This means we must not use a webserver in someone's office or home to send the sensor data. If that person quits SL, or can no longer pay for the connection or hardware, the entire system must be reconfigured to utilize some other makeshift Collection Server. It should not rely on libsecondlife bots or enternal websites for name2key operations.
- This requirement severely restricts our method of communication. I have chosen the Second Life Email System (not drawn in the System Architecture drawing) as the sole method of communication between objects. It is robust, and fault tolerant. The communication does not have to be real-time and can tolerate a few seconds of delay.
- Note: People may criticize the use of the Second Life Email System, especially given the bug introduced in a recent simulator upgrade (See Jira Entry). However, no part of Second Life is safe - over a year ago, XMLRPC-based communcations were broken in a similar upgrade - this occurred before the Jira system was up, so I cannot find references to it at this time.
Reliability
- REQT-1.05 says that the system should not depend on a single Resident to be around. If any part of the system is placed on a private sim, and that person quits SL or sells the land, the entire system can com crashing to a halt.
- REQT-1.07 and REQT-1.09 states that the system must be able to handle a lot of requests and have a mechanism in place that can overcome faults in the system (such as SIM's being down which house the servers). This is accomplished by the Relay Servers whose job is to handle the many requests, and once multiple Relay Servers are setup on different sims, the HUDs can continue to operate even when one of the sims are down. If the sim housing the Collection Server goes offline, the Relay Servers can distribute the cached data until the Collection Server comes back online. The Sensors will continue to send data which queue up and be processed later by the Collection Server.
- REQT-1.08 says that the system must be able to operate continuously, without intervention (unless some unexpected problems arise - such as a Sim Upgrade that introduces a LSL bug which causes a part of the system to stop). The email delivery and checks are controlled by timers in the Servers.
- REQT-1.06 is primarily for the Sensors. We can choose the location of the servers freely - and we shall pick low-lag sims. However, sensors and HUDs must operate in specific regions which are designed to discourage griefing attacks. One must be able to place a sensor on a no-built, no-object entry plot or sim and expect it to operate automatically in a no-script region, and do everything it can to not be returned to the Lost and Found folder. There will be more discussion on how this is accomplished in the Sensor and Endpoint Devices section.
Lum Pfohl 20:30, 1 September 2008 (PDT)
|
| Lum's Quick Links
|
Click to Enlarge
- External Wiki Contributions
|
| Related topics
|
|
|
| edit
|
|
