La tabella riporta una classificazione dei vari tipi di rete, infunzione dell’ambito operativo e delle distanze coperte.

AMBITO DISTANZA RETECOPERTA

Edificio 100 m Reti Locali (LAN)Comprensorio 1 km Reti Locali (LAN)Città 10 km Reti Metropolitane (MAN)Nazione 100 km Reti Geografiche (WAN)Continente 1000 km Reti Geografiche (WAN)Pianeta 10000 km Reti Geografiche (WAN)

La figura qui sopra riporta la struttura di una rete di calcolatoridi una ipotetica azienda. Essa è formata da una rete locale (LAN: Local Area Network) in ogni sede (edificio) della azienda; le LAN presenti all’interno di un’area metropolitana sono collegate tra loro tramite MAN (Metropolitan Area Network) e queste a loro volta tramite una rete geografica(WAN: Wide Area Network).

Una Tassonomia delle Reti

2LANLANLAN LAN LAN

MAN

WAN

Un esempio di Wan:la rete dell’Università di Bologna

3

Rimini

RavennaForlì

Bologna

M. Maggio

MonteCalderaro Cesena

Bertinoro

Ozzano

Le RETI LOCALI (LAN).• Una rete locale è un mezzo di trasporto equamente condiviso tra tutte le stazioni che vi si collegano, ad alta velocità e bassotasso d’errore, limitato ad un ambito locale.• Le velocità trasmissive sono comprese nell’intervallo 4 Mb/s -155 Mb/s. Accanto alle vecchie reti Ethernet e Token Ring si sono aggiunte reti più moderne quali FastEthernet a 100 Mb/s e ATM a 34 e 155 Mb/s.• Tutte queste tecnologie adottano tipicamente come supporto trasmissivo preferenziale il doppino di rame e la fibra ottica sulle dorsali. Il cavo coassiale è stato (per fortuna) quasi deltutto abbandonato.

Le RETI METROPOLITANE (MAN).Sono recenti estensioni delle reti locali in ambito urbano.Sfruttano una grande varietà di tecnologie, che vanno dai pontiradio ad alta frequenza (es ponti radio punto-punto a 38 GHz per velocità da 2 Mb/s a 34 Mb/s, o punto-multipunto di tipoSpread Spectrum) alle fibre ottiche.Le prestazioni classiche raggiunte sono comprese tra 2 Mb/s e 155 Mb/s.

Le RETI GEOGRAFICHE (WAN).Si basano solitamente su servizi offerti dai gestori nazionali ditelecomunicazione, che rendono disponibili canali pertrasmissione digitale punto a punto, i cosiddetti CDN (Canali Diretti Numerici). A causa della liberalizzazione del mercato l’offerta è in continua evoluzione.

Caratteristiche delle Reti

4

L’ OSI è un progetto di ampio respiro formulato dall’ISO(International Standard Organization) alla fine degli anni ‘70 con lo scopo di fungere da modello di riferimento per le reti dicalcolatori.L’ISO doveva:• standardizzare la terminologia;• definire quali sono le funzionalità di una rete;• servire come base comune da cui far partire lo sviluppo di standard per l’interconnessione di sistemi informatici;• fornire un modello rispetto a cui confrontare le architetture direti proprietarie.

Per gestire la complessità dei problemi, l’OSI ha adottato unapproccio a livelli (layers): il problema della comunicazione tra due applicazioni è stato spezzato in un insieme di 7 livelli,ciascuno dei quali esegue funzioni ben specifiche.

L’OSI ha cercato di diventare più di un modello di riferimento.Infatti l’ISO ha standardizzato per OSI una serie di protocolli,da collocare nei vari livelli del modello, per formare una vera architettura di rete concorrenziale con altre, quali lo Stack TCP/IP.

I livelli 1 (Fisico) e 2 (Data Link) sono stati accettati e sono oggi degli standard, garantendo l’interoperabilità dei prodotti.

I protocolli di livello superiore incontrano più difficoltà a causa dell’alto impatto che la loro adozione avrebbe sui dispositivi di instradamento e sul software dei sistemi informativi.

L’OSI (Open System Interconnections)

5

Per ridurre la complessità del progetto, OSI introduceun’architettura a livelli (layered architecture) i cui componenti principali sono:• i livelli (layers)• le entità (entities)• i punti di accesso al servizio (SAP: Service Access Points)• le connessioni (connections)In tale architettura, ciascun sistema è decomposto in un insieme ordinato di livelli, rappresentati per convenienza come una pila verticale. La figura seguente rappresenta i livelli che compongono il modello di riferimento ISO-OSI.

Tale approccio di progettazione a livelli è comune a tutte lemoderne architetture di rete.

Il modello ISO/OSIArchitettura a Livelli

6

• Anche se è definito un protocollo di livello N, nessun dato ètrasferito direttamente da un livello N all’altro su un diverso sistema.• Infatti ogni livello passa dati e informazioni di controllo aquello sottostante, sino a quando si giunge al livello Fisico, che effettua la trasmissione verso l’altro sistema.• L’interfaccia di un livello definisce quali operazioni primitive e quali servizi sono forniti da un livello ai livelli superiori.

In figura è rappresentato il meccanismo di comunicazione tra due entitàdi livello N= 4, con il messaggio che viene passato via via ai livelli inferiori (che aggiungono i loro header), viene trasmesso attraverso ilmezzo fisico, e giunto al sistema di destinazione risale liberandosi degliheader aggiunti, fino ad arrivare al livello stabilito.

Il modello ISO/OSIComunicazioni tra livelli su sistemi diversi (2)

9

• Il livello 1: FISICO.Il livello 1 del modello OSI si occupa di trasmettere sequenze binarie sul canale di comunicazione. A questo livello si specificano ad esempio le tensioni che rappresentano 0 e 1 e lecaratteristiche dei cavi e dei connettori.

• Il livello 2: DATA LINK.Il livello ha come scopo la trasmissione sufficientemente affidabile di pacchetti detti frame tra due sistemi contigui.Accetta come input dei pacchetti di livello 3 (tipicamente poche centinaia di bit) e li trasmette sequenzialmente. Esso verifica lapresenza di errori aggiungendo delle FCS (Frame Control Sequence) e può gestire meccanismi di correzione di tali errori tramite ritrasmissione.

• Il livello 3: NETWORK.Il livello 3 è il livello Network, che gestisce l’instradamento dei messaggi, ed è il primo livello (a partire dal basso) che gestisce informazioni sulla topologia della rete. Tale livello determina se e quali sistemi intermedi devono essere attraversati dal messaggio per giungere a destinazione. Deve quindi gestire delle tabelle di instradamento e provvedere ad instradamenti alternativi in caso di guasti (fault tollerance).

Il modello ISO/OSII Livelli (1)

7

• Il livello 4: TRASPORTO.Il livello 4 del modello OSI fornisce un servizio di trasferimento trasparente dei dati tra entità del livello 5 (sessione). Si occupadi garantire un servizio affidabile. Deve quindi effettuare laframmentazione dei dati, la correzione degli errori e laprevenzione della congestione della rete. Il livello 4 è il livello più basso, a partire dall’alto, a trascurare la topologia della retee la presenza di sistemi intermedi di instradamento, ed è quindi detto livello end-to-end.

• Il livello 5: SESSIONE.Organizza il dialogo tra due programmi applicativi, consentendodi aggiungere a connessioni end-to-end servizi più avazati.

• Il livello 6: PRESENTAZIONE.Definisce formalmente i dati che gli applicativi si scambiano, come questi dati sono rappresentati localmente sul sistema, e come vengono codificati durante il trasferimento.

• Il livello 7: APPLICAZIONE.Il livello 7 è il livello dei programmi applicativi, facenti parte del sistema operativo oppure scritti dall’utente, attraverso i quali l’utente utilizza la rete.

Il modello ISO/OSII Livelli (2)

8

• L’insieme dei livelli, dei protocolli e delle interfacce definisce un’architettura di rete. Le architetture di rete più note sono:• SNA (System Network Architecture) architettura della reteIBM;• DNA (Digital Network Architecture), meglio nota comeDECnet, la rete della Digital Equipment Corporation;• Internet protocol Suite, meglio nota con il nome TCP/IP, è larete degli elaboratori UNIX e rappresenta uno standard “de facto” attualmente impiegato per la rete Internet.•OSI (Open System Architecture), che è lo standard “de iure”prodotto dall’ISO.

Principali Architetture di Rete

10

La trasmissione dei dati avviene quindi:• attraverso una serie di passaggi da livelli superiori a livelli inferiori nel sistema che trasmette,• poi attraverso mezzi fisici di comunicazione,• infine attraverso un’altra serie di passaggi, questa volta da livelli inferiori a livelli superiori.Notare come a livello 2, sia necessario aggiungere in coda un campo che identifica la fine del pacchetto prima di passare lostesso al livello che utilizza il mezzo trasmissivo.

Incapsulamento dei Pacchetti

11

Non sempre lo scambio delle informazioni avviene direttamente tra i due sistemi finali che contengono le applicazioni (ES: End Systems). Può anche implicare l’attraversamento di alcuni sistemi intermedi (IS: Intermediate Systems).In questi Intermediate Systems esistono delle entità che assumono la funzione di Router (in senso esteso), ovvero entità che instradano le informazioni.Tali entità possono essere collocate a diversi livelli del modelloOSI, ed allora gli Intermediate Systems assumono nomi diversia seconda del livello in cui avviene l’instradamento dei dati. Si parla allora di repeater a livello 1, bridge a livello 2, router alivello 3 ed infine gateway a livello 7.Qui di seguito è rappresentata la collocazione di un Router nel modello OSI.

Sistemi Intermedi (1)

12

Accenniamo per ora solo all’azione svolta dai Repeater, mentre l’instradamento a livelli superiori, che comporta anche larigenerazione digitale del segnale, sarà approfondito analizzando lo stack TCP/IP

Qui di seguito è rappresentata la collocazione di un Repeater nel modello OSI. Il livello Fisico non effettua correzione dei dati ricevuti, compito che invece spetta al livello Data Link.• Il segnale che il Repeater riceve da un lato viene amplificato epropagato all’altro lato, quindi viene propagato anche il rumore che può essersi prodotto durante la trasmissione dal sistema A al Repeater, e a tale rumore si aggiungerà il rumore prodotto nella trasmissione dal Repeater al sistema B.• Di conseguenza il livello Fisico del sistema B riceve un segnale afflitto dalla somma dei rumori che si sono prodotti durante latrasmissione sui due tratti di percorso, e quindi aumenta laprobabilità che si riscontri un errore nei dati trasmessi.• La correzione potrà essere effettuata solo quando il segnale giungerà al sistema 2, ma l’eventuale ritrasmissione dei dati dovrà attraversare nuovamente i due tratti di rete.• E’ per questo motivo che bisogna ridurre al minimo il numerodi repeater in un percorso.

Sistemi Intermedi (2)

13

14

Architettura TCP/IP e confronto con OSI

15

Interfaccia Socket

I livelli TCP/IP hanno questa relazione con i livelli di OSI.

Lo stack di protocolli TCP/IP implementa un livello network(livello 3) di tipo:• packet-switched;• connectionless.

Il livello più basso (corrispondente ai livelli 1 e 2 di OSI) non èspecificato dall’architettura, che prevede di utilizzare quellidisponibili per le varie piattaforme HW e conformi aglistandard.Per quanto riguarda le reti in ambito locale (LAN), lo standardriconosciuto per i livelli 1 e 2 è rappresentato dal progetto IEEE802, che è stato riconosciuto anche da OSI.Per capire il funzionamento dei protocolli TCP/IP, nel seguitoconsidereremo proprio la situazione di una rete locale. Risultanecessario perciò soffermarsi brevemente sulla strutturazionedelle LAN.

Lo Stack TCP/IP: Le Basi

30

DEFINIZIONE: una LAN è un sistema di comunicazione chepermette ad apparecchiature indipendenti di comunicare tra loro,entro un DUHD�GHOLPLWDWD, utilizzando XQ canale fisico a YHORFLWjHOHYDWD e con EDVVR�WDVVR�G¶HUURUH.

• Le LAN hanno quindi sempre XQ�VROR�FDQDOH�WUDVPLVVLYR adalta velocità condiviso nel tempo da tutti i sistemi collegati.Quando un sistema trasmette diventa proprietariotemporaneamente (per la durata di uno o pochi pacchetti)dell'intera capacità trasmissiva della rete.

• La trasmissione è sempre di tipo EURDGFDVW, ovvero un sistematrasmette e tutti gli altri ricevono. Tale organizzazione haenormi vantaggi, ma impone anche alcune complicazioni: èQHFHVVDULD�OD�SUHVHQ]D�GL�LQGLUL]]L�GL�OLYHOOR�� per stabilire chisono il reale destinatario e il mittente della trasmissione eoccorre arbitrare l'accesso all'unico mezzo trasmissivo tra tutti isistemi che hanno necessità di trasmettere.

• L'unico canale trasmissivo presente deve anche esserecaratterizzato da un EDVVR�WDVVR�GL�HUURUH. Questo è ottenibileabbastanza facilmente in un'area delimitata usando mezzitrasmissivi di buona qualità. L'effetto ottenuto è quello che leLAN, essendo intrinsecamente affidabili, non hanno la necessitàdi correggere gli errori a livello 2 OSI e quindi normalmenteutilizzano SURWRFROOL�GL�OLYHOOR���FRQQHFWLRQOHVV ad alteprestazioni.

Le LAN (Local Area Network)

31

Quando le prime LAN cominciarono a diffondersi l’IEEE decise dicostituire sei comitati per studiare il problema dellastandardizzazione delle LAN e delle MAN, complessivamenteraccolti nel progetto IEEE 802. IEEE 802 introduce l’idea che OH/$1�H�OH�0$1�GHYRQR�IRUQLUH�XQLQWHUIDFFLD�XQLILFDWD�YHUVR�LOOLYHOOR�1HWZRUN (livello rete), pur utilizzando tecnologietrasmissive differenziate. Per ottenere tale risultato, il progettoIEEE 802 suddivide il livello Data Link in due sottolivelli:•�//&��/RJLFDO�/LQN�&RQWURO��•�0$&��0HGLD�$FFHVV�&RQWURO��

Il VRWWROLYHOOR�//&�q�FRPXQH�D�WXWWH�OH�/$1, mentre il 0$&�qFDUDWWHULVWLFR�GL�FLDVFXQD�/$1, FRVu�FRPH�LO�OLYHOOR�ILVLFR�DOTXDOH�q�VWUHWWDPHQWH�DVVRFLDWR. Il sottolivello LLC è l'interfacciaunificata verso il livello Network ed è descritto nell'appositostandard IEEE 802.2, mentre i vari MAC sono descritti neglistandard specifici di ogni rete locale (ad esempio il MACCSMA/CD è descritto nello standard IEEE 802.3, ed il MAC FastEthernet (100BaseT) è descritto in IEEE 802.3u).

32

Il Progetto IEEE 802

Il sottolivello MAC è specifico di ogni LAN e risolve ilSUREOHPD�GHOOD�FRQGLYLVLRQH�GHO�PH]]R�WUDVPLVVLYR.Il MAC è indispensabile in quanto a livello 2 (Data Link) leLAN implementano sempre una sottorete trasmissiva di tipobroadcast in cui ogni sistema riceve tutti i frame inviati daglialtri.

3HU�WUDVPHWWHUH�LQ�EURDGFDVW, cioè IDU�FRQGLYLGHUH�XQ�XQLFRFDQDOH�WUDVPLVVLYR�D�WXWWL�L�VLVWHPL, bisogna risolvere dueproblemi:• LQ�WUDVPLVVLRQH��YHULILFDUH�FKH�LO�FDQDOH�VLD�OLEHUR�SULPD�GLWUDVPHWWHUH�H�ULVROYHUH�HYHQWXDOL�FRQIOLWWL�GL�SL��VLVWHPL�FKHYRJOLDQR�XWLOL]]DUH�FRQWHPSRUDQHDPHQWH�LO�FDQDOH;• LQ�ULFH]LRQH��GHWHUPLQDUH�D�TXDOL�VLVWHPL�q�HIIHWWLYDPHQWHGHVWLQDWR�LO�PHVVDJJLR�H�TXDOH�VLVWHPD�OR�KD�JHQHUDWR.

La soluzione del primo problema è data dai vari algoritmi diMAC, basati su principi diversi, quali la contesa, il token, laprenotazione e il round-robin.

La soluzione del secondo problema QHFHVVLWD�GHOOD�SUHVHQ]D�GLLQGLUL]]L�D�OLYHOOR�0$& (quindi nella MAC-PDU) cheidentifichino ciascun sistema e trasformino trasmissionibroadcast in:• WUDPLVVLRQL�SXQWR�SXQWR, se l'indirizzo di destinazione indicaun singolo sistema;• WUDVPLVVLRQL�SXQWR�JUXSSR, se l'indirizzo di destinazioneindica un gruppo di sistemi;• WUDVPLVVLRQL�HIIHWWLYDPHQWH�EURDGFDVW, se l'indirizzo didestinazione indica tutti i sistemi.

MAC: Media Access Control (1)

33

Quando una scheda di rete locale riceve un pacchetto, questonon viene passato automaticamente al livello superiore (LLC)ma viene analizzato a livello MAC, per effettuare una serie dicontrolli.Per prima cosa il MAC verifica che il pacchetto sia integro (cioèabbia una FCS Frame Control Sequence corretta) e didimensioni ammesse. Successivamente il livello MAC analizza l'indirizzo didestinazione (MAC-DSAP).Si possono porre tre casi:

• se l’indirizzo MAC di destinazione (il MAC-DSAP) èEURDGFDVW, il pacchetto viene sempre passato al LLC, perchètutti i sistemi devono riceverlo;

• se il MAC-DSAP è single, il pacchetto viene passato al LLCsolo se il MAC-DSAP è uguale all'indirizzo hardware dellascheda o a quello caricato da software nell'apposito buffer;

• se il MAC-DSAP è multicast, si verifica se la ricezione di quelmulticast è stata abilitata dal software di livello superiore, cioè dilivello 3, cioè se la scheda appartiene al gruppo indirizzato.Poiché non è noto a priori a quanti gruppi possa appartenere unascheda, si usano delle tecniche di hash per mantenere la lista deigruppi abilitati.

Gli indirizzi di gruppo servono principalmente per scoprire qualialtri sistemi sono collegati alla rete locale, quali servizi questimettono a disposizione e, molto importante, le relazioniesistenti tra gli indirizzi MAC e gli indirizzi di livello 3.

Ricezione dei Pacchetti a livello 2

36

Nel modo normale visto nella precedente slide, se una scheda direte inserita in una LAN riceve un pacchetto, lo passa al livellosuperiore (LLC) solo se il pacchetto di livello MAC è unpacchetto broadcast, o è un pacchetto single con indirizzo ugualea quello della scheda di rete, o è un pacchetto multicast conindirizzo con cui un’indirizzo dell’host è in corrispondenza.In tal modo si ha la garanzia che i pacchetti destinati ad un hostvengano letti solo da quell’host.

In realtà esiste un’altra modalità di funzionamento delle schededi rete per LAN, detto “PRGR�SURPLVFXR” (SURPLVFXRXVPRGH) in cui tutti i pacchetti ricevuti a livello MAC sono passatiai livelli superiori. In tal caso l’analisi sulla destinazione deipacchetti dovrà essere effettuata da protocolli di livellosuperiore.Tale modalità di funzionamento viene utilizzata da applicazioni(ad es. il “tcpdump” per Linux) per effettuare il monitoraggiodella rete, ovvero per controllare quanti e quali pacchettivengono trasmessi in rete, da chi, ecc.. .Ovviamente tale modalità rappresenta un problema di sicurezzaperchè rende possibile vedere dati riservati trasmessi via rete.Per tale motivo i sistemi operativi moderni permettono soloall’amministratore del sistema (root) di configurare la scheda direte perchè funzioni in modo promiscuo, impedendo ad altri diaccedere alla porta attraverso la quale si configura lascheda di rete.

Ricezione dei Pacchetti a livello 2Un’eccezione: il modo PROMISCUO

37

I concetti di indirizzi single, multicast e broadcast sonoimplementati sia a livello MAC che a livello IP.

Un’applicazione importantissima del meccanismo di broadcastrealizzato a livello MAC, è rappresentato dal protocollo ARP di(livello 3) del TCP/IP, che permette ad un host S su una certa LAN,di scoprire a partire dall’indirizzo IP dell’host di destinazione D (sequesto sta nella stessa LAN), l’indirizzo MAC dell’hostdestinazione stesso, indirizzo che servirà per inviare il frame cheincapsulerà il pacchetto destinato all’host di destinazione. !!!Il protocollo ARP opera in questo modo:• l’host S invia a tutte le stazioni della LAN, in data link broadcast,una richiesta del tipo: "chi ha l'indirizzo IP uguale a IP_D ?”.• tutti gli host ricevono la risposta, e i MAC la passano a livello 3.• solo l'host che ha quell'indirizzo IP IP_D risponde, inserendonella risposta il proprio indirizzo MAC;• quando S riceve la risposta, sa a che MAC address deve inviare ilpacchetto.• l'host S mantiene in memoria il MAC address di D per alcuniminuti, per eventuali trasmissioni successive.

