Distributed Computing Course System Models

1
Distributed 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)

2
System 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

27
2.3 Fundamental Models Failure Model
28
2.3 Fundamental Models Failure Model
29
2.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)

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

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

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