As discussed in section 3.0, all Legion objects are automatically assigned a unique system-level identifying name called a Legion Object Identifier (LOID). The LOID enables Legion to manipulate Legion objects scattered on different machines. But a LOID consists of several lines of numbers (shown below), making it difficult to figure out which LOID belongs to which object. From the user's perspective it is much easier to give an object a context (string) name, such as "george" or "myHost". This method of allowing objects a system-level and a user-level name allows LOIDs to hold system-level information, such as public keys, without polluting the user-level name-space.
Moreover, each user's context space is independent of everyone else's context space. So, multiple users can assign an object a different context name to suit his or her own convenience. This is discussed further in section 4.3.
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 looks like this:
The groups of numbers, separated by period, show the object's characteristics. First, the type field, 1, indicates the LOID's type. Next, the first variable field, 01, indicates the domain in which the object was created. The second variable field, 07, indicates which class that the object belongs to. The third variable field, 01, indicates the object's instance number. The fourth variable field (the last field), 000001fc0d24ab..., is the object's RSA public key. This notation is obviously cumbersome, so we expect that users will prefer 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. Each user has a personal context that can be used like a home directory. It will probably be something like /home/<your Legion id>. Ask your system administrator.
Command-line tools let you move between contexts, just as Unix commands let Unix users move between directories. Legion provides a library interface and utility commands such as legion_ls and legion_rm. The library interface provides a Unix-like path interface for expressing navigation through multiple contexts. Paths are delimited by the "/" character. For example, the path /home/fred/foo would map to /home, then /fred, then to foo.
The name foo points to an object somewhere in Legion: in Figure 3 it points to object X. Context space does not reflect or influence an object's physical location. Object X may be in the same building as Fred or 500 miles away. When Fred assigned it the context path name /home/fred/foo, the object was not moved or copied. Objects in the same context path may actually be located on different machines in different countries.
A sample context space is shown in Figure 4, below. Notice that each user has his own context space. Each context is a separate name space, so a name can be reused. In Figure 4 User1 and User4 both have subcontexts called ContextA.
A name can be used by more than one user to refer to the same or different Legion objects. In Figure 4, /home/User1/ContextA and /home/User3/ContextC/ContextC hold the name Foo but each points to different objects. Conversely, /home/User1/ContextA/ Foo, /home/User1/ContextB/Fred, and /home/User2/Bar all point to object X.
You can share your context space with other Legion users, just as Unix users can work in one another's directories. You can also protect individual objects or groups of objects against unauthorized use by a specific user/object or a group.
Beyond the user-level grouping of individual context spaces, you can link object groups in graph- or directory-based structure. Just as a Unix directory tree or collection of hypertext documents provides 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 logically start with the /hosts context, then look in /ibm, then /sp2, where a list of host objects running on SP2s could be found. This is like moving through a set of directories to get to a /hosts/ibm/sp2 directory.
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.