7) Il livello cinque (Application)

Nel nostro modello di architettura (e anche nell'architettura TCP/IP) sopra il livello transport c'è il livello application, nel quale viene effettivamente svolto il lavoro utile per l'utente.

In questo livello si trovano diverse tipologie di oggetti:

protocolli di supporto a tutte le applicazioni, come per esempio il DNS (Domain Name System, RFC 1034 e 1035);
protocolli di supporto ad applicazioni di tipo standardizzato, come ad esempio:
- SNMP (Simple Network Management Protocol, RFC 1157) per la gestione della rete;
- FTP (File Transfer Protocol, RFC 959) per il trasferimento di file;
- SMTP e POP3 (Simple Mail Transfer Protocol, RFC 821, e Post Office Protocol, RFC 1225) per la posta elettronica;
- HTTP (HyperText Transfer Protocol, RFC 1945) alla base del World Wide Web (WWW);
applicazioni scritte in conformità ai protocolli di cui sopra;
applicazioni proprietarie, basate su regole di dialogo private (ad esempio, un'applicazione di tipo client/server per la gestione remota di un magazzino).

7.1) Il DNS

Poiché riferirsi a una risorsa (sia essa un host oppure l'indirizzo di posta elettronica di un utente) utilizzando un indirizzo IP numerico (della forma x.y.z.w) è estremamente scomodo, si è creato un meccanismo tramite il quale tali risorse possono essere identificate tramite un nome logico, cioé una stringa di caratteri (molto pù comprensibile per un essere umano) quale ad esempio:

sparc1.unimi.it (riferimento ad un host);
john@cern.ch (indirizzo di posta elettronica).

La corrispondenza fra gli indirizzi IP numerici ed i nomi logici si effettua mediante l'uso del DNS.

Esso consiste di:

uno schema gerarchico di nominazione, basato sul concetto di dominio (domain);
un database distribuito che implementa lo schema di nominazione;
un protocollo per il mantenimento e la distribuzione delle informazioni sulle corrispondenze.

Il funzionamento, in breve, è il seguente:

quando un'applicazione deve collegarsi ad una risorsa di cui conosce il nome logico (ad es. sparc1.unimi.it), invia una richiesta al DNS server locale (l'applicazione chiama per questo una apposita procedura di libreria detta resolver);
il DNS server locale, se conosce la risposta, la invia direttamente al richiedente. Altrimenti interroga a sua volta un DNS server di livello superiore, e così via. Quando finalmente arriva la risposta, il DNS server locale la passa al richiedente;
quando l'applicazione riceve la risposta (costituita del numero IP della risorsa in questione) crea una connessione TCP con la (o spedisce segmenti UDP alla) destinazione, usando l'indirizzo IP testé ricevuto.

Lo spazio dei nomi DNS è uno spazio gerarchico, organizzato in dominii, ciascuno dei quali può avere dei sottodominii.

Esiste un insieme di dominii di massimo livello (top-level domain), i più alti nella gerarchia.

Nel caso di un host, la forma del nome logico è costituita da un certo numero di sottostringhe separate da punti, come nell'esempio seguente:

host.subdomain3.subdomain2.subdomain1.topleveldomain

dove:

la prima sottostringa (quella più a sinistra) identifica il nome dell'host;
le altre sottostringhe (tranne quella più a destra) identificano ciascuna un sottodominio del dominio di cui alla sottostringa seguente;
l'ultima sottostringa (quella più a destra) identifica il top-level domain di appartenenza.

Per gli USA sono definiti, fra gli altri, i seguenti top-level domain:

com	aziende
edu	università
gov	istituzioni governative
mil	istituzioni militari
net	fornitori d'accesso
org	organizzazioni non-profit

Fuori degli USA, ogni nazione ha un suo top-level domain. Ad esempio:

au	Australia
ch	Svizzera
fr	Francia
it	Italia
jp	Giappone
uk	Inghilterra

Ogni dominio è responsabile della creazione dei suoi sottodominii, che devono essere registrati presso una apposità autorità.

Esempi di sottodominii sono:

cern.ch	il CERN a Ginevra, Svizzera
cnr.it	il Consiglio Nazionale delle Ricerche, Italia
mit.edu	il Massachussetts Institute of Technology, USA
nasa.gov	la NASA, USA
unige.ch	Università di Ginevra, Svizzera
uniroma1.it	Università di Roma "La Sapienza", Italia
dsi.uniroma1.it	Dip. di Scienze dell'Informazione, Università di Roma "La Sapienza"

L'estensione di un dominio è del tutto indipendente da quella delle reti e sottoreti IP.

Ogni dominio ha la responsabilità di fornire il servizio DNS per quanto di propria competenza. Ossia, deve poter rispondere a interrogazioni riguardanti tutti gli host contenuti nel dominio stesso.

Ciò si ottiene predisponendo un name server (o più di uno), che è un processo in grado di gestire le seguenti informazioni:

informazioni di corrispondenza fra nomi simbolici e indirizzi IP. Per ogni host del dominio esiste un resource record che contiene tali informazioni; tale record è detto authoritative record, in quanto è gestito dal DNS server responsabile del dominio (che è supposto fornire sempre informazioni corrette e aggiornate);
l'identità dei name server responsabili dei sottodominii inclusi nel dominio, così da poter inviare loro le richieste che gli pervengono dall'alto della gerarchia;
l'identità del name server responsabile del dominio di livello immediatamente superiore, così da potergli inviare le richieste che gli pervengono dal basso della gerarchia.

Una richiesta che arriva a un name server può dunque viaggiare verso l'alto nella gerarchia oppure (dal momento in cui perviene a un top-level domain server) verso il basso, a seconda dei casi. Quando una risposta ritorna indietro, essa viene tenuta dal server in una sua cache per un certo periodo; qui costituisce un nuovo record, detto cached record perché contiene della informazione che potrebbe anche divenire, col passare del tempo, obsoleta e non più corretta.

Un esempio di resource record (relativo a un host) è:

spcw.dsi.uniroma1.it 86400 IN A 151.100.17.110

dove:

`spcw.dsi.uniroma1.it`	domain_name: nome simbolico.
`86400`	time_to_live: la quantità di tempo (in secondi) trascorsa la quale il record viene tolto dalla cache.
`IN`	class: classe del record (Internet in questo caso).
`A`	type: tipo del record (Address in questo caso).
`151.100.17.110`	value: indirizzo IP numerico.

7.2) La posta elettronica

