Distributed systems

1
Distributed systems

• By. Issa Al smadi

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
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 users 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
Reasons for Distributed Systems

• Functional distribution computers have
  different functional capabilities
• Client / server
• Host / terminal
• Data gathering / data processing
• Load distribution / balancing assign
  tasks to processors such that the overall system
  performance is optimized.

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
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
Examples of Distributed Systems

• 1-The internet
• Heterogeneous network of computers and
  applications
• Implemented through the internet Protocol Stack
• Typical configuration

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
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
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
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
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
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
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
(No Transcript)
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
Challenges in the design of Distributed Systems

• 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
Challenges in the design of Distributed Systems
Challenges in the design of Distributed Systems

• 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
Openness ( contd )
The same looking at two distributed nodes
Application services
Middleware
Operating system
Operating system
Platform 1
Platform 2
Hardware Comp.NW
Hardware Comp.NW
Node 1
Node 2
20
Openness ( contd )
Software Architecture
Application services
Middleware
Operating system
The platform
Hardware and computer networked
21
Challenges in the design of Distributed Systems

• Security
• Privacy
• Authentication
• Confidentiality
• Protection against disclosure to unauthorized
  person.
• Integrity
• protection against alteration and corruption.
• Availability
• Keep the resource accessible

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
(No Transcript)
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
Challenges in the design of Distributed Systems

• 7. Performance
• Several factors are influencing the performance
  of a distributed system
• The performance of individual workstations.
• The speed of the communication infrastructure.
• Extent to which reliability (fault tolerance ) is
  provided (replication and preservation of
  coherence imply large overheads).
• Flexibility in workload allocation for example,
  idle processors ( workstations) could be
  allocated automatically to a users task.

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 ISOs Reference Model for ODP,
  quoted after Coulouris )
• Access access local and remote resources using
  identical operations
• e.g., network mapped drive using samba server
  , NFS mounts
• Location access without knowledge of location
  of a resource
• e.g., URLs , email addresses

27
transparency ( contd )

• Concurrency allow several processes to operate
  concurrently using shared resources in a
  consistent fashion
• 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 .
• Failure allow programs to complete their task
  despite failures retransmit of email messages

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
Forms of Transparency in a Distributed System
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 Hide that a resource may be shared by several competitive users
Failure Hide the failure and recovery of a resource
Persistence Hide whether a (software) resource is in memory or on disk
30
Communication

• Components of a distributed system have to
  communicate in order to interact. This implies
  support at two levels
• Networking infrastructure (interconnections
  network software).
• 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
Models
32
Overview

• System architecture
• Software layer
• Architecture models
• Client-server , peer processes,
• Mobile code , agents
• Design requirements
• User expectations of the system

33
Distributed design
Customer service
Scanner
Data base server
Mainframe
Printer service
34
Architecture

• Distribute Systems are foremost highly complex
  software systems
• -Nortel network DMS-100 switch25-30 million
  lines of code,3000 software developers ,20 years
  life cycle to date.
• -Motorola20 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 componentglobal control structure
  the protocols for communication
  ,synchronization,and data accessthe 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

35
Layers

• 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 n1
Layer n
Layer n-1
36
Layers

• Typical layering in Distributed systems
• -platform Hardware and operating system
• -windows NT / Pentium processor

37
Software Layers
Extend services available to those of the
distributed system
Language an runtime support for program
interaction
Applications
Open ( distributed ) services
Middleware
Conventional and distributed application
Operating system
platform
Computer and network hardware
Responsible for basic local resource management
memory allocation protection
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
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 systems
  programming interface for communication
  coordination between processes

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

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

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
Models

• Models can be used to provide an abstract and
  simplified description of certain relevant
  aspects of distributed systems.
• Model types
• 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

44
Models

• 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
• Failure models
• The failure model specifies what kind of failures
  can occur and what their effects are.
• Omission failures
• Arbitrary failures
• Timing failures

45
Architectural models

