cerca
Lezioni con Ceravolo
modifica cronologia stampa login logout

Wiki

UniCrema


Materie per semestre

Materie per anno

Materie per laurea


Help

Lezioni con Ceravolo

Torna alla pagina di Sistemi per l'elaborazione delle informazioni

:: 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 posta altrove sulla rete. Esempi di questi protocolli sono: server Email su internet, Msn, Emule, VoIp ecc...

Torna su

Nozioni preliminari

Ci sono tipi diversi di applicazioni distribuite:

  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)
  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 che è scalabile cioè funziona sia con pochi utenti che con tanti.
  3. 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).

Torna su

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. 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).

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:

Porta Servizio
20 /tcp FTP (data)
21 /tcp FTP (controllo)
23 /tcp Telnet
25 /tcp SMTP
53 /tcp/udp DNS
80 /tcp HTTP
110 /tcp POP3
143 /tcp IMAP4


Torna su

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.

Torna su

Che tipi di servizio richiede un'applicazione distribuita?

In base a ciò che un'applicazione richiede 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.

Torna su

Livello di trasporto: TCP vs UDP

TCP UDP
connessione NO connessione
controllo flusso NO controllo flusso
controllo congestione NO congestion control
NO timing NO timing
NO banda minima NO banda minima


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)

Una URI può essere rappresentata in forma di URL, URN o una combinazione di entrambi.

Torna su

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' 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 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! Mantenere la connessione aperta non significa avere gli stati.

HTTP Message

Nell' HTTP 1.0:

  • 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 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:

  • una si limita a NON chiudere la connessione dopo l'invio di un 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:

HTTP 1.0 HTTP 1.1 Descrizione
GET 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 POST Serve a richiedere dati al server, ma in questo caso la risposta finisce nel body.
HEAD HEAD Non chiede tutto l'oggetto ma solo l'intestazione (eg. per conoscere quando è stato aggiornato l'oggetto).
PUT Per l'upload dei file.
DELETE Per cancellare file dal server.


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

HTTP REQUEST 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 RESPONSE MESSAGE:
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.
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:

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

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.

Proxy server

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.

Torna su

FTP

File Transfer Protocol. Attivo 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. 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

Posta elettronica

Esistono tre componenti principali:

  1. user agent (il client email, ad esempio Thunderbird o Outlook)
  2. mail server
  3. SMTP (Simple Mail Transfer Protocol)

...e tre fasi di comunicazione:

  1. handshaking
  2. transfer
  3. closure

Il messaggio viene passato in codifica ASCII.

Passaggi:

  1. Scrivo 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. SMTP client manda il messaggio attraverso una connessione TCP
  5. Il mail server del destinatario mette il messaggio nella casella di posta destinata
  6. Per leggere il messaggio utilizzo di nuovo l'User agent

Sample SMTP interaction

Il client si presenta con il comando HELLO: 

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ò eseguire il tutto 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.

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

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.

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, nel DATA di una mail, ogni singolo pezzo ha il suo charnet e il suo tipo MIME.

Torna su

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 mail 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 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.

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 mantenere DNS per indirizzi interni alla rete.
I DNS mantengono una cache (aggiornata) di indirizzi dopo che ne hanno trovati alcuni sconosciuti.

Al DNS si possono fare delle richieste:

  • TYPE A: dò un nome intero, voglio un IP
  • TYPE NS: dò un dominio, 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 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.

Torna su

Content distribution

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 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 (ottimizzare contenuti server)
  • mirroring
  • distribution 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.

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. 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
  3. data transfert: permette a un host di prendere le risorse da 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 centralizzato - Eg. 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 è decentralizzato

P2P distribuito - Eg. Gnutella

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.

Per capire meglio l'architettura vedi slide 86

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.

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.

Torna su

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.

Torna su

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 address e 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

Torna su

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.
Dopo aver creato un server HTTP posso fare le richieste direttamente dal browser.

Torna su

Torna alla pagina di Sistemi per l'elaborazione delle informazioni