The Scalable Internet Resource Server (SIRS) concentrates on the development of a service capable of supporting internet resources that are encapsulated in Globe distributed shared objects (DSOs). A Globe DSO can be physically distributed across multiple machines, but more importantly, implements its own object-specific distribution strategy.
For example, consider a software package such as the Linux RedHat distribution. This highly popular package is basically updated at a single site and subsequently copied to several mirror sites all over the world. Clients wanting the latest RedHat release of Linux, should contact their nearest RedHat mirror site and download the software from there. In terms of Globe, the Linux package would be implemented as a DSO with a master/slave replication policy.
A completely different strategy could be used for the distribution of software that is related to a specific language, such as Dutch. In that case, distribution may be restricted to the Netherlands only by installing it at a single site, and let replication take place on demand by means of proxy caches.
These two examples illustrate that it makes sense to distinguish different distribution strategies, and assign strategies on a per-object basis. In particular, by distinguishing object-specific distribution strategies, it becomes possible to devise scalable solutions by exploiting distribution, caching, and replication. Solutions can be made scalable by taking into account exactly how an object is used and modified.
The SIRS project is basically concerned with building client and server software that can support Globe DSOs encapsulating typical internet resources such as Web pages and FTP-able files such as software packages.
An important part of the project is formed by a system that supports location-independent names. Such names are imperative if replication (or mobility) of objects is to be supported. At present, naming in internet applications is basically done by means of URLs. A URL identifies a transfer protocol, a server, and a resource that is managed by that server. Because the server's name is incorporated in the URL, it becomes impossible to replicate a resource to another server without changing its name.
To support replication, we need a location-independent name such as a URN, which is subsequently translated into one or more URLs, where each URL refers to a specific replica. The SIRS project includes the development of a naming system to support location-independent names, and the mapping of such names to URLs.
The goal of SIRS-1 was to build client software with the functionality listed below. For each item, we describe what has been achieved.
We have built a name service using BIND8, and connected this to our existing implementation of the Globe location service. At present, it is possible to resolve a Globe URN such as ``globe://globe-doc.html'' into a URL specifying exactly where the referred Globe distributed object can be contacted.
We have deleveloped a component that acts as a front end to the naming and location system. This front end is comparable to lightweight Web proxy capable of accepting http requests, possibly embedded with requests expressed in different protocols such as ftp. The front end, called the translator, supports the translation of http requests to Globe URNs, and vice versa. Http requests that do not have a Globe URN embedded, are forwarded to regular http servers and other proxies. Globe URNs are forwarded to the Globe naming service.
The translator can also accept an HTML page that contains Globe URNs, which it then translates into an HTML page with only syntactically http references. Such a page can be displayed on any existing Web browser. In effect, our translator is the main mechanism by which Globe distributed objects that encapsulate Web pages, can be accessed through existing browsers.
In addition to these deliverables, we have also done the following:
It should be clear from the previous section that in SIRS-1 we did much more than was laid down in the original project plan. However, what we have not yet done is thoroughly test our software. The main reason for not doing so, is that thorough testing makes sense only when the complete system is available in prototype version.
In particular, the following needs to be done (and will be done within the context of SIRS-2):
Added to this report are two documents. One document describes the current setup of SIRS, the other document describes in detail the combination of the naming and location service.
In a meeting with NLnet held on 09.12.1999, the following was agreed:
The sites will be selected as soon as possible. Although no date has been explicitly mentioned, a number of candidate sites will be contacted before 01.03.2000. Besides NLnet, possible candidates are:
A financial statement has been added separately to this report.
Back to Stichting NLnet projects page