A livello IP il multicast è utilizzato per realizzare con semplicità deiflussi di comunicazione punto-multipunto, che sono sfruttati ad es.in applicazioni di videoconferenza, quali ad es. MBone. In taliapplicazioni un singolo pacchetto inviato dal sorgente raggiungemolti hosts destinatari, duplicandosi opportunamente quando ipercorsi si dividono.

Utilizzo del Broadcast.

38

Qualche considerazione:•Ogni interfaccia di rete locale è gestita da un suo livello MAC. Su tale livello MAC si appoggia un livello LLC.•Il livello MAC è implementato nell'hardware della scheda di rete locale, mentre il livello LLC è di solito realizzato in software.•Ogni livello LLC può gestire un solo livello MAC: questo significa che un livello LLC non può avere funzionalità di "relaying" (non può inoltrare pacchetti) tra più MAC.•Tale funzionalità di instradamento dei pacchetti è delegata al livello 3.

In figura vediamo le relazioni tra le Protocol Data Unit di livello3 (Network), le LLC-PDU e le MAC-PDU, incapsulate unadentro l’altra. Notare come ogni livello specifichi due indirizzidi quel livello, un mittente (*-SSAP, S come Source) ed undestinatario (*-DSAP, D come Destination) per ipacchetti/frame passati al livello inferiore.

Relazione tra il Livello 3, Logical LinkControl e Media Access Control.

39

LLC ha lo scopo di fornire un’interfaccia unificata con il livellonetwork, e di IRUQLUH�XQ�VXSSRUWR�VWDQGDUG�DOOD�FRQYLYHQ]D�GLSL��SURWRFROOL�GL�OLYHOOR�VXSHULRUH�VXOOD�VWHVVD�/$1.

Proprio per questo scopo la Protocol Data Unit di LLC contieneanch’essa due indirizzi, una destinazione e una sorgente, e TXHVWLLQGLUL]]L�UDSSUHVHQWDQR�JOL�LGHQWLILFDWRUL�GHO�SURWRFROOR�GL�OLYHOORVXSHULRUH�D�FXL�LO�OLYHOOR�//&�GHYH�FRQVHJQDUH�LO�SDFFKHWWR�FKHJOL�q�DUULYDWR [o da cui il pacchetto è arrivato] .

LLC: Logical Link Control

DestinationAddress

SourceAddress

L3-InformationControl

Supporto multiprotocollo offerto da LLC

La PDU di LLC

40

Un

data

gram

di 3

760

byte

, inv

iato

da

S=13

0.13

6.2.

204

a D

=137

.204

.72.

49 ,

tutti

i tr

atti

di r

ete

hann

oM

TU

di 1

500

byte

, tra

nne

uno

che

ha M

TU

par

i a50

0 by

te

49b

Ese

mpi

odi

Fram

men

tazi

one

MTU

1500

MTU

1500

MTU

1500

MT

U50

04

582

0

999

370

255

17U

DP

chsu

m3

130.

136.

2.20

413

7.20

4.72

.49

0

DA

TI:

2960

-375

9

MTU

1500

45

1500

999

0

255

UD

Pch

sum

1

130.

136.

2.20

413

7.20

4.72

.49

1

DA

TI:

0

-147

9

1500

999

185

255

UD

Pch

sum

2

130.

136.

2.20

413

7.20

4.72

.49

1

DA

TI:

148

0 -29

59

MTU

1 500

45

500

999

370

254

17ch

sum

413

0.13

6.2.

204

137.

204.

72.4

9

1

DA

TI:

29

60-3

439

45

340

999

430

254

17ch

sum

5

130.

136.

2.20

413

7.20

4.72

.49

0

DA

TI:

3

440 -

3759

S13

0.1

36.2

.204

D13

7.20

4.72

.49

pacc

hetti

inva

riati,

trann

eTT

Lde

crem

enta

to

fram

men

tazi

one

iniz

iale

fram

men

tazi

one

delf

ram

men

to

rias

sem

blag

gio

dei f

ram

men

ti

1480

1480

800

0

14791480

29592960

3759

1480

1480

320

480

0

14791480

29592960

3759

34393440

0x8=

0

185x

8=14

80

370x

8=29

60

430x

8=34

40

MTU

1500

MTU

MTU

1500

0

17ch

sum

1ch

sum

1

45

17

MTU

1 500

999

999

S13

0.1

36.2

.204

D13

7.20

4.72

.49

pacc

hetti

inva

riati,

trann

eTT

Lde

crem

enta

to

fram

men

tazi

one

iniz

iale

fram

men

tazi

one

delf

ram

men

to

rias

sem

blag

gio

dei f

ram

men

ti

1480

1480

800

0

14791480

29592960

3759

0

14791480

29592960

3759

34393440

0x8=

0

185x

8=14

80

370x

8=29

60

430x

8=34

40

L’architettura TCP/IP (il cui nome più preciso è ,QWHUQHW�3URWRFRO6XLWH) è formata da diversi componenti, che si posizionano nellostack dei protocolli a partire dal livello 3 (network).I protocolli appartenenti a questa architettura sono specificatitramite standard denominati RFC (Request For Comments)disponibili in rete. Ad es. l’RFC 791 specifica il protocollo IP.

Il protocollo IP (,QWHUQHW�3URWRFRO) è il protocollo principale del livello 3 dell’architettura TCP/IP. Si tratta di un protocollosemplice, di tipo datagram ovvero VHQ]D�FRQQHVVLRQH e QRQDIILGDELOH;•�QRQ�DIILGDELOH: il pacchetto inviato può essere perso, duplicatoritardato o consegnato fuori sequenza, ma il protocollo IP noninformerà nè il trasmettitore nè il ricevitore.•�VHQ]D�FRQQHVVLRQH: ogni pacchetto viene trattato in manieraindipendente dagli altri, pacchetti diversi aventi stesso mittente estesso destinatario possono seguire percorsi diversi, alcuni possonoessere consegnati ed altri no. Se le risorse della rete lo consentonoil pacchetto viene portato a destinazione, in caso contrarioverrà scartato.

Il livello Network del TCP/IP.Il protocollo IP (versione 4)

42

Attualmente lo standard per il livello network dello stack TCP/IP èrappresentato dal protocollo IP versione 4, ma già dal 1995 è stataproposta una nuova versione del protocollo IP, nota col nome di IPversione 6 (RFC 1883: Internet Protocol, Version 6 (IPv6)Specification, December 1995 R. Hinden, S. Deering ).IP versione 4 versione soffre di almeno 3 problemi principali, cheIPv6 vuole correggere:• QXPHUR�GHJOL�LQGLUL]]L�,3�GLVSRQLELOL�RUPDL�LQVXIILFLHQWH: gliindirizzi IP sono composti da 4 byte (32 bit) e a causa del grandeincremento del numero degli hosts nel mondo la disponibilità degliindirizzi è in forte calo. Il protocollo IPv6 prevede invece indirizziformati da 16 byte (128 bit) e quindi rende disponibili un numeroenorme di indirizzi.• WUDIILFR�JHVWLWR�HVFOXVLYDPHQWH�LQ�PRGR�EHVW�HIIRUW: in IPv4 tutti ipacchetti sono trattati allo stesso modo dai router, anche se esistenell’header dei pacchetti IPv4 un campo priorità, che però non vieneutilizzato. Con IPv6 si vuole definire delle classi di servizio a cuiassegnare priorità diverse. Si vuole anche gestire la comunicazionecon un meccanismo simile ad un protocollo con connessione, cioèimplementando un flusso di dati.• VLFXUH]]D: in IPv6 saranno rese standard e disponibili alcuneprimitive per l’autenticazione e la cifratura dei dati.

Nonostante queste prospettive, il protocollo IP versione 6 è ancorapoco diffuso, e rimane ancora a livello di sperimentazione, forseperchè l’adozione del nuovo protocollo costringerebbe a modificarefortemente gli apparati di rete esistenti, con un grande dispendio didenaro. Esistono a tuttoggi, in un oceano IPv4, solo delle LVROH in cuisi parla IPv6.

Nel seguito parleremo di IPv4, che rappresenta ancora lostandard più diffuso.

Il protocollo IP versione 6

43

Il protocollo IP svolge le seguenti funzioni:• GLVWLQJXH ogni hosts, o meglio RJQL�VFKHGD�GL�UHWH�PHGLDQWH�XQLGHQWLILFDWRUH, detto LQGLUL]]R�,3. Un indirizzo IP di tipo single oXQLFDVW identifica un unico host, ma uno stesso host può avere piùindirizzi IP unicast, tanti quante sono le schede di rete chepossiede. Si parla allora di MultiHomed Systems. Ad es. i routerhanno più indirizzi, perchè dovendo fungere da centri dismistamento dispongono di più schede di rete. Un host puòcomunque disporre di più schede di rete anche senza essere unrouter, cioè anche se non effettua un servizio di instradamento perpacchetti destinati ad altri hosts, ma dovrà prevedere una politicache definisca quale scheda di rete utilizzare per inviare i dati.• ULFHYH�L�GDWL (una sequenza di PDU) GDO�OLYHOOR�WUDVSRUWR (4).• LQFDSVXOD�FLDVFXQD�3'8�ULFHYXWD�LQ�SDFFKHWWL di dimensionemassima 64 Kbyte (normalmente circa 1500 byte), DJJLXQJHQGRYLXQ�SURSULR�KHDGHU (o intestazione).

• eventualmente IUDPPHQWD�L�SDFFKHWWL all’inizio o durante iltrasporto, per inserirli nei frame di livello 2.• LQVWUDGD�L�SDFFKHWWL sulla rete,• HIIHWWXD�OD�ULOHYD]LRQH, non la correzione, GHJOL�HUURUL,• DOOD�GHVWLQD]LRQH, se necessario, ULDVVHPEOD�L�IUDPPHQWLricostruendo i pacchetti originali,• HVWUDH�GDL�SDFFKHWWL�L�GDWL (PDU) GHO�OLYHOOR�WUDVSRUWR,• FRQVHJQD�DO�OLYHOOR�WUDVSRUWR�L�GDWL�QHOO¶RUGLQH�LQ�FXL�VRQRDUULYDWL�D�GHVWLQD]LRQH, che può essere diverso dall’ordinein cui sono partiti.

Funzioni del protocollo IPv4

44

header delDatagram IP

area dati del Datagram IP(PDU del livello trasporto)

Un pacchetto IP è costituito da un header e da una parte dati, cherappresenta la porzione di dati del livello trasporto da trasferire.

L’header IP ha:• una prima parte fissa di 20 bye,• una seconda parte, opzionale, di lunghezza variabile, ma sempre multiplo di 4 byteed è strutturato come segue.

byte 0-3

byte 4-7

byte 8-11

byte 12-15

byte 16-19

byte .....

• Il campo 9HUVLRQ (di 4 bit) indica la versione del protocollo IPche ha generato il pacchetto. Serve al ricevente per capire ilformato del pacchetto che stà ricevendo. Se lo standard cambia, ades. il passaggio da IPv4 (Version=4) ad IPv6 (version=6) ilricevente capisce da questo campo come deve trattare il pacchetto.• Il campo +/(1 (anch’esso di 4 bit) indica la lunghezzadell’Header IP misurata in ZRUG�GL���E\WH. Se HLEN vale 7l’header è lungo 4*7=28 byte. Tutti i campi dell’header hannolunghezza fissa, tranne il campo Options, di lunghezza variabile,ed il corrispondente campo PAD (Riempimento) che serve arendere l’header lungo un multiplo di 4 byte.

Il pacchetto IPv4: lo HEADER

45

header delDatagram IP

area dati del Datagram IP(PDU del livello trasporto)

DF

MF

Version HLEN Type of service Total length

Identification Fragment offset

Time to live Protocol Header checksum

Source IP address

Destination IP address

32 bit

4 4 8 1 1 1

Pad (Riempimento)Options

• Il campo 7RWDO�/HQJWK (di 16 bit) indica la lunghezza totale delpacchetto IP, HVSUHVVD�LQ�E\WH, e comprende sia l’header che il campodati. Quindi se Total Length = 50 il pacchetto IP è lungo 50 byte.Poichè il campo è lungo 16 bit la massima lunghezza possibile per unpacchetto IP è di 216-1=65535 byte.

• Il campo 7\SH�RI�6HUYLFH (di 8 bit) rappresenta un’LQGLFD]LRQH�DLURXWHU�VXOOD�TXDOLWj�GHO�WUDVSRUWR�FKH�SRVVLELOPHQWH�LO�SDFFKHWWR�,3GRYUHEEH�VSHULPHQWDUH. Il router dovrebbe basarsi anche su questeindicazioni per decidere la precedenza dei pacchetti nelle sue code, el’instradamento. Ad es. se il pacchetto richiede un certo ritardomassimo, il router potrebbe decidere di instradarlo su un percorsoattraverso una rete ATM a cui chiedere garanzie sul ritardo massimopiuttosto che attraverso una rete con servizio di tipo Best Effort chenon può offrire garanzie.

• I primi 3 bit definiscono un campo 3UHFHGHQ]D con valori da 0 a7, al crescere del quale cresce l’importanza del pacchetto IP. Ilvalore 0 indica precedenza normale, il valore 7 un pacchetto dicontrollo della rete, e quindi maggiore importanza.• I bit 3 (D=Delay), 4 (T=Throughput) e 5 (R=Reliability) indicanoil tipo di trasporto preferito: D settato (D=1) indica richiesta dibasso ritardo, T settato chiede un elevato throughtput (ampia bandadi trasmissione), R settato indica richiesta di massima affidabilità.• I bit 6 e 7 non sono usati.

Di solito però i router non tengono conto delle preferenze espressemediante il campo Type of Service. Attualmente si studiano dellepolitiche (note come 'LIIHUHQWLDWHG�6HUYLFHV) che cercano direalizzare routing e buffering basandosi sulla classificazionedelle applicazioni proprio in base a indicazioni di questo tipo.

HEADER IPv4 (2)

46

Precedenza Non UsatiRTD 0 1 2 3 4 5 6 7

L’hardware di ogni tipo di rete impone un limite superiore alladimensione del frame di livello 2, e quindi anche alla quantità di datidi livello 3 che possono essere trasportati in un unico frame a livello 2.La dimensione massima di dati di livello 3 che possono esseretrasportati in un frame del Data Link viene chiamata 0DVVLPD�8QLWjGL�7UDVIHULPHQWR (078: 0D[LPXP�7UDQVIHU�8QLW), ed ècaratteristico di ogni tipologia di rete. Per Ethernet MTU=1500 bytes.• Se la porzione dati di un datagram IP (più la dimensione dell’headerIP) è più piccola della MTU della rete sottostante, il datagram IP potràessere inserito completamente in un frame di livello 2 e inviato adestinazione.

• Se invece la porzione dati del datagram IP ( più la dimensionedell’header IP) è più grande della MTU della rete sottostante, ODSRU]LRQH�GDWL dovrà essere spezzata in più pezzi che verrannoincapsulati in datagram IP (detti frammenti) più piccoli della MTU, eciascun frammento dovrà essere inserito in un frame diverso e verràspedito separatamente dagli altri verso la destinazione finale, dove ilprotocollo IP provvederà a rimettere assieme i diversi frammenti e aricostituire il datagram originale. Nell’esempio un pacchetto IP con3260 byte di dati frammentato per una MTU di 1500 byte.

47

La Frammentazione dei pacchetti IP

frammento 1 (offset 0) (MF=1)

frammento 1 (offset 1480)( MF=1)

frammento 3 (offset 2960) (MF=0)

Header Frame Area Dati Frame

Header Datagram IP Area Dati Datagram IP

header frammento 1(20 byte)

Dati 1(1480 byte)

header datagram IP(20 byte)

Dati 1(1480 byte)

Dati 2(1480 byte)

Dati 3(300 byte)

header frammento 3(20 byte)

Dati 3(300 byte)

header frammento 2(20 byte)

Dati 2(1480 byte)

il problema della frammentazione si propone ogni volta che nelpercorso seguito dai pacchetti IP, si deve attraversare una porzione direte avente una MTU minore della porzione di rete precedentementeattraversata, sempre se la dimensione dei pacchetti IP è maggiore dellaMTU più piccola.Il router preleva allora la porzione dati del datagram IP e lo spezza inpiù porzioni, in modo che ciascuna (aggiungendovi l’header) stia in unframe, e in modo che ogni frammento dei dati, tranne l’ultimo, abbiadimensione multipla di 8 byte, perchè così è definito il campo offsetdell’header IP.L’ultimo pezzo in genere sarà il più corto e verrà identificato comeultimo settandovi a zero il flag 0RUH)UDJPHQW, ad indicare che èl’ultimo frammento. Negli altri frammenti 0) è settato a 1.

Il protocollo IP usa tre campi dell’header per controllare ilmeccanismo della frammentazione e permettere il riassemblaggio deidatagram frammentati. Questi campi sono ,GHQWLILFDWLRn (16 bit),)UDJPHQW�2IIVHW (15 bit) e il flag 0RUH�)UDJPHQW (0)).

48

La Frammentazione dei pacchetti IP

DF

Version HLEN Type of service Total length

Time to live Protocol Header checksum

Source IP address

Destination IP address

32 bit

4 4 8 1 1 1

Pad (Riempimento)Options

MF Fragment offsetIdentification

/¶KHDGHU�GHO�GDWDJUDP�RULJLQDOH�YHUUj�FRSLDWR�LQWHJUDOPHQWH�QHLIUDPPHQWL (con qualche modifica per il campo Options) e in più verràcambiato il campo )UDJPHQW�2IIVHW�FKH�LQGLFD�LO�SXQWR�GHOO¶DUHDGDWL�GHO�GDWDJUDP�RULJLQDOH�LQ�FXL�FRPLQFLD�OD�SRU]LRQH�GL�GDWLWUDVSRUWDWD�QHO�IUDPPHQWR. Tale offset è pensato come un multiplodi 8 byte. Se l’offset indica ad es. 185, il frammento porta la porzionedi dati che inizia nella posizione 185*8=1480 byte.

• 7XWWL�L�IUDPPHQWL sono caratterizzati dall’avere lo stessoidentificatore (il campo ,GHQWLILFDWLRQ) del datagram originale. Talenumero è assegnato univocamente dal trasmettitore (che mantiene uncontatore dei datagram IP trasmessi), e la coppia (IP Provenienza,Identification) rende univocamente identificabile un certodatagram IP, e tutti i suoi frammenti.

49

La Frammentazione dei pacchetti IP

Dopo la frammentazione, ogni frammento viaggia separatamente daglialtri fino alla destinazione finale. Solo alla fine del viaggio avrà luogoil riassemblaggio dei frammenti, nel tentativo di ricostruire ildatagram Originale.

Il ricevitore riconosce di avere ricevuto un frammento e non undatagram intero in due modi:• il pacchetto IP ricevuto ha un RIIVHW�XJXDOH�D�]HUR, ma ha il flag0RUH�)UDJPHQW�VHWWDWR�DG�XQR (è il primo frammento).• il pacchetto IP ricevuto ha un RIIVHW�GLYHUVR�GD�]HUR (è unframmento successivo). Se il More Fragment è zero è l’ultimoframmento.

Il protocollo IP del ricevente identifica univocamente i frammenti diuno stesso datagram mediante la coppia (,3�WUDVPHWWLWRUH�,GHQWLILFDWLRQ�GHO�GDWDJUDP).

Il ricevente non conosce la dimensione del datagram originale perchèogni frammento mantiene nel campo Total Length la lunghezza delframmento stesso, e non quella del datagram originale. Solo quandoriceverà il frammento con il flag 0RUH�)UDJPHQW�VHWWDWR�D�]HUR(cheindica l’ultimo frammento del datagram originale), si potrà capire ladimensione totale del datagram originale sommando all’offsetdell’ultimo frammento la lunghezza dei dati trasportati nell’ultimoframmento.

Se un solo frammento viene perso, è impossibile ricostruire ildatagram IP originale.

Per evitare di aspettare inutilmente un frammento perso, il ricevitorenel momento in cui riceve un primo frammento inizializza un timer.Se il timer scade prima che tutti i frammenti siano giunti adestinazione il ricevitore butta via tutti i frammenti.

50

Il Riassemblaggio dei Frammenti

• Il campo 7LPH�7R�/LYH (TTL, tempo di vita, di 8 bit) indica in modoapprossimato il tempo, in secondi, che un pacchetto IP può rimanereall’interno di una rete prima di essere scartato.-Tale valore viene inizializzato a 255 dall’host che spedisce ilpacchetto IP. Ogni volta che un router processa quel pacchetto IP,decrementa di una unità questo contatore. Quando il contatoreraggiunge il valore zero, il router scarta il pacchetto.-Per ovviare al problema della congestione della rete che causa lungheattee in coda, quando il router riceve un pacchetto e lo mette in coda inattesa per spedirlo, salva il valore corrente dell’orologio.-Quando il pacchetto deve essere spedito si calcola il tempo (insecondi) trascorso in coda e si decrementa di questo tempo ilcontatore TTL.-Grazie al contatore TTL, i pacchetti IP non possono viaggiare ineterno nella rete anche se per un errore i router li instradano in unpercorso ciclico, e si evitano così congestioni nella rete.-Quando un pacchetto IP viene frammentato durante il percorso, tutti isuoi frammenti vengono incapsulati con il TTL residuo del pacchetto.

