Il documento discute i protocolli applicativi e le architetture di rete come client-server e peer-to-peer, evidenziando l'importanza della comunicazione tra processi attraverso messaggi e protocolli. Viene descritta la creazione di applicazioni di rete e l'interazione tra diversi livelli dell'architettura a strati, con un focus sui protocolli HTTP, SMTP, e file transfer, nonché sulla gestione delle richieste e risposte. Infine, vengono analizzati i requisiti di servizio e le differenze tra TCP e UDP nel contesto delle applicazioni di rete.

1. Protocolli Applicativi Paradigmi Client-Server e Peer-to-Peer HTTP: Web Surfing FTP: Connettività remota SMTP: posta elettronica DNS: indirizzamento simbolico P2P: file sharing

2. Alcune applicazioni di rete E-mail Web Instant messaging Remote login P2P file sharing Network games Video streaming Internet telephony Real-time video conference Massive parallel computing …

3. Creare un’applicazione di rete Scrivere un software che: Possa essere eseguito su diversi terminali e possa comunicare tramite la rete. Ad esempio il software dei Web server comunica con il software del browser. application transport network data link physical application transport network data link physical application transport network data link physical

4. Creare un’applicazione di rete Inventare una nuova applicazione non richiede di cambiare il softeare della rete i nodi della rete non hanno software applicativo Le applicazioni sono solo nei terminali e possono essere facilmente sviluppate e diffuse application transport network data link physical application transport network data link physical application transport network data link physical

5. Comunicazione tra processi Processo: programma in esecuzione su un host All’interno dello stesso host, due processi comunicano usando la comunicazione inter-processo (definita dal OS). Processi in host differenti comunicano scambiando messaggi

6. Processi e Protocolli Processi in esecuzione su sistemi remoti possono scambiarsi informazioni e servizi mediante una rete L’interazione avviene mediante lo scambio di messaggi I protocolli applicativi sono le regole e i formati con i quali i processi costruiscono i messaggi e ne interpretano il significato

7. Interazione coi livelli inferiori Lo scambio di messaggi fra i processi applicativi avviene utilizzando i servizi dei livelli inferiori attraverso i SAP ( Service Access Point ) Ogni processo è associato ad un SAP Applicazioni nella pila OSI: Presentazione Sessione WEB FTP Mail Trasporto Livello controllato dall’applicazione Livelli controllati dal sistema operativo

8. Interazione coi livelli inferiori Nella architettura a strati di Internet, i protocolli applicativi si appoggiano direttamente sul livello di trasporto WEB FTP Mail Trasporto Livello controllato dall’applicazione Livelli controllati dal sistema operativo

9. Sockets Processi inviano e ricevono messaggi attraverso i socket socket sono delle porte di comunicazione Il processo trasmittente mette il messaggio fuori dalla porta La rete raccoglie il messaggio e lo trasporta fino alla porta del destinatario Internet controlled by OS controlled by app developer I socket sono i SAP tra il livello applicativo e il livello di trasporto process TCP with buffers, variables socket host or server process TCP with buffers, variables socket host or server

