Appunti presi durante le lezioni di Sistemi di elaborazione e trasmissione dell'informazione

Reti lezione 1

Il sistema contiene i già visti dispositivi CPU, memoria RAM, Cache, ecc., e infine il dispositivo di interconnessione di rete (NIC). Il NIC (Network Interface Card) invia e riceve messaggi grazie a un trasferimento DMA tra zone di memoria RAM: i buffer di comunicazione. Quando si vuole inviare un messaggio, le sequenze di byte vengono trasferite un byte alla volta all’interno della NIC per poi essere serializzate nel canale di trasmissione. Analogamente e in direzione inversa opera sempre il DMA che copia nel buffer di ricezione i messaggi ricevuti dalla NIC.

La rete che permette alla NIC di fare ciò è costituita dai routers. Essi sono collegati tra loro e formano la rete. Al giorno d’oggi tali routers sono dei veri e propri computer costruiti al solo scopo di effettuare questi collegamenti: infatti i routers non hanno una sola unità NIC, ma ne hanno di più; cosa che permette loro di avere più collegamenti in contemporanea (si forma una “maglia” di collegamenti).

Modalità di trasferimento

La modalità di trasferimento viene chiamata Store & Forward: si riconduce alla comunicazione tra coppie di macchine. In un primo momento l’utente si connette al router a cui è fisicamente connesso e tutto il messaggio viene copiato nel buffer di memoria del primo router. Una volta ricevuto il messaggio, il router va a vedere a chi è destinato il messaggio: vi è quindi la necessità di attribuire degli indirizzi univoci alle varie macchine connesse nella rete. Dunque, una parte di bit del messaggio dovrà specificare l’indirizzo del destinatario; il router leggerà tali bit e deciderà il miglior percorso da seguire per trasferire i dati da un router all’altro fino al destinatario. Questi trasferimenti sono detti “salti”.

Le telecomunicazioni possono avvenire tramite cavi o altri canali fisici (come per la fibra ottica) oppure attraverso la trasmissione via radio (e segnali elettromagnetici), come il wi-fi.

Stratificazione in livelli (Protocol Stack)

Introduciamo la stratificazione in livelli (Protocol Stack). Un modello teorico è il modello ISO/OSI, basato su una stratificazione in 7 livelli, ma che non è mai stata implementata nella pratica. La stratificazione dei protocolli Internet avviene quindi su 5 livelli. Ciascun livello si occupa di un aspetto particolare dell’implementazione dei protocolli di comunicazione.

Il livello più basso è il livello fisico (le implementazioni a livello hardware: come l’utilizzo di un particolare cavo elettrico e il livello di tensione necessaria per far funzionare i dispositivi) e permette di realizzare fisicamente il dispositivo. Il secondo livello è il Data Link, questo permette di specificare il formato dei bit che vengono trasferiti, indica come devono essere fatti i messaggi, di quanti byte possono essere composti, come viene controllato l’indirizzo del destinatario, come controllare eventuali errori nel messaggio e specifiche nell’utilizzo del dispositivo. Fin qui stiamo ragionando a livello di un singolo canale di comunicazione (quindi di effettuazione di un singolo HOP).

Al terzo livello abbiamo il livello di Rete (Network), esso consiste nell’instradamento del messaggio da sorgente a destinazione. È quello che dice ai router quale strada percorrere per portare un messaggio da una parte del mondo all’altra. Il quarto livello è il livello di Trasporto, mentre il quinto è quello Applicativo (Transport and Application).

A noi programmatori che vogliamo usare la rete interessa principalmente il livello Applicativo (poiché gli altri servono a realizzare la rete in sé). Il Livello di Trasporto, al contrario di come suona, permette di interfacciarsi col sistema operativo. Per capire perché sia così basti pensare che storicamente le reti di calcolatori e i sistemi operativi si sono evoluti separatamente (c’erano ingegneri che provavano a realizzare reti ma che non sapevano niente di computer e gli ingegneri di computer che non sapevano nulla di reti, l’unica eccezione era chi progettava la NIC).

Inizialmente c’era un supporto di telecomunicazione analogico (come la rete telefonica) e un livello di traduzione/codifica ulteriore per inviare anche informazioni digitali, ma che utilizzavano lo stesso mezzo di trasmissione (per cui si dovevano utilizzare frequenze diverse; infatti, nei vecchi telefoni i numeri facevano rumori diversi per via della diversa frequenza a cui venivano codificati).