• Il campo 3URWRFRO (di 8 bit) indica di quale tipo è il dato trasportatonell’area dati del pacchetto IP, ovvero indica qual’è il protocollo dilivello 4 (o 3) che ha generato i dati trasportati dal pacchetto IP. In talmodo il livello Network sa a quale protocollo dovrà consegnare i datitrasportati. Tra i protocolli che possono essere trasportati nell’area datiricordiamo:•0 ICMP Internet Control Message Protocol•4 IP IP in IP (incapsulamento, tunneling)•6 TCP Transmission Control Protocol•17 UDP User Datagram Protocol•29 ISO-TP4 ISO Transport Protocol Class 4•93 AX.25 AX.25 frames

51

HEADER IPv4 (continua 3)

• Il campo +HDGHU�&KHFNVXP (di 16 bit) serve a verificare che ORKHDGHU�,3�VLD�DUULYDWR�LQWHJUR�D�GHVWLQD]LRQH. Viene codificatoutilizzando i byte del solo header. Se durante il trasporto l’headersubisce delle modifiche, la checksum risulta diversa e il protocollo IPcapisce che c’è stato un errore.Notare che la checksum verifica l’integrità del solo header, e non deidati trasportati.Il YDQWDJJLR�GL�DYHUH�XQD�FKHFNVXP�VHSDUDWD�SHU�KHDGHU e dati èche:

• i protocolli di livello superiore possono scegliere una loro codificaper il controllo degli errori,• i router diminuiscono il tempo necessario a calcolare la checksum,perchè devono processare solo l’header, che di solito è più piccolodei dati trasportati.

Di contro, lo svantaggio di avere a livello IP una checksum solo perl’header IP impedisce al livello 3 di accorgersi di eventuali errori suidati di livello 4, fino a che tali dati non sono giunti a destinazionefinale, e solo allora il protocollo di livello 4 effettuerà il controllo suidati con delle proprie checksum. Però il livello 2 potrebbe avere giàriconosciuto un errore e scartato il frame.

• I campi 6RXUFH�,3�DGGUHVV e 'HVWLQDWLRQ�,3�DGGUHVV contengonogli indirizzi IPv4 a 32 bit della provenienza originale e delladestinazione finale del datagramma IP. Tali indirizzi quindi noncambiano mai durante tutto il percorso, comunque venga instradato ilpacchetto, e comunque venga frammentato.

• Il campo 2SWLRQV, è di lunghezza variabile, e poichè l’header IPdeve avere lunghezza pari ad un multiplo di 4 byte, viene introdottoove necessario un ultimo campo 3DGGLQJ di riempimento,per arrivare alla giusta lunghezza. 52

HEADER IPv4 (4)

Il campo 2SWLRQV non è necessario in tutti i datagram IP. Le opzionisono utilizzate allo scopo di testare la funzionalità della rete sottostante.Evitiamo di addentrarci su come sono organizzati i sottocampi delcampo Opzioni IP, e analizziamone soltanto le funzionalità previste.Essenzialmente le opzioni sono classificabili in 3 categorie:�)�2S]LRQH�GL�UHJLVWUD]LRQH�GHO�SHUFRUVR.• Quando il trasmettitore setta l’opzione di registrazione del percorso,indica il numero massimo di hop che vuole memorizzare e crea spaziosufficiente nel campo opzioni per memorizzare tali hop, 32 bit per ogniindirizzo IP da memorizzare.• Quando il pacchetto IP viaggia per la rete, ogni router toccato daldatagram IP aggiunge il proprio indirizzo IP alla lista di registrazionedel percorso, almeno fino a che tale lista non è piena, nel qual caso ilrouter si limita ad inoltrare il messaggio.• Quando il pacchetto IP giunge alla destinazione finale, il protocollo IP,se vuole, può estrarre la lista dei router toccati dal pacchetto.•Questa opzione viene utilizzata ad es. per implementare l’applicazionedetta “traceroute” che visualizza i router toccati da un pacchetto.�)�2S]LRQL�GL�,QVWUDGDPHQWR�GL�3URYHQLHQ]D.Le opzioni di Instradamento di Provenienza, consentono al trasmettitoredi imporre ad un pacchetto IP un certo percorso attraverso la rete, anchese i router normalmente sceglierebbero un percorso diverso. Ciò puòessere utile per effettuare dei test sulla rete. Naturalmente per imporrel’instradamento è necessario conoscere la topologia della rete.Esistono due modalità per l’instradamento di provenienza. la prima,detta LQVWUDGDPHQWR�GL�SURYHQLHQ]D�VHYHUR specifica una sequenza disalti consecutivi, e causa errore se due router non sono consecutivi nellarete, cioè non stanno sulla stessa rete fisica o se il router non può seguirequel percorso. La seconda detta LQVWUDGDPHQWR�GL�SURYHQLHQ]DSHUPLVVLYR specifica una sequenza di indirizzi IP, ma consentedi attraversare più reti tra due indirizzi consecutivi.

53

HEADER IPv4 (5)

�)�2S]LRQH�GL�FRQWUDVVHJQR�WHPSRUDOH�E’ simile all’opzione di registrazione del percorso, ma aggiungeall’indirizzo IP di ogni router attraversato anche la data e l’ora in cui ilrouter gestisce il datagram IP, espresso secondo l’ora del meridiano diGreenwich.

•�(ODERUD]LRQH�GHOOH�2S]LRQL�GXUDQWH�OD�IUDPPHQWD]LRQH.Ciascuna Opzione IP, viene identificata mediante un byte nel campoOpzioni. Il primo bit (detto bit COPIA) di questo byte stabilisce, quandoposto ad 1, che l’opzione deve essere copiata in tutti gli eventualiframmenti del pacchetto IP. In caso contrario l’opzione verrà copiatasolo in uno dei frammenti.Questo diverso comportamento viene configurato in modo diverso perle diverse Opzioni IP.

• Per l’opzione di registrazione del percorso, si vuole che l’opzione siacopiata in uno solo dei frammenti, perchè essendo ogni frammentogestito separatamente, potrebbe seguire percorsi diversi verso ladestinazione. Si avrebbero così più liste di registrazione del percorsopotenzialmente diverse. Il flag COPIA viene perciò posto a zero, el’opzione copiata in uno solo dei frammenti.

• Al contrario, per l’opzione di instradamento di provenienza si vuoleche tutti i frammenti seguano lo stesso percorso, e quindi il flag COPIAviene posto ad uno.

54

HEADER IPv4 (6)

Gli indirizzi IP, che devono essere univoci sulla rete, sono lunghi 32 bit (quattro byte) e sono tradizionalmente visualizzati scrivendo ivalori decimali di ciascun byte separati dal carattere punto.

• Gli indirizzi IP comprendono due o tre parti. La prima parte indica l'indirizzo della rete (network), la seconda (se presente) quello della sottorete (subnet) e la terza quello dell'host.

• Si noti che non sono gli hosts ad avere un indirizzo IP, bensì leinterfacce di rete. Quindi se un nodo ha tre interfacce, esso ha tre indirizzi IP. Poichè la maggior parte degli hosts ha una sola interfaccia di rete, parlando di indirizzo IP di un host si fa riferimento all’indirizzo della sola interfaccia di rete presente.

• Gli indirizzi IP sono suddivisi in cinque classi, di cui le prime 3, denominate A, B e C, servono ad individuare singole interfacce di rete e differiscono per il numero di host che ciascuna rete può indirizzare, mentre le altre due classi D ed E sono utilizzate per servizi assai differenti. Ad es. le reti dell’Università di Bologna (130.136.*.* , 137.204.*.* ) sono di classe B.

- Classe A. Sono concepiti per poche reti di dimensioni molto grandi. Gli indirizzi di classe A sono riconoscibili in quanto il il bitpiù significativo del primo byte è posto a zero, e quindi il primocampo dell'indirizzo è compreso tra 0 e 127. I bit che indicano la rete sono 7 e quelli che indicano l'host 24. Quindi si possono avere almassimo 128 reti di classe A, ciascuna con una dimensione massimadi circa 16 milioni di indirizzi.

55

INDIRIZZAMENTO IP

- Classe B. Sono pensati per un numero medio reti di dimensioni medio-grandi. Gli indirizzi di classe B si riconosconno perchè i 2 bit più significativi del primo byte sono posti a 10, quindi il primo campo dell'indirizzo è compreso tra 128 e 191. I bit che indicano larete sono 14 e quelli che indicano l'host 16. Si possono avere circa 16000 reti di classe B, ciascuna con circa 64000 indirizzi.

- Classe C. Sono concepiti per identificare molte reti di dimensioni piccole. Gli indirizzi di classe C hanno i primi 3 bit settati a 110 equindi il primo campo dell'indirizzo è compreso tra 192 e 223. I bitche indicano la rete sono 21 e quelli che indicano l'host 8. Quindi si possono avere al massimo 2 milioni di reti di classe C, ciascuna conuna dimensione massima di 256 indirizzi.

- Classe D. Sono indirizzi usati per applicazioni di multicast . Gli indirizzi di classe D si riconoscono perchè i primi 4 bit del primo byte sono settati a 1110, e quindi il primo campo dell'indirizzo ècompreso tra 224 e 239.

- Classe E. Questi indirizzi sono riservati per usi futuri. Gli indirizzi di classe E hanno i 4 bit più significativi settati a 1111, equindi il primo campo dell'indirizzo è compreso tra 240 e 255.

56

INDIRIZZAMENTO IP (2)

127 qualunque numero

0 1 2 7 8 31loopback

Esistono inoltre indirizzi IP con significato particolare, ad esempioper gli indirizzi di broadcast e per il loopback.

57

INDIRIZZAMENTO IP (3)

tutti 0

0 1 2 7 8 31

questo host

tutti 1

0 1 2 7 8 31broadcast suquesta network

(non ammesso come indi_rizzo di provenienza)

(suggerimento: provare su s.o. Linux il comando ping 0.0.0.0)

(suggerimento: provare il comando ping 255.255.255.255)

l’host specificatoin questa rete

(non ammesso come indi_rizzo di destinazione)

(serve solo all’avviamento )

tutti 0 host

0 1 2 15 16 31

(suggerimento: provare il comando ping 0.0.0.204)

rete tutti 1

0 1 2 15 16 31Broadcast per larete specificata

(non ammesso come indi_rizzo di provenienza)

(suggerimento:staccare il cavo di rete e provare il comando ping 127.5.6.7)

Quando si utilizza il loopback, il pacchetto non viene inviato sulla rete ma viene passato ai moduli IP di ricezione, ed elaborato come se fosse in arrivo: ciò serve ad es. per effettuare localmentedei test su un software di rete in fase di sviluppo.

E’ necessario creare un insieme di protocolli di rete che nondipendano dall’archite ttura del computer o della scheda di rete. Nontutte le architetture di calcolatori memorizzano i dati nello stesso modo. In particolare gli interi di 32 bit (le dimensioni dell’indirizzoIP) sono memorizzati in due modi diversi: le macchine Little Endian mantengono il byte meno significativo nell’indirizzo di memoria piùbasso, le macchine Big Endian mantengono il byte più significativo nell’indirizzo di memoria più basso.

• Per evitare confusione, ovvero per evitare che un indirizzo IPpossa venire scritto in due modi diversi, i protocolli TCP/IPdefiniscono un ordine di byte standard della rete, che tutte lemacchine devono usare per i campi dei protocolli IP, ovviamentenon per la parte dati.• In trasmissione, prima di scrivere ad es. un’indirizzo IP nel campodestinazione del pacchetto IP, l’host deve convertire il numero IPdalla sua propria rappresentazione alla rappresentazione standard per la rete.• In ricezione, prima di valutare l’indirizzo IP contenuto nel campoprovenienza del pacchetto IP, deve convertire tale campo dal formato di rete standard nel formato interno della macchina.• Internet stabilisce come ordine standard per gli interi a 32 bit,quello che prevede che i byte più significativi siano trasmessi perprimi (stile Big Endian). Guardando viaggiare i dati da una macchina all’altra , un intero a 32 bit comincia ad essere trasmesso dal byte più significativo, cioè col byte più significativo più vicino all’inizio del pacchetto. Le librerie socket forniscono per le conversioni delle funzioniche sono: ntohs,ntohl,htons,htonl.

58

L’ORDINE dei BYTE in RETE

byte 3 byte 2 byte 1 byte 0byte

addressBig Endian

byte 3 byte 2 byte 1 byte 0fine

pacchettoinizio

pacchetto

direzione di trasmissione

Il routing IP, ovvero l’i nstradamento di un pacchetto IP verso ladestinazione specificata nell’header del pacchetto IP viene effettuato secondo le seguenti modalità:• Un certo host deve inviare un pacchetto IP verso una destinazioneIP_D (oppure un router ha ricevuto un pacchetto e deve instradarloverso la destinazione IP_D).• l’host controlla l’indirizzo IP di destinazione per capire sel’indirizzo IP_D appartiene alla sua stessa sottorete cioè se ladestinazione è raggiungibile in modo diretto mediante il MAC address cioè sfruttando il solo livello 2, ovvero se per raggiungere ladestinazione non è necessario attraversare router (livello 3) ma almassimo si attraversano dei bridge (vedi subnetting).• Se la destinazione sta sulla stessa sottorete dell’host , si usa laconsegna diretta, cioè l’host trova (col protocollo ARP) l’indirizzodi livello 2 di destinazione (MAC_D), incapsula il pacchetto IP in un pacchetto di livello 2 con quell’indirizzo MAC_D comedestinazione, e lo invia in rete.• La destinazione MAC_D a livello 2 vede passare il pacchetto,vede il proprio indirizzo MAC_D e carica il pacchetto passandolo allivello IP ed il gioco è fatto.• Se invece la destinazione non sta sulla stessa sottorete si usa laconsegna indiretta, cioè l’host deve inviare il pacchetto IP al router di default, ovvero un router che l’host conosce e che sta sulla stessa sottorete dell’host . L’host cerca (ancora con il protocollo ARP)l’indirizzo di livello 2 del default router (MAC_R), incapsula il pacchetto IP in un pacchetto di livello 2 con quell’indirizzo MAC_R come destinazione, e lo invia in rete.Il router vede passare il pacchetto con il proprio MAC address, lo

carica, estrae il pacchetto IP, vede che l’indirizzo IP_D non èil suo e lo instrada con lo stesso meccanismo già visto.

59

Approccio al ROUTING IP (1)

60

Approccio al ROUTING IP (2)

S cagnina130.136.3.204

Dsangiovese130.136.3.203

bridge (quindi livello 2), invisibile al livello IP,instrada i pacchetti tramite il MAC address

S cagnina130.136.3.204

Dsangiovese130.136.3.203BRIDGE

Consegna Diretta (via MAC address)Sorgente S e destinazione D appartengono alla stessa sottoreteanche se in mezzo c’e’ un bridge, perchè lavorando a livello 2

instrada i pacchetti mediante i MAC address, e non gli indirizzi IP

Consegna Indiretta (via IP address)Sorgente S e destinazione D non stanno sulla stessa sottorete

in mezzo c’e’ un router, che lavora a livello 3,necessario routing a livello IP

sarastro.cs.unibo.it130.136.2.10

Scagnina

130.136.3.8

DROUTER

130.136.3.252 130.136.2.253

MAC_S MAC_R3 MAC_R2 MAC_D

• Un certo indirizzo di rete di classe A, B o C permette di mappareun certo numero di hosts, come appartenenti ad una stessa rete.• Però una rete fisica, a seconda della sua topologia, della disposizione degli apparati di routing e bridging, e di criteri diopportunità vari, può essere intrinsecamente costituita da più parti,connesse in varia maniera, ciascuna delle quali costituisce una retebroadcast a livello 2.• Si è cercato di indirizzare ciascuna di queste porzioni di rete inmodo separato, senza essere costretti ad utilizzare per ciascuna diesse una diversa rete (non sono poi così tante le reti disponibili).• Il meccanismo del subneting serve proprio a descrivere lasituazione in cui alcuni host sono in grado di comunicare tra loro inmodo diretto via livello 2, in modo da dar loro la possibilità discambiarsi direttamente i pacchetti IP senza utilizzare un router, e sidice allora che gli host appartengono alla stessa sottorete.• Il meccanismo consiste nel considerare la parte host del’indirizzoIP di un host, come formato da due parti, la subnet e l’host . Aseconda dell’ampiezza del campo dedicato alla subnet, si possono ottenere molte subnet contenenti ciascuna pochi host, o pochesubnet contenenti molti hosts.• L’ampiezza dei campi subnet e host viene definita mediante unparametro, detto netmask, configurato uguale per tutti gli host della stessa subnet. La netmask contiene i bit ad uno in corrispondenza dei campi network e subnet dell’indirizzo IP, e a zero incorrispondenza del campo host.Ad es. una netmask 11111111111111111111111100000000, più comunemente scritta come indirizzo IP 255.255.255.0 (o inesadecimale ffffff00), indica che il campo host coincide conl’ultimo byte dell’indirizzo IP 61

SUBNET IP (1)

Con il subnetting dell’esempio qui sopra, a partire da uno stesso indirizzo di classe B, otteniamo 256 diverse sottoreti, ciascuna con 254 indirizzi disponibili per gli host (256 -broadcast(1) -questo(0)).Algoritmo di Riconoscimento di Appartenenza a stessa subnet.Dato un indirizzo IP di un host, e la netmask per la sua sottorete,dato un altro indirizzo IP (ad. es. di un host a cui il primo deve spedire un pacchetto) per capire se i due indirizzi appartengono alla stessa sottorete, ogni indirizzo viene messo in AND bit a bit con lanetmask, ottenendo due valori che sono la parte network e subnetdei due indirizzi. Se questi due valori sono uguali, allora i dueindirizzi IP stanno sulla stessa sottorete, altrimenti stanno su sottoreti diverse.Ad es., una rete (classe B) 130.136.*.* con netmask 255.255.255.0, i due indirizzi 130.136.3.204 e 130.136.3.203 stanno sulla stessa sotorete, perchè dall’AND bit a bit di indirizzi e netmask siottiene 130.136.3.0, quindi i due IP sono nella stessa subnet.

62

SUBNET IP (2)Vediamo un esempio di indirizzo di una classe B, a cui viene applicata una netmask 255.255.255.0 , in modo che la parte hostviene partizionata in una parte subnet ed una host di 8 bit ciascuna.

1 0

0 1 2 7 8 15 16 23 24 31

network hos t

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0

0 1 2 7 8 15 16 23 24 31

netmask

1 0

0 1 2 7 8 15 16 23 24 31

network subnet host

indirizzo diclasse B

netmask

subnetting

Come abbiamo visto poco fa (slide 59) l’importanza di capire se due host stanno sulla stessa sottorete risiede nel fatto che in IP il routingminimo (consegna diretta) è realizzabile solo se i due hosts stanno sulla stessa sottorete.Quindi, in tecnologia IP una subnet deve coincidere con una rete fisica (*), o meglio deve coincidere con l’insieme degli host che possono comunicare tra loro via broadcast di livello2 , e quindi può coincidere anche con un insieme di più reti fisiche connesse mediante bridges (livello 2).

(*) In realtà, il concetto di subnet è stato rilassato, e si permette che:• una stessa rete fisica (una LAN) (o più reti fisiche interconnesse da bridge) possa contenere più subnet IP, qualora sia necessario partizionare una rete fisica in modo logico.• Invece una subnet IP non può mai contenere più reti fisiche interconnesse da router, cioè una subnet IP non può mai attraversaredei router. (**)(**) Anche questa affermazione è messa in forse dall’avvento diconcetti quali le LAN virtuali, che però non è chiaro a quale livello debbano essere collocate. Quindi per ora ci teniamo il concetto di subnet IP come rete capace di comunicare per mezzo del broadcast di livello 2. 63

SUBNET IP (3)

Bridge

Router

130.136.3.0

130.136.2.0

130.136.2.0

cagnina

130.136.3.204

130.136.3.251

130.136.2.253

sangiovese

130.136.3.203

timur

130.136.2.7

sarastro

130.136.2.10

Per come viene effettuato il routing in IP, le informazioni che un host deve conoscere per poter instradare correttamente i pacchetti che vuole spedire sono:• il proprio indirizzo MAC, che legge nella sua scheda di rete,• il proprio indirizzo IP, che può essere assegnato e salvato su file o gli può essere assegnato al boot (per i sistemi diskless, mediante il protocollo RARP a partire dal MAC address),• l’indirizzo IP di un router di default, a cui consegnare tutti ipacchetti IP per indirizzi che non stanno nella sua stessa sottorete,• un criterio per sapere quali hosts stanno nella sua sottorete, inmodo da poter decidere se spedire i pacchetti direttamente (previa richiesta ARP) o se instradarli via default router. Tale criterio ècostituito dalla cosiddetta netmask, che l’amministratore di rete assegna ad ogni host, la stessa per tutti gli hosts della sottorete.

