1. Introduction
Chapter 1

2. Definition of a Distributed System (1)
A distributed system is:
A collection of independent computers that appears to its users as a single coherent system.

3. Definition of a Distributed System (2)
A DS is a collection of independent computers that appears as a single system. It is expected to have BOB. This is actually a middleware as a layer between the applications and the network. It gives the same interface to all the applications. All applications communicate with its components and with other applications.
1.1
A distributed system organized as middleware. Note that the middleware layer extends over multiple machines.

4. Goals
For a distributed system to be worthwhile it should have some reasonable useful goals:
Connection of users and resources: Accessibility
Transparency
Openness: syntax and semantics
Scalability: asynchronous comm, distribution, replications, etc.

5. Accessibility
Almost every component available over the network can be shared, and it is useful to share: computers, devices, data, communication medium.
But, how efficient and secure is all this sharing.
DS must work to provide enough security and efficiency.

6. Type of transparency
Transparency
Description
Access
Hide differences in data representation and how a resource is accessed
Location
Hide where a resource is located
Migration
Hide that a resource may move to another location
Relocation
Hide that a resource may be moved to another location while in use
Replication
Hide that a resource may be shared by several competitive users
Concurrency
Failure
Hide the failure and recovery of a resource
Persistence
Hide whether a (software) resource is in memory or on disk
Different forms of transparency in a distributed system: Hide the multiplicity, with best of the both

7. Clarification of Transparency
Hide difference in data representation
Resources have logical names, independent of where they are located
Resources can be migrated without changing how they are accessed logically
Hide the fact that several copies of the same resource exist
Concurrent access should leave the resource in a consistent state
The user of DS is not aware of a failure and the recovery from the failure

8. Degree of Transparency
High degree of transparency may be impractical: For example, you travel to Tokyo from Istanbul, you have time difference that may make electronic morning paper irrelevant.
Certain things are impossible to high: signal transfer time, delay caused by high traffic on the shared servers.
Replication is costly in time, because of consistency requirement in all copies.

9. Openness
An open system offers services according to the standard rules that allow interoperability and portability.
It should be possible to built systems out of different components. It should be easy to add new components replace the existing ones.
So, the system should be extensible

10. Scalability With respect to size: more or less users or resources
Geographical: users and resources may be far apart
Administratively: DS may span over more than one administrative bodies

11. Examples of scalability limitations.
Scalability Problems
Concept
Example
Centralized services
A single server for all users
Centralized data
A single on-line telephone book
Centralized algorithms
Doing routing based on complete information
Examples of scalability limitations.

12. Decentralized Algorithms for Scalability
No machine has complete inf about the system
Decision are made on locally available inf
Failure of one machine does not invalidate the system
There is no global clock
Geographic centralization hinders geographic scalability

13. Scaling techniques (1) Asynchronous communication
Moving the processing from server to the client, if it is more efficient. In this case instead of (a) it is more efficient as in (b)
Spreading the work across the system, as in DNS

14. Scaling Techniques (2) 1.4 The difference between letting: a server or
a client check forms as they are being filled

15. An example of dividing the DNS name space into zones.
Scaling Techniques (3)
1.5
An example of dividing the DNS name space into zones.

16. Scaling techniques (4) Replication
Caching, as a special form of replication:
consistency is an important issue in caching
Combination of distribution, replication and caching with appropriate consistency often provide sufficient scalability.

17. False assumptions on developing DS
Network is reliable
Network is secure
Network is homogeneous
Topology does not change
Latency is zero
Bandwidth is infinite
Transport cost is zero
There is one administrator

18. Type of Distributed Systems
Network is reliable
Network is secure
Network is homogeneous
Topology does not change
Latency is zero
Bandwidth is infinite
Transport cost is zero
There is one administrator

19. Hardware Concepts

20. 1.6
Different basic organizations and memories in distributed computer systems

21. A bus-based multiprocessor.
Multiprocessors (1)
1.7
A bus-based multiprocessor.

22. Multiprocessors (2)
1.8
A crossbar switch
An omega switching network

23. Homogeneous Multicomputer Systems
1-9
Grid
Hypercube

24. Software Concepts System Description Main Goal
DOS(Distributed Operating Systems)
Tightly-coupled operating system for multi-processors and homogeneous multicomputers
Hide and manage hardware resources
NOS (Network Operating Systems)
Loosely-coupled operating system for heterogeneous multicomputers (LAN and WAN)
Offer local services to remote clients
Middleware
Additional layer atop of NOS implementing general-purpose services
Provide distribution transparency

25. Uniprocessor Operating Systems
1.11
Separating applications from operating system code through a microkernel.

