Risposte terza verifica - a.a. 2012-2013

Prima parte

1 - le connessioni persistenti consistono nell'uso di una stessa connessione TCP per tutte le richieste-risposte dirette da uno user agent verso lo stesso server HTTP, mentre pipeline rappresenta la possibilità di inviare tutte le richieste senza attendere la ricezione delle rispettive risposte. Il vantaggio è di una maggiore velocità, avendo eliminato le attese dei tempi di setup e dei RTT.
2 - l'autenticazione Basic prevede l'invio delle credenziali di autenticazione in forma crittograficamente non sicura, facendo uso di una semplice trasformazione base64. Quella Digest invece fa uso di un nonce di sfida, usato come vettore di inizializzazione di un algoritmo hash MD5 usato per comunicare le credenziali in forma crittograficamente sicura.
3 - una Helper Application consiste in un programma che può essere eseguito in modo indipendente dal Browser, e che viene da questo invocato come processo figlio, passandogli come opzione di input il riferimento ad una copia dell'oggetto ricevuto nel body della risposta HTTP. Un plugin invece è un programma che non utilizza servizi di output grafico, ed offre al browser dei servizi di elaborazione ulteriori, il cui risultato è poi visualizzato dal browser stesso.
4 - in una applicazione web di tipo tradizionale le pagine visualizzate sono esattamente quelle inviate da parte del web server; in Ajax invece queste sono il risultato delle elaborazioni svolte da una applicazione javascript in esecuzione da parte del browser, eseguite a partire da dati recuperati (in formato XML o JSON) da uno o più server web.
5 - viene inoltrata una richiesta HTTP verso la URI indicata dall'attributo action dell'elemento HTML form che include il submit. La presenza dell'attributo method=POST determina che i valori espressi mediante i controlli siano serializzati in una query_string inviata nel body HTTP della richiesta.
6 - le richieste HTTP inviate con il metodo GET codificano i valori espressi dai controlli della form mediante una query_string che è concatenata alla URI indicata dalla action, separata dalla stessa da un punto interrogativo. Il server Web, prima di invocare il CGI, copia il valore della query_string in una variabile di ambiente, a cui il CGI può accedere e venirne così a conoscenza.
7 - i cookies sono stringhe inviate da server web a browser mediante l'intestazione Set-Cookie:, dal Browser memorizzate, e quindi dallo stesso re-inviate mediante l'intestazione Cookie: ogni volta che si effettua una richiesta diretta verso lo stesso server e path. Dato che la URI invocata corrisponde ad un cgi, questo utilizza il cookie come chiave di interrogazione di un DataBase, mediante il quale recupera lo stato della sessione dell'utente che interagisce tramite Browser, e personalizza così l'aspetto delle pagine inviate nelle risposte.
8 - un feed RSS è un documento XML, recuperabile in associazione ad una URI HTTP, in cui sono presenti informazioni sul canale, come titolo, autore, data di aggiornamento, ed informazioni legate a diversi item, ciascuno dei quali rappresenta un sommario relativo ad una pagina, od un post di blog.
9 - i surrogati hanno il compito di replicare i contenuti disponibili presso un server centrale ed unico, al duplice scopo di ripartire il carico di richieste su di un maggior numero di serventi, e di ridurre l'occupazione di banda sui collegamenti internazionali. Quest'ultimo risultato è conseguito grazie al meccanismo di instradamento delle richiesta, che provvede ad individuare il surrogato più idoneo ad un determinato client, in base alla valutazione della distanza tra client e l'insieme dei surrogati disponibili; tale distanza sarà ovviamente espressa in termini di numero di collegamenti, di sottoreti, e di sistemi autonomi, che dovrebbero essere attraversati.
10 - i chunks sono letteralmente pezzi di file. Un file distribuito da una rete peer to peer viene suddiviso in chunks, in modo che ogni peer possa detenerne un sottoinsieme, e sviluppare una politica di scambio tra i pezzi in suo possesso, e quelli in possesso di altri peer. Quando i chunck sono generati per la prima volta, per ognuno di essi è prodotto un hash, distribuito assieme i chunks stessi da parte del seeder. Quando un peer entra in possesso di un chunk, verifica che l'hash calcolato fornisca lo stesso risultato.
11 - finché non è completata la procedura di registrazione, non esiste nessuna associazione tra l'Address of Record ed il Contact Address, ovvero tra la URI da chiamare e l'indirizzo IP presso il quale la stessa è raggiungibile. Si può derogare a questa esigenza, qualora lo UA sia in esecuzione presso un host il cui nome a dominio è risolto dal DNS con il suo IP effettivo.
12 - un dialogo SIP corrisponde all'insieme di tutte le transazioni che intercorrono tra due UA nel corso della medesima chiamata. I messaggi del dialogo sono accomunati dal presentare tutti lo stesso identificativo Call-Id, e la stessa coppia from-tag e to-tag, espressi il primo come un header SIP, e gli ultimi due come parametri delle intestazioni From e To.
13 - lo viene a sapere dalla analisi dell'SDP presente nel body dei messaggi SIP di inizio sessione
14 - I payload dinamici sono identificati dai codici di PT da 96 a 127, a cui il profilo Audio-Video AVP non associa nessun tipo di codec, ma la corrispondenza tra PT e codec è definita dall'SDP scambiato ad inizio sessione, e questa associazione è valida solo per la durata della sessione stessa. Sono stati definiti per permettere l'utilizzo di codec sviluppati in tempi successivi alla emissione delle specifiche dell'RTP.
15 - si intende l'uso delle stesse porte UDP sia per il flusso RTP entrante (porta di destinazione) che per quello uscente (porta sorgente), in modo da permettere il funzionamento anche nel caso in cui un dispositivo è nattato, dato che il traffico uscente determina la creazione nel dispositivo NAT della corrispondenza necessaria a dirigere il traffico entrante verso lo UA corretto - e sopratutto verso la porta presso cui l'RTP è in ascolto.

