1. 1 Distributed systems By. Issa Al smadi

2. 2 Distributed Systems  Definitions  “ A system in which hardware or software components located at networked computers communicate and coordinate their actions only by message passing. ” [Coulouris]  “A system that consists of a collection of two or more independent computers whish coordinate their processing through the exchange of synchronous or asynchronous message passing.”  “ A distributed system is a collection of independent computer.” [ Tanenbaum ].  “A distributed system is a collection of independent computer linked by a network with software designed to produce an integrated computing facility.”

3. 3 What is a Distributed System ? Some comments : System architecture: the machines are autonomous ; this means they are computers which, in principle, could work independently; The user’s perception : the distributed system is perceived as a single system solving a certain problem (even though, in reality we have several computers placed in different locations). By running a distributed system software the computers are enabled to : -coordinate their activates -share resources: hardware, software, data

4. 4 Reasons for Distributed Systems 1. Functional distribution : computers have different functional capabilities ─ Client / server ─ Host / terminal ─ Data gathering / data processing 2. Load distribution / balancing : assign tasks to processors such that the overall system performance is optimized.

5. 5 Reasons for Distributed Systems 3. Replication of processing power : independent processors working on the same task: distributed systems consisting of collections of microcomputers may have processing powers that no supercomputer will ever achieve 10000 CPUs, each running at 50 MIPS, yields 500000 MIPS, then instruction to be executed in 0.002 nsec, equivalent to light distance of 0.6 mm – any processor chip of that size would melt immediately 4. Physical separation: systems that rely on the fact that computers are physically separated (e.g., to satisfy reliability requirements). 5. Economics: collections of microprocessors offer a better price / performance ration than large mainframes (mainframes: 10 times faster, 1000 times as expensive)

6. 6 Disadvantages of Distributed System Difficulties of developing distributed software : how should operating systems, programming languages and applications look like ? Networking problems: several problems are created by the network infrastructure, which have to be dealt with : loss of messages, overloading,.. Security problems: sharing generates the problem of data security.

7. 7 Examples of Distributed Systems 1-The internet -Heterogeneous network of computers and applications -Implemented through the internet Protocol Stack -Typical configuration :

8. 8 Examples of Distributed Systems Characteristics of Internet Very large and heterogeneous Enables email, file transfer, multimedia communications, WWW, … Open-ended Connects intranets (via backbones) with home users (via modems, ISPs )

