Distributed Systems Models

Architectural Models: considers

  • Placement of the component across the Network, to distribute workload and data.
  • Interrelationships between components.

Platform: Lowest-level hardware and software layers, including OS till APIs.

Middleware: Communication and resource sharing for distributed apps.

  • CORBA: naming, security, transactions, persistent storage and event notification.
  • Fault tolerance: needs to be included in the application, not only in Middleware

System Architecture:

  • Client – Server: what to say about this
  • Services by multiple servers: replication to increase performance and availability.
  • Proxys and Caches: Caches in clients or in Proxies
  • Peer Processes: Removing server reduces inter-process delays. Code in peer processes maintains consistency and synchronization.

Variations on Client-Server Model:

  • Mobile Code: Applets, etc
  • Mobile Agents: Running program moving, code and data, from one node of the network to another carrying out tasks. e.g. worm
  • Network Computers: diskless Computers loading data/code from a remote server.
  • Thin Clients:  Software Layer capable of running a windows-based UI, executing programs in a remote computer. e.g. X11
  • Mobile Devices and Spontaneous Networking: Mobile phones and embedded appliances. Key features: easy connection & easy integration, e.g. DLNA. Issues: Limited connectivity and security & privacy
  • Discovery Services: registration interface & lookup interface

Design requirements for distributed architectures:

Performance issues:

  • Responsiveness: User interaction requires low delays. e.g. few software layers.
  • Throughput: Considers computational work done both in clients and servers + communication delays
  • Balancing Computation Loads: E.g. applets, server HA, etc

Quality of Service:

  • Non-functional properties: reliability, security, performance and adaptability (to meet changing system configuration and resource availability).
  • Involves networks and Operating Systems.

Caching and Replication:

  • Web-caching Protocol:  browsers and proxies store webpages and check whether the cache is up to date using expire time and server time together.

Dependability issues:

  • Fault Tolerance: keep running despite of hardware, software or network failure. Reliability achieved using redundancy, which is expensive so there are limits. Redundancy also applied in protocol reliability.
  • Security: Not expose sensitive data when no necessary.

Fundamental Models:

Interaction model:

  • Processes complex interactions: DNSs or peer processes.
  • Performance of communication channels: latency, bandwidth, Jitter (relevant to multimedia data)
  • Computer Clocks and timing events: correcting clock drift rate using GPS.
  • Two variants:
  • Synchronous distributed systems: each step has lower/upper bounds, msgs received within a bound, local clocks have a known drift rate bound
  • Asynchronous distributed systems: No bound at all.
  • Event ordering: problem without synch clocks. Logical time used.

Failure Model:

Omission failure:  process or communication fails to perform actions it is supposed to do.

  • Process Omission Failure: Timeouts are used to detect crashes. Fail-stop, know exactly whether a process has crashed.
  • Communication omission failures
  • Arbitrary failures: wrong values, steps, etc. Checksum used to fight this.

Timing Failures: In synchronous systems. Slowness in Asynch systems not a timing failure

Masking Failures: Redundancy, checksums

Reliability of one-to-one Communications: Validity, any message going out is eventually delivered. Integrity, the message received is identical to one sent and no dups.

Security Model:

What a great definition: “The security of a distributed system can be achieved by securing the processes and the channels used for their interactions and by protecting the objects that they encapsulate against unauthorized accses.”

Protecting Objects: each invocation/relation associated to a principal (a user) and the server checks whether it has enough privileges.

Securing processes and their interactions: crap

The Enemy:

  • Threats to processes: they don’t know the other sides real identity
  • Threats to communications: Integrity attacks.

Defeating Security Threats:

  • Cryptography and shared secrets: PKI/shared key
  • Authentication: PKI/shared key
  • Secure channels: deliver integrity

Other possible Threats: DoS and worms

The uses of security models: stands for the need of a threat model, not just plain use of cryptography and access rights management.