Professional Documents
Culture Documents
3. Fault Models
• Resource managers can be in general modelled as
processes.
If the system is designed according to an object-
oriented methodology, resources are encapsulated
in objects.
• Peer-to-peer
peer peer
☞ Peer-to-Peer tries to solve some of the above - multiple servers and caches
- mobile code and mobile agents
• It distributes shared resources widely
- low-cost computers at the users’ side
- mobile devices
• Proxy servers are typically used as caches for web Step 2: interact with applet
resources. They maintain a cache of recently
visited web pages or other resources.
When a request is issued by a client, the proxy client applet server
server is first checked, if the requested object
(information item) is available there.
Network computers
☞ Mobile agent: a running program that travels from
one computer to another carrying out a task on
someone’s behalf.
Typical tasks:
Advantages:
Attention: potential security risk (like mobile code)!
• The network computer can be simpler, with limited
capacity; it does not need even a local hard disk (if
there exists one it is used to cache data or code).
• Users can log in from any computer.
• No user effort for software management/
administration.
• Synchronous distributed systems • Drift rates between local clocks have a known
bound.
• No bound on process execution time (nothing can ☞ Asynchronous systems are widely and successfully
be assumed about speed, load, reliability of used in practice.
computers).
• No bound on message transmission delays In practice timeouts are used with asynchronous
(nothing can be assumed about speed, load, systems for failure detection.
reliability of interconnections) However, additional measures have to be applied in
order to avoid duplicated messages, duplicated
• No bounds on drift rates between local clocks. execution of operations, etc.
Important consequences:
What kind of faults can occur and what are their effects?
Intended processing steps or communications are • Architectural models define the way responsibilities
omitted or/and unintended ones are executed. are distributed among components and how they
Results may not come at all or may come but carry are placed in the system.
wrong values.
We have studied three architectural models:
1. Client-server model
2. Peer-to-peer
3. Several variations of the two
Timing Faults
• Interaction models deal with how time is handled
throughout the system.
☞ Timing faults can occur in synchronous distributed Two interaction models have been introduced:
systems, where time limits are set to process 1. Synchronous distributed systems
execution, communications, and clock drifts. 2. Asynchronous distributed systems
A timing fault occurs if any of this time limits is
exceeded. • The fault model specifies what kind of faults can
occur and what their effects are.
Fault models:
1. Omission faults
2. Arbitrary faults
3. Timing faults
RMI, RPC
2. Network Protocol
Request&Reply
Middleware
Reply RMI, RPC
Request&Reply
Network
Operating System&Network Protocol
The solution:
The server: - Asking for a service is solved by the client
issuing a simple method invocation or procedure
------------------ call; because the server can be on a remote
receive(request) from client-reference; machine this is a remote invocation (call).
execute requested operation
send (reply) to client_reference; - RMI (RPC) is transparent: the calling object
(procedure) is not aware that the called one is
------------------
executing on a different machine, and vice
versa.
Request
Invocation
local ref.
local ref.
Client
Answer
Server
local ref. ↔ rem. ref.
Reply
module
Skeleton for B
Network
arguments
Marshal
results
Implementation of RMI
local ref.
Request
rem. ref.
Reply
------------------
local ref.
local ref.
The server contains the method:
Remote reference Communication
Proxy for B
Unmarshal
arguments
results
{ - - - };
Invocation
f.
Answer
local ref.
local re
module
Client
- The proxy is the local representative of the - A part of the skeleton is also called dispatcher.
remote object ⇒ the remote invocation from A The dispatcher receives a request from the
to B is initially handled like a local one from A to communication module, identifies the invoked
the proxy for B. method and directs the request to the
corresponding method of the skeleton.
- At invocation, the corresponding proxy method
marshals the arguments and builds the message
to be sent, as a request, to the server.
After reception of the reply, the proxy
unmarshals the received message and sends
the results, in an answer, to the invoker.
Problem: what if the request was not truly lost (but, for Danger!
example, the server is too slow) and the server • Some operations can be executed more than once
receives it more than once? without any problem; they are called idempotent
operations ⇒ no danger with executing the
duplicate request.
• We have to avoid that the server executes certain
operations more than once. • There are operations which cannot be executed
repeatedly without changing the effect (e.g.
• Messages have to be identified by an identifier and
transferring an amount of money between two
copies of the same message have to be filtered out:
accounts) ⇒ history can be used to avoid re-
- If the duplicate arrives and the server has not execution.
yet sent the reply ⇒ simply send the reply.
- If the duplicate arrives after the reply has been
History: the history is a structure which stores a record
sent ⇒ the reply may have been lost or it didn’t
of reply messages that have been transmitted,
arrive in time (see next slide).
together with the message identifier and the
client which it has been sent to.
Server
Request
receive
no Reply crash
Big problem!
The client cannot distinguish between cases b and c!
When the client got an answer, the RMI has been
However they are very different and should be handled in carried out at least one time, but possibly more.
a different way!
Alternative 2: at most once semantics
• The client’s communication module gives up and
immediately reports the failure to the client (e.g. by
What to do if the client noticed that the server is down raising an exception)
(it didn’t answer to a certain large number of repeated
requests)?
- If the client got an answer, the RMI has been
executed exactly once.
- If the client got a failure message, the RMI has
been carried out at most one time, but possibly
not at all.
Problems:
☞ If server crashes with loss of memory (case b on
• wasting of CPU time slide 44) are considered, only at least once and at
• locked resources (files, peripherals, etc.) most once semantics are achievable in the best case.
• if the client reboots and repeats the RMI, confusion
can be created. In practical applications, servers can survive crashes
without loss of memory. In such cases history can be
used and duplicates can be filtered out after restart of
the server:
The solution is based on identification and killing the
orphans. • the client repeats sending requests without being in
danger operations to be executed more than one
time (this is different from alternative 2 on slide 46):
- If no answer is received after a certain amount
of tries, the client is notified and he knows that
the method has been executed at most one
time or not at all.
- If an answer is received it is forwarded to the
client who knows that the method has been
executed exactly one time.
☞ And no hope about achieving exactly once semantics • With group communication a message can be sent
if servers crash ?! to multiple receivers in one operation, called
multicast.