Introduction - unisannio.it

Download Report

Transcript Introduction - unisannio.it

DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S. TANENBAUM MAARTEN VAN STEEN

Chapter 4 Communication

Layered Protocols (1)

Figure 4-1. Layers, interfaces, and protocols in the OSI model.

Layered Protocols (2)

Figure 4-2. A typical message as it appears on the network.

Middleware Protocols

Figure 4-3. An adapted reference model for networked communication.

Types of Communication

Persistent communications

Figure 4-4. Viewing middleware as an intermediate (distributed) service in application-level communication.

Types of Communication

• • • • – Persistent Un messaggio inviato, è conservato nel middleware di comunicazione fino a che la spedizione ha successo – Transient Un messaggio viene conservato solo per il tempo necessario alla spedizione o alla ricezione – Synchronous Chi spedisce viene bloccato fino al termine dell’invio – Asynchronous Chi spedisce continua immediatamente il proprio flusso di esecuzione • • Discrete Streaming Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Conventional Procedure Call

(a) Parameter passing in a local procedure call: the stack before the call to read.

(b) The stack while the called procedure is active.

Sometime used: call-by-copy/restore (dipende dal

linguaggio usato)

Client and Server Stubs

Figure 4-6. Principle of RPC between a client and server program.

Remote Procedure Calls (1)

A remote procedure call occurs in the following steps: 1.

The client procedure calls the client stub in the normal way.

The client stub builds a message and calls the local operating system.

The client’s OS sends the message to the remote OS.

The remote OS gives the message to the server stub.

The server stub unpacks the parameters and calls the server.

Remote Procedure Calls (2)

A remote procedure call occurs in the following steps (continued): 6.

The server does the work and returns the result to the stub.

10.

The server stub packs it in a message and calls its local OS.

The server’s OS sends the message to the client’s OS.

The client’s OS gives the message to the client stub.

The stub unpacks the result and returns to the client.

Passing Value Parameters (1)

Figure 4-7. The steps involved in a doing a remote computation through RPC.

Passing Value Parameters (2)

Figure 4-8. (a) The original message on the Pentium (little endian).

Passing Value Parameters (3)

Figure 4-8. (b) The message after received on the SPARC (big endian).

Passing Value Parameters (4)

Figure 4-8. (c) The message after being inverted. The little numbers in boxes indicate the address of each byte.

Passing reference parameters

Es. i puntatori?

• Possono essere proibiti i passaggi per riferimento; • Si possono usare strategie di copia Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Parameter Specification and Stub Generation

Figure 4-9. (a) A procedure. (b) The corresponding message.

Asynchronous RPC (1)

Figure 4-10. (a) The interaction between client and server in a traditional RPC.

Asynchronous RPC (2)

Figure 4-10. (b) The interaction using asynchronous RPC. Se non c’è l’accept request si ha una

one-way RPC

Asynchronous RPC (3)

