Presentation on theme: "1 Distributed Computing Course System Models 2.1 Basics –Architectural Model Hierarchy/placement of component parts and relationships, e.g., Client-Server."— Presentation transcript:
1 Distributed Computing Course System 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 (h’ware, s’ware, 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 – component’s 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 8.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 > 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/processes, 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 1 sec 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 synch’ed user A may see: t1 < t2 < t3 Local clocks can’t be synch’ed, 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 seq#s, 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