10. Indirizzamento dei processi Per poter indicare il processo destinatario alla rete è necessario un identificativo Gli host hanno un indirizzo IP univoco di 32 bit (di cui parleremo ampiamente in seguito. Domanda: è sufficiente l’indirizzo IP a identificare un processo in esecuzione su una macchina?

11. Indirizzamento dei processi Risposta: NO, molti processi possono essere in esecuzione sullo stesso host Il livello di trasporto multipla insieme messaggi di più applicazioni sulla stessa rete (ricordate la funzione di multiplazione?) L’ identificativo include sia un indirizzo IP che un numero di porta associato ad un processo in esecuzione. Ad esempio per inviare un messaggio al server web www.polimi.it: IP address: 131.175.12.34 Port number: 80

12. Protocolli applicativi Tipi di messaggi scambiati Richieste, risposte Sintassi dei messaggi: Campi del messaggio e delimitatori Semantica dei messagi Significato dei campi Regole su come e quando inviare e ricevere i messaggi Protocolli standard: Definiti negli RFC HTTP, SMTP, ecc. Protocolli proprietari: KaZaA, Skype, ecc.

13. Requisiti del servizio di trasporto Perdita di dati Alcune applicazioni possono tollerare perdite parziali (ad es. audio) Altre applicazioni richiedono a completa affidabilità (ad es. file transfer, telnet) Ritardo Alcune applicazioni richiedono basso ritardo (ad es. Internet telephony, interactive games) Banda Alcune applicazioni richiedono un minimo di velocità di trasferimento (ad es. appl. multimediali) Altre applicazioni si adattano alla velocità disponibile (“appl. elastiche”)

14. Requisiti del servizio di trasporto Application file transfer e-mail Web documents real-time audio/video stored audio/video interactive games instant messaging Data loss no loss no loss no loss loss-tolerant loss-tolerant loss-tolerant no loss Bandwidth elastic elastic elastic audio: 5kbps-1Mbps video:10kbps-5Mbps same as above few kbps up elastic Time Sensitive no no no yes, 100’s msec yes, few secs yes, 100’s msec yes and no

15. Servizi di trasporto in Internet Servizio TCP: connection-oriented: instaurazione connessione prima delle scambio dati Trasporto affidabile senza perdita di dati Controllo di flusso: il trasmettitore regola la velocità in base al ricevitore Controllo di congestione: per impedire di sovraccaricare la rete Non fornisce: garanzie di ritardo e di banda Servizio UDP: Trasferimento non affidabile senza connessione senza controllo sul traffico senza garanzie

16. Applicazioni e protocolli di trasporto Application e-mail remote terminal access Web file transfer streaming multimedia Internet telephony Application layer protocol SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] proprietary (e.g. RealNetworks) proprietary (e.g., Vonage,Dialpad) Underlying transport protocol TCP TCP TCP TCP TCP or UDP typically UDP

17. Comunicazione Client-Server Lo scopo fondamentale del colloquio tra processi remoti è quello di fornire servizi. In particolare due sono le funzioni che possono essere svolte da un processo applicativo richiedere servizi fornire servizi Se ogni processo applicativo svolge una sola delle due funzioni siamo in presenza di un interazione di tipo client-server

18. Comunicazione Client-Server Un processo client è solo in grado fare richieste di servizio (informazioni) e di interpretare le risposte Un processo server ha solo il compito di interpretare le richieste e fornire le risposte Se nello stesso host è necessario sia fare richieste che fornire risposte vengono usati due processi, client e server . Un protocollo applicativo per un’architettura client-server rispecchia questa divisione di ruoli e prevede messaggi di richiesta ( request ) generati dal lato client e messaggi di risposta ( response ) generati dal server client server request response

19. Processi Client-Server Un processo server è in esecuzione a tempo illimitato sul proprio host ( demone ) e viene attivato mediante un passive open Un processo client viene attivato solo al momento di fare le richieste e viene attivato mediante un active open su richiesta dell’utente o di altro processo applicativo il passive open del server fa si che da quel momento il server accetti richieste dai client l’active open del client richiede l’indicazione dell’indirizzo e della porta del client

20. Programmi Client-Server Normalmente più client possono inviare richieste ad uno stesso server Un client può fare più richieste contemporanee request response request response requests responses ... ...

21. Programmi Client e Server Un client può essere eseguito in modalità parallela o seriale esempio: invia più richieste in parallelo per i file che compongono una pagina web Anche un server può essere eseguito in modalità parallela o seriale Normalmente gli applicativi che usano UDP sono gestiti in modo seriale: i pacchetti con le richieste arrivati vengono immagazzinati e attendono il loro turno; il server li esamina e genera le risposte

22. Programmi Client e Server Normalmente i server che usano TCP vengono eseguiti in modalità parallela e sono dunque in grado di rispondere a più richieste contemporaneamente Con ognuno dei client viene aperta una connessione TCP che viene mantenuta per il tempo necessario a scambiare richieste e risposte La gestione delle procedure per ciascun client collegato avviene mediante la generazione di processi figli Si parla di applicativi multi-thread La generazione di un figlio è detta fork

