• Properties shared by all architecture models 
  • communicates by sending messages across a network
  • requirements of performance, reliability, and security
• Fundamental models
  • abstracts over unnecessary details
  • used to address questions like
  • what are the most important entities in the system?
  • how do they interact?
  • what are the characteristics that affect their individual and collective  behavior?
• The purpose of fundamental models : 
• to make explicit all relevant assumptions about the system we are modeling
• to find out what is generally feasible and not feasible under the given assumptions
• Aspects of distributed systems we want to express
  • Interaction model
  • processes, messages, coordination (synchronization and ordering)
  • must reflect that messages are subject to delays, and that delay
  • limits exact coordination and maintenance of global time
  • Failure model
  • defines and classifies failures that can occur in a DS
  • basis for analysis of effects of failures and for design of systems that are able to tolerate failures of each type while continuing to run correctly
  • Security model
  • defines and classifies security attacks that can occur in a DS
  • basis for analysis of threats to a system

Fundamental Model :
Interaction Model

• Two variant of interaction model
  • Synchronous distributed systems
    • the time to execute each step of a process has known lower and upper bounds
    • each message transmitted over a channel is received within a known bounded time
  • each process has a local clock whose drift rate from real time has a known bound
  • Asynchronous distributed systems
    • the time to execute each step of a process can take arbitrarily long
    • each message transmitted over a channel can be received after an arbitrarily long time
    • each process has a local clock whose drift rate from real time can be arbitrarily large
      
      
• Significance of synchronous vs. asynchronous DS
  • Many coordination problems have a solution in synchronous distributed systems, but not in asynchronous
  • Often we assume synchrony even when the underlying distributed system in essence is asynchronous
    • Internet is in essence asynchronous but we use timeouts in protocols over Internet to detect failures 
    • based on estimates of time limits 
    • but: design based on time limits that can not be guaranteed, will generally be unreliable
      
      

• Ordering of events

  • distributed coordination protocols have a need for ordering of events in time (“happened before”-relationship)

    • events: sending and receiving messages
    • example: update of replicated data must generally be done in the same order in all replica
    • difficult to use physical clocks in computers for  coordination (e.g.,. clock values in messages)
  • have limited time resolution and ticks with different rates (clock drift)
  • basic properties of message exchange limit the accuracy of the synchronization of clocks in a DS [Lamport 78]