Corso di Sistemi di Misura Distribuiti Ing. Domenico Capriglione capriglione@unicas.it
ARCHITETTURE CLIENT-SERVER I PROTOCOLLI TCP/IP E UDP
ARCHITETTURE CLIENT-SERVER Cosa è un applicazione Client-Server? E un architettura in cui un soggetto detto Client richiede un azione o un servizio da un fornitore del servizio detto Server
ARCHITETTURE CLIENT-SERVER Ad esempio: Un Web browser e un Web Server Quando viene richiesta una connessione ad un certo URL attraverso la finestra di un browser, tale richiesta è effettuata dal Client che sta richiedendo una pagina web da un Web Server Il Server restituisce una pagina html al Client, che viene visualizzata sul computer del Client
ARCHITETTURE CLIENT-SERVER Sviluppando applicazioni client-server, parallelamente si sviluppano programmi modulari La programmazione modulare divide applicazioni grosse in diverse piccole applicazioni più semplici da sviluppare e da gestire in termini di manutenzione In un applicazione Client-Server, i vari moduli non fanno parte dello stesso programma e ogni modulo può essere eseguito anche su diversi sistemi
ARCHITETTURE CLIENT-SERVER Cosa fa il Client? I programmi Client richiedono un servizio dal Server inviandogli un messaggio Ritornando all esempio precedente, quando si richiede il collegamento ad un link, si sta inviando un messaggio al corrispondente Web Server La risposta sarà la pagina HTML richiesta che, grazie al Web Browser (presente sul Client), verrà visualizzata comprensiva dei suoi contenuti grafici
ARCHITETTURE CLIENT-SERVER Cosa fa il Server? Il programma Server processa le richieste provenienti dal Client e se richiesto, restituisce la pagina web I Server sono generalmente passivi ed attendono una richiesta da parte di uno o più Client. Durante i periodi di inattività, i Server possono eseguire altri compiti o eseguire la manutenzione Diversamente dai Client, i Server devono essere continuamente in esecuzione, poiché uno o più Client possono richiedere dei servizi in ogni momento Molte applicazioni Server consentono richieste da più di un Client per volta
ARCHITETTURE CLIENT-SERVER Un esempio in un applicazione di misura: Acquisizione dei dati provenienti da un nodo di misura Si possono considerare tre moduli separati: 1) Modulo di acquisizione dati provenienti dal nodo di misura (ad esempio una termocoppia) 2) Modulo per l analisi del flusso dati e conversione in gradi 3) Modulo per la generazione di un pannello utente di tipo grafico!! Ogni modulo deve fornire i dati in un formato che è comprensibile dal modulo successivo
ARCHITETTURE CLIENT-SERVER Un esempio in un applicazione di misura: Acquisizione dei dati provenienti da una termocoppia Si possono avere 2 soluzioni: 1) Scrivere un unico programma che esegue i 3 moduli tutti su uno stesso sistema 2) Distribuire il processo su più di un sistema, eseguendo ciascuna routine su un sistema differente La scelta dipende dall applicazione!! (Ad esempio, se si stanno acquisendo un grosso numero di punti, potrebbe essere utile svolgere i compiti di acquisizione e analisi su un solo sistema e svolgere la parte di generazione del pannello grafico su un sistema ulteriore).
ARCHITETTURE CLIENT-SERVER Se si vuole avere la possibilità di accedere alle informazioni di misura da un calcolatore differente da quello che si occupa dell acquisizione dati, si può pensare ad una architettura client-server, in cui: - un computer (server) acquisisce e analizza i dati provenienti dal sensore; - un altro computer (client) richiede i dati e li visualizza
ARCHITETTURE CLIENT-SERVER A seconda del sistema di sviluppo (software) si può avere che: - Il server genera una schermata con i dati di misura e la trasmette come immagine (ad esempio jpeg) al client; - Il server invia lo stream dati al client che si occupa di «costruire» localmente l interfaccia grafica per la visualizzazione dei dati
ARCHITETTURE CLIENT-SERVER Alcune considerazioni sul progetto del Server (1) 1) Ci può essere più di un Client? 2) I vari Client sono serviti uno alla volta o contemporaneamente? 3) I vari Client vengono trattati con priorità differenti? Nel caso più semplice (1 client), il server deve soddisfare la richiesta di un solo client Se si ha più di un client, il server deve rimanere in attesa delle richieste. Le varie richieste sono messe in coda (FIFO), e vengono servite in modo da garantire che tutti i client accedano ai dati provenienti dalla misura della temperatura (eventualmente secondo delle priorità) Una volta che la coda si è svuotata, il server si pone in attesa di nuovi client
ARCHITETTURE CLIENT-SERVER Alcune considerazioni sul progetto del Server (2) Il processo di risposta ai client può essere suddiviso in due parti: 1) Rilevazione delle richieste e messa in coda 2) Elaborazione delle richieste (una per volta o contemporaneamente) Elaborare una sola richiesta per volta può essere opportuno per un applicazione semplice, quale il monitoraggio della temperatura Poter servire più client contemporaneamente, diventa essenziale per richieste che necessitano di un maggior tempo per essere soddisfatte, oppure se il numero di client diventa elevato
ARCHITETTURE CLIENT-SERVER Alcune considerazioni sul progetto del Server (3) Alcune applicazioni richiedono di assegnare diverse priorità ai vari client. Un sistema di monitoraggio della temperatura può avere client passivi, i quali visualizzano la temperatura ad ogni dato istante, e client attivi che richiedono la temperatura e la utilizzano nell elaborazione di un applicazione più ampia In tal caso è necessario rendere prioritari i client attivi rispetto a quelli passivi. Il server deve essere in grado di identificare, differenziare e autenticare i servizi di richiesta dei vari client
ARCHITETTURE CLIENT-SERVER E dal lato Client? (1) Deve essere rispettato il protocollo (interfaccia) utilizzato dal lato server L architettura del client non varia molto per i vari casi descritti, infatti l unico compito del programma client è quello di inviare un messaggio di richiesta della temperatura ed interpretare la risposta data dal server (sia con un solo client, sia con server che soddisfano le richieste di più client)
ARCHITETTURE CLIENT-SERVER E dal lato Client? (2) Un programma client che interagisce con un server che serve le richieste in base alle priorità, dovrà implementare un meccanismo di richiesta che includa alcuni parametri per l identificazione e l autenticazione Ad esempio, basterebbero due parametri (ID e password) da aggiungere alla normale richiesta, in modo che il server possa verificare le caratteristiche del client
ARCHITETTURE CLIENT-SERVER E per finire. Il server definisce l interfaccia per la comunicazione con il programma client. Una interfaccia ben progettata, definisce solo come inviare i messaggi, quali tipi di messaggi sono supportati, e quale è il messaggio di risposta al client Il server può essere progettato in maniera modulare, separando il meccanismo di gestione dei messaggi dalla parte funzionale di elaborazione della richiesta Si può aggiornare la parte funzionale, senza richiedere alcuna modifica del programma client
I PROTOCOLLI TCP/IP E UDP IL TCP/IP Il TCP/IP è un protocollo di rete utilizzato nelle reti LAN, WAN, Internet TCP/IP: Transmission Protocol / Internet Protocol, è l insieme di più protocolli E un protocollo a 4 livelli Ogni livello si pone sul livello sottostante aggiungendo delle funzionalità Il livello più basso si occupa della trasmissione dei dati sul mezzo fisico Il livello più alto si occupa di trasferimento file, gestione email, ecc. Tra il livello più alto e quello più basso vi sono altri strati che si occupano di funzioni quali il routing (instradamento dei dati) e affidabilità dei dati
I PROTOCOLLI TCP/IP E UDP IL TCP/IP Confronto con il modello OSI
I PROTOCOLLI TCP/IP E UDP Network Interface Layer IL TCP/IP E responsabile della formattazione dei pacchetti e del loro trasferimento sul mezzo fisico Internet Layer E responsabile dell indirizzamento. I protocolli principalmente utilizzati sono l IP (Internet Protocol), l ARP (Address Resolution Protocol), RARP (Reverse Address Resolution Protocol), ICMP (Internet Control Message Protocol) e IGMP (Internet Group Management Protocol)
I PROTOCOLLI TCP/IP E UDP Transport Layer IL TCP/IP E implementato attraverso il TCP e l UDP. Il TCP fornisce un trasporto di dati affidabile, mentre l UDP non riesce a garantire tale affidabilità Application Layer E responsabile dell interfacciamento tra applicazioni utente e Transport Layer. Le applicazioni più comunemente utilizzate sono l HTTP (HyperText Transfer Protocol) l FTP (File Transfer Protocol), il Telnet, l SNMP (Simple Network Management Protocolo), DNS (Domain Name System), SMTP (Simple Mail Transfer Protocol)
I PROTOCOLLI TCP/IP E UDP Lo scopo del TCP IL TCP/IP E un protocollo affidabile connection-oriented, cioè i dispositivi che intendono comunicare devono stabilire una sessione prima che inizino a scambiare i dati Processi o applicazioni comunicano con ogni altro, avendo la capacità di creare degli end points sia in trasmissione che in ricezione. Questi end points sono detti socket. Un socket viene creato specificando tre parametri: 1) Indirizzo IP del dispositivo 2) Protocollo utilizzato (TCP o UDP) 3) Il numero della porta
I PROTOCOLLI TCP/IP E UDP IL TCP/IP Ogni socket corrisponde ad un numero (indirizzo) che costituisce l indirizzo IP del dispositivo e un numero (a 16 bit) chiamato porta Il numero di porta è utilizzato dai protocolli di trasporto per effettuare l identificazione del tipo di protocollo o processo cui devono fornire i messaggi entranti Il numero di porta può essere compreso tra 0 e 65535 FTP: porta 21 Telnet: porta 23 DNS: porta 43
I PROTOCOLLI TCP/IP E UDP IL TCP/IP Il TCP vede lo stream di dati come una sequenza di byte divisi in vari segmenti Ogni segmento viaggia sulla rete in un singolo pacchetto IP L affidabilità è garantita assegnando un numero di sequenza ad ogni segmento Il dato inviato deve essere riconosciuto dal ricevitore Il controllo di flusso end-to-end è implementato nel seguente modo: se il dispositivo trasmettitore invia dati più velocemente rispetto al tempo necessario al ricevitore per elaborarli, quest ultimo, invierà un acknowledgement indicante che non c è più spazio nel buffer. In tal modo i trasmettitore non invierà nuovi dati fino a che il ricevitore non sarà nuovamente pronto
I PROTOCOLLI TCP/IP E UDP IL TCP/IP Struttura del pacchetto TCP Header = 24 byte
I PROTOCOLLI TCP/IP E UDP IL TCP/IP
I PROTOCOLLI TCP/IP E UDP IL TCP/IP
I PROTOCOLLI TCP/IP E UDP IL TCP/IP STABILIRE UNA CONNESSIONE TCP Il TCP utilizza un handshake a 3 livelli: 1) Il programma client TCP genera un numero di sequenza (1000 nell esempio). Il Client richiede una sessione inviando un segmento con la flag di sincronizzazione (SYN) a 1. Nell header del segmento è anche inclusa la dimensione del buffer in ricezione (window size) e la dimensione massima del segmento dati che può essere gestita, nonché il numero di sequenza 2) Il programma server riconosce (ACK) la richiesta inviando un segmento con la flag di sincronizzazione (SYN) a 1. Nell header del segmento è anche inclusa il numero di sequenza di start-up, acknowledgement e il numero del prossimo segmento che si aspetta ricevere dal client. Inoltre in questo header contiene anche la dimensione del buffer in ricezione (window size) e la dimensione massima del segmento dati che può essere gestita, nonché il numero di sequenza 3) Il client invia un acknowledgement della sequenza di start-up, inviando il numero del prossimo segmento che si aspetta di ricevere
I PROTOCOLLI TCP/IP E UDP IL TCP/IP STABILIRE UNA CONNESSIONE TCP 1 2 3 Ricordare: nel TCP si stabilisce una connessione prima di scambiare segmenti dati
I PROTOCOLLI TCP/IP E UDP L UDP Il protocollo di trasporto di Internet senza fronzoli Servizio best effort, i segm. UDP possono essere: persi Consegnati all appl. fuori ordine connectionless: non c è handshaking tra mittente e destinatario UDP ogni segmento UDP viene trattato separatamente dagli altri Perchè esiste UDP? Non occore stabilire una connessione (meno ritardi) semplicità: non occorre gestire la connessione L header del segmento è piccolo Non c è controllo della congestione: l UDP può spedire dati tanto velocemente quanto lo si desidera
I PROTOCOLLI TCP/IP E UDP Lo scopo del UDP L UDP Fornisce un servizio di tipo connectionless che offre una trasmissione non affidabile ma meno pesante L arrivo dei pacchetti non è garantito, così come la corretta sequenza l affidabilità è responsabilità dell applicazione L UDP è utilizzato in applicazioni che non richiedono un acknowledgement dei dati, ad esempio, audio o video broadcasting L UDP è utilizzato in applicazioni che tipicamente trasmettono pochi dati alla volta
I PROTOCOLLI TCP/IP E UDP L UDP L UDP fornisce dei numeri di porta usati per distinguere tra più programmi che vengono eseguiti sullo stesso dispositivo Quindi in addizione ai dati inviati, ogni messaggio UDP contiene sia il numero della porta di destinazione, sia il numero della porta sorgente Ciò rende possibile, in ricezione di far recapitare il messaggio alla giusta applicazione e di rendere possibile a quest ultima di inviare un reply (se è necessario) Trasferimento affidabile con UDP: aggiungere il controllo dell affidabilità al livello applicazione Recupero dell errore specifico per l applicazione!
I PROTOCOLLI TCP/IP E UDP L UDP Struttura del pacchetto UDP L header UDP è diviso in 4 campi da 16 bits ciascuno Header = 8 byte Source Port: Numero di porta UDP del trasmettitore Destination Port: Numero di porta UDP del ricevitore Length: Lunghezza del pacchetto UDP, includendo header e dati UDP Checksum: E utilizzato per verificare l integrità dell header