23. Architetture applicative Client-server I terminali (host) coinvolti nella comunicazione implementano o solo il processo client o solo il processo server Gli host client e gli host server hanno caratteristiche diverse Peer-to-peer (P2P) I terminali implementano tutti sia il processo client che quello server Ibrida

24. Architettura client-server Server: Host sempre attivo Indirizzo IP permanente Possibilità di utilizzo di macchine in cluster Client: Comunicano con il server Possono essere connessi in modo discontinuo Possono cambiare indirizzo IP Non comunicano con altri client

25. Architettura P2P (pura) Non ci sono server sempre connessi Terminali (peers) comunicano direttamente I peers sono collegati in modo intermittente e possono cambiare indirizzo Esempio: Gnutella Fortemente scalabile ma difficile da gestire

26. Architettura ibrida Skype IP Telephony Ricerca degli interlocutori: centralizzata in server Comunicazione diretta tra peer Instant messaging La comunicazione tra utenti è P2P Il meccanismo di localizzazione e presenza è centralizzato in server: L’utente registra il suo indirizzo IP a un server centrale quando si attiva L’utente contatta il server centrale per conoscere lo stato di altri utenti

27. Web Browsing Hyper Text Transfer Protocol (HTTP)

28. HyperText Tranfer Protocol (HTTP) architettura client-server i client richiedono oggetti ( file ) identificati da un URL al server i server restituiscono i file nessuna memoria sulle richieste viene mantenuta nei server (protocollo stateless ) HTTP request HTTP response "Hypertext Transfer Protocol -- HTTP/1.0," RFC 1945, May 1996. "Hypertext Transfer Protocol -- HTTP/1.1," RFC 2068, January 1997 client server

29. Trasporto dei messaggi HTTP fa uso di TCP per il trasporto dei messaggi una web page è di solito composta da un documento base (HTML) e più oggetti collegati la richiesta di una web page fa uso di URL (Uniform Resource Locator) http ://www.polimi.it /index.html Indica il protocollo applicativo Indica l’indirizzo di rete del server Indica la pagina web richieste La porta TCP viene definita per default (80) Method Host :// : Port Path /

30. Trasporto dei messaggi Supponiamo che un client richieda una pagina HTML di un server al cui interno sono contenuti i riferimenti ad altri oggetti (ad esempio 10 figure che compongono la pagina e che occorre visualizzare insieme al testo HTML). : nel trasferimento dell’insieme di oggetti sono possibili 2 modalità Non-persistent connection (default mode di HTTP 1.0) Persistent connection (default mode di HTTP 1.1) Altri oggetti Testo HTML

31. Non persistent Viene aperta una connessione TCP per una sola request-response : inviata la pagina, il server chiude la connessione TCP La procedura viene ripetuta per tutti i file collegati al documento HTML base Le connessioni TCP per più oggetti possono essere aperte in parallelo per minimizzare il ritardo Il numero max di connessioni è di solito configurabile nel browser Request (index.html) Response (index.html file) Request (image1.jpg) Request (image2.jpg)

32. Persistent connection Nel caso persistent il server non chiude la connessione dopo l’invio dell’oggetto La connessione rimane aperta e può essere usata per trasferire altri oggetti della stessa pagina web o anche più pagine I server chiudono di solito la connessione sulla base di un time-out without pipelining: il client invia una nuova richiesta solo dopo aver ricevuto la risposta per la precedente with pipelining: più richieste vengono inviate consecutivamente dal client (default mode HTTP v1.1)

33. Richieste

34. Esempi di Methods Altri methods: PATCH, COPY, MOVE, DELETE, LINK, UNLINK, OPTIONS. E’ utilizzato per memorizzare un documento nel server. Il documento viene fornito nel corpo del messaggio e la posizione di memorizzazione nell’URL. PUT E’ usato quando il client non vuole scaricare il documento ma solo alcune informazioni sul documento (come ad esempio la data dell’ultima modifica). Nella risposta il server non inserisce il documento ma solo degli header informativi. HEAD E’ usato per fornire degli input al server da utilizzare per un particolare oggetto (di solito un applicativo) identificato nell’URL. POST E’ usato quando il client vuole scaricare un documento dal server. Il documento richiesto è specificato nell’URL. Il server normalmente risponde con il documento richiesto nel corpo del messaggio di risposta. GET

