Legion Context Space

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. The first variable field indicates the Legion domain in which the LOID was created, the second is the class identifier, the third is the instance number, and the fourth is a public key. The type, domain, and class identifier fields must be present. 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. For example, a typical LOID would look something like this:
In this LOID, 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 too cumbersome for most users to manipulate as strings, so the naming service provided by context spaces allows users to deal with objects using meaningful string names chosen by the user. This separation of concerns between system-level names and user-level names allows Legion LOIDs to contain system-level information, such as an object's public key, without polluting the user-level name-space.

More about 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. Just as a Unix user organizes files in a series of directories, a Legion user orgaizes objects in a series of contexts: a Legion system has a root context, and within that space each user has a personal root context, or home context, in which he or she works (note that a user's home context is not necessarily the sub-context called home, which is part of a new Legion system). Users can use utility commands to move between contexts, just as they use utility commands to change directories in Unix space. A sample context space is shown in Figure 1.1 Note that each user's context space is independent from other users' context, so that if User1 and User2 have each created a sub-context called ContextA, each ContextA is autonomous. Note also that, depending on individual security arrangements, a user can work in another user's home context space.

Figure 1: Context space

Just as Unix files in different directories can have the same name but different contents, different contexts can assign the same name to different Legion objects: in Figure 1 the path names /User1/ContextA/ObjectFoo and /User3/ContextC/ContextC1/ObjectFoo describe different context paths that can refer to different objects. The two users' context spaces are independent of each other, allowing the users to assign names without fear of conflict.

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

Figure 2: Context space

It is important to remember that context space does not reflect object space: ObjectX remains in its native location, regardless of any path names users choose to give it. User1 might be in the same building as ObjectX or on the other side of the country. Context space is made up of string names organized by user preference. Objects named in a single context may actually be hundreds of miles apart.

Beyond this user-level grouping, 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 for users to organize information, context space provide a structure for finding and organizing Legion objects. For example, to find a host object running on an IBM SP2, one might enter a context named hosts, then to a sub-context named ibm, and then to a sub-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_list, and legion_context_lookup for manipulating and negotiating context space. The Legion library interface provides a Unix-like path interface for navigating 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 thus map to the object named adam within the context object named usr in the current context.

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. It is important to note that this default path service provided by the Legion library is completely replaceable. For example, if a user wished 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.

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