Figure 4-11. A client and server interacting through two asynchronous RPCs (

deferred synchronous

DCE

• Distributed Computing Environment • Meno diffuso di Sun RPC • E’ un middleware che si basa sul modello client/server; • – – – – – Mette a disposizione numerosi servizi: file service distribuito; directory; security; distributed time service; … Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Writing a Client and a Server (1)

Genera uno scheletro di idl con un identificatore unico

Figure 4-12. The steps in writing a client and a server in DCE RPC.

Writing a Client and a Server (2) Three files output by the IDL compiler:

• • •

A header file (e.g., interface.h, in C terms).

The client stub.

The server stub.

Binding a Client to a Server (1)

• Registration of a server makes it possible for a client to locate the server and bind to it. • 1.

Server location is done in two steps: Locate the server’s machine.

Locate the server on that machine.

Binding a Client to a Server (2)

Figure 4-13. Client-to-server binding in DCE.

DCE: semantica

• • Operazioni

At-most-once

: ogni operazione viene fatta un’unica volta anche in caso di crash – – RPC ritorna normalmente:

exactly once

RPC ritorna anormalmente (timeout):

once

nonce

At-least-once (Indepondent ops)

: un’operazione può essere ripetuta senza darne notizia (es. lettura da disco, finchè la lettura ha successo) •

Broadcast

DCE: errori

Una RPC può fallire per varie ragioni: • – – – superamento n. max timeout/retry, a causa di: server failure sovraccarichi perdita di request o reply • errore del codice rpc lato server (p.es. file name non valido) Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

DCOM: Distributed Component Object Model

Progettato da Microsoft e basato sul Component Object Model (COM) Affronta problemi come: – – Interoperabilità tra applicazioni, piattaforme e linguaggi diversi; Versioning: • Compatibilità tra nuove versioni di un server e vecchie versioni dei client; • • Le nuove interfaccie dovrebbero preservare le vecchie; Naming: usa identificatori unici globali.

DCOM: p rospettiva storica

DDE  OLE1  COM  OLE  DCOM Dynamic Data Exchange (DDE) – Scambio di dati tra applicazioni e clipboard – Implementato in Windows 2.1

Object Linking and Embedding (OLE v1.0) – Meccanismo per includere documenti in altri documenti prodotti con altre applicazioni (es., uno spreadsheet Excel in un document Word); – Un oggetto

embedded

è collegato alla propria applicazione originale; – Riguarda solo oggetti di tipo “documento”.

DCOM: p rospettiva storica

Component Object Model (COM) – – – Interoperabilità dei componenti Possibilità di condividere componenti non documentali.

Tecnologia basata sugli oggetto: • Identità, polymorfismo, ereditarietà.

OLE – – Costruito su COM (e DCOM) Collega il livello dell’applicazione all’architettura COM sottostante.

DCOM

• • • Gestione distributed della memoria condivisa tramite opportune interfacce; Interoperabilità e trasparenza; Caricamento dinamico: – reference counting; Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

DCOM: a rchitettura

• • • • DCOM: Inizializza una connsessione tra i componenti; Negozia i protocolli per la comunicazione; Supporta la persistenza degli oggetti; Assegna ai componenti nomi mnemonici: i

monikers.

DCOM: a rchitettura

Client "CoCreateI nstance" OLE32 (Remote) Activation Proxy Object Security Provider DCE RPC Protocol Stack SCM Service Control Manager Stub Component Security Provider DCE RPC Protocol Stack "CoCreateInstance" DCOM network protocol SCM From: Horstmann and Kirtland, DCOM architecture Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

DCOM: c reating objects

Classes of objects have globally unique identifiers (GUIDs) – – 128 bit numbers Also called class ids (CLSID) DCOM provides functions to create objects given a server name and a class id – The SCM on the client connects to the SCM of the server and requests creation of the object Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Client connecting to an auction server

IAuction* pAuction = NULL;

HRESULT hr=CoCreateInstance( CLSID_AuctionService,

// Request an instance of class

NULL, CLSCTX_SERVER, IID_IAuction, (void**) &pAuction);

// CLSID_AuctionService // No aggregation // Any server is fine // Ask for an interface of type IID_IAuction // Pointer to returned interface pointer } { if (SUCCEEDED(hr)) pAuction->PlaceBid(1324, 100000.00); pAuction->Release(); // Bid US$ 100,000.00 on item # 1324 // Release this AuctionService instance Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Monikers

Object names (as opposed to class names) are called monikers A moniker distinguishes one instance from another of the same class Monikers themselves are objects A moniker carries enough information to locate the object it represents – They can also recreate the object, if it is not currently running They have a human readable form similar to a URL. Example: Moniker for a file object “file:c:\my documents\July Report.doc” Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

When a client passes a moniker to access an object, COM looks up a Running Object Table (ROT) for the moniker name – If it exists, a pointer to the object is returned – Else, a new object instance is created, its state is restored, its reference is entered in ROT, and a pointer to the object is returned to the client • Monikers contain reference to the object’s persisted state Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Remote Procedure Call

RPC mechanism in DCOM is based on DCE (Distributed Computing Environment)-RPC Parameter values on the client’s stack are marshalled and send as a data stream to the server, and the results are similarly send back to the client.

The code for marshaling and unmarshaling are generated while compiling the interface specification – written in Microsoft Interface Description Language (MIDL) Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

MIDL

An extension of DCE’s IDL The MIDL compiler generates the client and server stub files Every DCOM interface inherits from an interface known as IUnknown – – Interface names start with I IUnknown has three methods • AddRef(), Release() and QueryInterface() • AddRef() and Release() are used to manage reference counts (for memory management) Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

MIDL (continued)

• • • QueryInterface() can be used to find out whether the named interface is implemented by the server Each interface has a unique interface id (IID) MIDL supports single inheritance Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

MIDL example

} { // Bank account interface [object, uuid(…)] interface IBankAcc void getCurrentBalance([in] double amount); void withdraw([in] double amount); ..

Threading models supported

Single-threaded apartment, main thread only.

 All instances are created on the same thread.

Single-threaded apartment.

 Instance is tied to a single thread; different instances can be created on different threads.

Multithreaded apartment.

 Instances can be created on multiple threads; instances can be called on arbitrary threads.

Berkeley Sockets

Figure 4-14. The socket primitives for TCP/IP.

Sockets

Figure 4-15. Connection-oriented communication pattern using sockets.

The Message-Passing Interface (2)

Figure 4-16. Some of the most intuitive message-passing primitives of MPI.

Message oriented persistent communication

• Message queuing systems • Offrono capacità di memorizzazione intermedia senza ausilio dell’utente • Usati per messaggi che richiedono un tempo di spedizione alto Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Message-Queuing Model (1)

Figure 4-17. Four combinations for loosely-coupled communications using queues.

Message-Queuing Model (2)

Figure 4-18. Basic interface to a queue in a message-queuing system.

General Architecture of a Message Queuing System (1)

Figure 4-19. The relationship between queue-level addressing and network-level addressing.

General Architecture of a Message Queuing System (2)

Figure 4-20. The general organization of a message-queuing system with routers.

Message Brokers

Figure 4-21. The general organization of a message broker in a message-queuing system.

IBM’s WebSphere Message-Queuing System

Figure 4 22. General organization of IBM’s message-queuing system.

Channels

Figure 4-23. Some attributes associated with message channel agents.

Message Transfer (1)

Figure 4-24. The general organization of an MQ queuing network using routing tables and aliases.

Message Transfer (2)

Figure 4-25. Primitives available in the message-queuing interface.

Data Stream

• – trasmissioni asincrone gli item vengono trasmessi in ordine, non ci sono requisiti di temporizzazione stringenti; • – trasmissioni sincrone Ci sono requisiti sui ritardi massimi ammissibili ma non su quelli minimi (es. sensori) • – trasmissioni isocrone Ci sono requisiti sui delay di trasmissione massimi e minimi (

bounded jitter

Data Stream

Stream complessi

Figure 4-26. A general architecture for streaming stored multimedia data over a network.

Streams and Quality of Service

• • • • • Properties for Quality of Service: The required bit rate at which data should be transported.

The maximum delay until a session has been set up The maximum end-to-end delay .

The maximum delay variance, or jitter.

The maximum round-trip delay.

Enforcing QoS (1)

Figure 4-27. Using a

buffer

to reduce jitter.

Enforcing QoS

Non è possibile richiedere ritrasmissioni dei pacchetti persi:

forward error correction

• inviati k e ricevuti n pacchetti (k>n) si possono ricostruire i k originali.

Enforcing QoS (2)

Figure 4-28. The effect of packet loss in (a) non interleaved transmission and (b) interleaved transmission.

Synchronization Mechanisms (1)

Un processo effettua letture sugli stream assicurandone la sincronia: • L’applicazione è responsabile della sincronia Figure 4-29. The principle of explicit synchronization on the level data units.

Synchronization Mechanisms (2)

L’applicazione colloquia direttamente con il middleware che controlla gli stream Figure 4-30. The principle of synchronization as supported by high-level interfaces.

Synchronization Mechanisms

MPEG-2 Un numero non limitato di stream continui o discreti può essere incluso in uno stream MPEG: • • Ogni stream è diviso in pacchetti e rapportato ad un timestamp che si basa su un clock di sistema fisso; I vari stream sono multiplexati in un unico stream di pacchetti.

Multicast

• • Application-level multicast i nodi si organizzano in una rete

overlay

i router non vengono coinvolti: si possono avere situazioni non ottimali 1.

I nodi possono organizzarsi in una struttura ad albero identificandosi con il proprio percorso 2.

I nodi possono organizzarsi in una

mesh

collaborando con più vicini.

Overlay Construction

Figure 4-31. The relation between links in an overlay and actual network-level routes.

Information Dissemination Models (1)

• • – – Anti-entropy propagation model Node P picks another node Q at random Subsequently exchanges updates with Q – – – Approaches to exchanging updates P only pushes its own updates to Q P only pulls in new updates from Q P and Q send updates to each other Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Information Dissemination Models (2)

Figure 4-32. The relation between the fraction s of update ignorant nodes and the parameter k in pure gossiping. The graph displays ln(s) as a function of k.

Riferimenti

• M. Horstmann and M. Kirtland, DCOM Architecture: http://www.microsoft.com/com From: A Sajeev. Distributed Component Object Model Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Introduction - unisannio.it

Transcript Introduction - unisannio.it

Chapter 4 Communication

Layered Protocols (1)

Layered Protocols (2)

Middleware Protocols

Types of Communication

Types of Communication

Conventional Procedure Call

Client and Server Stubs

Remote Procedure Calls (1)

Remote Procedure Calls (2)

Passing Value Parameters (1)

Passing Value Parameters (2)

Passing Value Parameters (3)

Passing Value Parameters (4)

Passing reference parameters

Parameter Specification and Stub Generation

Asynchronous RPC (1)

Asynchronous RPC (2)

Asynchronous RPC (3)

DCE

Writing a Client and a Server (1)

Writing a Client and a Server (2) Three files output by the IDL compiler:

A header file (e.g., interface.h, in C terms).

The client stub.

The server stub.

Binding a Client to a Server (1)

Binding a Client to a Server (2)

DCE: semantica

DCE: errori

DCOM: Distributed Component Object Model

DCOM: p rospettiva storica

DCOM: p rospettiva storica

DCOM

DCOM: a rchitettura

DCOM: a rchitettura

DCOM: c reating objects

Client connecting to an auction server

Monikers

Remote Procedure Call

MIDL

MIDL (continued)

MIDL example

Threading models supported

Berkeley Sockets

Sockets

The Message-Passing Interface (2)

Message oriented persistent communication

Message-Queuing Model (1)

Message-Queuing Model (2)

General Architecture of a Message Queuing System (1)

General Architecture of a Message Queuing System (2)

Message Brokers

IBM’s WebSphere Message-Queuing System

Channels

Message Transfer (1)

Message Transfer (2)

Data Stream

Data Stream

Streams and Quality of Service

Enforcing QoS (1)

Enforcing QoS

Enforcing QoS (2)

Synchronization Mechanisms (1)

Synchronization Mechanisms (2)

Synchronization Mechanisms

Multicast

Overlay Construction

Information Dissemination Models (1)

Information Dissemination Models (2)

Riferimenti

Directory