SKR 5302: Advanced Distributed Computing

2. System Model: Distributed System

2.6. Fundamental Model


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]