Sie sind auf Seite 1von 26

Reti di Calcolatori, A.A. 2005/06 M. Cesati / E.

Betti

Reti di calcolatori

Lezione 2
Lez. 2 — 1 M. Cesati / E. Betti

Aspetti software delle reti di calcolatori

• Per il funzionamento delle moderne reti di calcolatori, il software ha una enorme


importanza

• Il software di rete è estremamente complesso e articolato

• Per facilitarne la progettazione, la verifica, l’implementazione ed il testing, il


software di rete è altamente strutturato ed organizzato in strati o livelli (layers)

• Di conseguenza, l’architettura di una rete è organizzata come una gerarchia di


protocolli (protocol hierarchy)
Lez. 2 — 2 M. Cesati / E. Betti

Gerarchie di protocolli (1)

• Le reti sono organizzate in livelli (layers), ciascuno dei quali è costruito sopra il
precedente

• Lo scopo di ogni livello è fornire servizi al livello immediatamente superiore,


nascondendo i dettagli su come tali servizi sono implementati

• Ciascun tipo di rete ha

– un diverso numero di livelli

– diversi nomi e funzioni associati a ciascun livello


Lez. 2 — 3 M. Cesati / E. Betti

Gerarchie di protocolli (2)

• Il livello n su un host “dialoga” con il livello n di un altro host (solo logicamente!)

• Regole e convenzioni della comunicazione a livello n sono indicate col termine


protocollo di livello n

• Le entità logiche che portano avanti la conversazione a livello n sono dette peer
entity (entità di pari livello)

• Ciascuna peer entity di livello n porta avanti il dialogo utilizzando i servizi offerti
dal livello n − 1
Lez. 2 — 4 M. Cesati / E. Betti

Gerarchie di protocolli (3)

• Fra ogni coppia di livelli adiacenti è definita una interfaccia

• L’interfaccia definisce

– i servizi offerti dal livello sottostante

– le operazioni primitive che possono essere richieste al livello sottostante

• Analogia con i sistemi operativi: l’interfaccia tra il livello superiore e quello infe-
riore è simile alle API (funzioni di libreria e chiamate di sistema) tra i programmi
applicativi ed il sistema operativo
Lez. 2 — 5 M. Cesati / E. Betti

Gerarchie di protocolli (4)


Lez. 2 — 6 M. Cesati / E. Betti

Architettura di rete (1)

Una collezione di livelli e relativi protocolli è chiamata architettura di rete

Attenzione! I dettagli implementativi di ciascun livello, cosı̀ come la definizione di


ciascuna interfaccia tra livelli, non fanno parte dell’architettura di rete

Due host possono dialogare anche se utilizzano diverse piattaforme hardware e


diversi sistemi operativi, purché adottino la stessa architettura di rete

L’insieme dei protocolli di una determinata architettura usati da un determinato


calcolatore viene detto pila di protocolli (protocol stack)
Lez. 2 — 7 M. Cesati / E. Betti

Architettura di rete (2)

Una architettura di rete può essere:

• proprietaria

• standard de facto

• standard de iure
Lez. 2 — 8 M. Cesati / E. Betti

Architetture proprietarie

• Basate su scelte indipendenti ed arbitrarie di un costruttore

• Generalmente incompatibili con architetture differenti

• Raramente le specifiche sono rese pubbliche

Esempi: IBM SNA (Systems Network Architecture), Digital Decnet Phase IV,
Novell IPX, Appletalk
Lez. 2 — 9 M. Cesati / E. Betti

Architetture standard de facto

• Basate su specifiche di pubblico dominio

• Largamente adottate a livello mondiale

Esempio: Internet Protocol Suite (TCP/IP)


Lez. 2 — 10 M. Cesati / E. Betti

Architetture standard de iure

• Basate su specifiche pubbliche

• Approvate da enti internazionali di standardizzazione

Esempi: standard IEEE 802 (LAN), architettura OSI (Open Systems Interconnec-
tion), Decnet Phase V
Lez. 2 — 11 M. Cesati / E. Betti

Comunicazione multi-livelli (1)


Lez. 2 — 12 M. Cesati / E. Betti

Comunicazione multi-livelli (2)


Lez. 2 — 13 M. Cesati / E. Betti

Tipi di servizi
Vi sono due principali classi di servizi:

• servizi connection-oriented

• servizi connectionless

Inoltre i servizi possono essere:

• servizi affidabili

