عجفت الغور

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)
  • an address is
    • 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 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