35. Risposte

36. Messaggi 1xx Informational 2xx Success 3xx Redirection 4xx Client error 5xx Server error Prima parte della richiesta accettata. 100 Continue: Servizio non disponibile 503 Service unavailable Funzione non implementata 501 Not implemented Errore o guasto nel server 500 Internal server error La richiesta ha avuto successo; l’informazione è inclusa 200 OK: L’oggetto è stato spostato nell’URL indicato 304 Moved Temporalily: L’oggetto è stato spostato nell’URL indicato 302 Moved Permanently: Accesso senza necessari account e passwd 401 Unauthorized: l’oggetto non esiste sul server 404 Not Found: errore generico 400 Bad Request:

37. Header Gli header servono per scambiare informazione di servizio aggiuntiva E’ possibile inserire più linee di header per messaggio Esempi Header name Header value : Tipo di user agent User-agent Mostra i permessi del client Authorization Invia il doc. solo se modificato If-modified-since Linguaggio accettato Accept-language Formati accettati Accept Informazione sulla cache Cache-control

38. Scambio di messaggi: un esempio Esempio: di richiesta oggetto GET /ntw/index.html HTTP/1.1 Connection: close User-agent: Mozilla/4.0 Accept: text/html, image/gif, image/jpeg Accept-language:it HTTP/1.1 200 OK Connection: close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 09:23:24 GMT Content-Length: 6821 Content-Type: text/html data data data data data ... Esempio: risposta HTTP è testuale (ASCII)

39. Cache locale: get condizionato E’ possibile evitare di scaricare oggetti memorizzati nella memoria locale se non sono stati modificati Client : GET /fruit/kiwi.gif HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif, image/jpeg If-modified-since: Mon, 22 Jun 1998 09:23:24 Server : HTTP/1.0 304 Not Modified Date: Wed, 19 Aug 1998 15:39:29 Server: Apache/1.3.0 (Unix) (empty entity body) E’ possibile anche usare il metodo HEAD

40. Cache di rete: uso dei proxy Compito principale dei proxy è fornire una grande memoria di cache Se un documento è contenuto nella cache viene scaricato più velocemente sul client

41. Proxy I proxy sono degli application gateway , ovvero degli instradatori di messaggi di livello applicativo Devono essere sia client che server Il server vede arrivare tutte le richieste dal proxy (mascheramento degli utenti del proxy ) LL IP TCP HTTP User Agent LL IP TCP HTTP Server LL IP TCP HTTP Proxy

42. Autenticazione HTTP è stateless e quindi non si possono riconoscere richieste successive dello stesso utente in HTTP esiste un elementare meccanismo di autenticazione ( account e password ) che serve a riconoscere gli utenti Normalmente il browser memorizza passwd e account in modo da non richiedere la digitazione ogni volta GET /ntw/index.html HTTP/1.1 401 Authorization Required WWW-Authenticate:[tipo di autenticazione] GET /ntw/index.html HTTP/1.1 Authorization: account, passwd GET image.gif HTTP/1.1 Authorization: account, passwd . . .

43. Cookie Esiste anche un altro modo per riconoscere richieste successive di uno stesso utente che non richiede di ricordare password Il numero di cookie inviato dal server viene memorizzato in un opportuno file Cambiando il numero di cookie ad ogni operazioni (ad es. e-commerce) si può mantenere uno stato “virtuale” per ciascun utente. GET /ntw/index.html HTTP/1.1 200 OK Set-cookie:18988466 GET /ntw/carrello/index.html HTTP/1.1 Cookie: 18988466 GET image.gif HTTP/1.1 Cookie: 18988466 . . .

