subject revision distributed systems principles and paradigms n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Subject Revision Distributed Systems: Principles and Paradigms PowerPoint Presentation
Download Presentation
Subject Revision Distributed Systems: Principles and Paradigms

Loading in 2 Seconds...

play fullscreen
1 / 136

Subject Revision Distributed Systems: Principles and Paradigms - PowerPoint PPT Presentation


  • 140 Views
  • Uploaded on

Subject Revision Distributed Systems: Principles and Paradigms. Dr. Christian Vecchiola Postdoctoral Research Fellow csve@unimelb.edu.au Cloud Computing and Distributed Systems (CLOUDS) Lab Dept. of Computer Science and Software Engineering The University of Melbourne. Outline. Part I

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

PowerPoint Slideshow about 'Subject Revision Distributed Systems: Principles and Paradigms' - jubal


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
subject revision distributed systems principles and paradigms

Subject Revision Distributed Systems: Principles and Paradigms

Dr. Christian Vecchiola

Postdoctoral Research Fellow

csve@unimelb.edu.au

Cloud Computing and Distributed Systems (CLOUDS) Lab

Dept. of Computer Science and Software Engineering

The University of Melbourne

outline
Outline
  • Part I
    • Distributed Systems Fundamentals
    • Socket Programming
    • Multithreaded Programming
  • Part II
    • Operating Systems
    • Distributed System Models
    • Programming with Distributed Objects
  • Part III
    • Security
    • Distributed File System
    • Naming Services
  • Conclusions
part i1
Part I
  • Distributed Systems
    • Definitions
      • Colouris, Dollimore, Kindberg

“A system in which hardware or software components located at networked computers communicate and coordinate their actions only by message passing.”

      • Tanenbaum and Van Steen

“A distributed system is a collection of independent computers that appear to the users of the system as a single computer.”

      • Leslie Lamport

"A distributed system is one on which I cannot get any work done because some machine I have never heard of has crashed.“

part i2
Part I
  • Distributed Systems
    • Definitions
      • Main use:
        • Connecting Users and Resources
      • Characteristics:
        • Heterogeneity
        • Lack of Global Clock
        • Concurrent and Autonomous
        • Independent Failures
      • Desired Properties:
        • Transparency
        • Openness
        • Scalability
        • Enhanced Availability

Hide users/developers from the separation of components so that the system is perceived as a whole:

- location

- access

- migration

- concurrency

- failure

- replication

- application

The ability to interoperate with other systems and integrate new features with minimal changes, by means of open interfaces and standards.

The ability to exhibit acceptable performance as one of more dimensions of the systems increases.

Scalability in terms of number of nodes, users, operations.

The ability of serving users despite the presence of failures. A failure in the system should never bring the system down.

“Fault tolerance: no failure despite faults.”

  • Distributed Systems are heterogeneous in terms of:
  • Hardware Architectures
  • Operating Systems
  • Programming Languages
  • Software Interfaces
  • Communication Models
  • Information Representation
  • Security Measures
  • Being the result of the cooperative action of distinct computing elements…
  • There is no single time reference (not applicable efficiently)
  • Each system performs its activities together with the others
  • For these reasons failures are not related and occur at any time.
part i3
Part I
  • Distributed Systems
    • Examples:
      • Clusters
      • Grids
      • Clouds
      • The Internet!
    • Practical Applications
      • Communities (Virtual teams, organizations, social networks)
      • Science (e-Science)
      • Business (e-Business)
part i4
Part I
  • Socket Programming
    • Client Server Computing
      • Request – Response model
      • Two roles:
        • Client: makes requests and waits for responses
        • Server: serves requests and produces responses

request

result

network

client

server

part i5
Part I
  • Socket Programming
    • Technologies for communication
      • Java RMI
      • RPC
      • NET Remoting
      • AJAX-based
      • CORBA
      • FTP, HTTP, SMP

All of them are based on the Client Server model, and use Socket Programming (at some level) as communication abstraction and implementation technology.

part i6
Part I
  • Socket Programming
    • Definition

“A socket defines an endpoint of a communication between two processes and it is identified by an address (mostly IP) and a port.”

    • Where does socket fit?

Sockets are a programming interface for communication between two end points.

They provide an interface for programming networks at transport layer.

Application

(http,ftp,telnet,…)

Transport

(TCP, UDP,..)

TCP/IP Stack

Network

(IP ..)

Link

(Device driver)

part i7
Part I
  • Socket Programming
    • Properties
      • A socket is identified by an address and a port
      • They are implemented on top of TCP/UDP
      • Network communication is similar to file I/O
      • A socket handle is treated as a file handle
      • Socket programming is language independent
        • The abstraction of socket is identical in all the languages
        • Allows for interoperation between different languages and platforms
      • There are two types of socket:
        • Server socket  Server component of Client-Server model.
        • Client socket  Client component of Client-Server model.
part i8
Part I
  • Socket Programming

Output stream

Create user socket (random port: 39332)

Input stream

Server: 128.250.25.158

Server Socket: 1254

Connect(128.250.25.158, 1254)

It can be a host name like: mandroo.cs.mu.oz.au

Client Socket

part i9
Part I
  • Socket Programming
    • APIs for Socket Programming
      • JAVA
        • java.net.ServerSocket
        • java.net.Socket
        • java net.DatagramSocket
        • java.net.DatagramPacket
      • .NET
        • System.Net.Sockets.Socket
        • System.Net.Sockets.TcpClient
        • System.Net.Sockets.TcpListener
        • System.Net.Sockets.UdpClient

Sockets are mostly used over TCP and identify a connection oriented communication model.

UDP is connection-less communication model and it is based on the concept of Packet.

part i10
Part I
  • Multi-threaded Programming
    • Modern systems…
      • …perform multiple operations at the same time
      • …host multiple processes running concurrently

games

web & email

office automation

multimedia

pictures

Multitasking

part i11
Part I
  • Multi-threaded Programming
    • Modern applications…
      • …perform multiple operations at the same time
      • …host multiple threads running concurrently

Background printing

Threads

GUI rendering

Application core logic

Multithreading

part i12
Part I
  • Multi-threaded Programming
    • Characterizing a Thread

“A thread is a set of instructions that are executed sequentially within an program.”

public class SingleThread

{

public static void main(String[] args) {

…… …

for (int i=0; i<args.Length; i++) {

if (args[i].equals("-r") == true) {

SingleThread.executeOptionR(args);

}

}

}

private static void executeOptionR(String[] args) {

…… …

}

}

One Thread

