Distributed Systems - What is Distributed

Description link

 

Why Distribute?

• resource sharing

• physical separation

• robustness

• performance

• cost-effective system evolution

 

Examples

• file server, print server, etc.

• networked management

• directory and naming services

• desktop (multimedia) conferences

• large-scale computation

• etc.

 

Why are DSs Different?

• non-zero (and variable) message transmission time

1. • processors executing in parallel
2. • multi-path links between them
3. • same message may arrive at different times at different processors
4. • possibility of “race” situations, i.e. nondeterminism in algorithm execution (or bugs)
5. • consistency of data at different sites

• probability of partial failure of collaborating components

1. not a concept found in single processor programs
2. • recovery from failures
   1. – use of alternative processor
   2. – migration of services
   3. – update and propagation of naming/routing information
3. Fault tolerant algorithms
   1. – leadership elections
   2. – distributed synchronisation

 

• large scale

1. • Abstraction
2. • Inheritance/object orientation

• environment is not totally secure

1. computer hosts may be protectable via architecture and OS etc.
2. • ... but link is very vulnerable to
   1. – tapping/message reply
   2. – hosts faking addresses
3. • ... and hosts vulnerable to
   1. – deliberate message overload
   2. – faked services

 

 

Distributed Programming

• Remote Procedure Call
  1. common approach
  2. • client-server model
  3. • caller’s arguments are marshalled by “stubs”, put in a packet and sent to remote proc.
  4. • problems with memory addresses
     1. - need args to be sent by “value”
  5. • execution semantics when failure
     1. – at-least-once (cheap and easy but ...)
     2. – at-most-once (relatively easy)
     3. – exactly once (expensive protocol)
  6. • how is server located?
     1. – name server based on type matching
     2. – trader includes other attributes e.g. location of device, options, etc.
     3. – version management too
  7. parameter security
     1. – may need to pass encryption keys or other security tokens as parameters
  8. • Interface Definition Language (IDL)
     1. – indicates type and order of parameters
     2. – signature for matching in name server
     3. – possibly security indication for stubs
• Real World
  1. often termed “Middleware”
  2. • support by environments such as DCE, CORBA etc.
• Transparency
  1. is desirable, but may not be achievable:
     • – distribution - effects of distribution (delays etc.) should be invisible to user
     • – location - location of components should be irrelevant
     • – migration - remote objects may relocate during use
     • – failure - recovery from faults
• Security
  1. Use of cryptographic techniques to deal with:
     1. • secrecy
     2. • authentication of individuals and messages
     3. • replay and faking attacks
     4. • can also provide access control to object methods