Title: Distributed Computing Course System Models
1Distributed Computing CourseSystem Models
- 2.1 Basics
- Architectural Model
- Hierarchy/placement of component parts and
relationships, e.g., Client-Server and
Peer-Process models - C-S Model
- Partition/replication of data at cooperating
servers - Caching data by proxies (clients and servers)
- Use of mobile code (code migration) and mobile
agents - Open systems (ease of adding/removing mobile
devices) - Fundamental/Descriptive Model
- Specification/description of common properties of
all kinds of architectural models - No concept of global clock in DS, and local
clocks are not synchronized - Message passing is only means of communication
(rep. Interaction model) - Distributed systems suffer
- Delays, failures (rep. Failure model
failure/delay due to bad links or congestion) - security attacks (rep. Security model secure
channels or access/capability lists)
2System Models 2.1 Basics
- Architectural models
- Define the layer/levels of components, placement,
and manner of interactions - Well described mapping of components/functions
onto underlying physical network architecture (of
computers) - The chapters focuses on
- Variants of architectural models layered, C-S,
aspects of DS for being open systems - Fundamental models abstracting models to reveal
design issues, properties, difficulties,
correctness, reliability, security, and
variations in performance requirements, issues of
heterogeneity (hware, sware, network types,
clocks, data types/formats, integrity, QoS)
3System Models 2.2 Architectural Models
- Architecture structure which defines the
placement of system components, to guarantee
reliability, manageability, adaptability, and
cost-effectiveness a consistent frame of
reference - Component parts abstracted as processes and
objects - Issues
- A component (and its function/role), relation to
others, and its placement across a network - Interrelationships components roles and its
communication patterns - Characterization
- Components as processes server, client or peer
(cooperating process with symmetric communication
to other peers) - Variants of the C-S Model
- Allowing code/data migration, task delegation
reducing delays and comm - Dynamic adding/removing of mobile devices and
discovery of added/deleted resources supporting
ubiquitous and mobile DS
42.2 Architectural Models Software Layers
- Software architecture (focus for chp 3-6)
- Layers of software modules in the same or
different computers, and the manner of
interactions among modules and services each
provides and accessibility - Each layer/module offers a kind of services.
- E.g., the Internet has Network Time Protocol,
used by server processes solely responsibility
for reading and sending LocalHostTime info to
clients on request
52.2 Architectural Models Software Layers
- Platform
- The lowest-level hardware and software layers,
which provide services to the upper Middleware
and Application Layers. (The design and
implementation of the platform is independent of
the design and implementation of the upper layers
the glue or interface between the Platform
and upper layers is realized through systems
programming of Application Programming Interfaces
(APIs) or Bundles) - Examples SunSPARC/SunOS, Intel x86/Solaris,
PowerPC/MacOS, Intel x86/Linux, Intel x86/Windows
or NT - Middleware
- Layer of software, which masks heterogeneity in
DS, and facilitates API programming by
application programmers - It is represented by processes and objects on
service providing computers for communication
and resource (files/data, code, device) sharing. - Provides building blocks (classes, objects,
interfaces, library modules) for constructing DS
components - It abstracts device-level communication
requirements via, e.g., RMI, RPC, request/send,
notify, selective or group communication,
broadcast, protection/security, data
replication/integrity - Examples Sun RPC, Jave RMI, CORBA, DCOM,
ISO/RM-ODP - Infrastructural services facilities/libraries
for naming, security, transactions, persistency,
notification - Domain-specific services facilities/libraries
for communication and local (hidden) services
62.2 Architectural Models Software Layers
- Middleware limitations
- E.g., systems constrained by use of only RMI for
comm and data sharing consider a C-S model for
request/reply of names and addresses in a
database - Abstraction and full independence of
application layer is not achieved, yet! (E.g.,
consider a C-S-based mail service provider where
a server must add its own error
detection/recovery mechanism for retransmission
if a link breaks on large transmissions Or
vice-versa, is possible) - Arguably, error detection/recovery needs to be at
several levels, not only at middleware
72.2 Architectural Models System architectures
- Architectural design has a major impact on
performance, reliability, and security. - 1. The C-S model widely used, servers/clients
on different computers provide services to
clients/servers on different computers via
request/reply messaging. (Note servers could
also become clients in some services, and
vice-versa, e.g., for web servers and web pages
retrievals, DNS resolution, search engine-servers
and web crawlers, which are all independent,
concurrent and asynchronous (synchronous?)
processes
82.2 Architectural Models System architectures
- 2. The Multi-Server model a DS with multiple,
interacting servers responding to parts of a
given request in a cooperative manner. Service
provision is via the partitioning and
distributing of object sets, data replication,
(or code migration). E.g., A browser request
targeting multiple servers depending on location
of resource/data OR replication of data at
several servers to speed up request/reply
turnaround time, and guarantee availability and
fault-tolerance consider the Sun NIS
replication of network login-files for user
authorization.
9 2.2 Architectural Models System architectures
- 3. The Proxy Servers and Caches model Caching
frequently used objects/data/code, which can be
collocated at all clients Or located at a
single/multiple proxy server(s) and
accessed/shared by all clients. When requested
object/data/code is not in cache is it fetched
or, sometimes, updated. E.g., clients caching of
recent web pages, or designating a proxy server
for added security/firewall to hold shared web
pages/objects.
102.2 Architectural Models System architectures
- 4. The Peer Process model Without any
distinction between servers and clients, all
processes interact and cooperate in servicing
requests processes are able to maintain
consistency and needed synchronization of
actions and pattern of communication depends on
the application. E.g., consider a whiteboard
application where multiple peer processes
interact to modify a shared picture file
interactions and synch done via middleware layer
for notification/group comm.
11 2.2 Architectural Models System architectures
- 4. Mobile code model A variant of the C-S
model, code migration/mobility allows DS objects
to be moved to a client (or server) for
execution/processing in response to a client
request, e.g., migration of an applet to a local
browser avoiding delays and comm overhead.
E.g., dynamic/periodic auto-migration of
server-resident code/data to a client the push
model here, the server initiates the
interaction by sending update data to clients
applets to a) refresh, say, a stocks web page, b)
perform buy/sell condition-checks on clients
side, and c) automatically notify the server to
buy/sell all done while the user-application is
off or onto other things. (Caution security
threat due to potential Trojan Horse problem in
migrated code.)
12 2.2 Architectural Models System architecture
- 5. Mobile agents model A variant of the C-S
model, where both code and associated data are
migrated to a number of computers to carry out
specified functions/tasks, and eventually
returning results it tends to minimize delays
due to communication (vis-à-vis static clients
making multiple requests to servers). E.g., a
software installation-agent installing
applications on different computers for given
hardware-configs Or price-compare-agent checking
variations in prices for a commodity Or a
worm-agent that looks for idle CPU cycles in
cluster-computing.(Caution security threat due
to potential Trojan Horse problem in migrated
code, incomplete exec or hanging of agents)
132.2 Architectural Models System architectures
- 6. Network computer model
- A variant of the C-S model, where each client
computer downloads the OS and application
software/code from a server applications are
then run locally and files/OS are managed by
server this way, a client-user can migrate from
computer to computer and still access the server,
and all updates are done at the server side.
Local disks are used primarily as cache storage.
Has low management and hardware costs per
computer
142.2 Architectural Models System architectures
- 7. Thin Client model A variant of the
C-S/Network computer model, where each client
computer (instead of downloading the OS and
application software/code from a server),
supports a layer of software which invokes a
remote compute-server (e.g., a cluster of
computers, HPC, high-speed multiprocessors) for
computational services. If the application is
interactive and results are due back to
client-user, delays and communication can eclipse
any advantages. E.g., using Unix X-11 windows
system server process - with a boundary between
client and server set at graphical ops/primitives
level for servicing window-based objects
152.2 Architectural Models System architectures
- Mobile devices and Spontaneous networking model
A form of distributed computing that integrates
mobile devices (small portable devices laptops,
PDA, mobile phones, digital cameras, wearable
computers smart watches) and non-mobile
embedded microcomputers washing machines,
set-top boxes, home appliances, automobiles,
controllers, sensors) by connecting both mobile
and non-mobile devices to networks to provide
services to user and other devices from both
local and global points.
162.2 Architectural Models System architectures
- Mobile devices
- Requirements A network protocols used are either
wired or wireless (e.g., GSM-based 100s of
kbps, WaveLAN range of 100s of meters, few
meters Bluetooth, IR, HomeRF) to allow easy
auto-config of connection to local network and
auto-config/identification and integration of
local/intranet services into mobile services - Design issues/Problems assumed fixed
addressing/routing algorithms, reachability
range of connectivity, reliability,
security/privacy breaches introduces potential
attacks to local intranets while on the move - Discovery Service portable device awareness or
recognition (acceptance and storage of details)
of services on connected networks (more in chp
9) - client-side service registration (clients accept
registration requests from servers and store
service details in device database) and - lookup service (servers send details/attributes
of available services to clients to match
desired/registered services, and then connect)
172.2 Architectural Models Interfaces and objects
- A set of functions for invocation of services in
a process (server/client/peer) and their
specifications or interface definitions how to
use them! - E.g., CORBA and Java RMI Bundles of services
whose syntax/semantics and usage through remote
method invocation meaning, object resources
(their data and methods) are encapsulated in
server/peer processes. - Architectural choices may support static services
(e.g., the CS and other layered models) or
support open systems with dynamic add/remove of
service and on the fly or with mobility (e.g.,
Java-based object-oriented interface definitions)
182.2 Architectural Models Design requirements
for distributed architectures
- Motivating factors and relevance for distributed
objects and processes - Need to share resources data/code
- Availability of cheaper microprocessors
- Existence and advances of communication
infrastructure, network protocols, concurrency
control techniques - Performance
- Responsiveness timeliness of response to
requests, hampered by delays in computing,
communication, layers of middleware, bandwidth - Throughput determined by server/client speeds
and data transfer rates - Load balancing concurrent but without undue
competition for resources equal distribution of
tasks and resources with possible inter-process
data/code migration
192.2 Architectural Models Design requirements
for distributed architectures
- Use of caching and replication
- Much of challenges (due to performance
constraints) have been mitigated by use of
caching and replication - Techniques for cache updates and cache coherence
based on cache coherent protocols (e.g.,
web-caching protocol, a part of the HTTP cache
coherent protocol) - Web-caching protocol
- Provided by browsers or proxy servers, with
periodic update from web-server (dep. on
performance requirements) achieved by
browser/proxy sending validation-request to
servers, - Protocol Servers set approximate expiry
time-to-refresh and sends this time and the
server-time (time of sending) as a part of the
initial web-data requested/cached. Browser or
proxy calculates if(age server-time
lengthof-cached-time gt expiry-time) then
need-request-cache-update independent of
respective clocks or sychronization
202.2 Architectural Models Design requirements
for distributed architectures
- Dependability issues
- As related to correctness, security, and fault
tolerance (maturing fields) - Fault tolerance issues of fail-safe, graceful
degradation, partial availability due to
redundancy (of both hw and sw), dynamic
reconfigurability - Architectural redundancy multiple
computers/storage, replicated data/programs/proces
ses, alternative communication paths/switches,
e.g., air traffic control systems, with multiple
retransmission with Ack protocols - Security models and protocols that ensure
protection of sensitive data/programs/processes
from attack/abuse, e.g., securing patient records
on a server
21System Models 2.3 Fundamental Models
- Commonality of attributes or characteristics
- All models (for describing DS) have a common set
of attributes, e.g., all entail processes,
messaging, network-use, share common
characteristics or requirements - Common framework
- Any system model has a) main entities, b)
entity interactions, c) characteristics affecting
individual and collective entity behavior - Purpose of models
- Make relevant assumption and generalize via
algorithms/math model/proof-system to show that
properties holds under the assumptions - Basis of fundamental models
- Interactions algorithms for communication and
coordination with timing/delay analysis - Failure types of hardware, software or network
inaccuracies or faults analysis - Security modularity (of process/services) and
openness make DS vulnerable, and security models
classify possible cases of attack for analysis
222.3 Fundamental Models Interaction Model
- Levels of interaction c-server processes like
DNS with replicas, Sun NIS Or peer-process
interaction cooperating processes (no c-s
hierarchy) - Process interactions/behavior often captured in a
distributed algorithm - Performance of distributed behaviors, including
message patterns and timing, is unpredictable,
THEREFORE - A) communication is a bottleneck, affecting
performance - B) no sense/notion of global clock
232.3 Fundamental Models Interaction Model
- Performance of communication channels
- Latency time to transfer/receipt, setup time, OS
service overhead - Bandwidth traffic volume and capacity of pipe
versus of processes - Jitter variations in receipt-times of
distributed data (distortion, esp. in audio/video
data) - Computer clocks and timing events
- Different clock drifts disallows a notion
perfect, common/global time, making timestamps
differ in DS - Dealing with clock drift and clock synch can be
accomplished using radio receivers to obtain
times from a GPS within 1msec accuracy and
broadcast this time to other computers - Variants of interaction Model
- Synchronous DS assumes lower/upper bounds on
exec/comm times, and bounds on clock drift rates
computable (not usually a guarantee or
reliable) - Asynchronous DS no assumptions about time,
exec/comm times are unpredictable, and clock
drift rates are arbitrary (hard to design for
real-time or system needing hard deadlines, e.g.,
multimedia data delivery or real-time distributed
control system)
242.3 Fundamental Models Interaction Model
- Event ordering Event occurrences, sequencing,
and accuracy irrespective of clock inaccuracies,
for process computations and communication - If X, Y, Z have local clocks, and synched user A
may see t1 lt t2 lt t3 - Local clocks cant be synched, hence Lamport
proposed logical time for logical (temporal)
ordering of events w.r.t before, after,
concurrent
252.3 Fundamental Models Failure Model
- Taxonomy of failures
- Due to processes handled by request-reply
protocols for stream or datagram communication
(for both process and comm failures) - Due to communication handled by two-phase
commit (for both process and comm failures) - Omission Failures
- Process omission crash/fail-stop with timeouts
- Comm omission typified by send-omission,
receive-omission or channel-omission losses due
to failure to deliver messages for lack of buffer
space, network error from lines/surges, or
detection from checksum
262.3 Fundamental Models Failure Model
- Arbitrary / Byzantine failures taking unintended
path or calculation to result in errors (process
or comm) unexpectedly e.g., duplicates known
from seqs, corrupted message from checksum - Timing failures high clock drifts affecting
timeliness process/comm channel (serious in
multimedia computing due to distortion) - Masking failures hiding effect via checksum -
detect/correction, retrans, replications - Reliability of one-to-one communication
- Validity eventual delivery of queued message
from outbound to inbound buffer - Integrity message buffered on receipt is exact
copy of the message queued and sent
272.3 Fundamental Models Failure Model
282.3 Fundamental Models Failure Model
292.3 Fundamental Models Security Model
- Security Model
- Securing processes and comm channels by
protecting objects they encapsulate - against unauthorized access
- Protecting objects
- Uses access rights (allowable ops on given
object by a given client or principal)
302.3 Fundamental Models Security Model
- Securing processes and their interactions
- Securing processes and communication channels by
protecting objects they encapsulate - against unauthorized access
- Needs a model for the static analysis of
security threats, evaluation of risks, and
consequences - Enemy model - eavesdropping via message
interception, repeated trials of network access.
E.g., - Threats to processes inserting and forwarding
incorrect IP addresses in message to servers or
clients to confuse or disguise the enemy-sender - Threats to communication channels copying,
altering or inserting incorrect data into message
streams to deceive or replicate unauthorized
transactions (e.g. banking)
312.3 Fundamental Models Security Model
- Defeating security threats
- Cryptography science of keeping message secure
via encryption/decryption of messages and
public/private keys/codes - Authentication shared encrypted secret
identification info between server and clients - Secure Channels A service layer that uses
cryptography and authentication techniques on top
of communication services. Channels connect a
pair of processes - Secure channels for reliable identification,
privacy/integrity of data and physical / logical
timestamp to prevent replay or reordering of
messages (more in chp 7)
322.3 Fundamental Models Security Model
- Other Threats
- Denial of Service Bombarding processes in DS
with excessive requests/invocations for services
beyond server capability overloading physical
resources, or delay of authorized users - Mobile Code Trojan horse code, e.g., viruses,
popularly transmitted in email attachments