Milestone No. 4 & 5 Completed
Date: 31 March 2001
1.0 Deliverables
There are 9 major
objectives in Milestones 4 & 5.
Comments on each of these objectives are given below:
1.1 Technical Systems (equipment)
assembled and installed at 9 more schools Done
During the past 5 months, 9 SchoolWeb caching severs have been installed at the following 9 schools:
North Peace Secondary, Dr. Kearney Junior secondary, Fort Nelson Secondary, RL Angus Elementary, Westview Secondary, Mountain Elementary, Burnaby North Secondary, Topham Elementary, and Fulford Elementary.
SchoolWeb servers have now been installed at the following nineteen (19) schools:
|
|
School Name |
Locations In BC |
# Students |
# Computers Connected to SchoolWeb Server |
|
|
Secondary
Schools
|
|
|
|
|
1. |
Gladstone Secondary |
Vancouver |
1500 |
120 PCs |
|
2. |
Revelstoke Secondary |
Revelstoke |
650 |
46 PCs, 64 Macs |
|
3. |
Boundary Central Secondary |
Midway |
224 |
125+ PCs, & Macs |
|
4. |
Nakusp Secondary |
Nakusp |
263 |
46 PCs |
|
5. |
Burnaby South Secondary |
Burnaby |
2650 + 250 staff |
500+ PCs |
|
6. |
Burnaby North Secondary
|
Burnaby |
2019 |
200+ PCs |
|
7. |
North Peace Secondary
|
Fort St. John |
880 |
124 PCs |
|
8. |
Dr. Kearney Junior
Secondary
|
Fort St. John |
640 |
50 PCs |
|
9. |
Fort Nelson Secondary
|
Fort Nelson |
480 |
100 Macs |
|
10. |
Westview Secondary
|
Maple Ridge |
1100 |
200 Macs, 50 PCs |
|
|
|
|
|
|
|
|
Elementary
Schools
|
|
|
|
|
11. |
Fort Rupert Elementary |
Fort Rupert |
122 |
15 PCs |
|
12. |
Big Eddy Elementary |
Revelstoke |
110 |
32 Macs |
|
13. |
John A. Hutton Elementary |
Grand Forks |
360 |
80 Macs, 5 PC’s |
|
14. |
RL Angus Elementary
|
Fort Nelson |
260 |
80 Macs |
|
15. |
Mountain Elementary
|
Abbottsford |
431 |
50 Macs |
|
16. |
Fulford Elementary
|
Fulford Harbour |
127 |
50 Macs, 5 PCs |
|
17. |
Topham Elementary
|
Langley |
320 |
60 Macs |
|
|
|
|
|
|
|
|
Special
Schools
|
|
|
|
|
18. |
Robson Community School |
Robson |
175 + Community |
35 PCs |
|
19. |
Port Hardy District Office* |
Port Hardy |
< 1000 |
< 200 PCs, + few Macs |
* This office Server is a proxy for:
North Island Secondary school, 500 students, 100+ PC’s – via T1 line
Port Hardy Secondary School, 500 students, 100+ PCs – via T1 line
Woss Elementary School, 60 students, 12 PCs – via slow wireless
Data is being transmitted to all the schools using their PLNet line connection and by data inserted in the VBI of the Knowledge Network. The inserted data is recovered from the received television signal and cached in files on SchoolWeb servers.
This is the final group of schools to be installed. The project concentration will now be on adding software features to enhance and test different caching concepts.
The SchoolWeb project has chosen a good mix of Secondary and Elementary schools that will allow us to gather appropriate information on the use of caching servers. The mix contains 10 Secondary Schools, 8 Elementary Schools, and 1 District Office feeding several schools as a regional center. There are also some special tests to be made regarding:
(a) Port Hardy District Office, is using its Server as a Proxy server for two secondary schools, each connected by a T1 (1.544Mbps) link, and an elementary school connected by a slow link.
(b) Robson Community School, which allows extensive use of their system by the community during non-school hours.
(c) Boundary Central Secondary School, which carries out a significant distance education program, and could possibly use caching to a greater extent for distance education to students in their homes.
(d) Burnaby South Secondary School, the largest and most diverse school in the Province, with an average of 200+ clients active for much of the day. The school experiences record hits on the server, which handles a record number of files transferred from the Internet. This high level of activity will test the capacity and speed of the server to handle such a load.
(e) Westview Secondary will test the caching throughput through an additional proxy server. The second proxy server is specifically used for site filtering. Other techniques may also be tested, such as lookup tables located on the SchoolWeb server.
Both ‘Dynamic’ and ‘Policy’ caching is employed.
1.2
Data line caching
and broadcast caching to all possible schools.
Statistics of early cache monitoring reviewed and reported. Done
All schools now have both a PLNet line and a KNOW TV connection. Internet sites and data files are passed to the SchoolWeb servers using both of these connections. The connections operate 24 hours per day, 7 days a week.
Periodically checked in the past, but now routinely scheduled, and commencing at the start of the year, each SchoolWeb system is interrogated for statistics of use for the preceding month. Advanced Interactive recovers the raw data and places the statistics into a single file and chart for easy examination. The statistics are now being made available monthly to the schools in order for them to assess their own performance.
The following information is made available:
Number of MB transferred from the Internet in the month
Number of MB transferred from the SchoolWeb cache in the month
Average time to transfer 1MB from the Internet
Average time to transfer 1MB from the SchoolWeb cache
Time saved by using the caching server
Number of Client machines connected
Since there is much more data gathered by the statistics package, there are more monitoring statistics that could be transferred to the schools. The schools are informed that they can also ask for, and receive any other data that we collect. However, our feedback to date indicates that the above list meets their needs.
Early in March, Advanced Interactive sent a sample of the statistics-monitoring file to the first 10 systems installed, along with some insights into their use, and asked for their feedback. The response was very positive. Several schools expressed delight with the excellent results that they were getting, while others observed that they could see ways of improving, and resolved to do so. The exercise also allowed us to emphasize the value of ensuring that all clients were pointed to the caching server; and that the power of “policy-based” (pre-planned) caching was being effectively employed.
Now we, and each of the schools, will be able to look at their performance monthly, by visiting our server and accessing the statistics to assess their progress.
A sample of one of the statistics files that would go to schools is attached.
1.3 Operations Group completes the School
(client) Alpha version of management Software Done
The software development team completed SchoolWeb V1.2 of the software for release on the 19 SchoolWeb servers.
HIGH RELIABILITY DATA WITH COMPRESSION
SchoolWeb V1.1 added FEC coding to the data transmitted to the schools. Soon after the system was installed and tested, it was realized that occasionally, a complete data packet in the video line was lost and the FEC code alone could not replace the lost packet. Therefore, it was decided to add bundled FEC coding to the data transmission. The bundled FEC code effectively eliminates the missed data lines by replacing them with the redundant data contained in the bundled FEC code. The bundled FEC code reduces the effective data rate by approximately 14%. However, the additional 14% redundant data reduces the errors providing a much improved bit error rate. The bit error rate with the bundled FEC is better than 10-9.
Once the data at the schools could be received with high reliability we added a file compression feature that effectively compresses by two to four times. The compressed files are then transmitted to the SchoolWeb Server via the Knowledge Network TV signal. At the schools, the received files are de-compressed and added to the squid cache.
WEBSITE FILTERING
When SchoolWeb servers were initially installed we were relying exclusively on PLNet’s website filtering to prevent restricted websites from being accessed through SchoolWeb servers. At a few of the schools, access to the Internet is not through the PLNet but directly to the Internet via the local Internet Service Provider (ISP). This was causing concern to these schools since pornographic sites could be accesses by students. Therefore, we have enabled a website filter in the squid cache along with a list of restricted websites. The list is not a list of pornographic sites, but rather some general catchall rules that filter out sites, and a second list of sites that would be blocked by this list, that are in fact really legitimate web sites. The school administrators are given the capability of adding restricted sites and/or legitimate websites to the appropriate lists to suit their needs.
We also provide the website filtering utilizing the DNS (Domain Name Service) based filtering provided by the BC Government. The two DNS servers we use for this service are located at:
DNS1.GOV.BC.CA IP: 192.75.26.15
DNS2.GOV.BC.CA IP: 142.22.250.77
Both services are available on our SchoolWeb servers. The school administrator at each school can decide which service(s) they would like to utilize on the SchoolWeb server located at their school.
AUTOMATED STATICTICS COLLECTION SYSYEM
A completely automated system of collecting SchoolWeb statistics for each of the SchoolWeb servers was developed. Each weekday night the Squid log files are rotated and the old files are sent to AIC’s main server via e-mail for analysis. On receipt of the files, the log files are analyzed with an analysis tool and the summary of the analysis is posted on a Member-only website where the summary of the statistics for each of the schools is maintained. This information is available for the SchoolWeb server administrators/teachers to review. On a monthly basis, a complete month’s statistics are analyzed and a summary of the information is made available on the website. (i.e. http://www.advancedinteractive.com/secure)
POLICY BASED WEBSITE ORDERING
One of the main features of a SchoolWeb server is to allow teachers/librarians/school administrators to pre-order websites based on the curriculum in effect at the time. By pre-ordering websites it was felt that we would be able to provide substantially higher speed access to curriculum-based websites, at the school.
A system of ordering policy-based websites was developed and has been made available for test to selected School Teachers and Administrators to pre-order complete websites that would be cached at the SchoolWeb server. An example of a screen showing the ‘Ordering’ of a site is shown below. Again, this site is only accessible to Teachers/Librarians/Administrators that have been provided with a username and password to access the site. Teachers ordering the websites are asked to provide some information that would help in categorizing the ordered website. Information such as:
1. Applicable Grade
2. Subject(s)
3. Keyword(s)
4. Notes
5. Period of Time the website is cache on the SchoolWeb Server
Once a website is ordered, the main server at AIC collects the complete website, indexes it, and then sends each of the files to our Broadcast server at KNOW, for transmission to SchoolWeb servers via the Knowledge Network TV signal, or by line connection in off-hours. The AIC server remembers the files transmitted, and checks each night to see if there has been an update. If so, the new file is sent to all respective SchoolWeb servers.
Soon after this service was put into effect it was realized that a better method of categorizing each of the webpages on the websites was needed. The limited amount of information provided by the Teacher(s) on the WebSite Order page, while helpful, was not a sufficient way of cataloguing a complete website.
Trevor Schofield, the head librarian at Burnaby South Secondary School suggested that an automated way of cataloguing each of the html pages on each of the websites would overcome the problem. One way of doing this was to utilize the metadata contained in the html pages. This method would allow us to extract ‘library types’ of information from the metadata contained in the webpages, and build an automated Library Indexing system. After extensive discussion with Trevor and with additional research, it was decided to use the DUBLIN CORE METADATA INITIATIVE (http://www.dublincore.org) to automatically categorize each of the webpages that are pre-ordered by Teacher(s)/Librarian(s) via our Website Order form.
The Dublin Core Metadata Initiative is an open forum engaged in the development of interoperable online metadata standards that support a broad range of purposes and business models. DCMI's activities include consensus-driven working groups, global workshops, conferences, standards liaison, and educational efforts to promote widespread acceptance of metadata standards and practices.
The DUBLIN CORE contains the following information Elements:
Element:
Title
Name: Title
Identifier: Title
Definition: A name given to the
resource.
Comment: Typically, a Title
will be a name by which the resource is
formally
known.
Element:
Creator
Name: Creator
Identifier: Creator
Definition: An entity primarily
responsible for making the content of
the
resource.
Comment: Examples of a
Creator include a person, an organization,
or a
service.
Typically,
the name of a Creator should be used to
indicate
the entity.
Element:
Subject
Name: Subject and Keywords
Identifier: Subject
Definition: The topic of the
content of the resource.
Comment: Typically, a Subject
will be expressed as keywords,
key
phrases or classification codes that describe a topic
of the resource.
Recommended
best practice is to select a value from a
controlled
vocabulary or formal classification scheme.
Element:
Description
Name: Description
Identifier: Description
Definition: An account of the
content of the resource.
Comment: Description may
include but is not limited to: an abstract,
table of
contents, reference to a graphical representation
of content
or a free-text account of the content.
Element:
Publisher
Name: Publisher
Identifier: Publisher
Definition: An entity
responsible for making the resource available
Comment: Examples of a
Publisher include a person, an organisation,
or a
service.
Typically,
the name of a Publisher should be used to
indicate
the entity.
Element:
Contributor
Name: Contributor
Identifier: Contributor
Definition: An entity
responsible for making contributions to the
content of
the resource.
Comment: Examples of a
Contributor include a person, an organization,
or a
service.
Typically, the name of a Contributor should be used to
indicate
the entity.
Element:
Date
Name: Date
Identifier: Date
Definition: A date associated
with an event in the life cycle of the
resource.
Comment: Typically, Date will
be associated with the creation or
availability
of the resource. Recommended best
practice
for encoding the date value is defined in a profile
of
ISO 8601, and follows the YYYY-MM-DD format.
Element:
Type
Name: Resource Type
Identifier: Type