The key characteristics of Chapter 1 are generic requirements
for any distributed system. Specific goals can be expressed as
guarantees.
Basic Design Issues
- Naming
- Names should have global meanings; a name interpreter
translates names to allow access to resources.
- Communication
- fast, reliable, high-level
- Software Structure
- openness, data abstraction, work with existing services
- Workload allocation
- good performance under changing conditions
- Consistency maintenance
- difficult to acheive cheaply
Naming
To access a resource it doesn't manage, a process must have a name for it.
Names are interpreted by users or programs,
identifiers only used by programs.
Name resolution: translating a name into a form in which it
can be used to access a resource.
Communication identifier: usual target of name resolution
in distributed systems (e.g. IP address/port number)
issues
choice of name space
structured or flat? for object-based, all objects share a single name space
name resolution mechanism
name service: holds copies of names and their translations.
or, can let resource manager resolve names.
clients can cache recent translations to reduce communications.
Names are resolved in context. Resolution requires a name
and a context. Name service has a database for each context,
tries to keep them up to date. Important for large systems.
Some names are human readable.
The name can be structured to give it's position in a hierarchy.
Each part of the name has a different context, so names can be
reused in diffferent contexts. This allows the name space to grow
very large while reducing risk of conflicts.
(e.g., filenames, Internet domain names)
Some names are designed to prevent unauthorized access
by being chosen to be hard to guess or forge: called capabilities.
Embedding location info in names violates transparency.
Pure names are uninterpreted bit strings that must be
resolved via lookup.
Communications
involves transfer of data between processes, sometimes with synchronization.
The processes must share a communications channel. (e.g., sockt, port)
message passing
send and receive are the basic operations.
They can be synchronous (blocking), where the sender blocks until
the receiver receives the message,
or asynchronous (non-blocking), where the message sent is queued
until the receiver asks for it, and the sender immediately continues.
Recieve usually blocks if no message is pending.
(Hoare's CSP, Hansens's DP).
client-server communication
(Fig 2.2)
Usually uses Remote Procedure Calling (RPC).
Servers don't have to know about clients, since each request
contains a communication identifer that is used for the reply.
Clients need a way to find servers at run time: dynamic binding.
Servers register with a name service at startup, clients query name service.
group multicast
(Fig 2.3)
A message sent with a "group send" is received at every process in the group:
multicasting. Handy for locating an object (ask all servers),
fault tolerence, multiple update.
Without hardware support, the message must be sent to each member
using a point-to-point message pass.
Membership transparency: are the members of the group visible to senders?
in ISIS, membership is transparent.
function shipping
Instead of asking a server to perform a predefined function,
we can send it code for the function we want to perform,
and the server provides an environment for its execution.
Allows the server to be extended by clients.
Requires use of a specific language, usually interpreted.
(E.g., Display Postscript, Tcl).
Software structure
Centralized operating system structure is monolithic:
with a single interface, the system call.
Distributed system services, however, can each provide their own interface,
and the system can be extended with new services.
(Fig 2.4) shows how centralized systems are layered. The operating system
kernel provides:
- basic resource management
- memory management, process control, device handling
- user and applications services
- authentication and access control, file management, clock facilities
For distributed systems, want an extendible set of services,
and the kernel only does basic resource management (+IPC).
Services that don't need to be in the kernel are implemented
as user processes. Call these open services.
Systems can be configured to include only those services that are needed,
and new services can be added. (Fig 2.5)
A distributed operating system provides 3 main categories of service:
- OS kernel services
- can use a UNIX kernel, but many services in the kernel can be made open.
microkernels provide only very basic services (memory,
processes, IPC), leaving others open.
- Open services
- support application programming (files, mail, locks)
- distributed programming support
- RPC, multicasting
Workload allocation
Consistency maintenance
User Requirements