Al giorno d’oggi si fa la cosa opposta: è più efficiente trasformare i segnali analogici in digitali e trasmetterli così, i modem si sono quindi trasformati in routers, veri e propri computer. Le macchine usate dagli utenti invece hanno preso il nome di Host.

Quello che cambia tra router e host è che i routers in genere possono non avere un’unità a disco, inoltre diverse sono le capacità del processore e la quantità di RAM, poiché il loro scopo è semplicemente trasferire informazioni.

Al giorno d’oggi non c’è separazione tra reti e sistemi operativi/computer, tuttavia, poiché i protocolli che ormai sono diventati standard (poiché per poter comunicare a livello mondiale è necessario che tutti usino lo stesso protocollo) sono stati iniziati ad essere standardizzati a partire dal 1960+ o -, quando ciò è avvenuto c’era ancora la separazione tra sistemi operativi e reti di calcolatori. Per poter standardizzare i protocolli di rete in maniera indipendente dalla struttura dei sistemi di calcolo, si è dunque inventato il quarto livello, il Transport.

Infatti, in un computer normalmente non si vuole far girare solamente un’applicazione per volta, dunque il meccanismo di indirizzamento che viene usato a livello di rete per spostare le sequenze di byte da macchina sorgente a destinazione non era sufficiente (l’indirizzo indica solamente la macchina del destinatario, non l’applicazione in particolare a cui deve arrivare).

Si noti che le unità fondamentali nei sistemi di calcoli sono chiamati “Processi” e il livello di trasporto servirebbe, appunto, per mappare, attraverso il PID (Process ID) fornito dal sistema operativo, a quale Processo → Applicazione debbano arrivare le informazioni. Ma c’è da considerare che non tutti i sistemi operativi sono uguali, non sempre c’è un PID, o se c’è può essere gestito in maniera diversa.

Quindi quando si progetta il sistema di comunicazione è necessario non tanto identificare un programma quanto identificare la funzionalità di questo programma.

È così che viene introdotto il concetto di “Porta” (port) di comunicazione, anch’essa un intero su 16 bit come il PID. Le porte servono per mappare delle funzionalità attraverso dei programmi chiamati server. C’è un’organizzazione internazionale che ha stabilito una serie di numeri di porta che vanno associati a determinati server (ogni volta che se ne va aggiunto uno, quindi, bisogna chiedere a loro).

Il servizio di posta elettronica, per esempio, è stato uno dei primi servizi utilizzati in internet, dunque ha una porta molto piccola, il numero 25. Quindi se si vuole mandare un messaggio di posta elettronica a un amico, bisogna prima specificare l’indirizzo IP del destinatario e poi indicare la porta 25. Un altro protocollo è il protocollo FTP (File Transfer Protocol). A seguito di un’autenticazione si può accedere al file system di un’altra persona ed effettuare il download di un file particolare sul proprio. L’FTP utilizza le porte 20 e 21.

(Per realizzare un protocollo di questo livello è necessario utilizzare i protocolli di livello più basso.)

Il vantaggio di utilizzare queste porte è che se c’è un server FTP attivo questo starà in ascolto sempre sulla porta 20, indipendentemente da quale PID gli è assegnato dal sistema operativo. La funzione principale del livello di trasporto è quindi il multiplexing e il de-multiplexing (ossia la virtualizzazione nella rete) dei processi che girano nella macchina. Infatti, le porte predefinite possono essere usate in ricezione per i server quando vogliono ricevere un messaggio, ma quando vogliono inviare una risposta al client vengono utilizzate porte molto grandi (dette “effimere” / ephemeral). Un esempio si ha col protocollo http, che di base ascolta sulla porta 80.

(Si ricorda che mentre si possono avere più client, e quindi c’è bisogno di porte effimere, di server ce n’è solo uno, dunque questo può utilizzare una porta standard)

Esempio pratico

Esempio: Il Browser di Alice vuole accedere al sito di Bob, per fare ciò il server di Bob si aspetta le richieste sulla porta 80, tuttavia il Browser di Alice dovrà ricevere una risposta per poter visualizzare la pagina. Dunque, appena prima di inviare il messaggio il browser riceve assegnato un numero di porta effimero. Tale messaggio dovrà quindi contenere anche la porta effimera, così facendo quando poi il web server dovrà mandare il file di risposta basterà scambiare i dati tra sorgente e destinatario e il client otterrà le informazioni richieste. Dunque, i router dovranno fare l’operazione di multiplexing per permetter a più applicazioni di effettuare richieste sulla rete e l’operazione di de-multiplexing per distribuire le risposte.

