IF3056 Distributed Systems: Naming

Chapter 5: Naming

Names, indentifiers, and addresses
Name resolution
Namespace implementation

++NAMING

Essence
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.

Note
location-independent name for an entity E, is independent from the addresses of the access point offered by E.

++IDENTIFIERS

Pure Name
A name that has no meaning at all; just a random string. Pure name can be used for comparison(?) only.

Identifier
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

Observation
An identifier need not necessarily to be a pure name, it may have content(?)

++FLAT NAMING

Problem
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

Broadcasting
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

Forwarding Pointers
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
Single-tiered Scheme
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


Two-tiered Scheme
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?)

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s