La sottorete a cui un host (un IP address) appartiene è costituita da quegli host che:1) appartengono alla stessa rete IP, cioè hanno stesso indirizzo direte (sia essa di classe A B o C),2) appartengono alla stessa rete fisica (o a reti fisiche diverse ma separate solo da bridge, che inoltrano via MAC address) equindi propagano i broadcast di livello 2, per permettere ad es. di comunicare tramite livello 2 direttamente e di effettuare la chiamataal protocollo ARP,3) hanno avuto assegnata la stessa netmask, che individua l’appartenenza ad una stessa sottorete,4) hanno indirizzo IP e netmask tali che l’AND bit a bit tra indirizzo IP e netmask da’ lo stesso risultato per tutti gli IP della sottorete (criterio di appartenenza ad una stessasottorete). 64

Informazioni per Routing in un Host

------ OgniOgni hosthost deve manteneredeve mantenere lele seguenti informazioniseguenti informazioni::• il proprio indirizzo MAC,• il proprio indirizzo IP,• l’indirizzo IP di un router di default nella stessa sottorete,• la netmask della sua sottorete (riconoscere gli IP della sottorete).--- Un host per inviare un datagram IP,• fa l’AND bit a bit della netmask, una volta con l’indirizzo didestinazione, ed una volta con il proprio indirizzo IP.• Se i due risultati sono uguali l’indirizzo di destinazione appartiene alla sua stessa sottorete, e l’host usa l’ instradamento diretto, inviando il datagram in un frame di livello 2 avente, comeindirizzo di livello 2, il MAC address della destinazione.• In caso contrario l’host invia il pacchetto IP (che ha nell’header l’indirizzo di destinazione IP) incapsulato in un frame destinatoal router di default cioè avente MAC address del router sulla stessa rete, ed il salto successivo lo deciderà il router (Next Hop).• Qualunque sia la destinazione a livello 2 (il router per il primosalto o l’host destinazione in caso di consegna diretta) il MAC address verrà ottenuto con chiamata ARP o alla cache ARP.• La destinazione a livello 2 vede transitare il proprio indirizzoMAC, carica il frame, toglie l’incapsulamento e passa al livello IP.• Nell’host di destinazione, il livello IP riconosce nell’indirizzo IP di destinazione del pacchetto IP il proprio indirizzo IP e consegna il pacchetto IP al protocollo superiore.• Invece il router si accorge che il pacchetto IP non è per lui, e decide di instradarlo, consulta delle tabelle di instradamento (coppie(subnet, interface)) e se l’IP destinazione del pacchetto sta’ nella sottorete di una interfaccia instrada in modo diretto, altrimenti sceglie (tra i router a lui direttamente collegati) quale usare perinstradare il pacchetto; il prossimo router sceglie il successivo hop.

65

Il Routing in Internet Protocol

Il concetto di subnet introduce quindi un livello di gerarchia nelle reti TCP/IP. Il routing si scinde in:• un routing all’interno della subnet,• un routing tra subnet diverse ma gestite da una stessa autorità, icosiddetti autonomous systems (es. l’Univ . di Bologna),• un routing tra diversi autonomous systems.

Il routing all’interno della subnet è banale (* in teoria) perchè la subnet coincide con una rete fisica, che consente la consegna diretta tra le stazioni mediante una trasmissione broadcast. Serve solomappare indirizzi IP in indirizzi MAC con ARP e RARP.(*) In realtà la faccenda può complicarsi se si vuole minimizzare loscambio di pacchetti in reti fisiche costituite da più sottoreti fisiche collegate da bridge. Alcuni bridge intelligenti monitorano il trafficoa livello 2, memorizzando gli indirizzi MAC contenuti nei campi provenienza dei pacchetti di livello 2 che li attraversano. In tal modo capiscono automaticamente in che direzione sono collocati glihosts con quei MAC address, ed instradano i pacchetti MAC adessi destinati solo in quella direzione. I pacchetti broadcast sono invece propagati a tutti.

Il routing tra le subnet, cioè all’interno di un autonomous system ègestito dai router (detti Interior Router), mediante tabelle diinstradamento che possono essere scritte (in toto o in parte)manualmente dal gestore della rete o calcolate automaticamente conalgoritmi dei cosiddetti tipi distance vector o link state packet. Tra ipiù recenti ricordiamo OSPF (Open Shortest Path First) che effettua il bilanciamento di carico tra percorsi paralleli ed e’ standard.

Il routing tra autonomous systems risponde più ad esigenzeamministrative che non tecniche, ed è gestito con algoritmidetti Exterior Gateway Protocol, quali BGP (Border Gat. Prot.).

66

Routing Gerarchico

Il compito del livello transport (livello 4) è di fornire un trasporto efficace dall'host di origine a quello di destinazione, indipendentemente dalla rete utilizzata.

Questo è il livello in cui si gestisce per la prima volta (dal basso verso l'alto) una conversazione diretta, cioè senza intermediari, fra una transport entity su un host e la sua peer entity su un altro host..

Naturalmente, tali servizi sono realizzati dal livello transport per mezzo dei servizi ad esso offerti dal livello network.Così come ci sono due tipi di servizi di livello network, ce ne sono due anche a livello transport:• servizi affidabili orientati alla connessione, detti di tipo stream, offerti dal TCP (Transmission Control Protocol);• servizi senza connessione detti di tipo datagram offertidall’ UDP (User Datagram Protocol).

Il livello di Trasporto del TCP/IP

67

TSAP address

NSAP address

Liv. Applic.

Liv. Transport

Liv. Network

Transport Entity

Transport EntityTPDU

Quando si vuole trasferire una o più TPDU (Transport Protocol Data Unit) da una sorgente ad una destinazione di livello 4, occorre specificare mittente e destinatario di livello 4. Il protocollo di livello 4 deve quindi decidere come deve essere fatto l'indirizzo di livello transport, detto TSAP address (Transport Service Access Point address).Poichè l’indirizzo di livello 4 serve a trasferire informazioni tra applicazioni che lavorano su hosts diversi, deve poter individuare un host e una entità contenuta nell’host. Per questo motivo i protocolli di livello 4 tipicamente definiscono come indirizzo di livello 4 una coppia formata da un indirizzo di livello network che identifica l’host, e da un’altra informazione che identifica un punto di accesso in quell ’host (NSAP address, informazione supplementare).Ad esempio, in TCP/IP un TSAP address (ossia un indirizzo TCP o UDP) ha la forma:

( IP address : port number )Port number è un intero a 16 bit, che identifica un servizio o un punto di accesso e/o smistamento di livello 4.Ad es. la coppia (137.204.72.49 : 23) indica la porta 23 dell ’host poseidon.csr.unibo.it, cioè l’entry point per il demone telnet, cioè il punto di accesso all’applicazione che permette ad un utente di collegarsi mediante telnet all’host poseidon.• Anche se l’indirizzo di livello trasporto è formato da questa coppia, il TCP/IP, per ridurre l’overhead causato dagli header dei vari livelli, nella trasmissione effettua una violazione della stratificazionetra i livelli 4 e 3 (Trasporto e Network). Infatti, come vedremo TCP e UDP contengono nei loro header solo i numeri delle porte e riutilizzanogli indirizzi IP di mittente e destinaz. contenuti nel pacchetto IP.

Indirizzi a livello di Trasportoper il TCP/IP

68

• Gli identificatori di porta (port number) permettono di effettuare la demultiplazione dei pacchetti di livello 4, ovvero di discriminare l’applicazione destinazione dei pacchetti in funzio ne del port number contenuto nell’header del pacchetto di livello transport, sia esso di tipo TCP che UDP.• E’ ovvio che mittente e destinatario devono essere d’accordo su l valore della porta del destinatario per poter effettuare la trasmissione.• Il mittente scrive questo numero di porta come indirizzo del destinatario, ed il destinatario si deve mettere in attesa dei pacchetti che giungono all’host del destinatario e che posseggon o come identificatore proprio quel port number.• Alcune primitive fornite dall’interfaccia socket permettono di specificare il numero di porta di cui interessa ricevere i pacchetti (stream=flussi di dati nel caso TCP). E’ quindi il sistema opera tivo che si fa carico di effettuare le operazioni di demultiplexing dei pacchetti ricevuti dal livello network.

Multiplexing a livello Trasporto

69

• Il livello transport fornisce un protocollo per il trasporto diblocchi di dati non connesso e non affidabile, detto UDP (User Datagram Protocol), che utilizza l’IP per trasportare messaggi, che è molto simile all’IP in termini di risultato del trasporto, ed offre in più rispetto all’IP la capacità di distinguere tra piùdestinazioni all’interno di uno stesso host, mediante il meccanismo delle porte.•Ogni Datagram UDP viene incapsulato in un datagram IP, quindi la dimensione del datagram UDP non può superare la dimensione massima della parte dati del datagram IP. Il datagram IP puòessere frammentato se la MTU è piccola.

• L’UDP non usa dei riscontri per verificare se un messaggio èarrivato a destinazione, non ordina i messaggi arrivati, e non fornisce nessun tipo di controllo sulla velocità di trasmissione dei dati. Quindi i datagram UDP possono essere persi, duplicati o arrivare fuori ordine.• Utilizzano UDP alcuni protocolli standard, a cui sono riservati dei numeri di porte predefiniti, in modo da poter essere rintracciati nello stesso punto (punto d’accesso) su tutti gli hosts. Ricordiamo tra gli altri: nameserver (server di nomi di dominio, porta 53), bootps(server del protocollo di bootstrap, 67), tftp (Trivial File Transfer, 69), ntp (Network Time protocol, 123).

Il protocollo di Trasporto UDP (User Datagram Protocol)

70

IP header UDP header UDP data

20 bytes 8 bytes

UDP datagramIP datagram

Il pacchetto UDP è costituito da un header e da una parte dati.

L’header UDP è composto da 4 campi:• i primi due sono i numeri di porta del mittente e del destinatario del datagram, ciascuno di 16 bit.• il terzo è la lunghezza dei dati del datagram UDP, in byte.• l’ultimo è un checksum per il controllo d’errore, che però è opzionale. Un valore zero in questo campo indica che la chesksumnon è stata calcolata

Si noti che non ci sono gli indirizzi IP di mittente e destinatario.A differenza dell’header IP, il checksum contenuto nell’header UDP considera anche la parte dati UDP.Inoltre il calcolo della checksum viene effettuato ponendo in testa al datagram UDP una pseudointestazione (che non viene trasmessa), con gli indirizzi IP di provenienza e destinazione ricavata dall’header IP in cui l’UDP viene trasportato, pseudointestazione fatta in questo modo:

Il motivo di questo modo di computare la checksum è verificare a livello UDP, che il datagram UDP abbia raggiunto la corretta destinazione IP, che non compare nell’header UDP.

Formato del Datagram UDP

71

0 15 16 31

source port number destination port number

checksum UDPlength UDP

UDP data

UDPheader

0 15 16 31

source IP address

UDP datagram length

UDPpseudoheader

destination IP address

8-bit protocol (17)zero

esempio di trasmissionedi datagram UDP

72

Senza per ora entrare nei dettagli riguardanti i socket, vediamo unsemplice esempio di programma che sfrutta i socket per trasmettere undatagram UDP contenente una stringa di testo “pippo” da un hostsender 137.204.72.49 ad un host receiver 130.136.2.7 .Il punto di accesso stabilito dal programmatore è nel receiver, nella portaUDP caratterizzata dal numero 3001. Il receiver si mette in attesa sulla porta 3001 fino a che il sender inviaun datagram all’host receiver su quella porta, e stampa il conte nuto deldatagram ricevuto.Quindi sender e receiver devono essersi messi d’accordo sulla po rta dausare, ed il sender deve conoscere l’indirizzo IP del receiver.

Il codice completo (con la gestione degli errori) dei due programmiche realizzano l’esempio qui mostrato è disponibile allo indiriz zo http://www.cs.unibo.it/~ghini/didattica/sistemi3/UDP1/UDP1.html

data linkphysical

network

transport

application

3001

receiver

130.136.2.7

media

data linkphysical

network

transport

applicationsender

137.204.72.49

data

puntod’accesso

esempio: receiver di datagram UDP

73

/* eseguito sull’host 130.136.2.7 */#define SIZEBUF 10000void main(void) {struct sockaddr_in Local, From; short int local_port_number=3001;char string_remote_ip_address[100]; short int remote_port_number;int socketfd, OptVal, msglen, Fromlen; char msg[SIZEBUF];

/* prende un socket per datagram UDP */socketfd = socket (AF_INET, SOCK_DGRAM, 0);/* impedisce l'errore di tipo EADDRINUSE nella bind() */ OptVal = 1;setsockopt (socketfd, SOL_SOCKET, SO_REUSEADDR,

(char *)&OptVal, sizeof(OptVal) );/* assegna l'indirizzo IP locale e una porta UDP locale al socket */Local.sin_family = AF_INET;Local.sin_addr.s_addr = htonl(INADDR_ANY);Local.sin_port = htons(local_port_number);bind ( socketfd, (struct sockaddr*) &Local, sizeof(Local));

/* wait for datagram */Fromlen=sizeof(struct sockaddr);msglen = recvfrom ( socketfd, msg, (int)SIZEBUF, 0,

(struct sockaddr*)&From, &Fromlen);sprintf((char*)string_remote_ip_address,"%s",inet_ntoa(From.sin_addr);

remote_port_number = ntohs(From.sin_port);printf("ricevuto msg: \"%s\" len %d, from host %s, port %d\n",

msg, msglen, string_remote_ip_address, remote_port_number);}

esempio: sender di datagram UDP

74

/* eseguito sull’host 137.204.72.49 */int main(void) {struct sockaddr_in Local, To; char msg[]=“pippo";char string_remote_ip_address[]="130.136.2.7";short int remote_port_number = 3001;int socketfd, OptVal, addr_size;

/* prende un socket per datagram UDP */socketfd = socket(AF_INET, SOCK_DGRAM, 0);/* impedisce l'errore di tipo EADDRINUSE nella bind() */ OptVal = 1;setsockopt(socketfd, SOL_SOCKET, SO_REUSEADDR,

(char *)&OptVal, sizeof(OptVal));/* assegna l'indirizzo IP locale e una porta UDP locale al socket */Local.sin_family = AF_INET;/* il socket verra' legato all'indirizzo IP dell'interfaccia che verrà

usata per inoltrare il datagram IP, e ad una porta a scelta del s.o. */Local.sin_addr.s_addr = htonl(INADDR_ANY);Local.sin_port = htons(0); /* il s.o. decide la porta locale */bind( socketfd, (struct sockaddr*) &Local, sizeof(Local));/* assegna la destinazione */To.sin_family = AF_INET;To.sin_addr.s_addr = inet_addr(string_remote_ip_address);To.sin_port = htons(remote_port_number);addr_size = sizeof(struct sockaddr_in);/* send to the address */sendto(socketfd, msg, strlen(msg) , 0,

(struct sockaddr*)&To, addr_size);}

Il protocollo di Trasporto TCP (Transmission Control Protocol)

75

Il protocollo TCP è stato progettato per fornire un flusso di byte da sorgente a destinazione full-duplex, affidabile, su una rete non affidabile.Dunque, offre un servizio reliable e connection oriented, e si occupa di:• stabilire la connessione full duplex tra due punti di accesso a livello trasporto;• accettare dati dal livello application eventualmente bufferizzando in input;• a richiesta, forzare l’invio interrompendo la bufferizzazione;• spezzare o accorpare i dati in segment, il nome usato per i TPDU (Transport Protocol Data Unit) aventi dimensione massima 64 Kbyte, ma tipicamente di circa 1.500 byte;• consegnarli al livello network, per effettuare la trasmissione all’interno di singoli datagram IP, eventualmente ritrasmettendoli;• ricevere segmenti dal livello network;• rimetterli in ordine, eliminando buchi e doppioni;• consegnare i dati, in ordine, al livello application.• chiudere la connessione.

Il servizio effettua internamente la gestione di ack, il controllo del flusso e il controllo della congestione.Il servizio del TCP è di tipo orientato allo stream, ovvero trasporta un flusso di byte, il che significa che se anche la sorgente spedisce (scrive sul device) i dati a blocchi (es 1 KB poi 3 KB poi ancora 2 KB) la connessione non informa la destinazione su come sono state effettuate individualmente le scritture; la destinazione potrebbe ad es. leggere i dati a blocchi di 20 byte per volta.

• Come l’UDP, il TCP impiega numeri di porta di protocollo per identificare la destinazione finale all’interno di un host.• La situazione è però molto diversa rispetto all’UDP, in cui possiamo immaginare ogni porta come una sorta di coda a cui arrivano dei datagram delimitati, provenienti ciascuno da un mittente eventualmente diverso.• Per il TCP si vuole invece che una connessione sia dedicata in esclusiva ad una coppia di applicazioni risiedenti su macchine diverse. Il TCP impiega la connessione (virtuale), non la porta di protocollo, come sua astrazione fondamentale;

• le connessioni sono identificate da una coppia di punti d’accesso (endpoint) detti socket, uno su ciascuna macchina.

• Ogni socket è caratterizzato da una coppia ( IP address: Port number) che può essere utilizzata da più processi simultaneamente. Questa è ad esempio la situazione prodotta dal processo demone del telnet (telnetd) che consente agli utenti di una macchina unix A di collegarsi ad A da un’altro host accedendo tutti alla stessa porta TCP numero 23 di quell’host A. Tutte le connessioni condividono quindi la stessa coppia (IP_A, 23).

• Però ciascuna connessione viene univocamente individuata dalla coppia di socket dei due host A e B implicati nella connessione, ovvero dalla terna:( IP address A: Port number A , IP address B: Port number B )

Più utenti che effettuano tutti il telnet da una stessa macchina B verso una stessa macchina A instaurano connessioni identificate da terne del tipo ( IP_A : 23 , IP_B : tcp_port_B ) con tcp_port_Btutti diversi, e quindi con connessioni univocamentedeterminate.

Indirizzamento nel TCP (1)

76

Come per il caso UDP, anche per il TCP esistono dei port number che sono riservati ad uso di protocolli standard, e vengono dett i well-know-port. Queste porte sono quelle con valore inferiore a 256.

Port Number Service20 Ftp (control)21 Ftp (data)23 Telnet25 Smtp80 Http

I segmenti TCP• L’unità di trasferimento del TCP è detta segmento, e viene usato per stabilire connessioni, per trasferire dati, per inviare riscontri (una sorta di ricevuta di ritorno), per dimensionare le finestre scorrevoli e per chiudere le connessioni.• TCP usa un meccanismo di sliding window (finestre scorrevoli) di tipo go-back-n con timeout. Se questo scade, il segmento si ritrasmette. Si noti che le dimensioni della finestra scorrevole e i valori degli ack sono espressi in numero di byte, non innumero di segmenti.• ogni byte del flusso TCP è numerato con un numero d'ordine a 32 bit, usato sia per il controllo di flusso che per la gestione de gli ack;• ogni segmento TCP non può superare i 65.535 byte, e viene incluso in un singolo datagram IP;• un segmento TCP è formato da:

uno header, a sua volta costituito da:- una parte fissa di 20 byte;- una parte opzionale;

i dati da trasportare;

Well-Know-Port nel TCP

77

Formato del segmento TCP

78

Source port, destination port: identificano gli end point (locali ai due host) della connessione. Essi, assieme ai corrispondenti numeri IP, identificano la connessione a cui appartiene il segmento;

Sequence number: la posizione del primo byte contenuto nel campo dati all’interno dello stream di byte che il trasmettitore del segmento invia (si possono inviare quindi al max 4 miliardi di byte circa in uno stesso stream).

Ack. number: la posizione del prossimo byte aspettato all’interno del segmento inviato dal ricevitore del presente segmento.

TCP header length: lunghezza del segmento misurata in parole di 32 bit (necessario perché il campo options ha dimensione variabile).

Destination port

Sequence number

32 bit

Source port

Ack. number TCP

header len U R G

A C K

P S H

R S T

S Y N

F I N Window size

Options (zero o più parole di 32 bit)

Urgent pointer Checksum

Dati (opzionali)

reserved

Checksum, simile a quello di UDP, verifica che sia l’header che i dati del segmento siano arrivati a destinazione senza errori. Come per UDP il calcolo del checksum prevede che sia aggiunto in testa al segmento uno pseudoheader contenente gli indirizzi IP di sorgente e destinazione, la lunghezza del segmento, estratti dall’header del datagram IP che contiene il segmento.

Nell’header del segmento TCP sono presenti inoltre 6 flags di un bit ciascuno che servono per assegnare validità ad alcuni campi dell’header o per segnalare richieste o conferme:

URG 1 se il campo urgent pointer è usato, 0 altrimenti.ACK 1 se l'ack number è valido (cioè se si trasporta un ack), 0 altrimenti.PSH indica che questo segmento contiene dati urgenti (pushed

data), da consegnare senza aspettare che il buffer si riempia.RST richiesta di reset della connessione (ci sono problemi!).SYN usato nella fase di setup della connessione:

SYN=1 ACK=0 richiesta connessione;SYN=1 ACK=1 accettata connessione.

FIN usato per rilasciare una connessione.

Formato del segmento TCP (2)

79

0 15 16 31

source IP address

TCP segment length

TCPpseudoheader

destination IP address

8-bit protocol (=6)0

altri campi presenti nel segmento TCP sono:

Window size: il controllo di flusso è di tipo sliding window di dimensione variabile. Window size dice quanti byte possono essere spediti a partire da quello (compreso) che viene confermato con l'ack number. Un valore zero significa: fermati per un pò, riprenderai quando ti arriverà un uguale ack number con un valore di window size diverso da zero. Questo valore serve a ridurre la velocità di trasmissione dei dati nel flusso di byte che va dal ricevente al trasmettitore del presente segmento. Viene usato quando ci si accorge di una congestione della rete, per non incrementare ancora la congestione, oppure quando i buffer di ricezione sono ormai pieni e non si vuole rischiare di perdere dei dati .

Urgent pointer puntatore ai dati urgenti, indica la posizione in cui terminano i dati urgenti nello stream inviati dal trasmettitore.

Options contiene alcune opzioni appliccabili al flusso. Le piùimportante sono negoziabili durante il setup della connessione, e sono:• dimensione massima dei segmenti da spedire (MSS: Maximum Segment Size), serve se uno degli host ha dei buffer molto limitati ma soprattutto per adattare il segmento alla MTU della rete che collega i due host, in modo che ogni segmento venga incluso in un datagram IP che non debba essere frammentato;• uso di selective repeat invece che go-back-n (un diverso algoritmo di controllo del flusso);• uso di NAK.

Formato del segmento TCP (3)

80

Socket per TCP:Fondamenti

Molte applicazioni di rete sono formate da due programmi distinti (che lavorano su due diversi host) uno detto server ed uno detto client. Il server si mette in attesa di unarichiesta da servire, il clienteffettua tale richiesta.Tipicamente il client comunica conun solo server, mentre un serverusualmente comunica con piùclient contemporaneamente (suconnessioni diverse nel caso tcp).Inoltre spesso client e server sonoprocessi utente, mentre i protocollidella suite TCP/IP fanno solitamente parte del sistema operativo.Nel seguito faremo riferimento al termine IP nel senso di IPv4.

Unix StandardsPosix = Portable Operating System Interface è una famiglia di standard (vedi http://www.pasc.org/standing/sd11.html) sviluppata da IEEE e adottata da ISO. Posix comprende IEEE Std 1003.1 (1996)(una raccolta di alcune specifiche precedenti) che contiene al suo interno una parte detta “Part1: System Application Program Interface(API)” che specifica l’interfaccia C per le chiamate di sistema delkernel Unix, relative a processi (fork, exec, signal, timer, user ID, gruppi), files e directory (I/O function), I/O da terminale, password, le estensioni per il realtime, execution scheduling, semaphores, shared memory, clock, message queues. In particolare comprende IEEE Std1003.1g: Protocol Independent Interface (PII) che è lo standard per l’interfaccia di programmazione delle reti, e definisce due standard chiamati DNI (Detailed Network Interfaces): 1) DNI/Socket basato sulle API socket del 4.4BSD, di cui ci occuperemo2) DNI/XTI, basato sulle specifiche XPG4 del consorzio X/Open

Network Applications

86

Per primo viene fatto partire il server, poi viene fatto partire il client che chiede la connessione al server e la connessione viene instaurata. Nell’esempio (ma non è obbligatorio) il client spedisce una richiesta al server, questo risponde trasmettendo alcuni dati. Questa trasmissionebidirezionale continua fino a che uno dei due (il client nell’esempio)decide di interrompere la connessione,e tramite la close() chiude laconnessione. Infine il serverchiude a sua volta la connessione.

Interazioni tra Client e Server TCP

104

ephemeralport

Vediamo un semplice esempio di programma che sfrutta i socket TCP per instaurare una connessione tra un client e un server, trasmettere dal client al server una stringa di caratteri, aspettare che il server modifichi questi caratteri (tranne l’ultimo, lo’\0’ che delimita la stringa) shiftandoli di due posizioni (es: ‘a’ diventa ‘c’, ‘2’ diventa ‘4’) e li rispedisca indietro così traslati, infine stampare il risultato.Il server è l’host 130.136.2.7, mentre il client è l’host 137.204.72.49.Il punto di accesso del servizio di traslazione è la porta TCP 5001.

Il codice completo (con la gestione degli errori) dei due programmiche realizzano l’esempio qui mostrato è disponibile allo indirizzo http://www.cs.unibo.it/~ghini/didattica/sistemi3/TCP1/TCP1.html

esempio di trasmissione con TCP

114

data linkphysical

network

TCPtransport

application

5001

server

130.136.2.7

media

data linkphysical

network

TCPtransport

application

client

137.204.72.49

write

traslazionecaratteri

buf[i]=buf[i]+2

readwrite read

/* servTCP.c eseguito sull’host 130.136.2.7 */void main(void) {struct sockaddr_in Local, Client; short int local_port_number=5001;char buf[SIZEBUF]; int sockfd, newsockfd, n, nread, nwrite, len;

/* prende un socket per stream TCP */sockfd = socket (AF_INET, SOCK_STREAM, 0);/* collega il socket ad un indirizzo IP locale e una porta TCP locale */memset ( &Local, 0, sizeof(Local) );Local.sin_family = AF_INET;Local.sin_addr.s_addr = htonl(INADDR_ANY);Local.sin_port = htons(local_port_number);bind ( sockfd, (struct sockaddr*) &Local, sizeof(Local));/* accetta max 10 richieste simultanee di inizio conness., da adesso */listen(sockfd, 10 );/* accetta la prima conness. creando un nuovo socket per la conness. */newsockfd = accept(sockfd, (struct sockaddr*) &Cli, &len);/* riceve la stringa dal client */nread=0;while( (n=read(newsockfd, &(buf[nread]), MAXSIZE )) >0) {

nread+=n;if(buf[nread-1]=='\0') break; /* fine stringa */}

/* converte i caratteri della stringa */for( n=0; n<nread -1 ; n++) buf[n] = buf[n]+2;/* spedisce la stringa traslata al client */nwrite=0;while((n=write ( newsockfd, &(buf[nwrite]),nread-nwrite)) >0 )

nwrite+=n;/* chiude i socket */close(newsocketfd); close(socketfd);}

server TCP per l’esempio

115

/* cliTCP.c eseguito sull’host 137.204.72.49 */void main(void) {struct sockaddr_in Local, Serv; short int remote_port_number=5001;char msg[]="012345ABCD"; int sockfd, newsockfd, n, nread, nwrite, len

/* prende un socket per stream TCP */sockfd = socket (AF_INET, SOCK_STREAM, 0);/* collega il socket senza specificare indirizzo IP e porta TCP locali */memset ( &Local, 0, sizeof(Local) );Local.sin_family = AF_INET;Local.sin_addr.s_addr = htonl(INADDR_ANY);Local.sin_port = htons(0);bind ( sockfd, (struct sockaddr*) &Local, sizeof(Local));/* specifica l’indirizzo del server, e chiede la connessione */memset ( &Serv, 0, sizeof(Serv) );Serv.sin_family = AF_INET;Serv.sin_addr.s_addr = inet_addr ( string_remote_ip_address);Serv.sin_port = htons(remote_port_number);connect ( socketfd, (struct sockaddr*) &Serv, sizeof(Serv));/* spedisce la stringa al server */len = strlen(msg)+1; nwrite=0;while((len>nwrite)&&(n=write(socketfd,&(msg[nwrite]),len-nwrite))>0))

nwrite+=n;nread=0; /* riceve la stringa traslata dal server */while( (n=read(newsockfd, &(msg[nread]), MAXSIZE )) >0) {

nread+=n;if(buf[nread-1]=='\0') break; /* fine stringa */}

printf(“%s\n”, msg); /* stampa la stringa traslata *//* chiude i socket e termina*/close(socketfd);}

client TCP per l’esempio

116

Cominciamo la descrizione delle Socket API (Application program Interface) dalla descrizione delle strutture usate per trasferire indirizzi dall’applicazione al kernel (nelle funzioni bind, connect, sendto) e dal kernel alle applicazioni (nelle funzioni accept, recvfrom, getsockname e getpeername).

• I dati definiti per Posix.1g sono quelli della seguente tabella:int8_t signed 8-bit integer <sys/types.h>uint8_t unsigned 8-bit integer <sys/types.h >int16_t signed 16-bit integer <sys/types.h >uint16_t unsigned 16-bit integer <sys/types.h>int32_t signed 32-bit integer <sys/types.h>uint32_t unsigned 32-bit integer <sys/types.h>sa_family_t famiglia di indirizzi socket <sys/socket.h>

AF_INET per IPv4, AF_INET6 per IPv6,AF_LOCAL per indir. locali unix (per pipe ecc..)

socklen_t lunghezza della struttura checontiene l’indirizzo,di solito è un uint32_t <sys/socket.h>

in_addr_t indirizzo IPv4, = uint32 <netinet/in.h>in_port_t porta TCP o UDP, = uint16 <netinet/in.h>

• Poichè i socket devono fornire un’interfaccia per diverse famiglie di protocolli (IPv4, IPv6 e Unix), e poichè tali strutture vengono passate per puntatore, le funzioni di libreria presentano un argomento che è il puntatore alla generica struttura (struct sockaddr*), ma essendo diversa la struttura passata a seconda della famiglia di indirizzi usata, l’argomento passato deve essere convertito mediante il cast alla struttura (struct sockaddr*), ad es:

struct sockaddr_in server; /* IPv4 socket address structure */memset ( &server, 0, sizeof(server) ); /* azzero tutta la struttura */... riempimento dei dati della struttura server ...bind ( socketfd, ((struct sockaddrstruct sockaddr *)*)&server, sizeof(server) );

Socket Address Structures (1)

96

La generica struttura dell’indirizzo è dunque cosi definita:struct sockaddr {

uint8_t sa_len;sa_family_t sa_family;char sa_data[14];};

La famiglia di indirizzi Ipv4 (sa_family=AF_INET) usa la struttura:struct sockaddr_in {

uint8_t sin_len; /* lunghezza struttura */sa_family_t sin_family; /* = AF_INET */in_port_t sin_port; /*16-bit TCP UDP port, network byte ordered */struct in_addr sin_addr; /* 32-bit IPv4 address, network byte ordered */char sin_zero[8]; /* unused */

};construct in_addr { /* e’ una struttura per ragioni storiche */

in_addr_t s_addr ; /* 32-bit IPv4 address network byte ordered */};

• sa_len e sa_family si sovrappongono perfettamente a sin_len e sin_family rispettivamente, permettendo di leggere la costante di tipo sa_family_t e di capire che tipo di struttura si sta utilizzando.• il campo sin_len non è richiesto espressamente da Posix.1g, , e anche quando è presente non è necessario settarlo, se non per applicazioni dirouting, in quanto le principali funzioni in cui si passano indirizzi prevedono già un argomento in cui si passa (o riceve) la lunghezza della struttura indirizzo.• Il campo sin_zero non è usato, ma va sempre settato tutto a zero prima di passare una struttura che lo contiene. Di più, per convenzione, bisogna sempre settare TUTTA la struttura indirizzo tutta a zero prima di riempire i vari campi, usando la funzione memset().• memset ( &server, 0, sizeof(server) );

Socket Address Structures (2)

97

Confrontiamo alcune delle strutture usate per gli indirizzi:Socket Address Structure (3)

98

Poichè alcuni campi delle strutture di indirizzo (i numeri di porta o gli indirizzi IPv4 ad esempio) devono essere memorizzati secondo l’ordine per i bytes stabilito per la rete (network byte order), prima di assegnare alla struttura un valore di porta (16-bit) o un indirizzo IPv4 (32-bit) è necessario convertirlo dall’ordine dei byte per l’host all’ordine per la rete, utilizzando delle funzioni di conversione, i cui prototipi sono definiti nell’include <netinet/in.h>:

uint16_t htons (uint16_t host16bitvalue); /* Host TO Network Short */uint32_t htonl (uint32_t host32bitvalue); /* Host TO Network Long */

Viceversa, per convertire il valore di una porta o di un indirizzo IPv4, preso da una struttura di indirizzo, in un valore intero secondol’ordinamento dell’host si devono utilizzare le funzioni:

uint16_t ntohs (uint16_t net16bitvalue); /* Network TO Host Short */uint32_t ntohl (uint32_t net32bitvalue); /* Network TO Host Long */

Se l’ordinamento dell’host è corrispondente all’ordinamento di rete, queste funzioni sono implementate con delle macro nulle, cioè non modificano il dato.

Funzioni di Manipolazione dei ByteVediamo solo le funzioni portabili ovunque perche sono ANSI C.void *memset (void *dest, int c, size_t n_bytes);

setta al valore c un numero len di byte a partire da destvoid *memcpy (void *dest, const void *src, size_t n_bytes);

copia n_bytes byte da src a dest, problemi se c’e’ sovrapposizione, nel caso usare memmove. Resituisce dest.

void *memcmp (const void ptr1, const void *ptr2, size_t n_bytes);confronta due vettori di n_bytes ciascuno, restituisce 0 se sono uguali, diverso da zero se diversi.

Funzioni di Ordinamento dei Byte

99

Queste funzioni sono definite in <arpa/inet.h>Le funzioni inet_aton e inet_addr convertono gli indirizzi IP da una forma di stringa di caratteri ASCII decimali separati da punti del tipo “255.255.255.255”, nella forma di interi a 32-bit ordinati secondo l’ordinamento di rete.

int inet_aton (const char *str, struct in_addr *addrptr);scrive nella locazione puntata da addrptr il valore a 32-bit, nell’ordine di rete, ottenuto dalla conversione della stringa zero-terminata puntata da str. Restituisce zero in caso di errore, 1 se tutto va bene.

in_addr_t inet_addr (const char *str); NON VA USATArestituisce il valore a 32-bit, nell’ordine di rete, ottenuto dalla conversione della stringa zero-terminata puntata da str.In caso di errori restituisce INADDR_NONE, e questo è un casino,perchè INADDR_NONE è un intero a 32 bit di tutti 1, che sarebbe ottenuto come risultato della chiamata di inet_addr passandogli la stringa “255.255.255.255” che è l’indirizzo valido di broadcast.Per evitare confusione non deve essere usata.

Infine c’e’ una funzione che effettua la conversione inversa, da interi a 32-bit network ordered verso stringhe ASCII decimali separate da punti.char *inet_ntoa (struct in_addr addr);

scrive in una locazione di memoria statica (di cui restituisce un puntatore) la stringa ASCII null-terminata di caratteri decimali separati da punti corrispondeni all’indirizzo IP a 32-bit, nell’ordine di rete, contenuto nella struttura addr (che stranamente non è un puntatore). Occhio, questa funzione non è rientrante, perchèmemorizza il risultato in una locazione statica.

Funzioni di Conversione di Indirizzi IPdalla forma dotted-decimal ASCII stringalla forma 32-bit network byte ordered

100

La prima azione per fare dell’I/O da rete è la chiamata alla funziona socket() specificando il tipo di protocollo di comunicazione da utilizzare (TCP con IPv4, UDP con IPv6, Unix domain stream protocol per usare le pipe). #include <sys/socket.h>int socket (int family, int type, int protocol);restituisce un descrittore di socket maggiore o uguale a zero, oppure -1 in caso di errore, e setta errno.L’argomento family specifica la famiglia di protocolli da utilizzare.

family descrizioneAF_INET IPv4 protocolAF_INET6 IPv6 protocolAF_LOCAL Unix domain protocols (ex AF_UNIX)AF_ROUTE Routing socketAF_ROUTE Key socket (sicurezza in IPv6)

L’argomento type specifica quale tipo di protocollo vogliamo utilizzare all’interno della famiglia di protocolli specificata da family.

type descrizioneSOCK_STREAM socket di tipo stream (connesso affidabile)SOCK_DGRAM socket di tipo datagramSOCK_DRAW socket di tipo raw (livello network)

L’argomento protocol di solito è settato a 0, tranne che nel caso deisocket raw.

Non tutte le combinazioni di family e type sono valide. Quelle valide selezionano un protocollo che verrà utilizzato.

AF_KEYAF_INET AF_INET6 AF_LOCAL AF_ROUTE

SOCK_STREAM TCP TCP esisteSOCK_DGRAM UDP UDP esisteSOCK_DRAW IPv4 IPv6 esiste

funzione socket()

105

La funzione connect() è usata dal client TCP per stabilire la connessione con un server TCP.#include <sys/socket.h>int connect (int socketfd, const struct sockaddr *servaddr,

socklen_t addrlen);restituisce 0 se la connessione viene stabilita, -1 in caso di errore.• L’argomento socketfd è un descrittore socket ottenuto da una chiamata alla funzione socket().• L’argomento servaddr come visto in precedenza è in realtà per IPv4 un puntatore alla struttura sockaddr_in, e deve specificare l’indirizzo IP e il numero di porta del server da connettere.• L’argomento addrlen specifica la dimensione della struttura dati che contiene l’indirizzo del server servaddr, viene di solito assegnata mediante la sizeof(servaddr).

• Il client non deve di solito specificare il proprio indirizzo IP e la propria porta, perchè queste informazioni non servono a nessuno. Quindi può chiedere al sistema operativo di assegnargli una porta TCP qualsiasi, e come indirizzo IP l’indirizzo della sua interfaccia di rete, o dell’interfaccia di rete usata se ne ha più di una. Quindi NON SERVE la chiamata alla bind() prima della connect().• Nel caso di connessione TCP la connect inizia il protocollo three way handshake spedendo un segmento SYN. La funzione termina o quando la connessione è stabilita o in caso di errore.• In caso di errore la connect restituisce -1 e la variabile errno è settata a:- ETIMEDOUT nessuna risposta al segmento SYN- ECONNREFUSED il server risponde con un segmento RST (reset) ad

indicare che nessun processo server è in attesa(stato LISTEN) su quella porta

- EHOSTUNREACH o ENETUNREACH host non raggiungibile- ed altri ancora.

funzione connect()

106

La funzione bind() collega al socket un indirizzo locale. Per TCP e UDP ciò significa assegnare un indirizzo IP ed una porta a 16-bit.#include <sys/socket.h>int bind (int sockfd, const struct sockaddr *myaddr, socklen_t addrlen);restituisce 0 se tutto OK, -1 in caso di errore.• L’argomento sockfd è un descrittore ottenuto da una socket().• L’argomento myaddr è un puntatore alla struttura sockaddr_in, e specifica l’eventuale indirizzo IP locale e l’eventuale numero di porta locale a cui il sistema operativo deve collegare il socket.• L’argomento addrlen specifica la dimensione della struttura myaddr.

• L‘applicazione può collegarsi o no ad una porta.• Di solito il server si collega ad una porta nota (well know port). Fa eccezione il meccanismo delle RPC.• I client di solito non si collegano ad una porta con la bind.• In caso non venga effettuato il collegamento con una porta, ilkernel effettua autonomamente il collegamento con una porta qualsiasi (ephemeral port) al momento della connect (per il client) o della listen (per il server).

• L’applicazione può specificare (con la bind) per il socket un indirizzo IP di un’interfaccia dell’host stesso.

• Per un TCP client ciò significa assegnare il source IP address che verrà inserito negli IP datagram, spediti dal socket.• Per un TCP server ciò significa che verranno accettate solo le connessioni per i client che chiedono di connettersi proprio a quell’IP address. • Se il TCP client non fa la bind() o non specifica un IP addressnella bind(), il kernel sceglie come source IP address, nel momento in cui il socket si connette, quello della interfaccia di rete usata.• Se il server non fa il bind con un IP address, il kernel assegna alsocket come indirizzo IP locale quello contenuto nell’IP destination address del datagram IP che contiene il SYN segment ricevuto. 107

funzione bind() (1)

Chiamando la bind() si può specificare o no l’indirizzp IP e la porta, assegnando valori ai due campi sin_addr e sin_port della struttura sockaddr_in passata alla bind come secondo argomento.A seconda del valore otteniamo risultati diversi, che sono qui elencati, nella tabella che si riferisce solo al caso:

IP_address portsin_addr sin_port Risultatowildcard 0 il kernel sceglie IP address e portawildcard nonzero il kernel sceglie IP address, porta fissataLocal IP Address 0 IP address fissato, kernel sceglie la portaLocal IP Address non zero IP address e porta fissati dal processo

Specificando il numero di porta 0 il kernel sceglie collega il socket ad un numero di porta temporaneo nel momento in cui la bind() è chiamata.Specificando la wildcard (mediante la costante INADDR_ANY per IPv4) il kernel non sceglie l’indirizzo IP locale fino a che o il socket è connesso (se TCP) o viene inviato il primo datagram per quel socket (se UDP).