• servizi non affidabili


Lez. 2 — 14 M. Cesati / E. Betti

Servizi connection-oriented

Modellati sul sistema telefonico. Per comunicare si deve:

1. stabilire una connessione

2. scambiare informazioni per mezzo della connessione

3. rilasciare la connessione
Lez. 2 — 15 M. Cesati / E. Betti

Servizi connectionless

Modellati sul sistema postale. Per comunicare si deve:

1. inviare il messaggio
Lez. 2 — 16 M. Cesati / E. Betti

Servizi affidabili e non affidabili


Un servizio affidabile non perde mai i dati senza che il mittente ne sia informato:

• tutti i dati spediti arrivano al destinatario, oppure viene segnalato un errore

• il ricevente invia un acknowledgment (conferma) al mittente per ogni


pacchetto ricevuto

• in caso di errori transienti di trasmissione, il mittente può rispedire automatica-


mente i dati non giunti a destinazione

Un servizio non affidabile non offre alcuna certezza al mittente che i dati inviati siano
stati effettivamente ricevuti dal destinatario
Lez. 2 — 17 M. Cesati / E. Betti

Esempi di tipologie di servizi

Servizio Affidabile Non affidabile

Connection-oriented trasmissione di file voce digitalizzata

Connectionless richiesta ad un DB server posta spazzatura (“junk mail”)


Lez. 2 — 18 M. Cesati / E. Betti

Primitive di definizione dei servizi (1)

Un servizio di livello n è definito formalmente dalle primitive che una entità di livello
n + 1 può adoperare per accedere al servizio stesso

Quattro principali tipi di primitive:

Primitiva Descrizione
request() si chiede al servizio di fare qualcosa
indication() si viene avvertiti dal servizio di un evento
response() si chiede al servizio di rispondere ad un evento
confirm() il servizio segnala l’arrivo di una conferma
Lez. 2 — 19 M. Cesati / E. Betti

Primitive di definizione dei servizi (2)

Ad esempio, per stabilire una connessione fra le peer entity A e B

Entità Azione Descrizione


A invia connect.request() A vuole connettersi
B riceve connect.indication() qualcuno vuole connettersi
B invia connect.response() B accetta la connessione
A riceve connect.confirm() connessione stabilita
Lez. 2 — 20 M. Cesati / E. Betti

Servizi vs protocolli

servizio: insieme di operazioni primitive che un livello offre al livello superiore. Come
tali operazioni siano implementate non riguarda il livello superiore.

protocollo: insieme di regole che governano il formato ed il significato delle infor-


mazioni che le peer entity si scambiano fra loro. Le entità usano i protocolli per
implementare i propri servizi.
Lez. 2 — 21 M. Cesati / E. Betti

Problematiche nei vari livelli (1)

• identificazione delle peer entity

• modalità di trasferimento dei dati (simplex connection, half-duplex connection,


full-duplex connection)

• controllo degli errori di trasmissione (se rilevarli, se correggerli, se avvertire il


mittente)

• mantenimento dell’ordine di invio dei dati


Lez. 2 — 22 M. Cesati / E. Betti

Problematiche nei vari livelli (2)

• regolazione della velocità di trasmissione dei dati

• gestione della dimensione dei pacchetti

• multiplexing di vari flussi di dati sulla stessa connessione

• routing dei messaggi


Lez. 2 — 23 M. Cesati / E. Betti

Interfacce e Servizi (1)

Dati due livelli n − 1 ed n:

• il livello n − 1 fornisce servizi al livello n (è il service provider)

• il livello n usa i servizi del livello n − 1 (è il service user)

• i servizi offerti dal livello n − 1 sono accessibili tramite i Service Access Points
(SAP) di livello n − 1

• ogni SAP ha un identificatore che lo individua univocamente


Lez. 2 — 24 M. Cesati / E. Betti

Interfacce e Servizi (2)

• l’informazione inviata dal livello n + 1 al livello n è chiamata Interface Data Unit


(IDU) di livello n

• l’IDU è costituita da una Service Data Unit (SDU) e da Interface Control Informa-
tion (ICI)

• il livello n processa la SDU e prepara una o più Protocol Data Unit (PDU)

• ciascuna PDU di livello n diventerà parte di una IDU da inviare al livello n − 1


Lez. 2 — 25 M. Cesati / E. Betti

Interfacce e Servizi (3)

Das könnte Ihnen auch gefallen