Seconda parte

17 - - 20 - come da procedura illustrata

Terza parte

21 - alice@dock residente presso 192.168.1.100:5066 (vedi header Contact del pacch. n. 1) chiama bruno@dock residente presso 192.168.1.10:5060 (vedi header Contact del pacch. n. 4)
22 - si, c'è un proxy presso 192.168.1.10:5060, si capisce dal fatto che il secondo pacchetto, proveniente da tale socket, rappresenta la risposta temporanea 100 Trying, generata dal Proxy, in quanto presenta l'intestazione Server: OpenSER (1.3.0-tls (i386/linux)); inoltre, nel Record_Route al pacch. 4 compaiono due indirizzi
23 - sono annunciati 3 payload type dinamici
24 - è utilizzato il PT dinamico 98, che l'SDP mette in corrispondenza con il codec Speex operante a 16000 campioni/secondo. L'intervallo tra pacchetti, sempre descritto dall'SDP, è di 20 millisecondi
25 - i pacchetti 59 e 60 sono relativi alla stessa SSRC e presentano numeri di sequenza contigui, dunque la differenza dei rispettivi timestamp 4441-4121=320 rappresenta il numero di campioni rappresentati dal payload di un singolo pacchetto, che alla frequenza di campionamento di 16000 Hz corrisponde appunto all'intervallo temporale tra pacchetti indicato dall'SDP di 20 msec, ed infatti 320/(16*10³) = 2*10^-2
26 - si, operano in modalità simmetrica, come si può verificare osservando che l'RTP di alice usa porte UDP sorgente e destinazione pari a 8000 e 8004, mentre per quello di bruno le porte sono rispettivamente 8004 ed 8000, dunque ciascuno dei due usa come porta sorgente quella presso la quale vuole ricevere l'RTP entrante, corrispondente a quella indicata nell'SDP uscente.
27 - per entrambi i flussi si arriva ad una stima della banda di traffico IP pari a circa 44 kbps
28 - il payload di un pacchetto RTP corrisponde a 70 bytes
29 - se ogni 20 msec sono trasmessi 70 bytes, in un secondo viaggiano 70/0.02=3500 byte pari a 28000 bit; dunque il segnale vocale è codificato a 28 kbps.
30 - dato che il codec produce 16000 campioni/secondo e 28000 bit/secondo, realizza un tasso di codifica di 28/16=1.75 bit/campione