Nota tecnica

Nota: attualmente tutti i protocolli di rete prevedono che i messaggi siano inviati con una parte iniziale (un header), una piccola parte finale e una grossa parte centrale chiamata payload, ossia il carico di lavoro. Le informazioni ausiliarie, come gli indirizzi, si trovano negli header. Poiché un router si occupa solo dell’instradamento dell’informazione non c’è motivo per un router di implementare protocolli oltre il livello 3. La comunicazione a pari livello (per esempio tra protocolli http mittente e destinatario) avviene attraverso un canale virtuale costruito da altri livelli di protocollo. I protocolli di trasporto, TCP e UDP, e quelli Applicativi (es http) parlano quindi direttamente tra mittente e destinatario. Tuttavia, quando si scende a livello di network (quindi relativo all’IP) il pari livello si trova a distanza di un HOP (a distanza di un router), il Secondo HOP sarà tra il livello IP del primo router al livello IP del secondo router, fino ad arrivare alla macchina destinataria.

Poiché la comunicazione avviene solo a pari livello, quando si osserva la comunicazione tra due protocolli si possono ignorare tutti gli altri (quelli sottostanti per l’incapsulazione e quelli superiori perché non necessari per la comprensione della comunicazione).

Concetto di incapsulamento

Il concetto di incapsulamento: abbiamo un payload (contenuto), e il protocollo applicativo aggiunge il suo header: tale intestazione verrà letta e tolta dal livello 5 (applicativo) destinatario. Ai livelli inferiori abbiamo un comportamento analogo. La differenza è che al livello 4 il payload è sia il payload che l’header di livello 5. Il livello 4 quindi aggiunge l’header livello 4 (ad esempio l’header TCP) e tale header verrà interpretato dal protocollo 4 destinatario (per poter sapere qual è la porta destinataria). Il destinatario toglie l’header 4 e il payload viene recapitato all’applicazione che ha richiesto l’informazione (e che costituisce al livello 5).

Al livello 3 succede la stessa cosa: il payload con header 5 e header 4 è trattato come payload e ci viene aggiunto un header di livello 3 (interpretato dai network). Al livello 2 succede la stessa cosa che al livello 3, con la differenza che viene aggiunto anche un footer, in cui di solito si trova una verifica di integrità del messaggio (correzione degli errori, o meglio scarto del messaggio in caso di errori). Un esempio di protocollo di livello 2 di questo tipo è l’Ethernet. Dal livello 3 in poi l’aggiunta e rimozione dell’header avviene ad ogni Hop, poiché ogni router lo toglie e mette il proprio.

(Dal punto di vista del protocollo IP tutto quello che è contenuto sotto all’header di livello 3 (quindi anche header di livello 5 e livello 4) è considerato payload).

Non esiste un header di livello 1 perché a quel livello abbiamo i dispositivi fisici, per passare dal livello 2 all’1 non serve allungare il messaggio perché si passa direttamente alla codifica tramite segnali elettrici.

Utilizzo pratico per il programmatore

Come può il programmatore usare queste conoscenze a suo vantaggio? Sappiamo innanzitutto che il nostro programma girerà sulla macchina sotto forma di processo. Dal punto di vista del sistema operativo il nostro processo è qualcosa di chiuso in se stesso, costituito da un codice e dai vari segmenti dati (statici/stack/heap). È chiuso in se stesso perché io posso inviare tanti processi sulla stessa macchina e questi possono non interagire tra loro: ognuno di essi ha la propria macchina virtuale.

Tuttavia, ciò è un po’ limitante, perché a noi serve poter anche interagire con il mondo esterno, ad esempio tramite l’interazione coi dispositivi di input output. Nei dispositivi POSIX ciò avviene tramite l’utilizzo dei File Descriptor (i predefiniti per i programmi in esecuzione sono stdin, input da tastiera, stdout, stderr, output sul terminale per stampa normale e segnalazioni di errore). Tipicamente input e output sono bufferizzati (tranne stderr). Questi file Descriptor sono come dei buchi nel processo chiuso per fare entrare e uscire informazioni.

