CA2082870C - Name resolution for a multisystem network - Google Patents

Abstract

A unique naming system and method are described for managing object identification by a network of computer systems. The naming system employs data structures stored in the memory of the computer systems containing character strings and corresponding addresses to entries in the data structures and objects in the computer systems. Names employed in a particular computer system that correspond to objects in another computer system are resolved by a border data structure capable of transforming names, delimiters and visas across computer systems.

Description

AT9-92-007 1 ~ 370 NANE RESOLUTION FOR A MULTISYSTEM NE:TnORK
Field of the Invention Thi~ inver,tion generally relates to improvements in computer systems for network environments and more particularly to uniquely defining resource names in a flexible manner.
Bac:k~J.uu.ld of the Invention Name resolution is a fundamental function required to access operating systems and network objects such as hosts, printers, files, and mailboxes. Each object i8 usually known to its users by a name, and to t~le system supporting it by an object identifier called an address. A naming system resolves the names for objects it supports to addresses. The set of names constitute the naming space, and the set of addresses constitute the address space for that system.
Some examples of existing naming systems are the UNIXIM file cystem discussed in D Ritchie, K. Thompson, The UNIX
time-sharing system, Communication ACM, 365-75 ( 1974); the domain name server discussed il~ F. Mockapetris, Development of the Domain Namillg System, ACM, 123-33 (1988~; profile naming system discu~sed in L. Peterson, Tlle Profile Naming Service, ACM Transactions on Computer Systems 6, (4), 341-64, (1988); and the Global directory server discussed in B. Lampson, Designing a Global Name Service, ACM, 1-10 ( 1986 ), Each of the systems listed above have a specific synta~ for names and a resolution mechanism which resolves those names to addresses. Generally, names in a hierarchical name space consist of the multiple component_names separated by delimiters. Names in attribute-based name spaces contain <attribute_type = attrikut e_value? pairs as discussed in Comer, Douglas E. and Peter~on, Larry L.; Understanding Naming in Distributed Systems, Distributed Computing, pp.
51-60 (1989). The resolution mechanisms in all of these . . . ~

~ AT9 92 007 2Q~371) systems are dependent on the specific name syntax, and while all resolution mechanisms resolve a name to an address, current naming systems must support additional functions and flexibility in name interpretation to support emerging naming standards such as X. 500 .
Other examples of prior art systems for identifying computer resources a re disclosed in US Patent 4, 914, 571 entitled Locating Resources in Compute1- Networks; and US Patent 4,825,354 entitled Method of File Access in a Distributed Processing Computer Network. Examples of earlier rlame processing system work by the inventors includes EP
260458-A, entitled Operating System for Networking Processor - i8 arranged to recognize network architecture required for extended device file call; and EP 204994-A, entitled Generalized directory data model - Stores in data-base mapping of information related to names etc. with search and update controlled by algorithm, US Patent 4,644,470 and US 4,718,005 also discuss techniques for uslng alias names to facilitate communication over a common user network. However, none of the prior art techniques provide a fl~xible system and method for accommodating name resolution i~l accordance with the subject invention .
Sunmlary o the Invention Accordingly, it is a primary object of the present invention to provide an improved system and method for constructing and resolving resource names in a naming system.
These and other objects of t~le present invention are accomplished by one or more computer systems under the cooperation and control of a naming system. The naming system employs data structures stored ill the memory of the computer systems containil~g character strings and corresponding addresses to entries in the data structures and objects in the comp~lter systems. Names employed in a particular computer system that correspond to objects in _ _ _ _ . , .. . , .. _ .. _ .. .. , . . _ _ Z~
another computer system are resolved by a border data structure capable of transforming names, delimiters and visas across computer systems.
Different naming systems can reside on a single computer system. Eor example, a computer system can contain a file system with a specific naming syntax and a database system witll a different naming syntax. The present invention constructs and resolves an object name containing syntax for both naming systems. This capability allows a database to exist as a special file in the file system and a database record to be accessed from a directory in the ile system.
Brief Description of the Drawings Figure 1 is a block diagram of a personal computer system in accordance with the subject invention;
Figure 2 depicts a network of Figure 1 workstations connected together via a commullication adapter 34 in accordance with the subject invention;
Figure 3a is a diagram of a p~one system depicting an address space similar to comp~lter system addresses managed in accordance with the subject invention;
Figure 3b is a representation of ~ naming system consisting of four components in accordance witll t~le subject invention;
Figure 3c is a representatio~l of a name space N in accordance with the subject invention;
Figure 4 illustrates a data structure for resolving names in accordance with the subject invention;
Figure 5 is a flowchart of absolute name construction in accordance with the subject invention;
Figure 6 is a flowchart depicting the detailed logic associated with construction of a relative name in a _ _ . , , . . . , ... . . . .. _ . . ... . ... . ..

AT9-92-007 4 Zt~2~ 70 hierarchial name space in accordance with the subject invention;
Figure 7 iY a flowchart of tlle detailed logic asYociated with conYtruction of a name in a single name space in accordance with the subject invention;
Figure 8 is a flowchart of the detailed logic for construction of a cascaded name in accordance with the ~ubject invention;
Figure 9 is a flowchart depicting tlle detailed logic of a resolution function for one name space in accordance with the subject invention;
Figure 10 is additional detailed logic used in con~unction with the logic discussed relative to Figure 9 in accordance with the subject invention;
Figure 11 is a data structure representation of a lookup table as discuYYed in tlle detailed processing of Figure 9 and in accordance with t~le subj ect invention;
Figure 12 illustrates a data structure for resolving cascaded names in accordance wit~ e subject invention;
FigureY 13, 14 and 15 are flowcllarts setting forth the detailed logic corresponding to resol~ltion of cascaded names in accordance with the subject invelltion;
Figure 16 is the detailed logic associated with the border function in accordance with the subject invention;
Figure 17 and 18 are flowc~lartY depicti}lg the detailed logic of the extended name resolution for a single name space ln accordance wlth the subjec~ invention;
Figure 19 is a flowchart depicting additional detailed logic of the extended name resolution for a single name space ln accordance with the subject invention;

