KEMBAR78
Case Study: Distributed OS | PDF | Computer File | Operating System
Scribd
Upload
164 views17 pages

Case Study: Distributed OS

The Amoeba distributed operating system used a microkernel architecture with client-server model. Servers managed shared objects like files, directories, memory segments. Communication between clients and servers used remote procedure calls. It had modular servers like Bullet (read-only file server) and Soap (maps file names to capabilities). Processes, memory and communication were also implemented as protected objects. The system provided location independence, fault tolerance and high availability through replication and capabilities for access control.

Uploaded by

Katama Raju Bandigari
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
164 views17 pages

Case Study: Distributed OS

The Amoeba distributed operating system used a microkernel architecture with client-server model. Servers managed shared objects like files, directories, memory segments. Communication between clients and servers used remote procedure calls. It had modular servers like Bullet (read-only file server) and Soap (maps file names to capabilities). Processes, memory and communication were also implemented as protected objects. The system provided location independence, fault tolerance and high availability through replication and capabilities for access control.

Uploaded by

Katama Raju Bandigari
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 17

Case Study: Distributed OS

Distributed Systems, Lecture # 17

Amoeba OS

What if we could afford hundreds of computers per user?


Use

a shared pool of servers

These days this is called blade computing


Grid

Computing?

Location independent
Amake

Architecture

Micro-kernel

Process and thread (kernel/user space) management IPC Low level I/O management Low level Memory management

Client-Server Model
Clients are written by users Servers are written by system programmers

Essentially

isolating faults, and reliability

guarantees

Objects

Servers manage objects Clients can instantiate and access objects Objects protected by cryptographically protected capability

Files Directories Memory Segments Screen Windows Processors Disks

RPC Communication

Primitive for location independence


Stub acts as a proxy in the client address space
Resolve

name Marshal parameters Block for reply

Bullet + Soap Server

Modular Architecture

Naming File Manipulation

Bullet File server

Read-only file server


Files can only created and deleted Not modified!

Soap Directory Server

Maps file names to capabilties

Other Servers
Object replication server Process maintenance Health-monitoring server Inter-operability servers

Objects and Capabilities

Objects make the system modular


Secure Fault-tolerant More available

Capabilities
Naming as well as protection Managed in user space

Rights management
Can

downgrade rights of a capability

Takes

original bits XOR with old rights Take a one-way hash

Process Management

Process is also an object


Accessed

by process descriptor capability

Three-levels of interfaces
RPC

with process servers Library Calls Do-all dispatcher Run-server

Memory Management
Not paged or swapped Contiguous in memory Segments may be created, destroyed, read and written Simple and fast in an RPC model

Overly

restrictive

Message passing

Servers declare ports


Get_port Identifies

a service

Clients put-ports in their messages At-most once semantics

As

opposed to atleast once

Group Communication
Closed groups Reliable Broadcast

Sequencer

model

Lazy-ack

Client broadcast vs Sequencer broadcast

Layered Communication Model


LAN IP FLIP

Fast

local internet protocol FLIP addresses are persistent and location-independent

From the put-port to the FLIP address From the FLIP to the network address

You might also like