La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Come comunicano i processi ? r Sulla stessa macchina m Signal m Pipe m Memoria Condivisa m Code di Messaggi r Su macchine diverse ( stessa LAN ) m File.

Presentazioni simili


Presentazione sul tema: "Come comunicano i processi ? r Sulla stessa macchina m Signal m Pipe m Memoria Condivisa m Code di Messaggi r Su macchine diverse ( stessa LAN ) m File."— Transcript della presentazione:

1 Come comunicano i processi ? r Sulla stessa macchina m Signal m Pipe m Memoria Condivisa m Code di Messaggi r Su macchine diverse ( stessa LAN ) m File condivisi r Su macchine diverse NON stessa rete m Socket

2 Perché i socket r Tecniche di programmazione che rendano la rete "trasparente" ai processi stessi e quindi ai programmatori. r Libreria, nata per Unix, oggi usata per la realizzazione delle applicazioni Internet per quasi tutti i sistemi operativi.

3 Dalle pipe ai socket r Un socket è una struttura dati i cui elementi possono essere utilizzati come argomenti delle usuali chiamate di sistema read() e write() che consentono di scrivere e leggere i file ordinari. r E’ possibile comunicare anche con altre macchine univocamente identificate da un indirizzo IP r Il protocollo utilizzato è TCP/IP o UDP/IP

4 Application Programming Interface r Con Application Programming Interface (API), si indica ogni insieme di procedure, funzioni, strutture dati disponibili al programmatore per implementare un determinato compito all'interno di un certo programma. r Vengono realizzate tramite librerie software disponibili in un certo linguaggio di programmazione.

5 Inter-Process Communication r Inter-Process Communication ( IPC) si riferisce a tutte quelle tecnologie software il cui scopo è consentire a diversi processi di comunicare tra loro scambiandosi dati e informazioni. r I processi possono risiedere sullo stesso computer o essere distribuiti su una rete. Tutti i sistemi operativi multitasking forniscono qualche meccanismo fondamentale di IPC; altri meccanismi più sofisticati o orientati a particolari tipi di sistemi software possono essere forniti da tecnologie middleware In modo equivalente, questi metodi vengono utilizzati per la gestione dei thread. 2: Application Layer 5

6 Middleware r Con middleware si intende un insieme di programmi informatici che fungono da intermediari tra diverse applicazioni e componenti software. Sono spesso utilizzati come supporto per sistemi distribuiti complessi. r Esso oggi identifica una serie di strumenti come DBMS, Web server, Application server, sistemi di gestione dei contenuti ed altri strumenti basati sul concetto di sviluppo e pubblicazione di applicazioni e contenuti. Gli sviluppi attuali si dirigono verso XML, SOAP, REST, servizi Web e architetture orientate al servizio.. 2: Application Layer 6

7 Approccio a livelli r La comunicazione fra calcolatori di tipo diverso è in generale un problema abbastanza complesso. r Vantaggi: m riduzione della complessità (livelli di astrazione); m indipendenza di ogni strato; m interazione tramite servizi; m facilità di cambiamenti su uno strato senza alterare i restanti; m possibilità di utilizzare differenti protocolli.

8 La rete Internet si è sviluppata al di fuori dal modello ISO-OSI, è una architettura composta da 4 strati: strato di accesso alla rete (network access layer); strato Internet Protocol (IP); strato di trasporto (TCP o UDP); strato di applicazione (application protocol);

9 2: Application Layer 9 Livello applicativo Obiettivi generali: r Aspetti concettuali/ implementativi dei protocolli applicativi m Paradigma client server m Modelli dei servizi Obiettivi specifici: r Protocolli specifici: m http m ftp m smtp m pop m dns m Programmazione di applicazioni Uso dei socket