part i13
Part I
  • Multi-threaded Programming
    • Characterizing a Thread

“A multi-threaded application executes multiple threads within the same process space.”

public class MultiThread

{

public static void main(String[] args) {

…… …

for (int i=0; i<args.Length; i++) {

if (args[i].equals("-op1“) == true) {

Thread t1 = new Thread(Op1);

t1.start();

}

if (args[i].equals("-op2“) == true) {

Thread t2 = new Thread(Op2);

t2.start();

}

}

}

}

public class Op1 implements Runnable

{

public void run() {

…… …

}

}

public class Op2 implements Runnable

{

public void run() {

…… …

}

}

Thread

Thread

Thread

part i14
Part I
  • Multi-threaded Programming
    • Threads and Processes

Multithreaded Process

  • When a process starts a default (main) thread is created.
  • From this thread other threads can be created.
  • Each of these threads can run for different periods
  • Each of these threads can create new threads
  • All the threads have access to a shared memory space.

Common address space

Main Thread

Thread

Thread

Execution Timeline

Thread

Thread

Multiple Execution

Streams

part i15
Part I
  • Multi-threaded Programming
    • What is the use of threads?
      • Parallelism and concurrent execution of independent tasks / operations.
      • Implementation of reactive user interfaces.
      • Non blocking I/O operations.
      • Asynchronous behavior.
      • Timer and alarms implementation.
    • Major uses:
      • Throughput computing
      • GUI rendering
part i16
Part I
  • Multi-threaded Programming
    • Multi-threaded Servers
      • Allows to improve the throughput of server applications
      • Three Architectures
        • Thread per request
        • Thread per connection
        • Thread per component/object
      • Use of pooling to optimize OS resources.
part i17
Part I
  • Multi-threaded Programming
    • Synchronization
      • The use of multiple execution streams executed concurrently lead s to…
        • … contention…
        • … inconsistency of state ….
        • … unexpected / unpredictable behavior …

… while accessing shared resources.

      • Thread synchronization helps solving this issues by using….
        • … appropriate programming patterns
        • … appropriate programming language constructs
part i18
Part I
  • Multi-threaded Programming
    • Synchronization
      • There are several issues introduced by the use of shared resources
        • exclusive access
        • concurrent and compatible accesses
        • proper sequencing of operations
        • deadlock avoidance techniques
      • Basic techniques
        • use of lock/synchronized for exclusive access
        • use of wait-notify / wait-set patterns
        • resource acquisition ordering
part ii1
Part II
  • Operating Systems
    • Constitute…
      • … a common sub-stratus for all applications
      • … an essential component for DS
    • Operations:
      • Resource management (memory, CPU, disks)
      • Application scheduling (program and services)
      • Device access (printers, ad-hoc devices, etc..)
      • User management
part ii2
Part II
  • Operating Systems
    • Main Design Principles
      • The two key examples of kernel design approaches are:
        • Monolithic
        • Microkernel
      • Key difference: what does belong to the kernel?
      • Three main models:
        • Monolithic OS
        • Layered OS
        • Microkernel-based OS
      • The first two can be considered monolithic

The chambers 20th century dictionary definition of monolithic is: a pillar, column, of a single stone: anything that resembling a monolithic, massiveness.

part ii3
Part II
  • Operating Systems
    • Monolithic vs Microkernel

S1

.......

S3

S4

S1

S2

.......

S2

S3

S4

.......

Monolithic Kernel

Micro-Kernel

Server:

Kernel code and data:

Dynamically loaded server program:

part ii4
Part II
  • Operating Systems
    • Monolithic Kernel OS
    • Better application performance
    • Hard to extend
    • Example: MS-DOS

Application

Programs

Application

Programs

UserMode

Kernel Mode

System Services

Hardware

part ii5
Part II
  • Operating Systems
    • Layered Kernel OS

Application

Programs

Application

Programs

User Mode

Kernel Mode

System Services

Memory & I/O Device Mgmt

Process Scheduler

Hardware

part ii6

User

Kernel

Part II
  • Operating Systems
    • Micro Kernel OS
    • Tiny OS kernel providing basic primitive (process, memory, IPC)
    • Traditional services becomes subsystems
    • OS = Microkernel + User Subsystems
    • Examples: Mach, PARAS, and Chorus

Client

Application

OS Emulators

File

Server

Network

Server

Display

Server

Microkernel

Send

Reply

Hardware

part ii7
Part II
  • Operating Systems
    • Pros and Cons
      • Micro-Kernel main advantages:
        • Extensibility and its ability to enforce modularity beyond memory protection boundaries
        • A relative small kernel is more likely to be free of bugs than one that is larger and complex.
      • Monolithic OS main advantage:
        • Relative efficiency with which operations can be invoked is high because even invocation to a separate user-level address space on the same node is more costly.
part ii8
Part II
  • Distributed Systems Models
    • Distributed system models helps in…
      • ..classifying and understanding different implementations
      • ..identifying their weaknesses and their strengths
      • ..crafting new systems outs of pre-validated building blocks
    • We will study distributed system models from different perspectives
      • Structure, organization, and placement of components
      • Interactions
      • Fundamental properties of systems
part ii9
Part II
  • Distributed Systems Models
    • Three different perspectives to study from:
      • Architectural models
        • Capture structure and organization of systems
        • Define placement and interaction among components
      • Design requirements
        • Express goals in terms of performance and reliability
      • Fundamental models
        • Based on the fundamental properties
        • They give insights on..
          • …characteristics of the systems
          • …associated potential failures and security risks
part ii10
Part II
  • Distributed Systems Models
    • Architectural Models
      • First rough classification (by process types):
        • Server processes
        • Client processes
        • Peer processes
        • (Possible variations and compositions)
      • Other Models:
        • Mobile Code based systems
          • Dynamic code = security is a concern
        • Ad-hoc Systems (based on proximity networks)
          • High dynamism and volatility, more heterogeneity,
          • Limited capabilities

Peer-to-Peer Systems

Client-Server Systems

part ii11
Part II
  • Distributed Systems Models
    • Architectural Models
      • Layered model (reference architecture)
      • Advantages
        • Breaking up complexity
        • Decomposition of functions and responsibilities
        • Different levels of abstraction

Distributed systems cover this part of the layered architecture and might be internally organized into layers as well.

Application & Services

Middleware

Operating System

Computer and Network Hardware

part ii12
Part II
  • Distributed Systems Models
    • Architectural Models
      • Client Server Model
        • Mostly cited in the case of distributed systems.
        • Most widely employed.
        • Based on:
          • Two roles: server and client
          • Communication pattern:
            • asymmetric
            • request (client) – response (server)
        • Examples
          • HTTP, SMTP, DNS, NNTP
part ii13
Part II
  • Distributed Systems Models
    • Architectural Models
      • Client-Server
        • Two-tier model (classic)
        • Three-tier (when the server, becomes a client)
        • Multi-tier (cascade model)

client

server

client

server

Server/client

server

client

Server/client

Server/client

server

part ii14
Part II
  • Distributed Systems Models
    • Architectural Models
      • Peer-to-Peer Model
        • All the processes play a similar role.
        • No distinction between server and client that are played by each component.
        • Cooperative interaction.
        • Avoids centralization and potential SPOF.
        • More difficult to manage.
        • Provides a better scalable infrastructure (1000s hosts).
        • Examples
          • P2P File sharing (OpenNAP, eMule, etc..).
          • Distributed Hash tables.
part ii15
Part II
  • Distributed System Models
    • Architectural Models
      • Peer-to-Peer Model

peer

peer

peer

peer

peer

peer

peer

part ii16
Part II
  • Distributed Systems Models
    • Architectural Models
      • Variations of the previous two models
        • Multiple Server (kind of multi-tiers)
        • Cache and Proxy architectures
        • Mobile Code
        • Mobile Agents
        • Network Computers
        • Thin Clients
        • Mobile devices and ad-hoc networking
part ii17
Part II
  • Distributed Systems Models
    • Design Requirements
      • Aspects to be considered:
        • Performance
          • Responsiveness
          • Throughput
          • Load-balancing
        • Quality of Service
          • Analysis of non-functional properties of systems
          • Applications:
            • Reliability & Security
            • Performance, and Adaptability
part ii18
Part II
  • Distributed Systems Models
    • Design Requirements
      • Aspects to be considered:
        • Data and Replica management (caching)
          • Increase of throughput and availability
        • Dependability
          • How much we can trust, rely on a system?
          • How to measure?
            • Attributes: Availability, Reliability, Safety, Integrity, Confidentiality, Maintainability.
          • What tampers it?
            • Faults, Failures, Errors
          • Means as a support of dependability?
            • Prevention, Fault Tolerance, Forecasting
part ii19
Part II
  • Distributed Systems Models
    • Fundamental Models
      • Addresses the following questions:
        • What are the main entities in the system?
        • How do they interact?
        • What are the characteristic that affect their individual and collective behavior?
      • Aspects to consider:
        • Interaction: communication and coordination
        • Failure: classification of Faults/Failures
        • Security: classify attacks and devise potential countermeasures
part ii20
Part II
  • Distributed Systems Models
    • Fundamental Models
      • Interaction Model
        • Facts:
          • Communication takes place with delays (often of considerable duration)
          • Delays and the absence of global time limit the accuracy with which we can coordinate processes.
        • What are the element of interest?
          • Performance Communication Channels
          • Computer Clocks and Timing Events
          • Synchronous vs Asynchronous models
          • Event Ordering (Lamport: logical event ordering)
part ii21
Part II
  • Distributed Systems Models
    • Fundamental Models
      • Failure Model
        • What is failure?
          • Process and communication may depart from what is the expected behavior.
        • What is a failure model?
          • Defines the ways in which failure may occur in order to provide understanding of the effects it can cause.
        • Observations
          • Different kinds of failures can be addressed differently
          • Different kinds of failures denote different (major or minor) problems
          • Classification: omitting, arbitrary, timing [failures].
part ii22
Part II
  • Distributed Systems Models
    • Fundamental Models
      • Security Model
        • Goals:
          • Securing the processes composing the system.
          • Protecting the objects they encapsulate by unauthorized access.
            • Avoiding unauthorized access
            • Identifying requests (Principal)
          • Securing the channels they use to communicate.
            • Encryption and Cryptography
        • Measures:
          • Creation of a threat model.
part ii23
Part II
  • Distributed Systems Models
    • Fundamental Models
      • Security Model
        • Threat Model
          • A careful analysis of all the aspects of a DS (hardware, software, network, and human) allows to build a threat model.
          • The threat model lists all the potential attacks that the systems might be exposed to.
          • Security costs have to be balanced against these attacks (“how much your enemy is willing to pay to break your security?”)
part ii24
Part II
  • Distributed Objects Programming
    • Reference Model
      • Object Oriented Programming
      • Stub-skeleton model (aka. Client-Server)
      • Concept of Proxy
    • Technologies Studied
      • Java RMI
      • .NET Remoting
      • CORBA (no samples)
      • Web Services
part ii25
Part II
  • Distributed Objects Programming
    • Java RMI (Remote Method Invocation)
      • Implements a RPC model for Objects in Java
      • Components
        • Java Remote Object: java.rmi.server.UnicastRemoteObject
        • Java Remote Interface: java.rmi.Remote
        • Java Client (Stub) object
        • Java RMI Registry: java.rmi.Naming (rmiregistry)
      • Properties
        • Transparent method invocation pattern over the network
        • Automatic parameter and return value marshalling
part ii26
Part II
  • Distributed Objects Programming
    • Java RMI (Remote Method Invocation)
      • System View

RMI

RMI

Registry

RMI

RMI

Server

RMI

URL

Protocol

RMI Client

URL Protocol

Web

Server

URL Protocol

Web

Server

part ii27
Part II
  • Distributed Objects Programming
    • Java RMI (Remote Method Invocation)
      • Architecture

Request

Skeleton &

Dispatcher for B

Object B

Communication

Module

Proxy for B

Object A

Communication

Module

Remote Reference

Module

Remote Reference

Module

JVM Server

JVM Client

Reply

part ii28
Part II
  • Distributed Objects Programming
    • Java RMI (Remote Method Invocation)
      • RMI System Design
        • Remote Interface
          • Exposes the set of methods and properties available
          • Define the contract between the client and the server
          • Constitutes the root for both stub and skeleton
        • Servant component
          • Represent the remote object (skeleton)
          • Implement the remote interface
        • Server component
          • Main driver that makes available the servant
          • It usually register with the naming service
        • Client component

Example: RemoteTime

part ii29
Part II
  • Distributed Object Programming
    • Java RMI (Remote Method Invocation)
      • Security
        • Bottom Line:
          • Making available a remote interface exposes the hosting system to potential breaches into the security!
        • Observation:
          • It is a programming problem first (what do we want to expose and what operations we implement)
          • It is a security problem always (how we make accessible these operations)
        • Solution:
          • Java RMI Security Policies
          • Java Security Manager

This is part of the java security framework

part ii30
Part II
  • Distributed Object Programming
    • Java RMI (Remote Method Invocation)
      • Security
        • Security Policies:
          • Easy configuration of security
          • Use of default permissions
          • Grant – deny pattern
        • Security Manager:
          • Runtime component controlling access to resources
          • Monitors file/network access, dynamic code loading, …
          • Executes policies
          • Allows for a finer control on security since a custom implementation can be provided
part ii31
Part II
  • Distributed Object Programming
    • .NET Remoting
      • .NET built-in infrastructure for IPC
      • Allows method invocation across Application Domains
      • Highly sophisticated and customizable architecture
      • Fundamental Concepts
        • Application Domain
        • Remote Object
        • Proxy Object
        • Channels
        • Activation
        • Lifetime
part ii32
Part II
  • Distributed Object Programming
    • .NET Remoting
      • Application Domains
        • Define the execution context of any instance, rather than a control flow
        • They are lightweight processes inside a single process
        • Each process as at least one application domain
        • Define the boundary of a local call
        • A remoting call always occurs between application domains
        • Within a process, threads are shared among all the existing application domains
part ii33
Part II
  • Distributed Object Programming
    • .NET Remoting
      • Communication Reference Model

AppDomain

AppDomain

AppDomain

AppDomain

AppDomain

Process

Process

Process

Host

Host

Network

part ii34
Part II
  • Distributed Object Programming
    • .NET Remoting
      • Remotable Objects & Proxies

Proxy of B

Object B

Object A

Remoting Infrastructure

Remoting Infrastructure

Channel

Channel

Channel

Channel

Channel

Channel

Binary/SOAP/XML/Custom

Must extend MarshalByRefObject otherwise passed by value!

part ii35
Part II
  • Distributed Object Programming
    • .NET Remoting
      • Channels
        • Message transport across AppDomain boundaries
        • A channel
          • Listens for messages at an end point
          • Sends message from an end point
          • Sends an receive messages
        • Abstraction for the transport layer
        • Communication with non .NET processes
        • Hooks for custom protocol implementation
part ii36
Part II
  • Distributed Object Programming
    • .NET Remoting
      • Activation
        • Activation is the process of creating a remote object.
        • Client Side Activation
          • Objects are created on the server on a call to Activator.CreateInstance(…)
          • Lifetime is controlled by client scope
        • Sever Side Activation
          • Objects are created by the server when needed
          • Clients call Activator.GetObject(…)
          • Activation is controlled by WellKnownObjectMode
            • SingleCall: one object for each method invocation
            • Singleton: one object for all the clients
part ii37
Part II
  • Distributed Object Programming
    • .NET Remoting
      • Lifetime
        • Lifetime determines the existence of a remote object on the server side
        • Different lifetimes
          • [server] SingleCall: the y exist to serve the method call
          • [server] Singleton: variable and configurable lifetime
          • [client] : they exist as long as they can be referred in the client scope
        • Lease managers control MBR objects lifetime
          • MBR objects have a lifetime lease
          • Lease managers periodically check whether the lease is expired
          • On expiration lease managers can as for renewal
part ii38
Part II
  • Distributed Object Programming
    • CORBA
      • It is a specification more than an implementation
        • It does not focus on a specific language/ technology
        • It provides a reference architecture including
          • Protocols for accessing distributed components
          • Interfaces
          • Infrastructure for deploying distributed systems
      • Compared to RMI and Remoting
        • It has an object-oriented model
        • It can be implemented in non OO languages
        • It aims to be language agnostic
part ii39
Part II
  • Distributed Object Programming
    • CORBA
      • It is a specification more than an implementation
        • It does not focus on a specific language/ technology
        • It provides a reference architecture including
          • Protocols for accessing distributed components
          • Interfaces
          • Infrastructure for deploying distributed systems
      • Compared to RMI and Remoting
        • It has an object-oriented model
        • It can be implemented in non OO languages
        • It aims to be language agnostic
part ii40
Part II
  • Distributed Object Programming
    • CORBA

Implementation Repository

Interface Repository

ORB Core

ORB Core

Process

Process

Static or Dynamic

Invocation

ORB Core

Client Object

ORB Core

Static or Dynamic

Skeleton

Adaptor (POA)

Server

(Remote) Object

Client Process

Server Process

What are they?

part ii41
Part II
  • Distributed Object Programming
    • CORBA
      • Components
        • Client Process
          • Proxy Object
          • ORB Core
        • Server Process
          • Server Object
          • Portable Object Adapter
          • ORB Core
        • Interface Repository
          • ORB Core
        • Implementation Repository
          • ORB Core
  • The ORB constitutes a well define middleware that allows for interoperability between different vendor implementation of the CORBA architecture.
  • ORB Operations:
  • transmitting requests
  • receiving requests
  • dispatching calls
  • - keep track of server objects
part ii42
Part II
  • Distributed Object Programming
    • CORBA
      • Skeleton & Stub
        • Communication pair of a CORBA interface:

CORBA

INTERFACE (IDL)

Vendor A

Vendor B

Object Management Services

Object Management Services

STUB

SKELETON

Portable Object Adapter (POA)

Portable Object Adapter (POA)

Services

Services

Services

ORB Core

part ii43
Part II
  • Distributed Object Programming
    • CORBA
      • Interface Definition Language (IDL)
        • Type System
          • Primitive Types: octet, short, unsigned short, long, unsigned long, float, double, char, boolean, any (custom types)
          • Complex Types: array, sequence, string, record, enumerated union
          • Reference Types: object (root type of all IDL definitions)
        • Parameter Passing
          • By value: primitive and complex types
          • By reference: object references
part ii44
Part II
  • Distributed Object Programming
    • CORBA
      • Dynamic Interface Invocation (DII)
        • CORBA has some reflective capabilities
        • It allows…
          • …for the discovery of interfaces
          • …using types not known at compile time
        • How it works?
          • Use of the interface repository for type discovery
          • Dynamic construction of the client stub
        • Advantages
          • Support for remote server interface update
          • Integration of legacy code
part ii45
Part II
  • Distributed Object Programming
    • CORBA
      • Dynamic Skeleton Interface (DSI)
        • Provides a runtime binding for CORBA component that do not have a IDL-based compiled skeleton
      • How it works?
        • Use of interface repository
          • Before dispatching the invocation request
          • The interface repository is looked up to identify the target component
        • Advantages
          • Integration of legacy code
part ii46
Part II
  • Distributed Object Programming
    • Web Services
      • Definition
        • Infrastructure and a technology for distributed computing by using the Web as a transport layer
        • Language and platform independent interaction pattern based on open standards and technologies (XML,SOAP,HTTP)
      • Elements of interest
        • Architecture
        • Interaction
        • SOAP, UDDI, WSDL, REST
        • RESTful Web Services
part ii47
Part II
  • Distributed Object Programming
    • Web Services
      • Architecture
        • A Web service is generally hosted in a Web Server
          • It is identified by an URI
          • (Sometimes, applications can also host WSs by implementing minimal web servers)
        • A client can locate a WS in two ways
          • It can query the UDDI registry to find a WS that matches its requirements
          • It knows already the location of the WS
part ii48
Part II
  • Distributed Object Programming
    • Web Services
      • Interaction
        • The Web Service publishes a WSDL document
          • it is an XML specification of the WS interface
          • it defines: exchanged types, methods, parameters and return values
          • WSDL : Web Service Definition Language
        • The client
          • reads the WSDL and builds a WS-client
          • the WS-client is an in-process object mapping the WS interface
          • automatic tools are also available (.NET, axis)
part ii49
Part II
  • Distributed Object Programming
    • Web Services
      • WS Method Invocation

WSDL

Web Service Object

Client

Object

WSDL

Web

Server Engine

Web

Server Engine

WSDL Request/Response

Client

Object

WS

Client

WSDL

WS Method Invocation

Client Process

Web Server Process

Host

Host

HTTP POST/GET (SOAP)

Network

part ii50
Part II
  • Distributed Object Programming
    • Web Services
      • UDDI
        • Universal Description, Discovery and Integration
          • http://www.uddi.org
        • UDDI creates a platform-independent, open framework & registry for:
          • Describing services
          • Discovering businesses
          • Integrating business services
        • The UDDI may be less used than predicted, especially on the Internet level
part ii51
Part II
  • Distributed Objects Programming
    • Web Services
      • WSDL
        • Web Services Definition Language
          • http://www.w3.org/TR/wsdl/
        • An XML-based language for describing Web Services
          • what the service does (description)
          • how to use it (method signatures)
          • where to find the service
        • It does not depend on the underlying protocol
        • But: It is not much human-readable
part ii52
Part II
  • Distributed Objects Programming
    • Web Services
      • SOAP
        • Simple Object Access Protocol
          • http://www.w3c.org/TR/SOAP/
        • A lightweight protocol for exchange of information in a decentralised, distributed environment
        • Two different styles to use:
          • to encapsulate RPC calls using the extensibility and flexibility of XML
          • …or to deliver a whole document without any method calls encapsulated
part ii53
Part II
  • Distributed Objects Programming
    • Web Services
      • RESTful Web Services
        • They are an alternative model for exposing and programming Web Services w.r.t. SOAP
        • REST…
          • …focuses on resources
          • …leverage HTTP operations to manage resources
          • …is a lightweight, general, and simple approach for building WS.
        • Compared to SOAP
          • … is easier but less powerful (no transaction, security)
          • … uses “real standards” rather than specifications.
part ii54
Part II
  • Distributed Objects Programming
    • Web Services
      • Interoperability
        • Parameters and Return values type are the major obstacle
        • Each type exposed through a Web Service needs to be fully descriptive in order to be recreated on the client
        • Built-in types (int, string, bool, etc..) are automatically mapped to the built-in types of the client language
        • Custom types needs to be properly designed in order to be fully exportable:
          • They need to be XML serializable
          • Their properties need to have getter and setter
part ii55
Part II
  • Distributed Objects Programming
    • Comparison
      • RMI / .NET
        • OO RPC model for Java/.NET
        • Easy and transparent to use
      • CORBA
        • Industry standard
        • Very heavy, not used any more
        • Cross platform & language independent
      • Web Services
        • OO RPC model over the Web
        • Platform and language independent
        • Simple and have good support byframeworks
part iii1
Part III
  • Security
    • The concept of security in DS
    • Secure System Design
      • Cryptography
      • Access Control
      • Intrusion Detection Systems
    • Case Studies
      • Kerberos
      • SSL / TLS protocol
part iii2
Part III
  • Security
    • Fundamental Concepts
      • DS share resources and services over the network
        • Exposed interfaces
        • Unsecure networks
      • Resources need to be protected from
        • Misuse
        • Unauthorized access
        • Corruption
      • Security in a DS is achieved by
        • Security policies: tell me what to do
        • Security mechanisms: execute policies
part iii3
Part III
  • Security
    • Fundamental Concepts
      • Reference Scenario

Enemy

Request +

Credentials

Sensitive Object

User

Principal + Access Rights

Internet

<Untrusted Zone>

Security Service

Server

Communication Channel

part iii4
Part III
  • Security
    • Fundamental Concepts
      • Principal
        • Defines the security context of a request
        • Represent the information defining the user
        • Each request in a DS is executed under a specific principal
        • Provides rights and permissions attached to a request
      • Enemy
        • Malicious user/program
        • Sends message through the network to any process
        • Reads or copies any message between a pair of processes
        • Impersonates one end point of the communication
      • Communication channel
        • Medium / protocol through which messages are exchanged
part iii5
Part III
  • Security
    • Fundamental Concepts
      • Threat
        • Operation or behavior harmful to a resource
      • Types of Threat
        • Eavesdropping (leakage) : obtaining unauthorized information
        • Masquerading (impersonation): assuming other’s identity
        • Message tampering: message content alteration
        • Replaying: re-sending previously sniffed messages
        • Denial of Service: preventing resource availability by flooding
part iii6
Part III
  • Security
    • Fundamental Concepts
      • Goal
        • Securing the channel from the enemy
      • Method
        • Use of a secret to protect the information in the channel
        • The secret is shared among the system and the authorized users
      • Challenges
        • How to establish a secret?
        • How to verify whether the information is corrupted or misused?
part iii7
Part III
  • Security
    • Secure System Design
      • Reference scenario: electronic transactions
      • Requirements
        • Authenticate the vendor to the buyer
        • Keep buyer’s credit card details secure
        • Authenticate the identity of the account holder before access to the account is given
        • Ensure that the item bought is delivered to the buyer
part iii8
Part III
  • Security
    • Secure System Design
      • How to achieve that?
        • Tools
          • Algorithms: cryptography
          • System design: still a difficult task
        • Aims
          • Exclude all possible attacks and loopholes
          • Assume the worst case as normal
          • Minimize accidents and avoid disasters
        • But… Security is about balancing
          • Costs
          • Measures
part iii9
Part III
  • Security
    • Cryptography
      • Uses:
        • Secrecy and Integrity: prevents eavesdropping and tampering
        • Authentication: prevents impersonation
        • Digital Signatures: for proof of authenticity
      • Tools:
        • Symmetric / asymmetric encryption
        • Message digest
        • Certificates

Cryptography is the art of encoding information in a format that only intended recipient can access.

part iii10
Part III
  • Security
    • Cryptography
      • Symmetric/ Asymmetric cryptography
        • Encryption: plain text  cipher text
        • Decryption: cipher text  plain text
        • Encryption/Decryption are connected by a secret (key(s))
        • The secrecy of the key(s) is fundamental
      • Shared secret keys
        • Only one key used for both operations
        • The key is shared among the two endpoints
      • Public/Private key pair
        • Two different keys for the two operations
        • Each side has only one key
part iii11
Part III
  • Security
    • Cryptography
      • Message digest
        • Based on digital hashes
        • Used to prevent tampering
        • Collision (two different message, same hash)
        • Birthday attack
      • Digital certificates
        • Electronic document binding a public key to an identity
        • Verifies the identity and the source of a communication
        • Legally valid (potentially)
        • Chain of trust: (we can trust people we don’t know, CAs)
        • Dynamic creation of secure channels
part iii12
Part III
  • Security
    • Access Control
      • What is it?
        • system that enables an authority to control the access to areas or resources in a given physical facility or in a computer system
      • How it is achieved?
        • Access control lists (ACLs) are quite common.
        • ACLs are attached to resources to control access to them.
        • ACL is a list of Access Control Entities (ACEs)
        • ACE defines permissions, operations, and authorized users
        • Examples: Unix UGO permission set, Active Directory ACL
part iii13
Part III
  • Security
    • Intrusion Detection Systems
      • Intrusion detection can be:
        • Manual: made by humans
        • Automatic: made by computer systems
      • Main goal:
        • Identify deviations from the “normal behavior” of a system
        • Use of patterns to detect deviations
        • Not exact (false negatives, false positive)
        • Use of alarms to trigger corrective actions

Intrusion detection is the act of detecting attempts to compromise the confidentiality, integrity, and availability of a resource.

Intrusion Detection Systems (IDS)

part iii14
Part III
  • Security
    • Intrusion Detection Systems
      • Modeling approach (Helman)
        • Build a model of the computer system and identify its states
        • Rate all the actions from 0 to 1
        • Define a threshold for “suspicious actions”
        • Too many states (inapplicable)
      • Alternatives
        • Heuristics (decision tree, rule based systems)
        • Clustering algorithms
        • Statistics
part iii15
Part III
  • Security
    • Intrusion Detection Systems
      • Implementation
        • An IDS is a combination of hardware and software components actively monitoring a computer system
        • It uses one (or more) of the previous approaches to identify an intrusion
        • It raises an alarm when a possible intrusion is detected
      • Example: SNORT
        • Packet sniffing, logging, and IDS
        • A set of rules drives the behavior of the software
        • Widely used
        • Rule update
part iii16
Part III
  • Security
    • Kerberos
      • Network authentication protocol that…
        • … provides a secure way to authenticate two parties against each other
        • … protects against eavesdropping and replay attacks
        • ... uses symmetric encryption (Needham – Schoereder)
        • … relies on a third trusted party (KDC)
      • Properties
        • it can be deployed on medium large infrastructures
        • integrated in most widely used OSs
        • considered a weapon (for a while…) by US
part iii17
Part III
  • Security
    • Kerberos
      • Architecture

KA(ticketAB)

KA

Alice

Sara

ticketAB

  • Alice or Bob
  • Have their own keys(KA, KB)
  • Communicate with KDC to get a ticket
  • If Alice and Bob want to communicate
  • the KDC will create a ticker and send to
  • both of them, encrypted with their keys.

Bob

  • Key Distribution Center
  • Stores all the secret keys of the users/hosts
  • Generates tickets (session keys) for the
  • communication among two entities

KB

KB(ticketAB)

part iii18
Part III
  • Security
    • SSL / TLS
      • A series of cryptographic algorithms that…
        • … provide secure communication over a network (Internet)
        • … encrypt the communication at application layer
      • Features
        • Security without prior negotiation or 3rd party help
        • Configurable security: authentication protocols and encryption algorithms
        • Communication can be authenticate/encrypted/both on both the two directions
part iii19
Part III
  • Security
    • SSL / TLS
      • Communication Bootstrapping
        • Use of an hybrid scheme: key pair + session key
        • Two layers (both server & client):
          • TLS Record Protocol Layer:
            • implements a secure channel
            • message authentication and encryption
            • implemented at session layer
          • Handshake Layer:
            • handshake protocol and two others
            • establish and maintain the TLS session
part iii20
Part III
  • Security
    • SSL / TLS
      • Protocol Stack

change the secure channel to a new specification

negotiates cipher suite, exchanges certificates and key masters

HTTP

TELNET

SSL Handshake Protocol

SSL Change Cipher Spec

SSL Alert Protocol

…..

implement the secure channel

SSL Record Protocol

Transport Layer (TCP usually)

Network Layer (IP usually)

part iii21

abcdefghi

Application data

Fragment/combine

Record protocol units

abc

def

ghi

Compressed units

Compress

MAC

Hash

Encrypt

Encrypted

Transmit

TCP packet

Part III
  • Security
    • SSL / TLS
      • Transformation pipeline
part iii22
Part III
  • Distributed File Systems
    • Generic Concepts
      • File System
      • Distributed File system
    • Case Studies
      • NFS
      • Andrew File System
      • Google File System
      • Amazon Dynamo
part iii23
Part III
  • Distributed File System
    • DFSs …
      • .. constitute the basis of many distributed applications
      • .. allow multiple process to share data in a secure and reliable way
      • .. constitute the storage facility of a distributed system
    • They might expose several characteristics:
      • high availability
      • fault tolerance
      • location transparency
      • replication
part iii24
Part III
  • Distributed File System
    • Architecture

Lookup

AddName

UnName

GetNames

Directory Service

Flat File Service

Application Program

Application Program

Client Module

Read, Write, Create, Delete, GetAttributes, SetAttributes

Interface

Client Computer

Server Node

part iii25
Part III
  • Distributed File System
    • Components
      • Flat File Service
        • Content file management (operations)
        • Use of Unique File Identifiers (UFIDs) to uniquely refer to files.
      • Directory Service
        • Mapping between logical file names and UFIDs
        • Directory manipulation.
        • Add/Remove file from directory.
      • Client Module
        • Integrated access to both services (File & Directory Service)
        • Maintain information about the network location of file services and the files in use.
        • Exposes the standard operations available for local files.
part iii26
Part III
  • Distributed File System
    • Example Interface

Composed paths (/usr/bin/tar) are resolved by recursive calls to Lookup.

Flat File Service

Read(FileId, i, n)  data

Write(FileId, i, data)

Create()  FileId

Delete(FileId)

GetAttributes(FileId) Attr

SetAttrbutes(FileId, Attr)

Directory Service

Lookup(Dir, Name)  FileId

AddName(Dir, Name, FileId)

UnName(Dir, Name)

GetNames(Dir, Pattern)  Names

Unique across the entire DFS

Server Node

part iii27
Part III
  • Distributed File System
    • Network File System
      • Info
        • Developed by Sun Microsystems.
        • Open Standard (RFC, IETF).
        • Closely follow the abstract file service model.
        • Most popular, widely used (industry standard since 1985).
      • Support for:
        • transparency, heterogeneity, efficiency, fault tolerance
      • Limited achievement of:
        • concurrency, replication, consistency, and security
part iii28
Part III
  • Distributed File System
    • Network File System
      • Architecture

Also User Space

Application

Program

Application

Program

Application

Program

Application

Program

Kernel

Kernel

Virtual File System

Virtual File System

Other File

System

NFS

Client

UNIX

File System

UNIX

File System

NFS

Server

NFS

Client

UNIX

System Calls

Client Node

Server Node

part iii29
Part III
  • Distributed File System
    • Network File System
      • Architecture

nfsd

mountd

mount (cmdline, or fstab)

nfs: port 10003

….: port 30410

…..

…..

rpcbind

/dir/to/export *.mydomain.com(ro,root_squash)

/dir/to/share host2.mydomain.com(ro)

/dir/read_write *.mydomain.com(rw)

…..

….

nfs-server:/dir/to/export /mnt/exp timeo=14,intr

nfs-server:/dir/to/share /mnt/share rsize=8192

nfs-server:/dir/read_write /mnt/rwwsize=8192

….

/etc/exports

/etc/fstab

Client Node: host2

Server Node: nfs-server

part iii30
Part III
  • Distributed File Systems
    • Network File Systems
      • Observation
        • NFS is a good example of simple, robust, efficient, DFS
      • Features
        • Access: good support and integration with the UNIX kernel.
        • Concurrency: limited but enough for several scenarios.
        • Location: not guaranteed, naming is controlled by the client.
        • Replication: limited to read-only file systems.
        • Failure: limited but effective (thanks to stateless server).
        • Mobility: hardly achieved (no file relocation, yes for trees..).
        • Performance: good especially in case of multicore systems.
        • Scaling: good large file system can be easily distributed.
part iii31
Part III
  • Distributed File Systems
    • Andrew File System
      • Key features
        • Single namespace
        • Security (trusted server) & Caching
        • Designed to support thousands of clients
        • Volumes
      • Assumptions
        • Files are small (i.e. entire file can be cached)
        • Frequency of reads much more than those of writes
        • Sequential access common
        • Files are not shared (i.e. read and written by only one user)
        • Shared files are usually not written
        • Disk space is plentiful
part iii32
Part III
  • Distributed File Systems
    • Andrew File System
      • Architecture

<..>

<>

<..>

volume

local

volume

local

share

local

usr

home

bin

tmp

usr

home

bin

tmp

AFS

(VICE server)

….

AFS Workstation (client)

part iii33
Part III
  • Distributed File Systems
    • Andrew File Systems
      • Architecture
        • On the server(s):
          • VICE daemon exports a volume (directories, files, …)
          • RPC process.
        • On the client (s):
          • Venus daemon similar to NFS client
          • A rigid division into:
            • local (temporary files)
            • shared (single namespace, shared file system)
        • Infrastructure:
          • RPC on top of UDP
part iii34
Part III
  • Distributed File Systems
    • Andrew File System
      • Basic Characteristics
        • Volumes
          • consist of files, directories, mount points of volumes
          • unit of export by a VICE server
          • they can be moved transparently and have a quota
        • Caching Strategy
          • AFS is stateful (register callbacks for updating clients)
          • files are cached on client and updates are sent on close.
        • Security
          • identification: kerberos
          • permissions: user/groups and ACLs
part iii35
Part III
  • Distributed File Systems
    • Andrew File System
      • AFS is a reference model for several large scale DFS
      • Compared to NFS it is based on a stateful protocol:
        • Advanced caching strategies
        • Inconsistencies for server crashes
      • Mostly designed for:
        • Dedicated and high performance servers (VICE servers)
        • Thousands of users that mostly “read” rather than “write”
      • Failures are a weak point for the system
part iii36
Part III
  • Distributed File Systems
    • Google File System
      • Design Goals
        • Support for large scale data intensive applications.
        • Handle hundred of terabytes of data.
        • Manage over thousands of disks.
        • Spawn across thousands of machines.
        • Serve hundreds of clients.
      • Assumptions
        • Component failures are a norm rather than the exception.
        • Files are huge by traditional standards (Multi-GB).
        • Appends are more common than random writes.
        • Applications specifically target the GFS (API co-design).
part iii37
Part III
  • Distributed File Systems
    • Google File System
      • Architecture

Application

/foo/bar chunk ef80

….

….

File name, chunk index

….

GFS Client

Chunk handle, chunk location

GFS Master

Instructions to chunk servers

Chunk state

chunk index,

byte range

Linux File System

Linux File System

GFS Chunkserver

GFS Chunkserver

chunk data

part iii38
Part III
  • Distributed File Systems
    • Google File System
      • Disaster Recovery
        • Each process is designed to quickly recover after crash.
        • By routine the processes are killed to keep the system clean.
        • The master is in failover and it can be started on any node.
        • Chunks are replicated multiple times on different nodes.
        • Heartbet monitoring and logging keep system integral.
      • Consistency Model
        • Relaxed consistency model (simple and efficient).
        • File namespace mutations are centralized.
        • Checksums, handshakes, and restoration from healthy replicas keep prevent from long term data corruption.
part iii39
Part III
  • Distributed File Systems
    • Google File System
      • Summary
        • Target
          • Support large scale distributed applications
        • Assumptions
          • Failure is a norm
          • Large files are common
          • Appends vs random writes
        • Characteristic
          • Simple structure
          • Chunk-based model
          • Extremely fail tolerant
part iii40
Part III
  • Distributed File Systems
    • Amazon Dynamo
      • Characterization
        • highly-available, distributed, key-value store serving as a storage facility for maintaining the state of many services exposed by Amazon.
      • Not a DS but faces similar problems:
        • Performance
        • High-availability
        • Scalability
        • Consistence
part iii41
Part III
  • Distributed File Systems
    • Amazon Dynamo
      • Design Goals
        • Support application state maintenance at a massive scale
        • Support different storage needs for applications
        • Provide continuous availability
        • Minimize downtimes and latencies
      • Scenario
        • Ten millions of customers served worldwide in peak times
        • Thousands of servers (mostly commodity hardware)
        • Shopping Cart: ten millions requests / day
        • Session State: hundreds of thousands of concurrent sessions
part iii42
Part III
  • Distributed File Systems
    • Amazon Dynamo
      • Architecture

Key Ring

Storage Peer

Storage Peer

Storage Peer

Storage Peer

Storage Peer

Storage Peer

Request

Coordinator

Pluggable Storage Engine (BDB, MySQL)

Failure and Memberhip

Detection

.

part iii43
Part III
  • Distributed File Systems
    • Amazon Dynamo
      • Good example on how theory and algorithms find a practical implementation
      • It composes together several technologies
        • Data partitioning and replication: consistent hashing
        • Data consistency: object versioning, and quorum-like updates
        • Failure detection: gossip protocol and explicit membership
        • Maintenance: completely distributed infrastructure with minimal needs of manual administration
part iii44
Part III
  • Naming Services
    • Why using naming services?

Uhm,,, what was the address? … 66.102.11.???

#@!!%@!

66.102.11.104

Humans remember more easily names than meaningless sequences of numbers!

part iii45
Part III
  • Naming Services
    • Goals
      • Introduce a mapping between…
        • … a “computer efficient” resource addressing
        • … a “human readable” resource representation
      • Separate…
        • … digital representation of the location of a resource
        • … its logical name
      • Simplify resources/services lookup.
part iii46
Part III
  • Naming Services
    • Observations
      • Consistent and uniform naming is important
        • Simplifies organization of resources
        • Simplifies remembering locations by imposing
        • Is based on the logical (not physical) structure
      • Name resolution
        • Allows retrieving the physical address of a resource
        • Maps logical to physical structure
        • Explicitly/Implicitly performed when using resources
        • Name resolution is performed by the Naming Service
part iii47
Part III
  • Naming Services
    • Name Resolution

66.102.11.104

100.109.23.104

Naming Service

part iii48
Part III
  • Naming Services
    • Namespaces
      • Characterization
        • Context in which names for resources are defined
        • Provide a logical structure to names
      • Requirements
        • Allows for simple but useful names
        • Maintain potentially infinite numbers of names
        • Support structure
          • Manage similar sub-names without clashes
          • Group related names
        • Support restructuring
        • Management of trust
part iii49
Part III
  • Naming Services
    • Internet Domain Name System (DNS)
      • Distributed database for resolving names to IP addresses for the entire Internet
      • Uses a hierarchical structure that reflects the structural organization of the Internet
        • Root DNS
        • Authoritative DNS for .com, .au, .jp, …
        • Authoritative DNS for domain
        • Authoritative DNS for sub-domains.
      • Scales to million of computers and it is fault tolerant:
        • 100 ms typical query time
        • Heavy use of caching and replication
        • Partitioned database
part iii50
Part III
  • Naming Services
    • DNS

a.root-servers.net (root)

abc.unimelb.edu.au (unimelb.edu.au)

dns0-doc.usyd.edu.au

(usyd.edu.au)

ns.purdue.edu (purdueedu)

ns1.nic.au (au)

ns0.ja.net.au (edu.au)

*.au

*.purdue.edu

yahoo.com

……

mulga.csse.unimelb.edu.au (csse.unimelb.edu.au)

dis.unimelb.edu.au

csse.unimelb.edu.au

……

usyd.edu.au

unimelb.edu.au

……

*.purdue.edu

*.com.au

*.edu.au

……

*.usyd.edu.au

*.csse.unimelb.edu.au

(purdue.edu) DNS

U. Sydney DNS

UniMelb DNS

CSSE DNS

(edu.au) DNS

(au) DNS

Root DNS

authoritative path to lookup:

mundula.csse.unimelb.edu.au

part iii51
Part III
  • Naming Services
    • Internet Domain Name System
      • Practical Issues
        • Name changes
          • Naming changes infrequently but when it happens caching might slow down the update process.
          • It is responsibility of clients to detect this condition and refresh their cached information.
        • Structure mutation:
          • Merging to different namespaces is difficult.
          • Difficult to move subtrees in other part of the structure
part iii52
Part III
  • Directory Services
    • Directory services….
      • .. use categories and attributes
      • .. allows searching by
        • name
        • attributes
        • groups
      • .. are useful when the user…
        • … does not know the name
        • … looks for any service that

has specific attributes

SHOP DIRECTORY

Restaurants – G3

Bars – L2

Libraries – A1:A3

Clothes – A4:B7

Sports – C1:D2

part iii53
Part III
  • Directory Services
    • Features
      • Are a “yellow page” service for computer resources:
        • devices (printers, disks, storage, scanners, etc…)
        • services (any kind)
        • machines and users
      • They store a mapping between
        • Resource names
        • Resource attributes
      • They optimize the searches by attribute.
part iii54
Part III
  • Directory Services
    • Operations
      • Given a resource name, retrieves a collection of attributes (metadata) providing additional information.
      • Given a collection of attributes, retrieves a set of names that have (any or all) of the specified attributes.
    • Examples
      • X.500
      • LDAP
      • Microsoft Active Directory Services
      • DNS (it holds some descriptive data but…)
part iii55
Part III
  • Discovery Services
    • A Discovery Service is a Directory Service that integrates the following additional features:
      • It automatically updates as the network configuration changes
      • Meets the need of clients in spontaneous networks (see Section 2.2.3 of CDK)
      • Finds the most suitable services in the current scope that satisfy a search criteria of a (maybe mobile) client
    • Examples
      • JINI
      • Service Location Protocol
      • Simple Discovery Protocol (part of UPnP)
      • Secure Discovery Service
conclusions1
Conclusions
  • Summary
    • Part I
      • Characteristics of a DS
        • Definitions & Properties
      • Fundamentals of Programming
        • Concurrency & Networking
    • Part II
      • Key features of the infrastructure
        • Architecture: fundamental models & OS support
        • Programming: distributed objects
    • Part III
      • Basic Services for a DS
        • Security & Storage
        • Naming & Discovery