26. Multiprocessor Operating Systems (1):MONITOR
monitor Counter {
private:
int count = 0;
public:
int value() { return count;}
void incr () { count = count + 1;}
void decr() { count = count – 1;} }
A simple monitor, allowing one access at time: one processes finishes what it is doing, before the other can start
Monitor protects integer count against concurrent access.
A monitor is implemented using semaphores

27. Multiprocessor Operating Systems (2):MONITOR
monitor Counter {
private:
int count = 0;
int blocked_procs = 0;
condition unblocked;
public:
int value () { return count;}
void incr () {
if (blocked_procs == 0)
count = count + 1;
else
signal (unblocked); }
void decr() {
if (count ==0) {
blocked_procs = blocked_procs + 1;
wait (unblocked);
blocked_procs = blocked_procs – 1; }
else
count = count – 1;
A evolved monitor to protect an integer against concurrent access: count is incremented or decremented concurrently and correctly.
Monitor is implemented using semaphores, a process is blocked using condition variables in the Monitor

28. Multicomputer Operating Systems (1)
1.14
General structure of a multicomputer operating system

29. Multicomputer Operating Systems (2)
1.15
Alternatives for blocking and buffering in message passing.

30. Multicomputer Operating Systems (3)
Synchronization point
Send buffer
Reliable comm. guaranteed?
Block sender until buffer not full
Yes
Not necessary
Block sender until message sent No
Block sender until message received
Necessary
Block sender until message delivered
Relation between blocking, buffering, and reliable communications.

31. Pages of address space distributed among four machines
Distributed Shared Memory Systems (1) remote RAM is used as backup storage
Pages of address space distributed among four machines
Situation after CPU 1 references page 10
Situation if page 10 is read only and replication is used

32. Distributed Shared Memory Systems (2)
1.18
False sharing of a page between two independent processes.

33. Network Operating System (1)
1-19
General structure of a network operating system.
Services: rlogin, rcp, file servers,

34. Network Operating System (2)
1-20
Two clients and a server in a network operating system.

35. Network Operating System (3)
1.21
Different clients may mount the servers in different places.

36. Middleware Services Models Distributed file systems
Remote Procedure Calls
Distributed objects
Distributed Documents
Services
Communication
Naming
Persistence
Distributed Transactions
Security

37. Positioning Middleware
1-22
General structure of a distributed system as middleware:communication, naming, data persistence, distributed tx, security.

38. Middleware and Openness: for interoperability
1.23
In an open middleware-based distributed system, the protocols used by each middleware layer should be the same, as well as the interfaces they offer to applications.

39. Comparison between Systems
Item
Distributed OS
Network OS
Middleware-based OS
Multiproc.
Multicomp.
Degree of transparency
Very High
High
Low
Same OS on all nodes
Yes No
Number of copies of OS 1 N
Basis for communication
Shared memory
Messages
Files
Model specific
Resource management
Global, central
Global, distributed
Per node
Scalability
Moderately
Varies
Openness
Closed
Open
A comparison between multiprocessor operating systems, multicomputer operating systems, network operating systems, and middleware based distributed systems.

40. Cluster Computing Systems
Cluster Computing System is a kind of DS
Cluster computing is based on a collection of similar workstations and the same operating systems connected by a high speed LAN
It is used for parallel computing
A true cluster is expected to gibe a transparent process migration

41. Grid Computing Systems
Grid computing has heterogeneity, regarding computers, operating systems, networks, administrative domains, security policies
The heterogeneous resources are provided to a virtual organization that is formed by different users.
The resources are individual computers with possibly different OS, super computers, cluster computers, storage facilities, databases, etc.

42. Transaction based distributed systems
Transaction processing systems with ACID (Atomic, Consistent, Isolated, Durable) property
In such systems nested transactions is possible
Transaction processing monitor is often need to be installed to schedule the nested or concurrent sub transactions
Such applications may employ RPC-Remote Procedure Call, RMI-Remote Method Invocations, or MOM-Message Oriented Message exchange

43. Distributed Pervasive Systems
These are systems are characterized as being populated by relatively small members: that embrace changes in the environment, ad-hoc composition, sharing as default property, and mobile
Examples:
Home systems: self configured and self managed
Electronic health care systems: body area networks-BAN are examples of sensor based such systems that can process data locally or centrally
Sensor networks: management-configuration, aggregation of results, and failure management are important issues to be developed further

44. Clients and Server Models
Client Server model has been agreed on as one of the universal DS model, by many researchers

45. General interaction between a client and a server.
Clients and Servers
1.25
General interaction between a client and a server.

46. An Example Client and Server (1)
The header.h file used by the client and server.

47. An Example Client and Server (2)
A sample server.

48. An Example Client and Server (3)
1-27 b
A client using the server to copy a file.

49. Processing Level
1-28
The general organization of an Internet search engine into three different layers

50. Client Server Arch: Multitiered Architectures (1)
The simplest organization is to have only two types of machines:
A client machine containing only the programs implementing (part of) the user-interface level
A server machine containing the rest,
the programs implementing the processing and data level 50

51. Multi-tiered Architectures:
Vertical: put different components on different machines
Horizontal: clients and servers may be physically split into different parts and distributed to run on own data.
Peer-to-peer: No client server role is taken, the applications cooperate to conduct certain task…

52. Multitiered Architectures (1)
1-29
Two-tiered architecture: Example1 for vertical distribution:
Alternative client-server organizations (a) – (e).

53. Multitiered Architectures (2)
1-30
Three-tiered Architecture: vertical distribution example2
An example of a server acting as a client.

54. An example of horizontal distribution of a Web service.
Modern Architectures
1-31
An example of horizontal distribution of a Web service.

55. Peer-to-Peer as a horizontal distribution
Interaction between the processes is symmetric
Each process is client and server at the same time
Processes are interconnected by a network (overlay network)
They can be structured and unstructured

56. Example: Structured Peer-to-Peer Arc (1)
Figure 2-7. The mapping of data items onto nodes in Chord.
A Dist. Hash Table(DHT) is used
Data key k is mapped to node key id by DHT
The lag uses an order of O(logN) 56

57. Example: Structured Peer-to-Peer Arc: Node management (1)
A node has shortcut to other nodes, that why O(logN)
A node joining system: a node id is inserted between succ(id) and its predecessor in the logical ring

58. Unstructered Peer-to-Peer Arch.
Such networks are based on random organization rather than a virtual structured architecture.
An example : Each node may have a list of random set of so called neighbors
A new node wants join may contact a random alive node
Departing node may just leave, the other nodes adapt in time.

59. Unstructured Peer-to-Peer Architectures (1)
Figure 2-9. (a) The steps taken by the active thread. 59

60. Unstructured Peer-to-Peer Architectures (2)
Figure 2-9. (b) The steps take by the passive thread 60

61. Architecture vs Middleware
Middleware is realized according to different architectures
Architectures may be used to provide adaptability, reconfiguration etc.
Object orientation
Interceptors are used to allow adaptation 61

62. Figure 2-15. Using interceptors to handle remote-object invocations.62

63. General Approaches to Adaptive Software
Three basic approaches:
Separation of concerns, based on functionality
Computational reflection: inspect and itself and adapt accordingly
Component-based design: adaptation through comostion… 63

64. Self-Management in Distributed Systems-SMDS
Self-healing
Self-configuring
Self-optimizing
Feedback control loop can be used to self-manage 64

65. SMDS-The Feedback Control Model
Figure The logical organization of a
feedback control system. 65

66. Astrolabe: general monitoring of a very large system
SMDS- Example1
Astrolabe: general monitoring of a very large system
A large collection of hosts into a hierarchy of zones of increasing size
Every host runs an agent process that collect information about zone
The agents communicate to spread the local information 66

67. Example: Systems Monitoring with Astrolabe
Figure Data collection and information aggregation in Astrolabe. 67

68. SMDS- Example2 Globule: Collaborative content distribution network
End-user servers collaborate to optimize the performance to optimize performance through replication of web pages
A replication policy is required based on some performance metric
It is possible to choose the best policy, among the many. Each policy may depend on the history of requests 68

69. Example: Differentiating Replication Strategies in Globule (1)
Figure The edge-server model assumed by Globule.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved 69

70. Example: Differentiating Replication Strategies in Globule based on history(2)
Figure The dependency between prediction accuracy and trace length. 70

71. SMDS- Example3-1
Jade:
JADE (Java Agent DEvelopment Framework) is a software Framework fully implemented in Java language.
It simplifies the implementation of multi-agent systems through a middle-ware that complies with the FIPA -Foundation for Intelligent Physical Agents specifications and through a set of graphical tools that supports the debugging and deployment phases. 71

72. SMDS- Example3-2
The agent platform can be distributed across machines (which not even need to share the same OS) and the configuration can be controlled via a remote GUI.
The configuration can be even changed at run-time by moving agents from one machine to another one, as and when required.
JADE is completely implemented in Java language and the minimal system requirement is the version 1.4 of JAVA (the run time environment or the JDK). 72

73. SMDS- Example3-3: automatic repair
Jade is used to monitor a component based computer cluster system
Servers are built by Jade agents and maintained by Jades:
Terminate every binding of node to leave the network
Start and add a new node
Configure a new node to replace a crashed node
Integrate a new node into the system 73