Keyboard shortcuts

/ or ⌘/Ctrl K
Find a note
j / k
Next / previous section or linked note
h / l
Collapse or go to parent / expand or enter
e or Alt-click
Read a linked note here
o
Open focused note on its own
g g / G
First / last section or linked note
g h / g a
Home / all notes
g b / g t
Backlinks / table of contents
t
Cycle System, Light, Dark
? / Esc
Show / close this reference

Search: ↑/↓ or Ctrl N/P, Enter to open. Shortcuts pause while typing.

Steen and Tanenbaum - Distributed Systems [554c821b]

1. Chapter 5: Naming [20a077ab]

  • 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

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