44. HTML (HyperText Markup Language) HTTP trasferisce file e non si occupa della loro semantica Il funzionamento del WWW si basa sull’interpretazione di file e sulla loro visualizzazione Pagine di testo formattate sono trasferite come file ASCII mediante dei comandi di formattazione specificate nel linguaggio HTML Le pagine HTML possono contenere riferimenti ad altri oggetti che dal browser possono essere interpretate come parte del documento da visualizzare (immagini) Come link ad altre pagine web Se una pagina HTML è momorizzata nel server e viene inviata su richieste è una pagina statica

45. Pagine WEB dinamiche Se una pagina viene creata al momento della richiesta (e normalmente in base alle informazioni fornite del client ) si parla di pagine dinamiche Se una richiesta si riferisce ad una pagina dinamica il server esamina la richiesta, esegue un programma associato a quella richiesta e genera la pagina di risposta sulla base dell’output di un programma GET /cgi-bin/prog.pl HTTP/1.1 prog.pl 200 OK Pagina dinamica

46. Pagine WEB attive Una pagina web può anche contenere un programma che deve essere eseguito dal client Il programma viene scaricato come un oggetto della pagina ed eseguito in locale sulla macchina del client Può essere utile per ottenere delle pagine in grado di interagire con l’utente, per grafici in movimento, ecc. GET /java/applet HTTP/1.1 200 OK programma

47. Trasferimento di informazione File Transfer Protocol (FTP)

48. File Transfer Protocol (FTP) E’ un protocollo usato per il trasferimento di file tra due host remoti Sia sul lato cliente che sul lato server l’applicazione opera direttamente sul file system della macchina "File Transfer Protocol”, RFC 959, October 1985.

49. File Transfer Protocol (FTP) Fa uso di TCP per il trasporto Due connessioni sono aperte per dati e controllo User Interface Control process Data tranfer process LFS Control process Data tranfer process LFS client server Port 21 Port 20

50. FTP: user interface

51. FTP: connessione di controllo La connessione di controllo viene aperta in modo simile alle altre applicazioni Il server lancia un passive open per la porta 21 e rimane in attesa di richieste di connessione Il client lancia un active open ogni volta deve iniziare una sessione di trasferimento file e fa partire una richiesta di connessione TCP usando una porta dinamica La connessione di controllo è persistent , ovvero rimane aperta per tutta la durata della sessione di trasferimento e può essere usata per molti file da trasferire Control process Data tranfer process LFS LFS client server Passive open Port 21 Control process Data tranfer process Active open Port 66778

52. FTP: connessione dati Le connessioni dati sono non-persistent ovvero sono aperte solo per trasferire un file o altre informazioni e poi sono immediatamente chiuse Per aprire una connessione dati: Metodo 1: Il client che desidera iniziare un trasferimento dati effettua un passive open su una porta di sua scelta Il client comunica la porta al server sulla connessione di controllo mediante il comando PORT Il server fa un active open verso la porta del client usando il suo numero di porta noto 20 Metodo 2: Il client invia il comando di PASV al server Il server sceglie un numero di porta, fa un passive open e comunica il numero di porta al client nella risposta Il client fa un active open verso la porta comunicata dal server

53. FTP: connessione dati Il trasferimento di dati può avvenire con diverse modalità e formati: File type : ASCII file: file di caratteri Binary : formato generale per tutti i file non testuali Transmission mode : Stream mode : il file viene trasferito al TCP come una sequenza non strutturata di byte Block mode : il file viene trasferito in blocchi di cui i primi tre byte rappresentano l’header

54. FTP: comandi Il trasferimento di comandi di FTP è testuale (ASCII) USER username PASS password QUIT log out Comandi di accesso CWD change directory DELE delete file LIST list files RETR retrive file STOR store file Gestione file TYPE file type MODE transfer mode PORT client port PASV server choose port Modalità di trasferimento Gestione delle porte

55. FTP: risposte 125 Data connection already open; transfer starting 200 Command OK 225 Data connection open 226 Closing data connection 227 Entering passive mode; srv. sends Ip_add.,port 230 User login OK 331 Username OK, password required 425 Can't open data connection 426 Connection closed; tranfer aborted 452 Error writing file 500 Syntax error; unrecognized command 501 Syntax error in parameters or arguments 502 Command not implemented

