5.0 Context space

5.1 Legion object names

As previously mentioned, all Legion objects are automatically assigned a unique system-level identifying name called a Legion Object Identifier (LOID). The LOID enables Legion to find, control, and move Legion objects scattered over several different machines. But since LOIDs consist of several lines of numbers, you can map one or more simple string names--context names--to a LOID and use that name instead.

You and other Legion users are free to name objects as you please, since your context space is independent of other users' context spaces. This is discussed further in section 5.3. The next section provides a brief look at the anatomy of the system-level object name, the LOID.

5.2 About the LOID

A LOID is a variable length binary structure (typically more than 128 bytes), which contains a type field followed by several variable size fields. A LOID may be appended with any number of other fields, each of whose size and meaning are dependent on the LOID type. LOIDs are represented as strings, using standard "dotted hex" notation. A typical LOID would look something like this:

Here the type field, 1, indicates the LOID's type; the first variable field, 01, indicates the domain in which the object was created; the second variable field, 07, indicates the class that the object belongs to; the third variable field, 01, indicates the object's instance number; and the fourth variable field, 000001fc0d24ab..., is the object's RSA public key. This notation is obviously cumbersome, so we expect most users to rely on the context space naming service to manipulate objects: this distinction between system-level names and user-level names, however, allows Legion LOIDs to contain system-level information, such as an object's public key, without polluting the user-level name-space.

5.3 Organizing context space

All contexts in Legion are organized into a Unix-like hierarchy, with a root context that contains a set of other contexts. This structure provides each object with an absolute path name (i.e., /mycontext/myobject). Just as a Unix user organizes files in a series of directories, a Legion user organizes objects in a series of contexts: you have a personal "root" context, a home context which acts like a home directory.1 You use commands to move between contexts, just as Unix users use commands to move between directories. A sample context space is shown in Figure 5.2 Notice that the different users have autonomous context spaces. This allows the same name to be used by more than one user and in more than one context. E.g., User1 and User2 can create new subcontexts and call both of them ContextA. Depending on individual security arrangements, one user can work in another user's context space just as Unix users can work in one another's directories.

Figure 5: Context space

Similarly, a context name can refer to different Legion objects, just as Unix users can use the same name in different directories to refer to different files: in Figure 5 the context path names /User1/ContextA/Foo and /User3/ContextC/ContextC1/Foo refer to different objects.

On the other hand, a single Legion object can have multiple context names in multiple contexts. Figure 6's Foo and Bar refer to a single object, ObjectX, but these names are in two different context spaces.

Figure 6: Single object with multiple context names.

It is important to remember that context space does not reflect object space: ObjectX's native location is unchanged by its context path names. User1 might be in the same building as ObjectX or on the other side of the country. Objects named in a single context may actually be hundreds of miles apart.

Beyond the user-level grouping of individual context spaces, linking object groups in graph- or directory-based structures can be useful: just as a Unix directory tree or a collection of hypertext documents provide a logical means to organize information, context space provides a structure for finding and organizing Legion objects. For example, to find a host object running on an IBM SP2, you might enter a context called hosts, then a context called ibm, then a context called sp2, where a list of host objects running on SP2s could be found (in Unix, this would be the equivalent of moving through a series of directories--/hosts/ibm/sp2--to arrive at a directory called sp2).

Legion provides a library interface and utility commands such as legion_context_create, legion_context_add, and legion_ls for manipulating and negotiating context spaces. The Legion library interface provides a Unix-like path interface for expressing navigation through multiple contexts, and Legion command-line tools support path-like naming of objects within context space. Paths are delimited by the "/" character. For example, the path /usr/adam would map to the object named adam within the context named usr.

Objects contain in their state a root context (implicitly named /) that provides each object with a base for absolute path names. The root context's LOID is stored in a variable that can altered by the object at runtime. Objects also contain in their state the current context's LOID, which provides the basis for relative context paths.3

1.The home context being discussed here should not be confused with the sub-context called /home, one of the four basic subcontexts provided in a new Legion system.

2.There is another context that represents the user's shell, but it does not appear in object path names nor does it affect your movements in context space.

3.The default path service provided by the Legion library is completely replaceable. For example, if you wanted to manipulate context spaces via DOS-style "\" delimited path names the service could easily be implemented using the primitive context manipulation routines provided by the Legion library.

Directory of Legion 1.6.3 Manuals
[Home] [General] [Documentation] [Software]
[Testbeds] [Et Cetera] [Map/Search]

Free JavaScripts provided by The JavaScript Source