Esercizi – Strato di applicazione

Esercizio 4.1.
Con riferimento alla gerarchia DNS riportata in Figura 4.7, si chiede di suddividere in zone il dominio ac.nz in modo che il numero di queries richiesto per la risoluzione del nome ocean.physics.auckland. ac.nz da parte di un host esterno al dominio ac.nz sia esattamente 4 e il numero di zone sia il minimo possibile.

Figura 4.7 Esempio di nomi di dominio (Esercizio 4.1).

Esercizio 4.5.
Con riferimento all’Esempio 4.2, ipotizzando che il name server locale ns.math.auckland.ac.nz sia dotato di cache e che i record relativi alla precedente interrogazione per l’host flower.deib.polimi.it siano ancora nella cache, si chiede quante queries sono necessarie per ottenere l’indirizzo IP dell’host tree.deib.polimi. it con risoluzione ricorsiva e con risoluzione iterativa.

La risoluzione ricorsiva richiede quattro queries in quanto la precedente risoluzione del nome flower.deib.polimi. it non è di alcuna utilità. Invece, nel caso di risoluzione iterativa le queries richieste sono solo due, in quanto il NS locale ns.math.auckland.ac.nz conosce l’indirizzo IP per il NS autoritativo del dominio deib.polimi. it e quindi la risoluzione del nome avviene con interrogazione diretta tra due NS locali.

Figura 4.11 Risoluzione ricorsiva del nomi secondo l’Esempio 4.2 (Esercizio 4.5).

Esercizio 4.7.
Si chiede di rappresentare graficamente lo scambio di messaggi che ha luogo tra due MTA utilizzando il protocollo SMTP per trasferire dal client ducato.com al server fiorino.com una e-mail con mittente Andrea all’indirizzo andre@scudo.com e destinatario Mariangela all’indirizzo mari@guelfo.com. Il messaggio ha come soggetto “Buon compleanno” e contiene le righe di testo “Tanti auguri”, “da tutti noi”, “i cugini”.

La Figura E4.1 mostra la successione di comandi e risposte che realizza il trasferimento della e-mail richiesta dal MTA client ducato.com al server fiorino.com.

Figura E4.1 Trasferimento di e-mail con il protocollo SMTP secondo l’Esercizio 4.7.

Esercizio 4.10.
Si chiede di rappresentare graficamente l’accesso dell’utente Linda a un server FTP. Dopo l’autenticazione con password “Hello”, Linda chiede di ricevere il file lastnews.pdf dalla directory /home/ news/updates. Il server risponde che il file richiesto non si trova nella directory indicata. Quindi Linda chiede l’elenco dei file nella directory e scopre che il file di suo interesse si chiama last-updates.pdf. Ne chiede dunque il download che viene effettuato con successo e lascia il collegamento FTP aperto.

Come mostrato in Figura E4.2, Linda apre la connessione FTP fornendo le proprie credenziali e quindi il client FTP definisce la propria porta 8888 per consentire l’apertura della connessione dati per il trasferimento di file. Non ha successo il recupero del file lastnews.pdf nella directory /home/news/updates da cui invece viene recuperato il file last-updates.pdf utilizzando una nuova connessione dati TCP tra la porta 20 del server e la porta 8888 del client.

Figura E4.2 Trasferimento di file con il protocollo FTP secondo l’Esercizio 4.10.

Esercizio 4.12.
Un client accede a un server tramite una rete dorsale che mette a disposizione un canale dedicato di capacità e la distanza lungo il canale tra client e server è . Si chiede di determinare il tempo totale T di recupero dal server di una pagina HTML di 1000 byte che contiene 8 immagini di 25 kbyte ognuna adottando connessioni non-persistenti, oppure persistenti. Si assume che la dimensione dei messaggi di controllo del protocollo HTTP sia trascurabile e che la chiusura di una connessione TCP possa essere attuata in un tempo trascurabile.

Si calcolano preliminarmente i tempi di propagazione dei messaggi lungo il canale e i tempi di trasmissione dei messaggi. Il tempo totale di propagazione di un messaggio dal client al server e viceversa è dato da

   

mentre i tempi di trasmissione della pagina HTML e di ciascuno degli oggetti sono

   

   

Il tempo richiesto per il trasferimento di ogni oggetto è nel caso di connessioni non persistenti, mentre si riduce a con connessioni persistenti, dato che in quest’ultimo caso la connessione TCP viene aperta una volta soltanto. Dato che i messaggi di controllo hanno dimensione trascurabile, l’apertura della connessione TCP richiede un tempo fisso dato da RTT, indicato come e il tempo di recupero dal server di ogni elemento, attuato dal messaggio GET, è semplicemente dato dal tempo di propagazione RTT, indicato come , e dal tempo di trasmissione dell’elemento stesso. Quindi, nel caso di protocollo HTTP con connessioni non persistenti si ottiene

   

Nel caso di connessioni persistenti occorre considerare che la pagina web e gli oggetti sono richiesti e recuperati con una sola connessione TCP e quindi analogamente si ottiene

   

Esercizio 4.19.
Si chiede di determinare la condizione che in un’architettura peer-to-peer di N peer capacità di upload , minore della capacità di download , determina una riduzione di almeno un fattore F del tempo totale di distribuzione di un file di dimensione D byte.

Il numero k di frammenti in cui viene decomposto un file determina l’entità della riduzione del tempo di distribuzione. Quindi la condizione richiesta viene determinata imponendo una frammentazione che risulti in un tempo di distribuzione F volte inferiore rispetto a quanto richiesto da un file non frammentato, e cioè

   

Risolvendo la disequazione nella variabile k, si ricava

   

Questa relazione determina anche il limite sul fattore di riduzione del tempo totale di distribuzione che si può conseguire con la frammentazione del file

   

Risulta interessante osservare come la condizione finale trovata sul numero k di frammenti non dipenda dai parametri di distribuzione D e .