56. FTP: esempio trasferimento file Client Server 220 service ready USER matteo 331 username OK; password ? PASS pippo123 230 user login OK PORT 65667 150 opening data connection LIST /usr/pub 125 data connection OK 226 closing data connection Data

57. Servizio di E-mail Simple Mail Transfer Protocol (SMTP)

58. E-mail L’e-mail è un applicazione che consente di inviare in modo asincrono messaggi testuali E’ basata su una rete di server che comunica con il prot. appl. SMTP ( Simple Mail Transfer Protocol )

59. SMTP E’ un protocollo testuale richiede che anche il corpo dei messaggi sia ASCII i documenti binari devono essere convertiti in ASCII quando un server riceve un messaggio da un user agent mette il messaggio in una coda apre una connessione TCP con la porta 25 del server del destinatario trasferisce il messaggio J.B. Postel, "Simple Mail Transfer Protocol," RFC 821, August 1982.

60. Colloquio tra client e server SMTP S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <alice@crepes.fr> S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu> S: 250 bob@hamburger.edu ... Recipient ok C: DATA S: 354 Enter mail, end with &quot;.&quot; on a line by itself C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection Handshake

61. Formato dei messaggi Il formato dei messaggi inviati (comando DATA) è specificato Alcuni header standard precedono il corpo del messaggio vero e proprio D.H. Crocker, &quot;Standard for the Format of ARPA Internet Text Messages,&quot; RFC 822, August 1982 . From: alice@crepes.fr To: bob@hamburger.edu Subject: Request of information <black line> <Body> .

62. Multipurpose Internet Mail Extensions (MIME) Estensione MIME al RFC 822 ha come scopo principale quello di consentire il trasferimento di messaggi non ASCII &quot;Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,&quot; RFC 2045, Nov. 1996. &quot;Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,&quot; RFC 2046, Nov. 1996. From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ........................ .....base64 encoded data .

63. Multipurpose Internet Mail Extensions (MIME) Codifiche: Base64: Le sequenze di bit da trasferire sono divise in gruppi di 24 bit Ogni gruppo è in diviso in 4 sotto-gruppi di 6 bit Ad ogni gruppo viene aggiunto uno zero in testa e vengono trasferiti come caratteri ASCII 11001100 10000001 00111001 110011 001000 000100 111001 0110011 0001000 0000100 0111001 Z I E 5 base64

64. Multipurpose Internet Mail Extensions (MIME) Quoted-printable Le sequenze di bit da trasferire sono divise in gruppi di 8 bit Se una sequenza corrisponde ad un carattere ASCII è inviata così com’è Altrimenti viene inviata come tre caratteri , “=“ seguito dalla rappresentazione esadecimale del byte 00100110 & 01001100 L 10011101 Non-ASCII Quotable-printable 00111001 9 00100110 & 01001100 L 00111101 = 00111001 9 1001 9 1101 D

65. Multipurpose Internet Mail Extensions (MIME) MIME consente anche il trasferimento di più oggetti come parti di uno stesso messaggio: From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe with commentary MIME-Version: 1.0 Content-Type: multipart/mixed; Boundary=StartOfNextPart --StartOfNextPart Dear Bob, Please find a picture of an absolutely scrumptious crepe. --StartOfNextPart Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... --StartOfNextPart Let me know if you would like the recipe. .

66. Protocolli di accesso al mailbox Diversi protocolli sono stati sviluppati per il colloquio tra user agent e server in fase di lettura dei messaggi presenti nel mailbox POP3 ( Post Office Protocol versione 3 ) IMAP ( Internet Mail Access Protocol ) HTTP

67. POP3 Fase di autorizzazione Comandi del client: user: username pass: password Risposte del server: +OK -ERR Fase di transazione, client: list: elenca numero mess. retr: recupera messaggio dele: cancella messaggio quit C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> S: . C: dele 1 C: retr 2 S: <message 1 contents> S: . C: dele 2 C: quit S: +OK POP3 server signing off S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on

68. Case History Nel Dicembre 1995 S. Bhatia and J. Smith propongono un servizio di e-mail web-based e fondano Hotmail In un mese raggiungono 100K clienti In un anno raggiungono 12M clienti Nel dicembre 1997 Hotmail è acquisita da Microsoft per $400M Esempio di “ first mover advantage ” e di “ viral marketing ”

