|
The Application
WEB BASED:
MySatori™ is an Internet-based application. The servers are located at a dedicated hosting service provider.
RELIABLE:
The dedicated hosting provider is equipped with backup power generation, in the event of a long term primary power failure. We have offsite monitoring software that will notify us in case any critical servers become inaccessible, so that we are automatically alerted to begin working on any failure within minutes. Wherever possible, we use redundant servers, allowing client requests to be redirected to a responsive server in case one fails.
SCALABLE:
We used proven J2EE technologies to design a scalable server architecture. The server hardware is arranged into clusters of redundant workers, so that the access load, even from a single school campus, is spread over multiple independent servers for scalability.
SECURE:
All ports on all servers are source IP restricted, except the "front" Apache HTTP server, which has only ports 80 and 443 exposed to any source IP address, i.e., HTTP for normal web browser access and HTTPS for secure login to MySatori™. The middle layer workers and backend database servers are completely firewall protected from all external access on all ports, so that only Sleek Corporation employee IP addresses can connect to them.
PERFORMANCE:
Current student wait time between questions is 1-3 seconds. This performance assumes there are no client-side processes slowing the transmission of data from our servers to the workstations.
The application has been optimized to minimize bandwidth requirements. Significant additional bandwidth savings can be realized for those campuses and districts utilizing an http proxy server that can cache static files. The actual bandwidth savings depend on the number of users, the cache settings, and the proxy server's specifications.
Basic Requirements
We officially support:
- Internet Explorer 6 and 7 for Windows
- Firefox 1.5, 2.x, and 3.x for Windows
- Firefox 1.5, 2.x, and 3.x for Mac OSX
Other browsers may work, but are not guaranteed. There are currently known technical issues with Safari.
Popups should be allowed from the *.mysatori.com domain.
Firewalls and filters, etc. should allow the *.mysatori.com domain through.
The browsers should have Javascript enabled and have a Flash player installed (version 7 at least)
Bandwidth Requirements
Required Download speed = 16 Kbps per student workstation (or 2 K Bytes / sec down)
Required Upload speed = 2.3 Kbps per student workstation (or 0.3 K Bytes / sec up)
PLEASE NOTE that this bandwidth is averaged over time, so the initial starting of an assignment could use a little more bandwidth, but will level off after answering a few questions. The bandwidth requirements will also vary somewhat for different grades and subjects, but most titles should require less than this.
You can test your bandwidth speed using one of the online utilities:
http://myspeed.visualware.com/
http://www.speakeasy.net/speedtest/
If you share your Internet connection with others at your school or district, then your available bandwidth could vary from day to day or even from minute to minute depending on how others are using the shared Internet connection, e.g., if someone else is downloading a large file or VOIP, then this may consume a lot of your bandwidth. You would need to consult your network administrator to figure out how to resolve this.
For example, 1 lab with 30 workstations with a student at each workstation would need:
480 Kbps downstream = 16 Kbps * 30 students
69 Kbps upstream = 2.3 Kbps * 30 students
Another example:
A T1 connection is about 1300 Kbps download and upload speed, so a T1 would allow about 80 concurrent students, assuming the bandwidth was dedicated to MySatori usage, but it is more common that it is shared with other users, so the upper limit on concurrent students would be less than 80 depending on how much bandwidth is used for other purposes.
Licensing
We will provide you with a button graphic and HTML that you can post on your school's website for easy access.
Our licensing is based on concurrent users by title. This means you can enter all of your students into the system, but the number of students who can log in to a particular title at the same time will be limited to the number of seats you purchased of that title. Teachers and administrators do not count as concurrent users, unless they log in to work an assignment. You can have as many teachers and administrators as you like logged in, with no restrictions.
Internet Filters
In order for MySatori™ to work correctly, your network administrators should ensure that no traffic from your school's MySatori™ domain is blocked or altered. This is typically called White Listing.
If MySatori™ is being blocked, try the following:
- Any Internet filters your campus, district, and/or regional service center may use should allow traffic from your school's MySatori™ domain to pass through the filter, or better yet, bypass the filter completely.
- If your school uses packet inspection devices, the performance of MySatori™ may be impacted. It is best if traffic from your MySatori™ school domain is excepted from the inspection process.
- If several campuses at your district use MySatori™, then you can use wild cards such as *.mysatori.com for all your district's campuses.
- If the filter you are using does not accept a Domain Name, then you can use these IP addresses:
12.158.191.156
72.233.16.161
67.228.70.201
67.228.70.211
12.158.188.46
72.233.16.163
67.228.70.202
67.228.70.212
67.228.70.203
67.228.70.213
These addresses are either currently used or will be used in the future as we upgrade our servers. If an address is ever decommissioned then we will notify you so that you can block it again.
It is likely that there will be additional addresses as we increase our capacity so if at all possible, use your MySatori™ school domain or the wildcard domain name *.mysatori.com to configure your internet filtering and caching devices.
- Some browsers, such as Internet Explorer, have additional security settings. In this case, you will need to add your school's MySatori™ domain name to the list of "Trusted sites".
•
Open Internet Explorer and choose Internet Options from the Tools menu.
• Click on the Security tab.
• Click on the Trusted sites "zone" (the green check mark).
• Click on the Sites button.
• Uncheck the check box called "Require server verification (HTTPS)" which is at the bottom of the dialog box.
• Copy and paste your school's Domain into the top entry field called "Add this website to the zone:" Example:
myschoolname-mydistrictname-tx.mysatori.com
(Note that you should leave off the http:// or https://)
• Click the Add button.
- Finally, on Internet Explorer 7, the phishing filter can slow performance and in some instances interfere with MySatori™. We suggested that it be set to “Disabled.”
Caching
File caching can be and is done by a variety of different devices, both hardware and software, and may take place locally, at the district offices, or by your internet provider.
It is essential that two particular types of files in MySatori not be cached. Theses are files that end in .do and .jsp
If these files are cached you can see a myriad of problems:
- Users kicked out of the assignment to the Assignment List
- Users kicked out to the login page
- Duplicate problems/questions
- The students' names changing on the top right.
You should work with your network engineers to make sure that the appropriate changes are made to all the hardware/software that may cache files.
There are basically 2 reasons you would not want cache dynamic pages:
- The page may change over time (like a news web site)
- The page may be different or customized for different users who are logged into a web application
Some caching software will assume that #1 above is the reason for not caching pages and ignore #2 by default. But in this case, if two different users request the same dynamic page at the same time (ie, concurrently), then it will return the identical page result to both users. This will cause problems because the page should be customized for a given user with a different cookie or login session, otherwise resulting in unpredictable behavior where users will sometimes see a page that was intended for a different user.
We have seen this particular caching issue with Novell's BorderManager software where adding the *.do and *.jsp patterns as dynamic pages was not sufficient to resolve the caching problem when there were concurrent user requests to the same page. It was also necessary to "Specify to not cache or split requests that have a cookie to avoid sending different replies to different users for the same request."
(See http://www.novell.com/documentation/nbm39/pdfdoc/administration/administration.pdf, Pages 56/57 if you use Novell's BorderManager.)
|