-z~æ~() Figure 20 is a flowchart representing t~le detailed logic of a border function in accordance with the subject invention;
and Figure 21 is a drawing of a border table data structure in accordance with the subject invention.
Detailed Description Of The Invention The invention is preferably practiced in a representative hardware environment as depicted in Figure 1, which illustrates a typical hardware configuration of a workstation in accordance Witil t~le subject invention having a central processing uni t 10, such as a conventional microprocessor, and a number of other units interconnected via a syFtem bus 12. The wor}~station shown in Figure 1 include~ a Random Access Memory (RAM) 14, Read Only Memory (ROM) 16, an I/O adap~er 18 for connecting peripheral devices such as disk units 20 and tape drives 40 to the bus, a user interface adapter 22 for connecting a keyboard 24, a mouse 26, a speaker 28, a microphone 32, and/or other user interface devices such as a tOUC~l screen device (not shown) to the bus, a communication adapter 34 for connecting the workstation to a data processing network and a display adapter 36 for connecting the bus ~o a display device 38.
Figure 2 depicts a networl~ of Figure 1 workstations connected togetiler via t~le comm~ ication adapter 34. Each workstation has a naming system, and eac~l of the workstation links is referred to as a name border. Name borders can be used in resolving names that span two or more name spaces, possibly in a distributed computing environment. A name border between two name spaces isolates the needed information to link the two name spaces wllile preserving the autonomy and independence of each name space. Formal defini~ions are presented for such concepts as names, addresses, llame spaces, and resolution functions. A
detailed implementation of a name border is given with an example of a name that spans m~lltiple name spaces, and a _ _ _ _ . ... .. .... .

AT9-92-007 6 ~Q~ 370 disclosure discussing how to resolve t2le names using name bo rder s .
Name resolution is a fundamental f~ ction required to access operating systems and network objects such as hoGts, printers, files, and mailboxes. Each object is usually known to a user by a name, and to the system supporting it by an object identifier called an address. A naming system resolves the names for objecta it supports to addresses.
The set of names constitute the naming space, and a set of addresses constitute the address space for that system.
Examples of existing naming systems are: a Unix file system, a Domain Name Server (DNS), prof ile naming sy~tem, a Universal Directory Service (UDS), a2ld the global directory server. Each of t21ese systems have a specific syntax for names, and a resolution mechanism w2lich resolves those names into addresses. Generally, name3 in a 2lierarchical name space consi st of the multiple component_names separated by delimiters. Names in attribute-based name spaces contain pairs. The resolution m~challisms are dependent on the specific name syntax, and whiLe all resolution mechanisms resolve a name to an address, some are designed to support additional functions and flexibili ty in how they interpret names .
Two major problems arise when tl~ying to access an object whose name contains component_21~mes from multiple ~Lame spaces, each supported by ~ different naming system, possibly with a different naming syntax, such as a file on a remote host. The first problem is ~IOW to construct such a name, with potentially conflicting syntax between its components. The second is how to resolve it.
Consider a remote file example. File names in a Unix file system are defined by a pathname ~/dirl/dir2/file>, and host names in DNS have the syntax <host.domainl.domain2.topdomain~. A remote file's name should contain component_names wi th the above two syntaxes .
The second problem, name resolution, is compounded by the fact that most naming systems are integrated in servers ... . .. _ .... ..

7 z~82~370 which provide other services. A file ~ystem provides security checks for user permissions to access files and resolves a file' 8 name to an identifier. The domain naming aystem maps a host name to an address along with the system routing function for delivering messages to that host.
Numerous distributed applications and naming systems exist, each with a special approach to handle t~le above problems.
For example, the DNS naming system reserves a plurality of characters to isolate name compQnentS that can be resolved by DNS from t~lose that can't. The reserved character ":"
separates a domain name of ~ host from an object' 8 name on a specific host. The name ~local_part: domain_name> states that the "domain_name" is to be resolved by DNS to a host address, while "local_part" is to be resolved by that host.
Also, mailboxea are identified as user@domain, or in general, local_part~domain. This approach, however, re~auires that the isolation character is reserved in both name spaces. Another approach is to map a name format from a name space to another by a gateway between the two name space 8 .
The invention discloses a llew ~ystem and method for constructing and resolving names acros~ m-lltiple name spaces called Cascaded Names.
Obiects, Systems, and Addrease~
A system is defined as a finite set of objects. The objects in a system have disti~lct identifiers called addresses. An object can exist in more than one system, but it has an address for each system in whic~l it exists. Addresses must be unigue within a system, and addresses of the same object in different systems may or may not be different, but addresses of different objects in the same system are different. For example, a partic~llar display adapter 36 in the workstation shown in Figure 1 has a unique address in Figure 2 for system 220, system 240, system 260 and system _ . _ .. . .. . .. .. .

