Risposte Terza verifica - a.a. 2009-2010

Prima Parte

1) - Un elemento fondamentale è <a>, che consente di indicare una URI di destinazione se il teso corrispondente è cliccato, mentre ad es. elementi come <h1>, <b> producono rispettivamente una formattazione di tipo titolo e grassetto
2) - | IP | HTTP con header | HTML Head | HTML Body |
3) - copie degli oggetti HTTP sono contenute nella cache dello User Agent stesso, oppure in un proxy intermedio, oppure ancora da uno situato preso lo stesso provider, allo scopo di bilanciamento del carico. Il recupero (o meno) degli oggetti contenuti avviene per mezzo della intestazione If modified since, che riporta la data del'oggetto copia, che se più recente di quella dell'originale, produce una risposta Not Modified, che determina l'uso della copia locale.
4) - lo User Agent esegue una nuova query richiedendo la URI comunicata mediante l'header Location
5) - quando i diversi oggetti sono recuperati tutti da un medesimo server, mediante una singola connessione TCP
6) - uno User Agent invoca un diverso programma qualora venga cliccato un link che referenzia una URI con schema diverso da http (ad es mailto, o ftp), oppure quando le intestazioni HTTP dell'oggetto ricevuto indicano un ContentType particolare (ad es. application/pdf)
7) - javascript è eseguito presso lo UserAgent, e può produrre una modifica alla pagina html che si sta visualizzando
8) - i CGI sono programmi eseguiti dal server HTTP, che interfacciano la visualizzazione web con servizi come Database o risorse di calcolo remote, realizzando siti dinamici come CMS, wiki e blog
9) - un CGI è invocato grazie alla presenza della sua URI come parametro action dell'elemento HTML <form>
10) - il CGI riceve i parametri formali mediante variabili di ambiente e standard input, che sono forniti dal server web, il quale a sua volta vi riporta ciò che ha ricevuto dallo UserAgent per mezzo della sezione QueryString della URI che individua il CGI, oppure che lo UA ha posto nel Body della richiesta HTTP. Infine, lo UA configura QueryString e Body in base ai valori selezionati dall'utente per mezzo dei controlli HTML di tipo <input>, <select>, e altri. Per quanto riguarda i risultati della elaborazione di un CGI, sono comunicati mediante la pagina HTML creata in risposta dal CGI stesso.
11) - una CDN è costituita da un insieme di nodi di replica verso i quali sono dirottate le richieste altrimenti dirette verso il server di origine del contenuto, e può funzionare sia usando un DNS che restituisce l'indirizzo IP di un surrogato situato presso il client, sia presentando al client (all'interno di una pagina web) il link al surrogato più vicino, personalizzando la pagina in base all'IP da cui proveniva la richiesta originaria.
12 ) - Web Service rappresenta la possibilità di accedere ad uno o più servizi offerti da computer differenti da quello che viene direttamente interrogato, e si differenzia dai precedenti approcci essenzialmente perché il suo traffico è incapsulato in HTTP e per questo difficilmente bloccabile da eventuali firewall

13) - SIP si occupa di veicolare i messaggi di segnalazione VoIP. Inoltre, SIP permette di veicolare SDP, che è una sintassi di descrizione della tipologia di contenuti multimediali che saranno adottati nel corso della comunicazione. Infine, RTP ha lo scopo di incapsulare i veri e propri contenuti multimediali
14) - un Registrar permette di mettere in relazione l'AoR di un umano, con l'indirizzo IP presso cui l'individuo si è collegato alla rete, dovunque si trovi
15) - la richiesta al DNS dei RR SRV relativi al dominio della request-URI porta il chiamante a conoscenza del computer (e della porta di ascolto) destinato dall'intestatario dal dominio chiamato a gestire i messaggi SIP.
16 ) - la corrispondenza di Call-Id, fromtag e totag
17) - mediante l'elemento SDP m= inviato nel body dei messaggi SIP.
18) - il Playout Buffer permette di compensare le variazioni di tempo di transito dei pacchetti, mediante l'introduzione di un ritardo di riproduzione
19) - un server STUN permette di venire a conoscenza della corrispondenza che un NAT imposta tra il nostro indirizzo privato, e quello pubblico usato per comunicare il mondo esterno

Seconda Parte

20) - scelta del template,

21) - inserimento della poesia nel template
22) - modifica di colori e dimensioni del testo, rimozione o aggiunta di sezioni
23) - inserimento, al posto dei link presenti nella pagina originale:

un link alla propria email mailto:labint@proprionome.labint, con testo scrivimi
un link al proprio VoIP sip:proprionome@sip.labint, con testo chiamami
un link alla form che inseriremo al punto 26 form.html, con testo ordina
un link ad http://www.labint/, con testo indice dei siti
un link a scelta, tra i propri preferiti, con testo vedi anche

24) - upload sul server remoto via FTP

25) - copiare vristo.cgi sul proprio computer;
26) - copiare il file che contiene la form sul proprio computer e verificarne la raggiungibilità dal template

27) - modificare form.html in modo che

la action punti alla URI di vristo.cgi
il menù contenga qualcosa che ci piace
venga richiamato l'uso dello stesso foglio di stile adottato dal template originario

30) - modifica di vristo.cgi perché il mittente della email risulti labint@proprionome.labint
31) - trasferire i files form.html e vristo.cgi presso il computer remoto
32) - eseguire un ordine, inviandolo a alef@alef.labint

Terza Parte

33) - analizzando il capture SIP con Telephony, VoIP calls, e Graph, osserviamo 4 INVITE, a seguito dei quali la sessione diviene sendonly, poi di nuovo send-receive, e quindi receiveonly. Il primo cambiamento si determina in base all'elemento a=sendonly presente nelle sezioni relative ai media, presenti nell'SDP che compare nell'INVITE, e per gli altri succede una cosa analoga
34) - il .234 trasmette audio verso la porta 5052, e video verso 5064, e lo stesso avviene per il .156,

35) - Si, siamo nelle condizioni di RTP simmetrico, dato che per ogni UA le porte di uscita ed ingresso corrispondono; questo è utile nell'attraversamento NAT, dato che l'RTP uscente crea la corrispondenza nel NAT, che può esere usata per riscrivere correttamente la porta dell'RTP entrante

36) - il codec audio (Speex) è mappato sul payload type 113, ed il video (h.261) sul 31. Questa corrispondenza viene stabilita mediante l'offerta dell'SDP, che all'elemento m= elenca i possibili PT, a cui segue un SDP di risposta che stabilisce il PT che verrà in seguito usato.
37) - Speex adotta un campionamento a 16.000 campioni/secondo, come descritto nell'elemento a=rtpmap:113 Speex/16000/1 dell'SDP
38) - Il timestamp dei pacchetti RTP audio si incrementa di 320 (campioni), che se Tc = 1/fc = 1/16000 = 62,5 usec, corrisponde ad una durata di 20 msec
39) - dato che i 52 bytes di payload rappresentano 320 campioni, si ottiene che ogni campione è codificato (con Speex) utilizzando 52*8/320 = 1,3 bit
40) - dato che i 52*8 = 416 bit di payload sono prodotti ogni 20 msec, si determina una velocità di 20800 bps
41) - dato che i 52 byte di payload sono intestati da 106 - 52 = 54 byte, l'efficienza é pari a 52/106 = 0,4905... ossia di circa il 49%