L’assegnazione viene fatta con le istruzioni:struct sockaddr_in localaddr;localaddr.sin_addr.s_addr = htonl(INADDR_ANY);localaddr.sin_port = htons(port_number);

Se con la bind si lascia al kernel la scelta di IP address locale o port number locale, una volta che il kernel avrà scelto, si potrà sapere quale IP address e quale port number è stato scelto mediante la funzionegetsockname().

108

funzione bind() (2)

La funzione listen è chiamata solo dal TCP server e esegue due azioni:1) ordina al kernel di far passare il socket dallo stato iniziale CLOSED allo stato LISTEN, e di accettare richieste di inizio connessione per quel socket, accodandole in delle code del kernel.2) specifica al kernel quante richieste di inizio connessione può accodare al massimo per quel socket.#include <sys/socket.h>int listen (int socketfd, int backlog );restituisce 0 se tutto OK, -1 in caso di errore.• L’argomento socketfd è un descrittore ottenuto da una socket().• L’argomento backlog è un intero che specifica quante richieste di inizio connessione (sia connessioni non ancora stabilite, cioè che non hanno ancora raggiunto lo stato ESTABLISHED, sia connessioni stabilite) il kernel può mantenere in attesa nelle sue code.• Quando un segmento SYN arriva da un client, se il TCP verifica che c’è un socket per quella richiesta, crea una nuova entry in una coda delle connessioni incomplete, e risponde con il suo FIN+ACK secondo il 3-way handshake. L’entry rimane nella coda fino a che il 3-way è terminato o scade il timeout.• Quando il 3-way termina normalmente, la connessione viene instaurata, e la entry viene spostata in una coda delle connessioni completate.• Quando il server chiama la accept, la prima delle entry nella coda delle connessioni completate viene consegnata alla accept() che ne restituisce l’indice come risultato, ovvero restituisce un nuovo socketche identifica la nuova connessione.• Se quando il server chiama la accept(), la coda delle connessioni completate è vuota, la accept resta in attesa.• L’argomento backlog specifica il numero totale di entry dei due tipi di code.• Solitamente si usa 5, per http daemon si usano valori molto grandi. 109

funzione listen()

La funzione accept è chiamata solo dal TCP server e restituisce la prima entry nella coda delle connessioni già completate per quel socket. Se la coda è vuota la accept resta in attesa.#include <sys/socket.h>int accept (int socketfd, struct sockaddr *cli_addr,

socklen_t *ptraddrlen);restituisce un descrittore socket >=0 se tutto OK, -1 in caso di errore.

L’argomento socketfd è un descrittore ottenuto da una socket() e in seguito processato da bind() e listen(). E’ il cosiddetto listening socket, ovvero il socket che si occupa di insturare le connessioni con i client che lo richiedono, secondo le impostazioni definite dalla bind() e dallalisten(). Tale listening socket viene utilizzato per accedere alla coda delle connessioni instaurate come visto per la listen().• L’argomento cli_addr è un puntatore alla struttura sockaddr_in, su cui la funzione accept scrive l’indirizzo IP del client e il numero di porta del client, con cui è stata instaurata la connessione a cui si riferisce il socket che viene restituito come risultato .• L’argomento ptraddrlen è un puntatore alla dimensione della struttura cli_addr che viene restituita.

Se accept termina correttamente restituisce un nuovo descrittore di socket che è il connected socket, cioè si riferisce ad una connessione instaurata con un certo client secondo le regole del listening socket socketfd passato come input. Il connected socket verrà utilizzato per scambiare i dati nella nuova connessione.Il listening socket socketfd (il primo argomento) mantiene anche dopo la accept le impostazioni originali, e può essere riutilizzato in una nuovaaccept per farsi affidare dal kernel una nuova connessione.

110

funzione accept()

La funzione close è utilizzata normalmente per chiudere un descrittore di file, è utilizzata per chiudere un socket e terminare una connessione TCP.int close (int socketfd);restituisce 0 se tutto OK, -1 in caso di errore.L’argomento socketfd è un descrittore di socket.

• Normalmente la chiamata alla close() fa marcare “closed” il socket, e la funzione ritorna il controllo al chiamante. Il socket allora non può più essere usato dal processo, ovvero non può più essere usato come argomento di read e write.• Però il TCP continua ad utilizzare il socket trasmettendo i dati che eventualmente stanno nel suo buffer interno, fino a che non sono stati trasmessi tutti. In caso di errore (che impedisce questa trasmissione) successivo alla close l’applicazione non se ne accorge e l’altro end system non riceverà alcuni dei dati.• Esiste un’opzione però (la SO_LINGER socket option) che modifica il comportamento della close, facendo in modo che la close restituisca il controllo al chiamante solo dopo che tutti i dati nei buffer sono stati correttamente trasmessi e riscontrati.

• Se un socket connesso sockfd è condiviso da più processi (padre e figlio ottenuto da una fork), il socket mantiene il conto di quanti sono i processi a cui appartiene. In tal caso la chiamata alla close(sockfd) per prima cosa decrementa di una unità questo contatore, e non innesca la sequenza FIN+ACK+FIN+ACK di terminazione della connessione fino a che tale contatore è maggiore di zero, perchèesiste ancora un processo che tiene aperta la connessione.• Per innescare veramente la sequenza di terminazione, anche se ci sono ancora processi per quella connessione si usa la funzione shutdown().

111

funzione close()

La funzione getsockname serve a conoscere l’indirizzo di protocollo (IP e port number) dell’host locale associato ad un certo descrittore di socket connesso.int getsockname ( int socketfd, struct sockaddr *Localaddr,

socklen_t *ptr_addrlen );restituisce 0 se tutto OK, -1 in caso di errore.

Il primo argomento socketfd è un descrittore di socket connesso.Il secondo argomento Localaddr è un puntatore ad una struttura di tipo sockaddr, in cui la funzione metterà l’indirizzo locale della connessione.Il terzo argomento ptr_addrlen è un puntatore ad intero in cui la funzione metterà la dimensione della struttura scritta.

Questa funzione viene utilizzata in varie situazioni:

In un client, dopo una connect se non è stata effettuata la bind, e quindi non si è specificato nessun indirizzo: in tal caso getsocknamepermette di conoscere l’indirizzo IP e la porta assegnati dal kernel alla connessione.

In un client dopo una bind in cui come port number è stato specificato il valore 0, con il quale si è informato il kernel di scegliere lui la porta. In tal caso la getsockname restituisce il numero di porta locale assegnato dal kernel.

In un server multihomed, dopo una accept preceduta da una bind in cui come indirizzo IP LOCALE è stata messa la wildcardINADD_ANY, ciòè una volta che si sia stabilita una connessione, lagetsockname permette al server di sapere quale indirizzo IP ha la propria interfaccia di rete utilizzata per la connessione.

112

funzione getsockname()

La funzione getpeername serve a conoscere l’indirizzo di protocollo (IP e port number) dell’host remoto associato ad un certo descrittore di socket connesso.int getpeername ( int socketfd, struct sockaddr *Remoteaddr,

socklen_t *ptr_addrlen );restituisce 0 se tutto OK, -1 in caso di errore.

Il primo argomento socketfd è un descrittore di socket connesso.Il secondo argomento Remoteaddr è un puntatore ad una struttura di tipo sockaddr, in cui la funzione metterà l’indirizzo remoto della connessione.Il terzo argomento ptr_addrlen è un puntatore ad intero in cui la funzione metterà la dimensione della struttura scritta.

113

funzione getpeername()

I socket TCP, una volta che la connessione TCP sia stata instaurata, sono accedibili come se fossero dei file, mediante un descrittore di file (un intero) ottenuto tramite una socket() o una accept() o una connect(). Con questo descrittore è possibile effettuare letture tramite la funzione read, che restituisce i byte letti dal flusso in entrata, e scritture tramite le funzioni write e send, che spediscono i byte formando il flusso in uscita.

ssize_t read (int fd, void *buf, size_t count);cerca di leggere count byte dal file descriptor fd, scrivendoli nel buffer puntato da buf. Se count è zero la read restituisce zero. Se count è maggiore di zero viene effettuata la lettura e viene restituito il numero di byte letti (maggiore di zero, se tutto è OK).- Se viene restituito 0 (zero) significa end-of-file (fine stream), ovvero significa che l’altro end system ha volutamente chiuso laconnessione e quindi il socket non potrà essere più utilizzato per leggere.- Se viene restituito -1 è accaduto un errore e viene settata la variabile globale errno definita in <errno.h> con un valore che indica quale errore è avvenuto. In particolare, se errno vale EINTRsignifica che il sistema operativo ha dovuto interrompere la system call read, ma il socket non è in stato di errore, quindi la read può essere ripetuta immediatamente con gli stessi parametri. Altro caso particolare è quando il socket è stato definito non bloccante nel qual caso se non ci sono byte disponibili viene restituito EAGAIN, ed il socket rimane utilizzabile. Se invece errno ha un altro valore (EBADF, EINVAL, EFAULT, …) il socket viene invalidato.

La funzione read, applicata ad un socket, presenta una particolarità. Può accadere che la read() restituisca meno byte di quanti richiesti, anche se lo stream è ancora aperto. Ciò accade se il buffer a disposizione del socket nel kernel è stato esaurito. Sarà necessario ripetere la read(richiedendo il numero dei byte mancanti) fino ad ottenerli tutti. Oss.: ssize_t è definito in <unistd.h> ed è un long.

I/O su Socket TCP: read()

101a

I/O su Socket TCP: write() (1)

101b

ssize_t write (int fd, const void *buf, size_t count);

cerca di scrivere fino a count byte nel buffer di sistema corrispondente al file descriptor fd perché siano poi trasmessi. I byte vengono letti dal buffer puntato da buf. - Se count è zero la write restituisce zero e non scrive nulla. - Se count è maggiore di zero viene effettuata la scrittura e viene restituito il numero di byte scritti. - Se viene restituito -1 è accaduto un errore e viene settata la variabile errno con un valore che indica l’errore.

- Se il socket è configurato in modalità bloccante (è il default) la write è bloccante, cioè attende fino a che tutti i byte sono stati passati al buffer di sistema. Ciò significa che se non c’è abbastanza spazio nel buffer di sistema la write attende fino a che non sono stati spediti abbastanza byte da permettere la scrittura di tutti i byte passati. Durante questa attesa può capitare che al processo arrivi un segnale (es SIGUSR1) che deve essere gestito dal processo stesso; in tal caso la write termina restituendo il numero di byte scritti sul buffer di sistema. Se invece nessun byte è stato ancora scritto viene restituito -1 e indicato l’errore EINTR.- Se invece il socket è configurato in modalità non bloccante la write scrive sul buffer di sistema il maggior numero di byte possibile senza produrre attesa e poi termina restituendo il numero di byte scritti. Se non è stato possibile scrivere nulla la writerestituisce -1 senza attendere e setta errno al valore EAGAIN.

Altri possibili errori sono EBADF (file descriptor non valido), EINVAL (file descriptor non permette scritture), EFAULT (il buffer buf è fuori dallo spazio di memoria permesso), EPIPE (il socket è stato chiuso dall’altro end system).

Indipendentemente da come i socket sono stati settati, nel momento in cui viene invocata la write può capitare che il processo venga terminato dall’arrivo di un segnale SIGPIPE che viene generato dalla write stessa per indicare che il socket che si sta usando è stato chiuso in modo anormale dall’altro end system (inviando un segmento col flagreset) o che non è più utilizzabile.

Per impedire la terminazione del processo ho due diverse possibilità:

1) istruire il processo per far intercettare i segnali SIGPIPE, nel qual caso la write invece di inviare il segnale restituirà -1 indicando come errore EPIPE.

// da eseguire solo una volta, in fase di setup del processoif( signal(SIGPIPE, SIG_IGN) == SIG_ERR )

{perror("signal SIGPIPE failed: ");exit(1);}…..// poi si possono fare tutte le chiamate alla writeris=write(socketfd, buff, n);if(ris<0){

if(errno==EPIPE) { printf(“chiusura anomala\n”);exit(1); }……

}Così però intercetto tutti i segnale SIGPIPE indipendentemente da quale socket (usato dal processo) lo provoca.

2) utilizzare al posto della write la system call send, in cui può essere specificato di non generare il segnale SIGPIPE ma di restituire -1 indicando come errore EPIPE.In questo modo, solo il segnale SIGPIPE di quella particolare invocazione viene intercettato.

I/O su Socket TCP: write() (2)

101c

I/O su Socket TCP: send() (3)

101d

int send (int fd, const void *buf, size_t count, int flags);

cerca di scrivere fino a count byte nel buffer di sistema corrispondente al file descriptor fd perché siano poi trasmessi.I byte vengono letti dal buffer puntato da buf.

- Se count è zero la send restituisce zero e non scrive nulla.

- Se count è maggiore di zero viene effettuata la scrittura e viene

restituito il numero di byte scritti. - Se viene restituito -1 è accaduto un errore e

viene settata lavariabile errno con un valore che indica

l’errore.

Il comportamento viene influenzato dal valore del parametro flags, il cui valore può essere 0 oppure viene assegnato mediante OR bit a bit delle seguenti costanti: MSG_OOB, MSG_DONTWAIT, MSG_NOSIGNAL.Se il valore di flags è zero la send si comporta come la write.

Se viene specificato MSG_DONTWAIT la send non si blocca bensì scrive il numero di byte possibili nel buffer di sistema etermina restituendo il numero di byte scritti, eventualmente zero.Se viene specificato MSG_NOSIGNAL la send non solleva l’eccezione di tipo SIGPIPE e quindi non rischia di far terminare il processo. Al contrario, in caso di chiusura anormale della connessione, restituisce -1 e setta la variabile errno al valore EPIPE.

I/O su Socket TCP: (2)

TCP Output

102

Ogni socket TCP possiede un buffer per l’output (send buffer) in cui vengono collocati temporaneamente i dati che dovranno essere trasmessi mediante la connessione instaurata. La dimensione di questo buffer può essere configurata mediante un’opzione SO_SNDBUF.Quando un’applicazione chiama write() per n bite sul socket TCP, il kernel cerca di copiare n byte dal buffer dell’appl. al buffer del socket. Se il buffer del socket e’ più piccolo di n byte, oppure è già parzialmente occupato da dati non ancora trasmessi e non c’è spazio sufficiente, verranno copiati solo nc<n byte, e verrà restituito dalla write il numero nc di byte copiati.Se il socket ha le impostazioni di default, cioè è di tipo bloccante, la fine della routine write ci dice che sono stati scritti sul buffer del socketquegli nc byte, e possiamo quindi riutilizzare le prime nc posizioni del buffer dell’applicazione. Ciò non significa affatto che già i dati siano stati trasmessi all’altro end-system.

Per attendere di ricevere almeno un byte, o leggere i byte già arrivati, si usa la già descrittassize_t read (int fd, void *buf, size_t n);

Per attendere di ricevere TUTTI i byte richiesti, si implementa la seguente funzione readn, che

-restituisce -1 in caso di errore, e setta errno-restituisce il numero di byte letti se l’altro end system chiude la connessione- restituisce il numero di byte chieste (e letti) se tutto ok.

ssize_t readn (int fd, char *buf, size_t n){

size_t nleft; ssize_t nread;

nleft = n;while (nleft > 0) {

if ( (nread = read(fd, buf+n-nleft, nleft)) < 0) {if (errno != EINTR)

return(-1); // restituisco errore}else if (nread == 0) {

// EOF, connessione chiusa, termino// esce e restituisco il numero di byte letti break;

}else // continuo a leggere

nleft -= nread;}return(n - nleft); // return >= 0

}

I/O su Socket TCP : utility (1)

103a

I/O su Socket TCP : utility (2)Per attendere di consegnare al buffer di sistema TUTTI i byte richiestirestituisce -1 in caso di errore e setta errnorestituisce il numero di byte da inviare ed inviati, se tutto OK.

ssize_t writen (int fd, const char *buf, size_t n){

size_t nleft; ssize_t nwritten; char *ptr;

ptr = buf; nleft = n;while (nleft > 0) {

if ( (nwritten = send(fd, ptr, nleft, MSG_NOSIGNAL )) < 0) {if (errno == EINTR) nwritten = 0; /* and call write() again*/else return(-1); /* error */

}nleft -= nwritten; ptr += nwritten;

}return(n);

}

Per consegnare da zero ad n byte da trasmettere, ma senza attendere:restituisce -1 in caso di errore, se no restituisce il numero di byte scrittissize_t write_nowait (int fd, const char *buf, size_t n){

int nwritten;

do {nwritten=send ( fd, buf, n, MSG_DONTWAIT|MSG_NOSIGNAL);

}while( (nwritten<0) && (errno==EINTR) );return(nwritten);

} 103b

Per primo viene fatto partire il server, poi viene fatto partire il client che chiede la connessione al server e la connessione viene instaurata. Nell’esempio (ma non è obbligatorio) il client spedisce una richiesta al server, questo risponde trasmettendo alcuni dati. Questa trasmissionebidirezionale continua fino a che uno dei due (il client nell’esempio)decide di interrompere la connessione,e tramite la close() chiude laconnessione. Infine il serverchiude a sua volta la connessione.

Interazioni tra Client e Server TCP

104

ephemeralport

La funzione fork è usata per duplicare un processo.

#include <unistd.h>pid_t fork (void);

• restituisce -1 in caso di errore. Se tutto va a buon fine restituisce 0 nel processo figlio ed un valore maggiore di zero (il pid process identifier) nel processo padre.

• Questa funzione viene chiamata nel processo (padre=parent), e restituisce il risultato in due diversi processi (padre e figlio).

• Se il figlio vuole conoscere il pid del padre userà la funzione getppid().

• I descrittori di file e di socket aperti dal padre prima della forksono condivisi col figlio, e possono perciò essere usati da entrambi per l’I/O.

• Inoltre, per come funziona la funzione close(), è possibile per uno dei processi (padre o figlio) chiudere una connessione aperta condivisa(dai due processi) senza con questo impedire all’altro processo di continuare ad utilizzare la connessione.

• La fork viene usata per generare delle repliche del processo server, per gestire in parallelo le connessioni che via via vengono instaurate.

funzione fork()

117

• Un server banale in attesa su una porta TCP serializza le varie richieste di apertura di una connessione dei client permettendo la connessione ad un solo client per volta.• Server TCP più evoluti invece, come i web server, una volta risvegliati dalla richiesta di una connessione da parte di un client, effettuano una fork() duplicando se stessi (il processo). Il processo figlio viene dedicato a servire la connessione appena instaurata, il processo padre attende nuove richieste di connessione sulla stessa porta.

A livello di interfaccia socket, questa situazione si ottiene così:• Il server chiama la accept passando come argomento il socket listening (socket in ascolto), e subito dopo chiama la fork.• il processo padre chiude il connected socket, e ripete la accept sullistening socket, in attesa della prossima richiesta di connessione. • Invece il descrittore del connected socket (socket connesso) restituito dalla accept resta aperto per il figlio, e viene utilizzato da questo utilizzato per gestire l’I/O con la connessione. Quando infine il figlio termina il suo lavoro e chiude il connected socket con la close(), la connessione viene finalmente terminata con la sequenza di FIN.

pid_t pid; int listenfd, connfd;listenfd = socket (AF_INET, SOCK_STREAM, 0);bind ( listenfd, (struct sockaddr*) &Local, sizeof(Local));listen(listenfd, 10 );for( ; ; ) {

connfd = accept ( listenfd, (struct sockaddr*) &Cli, &len);pid = fork();if ( pid !=0) close(connfd); /* processo padre */else { /* processo figlio */

close(listenfd);usa_nuova_connessione_indicata_da_newsockfd(connfd);close(connfd); exit(0);

}}

Server TCP Concorrenti (1)

118

Vediamo graficamente cosa capita a livello di TCP e di porte.Entriamo un pò nei dettagli del programma appena visto, per quanto riguarda la scelta delle porte.Consideriamo la situazione più complicata, quella di un’applicazione server collocata su un host con più interfacce di rete, che vuole permettere le connessioni su una certa porta convenzionale (la 6001) da parte di client che accedono a una qualsiasi delle due interfaccedel server.

listenfd = socket (AF_INET, SOCK_STREAM, 0);/* collega il socket ad un indirizzo IP locale e una porta TCP locale */memset ( &Local, 0, sizeof(Local) );Local.sin_family = AF_INET;

Local.sin_addr.s_addr = htonl(INADDR_ANY); /* wildcard */Local.sin_port = htons(6001);

bind ( listenfd, (struct sockaddr*) &Local, sizeof(Local));/* accetta max 100 richieste simultanee di inizio conness., da adesso */ listen(listenfd, 100 );/* accetta la prima conness. creando un nuovo socket per la conness. */for( ; ; ){

connfd = accept(listenfd, (struct sockaddr*) &Cli, &len);pid = fork();if ( pid !=0 ) /* processo padre */

close ( connfd );else { /* processo figlio */

close ( listenfd ); /* chiuso il listening socket */il figlio usa il connected socket ()close ( connfd );exit(0);

}}

119

Server TCP Concorrenti (2)

120

La quaterna (IP locale, Port Number locale , IP remoto, Port Number remoto)che identifica univocamente una connessione TCP viene di solito chiamata socket pair.

