Notes on Naming

Lecturer: Professor Fred B. Schneider

Lecture notes by Lynette I. Millett

In this lecture, we introduce naming, a topic that has rarely been examined in isolation. As a result, people tend to make common mistakes with naming when building systems.


A name is a form of abstraction that allows us to designate without details. Naming an object permits us to refer to that object without having to worry about the underlying details.

Naming is not absolutely necessary; we could live in a world without naming by using descriptions to refer to objects, but these descriptions can take time and space. For example, to fully describe the password file in a Unix system, we would need to list every user and password in the file! In this case, a file name provides a much more useful and terse way to refer to the file.


Naming should possess the following properties:


We can achieve several things by using names:


We now look at some issues regarding naming. In the past, there had been considerable discussion in the network community regarding a distinction between names, addresses, and routes. This distinction actually turns out to be a non-issue. By conventional wisdom, a name designated an entity, an address denoted its location, and a route described how to get to that location. For example, in UUCP (Unix-Unix calling program), a route specifies the sequence of hosts to contact, e.g. rutgers!princeton!att!fbs. The question of naming arises in networks. In some cases, the name will also be the address and the route, e.g.

The current thinking is that such distinctions are specious. Each is merely a different level of abstraction. In fact, making such sharp distinctions can cause problems. Consider an Ethernet network.

Each Ethernet card has a unique address, and it was common to use the card attached to a processor to name the processor. The naming fails, however, when two cards are attached to the same processor, for then, there is the illusion of having two processors. The two cards provide names, routes and addresses for one CPU and the distinction is no longer useful.


Names are a way of denoting something, and associated with each name is an object. This association is called a binding. Names do not make sense without bindings, and they are always uttered with respect to a certain context. The meaning of the name is acquired from the context. A context maps names to objects and has the following properties: A simple example of a context is memory. Memory essentially associates with each address (name) a value

Where are these contexts? Generally speaking, names must acquire meaning in one of the following ways:

Context is another way in which to enforce security. For example, the name "write" may be bound to different things for different users depending upon their privileges. Context is thus also a form of protection.

Implementation of Hierarchical Naming

Recall that naming can be thought of in terms of a hierarchy. The question becomes how to manage binding? If there is no structure associated with a particular name then a global service is necessary. It makes more sense to regard a name such as /a/b/b as a list of simple names and implement it using a tree.

For example, in the above image, the name a/b/b denotes a leaf object and circles represent directories or contexts. A hierarchically-structured name can be regarded as defining a path in the tree.

What if we are trying to merging two organizations, effectively extending names to the "left"? By simply merging, we create a new root node, and make the two original trees its left and right children respectively. The trouble is that none of the old names will work anymore. We need a way to "jump" over parts of the tree, to equate the value of a name in a directory with the value of another name in another directory. Consider the following example:

A solution is to provide a mapping from the path in the old names to paths in the new names. When we see an old name starting with a we map it to ibm/a. Similarly, b is mapped to ibm/b, c to dec/c, and so on. Generally, we can map the old name p/n to the new name p'/n'/n. This technique works provided that we have no duplicate names between the original two trees. Disk mounting in UNIX systems is an example of this method. For example, ~users/fbs might be mapped to /disk1/fbs, while ~users/rz is mapped to /disk2/rz. Note: the naming trees can actually be merged at any level.