Verteilte Systeme at Hochschule Heilbronn

> Sharing of resources
> Transparency
> Openness
> Scalability
> Security

Sharing efforts, resources ...

> No single machine has a complete overview of the overall state of the system
> Machines make decisions based on local information
> There should be no “single point of failure”.
> There is no exact global time

> Asynchronous communication:
• Hides communication latency
> Transferring/relocating data/code to the user:
• Applets
• Replication (e.g. Lotus Notes,...) and caching
> Distribution:
• Splitting components into smaller, independent units with a local reference
- e.g. DNS (more on this later)
- Web server

• In terms of hardware
- Type of processor
- Type of memory
- Communication system
• In terms of operating systems
• In terms of business type (e.g. B2B, B2C, C2C, …)

> Facilitating communication between applications
> Directory services
> Persistence
> Distributed transactions
> Security

> Relevant information can be distributed across multiple machines.
> Decisions are made on the basis of local, possibly incomplete information.
> Distributed systems use concurrent processes that do not share the same address
space.
> Single points of failure should be avoided.
> There is often no common time reference.

> “Happened-before” relation:
• If “a” and “b” are events in the same process and “a” occurred before “b”, then the
following applies: a -> b (a happened before b).
• If “a” is an event in which a message is sent in a process and “b” is an event in
which the same message is received by another process, the following applies:
a -> b.
-> partial ordering of events, transitive, distinct events are said to be concurrent
> Logical clock:
• Software counter CP per process, is incremented whenever an event occurs:
• local event:
CP := CP + 1;
• process sends a message: CP := CP + 1; send(message, CP);
• process receives a message: receive(message,CQ);
CP := max (CP, CQ) + 1;

• All messages are delivered to all recipients in the same order
• messages that have a "happened-before" relation are also delivered in this order

> The message is multicast to all participants (including the sender) with Lamport’s timestamp
(counter).
> Each recipient adds the message to the local queue:
• Messages are sorted according to their timestamp
• Oldest message is at the head of the queue
> Each recipient broadcasts an acknowledgement message to every process (including itself):
• Confirmation timestamp greater than message timestamp
> Delivery of the message to the application only if:
• Message is at the head of the queue
• Everyone has acknowledged the message

Nennung des jeweiligen Gegenparts
> send(P, message)
> receive(Q, message)

• Im Programmtext einkodiert. Veränderung hat Recompilieren
  zur Folge
• Parametrisiert: Eingabe zur Laufzeit, über Eigenschaften
  (Properties), Deployment