Distributed systems by G8sE0Un


									    Distributed systems

        By. issa al smadi

                Distributed Systems

   “ 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.”
         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

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

     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)

          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,

Security problems: sharing generates the problem of data security.

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

     Examples of Distributed Systems

•Characteristics of Internet
 •Very large and heterogeneous

 •Enables email, file transfer, multimedia communications, WWW, …


 •Connects intranets (via backbones) with home users (via modems,

          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

             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

      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.

                   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

            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

        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
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

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
    -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.

     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,
    – Unconventional devices : teller machines , telephone switches,
        robots, etc.
    – Diverse networks and protocols: Ethernet, FDDI, ATM, TCP/IP
    – Different Programming language (in particular, data
    The solution:
          •   Middleware (e.g., CORBA) : transparency of network ,
              hardware and software and programming language
          •   Mobile Code (e.g., java) ; transparency from hardware and
              software and programming language heterogeneity through
              virtual machine concept.
     Challenges in the design of Distributed Systems
    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
    –        Support of heterogeneity (by adequate middleware, like CORBA)

               Openness ( cont’d )
The same looking at two distributed nodes

                     Application & services


         Operating                                 Operating
                         Platform 1

                                      Platform 2
          system                                    system

        Hardware:                                  Hardware:
        Comp.&NW                                   Comp.&NW
           Node 1                                     Node 2

             Openness ( cont’d )
Software Architecture

             Application & services


             Operating system

                                            The platform

          Hardware and computer networked

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

   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.)
           •IP addresses: from 32 to 128 bits

Challenges in the design of Distributed Systems

5. Handling of failures
      -Detection (may be impossible)
          •Redundancy of data storage
          •Exception handling (e.g., timeouts when waiting for a web resource)
          •Redundant routes in network

6. Concurrency
       - Try to Avoid of dead e lock problems.

  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
   4. Flexibility in workload allocation: for example, idle processors
      ( workstations) could be allocated automatically to a user’s

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
            * 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

            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

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

     Forms of Transparency in a Distributed
       Transparency     Description

                        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

                        Hide that a resource may be moved to another location
                        while in use
                        Hide that a resource may be shared by several
                        competitive users
                        Hide that a resource may be shared by several
                        competitive users

       Failure          Hide the failure and recovery of a resource

                        Hide whether a (software) resource is in memory or on
27                    Distributed Computing Systems
•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
    Communication primitives:
                        message passing
         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,
      `28which are members of a given group .

•System architecture

•Software layer

•Architecture models
   –Client-server , peer processes,…
   –Mobile code , agents

•Design requirements
   –User expectations of the system

                   Distributed design
Customer service


                                          Data base server


                                  Printer service

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
•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

                                     Layer n+1

                                        Layer n

                                      Layer n-1

•Example of layered architecture
-operating system, ( Kernal , other services )historical :the THE operating system
-computer network protocol architectures
•Typical layering in Distributed systems

              Application service


               Operating system

        Computer and network hardware        platform

-platform :Hardware and operating system
-windows NT / Pentium processor

                                  Software Layers

Language an runtime support for                                            Extend services available to
     program interaction                                                  those of the distributed system

                                                   Open ( distributed )

     and                            Operating system
 distributed                                           platform
                             Computer and network hardware

Responsible for basic
    local resource
management memory
allocation protection
                 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

               Important Layers

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

                        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


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


     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

                   Architectural models

Architectural models

         -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

     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

42                  Leon Jololian/George Blank     2/7/2013
                   Architectural models
1- Client Server System
1.1 One Tier Architecture

                             Presentation ( to clients )
 Network computer Or PC’s    + processing )transactions , applications )
 with terminal emulation     + data ( management & access )

                        Architectural models
  1- Client Server System
   1.2 Two Tier Architecture

                                                                “ fat client “
workstation                                                    Or “ fat server”

       Presentation + processing   Data ( remote data access )

          Or presentation
                                   Data processing
                                   ( Remote procedure call )

                      Architectural models
1- Client Server System
                                         Two tier is satisfactory for simple client-
1.3 Three Tier Architecture              server application , but more demanding
                                         transaction processing application

                              Shared application
                                                                          Shared Data
   clients                    services

                                  processing                data

             Remote data access                Remote data access or
  45         Procedure call                    Transaction processing
                         Client - server
Basic model

                     invocation            invocation

                client                                  Server
                         result   Server


       :process wishing to access data use resources or
 client
perform operation on different computer
 server : process managing data and all others shared
resources amongst server and client allow     clients
access to resource and performs computation
 interaction :invocation / result message pairs
•-service provided by multiple servers                 Service




Examples : many commercial webs services are implemented through different
physical server

          -performance (e.g CNN.com,down load servers,etc)
° Server maintain either replicated or distributed database
                         Client - server
-proxy   servers : render replication / distributedness transparent

                              client                                   Web

-Caching                                                               Web
-proxy server maintains cache store of recently requested resources
-frequently used in search - engines:

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

                             proxy server
A proxy server provides copies (replication) of resources which are managed by other

             client                                          server
             client                                           server

• Proxy servers are typically used as caches for web resources they maintain a cache
of recently visited web pages or other resources.
when a request is issued by a client the proxy server is first checked if the requested
object (information item) is available there .
• 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
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
                     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

                            Client - Server
                                                          service              Alarm
                                        gateway                                server

                             Internet                Hotel wireless
                                                                      laptop    PDA     Guest device
• 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

                                    Client - server
                                                         service              Alarm
                                        gateway                               server

                             Internet               Hotel wireless
                                                                                       Guest device
●     Further variant of client - server mode          TV/PC         laptop    PDA

* spontaneous networking


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
                                      Client - server
                                               service             Alarm
                       gateway                                     server

            Internet                   Hotel wireless

                       discovery                                   Camera
                         service                                    PDA
                        service           TV/PC           laptop
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
 * lookup services
 match requested services with available services
                            Client - server
 • 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

  - reliability
  - adaptability

• dependability
   - fault tolerance : system is expected to continue to function correctly in the
         presence of fault
   - security
          Fundamental interaction Model
• 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
  * delay jitter : variation in delay between different message of the
                  same type (e.g,video frames in ATM networks)

         Fundamental interaction Model
synchronous distributed system
  * time to execute each step of computation within a process has known lower and upper
  * 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
   Synchronous Distributed Systems
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.

 Asynchronous Distributed Systems
* Many distributed systems (including those on the internet) are
    • 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.
  The “Happened Before “ Relation
• 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
    * 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
                          Failure Models

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 ).

                    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

          Process p                                                     Process q

    Outgoing       Send m                                                      Receive
    message buffer

                                    Communication channel
Omission Failures
●Process omission failures: process crashes
                                                                                        message buffer
•      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
● Process: omit intended processing steps or carry out unwanted ones
● Communications channel: e.g., non-delivery, corruption or duplication
 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
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           Process    Process/channel exhibits arbitrary behavior: it may
                               send/transmit arbitrary message at arbitrary times.
(Byzantine)         or         Commit omissions: a process may stop or taken an
                               incorrect step.
                        Timing failures
     Class of Failure      Affects

                           Process    Process’s local clock
     Clock                            exceeds the bounds on
                                      rate of drift from real
     performance           Process    Process exceeds the
                                      bounds on the interval
                                      between two steps.

                           channel    A message’s
     performance                      transmission takes
                                      longer than the
                                      stated bound

              Security Model

     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


    - fast interactive response delayed remote
    -use of caching, replication


     -dependent on speed of server and data

•Load balancing
   67 -Use of applets, multiple servers
•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
     Object Interaction:

       RMI and RPC

• Distributed applications programming
        - distributed objects model
        - RMI, invocation semantics
        - RPC
        - Java RMI,CORBA,DCOM
        - Sun RPC
        - JINI

                   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++
          Middleware Layer

       RMI , RPC and events
       Request-reply protocol         layer
     External data representation
         Operating System


         Data                                 Data

        Implementation   m1           m4      Implementation
          of methods     m2           m5        of methods

• Objects = data + methods

• Interact via interfaces:
     - define types of arguments and exceptions of methods

                  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++)
         The distributed object model
                           LOCAL            LOCAL
            INVOCATION                                 INVOCATION

                            B                                       F
     A                                       E

• Objects distributed (client-server models)
• Extend with
   - Remote object reference
   - Remote interfaces
   - Remote method invocation (RMI)
 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
         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
            Remote Object Reference
• Constructing unique remote object reference
   - IP address, port, interface name
   - time of creation, local object number (new for each
• Use the same as for local object references
• If used as addresses
   - cannot support relocation
         32 bit          32 bit     32 bit     32 bit
   Internet address   Port number   time     Object     Interface of remote
                                             number     object

                 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
   Remote Object and its interfaces

                                        Remote object
                    Remote                                   interface
                   interface              Data

                               m1                       m4
                               m2     Implementation    m5
                               m3       Of method       m6

• CORBA: Interface Definition Language (IDL)
• Java RMI: as other interfaces, keyword remote
          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

                          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...

            Invocation semantics summary

                     Fault tolerance measures                                     Invocation


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...
                    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...
               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
             At-most-once invocation

• Remote method
   - invoker receives result (executed once) or exception (no
   - 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

             Transparency of RMI
•should remote method invocation be same as local?
– Same syntax
– need to hide
   •data marshalling
   •IPC calls
   •locating/contacting remote objects

– different RMI semantics?      susceptibility to failures?
– Protection against interference in concurrent scenario?

• Approaches (Java RMI)
– transparent,but express differences in interfaces
– provide recovery features
                      Implementation of RMI
           object A proxy for B
                                                           Skeleton       Remote object B
                                                         for B’s class

Remote reference            Communication
module                                                               Remote reference
                                                   module            module

Object A invokes a method in a remote object B:
communication module reference module,RMI software.
          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

           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

          RMI Software architecture
   – behaves like local object to client
   – forwards requests to remote object

   – receives request
   – selects method and passes on request to skeleton

   – implements methods in remote interface
   – unmarshals data, invokes remote object
   – Waits for result, marshals it and returns reply
            Remote Procedure Call (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)

                  RPC client and server

           Client process
                                                     Server process

           Client stub             Reply
           procedure                                           Server stub
                                         Communication         procedure
Client program           module                                              Service
                                         module          dispatcher          procedure

  Implemented over Request-Reply protocol

•Distributed object model
   – capabilities for handling remote objects (remote
   – 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)


To top