System Models

1
System Models
2
Architectural model

• Structure of the system in terms of components
• Goals
• reliable, manageable, adaptable, cost-effective
  system design
• We will see
• What are the components
• Placement of the components, and
• Interrelationships between the components
• Component processes
• Server process, client process, peer process

3
Software Layers in DS (Software Architecture)

• The term s/w architecture referred originally to
  the structuring of s/w as layers or modules in a
  single computer and more recently in terms of
  services offered and requested between processes
  located in the same or different computers.
• This process- and service-oriented view can be
  expressed in terms of service layers

4
Software Layers in DS (Software Architecture)
Applications, services
To mask the heterogeneity to provide a
convenient Programming model
Middleware
Operating system
Platform
Ex. x86/Windows, SPARC/Solaris, PowerPC/MacOS, x86
/Linux
Computer and network hardware
5
Middleware Basics

• Representation
• processes or objects interacting with each other
  to implement communication and resource sharing
• Function
• provides building blocks for developing SW
  components that can interact in a DS
• An Important goal is to hide the heterogeneity of
  the underlying platforms from applications
• Examples
• Remote method invocation, group communication,
  replication
• Earliest middlewares Sun RPC, ISIS group
  communication
• OO middlewares OMGs CORBA, MSs DCOM, Java RMI

6
Middleware basics (contd.)

• Services for application programs
• CORBA naming, security, transaction, persistent
  storage, event notification
• Limitations of middlewares
• Many dist. apps rely entirely on middleware
  services for communication and data sharing. But
  some aspects of dependability require support at
  the application level.
• Saltzer, Reed and Clarkes classic paper
  End-to-end Arguments in System Design makes a
  valuable point about the design of distributed
  systems.
• The paper appeared in ACM TOCS vol. 2 (9), 1984.

7
Middleware

• To paraphrase their statement Some
  communication related functions can be completely
  and reliably implemented only with the knowledge
  and help of the application standing at the end
  points of the communication system. Therefore,
  providing that function as a feature of the
  communication system itself is not always
  sensible.
• Their argument runs counter to the view that all
  communication activities can be abstracted away
  from the programming of applications by the
  introduction of appropriate middleware layers.

8
Distributed systems Architectures

• Client-server architectures
• Distributed services which are called on by
  clients. Servers that provide services are
  treated differently from clients that use
  services
• Basic model
• Variations
• Distributed object architectures
• No distinction between clients and servers. Any
  object on the system may provide and use services
  from other objects
• Objects and interfaces

9
The Client-Server Model

• A server is a program that provide a service.
• It makes some resource available to other
  programs running somewhere on the network.
• The resource could be anything a database, a
  file system, a printer, a modem, a screen, or a
  scanner.
• The server program runs on the machine which
  resource is attached to, and waits passively
  until the services are required.
• Servers are often started up at boot-time, via
  commands in a start-up script and Servers usually
  spent most of their time asleep, waiting for
  work.
• A client is a program that uses a resource.
• It may be running on the machine to which the
  resource is attached, or on a different machine.
• A client actively makes a connection across the
  network to the server it requires.

10
The Client-Server Model (cont.)

• The terms client and server are sometimes used to
  refer to a machine.
• We may point out a computer on our network which
  has a large disk attached and say That is our
  file server, and these workstations here are its
  clients.
• We may refer to a machine with a printer attached
  as a print server.
• The term client and server refer to the
  relationship between individual programs, not to
  machines.
• In general, machines cannot simply be labeled as
  clients and servers.

11
The Client-Server Model (cont.)

• One machine might be a server for a piece of the
  file system, but a client of a remote print
  server.
• Example, a program which is a server for a
  database might itself contact a time server to
  obtain an accurate timestamp to attach to a new
  record in the database.
• In UNIX world, the term daemon is sometimes used
  to refer to a server.
• It means that the server is permanently
  available, which implies that it is started at
  boot-time.
• Daemon usually provide a system-related
  service, such as rlogind, telnetd, ftpd, httpd,
  nfsd, etc.

12
Client-server architectures

• The application is modelled as a set of services
  that are provided by servers and a set of clients
  that use these services
• Clients know of servers but servers need not know
  of clients
• Server name/IP address and Port number
• Clients and servers are logical processes
• Can be in the same machine
• The mapping of processors to processes is not
  necessarily 1 1

13
Client-Server architecture
Client
Server
invocation
invocation
result
result
Server
Client
Key
Process
Computer

• Servers may in turn be clients
• Web servers may be clients of File servers, DNS
  servers

14
A service provided by multiple servers
Service
Replicated data partitioned in multiple servers.
Server
Client
Server
Client
Server
15
Web proxy server
Involves caching of data improves availability
and performance Proxy servers may be used to
access remote web servers through a firewall
16
A distributed application based on peer processes
Application
Application
Coordination
Coordination
code
code
Application
Coordination

