XS Server Services

These are services that the School server will provide. Additional services under consideration for deployment are listed separately. Service meta issues such as installation and management are discussed on School server specifics.

Please help by adding links to existing pages discussing these topics, if you are aware of them

Library

The school library provides media content for the students and teachers using a School server. This content may either be accessed directly from the school library or downloaded onto the laptops. The content in the school library comes from a variety of sources: OLPC, the country, the regional school organization, other schools, and teachers and students in the school.

A number of the attributes of a library (self-management, scalability, performance, identity) are discussed in their own sections below. But it is clear that the library is not a single service, but rather a set of services (wiki or wiki+,http cache, bittorrent client, etc...) which combine to provide the Library functionality.

Self-management

What is the mechanism for user submissions of media to the library? Teachers (and students) should certainly have a place to put resources they create where all can retrieve.

What about local wikis? Should they be supported on the School server? They are probably best replaced with a more function oriented information organization tool such Rhaptos or Moodle, and an online extension of the journal which supplants blogging.

Repository

Content centered, but allowing collaboration in building new content. See http://cnx.org for an example. The service is provided as open source software by the name Rhaptos. It's Python based.

Collaborative/Publishing/Learning Management System

Moodle could be an option? http://moodle.org

Exchanging published work with other communities could be done using a usb, taking a class portfolio (using moodle pages) to another village. Distance collaboration can also be done in an asynchronous way, where each school has its page or set of pages in Moodle, and it would work like standard mail, travelling by land to another school, kids contributing, commenting, peer-assessing, and then back again.--Anonymous contributor

Bandwidth Amplification

This problem is mainly one of supplying content posted to a school's library to a large number of other schools. This is a problem due to the limited bandwidth available for uplink from a typical school. It also appears in the distribution of new content (revised textbooks, OEPC, software updates, etc.)

This is the problem that cable and satellite networks were developed to solve. Thankfully, the Internet has made it an easier problem. Unfortunately, the architecture most useful for nonprofit distribution --- peer-to-peer (P2P)--- is not well suited for use by school servers using highly asymmetrical (DSL, satellite) network connections.

One solution is a well-connected server with a large amount of storage provided at the regional or country level which will mirror (and backup!) the unique content from each school. P2P access protocols can be used to reduce the load on these (seed) servers making use of schools with good uplink connectivity (are there any of these, perhaps in major cities ?).

Caching

The size of the desired library is larger than the storage capability of any single School server. Aside from locally generated content, a significant portion of the library is likely to be available only from remote sources. In order to preserve the user experience, a transparent HTTP proxy will cache frequently accessed content locally at the school.

Security and Identity

The issues around who can upload content to a Library, and how this identity is determined are difficult ones (being addressed elswhere in this wiki ?).

Network Router

The School server is first and foremost a node in the wireless mesh which provides connectivity to the larger internet.

A starting assumption is that it is largely a transparent router. It does not perform any network address translation, and very little packet filtering. It will perform bandwidth shaping to ensure fair access to the internet.

HTTP Caching

The only packet filtering proposed is a transparent proxy on port 80, which will allow a caching of commonly accessed HTTP (web) content to occur locally. This will reduce the load on the internet connection, as well as the response time seen by a user. This may be relied upon to implement the School library.

The problem here is availability of HTTP caching software. The open source favorite, squid, is not IPv6 compliant.

Name Resolution and Service Discovery

The School server will use and support the use of Zeroconf techniques for device name declaration and service discovery.

It should also support traditional DNS by exporting the mDNS name registry.

Bandwidth Fairness

The School server should implement a bandwidth fairness algorithm which prevents a single user from dominating the use of the internet connection. The problem is that the short-term fairness algorithms used by TCP give P2P software equal consideration as users trying to access a document over the web. By biasing the queueing algorithm based on usage over the past 4 to 24 hours, we can protect the random browser from the heavy downloader.

The problem is that due to our mesh network, we may really be penalizing a remote classroom relayed through a single node.

We could bias the bandwidth allocation based on remote port (e.g. favoring web access to port 80), but this solution seems less than optimal.

Backup

According to this description of the Journal, it will provide automatic backup to the School server, with a veriety of restore options.

What are the plans for providing additional storage to users of the XO laptops? How does the Journal handle filling up the available storage on the XO? allocated storage on the School server?