Please enable JavaScript.

Coggle requires JavaScript to display documents.

Models (Introduction (Interfaces (How it works (Programmers only concerned…

- - - - Processes
      - Threads
      - Nodes (e.g. sensors)
    - - Objects, distributed object system
      - Components, like objects but with dependencies made more explicit
      - Objects + components: used within an organization; web services: provide public interfaces
  - - - Programmers only concerned with abstraction offered, not aware of implementation details
      - Programmers do not need to know programming language or underlying platform used to implement the service
      - Service implementation can change transparently only if interface doesn't change or changes are backwards compatible
  - - - Underlying primitatives of support for communication between processes in a DS
      - E.g. shared memory, sockets, multicast communication
    - - Based on two-way exchange between communicating entities in a DS and resulting in the calling of a remote operation / procedure / method
      - E.g. request-reply protocols, remote procedure calls, remote method invocation
    - - Space uncoupling: senders do not need to know who they're sending to
      - Time uncoupling: senders and receivers do not need to exist at the same time
      - E.g. group communication, publish-subsribe system, message queues, tuple spaces, distributed shared memory
- - - - Client-server
        
        Clients invoke services in servers and results returned
        
        Servers in turn can become clients to other services
        
        Diagram 1
        
        Client can't communicate with other clients
        
        Client can't know other IP servers of other client
        
        Client can only communicate with other clients via the server
        
        All data stored in the server
        
        Might cause performance bottleneck
        
        Central point of failure --> less reliable
        
        Lower security: if server compromised, entire system goes down
      - Peer-to-peer
        
        Each process in the system playing roles of client and server simmultaneously
        
        Data objects stored across the peers
        
        Better fault tolerance - some things might become unavailable if a peer fails, but not everything
        
        Better security, but need to trust the peers --> need to reveal IP address of peers
        
        Failure of a peer should be no worse than a failure of another peer
        
        Diagram 2
      - Hybrid
        
        Central server for indexing + querying
        
        Tells requesting client which client contains the data so that they can connect
        
        Lowers data storage on the server; much faster throughput
      - A service provided by multiple servers
        
        Service provided by several server processes interacting with each other
        
        Objects may be
        
        Partitioned(e.g. web servers)
        
        Replicated across servers (e.g. Sun Network Information Service (NIS))
        
        Diagram 3
        
        Improve performance and reliability
      - Proxy servers and caches
        
        Diagram 4
        
        Cache
        
        Store of recently used objects that is closer to the client
        
        Co-located with the client or stored in a proxy server that can be shared by several clients
        
        New objects are added to the cache replacing existing objects
        
        When an object is requested, the caching service is checked to see if an updated copy is available (fetched if not available)
        
        Benefits
        
        Privacy protection: Client cannot be identified
        
        Adds a level of redirection that might be useful
        
        Add layer of caching for reliability
        
        Use for other purposes: Can count accesses (access restriction), tracking metrics etc.
        
        Can connect to another network that it ordinarily wouldn't be able to
        
        Saves time + bandwidth
        
        Reduce load on the wide area network and web servers -> Increase availability + performance of the service
      - Mobile Code and Agents
        
        Mobile code is downloaded to the client and executed on the client (e.g. applet, now Javascipt)
        
        Good interactive response
        
        Security threat
        
        Mobile agnts are running programs that includes both code + data that travels from one computer to another
        
        Process data at the data source, rather than fetching it remotely -> replace remote invocations with local ones -> less communication overhead
        
        Security threat
        
        Diagram 5
        
        Puts more load on the browser
      - Network computers and Thin client
        
        Network computers: download OS and application software from a remote file system. Applications are run locally
        
        Thin clients: application software not downloaded, runs locally on computer server (acts just like a window for user I/O), few assumptions made about client device
        
        Diagram 6
        
        Not suitable for highly interactive graphical activities or requiring high bandwidth
        
        Don't have to manage application, or install anything --> e.g. smartwatch
  - - - Platform
      - Middleware
        
        Provides value added services
        
        Naming
        
        Security
        
        Transactions
        
        Persistent storage
        
        Event service
        
        Addes overhead due to additional level of abstraction
        
        Communication not completely hidden from applications since appropriate error handling is important
- - - - Security
      - Performance
      - Reliability
  - - - Performance of communication channels
        
        Latency: time it takes for a message to transfer from one component to another
        
        Bandwidth: amount of data sent per unit of time
        
        Jitter: variation in latency / data unit frequency
      - Computer clocks + timing events
        
        Each computer in a DS has its own internal clock
        
        Timestamps can vary due to:
        
        Initial time setting being different
        
        Difference in clock drift rates
        
        GPS can be used to synchronise clocks BUT
        
        Do not operat inside buildings
        
        Too costly
    - - Steps taken by each process
      - Transmission of messages betwen processes
    - - Synchronous system model: assumes known bounds on
        
        Assumes known bounds on
        
        Message transmission delay
        
        Local clock drift rates
        
        Execution time of each step of a process
        
        Blocks on both send and receive operations
        
        When a send is issued, the sending process is blocked until the receive is issued
        
        Whenever the receive is issued, the process blocks until a message arrives
      - Asynchronous system model
        
        !Remember interaction diagrams with time on y axis: arrows need to be pointing diagonally downwards to show delta time!
        
        Assumes no bound on the above^
        
        The send operation is non blocking
        
        Sending process returns as soon as the message is copied to a local buffer and the transmission of the message proceeds in parallel
        
        Receive operation can be blocking/non-blocking
    - - Challenging without a global clock for all processes
      - Use the concept of logical time: event number generated and used for events, rather than time of receipt
  - - - Refers to when a process/communication channel fails to perform what it is expected to do
      - Normally caused by a process crash
      - Indicated by repeated failures during invocation
      - Timeouts can be used to detect
      - A crash is referred to as a fail-stop if other processes can detect certainly that the process crashed
      - Communication omission failures can be due to
        
        Send omission failure: a message not being transporting from sending process to its outgoing buffer
        
        Receive omission failure: A message not being transported from the receiving process' incoming message buffer and the receiving process
        
        Channel omission failure: A message not being transported from p's outgoing message bugger to q's incoming message buffer
    - - Intended steps omitted in processing
      - Message contents corrupted
      - Non-existent messages delivered
      - Real messages delivered more than once
      - Any type of failure that can occur in a system
    - - Occur when time limits set on process execution time, message delivery time and clock rates drift
      - More relevant to synnchronous systems as strict bounds on timing
      - Failures
        
        Clock: process' local clock exceed the bounds on its rate of drift from real time (affects process)
        
        Performance: process exceeds the bounds on the interval between two steps (affects process)
        
        Performance: a message's transmission takes longer than the stated bound (affects channel)
    - - Validity
        
        Any message in the outgoing bugger is eventually delivered to the incoming message buffer
      - Integrity
        
        Message identical to the one sent
        
        No messages delivered twice
  - - - Protecting objects
        
        Access rights specify who is allowed to perform operations on an object
        
        Each invocation and result is associated with a principal
        
        Diagram 8
      - Securing processes and interactions
        
        Enemy (adversary) is capable of sending any message to process or reading/copying any message between a pair of processes
        
        Diagram 9
    - - Threats to processes
        
        Servers and clients cannot be sure about the source of the message
        
        Source address can be spoofed
      - Threats to communication channels
        
        Enemy can copy, alter/inject messages
        
        Denial of service attacks
        
        Overloading the server
        
        Trigger excessive delays to the service
      - Mobile code: perform operations that corrupt the server/service in an arbitray way
    - - Encryption: secret key, public/private key pair, establishing a secure channel (SSL)
      - Authentication
      - Secure channel: encryption + authentication used to build secure channels as a service layer on top of an existing communication channel