Ics362 distributed systems
1 / 51

ICS362 Distributed Systems - PowerPoint PPT Presentation

  • Uploaded on

ICS362 Distributed Systems. Dr. Ken Cosh Week 3. Review. Architectural Styles Layered Architectures Object-Based Data-Centred Event-Based System Architectures Centralised / Decentralised / Hybrid. This Week. Processes Threads Virtualisation Clients Servers Code Migration.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'ICS362 Distributed Systems' - dexter

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Ics362 distributed systems

ICS362 Distributed Systems

Dr. Ken Cosh

Week 3


  • Architectural Styles

    • Layered Architectures

    • Object-Based

    • Data-Centred

    • Event-Based

  • System Architectures

    • Centralised / Decentralised / Hybrid

This week
This Week

  • Processes

    • Threads

    • Virtualisation

    • Clients

    • Servers

    • Code Migration

What is a process
What is a Process?

  • OS

    • A program in execution

  • Key Issue

    • Managing and Scheduling Processes

    • Both in terms of OS and in terms of Distributed Systems


  • The OS creates virtual processors

    • Each for running different programs

  • OS has a process table

    • To keep track of the virtual processors

    • CPU register values, memory maps, open files, privileges, etc.

  • OS manage these independent processes

    • One process can not affect another

    • i.e. concurrency transparency

Achieving concurrency transparency
Achieving Concurrency Transparency

  • Computationally Expensive

    • Allocation

      • Create complete independent address space

      • Initialising memory segments

        • Potentially moving existing data

    • Switching

      • Saving CPU context

      • Modify Memory Management Unit (MMU)

      • Potentially swapping processes between main memory and hard disk

        • If more processes than main memory


  • Threads are like processes

    • Executing code independently from other threads

    • But with no attempt at concurrency transparency

      • Threads can share the same address space

    • Computationally less expensive

    • But programming requires more intellectual effort


  • Consider a spreadsheet program

    • Editing one cell can cause updates to formulae throughout multiple sheets.

    • How do we allow user input concurrently with calculations?

      • And perhaps autosaving

Thread implementation
Thread Implementation

  • Normally in the form of a thread package

    • Containing operations to create and destroy threads & synchronisation variables such as mutexes.

  • Implementation can be done in different ways

    • Executed entirely in user mode

    • Kernel responsible for scheduling

    • Hybrid

User level thread library
User Level thread library

  • All thread administration is kept in user’s address space;

    • Cheap to create & destroy threads

  • Switching between threads is also cheap

  • However, a blocking system call will block the process – and hence any other threads in the process.

    • E.g. when waiting for input

Kernel level threads
Kernel level threads

  • That problem is avoided by implementing threads in the OS kernel.

  • Then, every thread operation is carried out by the kernel, through system calls

    • Creation, deletion, synchronisation etc.

  • Switching threads becomes as expensive as switching processes

Hybrid implementation
Hybrid Implementation

  • Light Weight Processes (LWP)

    • LWPs run in user space in the context of a single process, but several LWPs can run per process with a shared address space.

    • Creation, deletion operations etc. run in user space without intervention by the kernel.

Threads in ds
Threads in DS

  • A convenient way of allowing blocking system calls without blocking an entire process.

  • In DS, threads can be separated to different processors (clients or servers)

Multithreaded clients
Multithreaded Clients

  • Example: A Web Browser

    • Setting up connection

    • Read incoming data

    • Pass to display component

    • Potentially connecting to multiple load balanced replicated servers to transfer data in parallel streams

Multithreaded servers
Multithreaded Servers

  • Suppose a request comes into a single threaded server.

    • The request needs to be completed before any more requests can come

  • With multithreads, a dispatcher thread can assign a worker thread to read data from a file system

    • Normally a blocking operation

  • Meanwhile the dispatcher thread can deal with more reads, or responses from other worker threads.

Multithreaded servers1
Multithreaded Servers





Operating System

