EECE 411: Design of Distributed Software Applications What is a Distributed System? You know when you have one … … when the failure of a computer you’ve never heard of stops you from getting any work done (L.Lamport, ‘84) a collection of independent computers that appears to its users as a single coherent system

EECE 411: Design of Distributed Software Applications Independent hardware installations Uniform software layer (middleware) Note: the middleware layer extends over multiple machines 1.1

EECE 411: Design of Distributed Software Applications Main goals of a distributed system Connect users and resources Distribution transparency Openness Scalability

EECE 411: Design of Distributed Software Applications Transparency in a Distributed System TransparencyDescription AccessHide differences in data representation and resource access LocationHide where a resource is located MigrationHide that a resource may move to another location RelocationHide that a resource may migrate while in use ReplicationHide that a resource may have multiple copies Concurrency Hide that a resource may be shared by several competing users FailureHide the failure and recovery of a resource Note: transparency may be set as a goal, but achieving it is a different story.

EECE 411: Design of Distributed Software Applications Transparency – discussion Observation: Aiming at full transparency may be too much: Users may be located in different continents; distribution is apparent and not something you want to hide Completely hiding failures of networks and nodes is (theoretically and practically) impossible – You cannot distinguish a slow computer from a failing one – You can never be sure that a server actually performed an operation before a crash Full transparency will cost performance, exposing the fact that the system is distributed – Keeping Web caches exactly up-to-date with the master copy – Immediately flushing write operations to disk for fault tolerance Sometimes full transparency is not desirable from an application perspective

EECE 411: Design of Distributed Software Applications Openness Goal: Open distributed system -- able to interact with services from other open systems, irrespective of the underlying environment: Standard rules (protocols/interfaces) to describe services/components Interface definitions should be: Complete Neutral These help making system/services interoperable & portable Achieving openness: At least make the distributed system independent from heterogeneity of the underlying environment: Hardware Platforms Languages

EECE 411: Design of Distributed Software Applications Separating policy and mechanism To achieve flexibility: split the systems in smaller components. Components controlled policies specified by applications and users Example – web browser caching; Mechanism: caching infrastructure Policy: what to cache, how large the cache is, cache replacement algorithms Other examples: What operations do we allow downloaded code to perform? What level of secrecy do we require for communication? Implementing openness: Ideally, the distributed system provides only the mechanisms (and a way to specify policies)

EECE 411: Design of Distributed Software Applications Middleware and Interoperability Interoperability provided by: Protocols used by each middleware layer Interfaces offered to applications Independent hardware installations Uniform software layer (middleware)

EECE 411: Design of Distributed Software Applications Scalability Example Centralized servicesA single server for all users Centralized dataA single on-line telephone book Centralized algorithmsDoing routing based on complete information Observation: Many developers of existing distributed systems easily use the adjective “scalable” without making clear why their system actually scales. System should be able to grow over multiple axes: size (#user, #resources), geographical distribution, maintainability

EECE 411: Design of Distributed Software Applications Scaling Techniques (1) 1.4 Technique: Offload work to clients

EECE 411: Design of Distributed Software Applications Scaling Techniques (2) Technique: Hide communication latencies Make use of asynchronous communication Have separate handler for incoming response Problem: not every application fits this model

EECE 411: Design of Distributed Software Applications Scaling Techniques (3) 1.5 Technique: Divide the problem space. example: the way DNS divides the name space into zones.

EECE 411: Design of Distributed Software Applications Scaling Techniques (4) Replication/caching: Make copies of data available at different machines: Replicated file servers and databases Mirrored Web sites Web caches (in browsers and proxies) File caching (at server and client)

EECE 411: Design of Distributed Software Applications Scaling: The problem Applying scaling techniques is easy, except for one thing: Having multiple copies (cached or replicated), leads to inconsistencies: modifying one copy makes that copy different from the rest. Always keeping copies consistent (and in a generic way) requires global synchronization on each modification. This precludes large-scale solutions.

EECE 411: Design of Distributed Software Applications Summary so far: (primary) goals of a distributed system Connect users and resources Distribution transparency Openness Scalability

EECE 411: Design of Distributed Software Applications Developing distributed systems: Pitfalls Observation: Many distributed systems are needlessly complex caused by mistakes that required patching later on. Many possible false assumptions: The network is reliable The network is secure The network is homogeneous The topology does not change Latency is zero Bandwidth is infinite Transport cost is zero There is one administrator

EECE 411: Design of Distributed Software Applications Middleware 1-22

EECE 411: Design of Distributed Software Applications Architecture styles: Client/server Model: Server: process implementing a certain service Client: uses the service buy sending a request and waiting for the reply Main problem to deal with: unreliable communication Note: often both roles simultaneously for different services

EECE 411: Design of Distributed Software Applications Architectural styles: Layered style

EECE 411: Design of Distributed Software Applications Architectural styles: Layered style example Layered style: three-layer (tier) architecture commonly used in many internet based applications today General organization of an Internet search engine into three different layers 1-28

EECE 411: Design of Distributed Software Applications Architectural styles (II): object based Idea: Organize into logically different components, and subsequently distribute those components over the various machines. object-based style

EECE 411: Design of Distributed Software Applications Architectural styles (III) Alternatives: Decouple processes in space (“anonymous”) and/or time (“asynchronous”) Event-basedData-centered architectures

EECE 411: Design of Distributed Software Applications Summary so far: Definition of distributed systems collection of independent components that appears to its users as a single coherent system Goals, pitfalls, scalability techniques, architecture styles Requirement: Components need to communicate  Shared memory  Message exchange  need to agree on many things  Protocols: data formats, exception handling, naming, …

EECE 411: Design of Distributed Software Applications Layered Protocols Layers, interfaces, and protocols in the OSI model. 2-1

EECE 411: Design of Distributed Software Applications Layered Protocols (2) A typical message as it appears on the network. 2-2

EECE 411: Design of Distributed Software Applications Low-level layers Physical layer: contains the specification and implementation of bits, and their transmission between sender and receiver Data link layer: prescribes the transmission of a series of bits into a frame to allow for error and flow control Network layer: describes how packets in a network of computers are to be routed. Note: for many distributed systems, the lowest level interface is that of the network layer.

EECE 411: Design of Distributed Software Applications Transport Layer The transport layer provides the actual communication facilities for most distributed systems. Standard Internet protocols TCP: connection-oriented, reliable, stream-oriented communication UDP: unreliable (best-effort) datagram communication

EECE 411: Design of Distributed Software Applications TCP for client server a) Normal operation of TCP. b) Transactional TCP. 2-4

EECE 411: Design of Distributed Software Applications Middleware Protocols Middleware provides common services and protocols that can be used by many different applications: (Un)marshaling of data, necessary for integrating systems Naming protocols so that different applications can easily share resources Security protocols to allow different applications to communicate in a secure way Scaling mechanisms such as support for replication and caching

EECE 411: Design of Distributed Software Applications Summary so far: Definition of distributed systems collection of independent components that appears to its users as a single coherent system Goals, pitfalls, scalability techniques, architecture styles Requirement: Components need to communicate  Shared memory  Message exchange  need to agree on many things  Protocols: data formats, exception handling, naming, …