Systems Design and Implementation

1
Systems Design and Implementation

• Naming

2
Name Server

• What is reasonable name service protocol?

3
SawMill Naming Vision
4
Back to BasicsWhat is a name?

• Names are for humans
• to interpret, label, locate, organise
• Ideally
• Arbitrarily chosen
• Of arbitrary length
• Names bind human readable identifiers to system
  object identifiers.

5
Name Resolution Example
Names have a context in which they are resolved
6
Contexts

• Also termed catalog, folder, or directory.
• Early systems had a single catalog for the system
• Single user, batch systems
• What are the problems with this simple model?

• Large numbers of names are unwieldy to manage
• Name conflicts between users

7
Context Per User
Sharing????

• System switches name context pointer when it
  switches between users.
• System maintains a master context of contexts
• It maps users to their contexts

8
Current context pointer

• Users change the current context pointer to
  refer to the context is expects to bind the name.

Context
9
Current context pointer

• Users change the current context pointer to
  refer to the context is expects to bind the name.

Context
10
Current context pointer

• Security
• The simple naming system could rely on visibility
  for security
• No longer true if we can change contexts
• Potential for unintended name conflict or
  unintended bindings
• E.g. embedded reference in a program
• User must remember to switch contexts

11
A better approach?

• Like to select context for duration of a single
  name resolution
• Would avoid problems 2 3 on previous slide
• Explicitly specify the context with the name
• E.g. user_1/xyz or user_2/xyz
• We need a context to resolve the names of
  available contexts.
• Implies contexts are named objects

12
Naming Network

• Still have current context pointer
• Explicitly specify contexts to resolve names
• List of contexts form a path through network
• A Path Name

13
Naming Network
Can arbitrarily structure the name space as we
choose.
14
Naming network provides for sharing

• Network can be recursive

15
Issues

• Care must be taken to avoid endless loops
• Nothing prevents users from mistakenly create
  loops in the name space
• To add to the network dynamically we can either
• Create a new object and name it
• Add a new name to an existing object
• Problem
• Need a method to add to a context a new binding
  that refers to existing object
• Need a method to name the existing object.

16
Need a method to name the existing object.

• Usually solved by convention
• The root context from which all other contexts
  are reachable.
• Example
• / in UNIX
• Putting a binding to root in each users context
• root/user/u1
• Unnamable objects are unreachable

17
Thus far

• Names used to bind human interpretable strings to
  objects
• Contexts needed to bind the name to the object
• User can have their own initial context (view of
  the world)
• Contexts can nameable objects that can then form
  naming networks
• Naming networks can be recursive
• To be accessible, object must be nameable
• Typically by being reachable from the root of
  the name network