SERVER CLIENTIP = IP_A1 IP = IP_BIP = IP_A2 port = 2222

Server TCP Concorrenti (3)

listening socket( *, 6001 , * , * )

connected socket( IP_A2, 6001 , IP_B , 2222 )

IP_A2IP_A1

listening socket( *, 6001 , * , * )

IP_A1 IP_A2

dopo la listen(), prima della accept()

dopo la accept() , prima della fork()

121

Server TCPConcorrenti

(4)listening socket( *, 6001 , * , * )

connected socket( IP_A2, 6001 , IP_B , 2222 )

IP_A2IP_A1

listening socket( *, 6001 , * , * )

IP_A1 IP_A2

dopo la fork()

dopo la close(connfd) del padre, e la close(listenfd) del figlio

connected socket( IP_A2, 6001 , IP_B , 2222 )

padre

figlio

padre

figlio

Un’applicazione di rete può avere la necessità di accedere contemporaneamente a più tipi di input e di output, ad es. input di tipo stream dalla tastiera, input di tipo stream da rete eventualmente da più connessioni contemporaneamente, input di tipo datagram da rete anch’esso eventualmente da più socket contemporaneamente.Esistono vari modelli di I/O disponibili in ambiente Unix:

I/O BloccanteI/O Non BloccanteI/O tramite MultiplexingI/O guidato da signalI/O asincrono (per ora poco implementato)

Consideriamo per ora il modello di I/O standard, per cui quando viene effettuata una richiesta di I/O mediante una chiamata ad una primitiva di tipo read() o write(), la primitiva non restituisce il controllo al chiamante fino a che l’operazione di I/O non è stata effettuata, ovvero o la read() ha letto da un buffer del kernel dei dati, o la write() ha scritto dei dati dell’utente in un buffer del kernel.Le funzioni di I/O finora analizzate sono state descritte nel loro funzionamento proprio secondo la modalità standard (bloccante).

• Il problema è che, quando l’applicazione effettua una read su un certo descrittore di file o di socket, se i dati non sono già presenti nella coda del kernel dedicata a quel descrittore, l’applicazione rimane bloccata fino a che i dati non sono disponibili, ed è impossibile leggere dati eventualmente già pronti sugli altri descrittori di file o socket.Analogamente per la write() se i buffer del kernel in cui si deve scrivere il dato è già occupato.

• Un problema analogo, caratteristico dei socket, si ha quando l’applicazione effettua una chiamata alla funzione accept(), che restituisce il controllo solo quando una richiesta di inizio connessione è disponibile (o meglio è già stata soddisfatta ed è nella coda delle connessioni stabilite).

I/O Multiplexing

122

Quello che serve è un modo di ordinare al kernek di avvertirci quando, in un insieme di canali di I/O, si verifica una condizione di disponibilità all’I/O, che può essere così definita:1) o dei dati sono pronti alla lettura in una coda del kernel, e si può accedere mediante una read che restituirà immediatamente il controllo al chiamante con i dati letti,2) o una coda di output del kernel si è svuotata ed è pronta ad accettare dati in scrittura mediante una write,3) o si è verificato un errore in uno dei dispositivi di I/O e quindi una read() o write() restituirebbe il valore -1, 4) o quando un socket listening è disponibile a fornire immediatamente un connected socket in risposta ad una chiamata di tipo accept(), perchèha ricevuto una richiesta di connessione da un client,

Posix.1g mette a disposizione una primitiva, detta select(), che:

1) permette di effettuare attesa contemporaneamente su più tipi di canali di I/O in modo da essere risvegliati quando uno di questi canali è disponibile all’I/O in lettura o scrittura o ha verificato un errore, o ancora nel caso dei socket quando sono disponibili i cosiddetti dati fuori banda (usati solo in casi particolarissimi perchè meno utili di quanto il nome farebbe presupporre),

2) e permette di fissare un limite all’attesa, in modo da essere risvegliati se non accade nulla allo scadere di un certo tempio limite. Quest’ultima possibilità può collassare in un’attesa di durata nulla, ovvero permette di non effettuare attesa alcuna, ma solo di controllare lo stato istantaneo dei vari canali e restituire subito il controllo al chiamante.

I/O Multiplexing

123

124

La funzione select permette di chiedere al kernel informazioni sullo stato di descrittori di tutti i tipi, riguardo a loro disponibilità in lettura scrittura o condizioni eccezionali, e di specificare quanto tempo al massimo aspettare.#include <sys/select.h>int select ( int maxfdp1, fd_set *readset, fd_set *writeset,

fd_set *exceptset, const struct timeval *timeout);La funzione restituisce -1 in caso di errore,0 se il timeout fissato è scaduto,altrimenti restituisce il numero di descrittori che hanno raggiunto la condizione di disponibilità loro richiesta.

L’ultimo argomento timeout dice al kernel quanto aspettare al massimo, ed è una struttura così fatta:

struct timeval {long tv_sec; /* secondi */long tv_usec; /* microsecondi */

}con questa struttura noi possiamo specificare alla select:attesa infinita: attesa fino a che una delle condizioni si è verificata. Si passa un puntatore timeout nullo.attesa limitata: attesa il numero di secondi e microsecondi specificati nella struttura puntata dal puntatore timeout passato. In caso di timeoutla select restituisce 0.attesa nulla: ritorna subito al chiamante dopo avere fotografato la situazione dei descrittori. SI specifica settando a zero tv_sec e tv_usec.

NB: la timeval specifica microsecondi, ma i kernel non riescono a discriminare solitamente sotto i 10 msec.

funzione select()

125

int select ( int maxfdp1, fd_set *readset, fd_set *writeset, fd_set *exceptset, const struct timeval *timeout);

I tre argomenti centrali di tipo fd_set*, readset writeset exceptsetspecificano i descrittori che si vuole controllare rispetivamente per verificare disponibilità alla lettura scrittura o eccezioni (out of band data only).

Il tipo fd_set (descriptor set) è un array di interi, in cui ogni bit corrisponde ad un descrittore. Se il bit è settato il descrittore viene considerato appartenente al set, altrimenti non vi appartiene.Esistono delle macro per settare o resettare gli fd_set.void FD_ZERO (fd_set *fdset); clear di tutti i bit di fd_setvoid FD_SET ( int fd, fd_set *fdset); setta il bit fd in fd_setvoid FD_CLR ( int fd, fd_set *fdset); clear del bit fd in fd_setint FD_ISSET ( int fd, fd_set *fdset); !=0 se il bit fd è settato in fd_set

0 se il bit fd non è settatoCon queste macro posso settare pulire e controllare l’appartenenza o meno di un descrittore all’insieme. Es.:

fd_set readset; dichiaro la variabile fd_set

FD_ZERO ( &readset ); inizializzo, azzero tutto,insieme vuoto

FD_SET ( 1, &readset ); 1 appartiene all’insiemeFD_SET ( 4, &readset ); 4 “FD_SET ( 7, &readset );

FD_ISSET ( 4, &readset ) restituisce != 0FD_ISSET ( 3, &readset ) restituisce 0

Ricordarsi di inizializzare il set (FD_ZERO) altrimenti risultati impredicibili.

funzione select() (2)

int select ( int maxfdp1, fd_set *readset, fd_set *writeset, fd_set *exceptset, const struct timeval *timeout);

Il primo argomento maxfdp1, specifica quali descrittori controllare, nel senso che deve avere il valore più alto tra i descrittori settati + 1.Es.: se i descrittori settati sono 1, 4 , 7 maxfdp1 deve essere 8 = 7+1

I 3 descrittori di set passati per argomento contengono quindi idescrittori da controllare, e vengono passati per puntatore perchè la select li modifica scrivendoci sopra il risultato.Quando la select termina si controllano ciascuno dei 3 fd_set, chiedendo tramite la macro FD_ISSET() quali descrittori sono settati.Se un descrittore (es. 4) non è settato (es. FD_ISSET(4, &readset )== 0) significa che non è pronto.Se invece il descrittore è settato (es. FD_ISSET(4, &readset ) != 0) significa che è pronto.

• Il valore restituito dalla select dice quanti descrittori sono statisettati.• se la select restituisce 0 significa che è scaduto il timeout.• se la select restituisce -1 c’e’ stato un errore o è avvenuta unasignal.

N.B. esiste una define che specifica la costante FD_SETSIZE ovvero il numero di descrittori che può contenere la struttura fd_set.

Vediamo ora un esempio di uso della select, con cui implementiamo unweb server, che lavora in parallelo senza dover fare delle fork().

126

funzione select() (3)

Prima parte del server, inizializzazione:typedef SA struct sockaddr;

int main(int argc, char **argv){int i, maxi, maxfd, listenfd, connfd, sockfd;int nready, client[FD_SETSIZE];ssize_t n;fd_set rset, allset;char line[MAXLINE];socklen_t clilen;struct sockaddr_in cliaddr, servaddr;

listenfd = socket(AF_INET, SOCK_STREAM, 0);

bzero(&servaddr, sizeof(servaddr));servaddr.sin_family = AF_INET;servaddr.sin_addr.s_addr = htonl(INADDR_ANY);servaddr.sin_port = htons(SERV_PORT);

bind(listenfd, (SA *) &servaddr, sizeof(servaddr));

listen(listenfd, LISTENQ);

maxfd = listenfd; /* initialize */maxi = -1; /* index into client[] array */for (i = 0; i < FD_SETSIZE; i++)

client[i] = -1; /* -1 indicates available entry */FD_ZERO(&allset);FD_SET(listenfd, &allset);

127

esempio d’uso della select()server che non utilizza la fork() (1)

for ( ; ; ) {rset = allset; /* structure assignment */nready = select(maxfd+1, &rset, NULL, NULL, NULL);

if ( FD_ISSET( listenfd, &rset) ) { /* new client connection */clilen = sizeof(cliaddr);connfd = accept( listenfd, (SA *) &cliaddr, &clilen);

for (i = 0; i < FD_SETSIZE; i++)if (client[i] < 0) {

client[i] = connfd; /* save descriptor */break;

}if (i == FD_SETSIZE) err_quit("too many clients");FD_SET(connfd, &allset); /* add new descriptor to set */if (connfd > maxfd) maxfd = connfd; /* for select */if (i > maxi) maxi = i; /* max index in client[] array */if (--nready <= 0)

continue; /* no more readable descriptors */}for (i = 0; i <= maxi; i++) { /* check all clients for data */

if ( (sockfd = client[i]) < 0)continue;

if (FD_ISSET(sockfd, &rset)) {if ( (n = Readline(sockfd, line, MAXLINE)) == 0) {

/*connection closed by client */close(sockfd);FD_CLR(sockfd, &allset);client[i] = -1;

} elsewriten(sockfd, line, n);if (--nready <= 0)

break; /* no more readable descriptors */}

}}}

128

server che non utilizza la fork() (1)

Advanced TCP Socket

130

Le opzioni per i socket sono controllate mediante tre tipi di primitive:1) le funzioni getsockopt() e setsockopt(), che permettono di configurare alcune caratteristiche proprie solo dei socket, quali dimensioni dei segmenti, controlli sulla funzionalità della connessione, modalita’ di utilizzo degli indirizzi; 2) la funzione fcntl(), che invece consente di settare caratteristiche comuni a tutti i descrittori di I/O, quali comportamento bloccante o non bloccante e I/O guidato dai signal.3) la funzione ioctl(), che ripete operazioni delle fcntl ed inoltre effettua operazioni riguardanti ARP e routing.

Le opzioni tipiche per i socket possono essere settate solo quando il socket è reso disponibile all’interfaccia di programmazione.Consideriamo ad es. il caso di un connected socket ottenuto da un server in risposta ad una chiamata alla accept() a partire da un socket listening. Il connected socket viene creato dopo la listen() quando arriva una richiesta di connessione dal client, e tutto il procedimento di instaurazione della connessione avviene senza che il programmatore possa intervenire, in quanto il socket creato verrà reso disponibile al programmatore solo quando questo farà eseguire la accept().

Per rendere possibile configurare il socket anche in questa situazione temporanea, l’interfaccia socket implementa la politica seguente: il connected socket eredita dal listening socket alcune opzioni, invece di assumere le opzioni di default. Queste opzioni sono:SO_DEBUG, SO_DONTROUTE, SO_KEEPALIVE, SO_LINGER, SO_OOBINLINE, SO_RCVBUF e SO_SNDBUF. In tal modo se vogliamo che il connected socket abbia queste opzioni gia’ durante la fase del thee-way-handshake dobbiamo settare in quel modo il listening socket.In http://www.cs.unibo.it/~ghini/didattica/sistemi3/SOCKOPTS/checkopts.ce’ implementato un esempio di lettura delle opzioni di default di un socket.

Le Opzioni per i Socket

Il formato di queste due funzioni è il seguente:#include <sys/socket.h>int getsockopt ( int sockfd, int level, int optname,

void *optval, socklen_t *optlen );int setsockopt ( int sockfd, int level, int optname,

const void *optval, socklen_t optlen );restituiscono 0 se tutto OK, -1 in caso di errore.

- Il primo argomento socketfd è un descrittore di socket aperto con una socket(), su cui operano le funzioni.- L’argomento level indica a che livello di protocollo deve agire l’opzione: a livello di socket generale (level=SOL_SOCKET), a livello IPv4(IPPROTO_IP), IPv6(IPPROTO_IPV6), ICMPv6 (IPPROTO_ICMPV6), a livello TCP (level=IPPROTO_TCP).- optname specifica l’opzione da leggere /settare.- optval è un puntatore ad una variabile di tipo dipendente dall’opzionespecificata, che contiene il valore nuovo da settare dell’opzione da configurare (caso setsockopt) o che conterrà il valore attuale dell’opzione (caso getsockopt).- optlen contiene la dimensione della variabile puntata da optval.

Le opzioni possono effettuare due diverse operazioni:- settare o resettare un flag,- assegnare o leggere un valore più complesso.Nel caso dei flags, il valore restituito o passato (optval) punta ad un intero, che vale zero se l’opzione e’ disabilitata, vale nonzero se l’opzione e’ abilitata.Nel caso non flags optval punta ad un dato di tipo diverso, come indicato nella seguente tabella:

131

funzioni getsockopt() e setsockopt()

Tabe

lla d

elle

Opz

ioni

Soc

ketG

ener

iche

, cio

è di

live

llo

Sock

et, p

er g

etso

ckop

t() e

set

sock

opt(

)

132

Per q

uest

e op

zion

i, ne

lle fu

nzio

ni g

etso

ckop

t() e

set

sock

opt(

) de

ve e

ssre

utili

zzat

o co

me

seco

ndo

argo

men

to le

vel=

SOL_

SOC

KET

.

Consideriamo le principali opzioni caratteristiche di tutti i socket, quelle identificate dal livello SOL_SOCKET.

SO_BROADCAST questa opzione abilita o disabilita la possibilitàper un socket di spedire messaggi broadcast. Viene applicato solo ai socket datagram (DGRAM) e solo se la rete sottostante lo permette (es: ethernet, non punto a punto). Per default questa opzione èdisabilitata, per impedire ad un processo di spedire accidentalmente un datagram in broadcast, ad es. se l’indirizzo IP di destinazione viene preso a linea di comando e si digita per errore un indirizzo di broadcast. In tal caso il kernel si accorge di avere a che fare con un datagram di broadcast il cui invio è disabilitato, e restituisce un errore di tipo EACCES.

SO_DEBUG questa opzione è supportata solo da TCP, e ordina al kernel di mantenere informazioni su tutti i pacchetti spediti o ricevuti da/a un certo socket, in una coda circolare. Il programma trcp esaminera’ questa coda.

SO_DONTROUTE questa opzione e’ applicata per bypassare il normale meccanismo di routing dei pacchetti in uscita, ad es: per farli uscire da un’interfaccia di rete diversa da quella prevista dalle tabelle interne di routing. Viene usata ad es. dai processi daemon del routing (routed o gated) per instradare un pacchetto sull’interfaccia giusta quando le tabelle di routing sono sbagliate.

SO_KEEPALIVE questa opzione è applicata solo agli stream TCP, per verificare se una connessione che da molto tempo non scambiadati debba essere chiusa o no. Il motivo per cui una connessione deve essere chiusa da un end system e’ che l’altro end system a) e’down, b) non e’ raggiungibile (rete partizionata o problema nel routing), c) non e’ piu’ interessato a quella connessione.

Opzioni Socket Generiche (1)

133

SO_KEEPALIVE (continuazione) Quando un socket TCP ha questa opzione settata, se nessun dato viene scambiato in una delle due direzioni della connessione per 2 ore, il TCP spedisce un segmento, detto keepalive probe, all’altro end-system, per verificarne la situazione, e si aspetta di ricevere un ACK.1) se il peer risponde con un ACK tutto e’ OK, ed il TCP mandera’ un nuovo probe dopo altre due ore di inattivita’.2) se il peer risponde con un segmento RST (reset), significa che e’andato in crash e poi ha effettuato il reboot. Il socket allora viene chiuso, ed la variabile d’errore del socket settata a ECONNRESET.3) se non c’e’ risposta dal peer, il TCP riprova a mandare altri 8 segmenti keepalive probe, ogni 75 secondi, aspettando risposta.3.1) Se non viene ricevuta alcuna risposta il socket e’ chiuso e la var. d’errore settata a ETIMEOUT.3.2) se invece viene ricevuta un ICMP error in risposta ad uno dei keepalive probe, il socket viene chiuso, e viene restituito l’errore indicato dall’ICMP, che sara’ di tipo EHOSTUNREACH, ovvero l’host non e’ raggiungibile.

La specifica Posix.1g stabilisce anche le modalita’ per settarelintervallo di attesa (le 2 ore) ad un valore diverso, ma tale opzione e’implementata raramente.

Questa Opzione SO_KEEPALIVE serve a stabilire se il peer host e’andato in crash. Invece il crash dell’applicazione peer viene individuato e notificato dal TCP peer. Cioe’ quando nell’altro end system il processo che gestiva il socket va in crash, il TCP di quell’host spedisce un segmento FIN per chiudere la connessione, e questa chiusura può essere individuata con una read() o una select() settata per verificare la possibilita’ di leggere da quel socket. Non esiste altro modo di accorgersi di un crash se non cercando di fare un test per lettura.

Opzioni Socket Generiche (2)

134

SO_RCVBUF e SO_SNDBUF Queste due opzioni servono a modificare la dimensione dei buffer di ricezione e trasmissione del TCP e dell’UDP.Per il TCP la dimensione del buffer di ricezione viene mandata all’atto dell’instaurazione della connessione. E’ quindi necessario che per il server questa opzione sia settata prima della chiamata alla listen(), mentre per il client deve essere settata prima della chiamata alla connect().Invece per UDP il buffer di ricezione determina la dimensione massima dei datagram che possono essere accettati.

SO_REUSEADDR e SO_REUSEPORT Queste due opzioni servono a permettere di effettuare la bind() su porte e indirizzi IP gia’ utilizzati da qualche altro processo. La SO_REUSEADDR ad es. puo’ essere utile nei seguenti casi:

a) si cerca di fare la bind per un listening socket che e’ stato chiuso e si vuol fare ripartire, quando ancora esiste un connected socket nato dal listening socket appena chiuso.

b) ci sono piu connected socket che lavorano sulla stessa porta di un host ma con IP diversi. E’ il caso dei web server che devono lavorare sulla stessa well know port 80 ma su interfacce diverse.

SO_TYPE Questa opzione puo’ essere usata solo in lettura, e restituisce il tipo del socket, SOCK_STREAM o SOCK_DGRAM.

Opzioni Socket Generiche (3)

135

SO_LINGER Questa opzione determina le modalita’ di chiusura realizzate dalla funzione close(). Viene usato come argomento optvaldella setsockopt() un puntatore ad una struttura di tipo:struct linger { int l_onoff; /* 0=off , nonzero=on */

int l_linger; /* linger time, Posix.1g vuole secondi */}Per default la close() restituisce subito il controllo al chiamante, ma se alcuni dati rimangono nei buffer di spedizione il TCP tenta di spedirli.

1) se l_onoff==0 l’opzione SO_LINGER e’ disabilitata, quindi viene settato il modo di default appena visto.

• In questo modo non sappiamo se il TCP peer ha ricevuto tutti i dati, e a maggior ragione non sappiamo se l’application peer li ha ricevuti.

2) se l_onoff != 0 e l_linger==0 quando un socket chiama la close(), il TCP chiude la connessione in modo traumatico, non spedendo i dati eventualmente bufferizzati per la spedizione, e mandando un segmentRST (reset) all’altro end-system. Non si va nello stato TIME_WAIT e si rischia di danneggiare l’apertura di una nuova connessione con gli stessi indirizzi IP e di porta.• Anche in questo caso non sappiamo se il TCP peer ha ricevutotutti i dati, e nemmeno se li ha ricevuti l’ application peer.

Opzioni Socket Generiche (4)

136

