Chapter 5: Naming
Names, indentifiers, and addresses
Names are used to denote entities in a distributed system. To operate on an entity, we need to access it at an access point. Access points are entities that are named by means of an address.
A location-independent name for an entity E, is independent from the addresses of the access point offered by E.
A name that has no meaning at all; just a random string. Pure name can be used for comparison(?) only.
A name having the following properties:
Prop1: Each identifier refers to only one entity.
Prop2: Each entity is reffered by at most one identified
(1,2) One-to-one correspondence
Prop3: An identifier (assigned name) always refers to the same entity, prohibits reusing an identifier
An identifier need not necessarily to be a pure name, it may have content(?)
Given an essentially unstructured name, how can we locate which access point it refers to?
– Simple solution
– Home-based solution
– Distributed Hash Table (P2P)
– Hierarchical location service
++ SIMPLE SOLUTION
Broadcast the ID, requesting the entity to return its current address.
– It’s impossible to take this brute force method for scale beyond LAN
– It requires all processes to listen to incoming location requests
When an entity moves, it leaves behind a pointer to next location.
– Dereference the track. It is possible to follow the chain of pointers.
– Update a client’s reference when present location is found, track the access point.
++ HOME BASED SOLUTION
We let a home (main host) keep track of where the entity is.
– Entity’s home address registered at a naming service
– Client contacts the home first, then continue with foreign location
Keep track of visiting entities.
– Check local visitor register first.
– Fall back to home location if local backup fails.
Problems with home-based approaches
– Host shall not be down for the entity’s lifetime, always exists.
– Home address is fixed. What if the entity moves permanently?
– Poor geographical scalability (entity may be next to client, why not broadcast?)