La posta elettronica è uno dei servizi più consolidati ed usati nelle reti. In Internet è in uso da circa 20 anni, e prima del WWW era senza dubbio il servizio più utilizzato.

Un servizio di posta elettronica, nel suo complesso, consente di effettuare le seguenti operazioni:

comporre un messaggio;
spedire il messaggio (a uno o più destinatari);
ricevere messaggi da altri utenti;
leggere i messaggi ricevuti;
stampare, memorizzare, eliminare i messaggi spediti o ricevuti.

Di norma, un messaggio ha un formato ben preciso. In Internet un messaggio ha un formato (definito nell'RFC 822) costituito da un header e da un body, separati da una linea vuota.

Lo header è a sua volta costituito da una serie di linee, ciascuna relativa a una specifica informazione (identificata da una parola chiave che è la prima sulla linea); alcune informazioni sono:

`To`	indirizzo di uno o più destinatari.
`From`	indirizzo del mittente.
`Cc`	indirizzo di uno o più destinatari a cui si invia per conoscenza.
`Bcc`	blind Cc: gli altri destinatari non sanno che anche lui riceve il messaggio.
`Subject`	argomento del messaggio.
`Sender`	chi materialmente effettua l'invio (ad es. nome della segretaria).

Il body contiene il testo del messaggio, in caratteri ASCII. L'ultima riga contiene solo un punto, che identifica la fine del messaggio.

Gli indirizzi di posta elettronica in Internet hanno la forma:

username@hostname

dove username è una stringa di caratteri che identifica il destinatario, e hostname è un nome DNS oppure un indirizzo IP.

Ad esempio, bongiovanni@dsi.uniroma1.it è l'indirizzo di posta elettronica dell'autore di queste dispense.

La posta elettronica viene implementata in Internet attraverso la cooperazione di due tipi di sottosistemi:

Mail User Agent (MUA);
Mail Transport Agent (MTA).

Il primo permette all'utente finale di:

comporre messaggi;
consegnarli a un MTA per la trasmissione;
ricevere e leggere messaggi;
salvarli o eliminarli.

Il secondo si occupa di:

trasportare i messaggi sulla rete, fino alla consegna a un MTA di destinazione;
rispondere ai MUA dei vari utenti per consegnare loro la posta arrivata; in questa fase l'MTA richiede ad ogni utente una password per consentire l'accesso ai messaggi.

Corrispondentemente, sono definiti due protocolli principali per la posta elettronica:

SMTP (Simple Mail Transfer Protocol, RFC 821) per il trasporto dei messaggi:
- dal MUA di origine ad un MTA;
- fra vari MTA, da quello di partenza fino a quello di destinazione;
POP3 (Post Office Protocol versione 3, RFC 1225) per la consegna di un messaggio da parte di un MTA al MUA di destinazione.

Recentemente sono stati introdotti altri protocolli più sofisticati, quali IMAP (Interactive Mail Acces Protocol, RFC 1064) e DMSP (Distributed Mail System Protocol, RFC 1056), il cui supporto però non è ancora molto diffuso nel software disponibile agli utenti.

Come avviene la trasmissione di un messaggio? Supponiamo che l'utente

pippo@topolinia.wd

spedisca un messaggio a

minnie@paperinia.wd

e immaginiamo che:

Pippo usi un MUA configurato per consegnare la posta ad un SMTP server in esecuzione sull'host mailer.topolinia.wd;
Minnie abbia un MUA configurato per farsi consegnare la posta da un POP3 server in esecuzione sull'host mailer.paperinia.wd.

La sequenza di azioni che hanno luogo è la seguente:

Pippo compone il messaggio col suo MUA, che tipicamente è un programma in esecuzione su un PC in rete;
appena Pippo preme il pulsante SEND, il suo MUA:
- interroga il DNS per sapere l'indirizzo IP dell'host mailer.topolinia.wd;
- apre una connessione TCP ed effettua una conversazione SMTP con il server SMTP in esecuzione sull'host mailer.topolinia.wd, per mezzo della quale gli consegna il messaggio;
- chiude la connessione TCP;
Pippo se ne va per i fatti suoi;
il server SMTP di mailer.topolinia.wd:
- chiede al DNS l'indirizzo IP di paperinia.wd;
- scopre che è quello dell'host mailer.paperinia.wd;
- apre una connessione TCP e poi una conversazione SMTP con il server SMTP in esecuzione su quell'host e gli consegna il messaggio scritto da Pippo;
Minnie lancia il suo MUA;
appena Minnie preme il pulsante "check mail", il suo MUA:
- interroga il DNS per avere l'indirizzo IP dell'host mailer.paperinia.wd;
- apre una connessione TCP e poi una conversazione POP3 col server POP in esecuzione su mailer.paperinia.wd e preleva il messaggio di Pippo, che viene mostrato a Minnie.

Si noti che topolinia.wd e paperinia.wd in genere corrispondono a un dominio nel suo complesso e non ad un singolo host, al fine di rendere gli indirizzi di posta elettronica indipendenti da variazioni del numero, dei nomi logici e degli indirizzi IP degli host presenti nel dominio.

Nel DNS ci sono opportuni record detti di tipo MX (Mail Exchange), che si occupano di indicare quale host effetttivamente fa da server SMTP per un dominio.

Nel nostro esempio avremo, nel DNS server di Paperinia, i record:

mailer.paperinia.wd A     100.10.10.5
paperinia.wd        MX    mailer.paperinia.wd

Il secondo record è un record di tipo MX, e indica che tutta la posta in arrivo per

chiunque@paperinia.wd

deve essere consegnata all'host mailer.paperinia.wd, e cioé quello che ha l'indirizzo IP

100.10.10.5

Inoltre, non è detto che mailer.topolinia.wd consegni i messagi direttamente a mailer.paperinia.wd. E' possibile che le macchine siano configurate in modo da trasferire i messaggi attraverso un certo numero di server SMTP intermedi.

Infine, vanno citate due significative estensioni di funzionalità della posta elettronica, in via di progressiva diffusione:

possibilità di inviare messaggi di posta contenenti informazioni di qualunque tipo (per esempio programmi eseguibili, immagini, filmati, suoni, ecc.) attraverso lo standard MIME (Multipurpose Internet Mail Extension, RFC 1341 e 1521);
possibilità di inviare messaggi corredati di firma digitale o crittografati, attraverso lo standard in via di definizione S/MIME (Secure/MIME, RFC 1847).

Torna al sommario