System Proxylets

that the monitoring interface uses callbacks. The callbacks are implemented by an EEP making RMI calls back to the monitor interface. This causes two potential problems if the interfaces were integrated. Firstly, it would not be possible to start a proxylet that is not running a rmiregistry for whatever reasons. The second reason is that it would be difficult to start a proxylet on an EEP at a foreign site from behind a firewall. A typical configuration for a firewall is that outgoing connections are allowed and incoming ones are not. Similarly it would not be possible to start proxylets from sites that are behind NATs (Network Address Translators).

In the longer term however there is an intent to provide an integrated interface. This can perhaps be achieved by disabling monitoring features, or by implementing callbacks via an alternative mechanism to RMI.

5.6

System Proxylets

As has previously been observed, our initial release contained several deficiencies, per­ haps the most significant being in the area of dynamic discovery of EEPs and routing. It could be argued that such functions are core to the EEP infrastructure, and thus should be implemented within the EEP. However in practical terms it is more attractive to develop such functionality incrementally as proxylets. This allows us to upgrade the functionality of running EEPs relatively easily. In this section we describe two such

proxylets which represent quite simple, initial approaches to providing routing and er­

ror handling functions.

We have developed a simple mechanism for certain proxylets to be started at boot time of an EEP. We call these system proxylets. At this time system proxylets do not have any special privileges. They are also not handled differently to standard proxylets.

Their only distinction is that they are loaded at boot time. It should be noted that if either of the two system proxylets is not present, the EEP will continue to function, although with slightly reduced functionality.

5.6.1 Routing

The scope of the problem of building a scalable application level routing infrastructure is huge. In order to permit experimentation, we have provided a routing proxylet which does not scale and provides a very naive proximity interface. Below we outline our current work towards providing a scalable routing infrastructure [33]. The next chapter (6) goes into greater detail.

The initial routing proxylet provides two interfaces. The first interface provides a list of all executing EEPs. The second interface provides the location of a proxylet

close to a provided domain name.

The implementation of the routing proxylet is simple. A coordinator node is pre­ configured into the routing proxylet. Each proxylet periodically sends a registration packet to the coordinator. All EEPs are therefore known by the coordinator.

Any routing proxylet can be interrogated for the list of all EEPs. The client does not need to know which routing proxylet is the coordinator. If a request is made of an EEP which is not the coordinator then it will request the information from the coordi­ nator and pass it on to the client.

As well as a list of all available EEPs the routing proxylet also provides a proximity function. The proximity function has the name “close”. A domain name can be passed to the “close” method of any routing proxylet and it will attempt to return an EEP which is close to this domain name. Our implementation is extremely naive: a longest match on the domain name string is performed.

5.6. System Proxylets 109

We realize that there is a large number of obvious failure modes with such a scheme. For example, if a request is made for an EEP close to “acm.org” there is no useful geographic information. Another problem is that nowadays a site with, for example, the suffix “.au” does not necessarily have to be in Australia.

Therefore we have provided a routing proxylet with many limitations. However it has allowed more interesting proxylets to be built. For example, the caching proxylet

[52] is currently being modified to use the routing proxylet. This allows it to locate an EEP close the the source web server.

The routing proxylet has an automatic upgrade mechanism. When a routing prox­ ylet performs its periodic registration with the coordinator a version number compari­ son takes place. If the coordinator is running a newer version of the routing proxylet

than the proxylet registering, then the registering proxylet loads the latest version of the

proxylet. This automatic reload mechanism has allowed us to upgrade the implemen­

tation of the routing proxylet. It automatically deploys across all running EEPs. As we develop more scalable solutions they will be trivial to deploy.

5.6.2 Error Handling

As stated earlier a proxylet is a fire and forget entity. Therefore if debugging or error output is generated from a proxylet there is no obvious place to send the output.

Currently any output generated by a proxylet is multicast at a site wide scope. An application is provided to print out the error messages. This allows “local” proxylets

to be debugged. However currently there is no way to retrieve error messages from remote sites. A system proxylet has been provided for error handling which currently does nothing. Eventually we intend to use it to return error messages from foreign sites. As with the routing proxylet, this will be deployed automatically as it becomes

available.