Prof. PIER LUCA MONTESSORO Facoltà di Ingegneria Università degli Studi di Udine

(1)

RETI DI CALCOLATORI

Prof. PIER LUCA MONTESSORO Facoltà di Ingegneria Università degli Studi di Udine

© 2001-2007 Pier Luca Montessoro (si veda la nota a pagina 2) 2 Questo insieme di trasparenze (detto nel seguito slide) è protetto dalle leggi sul copyright e dalle disposizioni dei trattati internazionali. Il titolo ed i copyright relativi alle slides (ivi inclusi, ma non limitatamente, ogni immagine, fotografia, animazione, video, audio, musica e testo) sono di proprietà dell’autore prof. Pier Luca Montessoro, Università degli Studi di Udine.

Le slide possono essere riprodotte ed utilizzate liberamente dagli istituti di ricerca, scolastici ed universitari afferenti al Ministero della Pubblica Istruzione e al Ministero dell’Università e Ricerca Scientifica e Tecnologica, per scopi istituzionali, non a fine di lucro. In tal caso non è richiesta alcuna autorizzazione.

Ogni altro utilizzo o riproduzione (ivi incluse, ma non limitatamente, le riproduzioni su supporti magnetici, su reti di calcolatori e stampe) in toto o in parte è vietata, se non esplicitamente autorizzata per iscritto, a priori, da parte dell’autore.

L’informazione contenuta in queste slide è ritenuta essere accurata alla data della pubblicazione. Essa è fornita per scopi meramente didattici e non per essere utilizzata in progetti di impianti, prodotti, reti, ecc. In ogni caso essa è soggetta a cambiamenti senza preavviso. L’autore non assume alcuna responsabilità per il contenuto di queste slide (ivi incluse, ma non limitatamente, la correttezza, completezza, applicabilità, aggiornamento dell’informazione).

In ogni caso non può essere dichiarata conformità all’informazione contenuta in queste slide.

In ogni caso questa nota di copyright e il suo richiamo in calce ad ogni slide non devono mai essere rimossi e devono essere riportati anche in utilizzi parziali.

Nota di Copyright

Lezione 4 Architetture di rete e tipologie di servizio

Lezione 4: indice degli argomenti

• Architetture di rete

• Livelli, protocolli e interfacce

• Servizi orientati alla connessione e servizi non orientati alla connessione

• Servizi affidabili e servizi non affidabili

• Servizi con riscontro

Architetture di rete

Problemi da risolvere

• Che mezzi trasmissivi scegliamo?

• Come trasmettiamo i bit?

(2)

Problemi da risolvere

• Come devono presentarsi e come devono funzionare i servizi che userà l’utente?

Problemi da risolvere

• Come gestiamo il transito dei messaggi tra nodi intermedi (instradamento)?

Esempi di architetture di rete SNA

Transaction Service Presentation

Service Data Flow Trans.

Control Manag.

Serv.

Virtual Route Explicit Route Transm. Group Data Link

Physical

path control half session

User

Network Application

Session

End to End

Routing

Data Link

Physical Net Manag.

Decnet phase IV

Livello 1 Livello 1

Livelli, protocolli, interfacce

Livello 2 Livello 2

Protocollo di livello 1 Protocollo di livello 2 Protocollo di livello 3

Livello 3 Livello 3

Interfaccia tra i livelli 1 / 2 Interfaccia tra i livelli 2 / 3

mezzo fisico

Livelli, protocolli, interfacce

• La rete è organizzata in livelli: scopo di un livello è quello di fornire servizi ai livelli superiore

• Un protocollo specifica il modo con cui avviene la comunicazione tra gli stessi livelli di due nodi diversi

• L’interfaccia tra i livelli definisce i servizi che il livello inferiore rende disponibili a quello superiore e le modalità di accesso a tali servizi

Peer entities

protocollo

peer entities (entità di pari livello)

primitive del servizio (operazioni disponibili)

sistema A sistema B

(3)

Imbustamento multiplo

Livello 1 Livello 1

Livello 2 Livello 2

Livello 3 Livello 3

mezzo fisico SDU H3

SDU H2

SDU

Imbustamento multiplo

Livello 1 Livello 1

Livello 2 Livello 2

Livello 3 Livello 3

mezzo fisico SDU

Imbustamento multiplo

Livello 1 Livello 1

Livello 2 Livello 2

Livello 3 Livello 3

mezzo fisico SDU H3

SDU H2

SDU

Imbustamento multiplo

Tipologie di servizio

Primitive di servizio

• Operazioni a disposizione per accedere al servizio

• Determinano cosa si chiede (cosa si ottiene) al (dal) servizio di livello immediatamente inferiore

• Nel software che gestisce la pila di

protocolli nel sistema operativo si tratta di

chiamate a funzioni di sistema

(4)

Primitive di servizio

• Request

• Indication

• Response

• Confirm

Primitive di servizio

• Request

• Indication

• Response

• Confirm

L’entità richiede che il servizio faccia qualcosa

Primitive di servizio

• Request

• Indication

• Response

• Confirm

All’entità viene notificato un evento

Primitive di servizio

• Request

• Indication

• Response

• Confirm

L’entità vuole rispondere ad un evento

Primitive di servizio

• Request

• Indication

• Response

• Confirm

È arrivata la risposta ad una richiesta precedente

Primitive di servizio: un esempio

• Request

• Indication

• Response

• Confirm

data.request

data.confirm

tempo

data.indication

data.response

(5)

Servizi orientati alla connessione

• “Connection oriented”

• Modello telefonico

• si apre la connessione

• si scambiano i messaggi

• si chiude la connessione

Servizi non orientati alla connessione

• “Connectionless”

• Modello postale

• si affida il messaggio al sistema di inoltro

• non conosco il percorso seguito e quindi lo stato della rete

Caratteristiche dei protocolli connessi e non connessi

setup iniziale indirizzo di destinazione

ordine dei pacchetti controllo del flusso

connesso non conn.

sì durante il setup garantito

sì

no nei pacchetti

non garantito

no

Servizi affidabili

• Utilizzano le primitive response/confirm per gestire la ritrasmissione in caso di errori o perdita dei messaggi

• Garantiscono la ricezione completa e corretta di tutti i messaggi

• Possono introdurre ritardi inaccettabili dovuti ad eventuali ritrasmissioni

Servizi non affidabili

• Non garantiscono la corretta ricezione dei messaggi

• Non gestiscono la ritrasmissione dei messaggi

• Utilizzano soltanto le primitive request/indication

Un esempio

servizio orientato alla connessione affidabile connect.request

connect.confirm data.request

data.confirm ...

disconnect.request

connect.indication connect.response

data.indication data.response

...

disconnect.indication

(6)

Servizi datagram

• Senza riscontro

(non usano response/confirm), in analogia con i telegrammi

• Sono servizi

• non orientati alla connessione

• non affidabili

Datagram: a cosa servono?

• Un’infrastruttura di rete orientata alla connessione non è scalabile

• ogni nodo attraversato deve mantenere lo stato di ogni connessione attiva

• Un servizio affidabile introduce ritardi

• bisogna attendere i messaggi di riscontro

• se non arrivano bisogna ritrasmettere

Datagram: a cosa servono?

• Attualmente, le reti si basano su datagram

• I servizi connessi e affidabili vengono realizzati con protocolli di livello superiore, negli host

Bibliografia

• “Reti di Computer”

• Capitolo 1

• Libro “Reti locali: dal cablaggio all’internetworking”

contenuto nel CD-ROM omonimo

• Capitolo 2