• Code in the peer process maintains
• consistency and synchronization
• No designated clients or servers
• All play similar roles interacting
• cooperatively as peers.

code
17
Variations on the client-server model

• Several variations can be derived from the
  consideration of the following factors
• The use of mobile code and mobile agents
• Users need for low-cost computers with limited
  h/w resources that are simple to manage
• The requirement to add and remove mobile devices
  in a convenient manner

18
Layered application architecture

• Presentation layer (UI)
• Concerned with presenting the results of a
  computation to system users and with collecting
  user inputs
• Application processing layer
• Concerned with providing application specific
  functionality e.g., in a banking system, banking
  functions such as open account, close account,
  etc.
• Data management layer
• Concerned with managing the system databases

19
Fat client model

• More processing is delegated to the client as the
  application processing is locally executed
• Most suitable for new Client-Server systems where
  the capabilities of the client system are known
  in advance
• More complex than a thin client model especially
  for management. New versions of the application
  have to be installed on all clients

20
Example of a Three-tiered System

• The general organization of an Internet
  search engine into three different layers

1-28
21
Multi-tiered Architectures

• Alternative client-server organizations (a) (e).

1-29
22
Other Variations of client-server model Mobile
Code
Java applets Push model initiated by the server
Pull model initiated by the client
a) client request results in the downloading of
applet code
Web
Client
server
Applet code
b) client interacts with the applet
Web
Client
Applet
server
23
Mobile Code

• It can give good interactive response since it
  does not suffer from the delays or variability of
  b/w associated with network communication.
• Potential security threat to the local resources
  --- give applets limited access to local
  resources.

24
Mobile agent

• Mobile agents
• A running program that travels from one machine
  to other in a network carrying out task on
  someones behalf eventually returning with the
  result.
• e.g. install and maintain s/w on the computers
  within an organization or compare the prices of
  products from a number of vendors by visiting the
  site of each vendor and performing a series of
  database operations.
• A potential security threat
• The environment receiving a mobile agent should
  decide on which of the local resources it should
  be allowed to use, based on the identity of the
  user on whose behalf the agent is acting

25
Interfaces and Objects

• Distributed processes can also be developed by
  using objected oriented languages (C/Java)
• Many objects can be encapsulated in server or
  peer processes, and reference to them are passed
  to other processes so that their methods can be
  accessed by remote invocation. Adopted by ---
• CORBA
• Java RMI
• New services and new types of object can be
  instantiated and immediately be made available
  for invocation dynamic.

26
Fundamental models

• A system model
• defines
• the entities
• their interactions
• characteristics that affect their behavior
• purposes
• explicitly states all relevant assumptions
• generalize what is possible or not based on the
  assumptions
• Well study
• Interaction model
• Failure model
• Security model

27
Fundamental models

• Concerned with the properties that are common in
  all of the architectural models.
• No global time in a DS clocks on different
  computers do not necessarily give the same time.

28
Fundamental models

• All communication between processes is achieved
  by means of messages message communication over
  a network can be affected by delays, can suffer
  from a variety of failures and is vulnerable to
  attacks.
• These issues are addressed by three models.

29
Interaction model, Failure model Security model

• Interaction model deals with the performance and
  with the difficulty of setting time limits in a
  Distributed System.

30
Interaction model, Failure model Security model

• Failure model attempts to give a precise
  specification of the faults that can be exhibited
  by a process and communication channels.
• It defines reliable communication and correct
  processes.

31
Interaction model, Failure model Security model

• Security models discusses the possible threats to
  processes and communication channels.
• Introduces the concept of a secure channel, which
  is secure against those threats.

32
Interaction model

• Issues related to the interactions between
  processes
• What are the issues?

process
p
process
q
send
receive
m
Communication channel
Outgoing message buffer
Incoming message buffer
33
Interaction model

• Significant factors affecting interacting
  processes in a distributed system
• Communication performance is often a limiting
  characteristics
• It is impossible to maintain a single global
  notion of time

34
Interaction model

• Performance of Communication channel
• Latency the delay between the sending of a
  message by one process and its receipt by another
  is referred to as latency that includes
• propagation delays time taken for the first of
  a string of bits transmitted through a network to
  reach its destination
• network delays delay in accessing the network
• OS delays time taken by the OS communication
  services at both the sending and receiving
  processes
• Bandwidth
• The capacity of the communication channel
• Jitter
• Variation in time taken to deliver a series of
  messages.
• Relevant to multimedia data -- Audio-video

35
Interaction model

• Clocks and timing
• Absence of global clock, clock drift rate
• Two important variants of the Interaction Model
• It is hard to set time limits on the time taken
  for processor execution, message delivery or
  clock drift.
• Two opposing extreme positions provide a pair of
  simple models
• The first has a strong assumption of time and the
  second makes no assumptions about time
