Distributed Computing Course System Models - PowerPoint PPT Presentation

1 / 32
About This Presentation
Title:

Distributed Computing Course System Models

Description:

Use of mobile code (code migration) and mobile agents ... search engine-servers and web crawlers', which are all independent, concurrent ... – PowerPoint PPT presentation

Number of Views:137
Avg rating:3.0/5.0
Slides: 33
Provided by: george593
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com