Legion

Worldwide Virtual Computer

Release 0 Description

12/23/96 9:27 AM

Andrew Grimshaw

1 Background

The first release of the "full-blown" Legion system is targeted for the first week of February, 1997. The exact makeup of the release has been vague. The purpose of this document is to clarify what exactly is meant by "Release 0". Subsequent documents will describe "Release 0.5", scheduled for June 1, 1997, and "Release 1.0", scheduled for October 1, 1997.

The release will consist of eight major components, the run-time library and library technical report, the core demons, a set of user-level classes, a system startup mechanism, a set of system status tools, a partially re-targeted MPL compiler, some basic security mechanism, and a description of the exception model. Below I will expand on each of these.

Note: From now on when you give me text to read, please also attach either a URL so that I can find it, or a Unix path so that I can access the soft-copy.

2 The run-time library

There are no new functional requirements of the run-time library for Release 0. What we need to do is to continue to shake the library down, and to finish eliminating the memory leaks. There are several minor items though.
a) It would be nice, though not required, if we could port the library to another system, preferably one with different data types, e.g., the X-86, and demonstrate the heterogeneity aspects of the library. This might be desirable in order to improve compilation performance as well.
b) LOID's. Today LOID's are basically string class names and instance numbers. I'd like to move to the model originally planed, i.e., with integer class identifiers. In the long run class names are just not unique, and I don't want our user community to begin to make the association. Thus, we need to make the switch, and make sure that classclass knows the mapping, and that class objects and object instances can cough up the class name on demand.
c) Next, a description of how we intend to implement multi-threaded objects. (Note: in addition to the usual threads sources, we should look at the Nexus documentation. I think that Nexus supports a thin thread layer on all platforms. That may be our best, most portable, option.)
d) Another issue is calling Legion objects from inside events, e.g., the MayI function may need to call a security service to verify that a user is allowed to make a particular call, or a debugger may wish to save a copy of the parameters to a log file. Have we tried to do something like this? Is it implemented?
e) Object-mandatory member functions. (This perhaps should fall under compiler support.) Recall that there are a set of functions that each object must export, such as "do you support this function?", and "give me a copy of your interface".
f) Implement the "pre-load" function that tells the run-time system to go ahead and start binding a particular LOID. In fact we might want a method that takes an LOID list and starts binding them.

3 The core demons

The core demons include classclass (or whatever we are calling it), BindingAgents, LegionHosts, LegionVaults, and the necessary class objects.

My understanding is that most of the basic stuff has been accomplished. There remain several things though:
a) integrate modifications necessary to support the system startup functions - more on this later
b) integrate information services functions - John's Prolog stuff, into hosts, vaults, and classes
c) a single, always up, classclass at well-known address here at Virginia
d) support for class management functions in the class objects, e.g., get interface, set interface, give me the class name, etc.

4 User-level classes

We need a description of the mechanism that should be used for now to create new classes, including issues such as adding the interface, etc. In addition there are three user-level classes that I'd like to have complete by release time, context objects, Unix file objects, and a resource database object.

4.1 Context objects

These are the core of the Legion namespace. They are described in [1]. I expect them to be completely operational, and to have a set of utility functions that permits manipulating them. Initially these functions should be along the line of ls, mkdir, etc.. Later we'll get some sort of GUI. I also think that it would be VERY nice to have a simple MayI attached that implements an access control list, and to have member functions that allow the list to be manipulated and viewed.

4.2 Unix file objects

Unix file objects are the basis of all other file objects. We will be using them extensively ourselves. Further, I expect many of our initial user community to use them as well. They should support all of the usual operations. Later we will need to address issues such as pre-fetching strategies, and alternative interfaces.

4.3 Resource Database

This will be a simple class that illustrates how user-level resource discovery databases can be constructed that use the underlying host and vault infrastructure.

5 System startup

We need a mechanism to simplify the startup/shutdown of a test system. Using K open shells, where K is some large number, is just not practical. I have spoken to both John and Steve about this. We have come up with a plan that we feel is both practical, and follows the Legion philosophy. John look here. John will put together a brief document and presentation for the second week in January and present the plan to the group. (I'm sort of hoping that it will be a fait accompli.)

6 System status

In addition to starting the system up, we need a way to query the system about its state, how many objects are running, the names of the classes, information about their instances, the hosts that are up, the vaults that are up, etc. My understanding is that much of this has been done using a web interface. Let's take a hard look at what else is needed and do it. Then, a quick 1-pager cheat sheet on how to use it.

7 Re-targeted MPL compiler

This is the component that needs the most work to be ready. Mark has recently completed a modification plan which he will begin to implement after the break . I expect that all of the features listed in the document will be available by the February release. Basically we expect to be able to take existing MPL programs and run them in the new Legion environment, and to be able to write new Legion programs using the compiler. Left unsaid is how new class objects will be created.

The release 0 MPL compiler will not support

8 Security

Security continues to be a weak point in the implementation. To my knowledge nothing has been implemented. At this juncture I do not expect to be able to implement a public key algorithm for either authentication or encryption. It is important though that we demonstrate that we CAN implement the things we have described. In particular the ability to, a) do something to the messages that emulates both encryption and signatures, b) illustrate the ability to do call-outs from the MayI to external service providers, and, c) illustrate the notion of a responsible agent.

8.1 Emulate encryption and signatures

I propose that we implement a simple Caesar cipher using the first byte of the LOID of the sender as the key. Similarly we will form a signature by forming an XOR of all of the bits with the LOID of the sender. This is, of course, not secure by any stretch of the imagination. But it will clearly show that we can place an algorithm in the communication stream.

8.2 Call-outs from MayI

A key feature of the both the security plan, and many other aspects of the system, is the ability to call external service providers when needed. Thus, we have frequently said that the MayI function may invoke an external service provider to, for example, authenticate the caller or the responsible agent. This requires us to be able to make Legion object invocations from within the event stack. We should implement a simple external provider that says "yes" but illustrates the principle.

8.3 Responsible Agents

The original security documents included the notion of a responsible agent (RA). When I'm interacting with Legion the security policies of the objects I use need to know who "I" am. My understanding is that some sort of "Legion shell" will hold my LOID and will be my vehicle for interacting with Legion. That "shell" will in turn be authenticated by an RA. We need to start thinking about this shell in more concrete terms. In particular, are we going to modify an existing shell, e.g., ksh, or will we simply place some extra fields in the environment?

8.4 License caches

Do we need license caches to implement even a simple minded MayI? I don't think so, but I need to know.

9 Exceptions

We have no exception model. We have discussed several, but have never really gelled the design. Before release 0 Anh and I will put together a white paper describing an exception model, and the support required from the rest of the run-time system. The white paper will be available for internal discussion two weeks before the workshop. That will allow us to make a determination as to whether it is the model we want to present to the outside world.

10 References

1. French, Jim, and Dave Cooper, "Context Object Design," Legion Technical note, December, 1996.
2. Hyett, Mark, "Design Change Proposal: MPL: Retarget for Legion," Legion Technical note, December, 1996.