SO_LINGER (continuazione)3) se l_onoff != 0 e l_linger !=0 quando un socket chiama la close(), se il socket e’ di tipo bloccante (e’ il default) il TCP tenta di spedire i dati eventualmente bufferizzati per la spedizione, fino a che si verifica una di queste condizioni:3.1) tutti i dati sono trasmessi e riscontrati dal TCP peer, ed allora la funzione close() restituisce il controllo al chiamante con risultato 0, passando dallo stato TIME_WAIT.

Anche in questo caso però, anche se sappiamo che il TCP ha ricevuto i dati non abbiamo garanzie che l’application peer riceva i dati. Puo’capitare infatti che dopo che il TCP peer ha spedito l’ACK per i dati ed il FIN, e quindi la close() e’ terminata, l’application peer vada in crashe non riesca a leggere dalla coda del TCP peer.

3.2) oppure scade il tempo assegnato di attesa l_linger e la funzione close restituisce -1 mandando un segment RST (reset) all’altroend-system, e non passa dallo stato TIME_WAIT.

Opzioni Socket Generiche (5)

137

La funzione shutdown() e’ utilizzata per chiudere una connessione in modo differente rispetto alla close().Infatti:- mentre la close() decrementa solo il contatore dei processi che utilizzano quel socket e quando il contatore e’ zero spedisce il segmento FYN, la shutdown spedisce subito il segmento di FIN(anche se il contatore e’ maggiore di zero) ovviamente senza passare avanti agli altri dati bufferizzati per la spedizione.- mentre la close() chiude entrambe le direzioni della connessione, e quindi impedisce di usare con quel socket sia primitive di input sia di output (no read no write dopo close() ), la shutdown da’ la possibilita’ di effettuare chiusure asimmetriche di una connessione, specificando quale direzione deve essere interrotta.

int shutdown (int sockfd, int howto);restituisce 0 se tutto OK, -1 in caso di errore.L’argomento socketfd è un descrittore di socket.L’argomento howto specifica l’azione che deve essere effettuata sul socket sockfd, ed e’ una delle seguenti:

- SHUT_WR l’applicazione chiude il socket sia in scrittura che in lettura,, senza badare al contatore di processi per quel socket. Tutti i dati eventualmente presenti nelle code di output verranno spediti, e poi verra’ spedito un SYN segment, per terminare il lato di output della connessione. Rimane possibile effettuare delle read() fino a che l’altro end-system non effettua a suo volta un\a close() che fa inviare il SYN segment verso chi aveva effettuato la chiamata alla shutdown(). Questo tipo di chiusura viene detta half-close.

- SHUT_RD l’applicazione chiude il socket in lettura, resta possibile effettuare le write(). Non è piu’ possibile effettuare le letture, e tutti i dati eventualmente gia’ ricevuti dal TCP e presenti nelle code per l’inputvengono scartati. Vengono scartati anche eventuali dati giuntidopo la shutdown(). 138

funzione shutdown() (1)

- SHUT_RDWR l’applicazione chiude il socket sia in scrittura che in lettura, come se effettuasse due chiamate alla shutdown, con parametro SHUT_RD e poi con parametro SHUT_WR.

vediamo qui una rappresentazione di una half close (SHUT_WR).

139

funzione shutdown() (2)

Garanzie diTrasmissione Completata (1)

140

Garanzia per il Client che il Server ha ricevuto tutti i dati.Un modo sicuro per sapere se l’applicazione dell’altro end system (non solo il TCP) ha ricevuto i dati è sostituire la chiamata alla close() con una chiamata alla shutdown() usando come secondo argomento la costante SHUT_WR, e procedere poi con una chiamata alla read().

In questo modo la shutdown manda il segmento di FIN, ma lascia aperto il socket in lettura, permettendo di effettuare la chiamata alla read() che altrimenti restituirebbe immediatamente un errore. La read() rimane bloccata fino a che l’application peer termina la lettura di tutti i dati e legge il FIN, quindi effettua la close() che manda il segmento FIN di risposta.La read() allora riceve l’end-of-file e termina restituendo 0. Si ha allora la garanzia che la applicazione peer ha ricevuto tutti i dati.

Garanzia per il Client che il Server ha ricevuto tutti i dati.Un altro modo per garantire che l’application peer ha ricevuto tutti i dati e’ usare il cosiddetto application-level acknowledgment o application ACK.Il client dopo avere spedito tutti i suoi dati si blocca su una readaggiuntiva, che rappresenta l’attesa per un ACK a livello di applicazione. Il server, dopo avere ricevuto tutti i dati effettua una write di un byte, che rappresenta l’ACK a livello di applicazione.Quando il client ritorna dalla read() effettua la close() che manda il FIN segment. Solo allora l’application peer effettua la close().In questo modo si ha la garanzia che il processo server ha letto i dati che gli sono stati inviati.

141

Garanzie diTrasmissione Completata (2)

Tabe

lla d

elle

Opz

ioni

Soc

ketp

er T

CP,

cio

è di

live

llo

IPPR

OTO

_TC

P, p

er g

etso

ckop

t() e

set

sock

opt(

) 142

Per q

uest

e op

zion

i, ne

lle fu

nzio

ni g

etso

ckop

t() e

set

sock

opt(

) de

ve e

sser

e ut

ilizz

ato

com

e se

cond

o ar

gom

ento

leve

l=IP

PRO

TO

_TC

P.

143

Opzioni Socket per TCPQueste opzioni si usano specificando il livello IPPROTO_TCP.

TCP_KEEPALIVE Questa opzione specifica il tempo (in sec.) di inattivita’ della connessione prima che venga fatto partire il segmento di keepalive probe. Il valore di default e’ di 7200 sec. (2 ore). Questa opzione e’ realmente attivata solo quando l’opzione SO_KEEPALIVE e’ abilitata.

TCP_MAXSEG Questa opzione restituisce o setta il maximum segment size (MSS) per la connessione TCP.

TCP_NODELAY Per default il TCP abilita il cosiddetto Algoritmo di Nagle (Nagle Algorithm) il cui scopo e’ di diminuire il numero di segmenti piccoli trasmessi, come nel caso di client telnet che prevedono l’ACK per ogni singolo carattere battuto a tastiera. Questo algoritmo è legato all’algoritmo dell’ACK ritardato (delayed ACK algorithm) che fa aspettare il TCP per circa 50-200 msec) prima di dare l’ack ad un segmento, sperando di poter accodare l’ACK ad un segmento di dati. Questi due algoritmi assieme cercano di minimizzare il numero disegmenti trasmessi, ma producono ritardo per applicazioni che scambiano piccoli dati e quasi solo in una direzione.L’opzione TCP_NODELAY disabilita l’uso di questi algoritmi.

Nagle algorithm DISABLEDNagle algorithm Enabled settata TCP_NODELAY opt.

Consente di inviare uno stesso datagram UDP a piu’ destinatari, i quali devono essersi preventivamente registrati come membri del gruppo di multicast caratterizzato da un certo indirizzo di multicast.

Indirizzi di multicast: Classe D, 224.0.0.0 - 239.255.255.255

Indirizzi di Multicast Speciali: 224.0.0.1 (all-host group) vi si devono registrare tutti gli host di

una sottorete, che implementano il multicast.224.0.0.2 (all-router group) vi si devono registrare tutti gli host di

una sottorete, che implementano il multicast.

Operazioni necessarie per ricevere datagram UDP via multicast:creazione di un socket UDPcollegamento ad una porta del protocollo UDP (bind)join ad un indirizzo di multicast (setsockopt).

Operazioni necessarie per smettere di ricevere via multicast:leave del gruppo multicast (setsockopt).

N.B. Se con la bind non specifico un indirizzo IP, posso riceveredatagram UDP sia originati da multicast che da unicast, per laporta UDP specificata.

N.B. Se con la bind specifico l’indirizzo IP di multicast a cui faro’ iljoin, potro’ ricevere solo datagram UDP di multicast per quelloindirizzo di multicast.

Operazioni opzionali per spedire datagram UDP via multicast:Specificare il TTL dei datagram UDP multicast.

Se non si specifica, il default e’ 1, non si esce dalla subnet.Specificare se il mittente deve ricevere copia del datagram (se fa

parte del gruppo di multicast. 144

Opzioni Socket per IP: Multicast (1)

indica se i datagramdi multicast spediti devono andare anche al mittente, se questo appartieneal gruppo

u_charIP_MULTICAST_LOOP

specifica il TTL dei datagram di multicast da spedire

u_charIP_MULTICAST_TTL

indica l’interfaccia di rete da usare per spedire i datagram di multicast

struct in_addrIP_MULTICAST_IF

toglie il socket UDP dal gruppo di multicast

struct ip_mreqIP_DROP_MEMBERSHIP

collega il socket UDP ad uno specifico gruppo di multicast

struct ip_mreqIP_ADDR_MEMBERSHIP

usotipo di datoopzione

Opzioni di livello IPPROTO_IPLe opzioni utilizzate per configurare un socket UDP per la trasmissione/ricezione di datagram per un certo indirizzo di multicast, vengono settate mediante la primitiva setsockoption, utilizzando il livello IPPROTO_IP, ed i comandi e le strutture dati specificati in tabella.

145

Opzioni per il Multicast in IPv4

146

esempio: receiver di datagram UDPper gruppo di Multicast

struct ip_mreq Mreq;.....socketfd = socket (AF_INET, SOCK_DGRAM, 0);OptVal = 1;setsockopt (socketfd, SOL_SOCKET, SO_REUSEADDR,

(char *)&OptVal, sizeof(OptVal) );Local.sin_family = AF_INET;Local.sin_addr.s_addr = htonl(INADDR_ANY);Local.sin_port = htons( 6001); // local_port_numberbind ( socketfd, (struct sockaddr*) &Local, sizeof(Local));

/* join the multicast group. */Mreq.imr_multiaddr.s_addr = inet_addr("234.5.6.7");Mreq.imr_interface.s_addr = INADDR_ANY;setsockopt(socketfd, IPPROTO_IP, IP_ADD_MEMBERSHIP,

(char *)&Mreq, sizeof(Mreq) );

for (j=1;j<=1000;j++) {Fromlen=sizeof(struct sockaddr);msglen = recvfrom ( socketfd, msg, (int)SIZEBUF, 0,

(struct sockaddr*)&From, &Fromlen);sprintf(string_remote_ip_address,"%s",inet_ntoa(From.sin_addr);

remote_port_number = ntohs(From.sin_port);printf("ricevuto msg: \"%s\" len %d, from host %s, port %d\n",

msg, msglen, string_remote_ip_address, remote_port_number);}

147

esempio: sender di datagram UDPper gruppo di Multicast

struct ip_mreq Mreq; int ttl, int loopback;.....socketfd = socket (AF_INET, SOCK_DGRAM, 0);OptVal = 1;

/* set TTL to traverse up to multiple routers */ttl = TTL_VALUE; // per default 1setsockopt(socketfd, IPPROTO_IP, IP_MULTICAST_TTL,

(char *)&ttl, sizeof(ttl));

/* join the multicast group, NON NECESSARIO per SPEDIRE */Mreq.imr_multiaddr.s_addr = inet_addr("234.5.6.7");Mreq.imr_interface.s_addr = INADDR_ANY;setsockopt(socketfd, IPPROTO_IP, IP_ADD_MEMBERSHIP,

(char *)&Mreq, sizeof(Mreq) );

/* disable loopback , NON NECESSARIO se non si fa join */loopback =0;setsockopt(socketfd, IPPROTO_IP, IP_MULTICAST_LOOP,

(char *)&loopback, sizeof(loopback));

for (j=1;j<=1000;j++) {To.sin_family = AF_INET;To.sin_addr.s_addr = inet_addr("234.5.6.7" );To.sin_port = htons( 6001 ); // remote_port_numberaddr_size = sizeof(struct sockaddr_in);/* send to the address */sendto ( socketfd, msg, strlen(msg) , 0,

(struct sockaddr*)&To, addr_size);}

La funzione fcntl significa “file control” e serve ad effettuare alcune operazioni su vari descrittori non solo di socket ma in generale di file. In particolare la funzione fcntl permette di:• configurare l’I/O di un descrittore come non bloccante o bloccante usando nella fcntl il comando F_SETFL con argomento O_NONBLOCK (O_BLOCK),• configurare l’I/O di un descrittore come guidato dai signal usando nella fcntl il comando F_SETFL con argomento O_ASYNC, ottenendo che in corrispondenza di ogni modifica della situazione del socketvenga scatenato un SIGIO signal.• settare un proprietario per il descrittore (comando F_SETOWN), ovvero definire qual’e’ il processo che viene avvisato con il signalSIGIO quando il descrittore e’ disponibile all’I/O, ma questo solo se e’stato settato il socket come guidato dai signal. Si ricorda che un socketappena creato con la socket() non ha proprietario, un connected socketha lo stesso proprietario del listenung socket• conoscere il proprietario corrente per il descrittore (F_GETOWN).

#include <fcntl.h>int fcntl (int fd, int cmd, ... /* int arg */ );

restituisce -1 in caso di errore,un altro valore dipendente dal comando in caso tutto OK.

Le proprieta’ di un descrittore di file (e di socket) sono definite mediante alcuni flags, che la funzione fcntl permette di leggere (usando come secondo argomento cmd=F_GETFL) e di settare (usando come secondo argomento cmd=F_SETFL).

I due flags che ci interessano per i socket sono:O_NONBLOCK non blocking I/OO_ASYNC signal-driven I/O notification 148

Opzioni Socket tramite fcntl (1)

In generale la procedura corretta per settare un flags consiste nel leggere i flags del descrittore mediante il comando F_GETFL, modificare solo il flag che interessa con un OR logico, settare i nuovi flags per il socket mediante il comando F_SERFL.

Nel seguente esempio viene settato il flag O_NONBLOCK, quindi il socket diventa “non bloccante”.

Procedura correttaint flags, sockfd;sockfd = socket(....);if ( (flags=fcntl(sockfd,F_GETFL,0)) <0 )

exit(1);flags |= O_NONBLOCK;if ( fcntl(sockfd,F_SETFL,flags) <0 )

exit(1);

Procedura errata, vengono azzerati tutti gli altri flags.int sockfd;sockfd = socket(....);if ( fcntl(sockfd,F_SETFL, O_NONBLOCK )<0)exit(1);

Infine in questo esempio viene resettato il flag O_NONBLOCK, quindi il socket diventa “bloccante”.int flags, sockfd;sockfd = socket(....);if ( (flags=fcntl(sockfd,F_GETFL,0)) <0 )

exit(1);flags &= ∼O_NONBLOCK;if ( fcntl(sockfd,F_SETFL,flags) <0 )

exit(1);149

Opzioni Socket tramite fcntl (2)

Se per un socket viene settato il flags O_ASYNC, quando il socketdiventa disponibile all’I/O, o e’ in errore, viene lanciato un signalSIGIO al processo proprietario del socket, o ai processi del gruppo proprietario del socket, se il proprietario esiste.

Per settare il proprietario si usa la fcntl con secondo argomento F_SETOWN passando come terzo parametro o il numero positivo piddel processo proprietario, o il numero negativo ottenuto cambiando di segno il numero di gruppo.

Per conoscere il proprietario si usa la fcntl con secondo argomento F_GETOWN. La funzione restituisce un intero positivo (il pid del proprietario) o un numero negativo diverso da -1, che e’ l’identificatoredel gruppo cambiato di segno.

settare il proprietario di un socketint sockfd,pid;sockfd = socket(....);if ( fcntl(sockfd,O_SETOWN, pid ) <0 )

exit();

settare il gruppo di un socketint sockfd, gid;sockfd = socket(....);if ( fcntl(sockfd,O_SETOWN , -gid ) <0 )

exit();

150

Opzioni Socket tramite fcntl (3)

Per default un socket e’ bloccante. Cio’ significa che quando il socketdeve effettuare un’operazione di I/O, se questa non puo’ essere terminata immediatamente il processo si mette in attesa aspettando la fine dell’operazione. Se invece, mediante la fcntl vista prima, il socketviene settato Nonblocking il comportamento delle funzioni cambia:

Operazioni di input (read, recvfrom ). Con un socket Non Bloccante, se l’operazione di input non puo’ essere terminata (cioe’non c’e’ nemmeno un byte per il socket TCP o non c’e’ nemmeno un datagram per il socket UDP) la funzione ritorna immediatamente al chiamante restituendo il codice d’errore EWOULDBLOCK.

Operazioni di output (write, sendto ).• Con un socket Non Bloccante di tipo TCP, se l’operazione di scrittura non puo’ essere effettuata nemmeno in parte perche’ manca spazio nei buffer del TCP in cui andare a scrivere i dati, la funzione ritorna immediatamente al chiamante restituendo il codice d’errore EWOULDBLOCK. Se invece e’ rimasto spazio, viene effettuata una scrittura di una porzione di dati minore o uguale alla dimensione del buffer libero, e la write restituisce il numero di byte scritti.• Con un socket Non Bloccante di tipo UDP invece il problema non sussiste perche’ nessun datagram viene mantenuto in un buffer perche’non c’e’ ritrasmissione, quindi il datagram UDP viene immediatamente spedito e vada come vada. Quindi una primitiva di output di un socketUDP non blocca mai il processo che l’effettua.

Operazioni di Accettazione Richiesta Connessione (accept). Con un socket Non Bloccante, se l’operazione di accept non puo’restituire immediatamente una nuova connessione perche’ la coda delle connessioni accettate e’ vuota, la funzione ritorna immediatamente al chiamante restituendo il codice d’errore EWOULDBLOCK. 151

I/O Non Bloccante (1)

Operazioni di Richiesta Connessione (connect).Con un socket UDP la funzione connect non e’ realmente bloccante, perche’ deve solo scrivere nel kernel l’indirizzo IP e il numero di porta dell’altro end-system, quindi anche nel caso di socket Non Bloccante la connect per l’UDP effettua sempre l’operazione interamente e restituisce il controllo al chiamante.

Invece per il TCP la chiamata del client alla connect() di un socketbloccante deve aspettare che, all’interno del three way handshake, il client abbia ricevuto l’ACK per il SYN segment, sia stato ricevuto, e quindi puo’ veramente bloccare il processo.

Se il socket TCP e’ di tipo Non Bloccante, la chiamata del client alla connect() fa iniziare il procedimento di inizio connessione, cioe’ fa spedire il primo SYN segment, ma se la connessione non puo’immediatamente essere instaurata la connect() termina con un codice d’errore EINPROGRESS ad indicare che l’operazione continua a livello inferiore.Con una select() sara’ possibile accorgersi di quando il socketimpegnato nella richiesta di connessione ha stabilitpo la connessione, e quindi puo’ essere ripetuta la connect().Si noti che puo’ capitare che la connect() restituisca OK perche’ e ‘riuscita ad avere immediatamente risposta ed ha instaurato la connessione richiesta.

152

I/O Non Bloccante (2)

socketfd = socket(AF_INET, SOCK_STREAM, 0);/* SETTO IL SOCKET COME NON BLOCCANTE */set_socket_non_blocking(socketfd); /* ora socket e' non bloccante */

... qui va messo il necessario per la bind .......bind(socketfd, (struct sockaddr*) &Local, sizeof(Local));memset ( &Serv, 0, sizeof(Serv) );Serv.sin_family = AF_INET;Serv.sin_addr.s_addr = inet_addr(string_remote_ip_address);Serv.sin_port = htons(remote_port_number);/* connection request, NON BLOCCANTE */ris = connect(socketfd, (struct sockaddr*) &Serv, sizeof(Serv));if (ris != SOCKET_ERROR) { /* connessione riuscita subito */

set_socket_blocking(socketfd); /* ora socket e' bloccante */.....................

}else { /* (ris == SOCKET_ERROR) */

if(errno!=EINPROGRESS) exit(1); /* conness. non terminata */FD_ZERO(&fdr); FD_SET(socketfd,&fdr);fdw=fdr;

.....................

ris=select(socketfd+1,&fdr,&fdw,NULL,NULL);if ((FD_ISSET(socketfd,&fdr))||(FD_ISSET(socketfd,&fdw))) {

ris=connect(socketfd,(struct sockaddr*) &Serv, sizeof(Serv));if (ris == SOCKET_ERROR) {

if(errno==EISCONN) {printf ("connessione gia' esistente, OK\n");set_socket_blocking(socketfd); /* socket e‘ bloc*/

}else exit(1); /* connessione NON riuscita */

}}

}153

Connect Non Bloccante (1)

/* SETTO IL SOCKET COME NON BLOCCANTE */int set_non_blocking(int socketfd) {

int flags;if ( (flags=fcntl(socketfd,F_GETFL,0)) <0 ) return(0); /* errore */flags |= O_NONBLOCK; if ( fcntl(socketfd,F_SETFL,flags) <0 ) return(0); /* errore */return(1);

}

/* SETTO IL SOCKET COME BLOCCANTE */int set_blocking(int socketfd) {

int flags;if ( (flags=fcntl(socketfd,F_GETFL,0)) <0 ) return(0); /* errore */flags &= (~O_NONBLOCK); if ( fcntl(socketfd,F_SETFL,flags) <0 ) return(0); /* errore */

return(1);}

N.B.per l’esempio completo vedere nella home page

154

Connect Non Bloccante (2)