69. Terminale remoto TELNET

70. TELNET (TErminaL NETwork) E’ un semplice applicativo che consente di aprire un terminale remoto Al contrario di un terminale locale i comandi sono trasferiti su una connessione TCP Terminal driver Telnet client Pseudo-terminal driver Telnet server Internet TCP IP LL TCP IP LL

71. TELNET (TErminaL NETwork) TELNET trasferisce caratteri Caratteri dati: Sono caratteri ASCII con il primo bit pari a 0 Si possono trasferire anche caratteri ASCII con il primo bit pari a 1 se li si fa precedere da un byte di controllo speciale Caratteri di controllo: Sono comandi codificati in sequenze di 8 bit con il primo pari ad 1 Tra questi IAC (255): interpreta il prossimo come carattere di controllo EC (247): cancella carattere c a t f i l e a IAC EC 1

72. TELNET (TErminaL NETwork)

73. Indirizzamento simbolico dei domini Domani Name System (DNS)

74. Domain Name System (DNS) Gli indirizzi IP sono poco adatti ad essere usati dagli applicativi. E’ più comodo utilizzare indirizzi simbolici gerarchici (via, città, stato) senza vincoli derivanti da esigenze di livello 3. Occorre una mappatura fra i due 131.175.21.1 morgana.elet.polimi.it

75. Domain Name System (DNS) Le reti IP forniscono indirizzamento simbolico e un servizio di database distribuito che fornisce il servizio di mappaggio: DNS ( Domain Name System ) Il DNS è esso stesso un’applicazione IP che usa UDP/IP per trasferire i messaggi Il DNS viene usato anche per altri servizi: Host aliasing Mail server aliasing Load distribution &quot;Domain Names - Concepts and Facilities,&quot; RFC 1034, Nov. 1987. &quot;Domain Names - Implementation and Specification,&quot; RFC 1035, Nov. 1987.

76. Indirizzamento simbolico L’ indirizzamento è di tipo gerarchico Ogni ramo è sotto il controllo di un’autorità Per ottenere un nuovo indirizzo occorre chiedere il permesso all’autorità competente com edu org gov mil it fr jp de ... ucla columbia polimi elet cs virgilio rett yahoo morgana morgana.elet.polimi.it

77. Tipi di NS Local Name Servers Direttamente collegati agli host Ogni ISP (residenziale, università, compagnia) ha un NS locale Contatta i Root NS Root Name Servers contengono informazioni per l’indirizzamento di grandi gruppi di host e domini Contengono informazioni sugli NS authoritative per un certo dominio Contatta gli Authoritative NS Authoritative Name Servers NS responsabile di un particolare hostname

78. Gerarchia DNS I Name Servers (NS) sono organizzati in maniera gerarchica Source: Computer Networking, J. Kurose

79. Root NS nel 2004 http://www.wia.org/

80. Come ottenere un mappaggio Ogni host ha configurato l’indirizzo del LNS Le applicazioni che richiedono un mappaggio (browser, ftp, etc.) usano le funzioni del DNS Una richiesta viene inviata al server DNS usando UDP come trasporto Il server reperisce l’informazione e restituisce la risposta HOST Local NS DNS request DNS response DNS Network

81. Informazioni memorizzate Type A: Name è il nome di un host e Value è il suo indirizzo IP (morgana.elet.polimi.it, 131.175.21.1, A, TTL) NS: Name è un domain e Value è il nome di un server che può ottenere le informazioni relative (elet.polimi.it, morgana.elet.polimi.it, NS, TTL) CNAME: Name è un nome alternativo (alias) per un host il cui nome canonico è in Value (www.polimi.it, zephyro.rett.polimi.it, CNAME, TTL) MX: Name è dominio di mail o un alias di mail e Value è il nome del mail server (elet.polimi.it, mailserver.elet.polimi.it, MX,TTL) Name, Value, Type , TTL

