# Steen and Tanenbaum - Distributed Systems

## Chapter 5: Naming

• an identifier is one that is:
• referring to at most one entity
• referred to by at most one identifier
• always referring to the same entity (no-reuse)
• a single access point
• can be reused
• can be reassigned
• cannot be reused as an identifier
• oftentimes name-to-address bindings are done by creating a (name, address) table
• you can create a self-certifying name by hashing the name, that way the name can always be guarneteed to be the data
• flat naming - when we don’t want the name to give any information about how to locate the access point of an entity

### Ways of Transmitting Names

• broadcasting or multicasting is difficult to implement efficiently in large-scale networks
• broadcast a message to each machine regarding the location of an entity and allow every machine to check if it has knowledge about that entity
• extremely inefficient as network grows
• forwarding pointers chains introduce performance problems and are susceptible to broken links
• when an entity moves from A to B, it leaves behind a reference in A about where its going
• chains for highly mobile entities can become very long
• example: SSP Chains
• SSP chains are forwarding pointers implemented with a (client stub, server stub) pair
• a server stub contains either a local reference to the actual object or a local reference to a remote client stub for that object
• whenever an object moves from A to B, it leaves behind a client stub in A, and sets up a server stub in B.
• this allows shortcuts to be setup, by keeping track of the chain, when a client stub goes to get a server stub and ends up hitting another client stub, it marks where the final server stub is at
• you can piggyback the stub change message on top of the response, by responding directly to the client
• when a sever stub is no longer being used, you can cross it out, similar to a form of distributed garbage collection
• issues
• when stub pairs crashes or becomes unreliable
• you can create a LII system to let the where where an object was created always keep a reference to its current location. That reference is stored and maintained in a fault-tolerant way, and eventually allows the user to ask where the object is at whenever the chain is broken.
• Home-based approaches
• keeps track of current location of an entity, which safeguards against network or process failures