AT9-92-007 8 ;~ 32~70 A system can also be an object in a larger system, in which case the 3y3tem ha3 an address in that larger 3ystem. For example a host system may have many irldividual wor}{stations attached to the host system Wit~l each work3tation comprising an individual system. A system that is not an object in a larger system is called a root system. In Eigure 2, each of the work3tation3 220, 240, 260 and 280 are root systems.
Root systems have distinct addresses and multiple root systems can exist. DNS and X. 500 are examples of individual root systems.
An absolute address of an object is defined recursively as follows. If an object is in a root system, t~len its address is an absolute address. If tlle object is not in a root system, then its absolute address is defined by the absolute address of that system, concatenated with the objects address in the system. The term address denotes an address of an object within a system. The absolute address of an object will be explicitly specified when used.
Consider a phone system in t~le USA as a root system. This system consist3 of different area 3ystems Each area system in turn consists of district systems, and each district system consists of a large nulnber of p~lones. A diagram of the phone system appears in E igure 3 . The pllone system has an address consisting of tlle siIlgle digit "1" called the USA
phone system code. Because area systems are objects in the same phone system, they have distirlct addresses, called area codes. Each area code 300 and 304 is a string of three digits. District systems t~lat belong to the same area system have distinct addresses, called district codes 312 and 320.
Each district code is a string of three digits. Similarly, phones that belong to the same district system have distinct addresses, called phorle codes 340, 342, 344, 346, 348 and 350. Each phone code is a string of four digits. The absolute address of a p~lone, called the phone number, is a concatenation of the following addresses:
o the USA phone system code ( 1 );
o tlle area code of the area system w~lere the phone resides;
_, _ _ _ _ _ _ _ . , ... , ... . .... . . _ _ AT9-92-007 9 ZQ~
o the district code of the district system where the phone reside#; and o the phone code.
Figure 3b i8 a representation o a name space N. The name ~pace is represented by a directed grap~l. Each node in the graph is connected to one or more nodes by a directed edge, and is defined by a component_name called c_name. One node in the graph is denoted as "root" and ~las a <null~ c_name.
Figure 3c represents a naming system consisting of four components. The four components are: a name apace, which is a set of names of the objects supported by a system, a character domain that defines t~le set of characters allowed in a user defined name, and t~lose reserved by the system.
The re~olution function resolves a name defined over the character domain to an address of an obj ect in the address space .
NamiJIg Systems In this ~ection, we introduce a formal definition of naming systems. Components of a naming system are defined, and the function of each of them in the system is discussed. Naming 3ystems are u~ed to identify a set of objects via a pre ~pecified interface. A naminq system consists of four components:
1) an address ~pace;

2 ) a character domain C;

3 ) a name space N; and 4) a resolution function R.
The components of the naming ~ystems are illustrated in Figure 3b and defined as follows. An address space A i3 a set of addresses for objects defilled ill the naming sy~tem.
Each naming system defines two mt~tually exclusive sets of characters: a re~erved set of characters, called the character domain, C, w~lich is used by the system for constructing and resolving names, and an available set C' _ _ _ _ _ _ _ .. . .. . .. . ... , , ., _ . ..

AT9-92-007 lO Z~)8;;~7~) which can be used in user defined components of the object names. A name space, N, is defined as a directed graph as illustrated in Figure 3c. Each node is labelled by a finite string of characters called a component name, c_name, which identifies the node. One llode in tl~e graph, the root, has the empty string as a component name. For other nodes, component names are finite, non-empty string of characters over the allowed character set C'.
Construction of a Name A name from a name space i6 a fini te set of characters. An absolute name of a node n in a llame space N is defined a8:
a_name~n) = ~del><c_namel><del~'c_name2> ...
<del><c_namen>
where:
c_name1s are the labels of all nodes in the path from the root node to node n in N.
A Relative Name of a node ll from another node m is defined aB:
r_name(m,n) = c_name(m+~ e1.~c_name2> ..
<del><c_namen~
whe re:
m and n are nodes in a name s~ce N, and <n_name(m+i)>
are the labels of all nodes in the path from node m to node n in N.
Note that an absolute name in t~le name space corresponds to one node in the graph. Also, two names are equivalent if they correspond to the same node. We refer to a name of either type simply as name, e~ccept when t11ere is a need to address issues specific to one of them.
A homogeneous name is a name constructed from component names ~c_names) separated by delimiters, ~uch that c_names are elements in one name space N, and the delimiter ~del> is an element of a reserved character set for a naming system _ _ _ _ ~ .. ..