10 2: Application Layer 10 Applicazioni e protocolli applicativi Applicazione: processi ditribuiti in comunicazione m In esecuzione su host remoti m Si scambiano messaggi per eseguire l’applicazione m Es., posta, FTP, WWW Protocolli applicativi m Costituiscono una parte di ogni applicazione m Definiscono il formato dei messaggi scambiati e le loro azioni m Usano i servizi degli strati inferiori application transport network data link physical application transport network data link physical application transport network data link physical

11 2: Application Layer 11 Applicazioni: terminologia essenziale r Un processo è un programma in esecuzione su un host r Sullo stesso host i processi comunicano mediante meccanismi definiti dal SO. r Processi in esecuzione su host diversi comunicano mediante meccanismi definiti dal protocollo dello strato di applicazione (application layer protocol) r Un agente utente (user agent) è un’interfaccia tra l’utente e l’applicazione di rete. m Browser Web m lettore di posta m streaming audio/video: lettore di file audio/video

12 2: Application Layer 12 Paradigma client-server App. di rete tipica consiste di due parti: client e server application transport network data link physical application transport network data link physical Client: r Inizia il dialogo col server (“speaks first”) r Di solito richiede un servizio r Nel caso del Web, il client è integrato nel browser Server: r Fornisce il servizio al client, su richiesta r Es., un Web server invia una pagina Web richiesta, un mail server accede alla casella di posta elettronica richiesta risposta

13 2: Application Layer 13 Protocolli di livello applicativo: servizi dagli strati inferiori e identificazione API: Application Programming Interface r Definisce l’interfaccia tra applicazione e strato di trasporto r Socket: API Internet m Due processi (applicazione nel modello client server) comunicano inviando/leggendo dati nel/dal socket Come può un processo “identificare” quello con cui intende comunicare? m Indirizzo IP dell’host su cui l’altro processo è in esecuzione m Numero di porta (port number) – permette all’host ricevente di identificare il processo locale destinatario del messaggio

14 2: Application Layer 14 Socket: funzionamento di base processo TCP con buffer e variabili socket host o server processo TCP con buffer e variabili socket Programmatore Sistema operativo host o server Internet Programmatore Sistema operativo

15 2: Application Layer 15 Requisiti delle applicazioni Perdita (Data loss) r Alcune app.ni (es., audio) sono tolleranti (fino a un certo punto) r Altre (es., FTP, telnet) richiedono affidabilità totale Ritardo r Alcune applicazioni (es., telefonia Internet, giochi interattivi in rete) richiedono una banda minima per funzionare con qualità sufficiente Banda r Alcune app.ni (soprattutto multimediali) richiedono una banda minima r Altre (dette “elastiche”) usano la banda a disposizione Nota: alcuni requisiti sono determinati da esigenze percettive umane (es. ritardo nella telefonia Internet)

16 2: Application Layer 16 Transport service requirements of common apps Application file transfer Web documents real-time audio/video stored audio/video interactive games financial apps Data loss no loss loss-tolerant no loss Bandwidth elastic audio: 5Kb-1Mb video:10Kb-5Mb same as above few Kbps up elastic Time Sensitive no yes, 100’s msec yes, few secs yes, 100’s msec yes and no

17 2: Application Layer 17 Servizi offerti dai protocolli di trasporto Internet Servizio TCP : r Orientato alla connessione: richiesto “setup” tra client e server r Trasporto affidabile (reliable transfer) tra processi mittente e ricevente r Controllo di flusso) flow control: il mittente non sommerge il ricevente r Controllo della congestione (congestion control): si limita il mittente quando la rete è sovraccarica r Non offre: garanzie di banda e ritardo minimi Servizio UDP : r Trasporto non affidabile tra processi mittente e ricevente r Non offre: connessione, affidabilità, controllo di flusso, controllo di congestione, garanzie di ritardo e banda D: perché esiste UDP? Può essere conveniente per le applicazioni (si vedrà più avanti)

