Resource concepts in more detail

This section and the next four deal with deeper resource issues in case we want finer grained allocation. See Figure . However, be warned: this is a complicted area, and almost everything we need has already been covered. The first-time reader is very strongly advised to skip all this and go straight to Section . Go now.

Figure: Resource concepts and how they relate.

Resource instances

A resource instance is a particular resource earmarked for a particular application. At any one time it may be connected to a particular node. However, just because a resource instance is contracted to a particular application and connected to a node it does not imply that any of the application's netlets are running on that node at that time, let alone using it. It may be waiting for a first netlet to start up and start using it. Or the last netlet might have died, so it will be waiting for another one from the same application to start and pick up where the last one left off.

Examples of resource instances are: 1MB of disk space; 10TB of triply-redundant disk space; a socket factory which can generate sockets listening on port 80; a socket factory which can generate sixteen sockets on ports higher than 1023; a socket factory sitting behind a redundant load balancer; a CD-ROM containing the names and phone numbers of everyone in the San Francisco Bay Area. In fact, anything can be a resource.

Resource classes

Resource instances of the same kind are gathered into resource classes. For example, if a hosting service has 2000 little 1MB disk areas then they may all appear in the same resource class.

Each resource class is characterised by two things: resource-specific properties, and what facets it supports.

For example, a file system resource class should support the IFileSystem facet. But beyond that it may have properties such as kilobyte size and redundancy.

On the other hand, a socket factory resource class should support the ISocketFactory facet. But kilobyte size is meaningless to a socket factory. Instead it may have properties describing what port range it supports.

The node's administrator can choose to classify their resource instances how they like. Suppose the administrator has 65535 socket factories, each of which generates a socket on one particular port. There may be one resource class encompassing all these factories, in which case the properties will describe ``a socket factory which can generate one socket''. Or there may be 65535 resource classes, in which case the properties will describe ``a socket factory which can generate one socket on port X'' where X is different for each resource class.

Selecting resource classes

When a Beatrix manager asks for a resource for an about-to-be-started worker it does not ask for a particular resource instance or even a particular resource class. Instead it asks for all classes which exactly match particular criteria, and then sorts through those by hand. For example, suppose Beatrix wants to find a triply-redundant file system with at least 10MB. It would say ``Give me all classes which support IFileSystem and which have redundancy property equal to three''. When it gets (say) ten resources classes back it examines the properties of each until it finds those with disk space property equal to 10MB or more. (It would be advised to choose the class with no more space than necessary, otherwise it may find it is paying over the odds.) If it doesn't find anything suitable it can try another tactic.

Resource handles

Any worker netlet which uses resources will most likely have several requirements: some disk, some sockets. So when a manager has found all the right resource classes (suitable disk space, suitable socket factories, and anything else) it bundles them all up into a resource handle. Each resource handle needs a unique resource label. A resource handle is also called a resource for short.

Figure: How resource classes and instances and bound to resource handles.

[The resouce handle, before resource instances are allocated]

 

[The resource handle, after resource instances are allocated]

Resource binding

The process of bundling resource classes into resource handles is called binding resource classes. See Figure . Since there are several bindings within a resource handle we need to set a binding label for each one to distinguish them. In our skeleton example we label the disk binding disk and the socket factory binding net. Beatrix then takes this resource handle and finds a node with resource instances matching the resource classes, contracts them and starts the worker.

When the worker netlet starts up it can bind these resource instances using the same binding labels. Then it can use them. This is the code in Section  above.

Releasing resources

Once we are finished with a resource handle we can release it. Then the hosting service can clean and remove all its resource instances and allow other contracts to create new instances in their place. If we don't explicitly release a resource it stays contracted to us. This is regardless of whether or not the netlet using it terminated in a planned way.

Re-use priority

It follows from this that if our netlet did terminate prematurely then we would want to start a new one to pick up where it left off, reusing its old resources. Therefore, in binding resource classes into a resource handle we can also specify a reuse priority. This says to Beatrix ``If I had a resource instance from this class before, try to give me the resource handle with that same resource instance again''. This is how we can pick up from where old netlets died prematurely.

For example, if we are running a DNS service then any worker might need a socket factory and some disk space. If a worker died we would want to restart another one. But we would want to prioritise reuse of our old socket factory, because all our clients are expecting us to be listening on that address. We can live without the same disk space, because we can replicate our domain name database from another worker.

Fresh resources

If a particular resource instance is not being reused then it is a fresh resource. The IWorkerResourceProvider can give us a list of the fresh resources. For example, suppose our application was a redundant file storage service and the disk space was a fresh resouce. We would need to bring it up to date with the latest files. However, in practice, even if we did get to reuse previous disk space the files could have changed in between the old netlet dying and the new one starting, so we would still have to synchronise it in our own application-specific way.

Using warrants

Finally, when a manager binds resource classes to a resource handle it can also specify a warrant. This allows the node to use an external service for the resources. The worker netlet will not know the difference. If resource classes and a warrant are both specified then Beatrix will use the warrant only if none of the resource classes could be used; if no resource classes are specified then the warrant will always be used.

So in brief summary... Resource instances are classified into resource classes. A manager netlet specifies what resource classes it wants for a worker, and binds them into a resource handle. For each binding it can specify a reuse priority to reuse old resources from netlets which have died prematurely. It can also specify a warrant to use an external service as if it was that resource instance. Either way it must specify a label. The worker will then use the same labels to bind its allocated resource instances and use them.