• MIME (RFC 822)

Per capire meglio l'architettura vedi slide 86

Torna su

Torna su

Torna su

Torna su

1. Content distribution
   • Web caching
   • Content distribution networks
2. P2P
   • P2P centralizzato - Eg. Napster
   • P2P distribuito - Eg. Gnutella
   • P2P ibrido - Eg. Kazaa
3. Scalability
4. Socket programming
   • Socket programming with TCP
   • Socket programming with UDP
5. Costruire un semplice Web server

Content distribution

• Propagazione: tempo e velocità di propagazione dei byte
• trasmissione legata alla banda (dtrans = Lunghezza/ Rate{portata})
• coda dei pacchetti che dipende dalla prestazioni del router e dei protocolli di trasporto
• tempo di processo legato all’header del pacchetto e all’instradamento dei router

Le strategie per ridurre il ritardo sono chiamate di Content Distribution. Tutte agiscono sul tempo di trasmissione aumentando e diminuendo l’uso della banda. Esse sono:

Web caching

Content distribution networks

Torna su

P2P

Non si usa un’architettura client-server (richiesta a un fornitore di servizio) ma host che fungono sia da client che da server. Distribuire i contenuti non significa però diminuirli.

Ci sono tre tipi di file sharing:

1. lookup: per avere la risorsa x devo fornire uno o più host che mi dicono ciò che voglio
2. data transfert: permette a un host di prendere le risorse da altri (host to host)

P2P centralizzato - Eg. Napster

• infrazione di copyright: il server non sa cosa si inviano tra loro gli host perchè il trasferimento dei file è decentralizzato

P2P distribuito - Eg. Gnutella

P2P ibrido - Eg. KaZaA

In quest'architettura c'è un super peer cioè un gruppo leader che funge da server, collegati ciascuno ad altrettanti host tutti attraverso il protocollo TCP.

Torna su

La scalabilità di un protocollo è relativa all'efficacia del servizio di lookup (cioè quello che manda i messaggi di richiesta dei dati).

Socket programming with TCP

Socket programming with UDP

Costruire un semplice Web server

(nb. può servirci per costruire quello da fare per Sassi?)
Un web server si occupa di richieste HTTP e di tutti gli annessi e i connessi, cioè: accettare le richieste, analizzare l'header, ottenere le richieste dal server file system, creare una risposta al messaggio HTTP (header lines + file), mandare la risposta al client.\\

• request line, così formata: metodo (vedi dopo), URI, versione del protocollo.
  Ad esempio: GET/somedir/page.html HTTP/1.1

• status line, nella quale compare un codice a tre cifre che definisce la categoria del messaggio. Per conoscere il significato dei vari codici si può fare richiesta con un telnet, oppure andare su questa pagina. Ad esempio, una status line potrebbe essere: "HTTP/1.1 200 OK <CR><LF>"
• header:

• body, il contenuto della risposta.

File Transfer Protocol. Attivo sulla porta 21, apre due connessioni: una per il controllo e una per il trasferimento dati. Problemi:

E' persistente perciò la connessione viene tenuta aperta e si mantiene una sessione. Meglio ancora: è la connessione per il controllo del trasferimento che rimane aperta per tutta la sessione, mentre quella del trasferimento vero e proprio si apre e si chiude per ogni file trasferito.
Per autenticarsi occorre mandare username e password.

I comandi FTP sono delle stringhe di caratteri ASCII, che richiedono l'inserimento di una USER e di una PASSword per ogni sessione. Alcuni comandi:

• LIST, ritorna una lista di file nella directory corrente
• RETR, filename retrievers (gets) file. Obbliga il server a spedire una copia del file all'utente/server dall'altra parte della connessione.
• STOR, filename stores (puts) file onto remote host. Obbliga il server ad accettare i dati inviati tramite la connessione dati e salvarli.

Di seguito alcuni codici di ritorno dell'FTP:

• 125: data connection already open, transfer starting
• 200: command ok
• 220: service ready for new user
• 231: user logged out; service terminated
• 331: user ok, pass requied
• 332: need account for login
• 425: can't open data connection
• 452: error writing file

Torna su

Sample SMTP interaction

client: MAIL FROM <address@server.extension>
server: 250 server ok
client: RCPT TO <....@....>
server: recipient ok
client: DATA
server: 354 Enter mail
client: ...inizio email....

Alla fine si saluta scrivendo QUIT.

Riassumendo i comandi principali di un messaggio in SMTP sono: HELO, MAIL FROM, RCPT TO, DATA, QUIT.

SMTP viene usato anche tra server e server per l'invio effettivo di mail. NON c'è bisogno di autenticazioni.

MIME (RFC 822)

Il MIME (Multipurpose Internet Mail Extensions) è uno standard che estende il formato delle e-mail, consentendo di inviare altri tipi di informazione oltre al testo ASCII, come ad esempio testi scritto in lingue diverse dall'Inglese, immagini, suoni e filmati, o anche programmi.

Gli headers aggiuntivi del MIME sono:

• MIME-Version: se è presente nel messaggio significa che questo è formattato secondo lo standard MIME. Generalmente la versione è la 1.0
• Content-type: il tipo dei dati multimediali contenuti nel messaggio, descritti come tipo/sottotipo. Tra questi ricordiamo:
  • testo semplice: text/plain (che è il valore di default dell'header content-type)
  • testo html: text/html
  • immagine: eg, image/jpg
  • audio: eg, audio/mp3
  • video: eg, video/avi
• Content-transfer-encoding: metodo usato per decodificare i dati. Generalmente impostato come base 64

POP3

Torna su

Tipi di ritardo

• Propagazione: tempo e velocità di propagazione dei byte
• trasmissione legata alla banda (dtrans = Lunghezza/ Rate{portata})
• coda dei pacchetti che dipende dalla prestazioni del router e dei protocolli di trasporto
• processo: legato all’header del pacchetto e all’instradamento dei router

WEB CACHING

CONTENT DISTRIBUTION NETWORKS

• request line, così formata: metodo (vedi dopo), URI, versione del protocollo. Ad esempio: GET/somedir/page.html HTTP/1.1

(:table border=0 width=100% cellpadding=5 cellspacing=0:)

• Porte note

• Esempio di HTTP Message
• Implementare stati HTTP
• Proxy Server

Cosa sono?

Torna su

Nozioni preliminari

Torna su

Comunicazioni fra processi

Porte note

Le porte note (well known ports, per dirlo alla francese) sono delle porte dai valori compresi tra lo 0 e il 1023, che lo IANA (Internet Assigned Numbers Authority) ha associato a specifici servizi TCP e/o UDP. Tra le più importanti ricordiamo:

(:table width=50% border=0 cellpadding=5 cellspacing=0 align=left:) (:cellnr bgcolor=#d9e4f2 align=center:) Porta (:cell bgcolor=#d9e4f2 align=center:) Servizio (:cellnr width=20%:) 20 /tcp (:cell:) FTP (data) (:cellnr bgcolor=#f5f9fc valign=middle:) 21 /tcp (:cell bgcolor=#f5f9fc valign=middle:) FTP (controllo) (:cellnr width=20%:) 23 /tcp (:cell:) Telnet (:cellnr bgcolor=#f5f9fc valign=middle:) 25 /tcp (:cell bgcolor=#f5f9fc valign=middle:) SMTP (:cellnr width=20%:) 53 /tcp/udp (:cell:) DNS (:cellnr bgcolor=#f5f9fc valign=middle:) 80 /tcp (:cell bgcolor=#f5f9fc valign=middle:) HTTP (:cellnr width=20%:) 110 /tcp (:cell:) POP3 (:cellnr bgcolor=#f5f9fc valign=middle:) 143 /tcp (:cell bgcolor=#f5f9fc valign=middle:) IMAP4 (:tableend:)

Torna su

Che cosa definisce un protocollo applicativo?

Torna su

Che tipi di servizio richiede un'applicazione distribuita?

Torna su

Livello di trasporto: TCP vs UDP

(:cellnr bgcolor=#d9e4f2 colspan=2 align=center:)TCP (:cell bgcolor=#d9e4f2 colspan=2 align=center:)UDP

Ma se UDP non fa un cavolo, che utilità ha? Beh, innanzitutto è un protocollo più leggero (intestazione di 8 byte) e quindi comporta un basso consumo di banda. Poi il fatto di non creare alcuna connessione elimina i ritardi dovuti alla configurazione della comunicazione (non ci sono partecipanti da sincronizzare).

Torna su

WEB & HTTP

Le pagine web come tutti sappiamo sono composte da un gran numero di oggetti: un file html di base contiene infatti riferimenti ad altri oggetti: immagini jpg, applet java ecc... Ogni oggetto è indirizzabile con un URL: eg. "www.someschool.edu/someDept/pic.gif" identificherà il nome di un'immagine.

Attenzione! Ci sono delle differenze quando di parla di URL, URI e URN!

• URL = Universal Resource Locator: identifica la risorsa in modo globale attraverso la locazione della risorsa stessa ("su che server è")
• URI = Universal Resource Identifier: identifica la risorsa indipendentemente da dove si trova o dal nome con il quale è nota
• URN = Universal Resource Name: identifica la risorsa attraverso il nome anche se l'oggetto stesso non è reperibile (eg. voglio dare un nome alla documentazione di un software all'interno della mia rete aziendale)

Torna su

HTTP (Hyper Test Transfer Protocol)

Ne esistono due versioni diverse: la 1.0 e la 1.1 (come GDA d'altronde).

Attenzione! Mantenere la connessione aperta non significa avere gli stati.

HTTP Message

Nell' HTTP 1.0:

TOTALE = 2RTT + tempo di trasmissione per ogni oggetto.

• l'altra è detta PIPELING: il client manda richiesta per ogni oggetto che trova, senza aspettare di aver ricevuto gli oggetti trovati prima; il server crea una pipeline e glieli manda tutti insieme.

Ho due messaggi HTTP: REQUEST e RESPONSE

HTTP REQUEST MESSAGE

E' in ASCII ed è composto da tre parti:

• request line, così formata: metodo (vedi dopo), URI, versione del protocollo. Ad esempio: "GET/somedir/page.html HTTP/1.1"
• header line, così formata:
  • Host : www.someschool.edu
  • User-agent : Mozilla/4.0
  • Connection : Close (indico che voglio chiudere la connessione)
  • Accept-language : Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo)
  • infine, un <CR> (Carriage Return) e un <LF> (Line Feed) che indicano la fine del messaggio.
• body, che è il corpo del messaggio, con cui si può inviare roba al server.

I metodi che possono apparire nella request line sono i seguenti, divisi per versione del protocollo:

(:table border=0 width=80% cellpadding=5 cellspacing=0:) (:cellnr bgcolor=#d9e4f2 width=10% align=center:)HTTP 1.0 (:cell bgcolor=#d9e4f2 width=10% align=center:)HTTP 1.1 (:cell bgcolor=#d9e4f2 align=center:)Descrizione (:cellnr align=center valign=middle:)GET (:cell align=center valign=middle:)GET (:cell valign=middle:)Serve a richiedere dati al server, la risposta finisce nell'URL/URI (tanti server mandano le variabili direttamente nell'URI, con un vantaggio per il copia e incolla - ad esempio i file di youtube con il ?= - ma uno svantaggio perché sono in chiaro). (:cellnr align=center bgcolor=#f5f9fc valign=middle:)POST (:cell align=center bgcolor=#f5f9fc valign=middle:)POST (:cell bgcolor=#f5f9fc valign=middle:)Serve a richiedere dati al server, ma in questo caso la risposta finisce nel body. (:cellnr align=center valign=middle:)HEAD (:cell align=center valign=middle:)HEAD (:cell valign=middle:)Non chiede tutto l'oggetto ma solo l'intestazione (eg. per conoscere quando è stato aggiornato l'oggetto). (:cellnr align=center bgcolor=#f5f9fc valign=middle:) (:cell align=center bgcolor=#f5f9fc valign=middle:)PUT (:cell bgcolor=#f5f9fc valign=middle:)Per l'upload dei file. (:cellnr align=center valign=middle:) (:cell align=center valign=middle:)DELETE (:cell valign=middle:)Per cancellare file dal server. (:tableend:)

HTTP RESPONSE MESSAGE

Anch'essi composti da tre parti:

• Status line, nella quale compare un codice a tre cifre che definisce la categoria del messaggio. Per conoscere il significato dei vari codici si può fare richiesta con un telnet, oppure andare su questa pagina. Ad esempio, una status line potrebbe essere: "HTTP/1.1 200 OK <CR><LF>"
• Header:
  • Connection, eg: close
  • Date, eg: Thu,6 august
  • Server, tipo e versione del server. Eg: Apache/1.3.0(Unix)
  • Last modified, eg: Thu,1 may
  • Content length, eg: 6821
  • Content type, tipo di contenuto restituito. Eg: text/html (sono i tipi MIME)
• Body, il contenuto della risposta.

Esempio di HTTP Message

GET /wiki HTTP/1.1
Host: doppioclic.altervista.org
Connection: Close 
User-Agent: Mozilla/5.0
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5 
Accept-Language: it

HTTP/1.1 301 Moved Permanently
Date: Fri, 18 Jan 2008 20:56:52 GMT
Server: Apache
Location: http://doppioclic.altervista.org/wiki/
Vary: Accept-Encoding
Content-Length: 246
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head ... ecc ecc

Implementare stati HTTP

Per simulare uno stato nell'HTTP vengono usati i Cookies.\\

Torna su

• Get = serve a richiedere dati al server, la risposta finisce nell'URL/URI (tanti server mandano le variabili direttamente nell'URI, con un vantaggio per il copia e incolla - ad esempio i file di youtube con il ?= - ma uno svantaggio perché sono in chiaro)
• Post = che serve a richiedere dati al server, la risposta finisce nel body

• distribution of multiple host on a single DNS

• infrazione di copyright: il server non sa cosa si inviano tra loro gli host perchè il trasferimento dei file è decentralizzato

Successivo a Napster. In questo caso le richieste di dati vengono propagate attraverso query attraverso una connessione TCP tra host. Le query sono gestite attraverso un TTL per cui dopo un po' non può più essere propagata la richiesta per non saturare la rete. Il protocollo ha una sua tipologia che si inserisce su internet.

Che differenza c'è? C'è che l'IP address e la porta di destinazione del mittente deve essere estratta direttamente dal pacchetto inviato, non viene mandato a parte.

Propagazione: tempo e velocità di propagazione dei byte

• alias dei mail server

Il DNS usa un database distribuito, strutturato con server organizzati gerarchicamente: in pratica se non so una cosa il DNS sa a quale altro server chiedere, magari di livello superiore. Usa inoltre una cache per mantenere la lista dei nomi.

Nelle organizzazioni si possono mantenere DNS per indirizzi interni alla rete.\\

• Server : Apache/1.3.0(Unix)

La prima cifra mi definisce la categoria del messaggio. Per conoscere il significato dei vari messaggi si può fare richiesta con un telnet.

1. Client-server = c'è un client, presente in modo discontinuo sulla rete che richiede man mano informazioni al server che invece è sempre presente. I client per contro non possono comunicare direttamente l'uno con l'altro ma solo tramite server. IL SERVER é SCALABILE??(ndP)

• collo di bottiglia: collegamento con problemi di banda tra host con differenti bande
• infrazione di copyright: il server non sa cosa si inviano tra loro gli host perchè il trasferimento dei file è decentrallizzato

Esempio client/server with TCP

1. client legge le righe che riceve in input (inFromUser stream) e le manda al server via socket (outToServer stream)
2. il server legge le linee dal socket
3. le converte in maiuscolo (uppercase???)e le rimanda al client
4. il client legge, stampa e modifica le linee dal socket (inFromServer stream)

P2P centralized as Napster

P2P as Gnutella

Ibrido: KaZaA

Stream jargon (non ho la minima idea del perchè sia messo qui, ma teniamolo)

P2P centralized as Napster

P2P as Gnutella

Ibrido: KaZaA

Socket programming with UDP

Tipi di ritardo

Viaggiando dal sorgente al destinatario il pacchetto può essere soggetto a differenti ritardi. Elementi di ritardo possono essere: Propagazione: tempo e velocità di propagazione dei bite trasmissione legata alla banda (dtrans = Lunghezza/ Rate{portata}) coda dei pacchetti che dipende dalla prestazioni del router e dei protocolli di trasporto processo: legato all’header del pacchetto e all’instradamento dei router

Le strategie per ridurre il ritardo sono chiamate di Content Distribution. Tutte agiscono sul tempo di trasmissione aumentando e diminuendo l’uso della banda. Esse sono:

• web caching (ottimizzare contenuti server)
• mirroring
• ditribution of multiple host on a single DNS
• P2P

WEB CACHING

Server proxy: le richieste del client non vanno al server di origine ma si fermano in un server diverso che ha già in sè la maggioranza delle informazioni richieste dal client. Il vantaggio principale è derivato dal fatto che di solito la banda passante tra client e proxy è maggiore di quella tra client e server di origine. Inoltre riduce il tempo di risposta alla richiesta e il traffico al link. E' un'architettura con grande replicazione cache e a chi ha banda bassa può fornire risorse con banda alta richiedendo direttamente alla cache. Siccome non so come mettere i suoi disegni guardare le sue dispense:

Vedi slide 74-78 Ceravolo

CONTENT DISTRIBUTION NETWORKS

Sono compagnie che affittano spazi dove i clienti possono replicare contenuti. Il cliente sviluppa un meccanismo che risolve le richieste del server centrale e le reindirizza al più vicino CND, quindi fornisco degli spazi dove smistare le richieste a vari mirroring. L’impatto positivo è la valorizzazione economica del servizio. Conoscere la mappa della rete è quindi importante.

P2P file sharing

Non si usa un’architettura client-server (richiesta a un fornitore di servizio) ma host che fungono sia da client che da server. Distribuire i contenuti non significa però diminuirli. Ci sono due tipi di file sharing:

1. bootstrap: gli host si collegano alla rete quindi deve essere agganciato alla rete stessa e avere un punto di collegamento per invio richieste ad altri peer. Smisto le richieste sapendo chi sono i suoi vicini
2. lookup: per avere la risorsa x devo fornire uno o più host che mi dicono ciò che voglio.

Data transfert: dare risorsa ad altri (host to host)

Penso che tutti sappiano come sia il file sharing, i punti principali sono spiegati nella slide 81 di Ceravolo comunque.

P2P centralized as Napster

In quest'architettura centralizzata il server riconosce l'host e lo registra e si occupa del lookup cioè controlla chi è l'host che può soddisfare la richiesta inviata da un altro host. (Lookup = richiesta di dati ai vicini, che propagano la richiesta ad altri vicini e man mano si allarga il giro) I problemi di questo tipo sono: collo di bottiglia: collegamento con problemi di banda tra host con differenti bande infrazione di copyright: il server non sa cosa si inviano tra loro gli host perchè il trasferimento dei file è decentrallizzato

P2P as Gnutella

Successivo a Napster. In questo caso le richiste di dati vengono propagate attraverso query attraverso una connessione TCP tra host. Le query sono gestite attraverso un TTL per cui dopo un po' non può più essere propagata la richiesta per non saturare la rete. Il protocollo ha una sua tipologia che si inserisce su internet.

Per capire meglio l'architettura vedi slide 86

Ibrido: KaZaA

In quest'architettura c'è un super peer cioè un gruppo leader che funge da server, collegati ciascuno ad altrettanti host tutti attraverso il protocollo TCP.

Ogni file ha un suo codice e una descrizione. Il client manda la query con la parola chiave al suo gruppo leader. Questo risponde con le informazioni richieste fornendo metadata (dati relativi al dato dato), hash e IP address. Se il gruppo leader deve inviare la domanda ad altri gruppi anche questi dovranno rispondere con le stesse informazioni. Infine il client sceglie i file da scaricare.

Ci sono dei problemi sull'efficienza e la sicurezza perchè un peer può ingannare l'altro modificando i dati visibili del file da scaricare. Limitato inoltre il download parallelo per via delle code nella rete.

Scalability

La scalabilità di un protocollo è relativa all'efficacia del servizio di lookup (cioè quello che manda i messaggi di richiesta dei dati) Due sono gli obiettivi principali:

• minimizzare il numero di messaggi richiesti per il lookup
• minimizzare i metadata richiesti per descrivere ogni nodo

Il progetto Chord si prefigge di sviluppare sistemi distribuiti scalabili (può allargare la sua distribuzione) e robusti sfruttando le idee del peer-to-peer. Il componente base del progetto Chord è l'algoritmo di ricerca distribuita basata su tabelle di hash, tabelle di codici di dati. Chord può trovare dati usando log(N) messaggi, dove N è il numero di nodi nel sistema. Perciò per trovare dei dati non fa passare il messaggio di richiesta da tutti i nodi ma solo a logN nodi attraverso un sistema di ricerca del "vicino". Cioè invio la richiesta a un nodo conoscendo già il suo o i suoi vicini.

Socket programming

Cos'è un socket? Un socket in inglese è letteralmente la "presa da muro". Attraverso di esso un processo applicativo può sia mandare che ricevere messaggi da un altro processo. I socket permettono al protocollo applicativo di comunicare con il protocollo di trasporto. Il protocollo di trasporto può essere come tutti ben sappiamo UDP o TCP.

Socket programming with TCP

TCP è un protocollo affidabile, ossia trasferisce pacchetti in ordine tra client e server. E' più lungo da utilizzare perchè bisogna tener conto del fatto che il client e il server "si mettono d'accordo" su dettagli di trasferimento.
Infatti il client contatta il server che deve essere prima fatto "partire" (running) e deve essere stata creata una socket door che riceve il client.
Quando il client vuole contattare il server deve fornire IP address e port number. Quando il client crea il socket il client TCP stabilisce una connessione con il server TCP. E ogni volta che il client lo contatta il server TCP crea nuovi socket per il processo per comunicare con il client. Il server può parlare con molti client e identificarli attraverso il numero di porta.

Stream jargon (non ho la minima idea del perchè sia messo qui, ma teniamolo)

Lo stream è una sequenza di caratteri che scorre dentro o fuori dal processo.

• Input stream = semplicemente tutti i dati che vengono dalle periferiche di input (tastiera, mouse ecc)
• Output stream = tutti i dati che deve inviare in uscita (stampante)

Esempio client/server with TCP

1. client legge le righe che riceve in input (inFromUser stream) e le manda al server via socket (outToServer stream) 2. il server legge le linee dal socket 3. le converte in maiuscolo (uppercase???)e le rimanda al client 4. il client legge, stampa e modifica le linee dal socket (inFromServer stream)

vedi slide 100-104 per un esempio di Java client/server TCP

Socket programming with UDP

UDP non dà connessione e il lavoro è perciò ridotto perchè non c'è bisogno dei patteggiamenti (le "strette di mano") da fare con UDP, è un modello più semplice perchè non c'è bisogno di aprire la connessione. Però come ricordiamo è un protocollo non affidabile quindi i pacchetti possono essere persi o ricevuti in ordine sbagliato. Che differenza c'è? C'è che l'IP addresse la porta di destinazione del mittente deve essere estratta direttamente dal pacchetto inviato, non viene mandato a parte.

vedi slide 107-112 per un esempio di Java client/server UDP

Costruire un semplice Web server (nb. può servirci per costruire quello da fare per Sassi?)

Esso si occupa di richieste HTTP e di tutti gli annessi e i connessi, cioè: accettare le richieste, analizzare l'header, ottenere le richieste dal server file system, creare una risposta al messaggio HTTP (header lines + file), mandare la risposta al client.
Dopo aver creato un server HTTP posso fare le richieste direttamente dal browser.

Sono applicazioni distribuite, ovvero eseguiti su una macchina locale ma che interagiscono con una macchina posta altrove sulla rete. Esempi di questi protocolli sono: server Email su internet, Msn, Emule, VoIp ecc...

1. P2P = ogni host chiede e passa informazioni ad altri host che possono esserci o non esserci, sono connessi in modo intermittente. Proprio qui sta il problema: le informazioni devono essere "garantite" a prescindere da quali host sono connessi. Sono rare le P2P pure, di solito sono ibride, l'unico è Gnutella che è scalabile cioè funziona sia con pochi utenti che con tanti.
2. Ibride = ci sono dei supernodi che smistano gli host collegati. Esempi di ibridi sono Napster (file transfer P2P) o IM (istant messaging) in cui comunico ad un server la mia esistenza e quando sono registrata trova tutti gli indirizzi collegati al mio buddy (il profilo).

Un processo è un qualunque programma che funziona su un host, sia lato client che lato server. Il sistema operativo gestisce i processi e la IPC (Inter Process Communication). Come collegare tra loro processi diversi? Tramite la nozione di porta. Una porta è un concetto astratto per stabilire che il processo X, che sarà interrotto da altri processi, possa comunicare con il processo Y, il quale parimenti sarà interrotto e così via. Sostanzialmente per porta si intende quindi un canale di comunicazione attraverso cui due host riescono a comunicare.

Per gestire la comunicazione dei processi fra host diversi uso i socket. A cosa mi servono le porte allora? Beh, non posso tener conto solo del fatto che ogni host ha un indirizzo IP unico, perchè processi diversi possono essere inviati sullo stesso terminale. Devo quindi associare un numero di porta per distinguerli (eg il numero di porta di internet solitamente è 80).

Solitamente il protocollo definisce espressamente le prime due cose, la terza è implicita.

In base a ciò che un'applicazione richiede si caratterizza il protocollo:

1. Banda: quanta banda minima mi serve?

Ma se UDP non fa un cavolo, che utilità ha? E' un protocollo più leggero.

Le pagine web come tutti sappiamo sono composte da un gran numero di oggetti: un file html di base contiene infatti riferimenti ad altri oggetti: immagini jpg, applet java ecc... Ogni oggetto è indirizzabile con un URL: eg. "www.someschool.edu/someDept/pic.gif" identificherà il nome di un'immagine.\\

• URN = universal resource name: identifica la risorsa attraverso il nome anche se l'oggetto stesso non è reperibile (eg. voglio dare un nome alla documentazione di un software all'interno della mia rete aziendale)

HTTP (Hyper Test Transfer Protocol)

Applicazione Web. Il client invia una richiesta di un oggetto, identificato con un URI: il server se ce l'ha lo invia, altrimenti risponde con un errore. Semplice vero?
Ne esistono due versioni diverse: la 1.0 e la 1.1 (come GDA d'altronde).

L'HTTP si basa su TCP: il client richiede dati aprendo una connessione TCP al server sulla porta 80; quando ho ottenuto le informazioni che mi servono, la connessione si chiude. Per ogni oggetto invio una richiesta.\\

E' un protocollo senza stati, cioè la connessione viene aperta e chiusa ogni volta; il server non tiene memoria delle richieste precedenti, perciò se non mi arriva un oggetto dovrò ripetergliela.

Dato però che questa semplicità eccessiva non permetteva di gestire la persistenza della connessione (e per altri motivi), si è passati alla versione 1.1 con il vantaggio che riesco a mandare più oggetti con una singola connessione, risparmiando banda.

Attenzione! Tenere la connessione aperta non significa avere gli stati.

HTTP 1.0:

Quant'è perciò il tempo di risposta? C'è un RTT per aprire la connessione, un RTT per la richiesta HTTP e i primi bytes della risposta, infine il tempo di trasmissione dei file. TOTALE = 2RTT + tempo di trasmissione per ogni oggetto.
Ecco perchè sorge la necessità di un HTTP persistente.

Ci sono due implementazioni di persistenza:

• l'altra è detta PIPELING: il client manda richiesta per ogni oggetto che trova, senza aspettare di aver ricevuto gli oggetti trovati prima, il server crea una pipeline e glieli manda tutti insieme.

E' in ASCII.

• Post = che serve a mandare dati al server (anche se adesso tanti server mandano le variabili direttamente nell'URI, con un vantaggio per il copia e incolla - ad esempio i file di youtube con il ?= - ma uno svantaggio perché sono in chiaro)
• Head = non chiedo tutto l'oggetto ma solo l'intestazione (eg. per conoscere quando è stato aggiornato l'oggetto)

I messaggi hanno codici di tre cifre, come ad esempio:

Eg. ho un sito che vende ciarpame e voglio mantenere un carrello della spesa per un utente. Dato che HTTP non ha memoria, scrivo le informazioni su file detti cookies. Posso dunque usarli per:

Se serve un cookie, quando il server risponde aggiungerà una linea nell'header (ad esempio) "Set-cookie:1678" ed il client dovrà mantenerlo in memoria. Quando poi il client invierà successive richieste, manderà anche "cookie: 1678" così che il server sappia chi sono.

E' tutto bello e comodo, ma sorgono però dei problemi di privacy, dato che questi file contengono informazioni più o meno riservate sul mio conto.

Per migliorare l'efficienza della rete è meglio ridurre il numero di richieste sui server. Si utilizzano così dei dispositivi chiamati proxy che provvedono a fare da tramite e che mantengono nella loro cache una copia degli oggetti richiesti, così da mandar questi invece di richiederli dai server. Certo, in questo modo un proxy dovrà sempre controllare che l'oggetto nella cache sia aggiornato, ed ecco quindi a cosa serve il campo date dello header HTTP. (Attenzione! l'aggiornamento non viene fatto ogni volta, o il risparmio di traffico sarebbe relativo)
Il server a cui viene chiesto di controllare se l'oggetto sia stato aggiornato risponde 304 se non lo è, con una data altrimenti.

File Transfer Protocol. Attivo sulla porta 21, apre due connessioni: una per il controllo e una per il trasferimento dati.\\

FTP codici

Esistono tre componenti principali:

1. user agent (il client email, ad esempio Thunderbird o Outlook)

1. SMTP (Simple Mail Transfer Protocol)

...e tre fasi di comunicazione:

Il messaggio viene passato in codifica ASCII.

1. Per leggere il messaggio utilizzo di nuovo l'User agent

client: ...inizio email....

Le email sono terminate da un punto messo in una riga da solo. La connessione viene aperta e chiusa alla fine del messaggio. Si può eseguire il tutto da telnet sulla porta 25.\\

Riassumendo i comandi principali di un messaggio in SMTP sono: HELO, MAIL FROM, RCPT TO, DATA, QUIT

Body: contiene il messaggio in codifica ASCII

Content-type : image/jpg => questi sono definiti dalla versione del MIME (solitamente versione 1.0)

Diversamente dall'SMTP, per ricevere la posta ha bisogno dell'autenticazione con username e pass. Si possono listare i messaggi, che vengono identificati con un numero, e poi cancellati dal server, e non posso più rileggere i messaggi se accedo a un altro client.

Poi, nel DATA di una mail, ogni singolo pezzo ha il suo charnet e il suo tipo MIME.

Il DNS usa un database distribuito, strutturato con server organizzati gerarchicamente: in pratica se non so una cosa il DNS sa a quale altro server chiedere, magari di livello superiore. Usa inoltre una chache per mantenere la lista dei nomi.

Nella gerarchia c'è un ROOT DNS (ce ne sono pochi nel mondo) e poi altri livelli più bassi, uno per il dominio (.com, .edu, ecc.. => server top level) e infine quelli locali.
Nelle organizzazioni si possono matenere DNS per indirizzi interni alla rete.
I DNS mantengono una cache (aggiornata) di indirizzi dopo che ne hanno trovati alcuni sconosciuti.

• TYPE NS: dò un dominio, mi dà l'IP del DNS che sa qualcosa di quel dominio

Il formato delle richieste RR (Resource Record) sono del tipo: name, value, type, TTL e anche le risposte sono così. A seconda del tipo di chiamata il VALUE contiene cose diverse.
Le QUERY e le REPLY hanno lo stesso formato di messaggio. A una richiesta DNS possono rispondere sia con DNS che hanno in cache, sia con quelli che sono AUTORITHATIVE per quel server. Se indico RECURSION voglio raggiungere il server autoritativo di quell'indirizzo, se no lascio decidere al DNS a cui chiedo.

Attenzione! Tenere al connessione aperta non significa che ha gli stati.

Cosa sono?

Nozioni preliminari

Comunicazioni fra processi

Che cosa definisce un protocollo applicativo?

Che tipi di servizio richiede un'applicazione distribuita?

Livello di trasporto TCP vs UDP

WEB & HTTP

HTTP -> Hyper Test Transfer Protocol

FTP

Posta elettronica

DNS

ovvero Protocolli applicativi - Application Layer

Torna alla pagina di Sistemi Anticoncezionali delle Reti e dei Damiani

:: A lezione con Ceravolo! ::

ovvero Protocolli applicativi - Application Layer

Cosa sono?

Nozioni preliminari

Comunicazioni fra processi

Che cosa definisce un protocollo applicativo?

• Azioni da intraprendere a seconda di ciò che riceve

Che tipi di servizio richiede un'applicazione distribuita?

Livello di trasporto TCP vs UDP

WEB & HTTP

Attenzione! Ci sono delle differenze quando di parla di URL, URI e URN!

HTTP -> Hyper Test Transfer Protocol

HTTP message

HTTP REQUEST MESSAGE

La request line è così formata:
GET, POST, HEAD commands => "GET/somedir/page.html HTTP/1.1" (per far sapere al server se ho persistenza o no)

L' Header line è così formata:

• Host : www.someschool.edu
• User-agent : Mozilla/4.0
• Connection : Close (indico che voglio chiudere la connessione)
• Accept-language : Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo)

HTTP 1.1

HTTP RESPONSE MESSAGE

C'è uno Status line così fatto:
"HTTP/1.1 200 OK <CR><LF>"

• 505 - HTTP version not supported

La prima cifra mi definisce la categoria del messaggio. Per conoscere il signficato dei vari messaggi si può fare richiesta con un telnet.

Vengono usati i Cookies.\\

FTP

File Transfer Protocol. Aperto sulla porta 21, apre due connessioni: una per il controllo e una per il trasferimento dati.\\

FTP commands:

Posta elettronica

Sample SMTP interaction

Il client si presenta con il comando HELLO:

Alla fine si saluta scrivendo QUIT.

RFL 822

Qualora volessi inviare altro oltre al testo dovrei servirmi dei tipi MIME che codificheranno il messaggio.

SMTP viene usato anche tra server e server per l'invio effettivo di mail. NON c'è bisogno di autenticazioni.

POP3

IMAP invece mantiene tutti i messaggi sul server e si può accedervi da diversi client. I messaggi in genere contengono più oggetti, esempio testo e allegati. Il MIME è quello che me li fa vedere. Devo anche stabilire un marcatore per dividere un tipo di oggetto da un altro, eg. BOUNDARY: "--next part 011397--", quindi dopo questa riga so che c'è un altro oggetto di diverso.\\

DNS

• si distribuisce il carico di un server: si danno più indirizzi IP a un singolo nome così che ci sono più computer che lo gestiscono

Perchè non è una buona idea avere un registro centrale? Perchè:

• inoltre non è scalabile

Il DNS usa un databese distribuito, organizzata con server organizzati gerarchicamente: in pratica se non so una cosa il DNS sa a quale altro server chiedere, magari di livello superiore. Usa inoltre una chache per mantenere la lista dei nomi.

• TYPE MX: mi dà l'IP di un mail server associato con nome

Torna alla pagina di Sistemi Anticoncezionali delle Reti e dei Damiani

IMAP invece mantiene tutti i messaggi sul server e si può accedervi da diversi client. I messaggi in genere contengono più oggetti, esempio testo e allegati. Il MIME è quello che me li fa vedere. Devo anche stabilire un marcatore per dividere un tipo di oggetto da un altro, eg. BOUNDARY: "--next part 011397--", quindi dopo questa riga so che c'è un altro oggetto di diverso. Poi, noi DATA di una mail, ogni singolo pezzo ha il suo charnet e il suo tipo MIME.

DNS

Domain Name System: è basato su architetture client - server ma è un protocollo "fondativo" di internet, un servizo offerto alle applicazioni. I servizi offerti sono:

• alias di host
• alias dei mal server
• si distribuisce il carico di un server: si danno più indirizzi IP a un singolo nome così che ci sono più computer che lo gestiscono
  Perchè non è una buona idea avere un registro centrale?
  Perchè:
• la rete rallenterebbe
• inoltre non è scalabile
  Il DNS usa un databese distribuito, organizzata con server organizzati gerarchicamente: in pratica se non so una cosa il DNS sa a quale altro server chiedere, magari di livello superiore. Usa inoltre una chache per mantenere la lista dei nomi
  Nella gerarchia c'è un ROOT DNS, ce ne sono pochi nel mondo e poi ci sono di livello più basso, uno per dominio (.com, .edu, ecc.. =>server top level) e infine quelli locali.
  Nelle organizzazioni ci possono matenere DNS per indirizzi interni alla rete.
  I DNS mmantengono una cahce di indirizzi dopo che ne hanno trovati alcuni sconoscuti, la chache ogni tot scade.

Al DNS si possono fare delle richieste:

• TYPE A: dò un nome intero, voglio un IP
• TYPE NS: dò un domnio mi dà l'IP del DNS che sa qualcosa di quel dominio
• TYPE CNAME: nome è l'alias, mi dà indietro il suo nome canonico (eg.www.ibm.com è alias di severeast.backup2.ibm.com)
• TYPE MX: mi dà l'IP di un mail server associato con nome
  Il formato delle richieste RR (Resource Record) sono del tipo: name, value, type, TTL e anche le risposte sono così. A seconda del tipo di chiamata il VALUE contine cose diverse.
  Le QUERY e le REPLY hanno lo stesso formato di messaggio. A una richiesta DNS possono rispondere sia di DNS che ce l'hanno in cache, sia quelli che sono AUTORITHATIVE per quel server, se indico RECURSION voglio raggiungere il server autoritativo di quell'indirizzo, se no lascio decidere al DNS a cui chiedo.

Body: contiene il messaggio in codifica ASCII
Qualora volessi inviare altro oltre al testo dovrei servirmi dei tipi MIME che codificheranno il messaggio.
Content-transfer-encoding : base 64 => codifica in base 64
Content-type : image/jpg => questi sono definiti dalla versione del MIME (solitamente versione 1.0)
SMTP viene usato anche tra server e server per l'invio effettivo di mail. NON c'è bisogno di autenticazioni

POP3

Diversamente dall'SMTP per ricevere la posta ha bisogno dell'autenticazione con username e pass. Si possono listare i messaggi, che vengono identificati con un numero, e poi cancellati dal server, e non posso più rileggere i messaggi se accedo a un altro client.

FTP commands\\\

Sample SMTP interaction\\\

RFL 822\\\

Sample SMTP interaction\\

RFL 822\\

Sample SMTP interaction Il client si presenta con il comando HELO
client: MAIL FROM <address@server.extension>
server: 250 server ok
client: RCPT TO <....@....>
server: recipient ok
client: DATA
server: 354 Enter mail
client: ...inizio email....
Le email sono terminate da un punto messo in una riga da solo. La connessione viene aperta e chiusa alla fine del messaggio, si può fare da telnet sulla porta 25.
Alla fine si saluta scrivendo QUIT.

Riassumendo i comandi principali di un messaggio in SMTP sono: HELO,MAIL FROM, RCPT TO, DATA, QUIT

RFL 822 E' lo standard per i messaggi di testo che sono composti da un header e da un body.
Header: to, from, subjet => comandi differenti da quelli di SMTP
Body: contiene il messaggio in codifica ASCII

1. Scrivo un messaggio con un User agent

1. SMTP client manda il messaggio attraverso una connessione TCP
2. Il mail server del destinatario mette il messaggio nella casella di posta destinata
3. Per leggere il messaggio invoco lo User agent

Posta elettronica

Tre sono le componenti principali:

1. user agent
2. mail server
3. SMTP simple mail transfer protocol

E tre sono le fasi:

1. handshaking
2. transfer
3. closure

Il messaggio viene passato in codifica ASCII
Passaggi:

1. Invio un messaggio con un User agent
2. Lo mando al mio mail server, esso viene messo in una coda
3. Il lato client dell'SMTP apre una connessione TCP con il server mail del destinatario
4. Viene inviato

Proxy server

Per migliorare l'efficienza della rete è meglio ridurre il numero di richieste perciò uso un proxy che mantiene nella memoria locale le informazioni richieste così che è lui a darle al cliente, non il server, così non si sovraccarica. Il proxy deve controllare se un oggetto è aggiornato. Ecco a cosa serve la richiesta dello head che il proxy usa per aggiornare la chache. Attenzione!questo lavoro di aggiornamento non lo fa ogni volta altrimenti il risparmio è relativo. Per sapere se un oggetto è aggiornato o no ecco che il server risponde 304 se non è modificato oppure se lo è dice la data.

FTP

File Transfer Protocol. Aperto sulla porta 21, apre due connessioni: una per il controllo e una per il trasferimento dati. Problemi:

• è basato su due connessioni, perciò non basta telnet per usarlo
• la codifica dei caratteri va gestita perchè può essere che server e client usino codifiche diverse.

E' persistente perciò la connessione viene tenuta aperta e si mantiene una sessione. Per autenticarsi occorre mandare username e password.

FTP commands

• manda un testo ASCII
• chiede USER e PASS
• LIST ritorna una lista di file nella directory corrente
• RETR filename retrievers (gets) file
• STOR filename stores (puts) file onto remote host

FTP codici

• 331 user ok, pass requied
• 125 data connection already open, transfer starting
• 425 can't open data connection
• 452 error writing file

Implementare stati HTTP

Vengono usati i Cookies
Eg. ho un sito che vende roba e voglio mantenere un carrello della spesa per un utente, ma so che HTTP non ha memoria perciò uso i cookies. Essi possono servire quindi per:

• autorizzazioni
• shopping carts
• raccomandazioni
• sessioni aperte (eg web mail)

Se serve un cookie quando il server risponde nell'header invierà eg: "Set-cookie:1678" e il client deve mantenere quel cookie, perciò poi quando il client invierà successive richieste manderà anche: "cookie: 1678" così il server sa chi sono. I cookie creano però problemi di privacy.

"HTTP/1.1 200 OK <CR><LF>"\\

"HTTP/1.1 200 OK <CR><LF>"\\

La request line è così formata: GET, POST, HEAD commands => "GET/somedir/page.html HTTP/1.1" (per far sapere al server se ho persistenza o no)\\

"HTTP/1.1 200 OK <CR><LF>"\\

La request line è così formata: GET, POST, HEAD commands => "GET/somedir/page.html HTTP/1.1" (per far sapere al server se ho persistenza o no)\\

La request line è così formata: GET, POST, HEAD commands => "GET/somedir/page.html HTTP/1.1" (per far sapere al server se ho persistenza o no)\\

"HTTP/1.1 200 OK <CR><LF>"\\

Metodi\\

Metodi\\

Metodi

C'è uno Status line così fatto:

La prima cifra mi definisce la categoria del messaggio. Per conoscere il signficato dei vari messaggi si può fare richiesta con un telnet.

Header:

• Connection : close
• Date : Thu,6 august ecc..
• Sever : Apache/1.3.0(Unix)
• Last modified : <data>
• Content length : 6821
• Content type : text/html (sono i tipi MIME)

I messaggi hanno codici di tre cifre come si può vedere,questi codici sono ad esempio:

• 200 - OK
• 301 - Moved permanentely
• 400 - Bad request
• 404 - Page not found
• 505 - HTTP version not supported
  La prima cifra mi definisce la categoria del messaggio. Per conoscere il signficato dei vari messaggi si può fare richiesta con un telnet.

!Metodi

HTTP RESPONSE MESSAGE

C'è uno status line così fatto: "HTTP/1.1 200 OK <CR><LF>"
I messaggi hanno codici di tre cifre come si può vedere

HTTP 1.1\\

Aggiunge due nuovi metodi:

Alla fine dell'header c'è un <CR> (Carrige Return) e un <LF> (Line Feed) che indicano la fine del messaggio. Poi c'è il Body con cui si può inviare roba al server.

Metodi

HTTP 1.0

• Get
• Post = che serve per mandare roba al server (anche se adesso tanti server mandano le variabili direttamente nell'URI, vantaggio per il copia e incolla, ad esempio i file di youtube con il ?=, svantaggio è che sono in chiaro)
• Head = non chiedo tutto l'oggetto ma solo l'intestazione (eg. per conoscere quando è stato aggiornato l'oggetto

HTTP 1.1 Aggiunge due nuovi metodi:
* Put = per l'upload dei file

• Delete = per cancellare file dal server

L' Header line è così formata:\\

• Accept-language : Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo)
  
  

Alla fine dell'header c'è un <CR> (Carrige Return) e un <LF> (Line Feed) che indicano la fine del messaggio. Poi c'è il Body

L' header line è così formata:\\

• Host : www.someschool.edu
  *User-agent : Mozilla/4.0
  *Connection : Close (indico che voglio chiudere la connessione)
  *Accept-language : Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo

Host : www.someschool.edu User-agent : Mozilla/4.0 Connection : Close (indico che voglio chiudere la connessione)

Host : www.someschool.edu
User-agent : Mozilla/4.0
Connection : Close (indico che voglio chiudere la connessione)
Accept-language : Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo

Host: www.someschool.edu
User-agent: Mozilla/4.0
Connection: Close (indico che voglio chiudere la connessione)
Accept-language: Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo

L'header line è così formata:\\

L'header line è così formata:\\ Host: www.someschool.edu
User-agent: Mozilla/4.0
Connection: Close (indico che voglio chiudere la connessione)\\

HTTP REQUEST MESSAGE

E' in ASCII.\\

E' in ASCII.\\\

HTTP REQUEST MESSAGE

E' un protocollo senza stati cioè la connessione è ogni volta aperta e chiusa, il server non tiene memoria delle richieste precedenti perciò se non mi arriva un oggetto devo ripetere la mia richiesta. Ma questa semplicità eccessiva non permette di gestire la persistenza della connessione. Si è passati perciò alla versione 1.0 con il vantaggio che mando più oggetti con una singola connessione e risparmio banda.
Attenzione! Tenere al connessione aperta non significa che ha gli stati.
HTTP message:

• client apre una connessione TCP con un host su una certa porta
• server risponde
• client invia REQUEST MESSAGE per un oggetto
• server invia RESPONSE MESSAGE e chiude la connessione
• se però il client aprendo la pagina vede che contiene 10 oggetti richiede le 10 immagini in sequenza e ricomincia daccapo

Quant'è perciò il tempo di risposta? C'è un RTT per aprire la connessione, un RTT per la richiesta HTTP e i primi bytes delal risposta, infine il tempo di trasmissione dei file. TOTALE = 2RTT + tempo di trasmissione per ogni oggetto
Ecco perchè c'è la necessità di HTTP persistente. Ci sono due implementazioni di persistenza:

• una si limita a NON chiudere la connessione dopo l'invio di un oggetto
• una è detta PIPELING: il client manda richiesta per ogni oggetto che trova, senza aspettare di aver ricevuto gli oggetti trovati prima, il server crea una pipeline e glieli manda tutti insieme.

Ho due messaggi HTTP: REQUEST e RESPONSE

HTTP REQUEST MESSAGE

E' in ASCII.
La request line è così formata: GET, POST, HEAD commands => "GET/somedir/page.html HTTP/1.1" (per far sapere al server se ho persistenza o no)
L'header line è così formata: Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: Close (indico che voglio chiudere la connessione) Accept-language: Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo

E' un protocollo senza stati cioè la connessione è ogni volta aperta e chiusa, il server non tiene memoria delle richieste precedenti perciò se non mi arriva un oggetto devo ripetere la mia richiesta. Problema: quanto tempo ci metto? Contando che per ogni oggetto invio una sola richiesta e ottengo ogni volta risposta, totale = 2RTT+transmit time

HTTP->Hyper Test Transfer Protocol\\

Esso si basa su TCP: il client richiede dati aprendo una connessione TCP al server sulla porta 80-> quando ho ottenuto le informazioni che mi servono, la connessione si chiude. Per ogni oggetto invio una richiesta.
E' semplice da gestire, sia lato client che lato server, e questa è stata la base del successo iniziale del web.
E' un protocollo senza stati cioè la connessione è ogni volta aperta e chiusa, il server non tiene memoria delle richieste precedenti perciò se non mi arriva un oggetto devo ripetere la mia richiesta. Problema: quanto tempo ci metto? Contando che per ogni oggetto invio una sola richiesta e ottengo ogni volta risposta, totale = 2RTT+transmit time

WEB & HTTP

Le pagine web come tutti sappiamo sono composte da un gran numero di oggetti: un file html di base che contiene riferimenti ad altri oggetti: immagini jpg, applet java ecc... Ogni oggetto è indirizzabile con un URL: eg. "www.someschool.edu/someDept/pic.gif" identificherà il nome di un'immagine.
Attenzione! Ci sono delle differenze quando di parla di URL, URI e URN!
*URL = universal resource locator: identifica la risorsa in modo globale attraverso la locazione della risorsa stessa (su che server è)

• URI = universal resource identifier: identifica la risorsa indipendentemente da dove si trova o dal nome con il quale è nota
• URN = universal resource name: identifica la risorsa attraverso il nome anche se l'oggetto stesso non è reperibile (eg. voglio dare un nome alla documentazione di un software all'interno della mia rete aziendale)
  Una URI può essere rappresentata in forma di URL, URN o una combinazione di entrambi.

HTTP->Hyper Test Transfer Protocol
Applicazione Web. Il client invia una richiesta di un oggetto, identificato con un URI, il server se ce l'ha lo invia, altrimenti risponde con un errore, semplice vero?
Esistono due versioni diverse: la 1.0 e la 1.1 (come GDA d'altronde)
Esso si basa su TCP: il client richiede dati aprendo una connessione TCP al server sulla porta 80-> quando ho ottenuto le informazioni che mi servono, la connessione si chiude.
E' semplice da gestire, sia lato client che lato server, e questa è stata la base del successo iniziale del web.

(:cellnr bgcolor=#f5f9fc valign=middle:)NO timing

Ma se UDP non fa un cavolo, a cosa mi serve? E' un protocollo più leggero.

(:cellnr bgcolor=#f5f9fc valign=middle:)eNO timing

(:cellnr valign=middl:)NO banda minima (:cell valign=middle:)NO banda minima

(:cellnr valign=middle:)connessione (:cell valign=middle:)NO connessione

(:cellnr bgcolor=#f5f9fc valign=middle:)NO timing (:cell bgcolor=#f5f9fc valign=middle:)NO timing

(:cellnr bgcolor=#d9e4f2 colspan=2:)TCP (:cell bgcolor=#d9e4f2 colspan=2:)UDP (:cellnr:)connessione (:cell:)NO connessione

(:cellnr align=center:)connessione (:cell align=center:)NO connessione (:cellnr bgcolor=#f5f9fc valign=middle:)controllo flusso (:cell bgcolor=#f5f9fc valign=middle:)NO controllo flusso (:cellnr valign=middle:)controllo congestione (:cell valign=middle:)NO congestion control

(:cellnr bgcolor=#d9e4f2 colspan=2 align=center:)TCP (:cell bgcolor=#d9e4f2 colspan=2 align=center:)UDP (:cellnr:)connessione (:cell:)no connessione

(:table border=0 width=55% cellpadding=5 cellspacing=0:) (:cellnr bgcolor=#d9e4f2 colspan=2 align=center:) (:cell bgcolor=#d9e4f2 colspan=2 align=center:) (:cellnr:) (:cell:) (:cellnr bgcolor=#f5f9fc valign=middle:) (:cell bgcolor=#f5f9fc valign=middle:) (:cellnr valign=middle:) (:cell valign=middle:) (:cellnr bgcolor=#f5f9fc valign=middle:) (:cell bgcolor=#f5f9fc valign=middle:) (:tableend:)

::A lezione con Ceravolo!(ovvero Protocolli applicativi - Application Layer)::

1. P2P = ogni host chiede e passa informazioni ad altri host che possono esserci o non esserci, sono connessi in modo intermittente. Proprio qui sta il problema: le informazioni devono essere "garantite" a prescindere da quali host sono connessi. Sono rare le P2P pure, di solito sono ibride, l'unico è Gnutella che è scalabile cioè funziona con pochi utenti che con tanti.
2. Ibride = ci sono dei supernodi che smistano gli host collegati. Esempi di ibridi sono Napster (file transfer P2P) o IM (istant messaging) in cui comunico ad un server la mia esistenza e quando sono registrata trova tutti gli indirizzi collegati al mio buddy (penso intenda profilo...)

Comunicazioni fra processi

Un processo è un qualunque programma che funziona su un host, sia lato client che lato server. Il sistema operativo gestisce i processi e la IPC (Inter Process Communication). Come collegare tra loro processi diversi? tramite la nozione di porta. Una porta è un concetto astratto per stabilire che il processo X, che sarà interrotto da altri processi, possa comunicare con il processo Y, il quale parimenti sarà interrotto e così via.
Per gestire la comunicazione dei processi fra host diversi uso i socket. A cosa mi servono le porte allora? Non posso tener conto solo del fatto che ogni host ha un indirizzo IP unico perchè processi diversi possono essere inviati allo stesso host, perciò devo associare un numero di porta (eg il numero di porta di internet solitamente è 80).

Che cosa definisce un protocollo applicativo?

• Formato dei messaggi
• Ordine della comunicazione
• Azioni da intraprendere a seconda di ciò che riceve
  Solitamente il protocollo definisce espressamente le prime due cose, la terza è implicita

Che tipi di servizio richiede un'applicazione distribuita?

In base a ciò che un'applicazione richiede infatti si caratterizza il protocollo

1. Perdita dei dati: è tollerata o no?
2. Tempistica: i pacchetti devono arrivare entro un certo tempo?
3. Banda: quanta banda minima mi serve?
   Eg: per il trasferimento dei file non dovrò avere perdita di dati, poco tempo di attesa e una banda elastica in base alla quantità di dati da trasferire.

Livello di trasporto TCP vs UDP

Sistemi

(:title Lezioni con Ceravolo:)

A lezione con Ceravolo!(ovvero Protocolli applicativi - Application Layer)

Cosa sono?

Sono applicazioni distribuite, ovvero eseguiti su una macchina locale ma che interagiscono con una macchina altrove sulla rete. Esempi di questi protocolli sono: server Email su internet, Msn, Emule, VoIp ecc...

Nozioni preliminari

Ci sono tipi diversi di applicazioni distribuite:

1. Client-sever = c'è un client, presente in modo discontinuo sulla rete che richiede man mano informazioni al server che invece è sempre presente. I client per contro non possono comunicare direttamente l'uno con l'altro ma solo tramite server. IL SERVER é SCALABILE??(ndP)
2. P2P = ogni host chiede e passa informazioni ad altri host che possono esserci o non esserci, sono connessi in modo intermittente. Proprio qui sta il problema: le informazioni devono essere "garantite" a prescindere da quali host sono connessi. Sono rare le P2P pure, di solito sono ibride, l'unico è Gnutella è scalabile cioè funziona con pochi utenti che con tanti.

Sistemi