• 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
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
Architectural models
Architectural models
1- Client Server System 1.1 One Tier
Architecture
48
Architectural models
Architectural models
1- Client Server System 1.2 Two Tier
Architecture
49
Architectural
Architectural models
1- Client Server System 1.3 Three Tier
Architecture
Two tier is satisfactory for simple client-server
application , but more demanding transaction
processing application
Shared application services
Shared Data services
clients
presentation
processing
data
Remote data access Procedure call
Remote data access or Transaction processing
50
Client - server

• 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

invocation
invocation
client
Server
Server
result
result
Client
51
Variants

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

52
Client - server
Variants -proxy servers render replication /
distributedness transparent -Caching
-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
53
proxy server

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

server
client
Proxy server
client
server
54
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 (codedata),migrating
  amongst processes ,carrying out of an autonomous
  task, usually on behalf of some other process .
• - Advantages flexibility ,savings in
  communications cost

55
Client-server Model Variations (Thin Clients)

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

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

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

58
Client - server
Music service
Alarm server
gateway

• ? Further variant of client - server mode
  
  
• spontaneous networking
• -Challenges
• 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
• security
• 1- access to device 2- access right
  in dynamic

Hotel wireless
Internet
Camera PDA
discovery service
Guest device
laptop
TV/PC
59
Client - server
Music service
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



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.

61
Architectures Design Requirements

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

62
Client - server

• 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

63
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 unit
• delay jitter variation in delay between
  different message of the same type
  (e.g,video frames in ATM networks)
  
  
  

64
Fundamental Models (Interaction Model)

• Interacting processes in a distributed system are
  affected by two significant factors
• 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).

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
Fundamental interaction Model

• 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

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

68
Asynchronous Distributed Systems

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

69
Fundamental Models (Interaction Model)

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

70
Fundamental Models (Interaction Model)
Real-time ordering of events
71
(No Transcript)
72
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
• 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

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

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
Failures
Process p
Process q
Send m
Receive
Outgoing message buffer
Communication channel

• 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

Incoming message buffer
76
Failures
Class of failure Affects description
process
Fail-stop
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 ends incoming message
buffer
Send-omission
process
A process completes a send, but the message is
not put in its outgoing message buffer
Receive-omission
process
A message is put in processs 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.
77
Timing failures
description Affects Class of Failure
Processs 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. Process performance
A messages transmission takes longer than the stated bound channel performance
78
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 access.
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

• 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
Object Interaction RMI and RPC
82
Overview

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

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
Middleware Layer
Applications
RMI , RPC and events
Middleware layer
Request-reply protocol External data
representation
Operating System
85
Objects

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

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
The distributed object model

• Objects distributed (client-server models)
• Extend with
• - Remote object reference
• - Remote interfaces
• - Remote method invocation (RMI)

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
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
Remote Object Reference

• 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

32 bit 32 bit
32 bit 32 bit
Interface of remote object Object number time Port number Internet address
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
Remote Object and its interfaces
Remote object
Local interface
Data
Remote interface
m4 m5 m6
m1 m2 m3
Implementation Of method

• CORBA Interface Definition Language (IDL)
• Java RMI as other interfaces, keyword remote

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
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
Invocation semantics summary
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...
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
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
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
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
Implementation of RMI
Server
Client object A proxy for B
Request
Remote object B
Skeleton dispatcher for Bs class
Reply
Remote reference module
Communication module
Communication module
Remote reference module
Object A invokes a method in a remote object
B communication module reference module,RMI
software.
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
• Servers communication module
• selects dispatcher within RMI software
• converts remote object reference to local

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
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
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
RPC client and server
Client process
Server process
Request
Reply
Client stub procedure
Server stub procedure
Communication module
Communication module
Service procedure
Client program
dispatcher
Implemented over Request-Reply protocol
106
Summary

• Distributed object model
• capabilities for handling remote objects (remote
  references,etc)
• RMImaybe,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,asynchronou
  s systems)