Request from network


  • Of course, we are still referring to a single processor, but giving the illusion of simultaneous execution.

    • ‘Resource Virtualisation’

  • Renewed interest in virtualisation as distributed systems become popular

    • Extending (or replacing) an existing interface to mimic the behaviour of another system

    • E.g. to allow software to run on a different platform.

Applications of virtualisation
Applications of virtualisation

  • Hardware & Low level systems software evolves quicker than application software.

    • Virtualisation allows older, more stable, software to run on newer platforms

  • Networking is pervasive across heterogeneous computers

    • Virtualisation helps by letting each application run on its own virtual machine.

Virtual machine implementation
Virtual Machine Implementation

  • Virtualisation mimics the behaviour of various interfaces:

    • Interface between Hardware and Software, which can be invoked by any program.

    • Interface between Hardware and Software, which can be invoked by privileged programs such as the OS.

    • Interface of system calls offered by an OS

    • Interface of library calls offered by an API (essentially hiding the OS system calls).

Computer systems interfaces
Computer Systems Interfaces


Library Functions




System Calls

Operating System




Process virtual machine
Process Virtual Machine


Runtime System

Operating System


Virtualisation is for single processes

Virtual machine monitor
Virtual Machine Monitor


Operating System

Virtual Machine Monitor


Multiple different Operating Systems running concurrently on the same platform


  • Provide means for users to interact with remote servers

    • 1) Fat Client

      • Application specific protocol

      • E.g. Agenda application running on a PDA, synchronising with a remote (possibly shared) agenda.

    • 2) Thin Client

      • Application neutral protocol

      • Client is a terminal with no need for local storage

      • Example – X Window

X window
X Window

  • Oldest, still widely used networked user interface.

  • The heart is the ‘X-kernel’ OS running on the client

    • Containing terminal specific device drivers for monitor, keyboard & mouse.

    • Captures keyboard / mouse events and made available through Xlib library, running elsewhere and communicating through X protocol.

X window system
X Window System






Local OS

Local OS

X Kernel

Device Drivers

X window manager
X Window Manager

  • Application which dictates the “look and feel” of the display

    • How to display windows, what buttons etc.

    • Other applications adhere to these rules.

  • So.. Confusingly the X Kernel acts as a server where applications play the role of clients!

Communication efficiency
Communication Efficiency

  • This takes a lot of data communication!

    • Video stream 30 frames per second

    • 320x240 screen (PDA)

    • 24bits per pixel

    • = 53 Mbps!

  • Compression techniques are necessary

Increasing ui complexity
Increasing UI Complexity

  • Drag & Drop Functionality

  • Consider a document which contains text & images

    • Document contains multiple applications

    • Suppose we want to rotate an image

  • It needn’t reside on the client, but the client may require more processing power.

    • Or the Client needs to be fatter


  • A process implementing a specific service on behalf of a collection of clients

    • It waits for an incoming request

    • Then ensures the request is taken care of

    • Returns to wait for the next request

Iterative vs concurrent
Iterative vs Concurrent

  • Iterative Server

    • Handles the request itself and returns response if necessary to the user.

  • Concurrent Server

    • Passes the request to a separate thread or another process.

    • The other process is responsible for responding to the requesting client.


  • Clients send requests to an endpoint (port)

  • Servers listen to a particular port

    • E.g. FTP on TCP port 21, HTTP on TCP port 80

  • Or a Daemon can listen to a port and contact the specific server when requests arrive.

Stateless servers
Stateless Servers

  • Does not keep information on the state of its clients.

  • Can change its state without informing clients

  • Once an HTTP server delivers the files it forgets about the client.

    • Technically the web server might log all client requests as useful information, but if the information is lost there is no damage to the service.

Soft state servers
Soft State Servers

  • Server which promises to maintain state on behalf of the client – for a limited time

    • E.g. server promises to inform client about updates, but only for a limited time.