Se noi vogliamo aggiungere una primitiva di comunicazione che ci permetta di scrivere o ricevere messaggi attraverso la rete possiamo pensare di fare la stessa cosa, e di usare quindi sempre il concetto di file Descriptor. Infatti, mentre quelli di default sono tipicamente visti come dei file (e sono sempre presenti grazie al sistema operativo) per poter accedere a un file vero e proprio è necessario chiamare una system call OPEN per poter usare un nuovo file Descriptor (quello del file che ci serve modificare o leggere). La OPEN in particolare prende come parametro il nome del file e restituisce il file Descriptor come un intero, che però rappresenta un buco nel processo (stdin, stdout e stderr hanno di base 0, 1, 2 assegnatoli). Per poter leggere e scrivere basta usare le call READ e WRITE col File Descriptor. Quando si chiude un file con la CLOSE il buco viene “tappato”.

Per la comunicazione di rete si fa in maniera analoga, ma anziché OPEN si usa SOCKET: questa system call restituisce un file Descriptor che rappresenta un buco nel processo perché possa interagire con il protocollo di livello 5 della NIC. (Il SOCKET è una virtualizzazione della comunicazione via rete attraverso la NIC).

Reti 2

Avevamo accennato i SOCKET come comitiva di comunicazione utilizzabile da un’applicazione. L’idea è di avere dei processi che mandiamo in esecuzione, tali processi possono aprire dei “buchi” dai quali poter far entrare e uscire sequenze di byte. Il funzionamento è analogo a quello dei file Descriptor per accedere al file system: la differenza è che la system call per creare il Descriptor in questo caso è “socket()” (fd = socket()).

Il file Descriptor è necessario perché il processo non ha i mezzi per uscire dalla propria scatola virtuale, ma il sistema operativo, tramite i suoi privilegi, sì (per questo si usano le system call).

Nei sistemi POSIX sono realizzati due tipi principali di socket: quelli di tipo “DATAGRAM” e quelli di tipo “STREAM”.

Socket di tipo Datagram

I Socket di tipo Datagram permettono di ricevere e inviare messaggi, che vengono chiamati datagrammi. Un datagramma è una certa quantità di byte che contiene delle informazioni codificate in qualche modo (da parte dell’applicazione, che seguirà una certa convenzione in modo che si possano poi decifrare). Questi datagrammi, quindi, oltre al payload avranno delle intestazioni (gli header) che dipendono dal protocollo usato (cioè dal suo livello). Si ricorda che le intestazioni contengono gli indirizzi, mentre il payload è il messaggio.

Con una struttura di tipo Datagram il dispositivo A può indicare un’applicazione di destinazione B e noi non ci preoccupiamo di come sia fatto il meccanismo di trasmissione.

Le system call utilizzabili sul file Descriptor di tipo socket sono la “send(fd, …)” che serve per inviare le informazioni, e contiene un file Descriptor, (e, in genere) un puntatore all’area di memoria contenente i dati che voglio inviare e la quantità di byte che vogliamo inviare, e la “recv(fd, …)” che serve per ricevere i dati.

Il protocollo di tipo DATAGRAM, nella sua implementazione classica, ha le stesse caratteristiche dei protocolli che si usano al livello 3 (quindi il protocollo IP), dunque nell’header ci sarà la rappresentazione di un numero su 16 bit che rappresenterà la lunghezza effettiva del payload. Chi vuole inviare deve inoltre specificare un buffer (tramite un puntatore a un’area di memoria).

Esempio: char buf[1024]; send(fd, buf, 1024);

Dalla parte del ricevente, bisogna fare una cosa analoga: serve aver dichiarato un buffer di lunghezza adeguata a ricevere il messaggio ed effettuare la ricezione passando come parametro un puntatore all’area di memoria e la lunghezza del messaggio. Ma come fa il ricevente a sapere di quanti byte è il messaggio? Di base non può saperlo, anche in caso di comunicazione a priori ci potrebbero essere dei fraintendimenti. Se arrivassero meno byte del previsto, la recv restituirebbe come valore il numero di byte effettivamente scritti nel buffer (lo fa comunque, ma è significativo solo se è un numero diverso da quello che ci aspettavamo). Se arrivassero più byte del previsto, verrebbero letti e scritti solo i primi x byte (dove x è la dimensione del buffer di ricezione) e tutti i restanti verrebbero buttati via.