~ AT9-92-007 11 2C;)~
S. Homogeneous names are resolved to addresses by the resolution function R o S.
Resolution Function For a namin~ system, the resolution function R takes two arguments: an absolute name aIld R relative name (which can be the empty string), and it returns an address. R is defined as follows:
R (a_name(m), r_name(m, n)) = addres~(n) if a_name~m) and r name(m, n~ are names in N

= undefined otherwise. ~here address(n) is the address of node n in address space ~.
R resolves a name to an address in the same naming system.
R depends on the character domain of the naming system.
Specifically, it recognizes a special character, the delimiter ~del>C which indicates the ~nd of a c_name.
Examples of common naming systems are file systems and host names in a network such as the dolnain name server. In DNS, R
takes a path in the format ~host . domain. top_domain> and returns an a host address. In UNIX-like file systems, R
takes an absolute name 8~C~I as /~l~r/lpp and a relative name dir/file and returns a file ~landle (address) for the ile /dirl/dir2/file. In I)OS and OS/2 file systems, an absolute name of a file takes the format ~drive: ~dir\file>. In this case, the character domain ~las two separator6, ": " which indicates the end of a drive name, and "\", that separates other c names .
Ca~caded Names The previous disc~læsion has been limited to constructing and resolving homogeneous names that have c_names in the same naming system. Often, however, one needs to access an object which cannot be identified by a homogeneous name such as a -12 ;~ 32870 file or a user' s mailbox on a remote host, possibly on a different network. In this case, t~e 11ost name and file name are in different naming systems.
Assume that a name contains c_names from different naming systems S1 and S2, with delimiters 'dell> and <del2>, and resolution functions Rl and R2 respectively. When resolving such a name, three problems arise:
1) how to detect the end of a c_name;
2 ) which character domain should be used; and 3) which resolution function: R1 or R2 is used to resolve the name?
Note that <del2> may not be an element in C1. Thus, <del2>
may appear in a valid node name, c_name, in S1.
Numerous distributed applications exist, each with a special approach to handle the above problems. For example, the ARPANET internet domain na~e servers recognize two special characters: the " . " and "@" . Servers accept names with the following format:
name = local_component @ host . domain where the character string o~l t~le right side of the @
indicates a host name in the domain naming system, and the string on its left is a local component of the name, to be resolved at that host. Other reserved character in S network applications use different characters to identify the boundaries between naming systems such as the ": " and the 110~11 Problems will also arise in heterogeneous distributed file systems. Consider the case w~lere a user of a UNIX-like operating sy3tem requires access to an OS/2(iD (or DOS) directory. The convention~l Unix approach is to create a stub directory, and moullt the OS/2 directory (or the drive containing it) on that stub. Let:
a_name(stub) = /u/user_id/st~lb ~ AT9-92-007 13 2~
be the absolute name for the stub directory at the client, and C: \di r l\di r2 be the path of the OS/2 directory to be accessed. Following the Unix convention, the path to dir2 iB the character string:
a_name(stub) = /u/user_id/C:\dirl\dir2 and expects it to be resolved to the required directory.
Note that a ": " i~ a valid character for a UNIX file name, and the "\" is ignored. Thus, tlle client will resolve the mounted component to C:dir dir which cannot be resolved to the required directory.
A systematic approach to col~str-~ct cascaded names with n_names from more tha~l one naming sy~3tem is required. The resolution of such a name resolution function in an existing computer system is al60 discussed.
Construction of a Caccaded Name A cascaded name is defined as a Ilame which contains component names from more than one naming sy~tem. Let:
~namel> be a name from name space S1, whose delimiter is <dell>, <name2> be a name from name space S2, whose delimiter is ~del2 >, ~visa> be a finite, non-empty ~tring of characters that does not include <del1>.
Then:
name = ~namel> ~dell? 'visa> ~del1> ~name2> is a cascaded name .

AT9-92-007 1~
2Q~i~9 <del1><dell> is defined as a pass through Sl, and <visa>
allows entry from S1 to S2, across the borders between the two naming systems.
The next section introduces the concept of name borders and presents two algorithms for employing borders in cascaded name resolution.
Name Borders and Cascaded Name Resolution Name borders are used in resolviIlg names that span two or more naming systems, possibly in a distributed environment.
A name border between two naming systems isolates the needed information to linl~ the two systems w~lile preserving the autonomy and independence of each system.
Assume that a cascaded name is to be resolved. A name border between Sl and S2 is defiIled as the Border Resolution Function which uses the pass resolution in S1 and Visa, to define the naming system to be used in resolving the remainder part of the name.
When resolving a name that spans m~ll tiple name spaces, a mechanism is needed to identify the borders between the two name spaces, and wl~en to cross from one name space to another. Application programs use different conventions to identify wllen to switch between m~lltiple name spaces. Two algorithms for crossing the borders from naming system Si to S(i+1) ~ using Border Resol~ltion Function Bi are discussed below .
Resolution of ('~C:~A~'i Names - Algorithm I:
In this algorithm, it is assumed tllat Resolution function Ri for namlng system S1 is extended to detect the se~uence,pass (<deli><deli>), and interpret it as the end of component names that can be resolved using Ri. It is also assumed that Ri returns the delimiter deli, w~lich is then used by the following border function to define the end of visai. Thus, for namei = r name (mi, ni ) 9 0 15 21~ 370 that starts at node mi in naming system Si Ri(a_name(mi), r_name(mi,ni))- address(n) if a_name (mi) & r_name(mi,ni) are names in N
Ri ( a_name (mi ), r_name ( mi ~ ni ) ~deLi > <deli > ) address ( n ' ), deli if a_name (mi) & r_name(mi,lli) are names in N;
= undefined otherwise.
The cascaded name name = ~namel><paasl~<vlsal>~dell>~name2> which starts at a node ml in naming system Sl, is to be resolved to an address in naming system 52 name is resolved as follows:
Rl ( a_name ( ml ), name ) =
Bl (address(~ visal>~dell~name2>) =
R2 ( a_name ( m2 ), <name2 > ) addre~S(n2) in S2 Note that address nl ' may or may l~nt be the same as address nl. A naming system may llave a level of indirection (alias) when resolving a pass, that iY only visible in Sl.
In general, the border function Bi between Si and Si+l will accept as arguments an address for an object in naming system Si and the remainder of t~le "name" after resolving <namel><passl>.... <namei><passi~. Bi will consume <visai><dell> and defines the next namillg system Si+l to resolve "name", and the starting node at Si~l. Bi then calls the resolution function Ri., 1 to continue name resolution.
Bi(address(ni ), 'visai>, <deli~ <namei>
<pass(i+l)> <ViSa(i+l )> 'del(i+l) . . .
<name(K 1)> <Pass(K_l)> <Visa(K-l) <del ( K 1 ) > <nameK> ) R_i+l(a_name(m-i+l) ~
<namei><paSS(i+l)><visa(il l)><del(i~ 1) 20$28~0 <name(K_l)' <paSs(K_l)> <Visa(K-l) <del(K_l)> 'name(K) Resolution of Cascaded Names - Algorithm II
A second algorithm is presented in this section to allow the use of name borders with existing naming systems without the resolution function modification required by the algorithm in section 5.1. In this algorithm, it is assumed tllat there is a two-level hierarchy of naming systems. Existing naming systems Sl, S2, , SK are assumed to be objects in ar~
attrlbute-ba~ed naming system S. For each ob~ect Si in S, the following attribute types are defined:
o address A_Si in S; (Different objects have different addresses. ) o delimiter <deli>;
o a resolution function Ri ~ to be called when resolving a name in Si; and o an optional alias name Ni, w~ich can be resolved by S to Ai ~
The cascaded name name = <name1>~del1~<dell~<visa1>-del1>
<name2><del2><del2><visa2>~del <nameK>
which starts at a node (m1) in llaming system 51' is resolved as follows:
1. R1 is called to resolve "namel" to an address in Sl.
Rl(a name(ml), r_name(ml,nl) ~ = address(nl) .
2. A border function Bl is called to identify S2 and the starting point of name2.
Bl(A_Sl, address(nl), visal) = (A_S2, a_name(m2)) Since S is an attribute-based naming system, address_S2 readily identifies other attrib-ltes of 52 such as the R2 and del 3. Steps (1) and (2) are repeated for i = 2, K - 1.
4. RK is called to resolve nameK
RK (a_name(mK) r_name(mK,nK) ) = address(nK) 5. R (a_name(nl), name) = address(nl) for K=l = (address(llK), address(SK) ) K>l This architecture satisfies a req~lirement to isolate all the information needed for linking naming systems, while it avoids placing requirements on existing name resolution functions .
DETAILED LOGIC
Figure 4 illustrates a data structure for resolving names in accordance with the subject invention residing ln a memory or on a disk of a computer as depicted in Figure 1. The data structure can be implemented as part of a relational database resident in memory or on tlle disk. The data structure is used to resolve tlle name appearing at label 402. In the Eigure, ~del~ is tlsed to refer to a defined delimiter. Thus, the name is resolved by searching for the initial delimiter in tlle data str~lcture at 403. The data structure is act~lally a two dimellsional array containing character information in one array and integer, address information in t~le other array. T~l~ls, wllen t~le delimiter is located in t~le character array at 404, the address in the linked integer array i s used as a pointer to the location where the search for "~A><del~" should be commenced ~03.
When "<A>~del>" is located, the address in the linked array is used as a pointer to the location w~lere the search for "<B><del>" should be commenced 408. Wllen "<B~<del~" is located, the address in the linked, integer array is used as a pointer to the location where the search for "<C>" should be commenced 403. When "<C>" is matched in the character AT9-92-007 zo~ 0 array 407, the address in the linked, integer array is the absolute address of the object "C".
The logic used to process a data structure ir. accordance with the sub~ect invention includes a set of primitive functions that are common to the naming system. The first function is the LeftMost_String( stringl, 3tring2). Thi3 function searches the character string, stringl from left to right until it matches string2 or detects the end of string1 without a match. The function then returns the string of characters in string1 left of string2. A common usage of the function is to search for a name in a character buffer, where name consists of 3everal component names separated by delimiters and returns the leftmost component name. In cascaded names, this function is also used to scan a cascaded name from the left to detect <del><del>. Thus, LeftMost_String(cascaded_name, ~del><del>) returns the left most name in a cascaded name residing in a character buffer.
The second function is rightmoEt_charact(STRING) whic11 returns the right most character in a character string ] abeled STRING. The third function iB rig~lt_remainder (STRING, STRINGl) which removes the character string STRING1 from the riglltmost location in STRING and returns the remainder string in the character string labeled STRING. The fourt~l function is left_r~ -~n~Pr (STRING, STRING1) wllich removes the character string STRINGl from t~le lef tmost location in STRING and returns the remainder string in t~le character string labeled STRING. The final primitive fullction i5 left_most (STRING, n) which returns the n leftmost characters located in the character string STRING i~ the character string STRING.
Figure 5 is a flowchart of absolute name construction in accordance witil tlle subject invention. This is an absolute name in one hierarchical name space, starting from the root of the name space. It is constr~cted by using the delimiter <del> and one or more component names. Processing commences at label 500 and immediately passes control to input block _ _ _ ~ _, _ , ... . , .. , . .. . , _ . .....

AT9-92-007 19 2t~ 70 502 for reception of the counter K, the delimiter character, and component_names l, 2,... K.
The information received over a communications adapter as shown in Figure 1. In function block 504, a_name is equated to the delimiter character. Then a loop test is commenced at decision block 506 to determine if all component names have been processed. If so, then control passes to ~erminsll 518 and processing is compiete. ~owever, if more component names remain to be processed, t~len a counter i is initialized in function block 508 to commence a loop.
Function block 510 builds t~le absolute name a_name by concatenating the existing a_name with the component_namei.
Then, at decision block 512, a test is performed to determine if the Kth component_name has been procesaed. If it has, then proces3ing is comp~ ete and control passes to terminal 518. If not, then a delimiter i5 added onto the end of a_name a3 shown in function block 514. Then, the counter i is incremented and control passes to function block 510 for additional processing.
Figure 6 is a flowchart depic~:ing t~le detailed logic associated with construction of a relative llame in a hierarchial name space in accordance with t~le subject invention. Control commences at terminal 600 and immediately passes to input block 602 for reception of the counter K and component_names l-K. Tlle information may be received over a communication adapter as shown in Figure 1.
In function block 604, the relative name is initialized to the null character Decision block 606 is processed next to determine if no component names are available for processing. If counter K is e~lal to zero, then control pas3es to terminal 622 and processing is complete. If K is not equal to zero, then a loop variable is initialized to 1 at function block 610 and a component_namei is concatenated onto the relative name in function block 612. Then, at decision block 614, the loop variable i is compared to K to determine if all of the c4mponent names have been processed.
If i = K, then processing is complete and control passes to termin~l 622. If not, then control passes to function block 616 where a delimiter is added onto the end of the relative name . Then, the loop index i i s incremented and control flows to function block 612 for proce6sing of the next component_name .
Figure 7 is a f lowchart of the detailed logic associated with construction of a name in a single name space using the absolute name and relative name and the primitive functions rightmost_character and rightmost_remainder. Processing commences at terminal block 700 and control immediately flows to input block 702 for reception of absolute name, relative name and a delimiter character. Eunction block 704 initializes a name variable wit~ the absolute name. Control then passes to decision blocl~ 706 to test the rightmost character of the absolute name to determine if it is the delimiter character. If a delimiter character is not detected, then control jumps to function block 710. If a delimiter character is detected, then the delimiter is stripped off in function block 708 and the final name is constructed in function bloc~ 710 by concatenating the absolute name, the delimiter character and the relative name. Finally, control passes to terminal 712 and processing is complete.
Figure 8 is a flowchart of the detailed logic for construction of a cascaded name in accordance with the subject invention. Processing commences at terminal block 800 and immediately passes to input block 802 for reception of a counter K which identifies the maximum number of involved name spaces, delimiters for the name spaces, names to be resolved by the name spaces, and visss. Then, control passes to function block 804 for initialization of a cascaded_name to the null value. Next, at decision block 806, a test is performed to determine if the count is equal to zero. If so, then processing is complete and control passes to terminal block 820. If processing is not complete, then a loop counter i is set e~ual to 1 at function block 808 and a loop is commenced. Function block 810 concatenates the namei onto the cascaded_name. Then, a AT9-92-007 21 ;;:06~70 test is performed at declsion block 812 to determine if i is equal to K. If so, then processing is complete and control passes to 820 If not, then two delimiter characters, vi~ai, and a final delimiter are concatenated onto the cascaded name at function block 814. Then, at function block 816, the loop counter is incremented and control passes to function block 810 for additional name proce~ing.
Figure 9 is a flowchart depicting the detailed logic of a resolution function for one name space in accordance with the subject invention. Processing commences at 900 and immediately flows to input block 910 to receive a root address, absolute name, relative name and delimiter character. Then, control is passed at label 912 to label 600 of Figure 6 for construction of a name from the given absolute name, relative name and the delimiter. Then, at function block 914 address is initialized to the root address and in function block 916, name is initialized to the left most characters of the name after the leftmost delimiter character is removed. A test i:3 performed next at deci~ion block 918 to determine if the name is now equal to the null character. If so, thell processing i~ complete and control is passed to termination bloc]~ 920. If ~lot, then at function block 924, component_llame is defined as the character string on the left of the first occurrence of the delimiter from the left in name. A table lookup is performed to ascertain the new address. The table lookup includes re~olving the absolute name and the relative name r_names to recursively call LeftMost_String(name, del) to obtain component names and resolve the name to an address as explained in the detai led description of Figure 4.
The table appears in Figure 11 and is queried by lookup employing tlle current address and the component_name to search the table for an entry where the X entry 1100 is equal to address and the y elltry 1102 is equal to component_name. The corresponding entry in the new_addre3s entry 1104 is the new addre~s ~Ised in function block 930 of Figure 9 for replacemen': of the address value. Then, in function block 932, name is f~lrther processed to remove _, . . . . . .. . .. . _ .

ATg - 92 - 007 Z~?,7~
component name. Then, in decision block 940 a test i8 performed to determine if name is equal to the null value.
If so, then processing is completed and control passes to termination block 920. If not, then processing is continued via label 950 corresponding to label 1000 in Figure 10 which immediately performs a test at decision block 1002 to determine if name is equal to a delimiter character. If not, then the delimiter character is stripped off of the name in function block 1006 and a branch is performed via label 1008 to label 922 of Eigure 9 to function block 924.
If name is equal to the delimiter character, then processing is complete and control flows to terminal 1004.
Figure 10 is additional detailed logic used in con~unction with the logic discussed relative to Figure 9 in accordance with the subject invention. Figure 11 is a data structure representation of a lookup table as discussed in the detailed processing of Eigure 9 and in accordance with the sub~ ec t i nventi on .
Figure 12 illustrates a data structure for resolving cascaded names in accordance wi tll the subject invention residing in a memory or on a disk of a computer as depicted in Figure 1. The data structure is used to resolve the name appearing at label 1200. There are three distinct nàming systems tied into this example, 1202, 1206 and 1208. Name cascading refers to the resolution of a Ilame with visa and delimiters across system borders into tlle particular name unique to the particular system. T~lus, as a name constructed in Sl 1202 and referring to an object in system S3 1208 is resolved, it ~u~t have its visa resolved via the border linked list data structure at 1204. After resolving the leftmost i names in a cascaded name, thi~ function defines the subsequent naming system w~lich resolves the remainder of the cascaded name. The ful~ction takes as input parameters the address A_Si of the preceding naming system Si, the address_ni of the last Ilame in Si, and visai. It returns the address A_Si ~1 of the naming system Si+l and the absolute name a_name(mitl) of the starting node in Si~l.
Since Si+l is an object in an attribute based name space, _ ~ _ _ , . , .. . .. . _ _ .. . , . .. , _ _ _ _ _ AT9-92-007 23 Z~,~Z~70 A_Si+l readily identifies resolution function Ri+l and the delimiter <deli+l~ for Si+l' Eor example, the name appearing at 1200 is resolved by searching for ~dell> in 1202. T~le address linked to <dell>
points to the beginning of the list to query for <A~<dell><dell> at 1220. When a match is found at 1222, the address linked to that entry points to the particular border data structure where ~visal>~dell> can be matched. The match occurs at entry 1226 and the linked address points to an entry for <B><del2><del2> at location 1230. When a match occurs at 1232, the address associated with the matched entry points back to the border data structure wherein the search commencee for ~visa2>. The entry matching <visa2><del2> has a corre3pondin~ address which points to the beginning of the linked list 1240 wherein <C> can be searched for. The entry matching <C> 1242 has a correeponding entry with the unique id address 1210 corresponding to ~C> in name space S3.
Figure 13 is a flowchart setting fortil the detailed logic corresponding to a resolutio!l of cascaded names in accordance with the subj~ct inventioll. Processing commences at 1300 and control is immediately passed to input block 1302 where an absolute nallle, cascaded name, delimiter for the first name space to be used in resolving the cascaded name, and addresses for each naming system involved are received. Then, at function block 1304, a counter i is initiali2ed to 1 and in function block 1310 the caecaded name is processed to isolate the it~l relative name (r_namei) which will be resolved by name space Si. R_namei is e~uated with the character string in cascaded_name, left to the first occurrence of the sequence ~deli>~deli>. Then, at label 1320 the relative name r_namei is resolved as set forth in the detailed logic of Ei~ure 6. The relative name r_namei and the sequence <deli~deli> are then removed from cascaded name in function block 1330. A test is performed at decision block 1340 to determine if the cascaded_name is equal to the null value. If it is, then control is passed via label 1350 to Eigure 15 label 1500. If it is not e~ual ... . . ..

24 Z~8~
to a null value, then vlsa. is set equal to the character string let of ~deli > in cascaded_name at function block 1360. The cascaded_name is then defined as the remainder of that name after removing ~visa~'deli~ at function block 1370 and control is passed to label 1400 of Figure 14 Control is then transferred to function block 1600 in Figure 16 to process the border function on Bi. Function block 1420 determines the next address based on the current address information. Then, index i i8 incremented at function block 1440 and control is passed via label 1450 to label 1306 of Figure 13 to process the next name Figure 15 is a detailed flowchart depicting the logic associated with processing addresses in accordance with the subject invention. Processing commences at label 1500 which flows into decision block 1510 to determine if i is equal to one; i . e. there was only one name space involved in resolving the name. If 80, then in function block 1520, address is equated to the address of node ni in that system and proces~ing is completed at terminal block 1540. If i is not equal to one, then address consists of the address of the last system and the address of the final node encountered during name resolution in t~lat system as shown in function block 1530 and control is pasges to ~rmin~l block 1540.
Figure 16 is the detailed logic associated with the border function in accordance with t~le s~lbject invention.
Processing commences at 1600 and passes to input block 1610 for reception of the address of the data structure corresponding to the ith naming system A_Si and the address of the node ni in t~lat system. Then, at function block 1620, the-data structure for A_Si is searched for a match of the name at the address corre~ponding to the ith name. The data structure is a three dimensional array. For each entry, the X value is an address of a node and the Y value is a visa. The Z value is a pointer to the data structure A_Si+1 for the following naming system after the border, and the absolute name of the starting node in A_Si+1.
_ _ _ _ . . . .. ....... _ .. . . _ , .. . .

AT9-92-007 25 Z~ $7Q
Referring to Eigure 21, wllich is a drawing of the border table data structure located at tlle address of the ith system (A--Si ), the column of string values at 2100 are searched for a match of the matched to the ith node (address ni) and the corresponding value in the column labeled 2110 is the visa. The column labelled 2120 corre~3ponds to the next entry to be used.
Returning to Figure 16, the next step in the border processing is to search the table corresponding to the address of the 1~1 system at function block 1630. The first entries ln the table define the attributes of that system.
Each entry has an {attribute type = attribute value} pair.
For attribute type delimiter, the value is deli+1, and for type resolution, the value is Ri~ 1 Figure 17 is a flowchart depicting the detailed logic of the extended name resolution for a single name space. Processing commences at label 1700 and receives input of a root address, absolute name, relative name and delimiter at function block 1710. Then, the relative name, absolute name and delimiter are used to construct a name in accordance with the logic set forth i~l Figure 6 at 1720 and an address is initialized to the root address at 1722. The basic extension to t~le resolution function is to search for and identify the sequence <del~<del?. Then, at decision block 1730, the two leftmost character.s ill name are checked to see if they are <del>~del~. If the test i8 affirmative, the control passes to label 1740. If the test is not, then in function block 1742, the delimiter character is stripped from name and a test is performed at decision block 1744 to determine if the name is eqtlal to null. If so, then processing is complete and control is transferred to 1750.
If not, then in function block 1751, tlle following component name in the path is defined as the string of characters left of the first delimiter, a table lookup is performed in accordance with the logic set forth in Figure 11. The table lookup returns a new addr~ss in f~lnction block 1754, the new values for address is assigned and the name is redefined after removing the compo~tent_name for its left. Then, _ _, . _ _ _ . . . . .... . .... , . , . _ _ _ _ _ T 9 26 2013~$7 control passes to Figure 1~ via label 1760. Figure 18 tests to determine if the name is equal to a null at 1810 and completes processing if it is at terminal 1840. If the name i~ not equal to a null, then processing is returned to Figure 17 label 1724 for further processing.
Figure 19 is a flowchart depicting additional detailed logic of the extended name resolution for a 6ingle name space. It defines the extensions when cdel'~del~ is formed. Processing commences at label 1900 when a branch is made via Figure 17 label 1740. Function block 1910 strips of the two delimiters from a name. Then, at decision block 1920, a test is performed to determine if t~le leftmost character is still a delimiter. If so, thell in fullction block 1930, another delimiter is stripped off and control is passed back to decision block 1920. If not, tlle control is passed to the border function at label 1940.
Eigure 20 iE a flowchart representing tlle detailed logic of a border function in accordance with the subject invention.
Control is initially passed from Fig~lre 19 at label 1940 to label 2000 of Figure 20. Tllen, at input block 2010, the address of the la~t node is received along with the name and delimiter character. Then, at f~lnction block 2012, the ith visa is formed based on the leftmost characters left of deli in name. Function block 2014 transforms name into a string variable without the visa characters. Then, at function block 2016, the delimiter is stripped off of the end of name and a test is performed at decision block 2020 to determine if name is equated to a null character. If so, then processing ls completed as shown at terminal 2030. If not, then a table lookup is performed using the border table ~et forth in Figure 21 to determine the resolved addre~s for the following name space Si+1 to be used in resolving the r. -inril-r of the name. Thus identifies the name resolution function Ri+ 1~ the absolute address of tlle starting node A_Mi+l, and the delimiter deli+l. The counter i is incremented in function block 2050, and control is passed via label 2060 to function bloc}~ 1700 in Figure 17.
, ... ... . . . _ _ _ .. , . . .. _ . _ _ _ _ AT9-92-007 27 20$~370 While the invention has been described in terms of a preferred embodiment in a specific system enviromTent, those akilled in the art recogni~e that the invention can be practiced, Wit~1 modi:fication, in other and diffe~ent hardware and software environments within the spirit and acope of the appended claims.

Claims (32)

1. An apparatus for resolving names corresponding to one or more object addresses residing on one or more computer systems, comprising:
(a) memory means for storing a plurality of data structures;
(b) means for parsing the names into strings of characters;
(c) means for matching a first string of characters in a first data structure and obtaining an address to a second data structure; and (d) means for matching a second string of characters in a second data structure and obtaining an address to an object in a particular computer system.

2. An apparatus as recited in claim 1, wherein the data structures are stored in a file system.

3. An apparatus as recited in claim 1, including means for using existing delimiter characters to parse the names into strings of characters.

4. An apparatus as recited in claim 1, including name border means for isolating the syntax of a particular naming system.

5. An apparatus as recited in claim 1, including visa means based on an existing name system for crossing from a first system to a second system.

6. An apparatus as recited in claim 1, including double delimiter means for identifying the end of a name in a specific name space.

7. A method for resolving names corresponding to one or more object addresses residing on one or more computer systems, comprising the steps of:

(a) storing a plurality of data structures;
(b) parsing the names into strings of characters;
(c) matching a first string of characters in a first data structure and obtaining an address to a second data structure; and (d) matching a second string of characters in a second data structure and obtaining an address to an object in a particular computer system.

8. A method as recited in claim 7, wherein the data structures are stored in a file system.

9. A method as recited in claim 7, including the step of using existing delimiter characters to parse the names into strings of characters.

10. A method as recited in claim 7, including the step of isolating the syntax of a particular naming system.

11. A method as recited in claim 7, including the step of supporting existing name systems.

12. A method as recited in claim 7, including identifying the end of a name in a specific name space by detecting a double delimiter.

13. A method as recited in claim 7, including crossing a system border by processing a visa.

14. A control element for directing the operation of a computer, having storage means for retaining signals recognizable by the computer and controlling the operation thereof, the signals comprising:
(a) memory means for storing a plurality of data structures;
(b) means for parsing the names into strings of characters;
(c) means for matching a first string of characters in a first data structure and obtaining an address to a second data structure; and (d) means for matching a second string of characters in a second data structure and obtaining an address to an object in a particular computer system.

15. A control element as recited in claim 14, wherein the data structures are stored in a file system.

16. A control element as recited in claim 14, including means for using existing delimiter characters to parse the names into strings of characters.

17. A control element as recited in claim 14, including name border means for isolating the syntax of a particular naming system.

18. A control element as recited in claim 14, including visa means based on an existing name system for crossing a system border.

19. A control element as recited in claim 14, including double delimiter means for identifying the end of a name in a specific name space.

20. An apparatus for constructing names corresponding to one or more object addresses residing on one or more computer systems, comprising:
(a) memory means for storing a plurality of data structures;
(b) means for parsing the names into strings of characters;
(c) means for matching a first string of characters in a first data structure and obtaining an address to a second data structure; and (d) means for matching a second string of characters in a second data structure and obtaining an address to an object in a particular computer system.

21. An apparatus as recited in claim 20, wherein the data structures are stored in a file system.

22. An apparatus as recited in claim 20, including means for using existing delimiter characters to parse the names into strings of characters.

23. An apparatus as recited in claim 20, including name border means for isolating the syntax of a particular naming system.

24. An apparatus as recited in claim 20, including visa means based on an existing name system for crossing from a first system to a second system.

25. An apparatus as recited in claim 20, including double delimiter means for identifying the end of a name in a specific name space.

26. A method for constructing names corresponding to one or more object addresses residing on one or more computer systems, comprising the steps of:
(a) storing a plurality of data structures;
(b) parsing the names into strings of characters;
(c) matching a first string of characters in a first data structure and obtaining an address to a second data structure; and (d) matching a second string of characters in a second data structure and obtaining an address to an object in a particular computer system.

27. A method as recited in claim 26, wherein the data structures are stored in a file system.

28. A method as recited in claim 26, including the step of using existing delimiter characters to parse the names into strings of characters.

29. A method as recited in claim 26, including the step of isolating the syntax of a particular naming system.

30. A method as recited in claim 26, including the step of supporting existing name systems.

31. A method as recited in claim 26, including identifying the end of a name in a specific name space by detecting a double delimiter.

32. A method as recited in claim 26, including crossing a system border by processing a visa.