82. Organizzazione del database I record in ARPANET erano contenuti in un name server centrale Per Internet la struttura del database è distribuita I rami sono partizionati in zone e un DNS server viene associato ad ogni zona Il server di una zona è responsabile per le informazioni di quella zona ( authoritative ) com edu org gov mil it fr jp de ... ucla columbia polimi elet cs virgilio rett yahoo morgana

83. Reperire informazioni in modalità puramente ricorsiva la richiesta viene inoltrata seguendo la gerarchia la risposta segue la strada inversa Source: Computer Networking, J. Kurose

84. Reperire informazioni con la modalità iterativa un server può rispondere ad una richiesta con il nome di un altro server dove reperire l’informazione

85. Caching Un server, dopo aver reperito un’informazione su cui non è authoritative può memorizzarla temporaneamente All’arrivo di una nuova richiesta può fornire l’informazione senza risalire sino al server authoritative Il TTL è settato dal server authoritative ed è un indice di quanto stabile nel tempo è l’informazione relativa I server non-authoritative usano il TTL per settare un time-out

86. Messaggi DNS identification : identificativo coppia richiesta/risposta flag: richiesta/risposta, authoritative/non auth., iterative/recursive number of : relativo al numero di campi nelle sez. successive questions : nome richiesto e tipo (di solito A o MX) answers : resource records completi forniti in risposta authority : contiene altri record forniti da altri server additional infor .: informazione addizionale, ad es. il record con l’IP ADDR. per il MX fornito in answers sono in binario (non ASCII)

87. Applicazioni Peer-to-Peer

88. P2P file sharing Gli utenti utilizzano il software P2P sul proprio PC Si collegano in modo intermittente a Internet prendendo indirizzi IP diversi ogni volta Se un utente cerca un file l’applicazione trova altri utenti che lo hanno L’utente scegli da chi scaricarlo Il file è scaricato usando un protocollo come HTTP Altri utenti potranno (in seguito o in contemporanea) scaricare il file dall’utente L’applicazione P2P è sia client che server. Elevata scalabilità!

89. P2P: directory centralizzata Meccanismo di “Napster” 1) Quando i peer si connettono, informano il server centrale: Indirizzo IP File condivisi 2) Il peer interroga il server centrale per uno specifico file 3) Il file viene scaricato direttamente centralized directory server peers Alice Bob 1 1 1 1 2 3

90. P2P: directory centralizzata Problemi dell’architettura centralizzata Se il server si rompe il sistema si blocca Il server è un collo di bottiglia per il sistema Chi gestisce il server può essere accusato di infrangere le regole sul copyright Il trasferimento file è distributito, ma la ricerca dei contenuti è fortemente centralizzata

91. P2P: completamente distribuita Meccanismo di Gnutella Nessun server centrale Protocollo di pubblico dominio Molti software diversi basati sullo stesso protocollo Basato su una rete (grafo) di overlay I peer si attivano e si collegano ad un numero (<10) di altri vicini La ricerca dei vicini è distribuita I vicini nella rete overlay possono essere fisicamente distanti

92. P2P: completamente distribuita Ricerca di un file I messaggi di richiesta vengono diffusi sulla rete di overlay I peer inoltrano le richieste fino a una certa distanza Le risposte vengono inviate sul cammino opposto File transfer: HTTP Query QueryHit Query Query QueryHit Query Query QueryHit

93. P2P: completamente distribuita Accesso alla rete Per iniziare il processo di accesso il peer X deve trovare almeno un altro peer; la ricerca si basa su liste note X scandisce la lista fino a che un peer Y risponde X invia un messaggio di Ping a Y; Y inoltra il Ping nella rete di overlay. Tutti i peer che ricevono il Ping rispondono a X con un messaggio di Pong X riceve molti messaggi di Pong e può scegliere a chi connettersi aumentando il numero dei suoi vicini nella rete di overlay

94. P2P: architettura ibrida Meccanismo di KaZaA Ogni peer o è un group leader o è assegnato a un group leader. Connessioni TCP tra peer e suo group leader. Connessioni TCP tra alcune coppie di group leaders. I group leader mantengono informazioni sul contenuto dei loro associati