18 2: Application Layer 18 Applicazioni Internet: loro protocolli e protocollo di transporto usato Applicazione remote terminal access Web file transfer streaming multimedia remote file server Internet telephony Protocollo applicativo smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] proprietario (es. RealNetworks) NFS proprietary (e.g., Vocaltec) Protocollo di trasporto usato TCP TCP o UDP tipicamente UDP

19 2: Application Layer 19 WWW: terminologia essenziale r Pagina Web: m È costituita da “oggetti” (di solito: pagina HTML iniziale+oggetti indirizzati) m È indirizzata da una URL r URL (Uniform Resource Locator) m Identifica un oggetto nella rete e specifica il modo per accedere ad esso m Ha due componenti: nome dell’host e percorso nell’host: r Uno user agent per il Web è detto browser: m MS Internet Explorer m Netscape Communicator r un server per il Web è detto Web server: m Apache (pubblico dominio) m MS Internet Information Server

20 2: Application Layer 20 Il Web: protocollo http http: hypertext transfer protocol r Protocollo di livello applicativo per il Web r Usa il modello client/server m client: browser che richiede, riceve e “mostra” oggetti Web m server: Web server che invia oggetti in risposta alle richieste PC running Explorer Server con NCSA Web server ( National Center for Supercomputing Applications Mac running Navigator http request http response

21 2: Application Layer 21 Il protocollo http (cont.) http: usa TCP: r Il client inizia una connessione TCP (crea un socket) verso il server sulla porta 80 r Il server accetta la connesione TCP dal client r Vengono scambiati messaggi http (messaggi del protocollo di livello applicativo) tra il browser (client http) e il Web server (server http) r La connessione TCP è chiusa http è “stateless” r Il server non mantiene informazione sulle richieste precedenti del client I protocolli che mantengono informazione di stato sono complessi (es. TCP) !

22 2: Application Layer 22 Esempio http L’ utente accede alla URL 1a. Il client http inizia una connessione TCP verso il server (processo) http sull’ host La porta 80 è quella standard (default) per i server http. 2. Il client http invia un messaggio di richiesta http (request message) contenente la URL 1b. Il server http presso l’ host è “in ascolto” sulla porta 80. “Accetta” la richiesta di connessione e ne dà conferma al client 3. Il server http riceve il messaggio di richiesta, costruisce un messaggio di rispota (response message) contenente l’oggetto richiesto ( someDepartment/home.index ), inoltra il messaggio nel socket Tempo (contiene testo e i riferimenti a 10 immagini jpeg)

23 2: Application Layer 23 Esempio http (cont.) 5. Il client http riceve il messaggio di risposta contenente il file html, visualizza la pagina html. Analizzando il file html, il browser trova i riferimenti a 10 oggetti jpeg 6. I passi 1-5 sono ripetuti per ciascuno dei 10 oggetti jpeg 4. Il server http chiude la connessione TCP. time

24 2: Application Layer 24 Connessioni persistenti e non-persistenti Non-persistente r HTTP/1.0 r Il server analizza la richiesta, risponde e chiude la connessione TCP r 2 RTTs per ricevere ciascun oggetto r Ogni oggetto subisce lo “slow start” TCP r E’ possibile parallelizzare le richieste agli oggetti di una pagina Persistente r default per HTTP/1.1 r Sulla stessa connessione TCP : il server analizza una richiesta, risponde, analizza la richiesta successiva,.. r Il client invia richieste per tutti gli oggetti appena riceve la pagina HTML iniziale. r Si hanno meno RTTs e slow start. r Connessione incanalata: m non si attende la risposta alla richiesta prededente prima di inviare la successiva. m Richiesta successiva a ridosso della precedente cosi’ come le risposte del server. m Solo 2 RTT per ottenere un insieme di oggetti

25 2: Application Layer 25 Formato dei messagi http r Due tipi di messaggi http: request, response r Messaggio http request: m ASCII (formato testo leggibile) GET /somedir/page.html HTTP/1.1 Host: Connection: close User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr (extra carriage return, line feed) Request line (GET, POST, HEAD commands) header lines Carriage return, line feed indica fine messaggio Chiudi la connessione al termine della richiesta

26 2: Application Layer 26 Message http request : formato generale

27 2: Application Layer 27 Message http request : formato generale r Metodo post: m Usato quando l’utente compila una form. Il contenuto dei campi della forms sono disposti nell’Entitiy Body m Il comando richiede una pagina Web il cui contenuto dipende dalle informazioni nel campo body m Ex: Query inviata ad un motore di ricerca r Metodo Head: m Simile al metodo get ma viene restituito solo l’Head della pagina Web m Spesso usato in fase di debugging

28 2: Application Layer 28 Formato del messaggio http response HTTP/ OK Connection: close Date: Thu, 06 Aug :00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html data data data data data... status line (protocol status code status phrase) header lines data, e.g., requested html file Client HTTP 1.0: Server chiude connessione al termine della richiesta Client HTTP 1.1: mantiene aperta la connessione oppure chiude se Connection: close

29 2: Application Layer 29 Risposta: codici di stato 200 OK m Successo, oggetto richiesto più avanti nel messaggio 301 Moved Permanently m L’oggetto richiesto è stato spostato. Il nuovo indirizzo è specificato più avanti (Location:) 400 Bad Request m Richiesta incomprensibile al server 404 Not Found m Il documento non è stato trovato sul server 505 HTTP Version Not Supported Prima riga del messaggio di risposta server->client. Alcuni esempi:

30 2: Application Layer 30 Prova (client) 1. Telnet verso un Web server: Apre connessione TCP verso la porta 80 (default) prsso Tutto quanto viene digitato è inviato alla porta 80 di telnet Si digita una richiesta http GET: GET /~leon/index.html HTTP/1.0 Digitando ciò (carriage return due volte), si invia una richiesta GET al server http 3. Si osservi la risposta!

31 2: Application Layer 31 Autenticazione Obiettivo: controllare l’ accesso ai documenti sul server r stateless: il client deve autenticare ogni richiesta r autenticazione: tipicamente log e password  authorization: riga nell’header del messaggio di richiesta m Senza autenticazione il server rifiuta la connessione WWW authenticate: Nell’ header client server usual http request msg 401: authorization req. WWW authenticate: usual http request msg + Authorization:line usual http response msg usual http request msg + Authorization:line usual http response msg Tempo Il browser memorizza nome & password in modo che l’utente non debba digitarli ogni volta.

32 2: Application Layer 32 Cookie r Il server invia un “cookie” al client con la risposta Set-cookie: r Il client presenta il cookie in accessi successivi cookie: r Il server controlla il cookie presentato m Autenticazione m Traccia delle preferenze dell’utente client server usual http request msg usual http response + Set-cookie: # usual http request msg cookie: # usual http response msg usual http request msg cookie: # usual http response msg cookie- spectific action cookie- spectific action

33 2: Application Layer 33 GET condizionale (conditional GET) r Obiettivo: non inviare oggetti che il client ha già in cache r client: data dell’oggetto memorizzato in cache If-modified-since: r server: la risposta è vuota se l’oggetto in cache è aggiornato: HTTP/ Not Modified client server http request msg If-modified-since: http response HTTP/ Not Modified object not modified http request msg If-modified-since: http response HTTP/ OK … object modified

34 2: Application Layer 34 Web Cache (proxy server) r L’utente configura il browser: accesso attraverso web cache r Il client invia tutte le richieste al proxy r La cache restituisce l’oggetto se presente m Altrimenti l’oggetto è richiesto prima al server e poi è restituito al client Obiettivo: rispondere alle richieste evitando di accedere al derver remoto client Server proxy client http request http response http request http response http request http response Server di origine Server di origine

35 2: Application Layer 35 Perché il Web Caching? Assunzione: la cache è “vicina” al client (es., stessa rete locale) r Tempo di risposta minore: la cache è “più vicina” al client r Diminuisce il traffico verso server lontani m Il link di uscita della rete di un ISP istituzionale/locale è spesso un collo di bottiglia server di origine Internet Rete del DIS LAN a 10 Mbps Link di acesso a 1.5 Mbps Cache del DIS

36 2: Application Layer 36 Perché il Web Caching? r Richieste di 100Kb/sec, 15 richieste per secondo. Intensità di traffico I =1 r Occorre aggiornare la velocità di connessione esterna, i.e. da 1.5 a 10 Mb/sec r Alternativa: adottare un proxy cache interno alla LAN r Se riesce a servire il 40% delle richieste, hit rate = 0,4, I = 0,6 (ritardo sale esponenzialmente quando I->1)

37 2: Application Layer 37 Caching cooperativo r Insieme di proxy cache in cooperazione distribuiti su Internet. r Possono essere distribuiti in modo gerarchico. Le cache di livello superiore mantengono una copia della pagina mentre questa viene inviata ad una cache di livello inferiore. r Permette a server con bassa connettività di servire grandi quantità di richieste r Internet Caching Protocol: comunicazione tra cache

38 2: Application Layer 38 Cluster di Cache r Permettono di alleviare il carico su una singola cache r Occorre saper quale cache contiene una specifica pagina r Si ricorre all’instradamento attraverso tabelle hash (Cache Array Routing Protocol) r L’elaborazione hash assegna ogni pagina ad una singola cache

39 2: Application Layer 39 Esercizi r Una pagina Web contiene 5 oggetti. r Quanti RTT sono necessari per una rchiesta http nel caso di a. Connessioni non persistenti b. Connessioni persistenti non incanalate c. Connessioni persistenti incanalate

40 2: Application Layer 40 ftp: File transfer protocol r Trasferimento file da/verso un host remoto r Usa il modello client/server m client: parte che richiede il trasferimento (da/verso l’ host remoto) m server: host remoto r ftp: RFC 959 r ftp server: porta 21 file transfer FTP server FTP User interface FTP client local file system remote file system Utente su un host

41 2: Application Layer 41 ftp: connessioni controllo e dati separate r Il client contatta il server sulla porta 21, specificando TCP come protocollo di trasporto r due connessioni TCP parallele: m controllo: scambio di messaggi di controllo tra client e server. “controllo fuori banda” m dati: trasferimento dati da/verso il server r Entrambi le connessioni aperte dal client r Il server ftp mantiene info di “stato”: directory corrente, autenticazione r Una nuova connessione per ogni file trasferito FTP client FTP server Connessione di controllo TCP porta 21 TCP data connection porta 20

42 2: Application Layer 42 ftp comandi, risposte Esempi di comandi: r Inviati come testo ASCII mediante il canale di controllo  USER username  PASS password  LIST richiede la lista dei file nella directory corrente (ls)  RETR richiede (get) un file  STOR scarica (put) un file sull’ host remoto Esempi di codici r Codice di stato e frase (come in http) r 331 Username OK, password required r 125 data connection already open; transfer starting r 425 Can’t open data connection r 452 Error writing file

43 2: Application Layer 43 Posta elettronica Tre componenti principali : r User agent r Server di posta r Simple Mail Transfer Protocol: SMTP User Agent r “Lettore di posta” r Composizione e lettura di messaggi di posta r Es., Eudora, Outlook, elm, Netscape Messenger r I messaggi in ingresso/uscita memorizzati sul server user mailbox outgoing message queue mail server user agent user agent user agent mail server user agent user agent mail server user agent SMTP

44 2: Application Layer 44 Posta elettronica: mail server Mail Server r Mailbox contenente messaggi (non ancora letti) per l’utente r Coda di messaggi in uscita (non ancora spediti) r Protocol smtp tra i mail server per il recapito dei messaggi m client: il server che invia il messaggio m “server”: server che riceve il messaggio Nota: solo una distinzione di ruoli mail server user agent user agent user agent mail server user agent user agent mail server user agent SMTP

45 2: Application Layer 45 Recapito di un messaggio di posta elettronica r Alice compone un messaggio e lo inoltra al suo Mail Server r Mail Server dispone il messaggio nella coda di messaggi in uscita r Mail Server di Alice apre una connessione smtp con il Mail Server di Bob ed inoltra il messaggio r Se il contatto fallisce, l’invio è ripetuto ogni trenta minuti r Se l’invio fallisce per diversi giorni, mail di notifica inviato ad Alice r Mail Server di Bob riceve il messaggio dal Mail Server di Alice e lo salva nella Mailbox di Bob r Bob accede la propria Mailbox specificando Username e Password r Messaggi possono essere trasferiti dalla Mailbox all’host da cui Bob ha acceduto la Mailbox e/o lasciati sul server r Bob legge il messaggio di Alice

46 2: Application Layer 46 Posta elettronica: smtp [RFC 821] (1982!) r Usa tcp per il trasferimento affidabile dei messagi da client a server, porta 25 r Trasferimento diretto: da server a server, non si usano server intermedi di posta r Tre fasi m Handshaking (saluto) m Trasferimento di uno o più messaggi (connessione permanente) m Chiusura r Interazione mediante comandi/risposte m Comando: testo ASCII m Risposta: codice di stato e frase r Attenzione: I messaggi devono essere comunque riportati in formato ASCII a 7 bit, anche dati multimediali

47 2: Application Layer 47 Esempio di interazione SMTP S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: S: 250 Sender ok C: RCPT TO: S: 250 Recipient ok C: DATA S: 354 Enter mail, end with "." 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

48 2: Application Layer 48 Prova  telnet servername 25 r Attendi 220 risposta dal server r Inserisci HELO, MAIL FROM, RCPT TO, DATA, QUIT r Comandi permettono di inviare senza usare un User Agent

49 2: Application Layer 49 SMTP: conclusioni r Connessioni TCP persistenti r Richiede che il messaggio (header & corpo) sia in formato ascii 7-bit  Alcune sequenze di caratteri non consentite (es., CRLF.CRLF ). Conseguenza: il messaggio deve essere codificato  Il server smtp usa CRLF.CRLF per determinare la fine del messaggio Confronto con http r http: pull r push r Entrambi usano un’interazione mediante comandi/risposta in testo ASCII e codici di stato r http: ogni oggetto incapsulato nel messaggio di risposta r smtp: un messaggio con più oggetti è inviato mediante un messaggio in più parti

50 2: Application Layer 50 Formato dei messaggi smtp: protocollo per lo scambio di messaggi di posta RFC 822: standard per il formato dei messaggi inviati: r header, es., m To: m From: m Subject: Diversi dai comandi smtp! r body m Il “messaggio” vero e proprio, solo caratteri ASCII header body Linea vuota

51 2: Application Layer 51 Formato: estensioni multimediali r MIME: multipupose internet mail extension, RFC 2045, Dati Multimediali e di specifiche applicazioni r Righe addizionali dell‘ header specificano il tipo del contenuto MIME From: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data base64 encoded data Tipo di dato multimediale, sottotipo, dichiarazione di parametri Metodo di codifica Versione MIME Dati codificati

52 2: Application Layer 52 Tipi MIME Content-Type: type/subtype; parameters Text  Esempi di sottotipi: plain, html Image  Esempi di sottotipi : jpeg, gif Audio  Esempi di sottotipi : basic (8-bit mu-law encoded), 32kadpcm (32 kbps coding) Video  Esempi di sottotipi : mpeg, quicktime Application r Dati che devono essere processati da un’ applicazione prima di essere “visibili”  Esempi di sottotipi : msword, octet-stream

53 2: Application Layer 53 Tipo Multipart From: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Dear Bob, Please find a picture of a crepe Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data base64 encoded data r contenenti più oggetti. r Boundary character: delimitano i messaggi. r Content-Transfer- Encoding e Content- Type per ogni oggetto

54 2: Application Layer 54 Messaggio ricevuto r Received indica i Mail Server che hanno recapitato il messaggio r Più linee “Received” se il messaggio è stato inoltrato da più server SMTP lungo il percorso da mittente a destinatario Received: from crepes.fr by hamburger.edu; 6 Oct 2003 From: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg

55 2: Application Layer 55 Protocolli di accesso alla posta r Soluzione tradizionale: utente legge direttamente la posta sul Mail Server r L’host su cui è disposto il Mail Server deve essere sempre attivo r Agenti di posta permettono di trasferire la posta dal Mail Server all’host locale al ricevente r Possibile visualizzare file multimediali e di specifiche applicazioni r Occorre un protocollo “Pull” per accedere alla Mailbox collocata sul Mail Server

56 2: Application Layer 56 Protocolli di accesso alla posta r SMTP: consegna al/memorizzazione nel server di posta del ricevente r Protocollo di accesso: recupero della posta dal server locale m POP: Post Office Protocol [RFC 1939] Autenticazione (agent server) e scaricamento m IMAP: Internet Mail Access Protocol [RFC 1730] Più possibilità (più complesso) Manipolazione dei messaggi memorizzati sul server m HTTP: Hotmail, Yahoo! Mail, ecc. user agent mail server del mittente user agent SMTP POP3 o IMAP mail server del ricevente

57 2: Application Layer 57 Protocollo POP3 Fase di autorizzazione r Comandi del client:  user: nome utente  pass: password r Risposte del server m +OK  -ERR Fase di transazione, client:  list: lista numeri e dim. msg  retr: scarica messaggio in base al numero  dele: cancella r quit C: list S: S: S:. C: retr 1 S: S:. C: dele 1 C: retr 2 S: S:. C: dele 2 C: quit S: +OK POP3 server signing off S: +OK POP3 server ready C: user alice S: +OK C: pass hungry S: +OK user successfully logged on

58 2: Application Layer 58 Protocollo POP3 r Scarica ed elimina: 1. User Agent elimina la posta dalla Mailbox dopo averla scaricata 2. Un utente disperde la posta sui diversi host da cui accede la Mailbox 3. User Agent permette di creare cartelle, spostare messaggi, effettuare ricerce nei messaggi r Scarica e conserva 1. User Agent conserva la posta sulla Mailbox 2. Utente può leggere i messaggi da macchine diverse 3. POP3 stateless, non permette di strutturare i messaggi in directory

59 2: Application Layer 59 Protocollo IMAP r Permette di gestire cartelle di posta remote come se fossero locali r IMAP deve mantenere una gerarchia di caretelle per ogni utente r Permette allo User Agent di scaricare solo parti del messaggio: m Intestazione m Solo intestazione file MIME Multipart m Messaggi di dimensione piccola per utenti a banda limitata r Stati: m Non-authenticated: utente deve fornire username e password per la connessione m Authenticated State: utente deve specificare una cartella prima di eseguire comandi che influiscono sul messaggio m Selected State: utente può dare comandi che influiscono sul messaggio, e.g. elimina, salva, sposta m Logout State: sessione terminata

60 Fine 2: Application Layer 60

61 2: Application Layer 61 Esempio:DBMS, Web Server, ecc. Gli sviluppi attuali si dirigono verso XML, SOAP (Simple Object Access Protocol), servizi Web e architetture orientate al servizio.


Scaricare ppt "Come comunicano i processi ? r Sulla stessa macchina m Signal m Pipe m Memoria Condivisa m Code di Messaggi r Su macchine diverse ( stessa LAN ) m File."

Presentazioni simili


Annunci Google