Browse Prior Art Database

Resource Directory for Network Communication

IP.com Disclosure Number: IPCOM000035713D
Original Publication Date: 1989-Aug-01
Included in the Prior Art Database: 2005-Jan-28
Document File: 5 page(s) / 54K

Publishing Venue

IBM

Related People

Ferro, MT: AUTHOR [+3]

Abstract

Disclosed is a resource directory which allows a network application program (NAP) to refer to its communication partner by a symbolic name. The NAP relies upon the underlying operating system and networking software to translate the symbolic name into specific network addressing and security parameters. The translation occurs at conversation start-up time and can be transparent to the NAP. The translation process as implemented in VM/SP is illustrated in the figure.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 37% of the total text.

Page 1 of 5

Resource Directory for Network Communication

Disclosed is a resource directory which allows a network application program (NAP) to refer to its communication partner by a symbolic name. The NAP relies upon the underlying operating system and networking software to translate the symbolic name into specific network addressing and security parameters. The translation occurs at conversation start-up time and can be transparent to the NAP. The translation process as implemented in VM/SP is illustrated in the figure.

The computer user sees the resource directory to be a set of system-wide resource definitions supplemented by the user's additions. This makes it possible to override any or all of the definitions supplied by the system administrator. Each definition maps a symbolic name to a set of parameters which describes the name and location of the resource. The directory can also provide authentication tokens (needed to access the remote resource) as part of the symbolic name translation process.

The resource directory implements the following facilities, each of which is described in this article: A facility that allows the directory lookup service to

be implicitly invoked each time a conversation is

started;

A facility for explicitly querying the directory to

resolve a specific symbolic name;

User commands to set and query the operational state of

the directory;

A facility for maintaining the data base that maps

symbolic names to real addressing information;

Two implementation models: one that emphasizes

resolution speed, and one that allows for automatic

detection of changes to the directory data base.

Finally, the directory allows both existing and new applications to operate without a directory if they choose to do so, and applications written before the directory may take advantage of the directory without changing their code.

The directory data base is considered to be partitioned into two domains of control, the user level and the system level. When a name needs to be resolved, the user level is searched first. If the name is not found there, then the system level is searched.

The translation data bases for the two directory levels are stored in disk files. Typically, each user supplies his own user-level mapping file, and the system administrator supplies the system-level file. The system-level file is shared among all users.

The names of the mapping files are provided to the operating system through a user command. The names installed via this command are part of the user's environment. Each user is free to choose the names of his user-level and

1

Page 2 of 5

system-level mapping files. By convention, a user typically chooses his system- level file to be the shareable one provided by the system administrator.

Two operational models for the directory are available. In the static model, a user command loads the data base completely into storage, and name resolution takes place against the memory image. Changes in the disk fil...