Global Namin-g in Distributed systems

Transcription

1 Global Namin-g in Distributed systems Ronald Curtis and Larry wittie State University of New York at Stony Brook This Unix-based global naming system, developed for debugging distributed programs, provides concise notation for accessing networks, tasks, modules, data, and files. BugNet1 is a debugging system for distributed applications software. Although developed for Modula-22 programs and written in that language, BugNet techniques apply to other languages. In particular, its uniform naming mechanism can be used for many languages under many distributed operating systems. One goal of our research has been to ease the task of porting the debugging system by making the naming scheme independent of the notation of any single operating system or language. Although originally intended for use within a distributed system debugging tool, the notation can provide global naming from programs. A consistent, portable mechanism for naming allows a single, user-level name space interface to exist on multiple independent systems or on systems that support multiple languages. BugNet is part of the Micros3'4 project. Micros is a distributed operating system to control large network computers consisting of thousands of processing nodes, each of which has direct access to at least two of a plexus of buses. The current configuration includes LSI-1 1 and M68000 nodes, each connected to two Ethernets. Vax nodes will soon be added to the network. Unix-based approach File names in Unix. The naming mechanism developed for distributed systems is based on file specifications in Unix. 5 The Unix system provides a hierarchical directory structure with files at the tree leaves and a syntax that allows references to all items in the tree. A directory can include other directories and files, for example, paper in the sample structure given in Figure 1. A special directory, called root, at the top of the tree structure has a nil name; an initial slash (/) refers to this directory. At any time, the user is in a current, or working, directory from which he can refer to local items directly. When a user logs into a Unix system, the initial working directory is the default, or home, directory. The user can refer to this directory with a tilde (-); others would use the tilde plus the user's ID (- ID). A slash can be concatenated after any directory name; it is required when other names follow. The user can refer to other items by giving path names. A full path name starts at the root and lists all directories down to the desired item- /uh/micros/curtis/paper/conf/ Demo, for example. A list of directories separated by slashes is used to access items below the current directory. For example, the file Demo can be referenced from the home directory curtis by paper/conf/demo, from the paper directory by conf/ Demo, and from the conf directory as Demo. Partial names can start at a user's home directory. For example, -curtis/paper/conf/demo can be used from any account, but -/paper/ conf/demo can be used only from the curtis account. Unix provides a mechanism (../) for accessing levels above the current directory. If the current directory is /uh/micros/curtis/paper/letters, the Demo file can be accessed by using../conf/demo. Multiple../s can be /84/0700/0076$ IEEE

2 concatenated to access items at higher levels. Unix provides a simple notation to access items at the current level, at the system level, at the user's home level, at lower levels, and at higher levels. Naming in distributed systems. In traditional languages, naming is weak for nonlocal items. Block structured languages make it difficult to develop a code unit that can access global task data from any location in a large system. The problem arises because an item of data with the same name might exist in an enclosing unit, effectively barring access to a more global item. One goal of this research is to provide a single, unified mechanism for accessing local, nearby, and global items. Distributed systems complicate matters by adding network and task-level names. Names appear at many levels in distributed systems, but serve three basic functions. First, names are required for access to parts of the control structure, such as routines in the operating system or procedures within a distributed program. Statements within a single code component might need access to one another. Second, names are required for access to elements of the data structures of a distributed application. Since accesses to shared data are common in distributed programs, a simple mechanism should be available to carry them out. Third, names are required to access systems in external networks. Related research. A similar uniform notation is being developed for naming in Basix,6 a Unix-based language. Basix is being developed for the Newcastle Connection,7 a hierarchical connection of Unix systems. It will be an object-oriented interactive language with a programming support environment. Basix has a concise notation for local objects (.), parameters ($), previous level (..), and the directory of a program (/). Compared with Basix, BugNet notation provides greater ease in naming at multiple levels in a distributed system. Unlike Basix, BugNet local names do not require a prefix symbol. Since parameters are treated as local names, they require no special notation. The BugNet notation allows access to multiple context levels: network, task, module, data, and file. There is a concise notation for three special contexts at each level. Another BugNet goal is to provide a notation that can be applied to many languages running under many different operating systems. Compared with Basix, BugNet notation provides greater ease in naming multiple levels in a distributed system. BugNet naming mechanism Naming is hierarchical in many distributed systems. There is always a top system level. Many system levels can be above the top user level, and the user can have many lower levels. A variation on the Unix file name convention for naming entities can be used within distributed systems. Within this variation, there is always a local context for any computation. It is standard to refer to items local to the current context by names alone. A slash denotes the highest possible bin/ uh/ Figure 1. A Unix directory structure. vlsi/ micros/ curtis/calendar debugger/ mod2/ paper/ HEADER WORD letters/ thesis/ conf/ Demo RTOS July