9. 9 Examples of Distributed Systems 2- Intranets -Locally administered network -Usually proprietary ( e.g., the University campus network ( -Interface with the Internet firewalls - Provides services internally and externally

10. 10 Characteristics of intranets Several LANs linker by backbones Enables info. Flow within organization - Electronic data, documents, … Provides services - Email, file, print services, … Often connected to Internet via router In / out communications protected by firewall

11. 11 Examples of Distributed Systems 3- Mobile and Computing Systems 1- Cellular phone system (e.g., GSM, UMTS) Resources being shared Radio frequencies The mobile on the move 2- Laptop computers Wireless LANs (uni campus WLAN soon to come here?) 3- Handheld devices, PDAs etc.

12. 12 Mobile & computing  Wireless LANs (WLANs) -Connectivity for portable devices (laptops, PDAs, mobile phones, video / dig. Cameras,…) -WAP (Wireless Applications Protocol)  Home intranet -Devices embedded in home appliances (hi-fi, washing machines) -Universal ‘remote control’ + communication

13. 13 Examples of Distributed Systems 4- Embedded Systems 1-Avionics ( airplanes engineering ) control system Flight management systems in aircraft 2-Automotive control system Mercedes S-Class automobiles these days are equipped with 50+ autonomous embedded processors Connected through proprietary bus-like LANs 3-Consumer Electronics Audio HiFi equipment

14. 14 Examples of Distributed Systems 5- Network file Systems 1- Architecture to access file systems across a network 2- Famous example Network File System (NFS), originally developed by SUN Microsystems for remote access support in a UNIX context FTP 6- The World Wide Web 1- Open client-server architecture implemented on top of the Internet 2- Shared resources Information, uniquely identified through a Uniform Resource Locator (URL)

15. 15

16. 16 Computer network vs. Distributed Systems  Computer network :the autonomous computers are explicitly visible (have to be explicitly addressed)  Distributed System : existence of multiple autonomous computer is transparent  However -Many problems in common -In some sense networks (or parts of them, e.g., name services) are also distributed systems, and - Normally, every distributed system relies on services provided by a computer network.

17. 17 Challenges in the design of Distributed Systems 1.Heterogeneity of: Distributed applications are typically heterogeneous: –Different hardware : mainframes, workstations, PCs, servers, etc.; –Different software : UNIX,MS Windows,IBM OS/2, Real-time OSs, etc.; –Unconventional devices : teller machines, telephone switches, robots, etc. –Diverse networks and protocols: Ethernet, FDDI, ATM, TCP/IP –Different Programming language (in particular, data representations). The solution: Middleware (e.g., CORBA) : transparency of network, hardware and software and programming language heterogeneity. Mobile Code (e.g., java) ; transparency from hardware and software and programming language heterogeneity through virtual machine concept.

18. 18 Challenges in the design of Distributed Systems 2.Openness One of the important features of distributed systems is openness and flexibility : -Ensure extensibility and maintainability of systems -Every service is equally accessible to every client (local or remote). -It is easy to implement, install and debug new services -Users can write and install their own services. Key aspect of openness: –Standard interfaces and protocols (like internet communication protocols) –Support of heterogeneity (by adequate middleware, like CORBA)

19. 19 Application & services Middleware Operating system Hardware: Comp.&NW Platform 1 Platform 2 Node 1Node 2 The same looking at two distributed nodes Operating system Hardware: Comp.&NW Openness ( cont’d )

20. 20 Software Architecture Application & services Middleware Operating system Hardware and computer networked The platform Openness ( cont’d )

21. 21 Challenges in the design of Distributed Systems 3.Security -Privacy -Authentication -Confidentiality : Protection against disclosure to unauthorized person. - Integrity: protection against alteration and corruption. - Availability: Keep the resource accessible

22. 22 Challenges in the design of Distributed Systems 4. Scalability The system should remain efficient even with a significant increase in the number of users and resources connected; - cost of adding resources should be reasonable -Performance loss with increased number of users and resources should be controlled -Software resources should not run out (number of bits allocated to addresses, number of entries in tables, etc.) Solution: IP addresses: from 32 to 128 bits

23. 23

24. 24 Challenges in the design of Distributed Systems 5. Handling of failures -Detection (may be impossible) -masking retransmission Redundancy of data storage -Tolerance Exception handling (e.g., timeouts when waiting for a web resource) -redundancy Redundant routes in network 6. Concurrency - Try to Avoid of dead e lock problems.

25. 25 Challenges in the design of Distributed Systems 7. Performance Several factors are influencing the performance of a distributed system : 1.The performance of individual workstations. 2.The speed of the communication infrastructure. 3.Extent to which reliability (fault tolerance ) is provided (replication and preservation of coherence imply large overheads). 4.Flexibility in workload allocation: for example, idle processors ( workstations) could be allocated automatically to a user’s task.

26. 26 Challenges in the design of Distributed Systems 8. transparency: concealing the heterogeneous and distributed nature of the system so that it appears to the user like one system. -Transparency categories ( according to ISO’s Reference Model for ODP, quoted after [Coulouris ]) 1. Access :access local and remote resources using identical operations * e.g., network mapped drive using samba server, NFS mounts 2. Location : access without knowledge of location of a resource * e.g., URLs, email addresses

27. 27 transparency ( cont’d ) 3.Concurrency : allow several processes to operate concurrently using shared resources in a consistent fashion 3.Replication : The system is free to make additional copies of files and other resources (for purpose of performance and / or reliability ), without the users noticing. Example :several copies of a file; at a certain request that copy is accessed which is the closest to the client. 5.Failure : allow programs to complete their task despite failures retransmit of email messages

28. 28 6- Mobility : Resources should be free to move from one location to another without having their names changed 7- Performance: adaptation of the system to varying load situations without the user noticing it. This could be achieved by automatic reconfiguration as response to changes of the load ; it is difficult to achieve 8- Scaling : allow system and applications to expand without need to change structure or application algorithms

29. Distributed Computing Systems29 Forms of Transparency in a Distributed System TransparencyDescription Access Hide differences in data representation and how a resource is accessed LocationHide where a resource is located MigrationHide 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 Hide that a resource may be shared by several competitive users FailureHide the failure and recovery of a resource Persistence Hide whether a (software) resource is in memory or on disk

30. 30` Communication Components of a distributed system have to communicate in order to interact. This implies support at two levels : 1.Networking infrastructure (interconnections & network software). 2.Appropriate communication primitives and models and their implementation:  Communication primitives:  Send  Receive  Remote procedure call (RPC)  Communication models - Client-server communication: implies a message exchange between two processes : the process which requests a service and the one which provides it; - Group multicast : the target of a message is a set of processes, which are members of a given group. message passing

31. 31 Models

32. 32 Overview System architecture Software layer Architecture models –Client-server, peer processes,… –Mobile code, agents Design requirements –User expectations of the system

33. 33 Scanner Data base server Mainframe Printer service Customer service Distributed design

34. 34 Distribute Systems are foremost highly complex software systems -Nortel network DMS-100 switch:25-30 million lines of code,3000 software developers,20 years life cycle to date. -Motorola:20% of engineers produce hardware,80% produce software -Subject to all kinds of software engineers problems Investigation of software Architecture to deal with design challenges - “…….include the organization of a system as composition of component:global control structure the protocols for communication,synchronization,and data access:the assignment of functionality to design elements the composition of design elements physical distribution scaling and performance dimension of evolution and selection among design alternatives this is the software architecture level of design “[garlan and Shaw] Architecture paradigms pertinent to distributed systems - layers - client-server Architecture

35. 35 basic idea -Breaking up the complexity of systems by designing them through layers and services -layer: group of closely related and highly coherent functionalities -service: functionalities provided to superior layer Example of layered architecture -operating system, ( Kernel, other services )historical :the operating system -computer network protocol architectures Layer n+1 Layer n Layer n-1 Layers

36. 36 Typical layering in Distributed systems -platform :Hardware and operating system -windows NT / Pentium processor Application service Middleware Operating system Computer and network hardware platform Layers

37. 37 Software Layers Applications Middleware Operating system Computer and network hardware Language an runtime support for program interaction Conventional and distributed application platform Responsible for basic local resource management memory allocation protection Extend services available to those of the distributed system Open ( distributed ) services

38. 38 Software Layers Service Layers Higher-level access services at lower layer Services can be located on different computers process type: -server process -client process -peer process

39. 39 Terminology Server: process that accepts requests from other processes & interacts with other servers and client processes to provide a consistent view of its services Platform: low-level layers that provide services to other higher layers & bring to them a system ’ s programming interface for communication & coordination between processes

40. 40 Terminology Middleware: a layer of software whose purpose is to mask heterogeneity & provide a unified distributed programming interface to application programs by providing useful building blocks & communication mechanisms Examples: sun RPC, java RMI, CORBA Limitations: require application level involvement in some tasks like error corrections and security

41. 41 1- Platform lowest-level hardware + software common programming interface, different implementation of operating system facilities for co-ordination & communication Important Layers

42. 42 Important Layers 2- Middleware Achieve transparency of heterogeneity at platform level programming support for distributed computing Middleware provides support for distributed process/objects: -suitable for application programming -communication via –remote method invocation (Java RMI),or –remote procedure call(sun RPC) services infrastructure for application programs - security, transaction, event, notification,…. -products :CORBA,DCOM

43. 43 Models can be used to provide an abstract and simplified description of certain relevant aspects of distributed systems. Model types: 1.Architectural models define the way responsibilities are distributed among components and how they are placed in the systems. Three architectural models: 1.Client-server model 2.Proxy server 3.Peer processes Models

44. 44 2. Interaction models deal with how time is handled throughout the system. Two interaction models have been introduced: 1.Synchronous distributed systems 2.Asynchronous distributed systems 3. Failure models: The failure model specifies what kind of failures can occur and what their effects are. 1.Omission failures 2.Arbitrary failures 3.Timing failures Models

45. 45 Architectural models Define -software component (processes,objects) -ways in which components interact -mapping of components onto the underlying network Why needed? -to handle varying environments and usage -to guarantee performance

46. 6/10/2016Leon Jololian/George Blank46 Client/Server Performance Performance, scalability and mobility of the client/server model can be improved by –Partitioning or replicating data on servers –Caching data at proxy servers or clients –Using mobile code and mobile agents

47. 47 1- Client Server System 1.1 One Tier Architecture Network computer Or PC’s with terminal emulation Presentation ( to clients ) + processing ) transactions, applications ) + data ( management & access ) Architectural models

48. 48 workstation Presentation + processingData ( remote data access ) Or presentation Data processing ( Remote procedure call ) Client-Server “ fat client “ Or “ fat server” 1- Client Server System 1.2 Two Tier Architecture Architectural models

49. 49 clients presentation Shared application services processing data Remote data access Procedure call Remote data access or Transaction processing Shared Data services Two tier is satisfactory for simple client- server application, but more demanding transaction processing application 1- Client Server System 1.3 Three Tier Architecture Architectural models Architectural

50. 50 Basic model  client :process wishing to access data use resources or perform operation on different computer  server : process managing data and all others shared resources amongst server and allow clients access to resource and performs computation  interaction : invocation / result message pairs client Server Client Server invocation result Client - server

51. 51 -service provided by multiple servers Examples : many commercial webs services are implemented through different physical server -performance (e.g CNN.com,down load servers,etc) -reliability ° Server maintain either replicated or distributed database client server Service Variants

52. 52 Variants - proxy servers : render replication / distributedness transparent - Caching -proxy server maintains cache store of recently requested resources -frequently used in search - engines: Google Google (if we search for any page It may take 0.2 sec to find it, but at second search it will take 0.04 sec client Proxy server Web server Web server Client - server

53. 53 A proxy server provides copies (replication) of resources which are managed by other servers. Proxy servers are typically used as caches for web resources they maintain a cache of recently visited web pages or other resources. Proxy server can be located at each client or can be shared by several client. The purpose is to increase performance and availability, by avoiding frequent accesses to remote servers. client server Proxy server proxy server

54. 54 Further variants of client-server model -mobile code code that is sent to a client process to carry out a specific task - Examples Applets active messages(containing communications protocol code) mobile agents - executing program (code+data),migrating amongst processes,carrying out of an autonomous task, usually on behalf of some other process. - Advantages :flexibility,savings in communications cost Client - server

55. Software layer that supports a window-based user interface on a local computer while executing application programs on a remote computer. Same as the network computer scheme but instead of downloading the applications code into the user’s computer, it runs them on a server machine, compute server. Compute server is a powerful computer that has the capacity to run large numbers of applications simultaneously. Disadvantage: Increasing of the delays in highly interactive graphical applications Client-server Model Variations (Thin Clients) 55

56. 56 Thin clients executing windows -based user interface on local computer while application executes on computer server. -example : X11 server (run on the application client side) mobile devices for mobile computing -personal digital assistance ( PDAs) -how to connect to internet wireless LANs/MANs wireless Personal Area Networks

57. 57 Further variants of client-server model -spontaneous networking - characteristics * W-LAN confronted with constantly changing set of heterogeneous mobile devices * Devices roaming in heterogeneous W-LAN environments - Benefits * no need for wire line connection * Easy access to locally available services Music service gateway Internet Alarm server discovery service TV/PC Hotel wireless Camera PDA laptop Guest device Client - Server

58. 58 ● Further variant of client - server mode * spontaneous networking - Challenges 1. support for convenient (easy) connection and integration: ● internet assumes device has IP address in fixed sub-network 2. Intermittent (distortions ) connectivity of devices ● unavailable when in tunnels, airplanes,etc. 3. Privacy ubiquity of location information 4.security 1- access to device 2- access right in dynamic Music service gateway Internet Alarm server discovery service TV/PC Hotel wireless Camera PDA laptop Guest device Client - server

59. 59 Further variant of client - server mode * spontaneous networking - Discovery services *services available in the network * their properties,and how to access them ( including device-specific driver information ) - Interfaces of discovery services * registration service accept registration requests from servers, stores properties in database of currently available services * lookup services match requested services with available services Music service gateway Internet Alarm server discovery service TV/PC Hotel wireless Camera PDA laptop Discovery service Client - server

60. Architectures Design Requirements Performance Issues: –Considered under the following factors: Responsiveness: –Fast and consistent response time is important for the users of interactive applications. –Response speed is determined by the load and performance of the server and the network and the delay in all the involved software components. –System must be composed of relatively few software layers and small quantities of transferred data to achieve good response times. Throughput: –The rate at which work is done for all users in a distributed system. Load balancing: –Enable applications and service processes to proceed concurrently without competing for the same resources. –Exploit (مأثرة)available processing resources. 60

61. Quality of Service: –Main system properties that affect the service quality are: Reliability: related to failure fundamental model (discussed later). Performance: ability to meet timeliness guarantees. Security: related to security fundamental model (discussed later). Adaptability: ability to meet changing resource availability and system configurations. Dependability issues: –Achieved by: Fault tolerance: continuing to function in the presence of failures. Security: locate sensitive data only in secure computers. Correctness of distributed concurrent programs: research topic. Architectures Design Requirements 61

62. 62 Interfaces use of client-server architecture has impact on the software architecture used -what are the synchronization mechanisms between client and server -admissible types of request/responses Design challenges quality of service - performance 1- response times 2- throughput - adaptability dependability - fault tolerance : system is expected to continue to function correctly in the presence of fault - security Client - server

63. 63 Performance characteristics of communication channels * latency: delay between sending and receipt of message - network access time (e.g, Ethernet retransmission delay) - time for first bit to travel from senders network interface to receivers network interface - processing time with in the sending and receiving processes * throughput: number of unit (e.g, packets) delivered per time unit * band width: amount of information (e.g,bits) transmitted per time unit * delay jitter : variation in delay between different message of the same type (e.g,video frames in ATM networks) Fundamental interaction Model

64. Interacting processes in a distributed system are affected by two significant factors: 1. Performance of communication channels: is characterized by: Latency: delay between sending and receipt of a message including –Network access time. –Time for first bit transmitted through a network to reach its destination. –Processing time within the sending and receiving processes. Throughput: number of units (e.g., packets) delivered per time unit. Bandwidth: total amount of information transmitted per time unit. Jitter: variation in the time taken to deliver multiple messages of the same type (relevant to multimedia data). Fundamental Models (Interaction Model) 64

65. 65 Interaction Model 2. Computer clocks Clock drift rate: relative amount a computer clock differs from a perfect reference clock Clock corrections can be made by sending messages which will still be affected by network delays

66. 66 synchronous distributed system * time to execute each step of computation within a process has known lower and upper bounds * message delivery times are bounded to known value * each process has a clock whose drift rate from real times is bounded by a known value Asynchronous distributed system : (no bounds on) * process execution times * message delivery times * clock drift rate Note * synchronous distributed systems are easier to handle but determining realistic bounds can be hard or impossible * asynchronous systems are more abstract and general : a distributed algorithm executing on one system is likely to also work on another one Fundamental interaction Model

67. 67 Main features: lower and upper bounds on execution time of processes can be set transmitted messages are received within a known bounded time drift rates between local clocks have a known bound Important consequences : 1. Only synchronous distributed system have a predictable behavior in terms of timing only such systems can be used for hard real-time application 2. In a synchronous distributed system it is possible and safe to use timeouts in order to detect failures of a process or communication link. ** it is difficult and costly to implement synchronous distributed systems. Synchronous Distributed Systems

68. 68 * Many distributed systems (including those on the internet) are asynchronous. No bound on process execution time (nothing can be assumed about speed, load, reliability of computers). No bound on message transmission delays(nothing can be assumed about speed, load, reliability of interconnections). No bounds on drift rates between local clocks. Important consequences: 1. In an asynchronous distributed systems there is no global physical time Reasoning can be only in terms of logical time 2. Asynchronous distributed systems are unpredictable in terms of timing. 3. No timeouts can be used. Asynchronous Distributed Systems

69. Event ordering: when need to know if an event at one process (sending or receiving a message) occurred before, after, or concurrently with another event at another process. It is impossible for any process in a distributed system to have a view on the current global state of the system. The execution of a system can be described in terms of events and their ordering despite the lack of accurate clocks. Logical clocks define some event order based on causality. Logical time can be used to provide ordering among events in different computers in a distributed system (since real clocks cannot be synchronized). Fundamental Models (Interaction Model) 69

70. Fundamental Models (Interaction Model) Real-time ordering of events 70

71. 71

72. 72 Lamport defined the happened before relation (denoted as “ “), which describes a casual ordering of events: (1) if a and b are events in the same process, and a occurred before b, then a b (2) if a is the event of sending a message m in one process, and b is the event of receiving that message m in another process, then a b (3) if a b, and b c, then a c (i.e., the relation “ “ is transitive Causality: * past events influence future events * this influence among casually related events (those that can be ordered by “ “ ) is referred to as casual affects * if a b, event a casually affects event b The “Happened Before “ Relation

73. 73 What kind of failures can occur and what are there effects ? Omission failures Arbitrary failures Timing failures ** Failures can occur both in processes and communication channels,the reason can be both software and hardware. ** Failure models are needed in order to build systems with predictable behavior in case of failures (systems which are fault tolerant ). Failure Models

74. 74 Omission failure A processor or communication channel fails to perform actions it is supposed to do. This means that the particular action is not performed ! We do not have an omission failure if : An action is delayed (regardless how long) but finally executed. An action is executed with an erroneous result. If we are sure that messages arrive, a timeout will indicate that the Sending process has crashed. Such a system has a fail-stop behavior

75. 75 Omission Failures ●Process omission failures: process crashes Detection with timeouts Crash is fail-stop if other processes can detect with certainty that process has crashed ●Communication omission failures: message is not being delivered (dropping of messages) possible causes: Network transmission error Receiver incoming message buffer overflow Arbitrary failures ( Any type of error can occur in processes or channels (worst).) Process: omit intended processing steps or carry out unwanted ones ● Communications channel: e.g., non-delivery, corruption or duplication Process p Send mReceive Process q Communication channel Outgoing message buffer Incoming message buffer Failures

76. 76 Class of failure Affects description Fail-stop process process halts and remains halted. Other processes may detect this state Crash process Process halts and remains halted. Other processes may not be able to detect this state. Omission Channel A message inserted in an outgoing message buffer never arrives at the other end’s incoming message buffer Send-omission process A process completes a send, but the message is not put in it’s outgoing message buffer Receive-omission process A message is put in process’s incoming message buffer, but that process does not receive it. Arbitrary (Byzantine) Process or channel Process/channel exhibits arbitrary behavior: it may send/transmit arbitrary message at arbitrary times. Commit omissions: a process may stop or taken an incorrect step. Failures

77. Timing failures 77 description AffectsClass of Failure Process’s local clock exceeds the bounds on its rate of drift from real time. Process Clock Process exceeds the bounds on the interval between two steps. Processperformance A message’s transmission takes longer than the stated bound channel performance

78. Security Model 78 The security of a DS can be achieved by securing the processes and the channels used in their interactions and by protecting the objects that they encapsulate against unauthorized access.

79. 79 Performance Responsiveness - fast interactive response delayed remote requests -use of caching, replication Throughput -dependent on speed of server and data transfer Load balancing -Use of applets, multiple servers

80. 80 To model security threats, we postulate an enemy that is capable of sending any process or reading/copying message between a pair of processes Threats form a potential enemy: threats to processes, threats to communication channels, and denial of service.

81. 81 Object Interaction: RMI and RPC

82. 82 Overview Distributed applications programming - distributed objects model - RMI, invocation semantics - RPC Products - Java RMI,CORBA,DCOM - Sun RPC - JINI

83. 83 Why Middleware? Location transparency - client/server need not know their location Sits on top of OS, independent of: - communication protocols: use abstract request-reply protocols over UDP,TCP - computer hardware: use external data representation e.g. CORBA CDR - operating system: use e.g. socket abstraction available in most systems - programming language: e.g. CORBA supports Java, C++

84. 84 Middleware Layer Applications Request-reply protocol External data representation RMI, RPC and events Operating System Middleware layer

85. 85 Objects Objects = data + methods Interact via interfaces: - define types of arguments and exceptions of methods Data Implementation of methods object Data Implementation of methods object interface m1 m2 m3 m4 m5

86. 86 The object model Programs logically partitioned into objects - distributing objects natural and easy Interfaces - the only means to access data, make them remote? Actions - via method invocation - interaction, chains of invocations - may lead to exceptions, part of interface Garbage collection - reduced effort, error-free (Java, not C++)

87. 87 The distributed object model Objects distributed (client-server models) Extend with - Remote object reference - Remote interfaces - Remote method invocation (RMI) A B C D E REMOTE INVOCATION LOCAL INVOCATION LOCAL INVOCATION LOCAL INVOCATION F REMOTE INVOCATION

88. 88 Advantages of distributed objects Data encapsulation gives better protection - concurrent processes, interference Method invocations - can be remote or local Objects - can act as clients, servers, etc - can be replicated for fault-tolerance and performance - can migrate, be cached for faster access

89. 89 Remote Object Reference Object References - used to access objects which live in processes - can be passed as arguments, stored in variables,… Remote Object References - object identifiers in a distributed system - must be unique in space and time - error returned if accessing a deleted object - can allow relocation

90. 90 Constructing unique remote object reference - IP address, port, interface name - time of creation, local object number (new for each object) Use the same as for local object references If used as addresses - cannot support relocation Interface of remote object Object number timePort numberInternet address 32 bit 32 bit 32 bit 32 bit Remote Object Reference

91. 91 Remote interfaces Specify externally accessed - variables and procedures - no direct references to variables (no global memory) - local interface separate Parameters - input, output or both, - instead of call by value, call by reference No pointers No constructors

92. 92 Remote Object and its interfaces CORBA: Interface Definition Language (IDL) Java RMI: as other interfaces, keyword remote m1 m2 m3 Data Implementation Of method Remote object m4 m5 m6 Local interface Remote interface

93. 93 Handling remote objects Exceptions - raised in remote invocation - clients need to handle exceptions - timeouts in case server crashed or too busy Garbage collection - distributed garbage collection may be necessary - combined local and distributed collector

94. 94 RMI issues Local invocations -executed exactly once Remote invocations - via Request-Reply - may suffer from communication failures! retransmission of request/reply message duplication, duplication filtering - no unique semantics...

95. 95 Fault tolerance measures Invocation semantics Retransmit request Duplicate Re-execute procedure message filtering or retransmit reply No Not applicable Not applicable Maybe Yes No Re-execute procedure At-least-once Yes Yes Retransmit reply At-most-once Re-executing a method sometimes dangerous... Invocation semantics summary

96. 96 Maybe invocation Remote method - may execute or not at all, invoker cannot tell - useful only if occasional failures Invocation message lost… - method not executed Result not received… - was method executed or not? Server crash… - before or after method executed? - if timeout, result could be received after timeout...

97. 97 At-least-once invocation Remote method - invoker receives result (executed exactly) or exception (no result, executed once or not at all) - retransmission of request message Invocation message retransmitted… - method may be executed more than once - arbitrary failure (wrong result possible) - method must be idempotent (repeated execution has the same effect as a single execution) Server crash… - dealt with timeouts, exceptions

98. 98 At-most-once invocation Remote method - invoker receives result (executed once) or exception (no result) - retransmission of reply & request messages - duplicate filtering Best fault-tolerance… - arbitrary failures prevented if method called at most once Used by CORBA and Java RMI

99. 99 Transparency of RMI should remote method invocation be same as local? – Same syntax – need to hide data marshalling IPC calls locating/contacting remote objects Problems – different RMI semantics? susceptibility to failures? – Protection against interference in concurrent scenario? Approaches (Java RMI) – transparent,but express differences in interfaces – provide recovery features

100. 100 Implementation of RMI Skeleton &dispatcher for B’s class Client object A proxy for B Request Reply Remote object B Remote reference module Communication module Communication module Remote reference module Server Object A invokes a method in a remote object B: communication module reference module,RMI software.

101. 101 Communication modules Reside in client and server Carry out Request-Reply jointly – use unique message ids (new integer for each message) – implement given RMI semantics Server’s communication module – selects dispatcher within RMI software – converts remote object reference to local

102. 102 Remote reference module Creates remote object references and proxies Translates remote to local references (object table): – correspondence between remote and local object references (proxies) Directs requests to proxy (if exists) Called by RMI software – when marshalling / unmarshalling

103. 103 RMI Software architecture Proxy – behaves like local object to client – forwards requests to remote object Dispatcher – receives request – selects method and passes on request to skeleton skeleton – implements methods in remote interface – unmarshals data, invokes remote object – Waits for result, marshals it and returns reply

104. 104 Remote Procedure Call (RPC) RPC – historically first,now little used – over Request-Reply protocol – usually at-least-once or at-most-once semantics – can be seen as a restricted form of RMI –sun RPC RPC software architecture – similar to RMI (communication,dispatcher and stub in place of proxy / skeleton)

105. 105 RPC client and server Client process Client stub procedure Client program Communication module Request Reply Communication module dispatcher Service procedure Server stub procedure Server process Implemented over Request-Reply protocol

106. 106Summary Distributed object model – capabilities for handling remote objects (remote references,etc) – RMI:maybe,at-least-once,at-most-once semantics – RMI implementation,software architecture Other distributed programming paradigms – RPC,restricted form of RMI, less often used – event notification (for heterogeneous,asynchronous systems)