Stateful server
Stateful Server

  • Server maintains persistent information on its clients.

    • E.g. server allows a client to keep a local copy of a file (possibly for updating). Server then maintains a list of client/file entries.

  • This can improve performance, however if the server crashes it has to restore the list.

Session state vs permanent state
Session State vs Permanent State

  • Bear in mind that Permanent State is generally stored in a database, such as customer information, purchases etc.

  • Maintaining Session State is part of Stateful Server design.

Stateful vs stateless
Stateful vs Stateless

  • Should not affect services provided by the server.

    • If files have to be opened before they can be read from or written to, then either design should mimic this behaviour.

Server clusters
Server Clusters

  • A collection of machines connected through a network, where each machine runs one or more servers.

  • Logically organised into three tiers (layers)

    • Switch – through which requests are routed

    • Application – servers where programs run

    • File/Database – where the data is stored

Server clusters1
Server Clusters

Database / File Servers

Application Servers





First Tier

Second Tier

Third Tier

Server clusters2
Server Clusters

  • Some systems combine the data and application into a single server resulting in a two tiered system architecture

    • E.g. Streaming Media

Server clusters3
Server Clusters

  • Often Offer Multiple Services, with different machines running different services

    • Switch needs to be able to distinguish requests and services.

    • Often caused by limitations on available software & hardware, and different administrators not wanting to interfere with each other.

  • Leads to some overloaded servers, while others are idle.

    • Possibility for code migration?

Code migration
Code Migration

  • So far we have been concerned with passing data.

  • Sometimes it is useful to pass programs

    • Even while they are running

  • Sometimes overall system performance can be improved by moving processes from overloaded machines to lightly loaded machines.

    • Load in terms of CPU queue length or CPU utilisation


  • 1) A client application needs to perform many database operations

    • Why not move the operations closer to the data and then only return the results?

  • 2) A form needs to be filled in, processed and then translated into a series of database operations

    • Why not do the form processing on the client?

Code migration1
Code Migration

  • Benefits

    • Flexibility

    • Dynamically configured distributed systems

    • Software need not be pre-installed

  • Concerns

    • Security

Strong vs weak mobility
Strong vs Weak Mobility

  • A process consists of 3 segments

    • Code Segment – set of instructions

    • Resource Segment – references to necessary external resources (files, devices, printers etc.)

    • Execution Segment – current execution state of the process

Weak mobility
Weak Mobility

  • The code segment is sent

    • In this case the code must always begin from a predefined point (perhaps the start)

    • E.g. Java Applets

    • Only requires that the target machine is capable of running the code

Strong mobility
Strong Mobility

  • The execution segment is transferred as well as the code segment.

    • Code can be stopped, moved to a new machine, and restarted from where it was.

    • More general than weak mobility, but harder to implement.

The resource segment
The Resource Segment

  • Consider; you’ve designed your website on localhost, and then upload it to a webserver

    • Absolute vs Relative URLs?

    • Changing IP addresses

The resource segment1
The Resource Segment

  • Binding by Identifier

    • A precisely referenced resource, and nothing else!

  • Binding by Value

    • It doesn’t matter which resource is used, so long as the correct value is returned.

    • Does it matter if I use my C++ libraries or yours?

  • Binding by Type

    • What type of device are we referring to – a printer? A monitor?

Kinds of resource
Kinds of Resource

  • Unattached Resources

    • Easily moved – e.g. data files associated with the program

  • Fastened Resources

    • Possible, but relatively high cost – e.g. moving a database – not dependent on current machine, but infeasible to move to a new environment

  • Fixed Resources

    • Cannot be moved from environment or machine – e.g. local resources, or a local comunication end point.


  • With 3 kinds of process-to-resource bindings and 3 kinds of resource-to-machine bindings, there are 9 combinations to consider.

  • And 4 common solutions

    • Establish a Global System wide reference (GR)

    • Move the Resource (MV)

    • Copy the Value of the Resource (CP)

    • Rebind process to a locally available resource (RB)