3 Table 1. Structural isomorphisms in distributed systems. ROOT HOME GROUP OF TYPE NAME ELEMENT ELEMENT ELEMENTS ELEMENT SYMBOL NETWORK HIGHEST LOCAL NETWORK SYSTEM n NETWORK NETWORK SYSTEM SHELL PROCESS t MODULE PROCESS PROCESS MODULE PROCEDURE m FILE ROOT HOME FILES f DATA SYSTEM SHELL DATA d Table 2. Structural isomorphism between tasks and Unix files. SYSTEM SHELL PROCESS ROOT HOME FILE Table 3. Structural isomorphism between modules and Unix files. PROCESS ROOT PROCESS HOME MODULE PROCEDURE FILE 78 entity of a complex name, or "name path." A tilde refers to the user's default level. The../ notation provides access to levels above the current context. Parameters for BugNet commands have different types, such as task and data. Normally, names and the special context symbols (-, /, and..) are interpreted in the context of the parameter type. If names and context symbols are to be used at other levels in composite path names, the items must be prefixed by a type indicator. For example, the name [t]/ refers to the top system task. Individual type indicators are explained below and are summarized in Table 1. A type prefix is often needed to clarify root and home contexts, since they are available for several types and component levels. However, an explicit type indicator is not needed for unique names within a known context, since local name searches are performed. Naming for control structures We assume a distributed operating system supports task groups. A task group consists of multiple tasks, which might run on separate processors. A task consists of multiple modules running on the same processor. Under this system, the user should not have to specify physical connections among processors. Within the system, control structures can be referenced on the task or module level. Task level. Debugging in a distributed system requires a global naming mechanism for access to the tasks and processes. Table 2 gives the naming correspondence between Unix files and task structures. The root maps to the operating system task; the home directory maps to the highest-level task for the user. An operating system consists of a task that provides many subtasks, such as file and communication servers. The operating system can start tasks that interact with user terminals or execute user programs. The shell task that interprets commands to start user programs corresponds to the home directory. The user or the program can start subsidiary tasks, which finally resolve into processes at the leaves of the task control tree. Under this scheme, a task is accessed by its name or by [t] followed by its name. The name with the prefix [t]/ refers to a task created by the operating system task. For example, the system task filer is named [t]/filer. A nested task is named by prefixing the names of its ancestors, which are separated by slashes. For example, a task open in the system filer task is named [ti/filer/open. Any task has a full path name, starting from the nil named system task I. The user's shell task is accessed as [t]. Task groups decended from it can be accessed by prefixing the name with [ti-/. For example, if task donow is created by the user, it can be

4 referenced within any task descended from the user's shell as [t]-/donow. A task can refer to its parent task as [t]../. The notation can refer to sibling tasks under the same parent. Tasks defined on even earlier levels are accessed by repeating the../ portion. The task notation allows references to system tasks (/), nearby tasks (../) and shell tasks (-/). Module level. For naming purposes, any program unit that allows only one locus of execution at a time is a module. We assume that program units have unique names, which can be composites. For example, there might be several started instances of a Modula-2 process. The composite name for each instance would consist of the process type name plus an index. A module can be a process, a procedure, or a scoping unit such as a module in Modula-2. As Table 3 shows, module names also form a hierarchy. For modules, the containing process corresponds to both the root and home for files. Specifying a procedure in another task requires concatenating task and module notations. For example, the procedure dowork-in the process supervisor, in the task now, spawned by an independent user task donow, started from the user shell task group for account test-can be accessed by [t] -test/donow/now/im]supervisor/dowork, a path name that starts at the shell task. If supervisor is a unique name in now, the module indicator can be eliminated, giving [t] -test/donow/now/supervisor/dowork. Naming for data structures and files There are two reference levels for data structures within a system. Users can access data items by their location in a task tree or in a module. In both cases, the name is created by concatenating [d] and the data name to the name of a task or module. Most data references are to local data, data in an enclosing unit, or to global data. Local data can be accessed directly. Except for a final entry that maps data to files, the structural isomorphism for naming data items is the same as that for naming tasks (shown in Table 3). The mechanism for referring to data in a task is similar to that for referring to a task-a list of task names separated by slashes. The only difference is that the data type indicator, [d], is used before the data name, which ends the sequence. The abbreviations for root and home tasks are still used. For example, if the highest-level system task provides a data item numberofusers, it can be referenced as [t]/[d] numberofusers. Since the task hierarchy forms the upper part of the data hierarchy, [d]/numberofusers is equivalent. The mechanism for naming files is identical to that of Unix. Similarly, It]-! allows tasks to access data in the shell task that creates them. For example, if a shell task has a data item answerfound, all descendents of the shell task can refer to the data as [t]-/[d]answerfound. Similarly, [t]../[d] can be used by a group of subtasks to refer to data in the task directly above them. References to data within modules are similar. One can refer to data contained in an enclosing module by using [m]../ before the local name. For example, a variable xflag in an enclosing procedure would be referenced by [m]../[d]xflag. Data global to the process can be referenced by using [m]-/. For example, reference for the global flag devicebusy would be [m]-/devicebusy. The module using the data need not know the name of the enclosing process. This notation aids the development of module libraries. A procedure can access the data item busyflag in process devo under shell task temp by [t] -temp/[m] devo/[d]busyflag. Since good style dictates that the same name not be used for separate task, process, and data items, the shorter name [t] -temp/devo/busyflag-is usually adequate. The mechanism for naming files is identical to that provided by Unix. The file type indicator [f] allows construction of composite names involving files. For example, [t]test/ [f]demo provides access to the file demo in the current working directory of the task test. Naming for network structure Today, many systems are parts of networks. The BugNet notation can be extended to indicate networks by means of the symbol [n]. A network nl is accessed from any system connected to it as [n]nl. The notation is similar to that of the Xerox Clearinghouse,8 an agent for supporting distributed naming on networks. Systems connected to only one external network can access it as In]-/. In general, network interconnections form a graph instead of a tree. By starting at [n]-/, a connection path to another network can be given. For example, assuming the interconnections in Table 4, a system within nl can access node n3 by [n]-/n2/n3, [n]-/n4/n3, [n]nl/n2/ n3, or [n]nl/n4/n3. In hierarchical networks, [n]/ refers to the highest-level network. The notation developed for tasks and modules can be concatenated to the network notation for interactions among systems. For example, the open task of the filer server on network nl can be accessed from n3 as [n]n3/n2/nl/it]/filer/open. Table 4. Network interconnections. nl n2 n3 n4 nl YES YES NO YES n2 YES YES YES YES n3 NO YES YES YES n4 YES YES YES YES July

5 Extensions Our notation allows any code unit to name any data or code item in the system. An operating system should not provide this freedom universally, though a system debugger needs such flexibility. However, a debugger operating on behalf of a specific user should be limited to accessing items in the name space of that user. Protection mechanism. We are investigating a protection mechanism based on the Unix method of read, write, and execute permissions for files. It will allow assignment of access privileges at any level in the network-task-module-data tree. Naming mechanism. We are also studying several extensions to the naming mechanism. Some path names might become too long. The BugNet debugger allows the user interactively to change the current context, thus shortening names. The command is similar to the Unix change directory (cd) command. In many instances, however, it is impossible to find a context in which several important entities in different task groups all have short names. An abbreviation method is needed. The notation should also be able to specify individual statements within control structures, to allow debugging changes to force transfers of control. Names for statements can be qualified by the names of the routines and loops in which they are embedded during execution. The../ notation can provide a single mechanism for leaving routines and loops, without requiring GOTOS or labels. Exception-handling routines can use this mechanism to access items available only in the original exception context. Acknowledgments This work has been supported by National Aeronautics and Space Administration grant NAG-1-249, Army Research Office contract DAAG K-0103, an external research grant from Digital Equipment Corporation, and National Science Foundation equipment grants MCS and MCS References 1. R. Curtis and L. Wittie, "BugNet: A Debugging System for Parallel Programming Environments," Proc. IEEE Third Int'l Conf. Distributed Computer Systems, Oct. 1982, pp N. Wirth, Programming in Modula-2, 2nd edition, Springer-Verlag, New York, L. Wittie and A. van Tilborg, "Micros, A Distributed Operating System for Micronet, A Reconfigurable Network Computer," IEEE Trans. Computers, Vol. C-29, No. 12, Dec. 1980, pp L. Wittie and A. van Tilborg, "Operating Systems for the Micronet Network Computer," IEEE Micro, Vol. 3, No. 2, Apr. 1983, pp Ronald S. Curtis is working toward a PhD in the Computer Science Department of the State University of New York at Stony Brook. His research interests include distributed debugging, distributed programming languages, and software development support environments. From 1979 to 1983, Curtis was chairman of the Computer Science Department at Canisius College, Buffalo, NY. Curtis received the BA degree in mathematics from Keene State College in 1972 and a MSc degree in mathematics from the University of New Hampshire in He is a member of the IEEE and the Computer Society, ACM, and Kappa Delta Pi. 5. D. Ritchie and K. Thompson, "The Unix Time-Sharing System," Comm. ACM, Vol. 17, No. 7, July 1974, pp I. Lima et al., "Decentralized Control Flow Based on Unix," Symp. Programming Language Issues Software Systems, SigPlan Notices, Vol. 18, No. 6, June 1983, pp D. Brownbridge et al., "The Newcastle Connection or Unixes of the World Unite!" Software-Practice & Experience, Vol. 12, No. 12, Dec. 1982, pp D. Oppen and Y. Dalal, The Clearinghouse: A Decentralized Agent for Locating Named Objects in a Distributed Environment, Xerox technical report OPD-T8103, Palo Alto, Calif., Larry D. Wittie is an associate professor in the Computer Science Department of the State University of New York at Stony Brook and previously taught at Purdue and at SUNY/Buffalo. He is interested in the organization of large distributed systems, including portable operating systems and debugging systems for network computers. Wittie received his PhD degree in computer science from the University of Wisconsin at Madison in He is a member of IEEE, ACM, the Society for Neuroscience, and Sigma Xi. The authors' address is Computer Science Department, SUNY at Stony Brook, Stony Brook, NY