• Synchronous DS
• Asynchronous DS

36
Synchronous and asynchronous DS

• Synchronous
• Processing time (time to execute each step of a
  process) has a known lower and upper bound
• Msg. Transmission delay is within a known bound
• Local clock drift rates are also within a known
  bound
• Examples Multiprocessor systems
• Asynchronous
• Processing time doesnt have any bound
• Msg. Transmission delay doesnt have any bound
• Local clock drift rates dont have any bound
• Examples Internet, wireless networks,
  datacenters, most real systems

37
Synchronous and asynchronous DS

• Synchronous
• Possible to suggest likely upper lower bounds
  but difficult to arrive at a realistic values and
  to provide guarantee for the chosen values
• Possible to use timeouts
• Unless the values of the bounds are guaranteed,
  any design based on those will not be reliable
• Modeling an algorithm as a synchronous system may
  be useful for giving some idea of how it will
  behave in a real distribute system

38
Synchronous and asynchronous DS

• Asynchronous
• Many DS (e.g. Internet) are very useful w/o being
  able to qualify as synchronous system
• Actual DS are very often asynchronous
• There are many design problems that cannot be
  solved for an asynchronous system that can be
  solved when some aspects of time are used.
• Any solution that is valid for asynchronous DS is
  also valid for synchronous DS

39
Real-time ordering of events

• User A
• X sends a message with the subject Meeting
• Y and Z reply with the subject Re Meeting

send
receive
receive
X
1
4
m
1
m
send
2
receive
2
3
Physical
Y
time
receive
send
Z
receive
receive
From Subject
m
m
m
1
2
3
A
receive
receive
receive
t
t
t
1
2
3
40
Failure model

• Types of failures
• Omission failure
• process
• communication channel
• Arbitrary failure
• Timing failure

process
p
process
q
send
receive
m
Communication channel
Outgoing message buffer
Incoming message buffer
41
Failure Types

• Process omission failure
• Crash-stop (fail-stop) a process halts and
  does not execute any further operations
• Crash-recovery a process halts, but then
  recovers (reboots) after a while
• Special case of crash-stop model (use a new
  identifier on recovery)
• We will focus on Crash-stop failures
• They are easy to detect in synchronous systems
• Not so easy in asynchronous systems

42
Failure Types

• Communication omission failures
• Send-omission loss of messages between the
  sending process and the outgoing message buffer
  (both inclusive)
• What might cause this?
• Channel omission loss of message in the
  communication channel
• What might cause this?
• Receive-omission loss of messages between the
  incoming message buffer and the receiving process
  (both inclusive)
• What might cause this?

43
Failure Types

• Arbitrary failures
• Arbitrary process failure arbitrarily omits
  intended processing steps or takes unintended
  processing steps.
• Arbitrary channel failures messages may be
  corrupted, duplicated, delivered out of order,
  incur extremely large delays or non-existent
  messages may be delivered.
• Above two are Byzantine failures, e.g., due to
  hackers, man-in-the-middle attacks, viruses,
  worms, etc., and even bugs in the code
• A variety of Byzantine fault-tolerant protocols
  have been designed in literature!

44
Omission and Arbitrary Failures
45
Masking reliability

• Masking failures
• Some services can mask a failure, e.g.,
  checksums are used to mask corrupted messages
  effectively converting an arbitrary failure into
  an omission failure, omission failures can be
  masked by retransmission
• Reliable communication is defined in terms of
• - Validity a message eventually reaches the
  destination
• - Integrity the message received is identical
  to the message sent

46
Security model

• The security of a DS can be achieved by securing
  the processes and the channels used for their
  interactions and by protecting the objects that
  they encapsulate against unauthorized access
• Access rights specify who is allowed to perform
  the operations of an object
• Principal associated with each invocation and
  each result the authority on which it is issued.
  A principal may be a user or a process

47
Securing Processes and their Interactions

• Processes interact by sending messages
• Due to the openness of the underlying networks
  and the communication services, the messages are
  vulnerable to attacks
• The Enemy
• To model security threats we postulate an enemy
  or an adversary who can pose security threats
• Threats assessment
• is an important aspect of security model

48
Security threats
The enemy (intruder) 1. Threats to the
processes 2. Threats to the servers 3. Threats
to the communication channel
m
Copy of
The enemy
m
p
q
m
Process
Process
Communication channel
49
Secure channel

• Encryption and authentication are used to build
  secure channels as a service layer on top of
  existing communication services. Has the
  following props.
• Each process knows reliably the identity of the
  principal on whose behalf the other process is
  executing
• Ensures the privacy and integrity of the data
  transmitted across it
• Each message includes a physical or logical
  timestamp to prevent messages from being replayed
  or reordered

Other forms of threats 1. Denial of service
attacks 2. Threats associated with the mobile
codes