Senza titolo

In questo articolo, Le reti LAN e lo standard 802, analizziamo le modalità con le quali le reti LAN accedono al mezzo trasmissivo utilizzando i protocolli di accesso alla rete specificati dagli standard 802 (ETHERNET)

Indice dei contenuti

- Introduzione - Lo standard 802 - Sottolivello superiore LLC: 802.2 - Sottolivello inferiore MAC: 802.3 - Ethernet- Gli indirizzi MAC - Rilevamento delle collisioni Ethernet - CSMA/CD - Gli Switch- Funzionamento dello switch - Struttura di uno switch layer 2 - Dalla CSMA/CD allo switching - Tecnologie Ethernet ed evoluzione- Ethernet, Fast Ethernet, Gigabit Ethernet

Introduzione

Nel mese di febbraio del 1980 gli enti di standardizzazione IEEE, ISO, ANSI hanno dato vita ad un progetto con l'obiettivo di stabilire come devono essere realizzate le reti LAN ai livelli fisico e data link del modello ISO/OSI in termini di servizi disponibili e di protocolli per l'espletamento di tali servizi. Tale progetto ha preso il nome dal mese (2) e dall'anno (80) in cui ebbe inizio. Naque così il progetto IEEE 802. Tale progetto, in continuo aggiornamento, si propone dunque di standardizzare le principali tecnologie di rete e definire un'insieme di regole per passare da una tecnologia all'altra

Lo standard 802

Gli standard introdotti dal Progetto 802 stabilirono 20 categorie con cui identificare i diversi modi di accedere al canale di trasmissione già commercializzate e quelle ancora in fase progettuale: Standard IEEE 802Descrizione802Overview and Architecture802.1Bridging and Management802.2Logical Link Control802.3CSMA/CD Access Method (Ethernet)802.4Token-Passing Bus Access Method802.5Token Ring Access Method802.6DQDB Access Method (Distributed Queue Dual Bus)802.7Broadband (Technical Advisory Group)802.8Fiber-Optic (Technical Advisory Group)802.9Isochronous LAN802.10Interoperable LAN/MAN Security802.11Wireless LAN (Wi-Fi)802.12Demand Priority Access Method (100VG-AnyLAN)802.13Cable-TV Based Broadband Networks (mai completato)802.14Cable Modem LAN802.15Wireless PAN (Bluetooth)802.16Broadband Wireless MAN (WiMAX)802.17Resilient Packet Ring (RPR)802.18Radio Regulatory (Technical Advisory Group)802.19Coexistence (Technical Advisory Group)802.20Mobile Broadband Wireless Access Il problema di fondo che il progetto IEEE 802 si è proposto di risolvere, oltre alla standardizzazione e l'interoperabilità delle diverse tecnologie di rete, è stato quello di stabilire degli algoritmi di accesso al canale cioè definire delle tecniche che consentissero di evitare eventuali conflitti tra più stazioni che vogliono trasmettere sullo stesso mezzo trasmisivo. Ci sono due possibilità: La tecnica a contesa: se due o piu stazioni vogliono tarsmettere simultaneamente il conflitto viene risolto secondo alcune regole di mediazione. Le prestazioni possono essere calcolate solo statisticamente, in relazione alla probabilità che all’inizio di una trasmissione non vi sia una contesa tra stazioni per l’accesso al mezzo trasmissivo. Non è quindi possibile stabilire a priori l’intervallo di tempo necessario per portare a termine una trasmissione. La più nota tecnica a contesa è la CSMA/CD (Carrier Sense Multiple Access with Collision Detection) basata sulla gestione delle collisioni. Le reti Ethernet (IEEE 802.3) con hub e velocità di 10 Mbps utilizzano questa tecnica (verrà poi soppiantata dalle tecniche di switching con l'introduzione degli switch). Un’altra tecnica è la CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) basata sulla prevenzione delle collisioni. Le reti Wi-Fi (IEEE 802.11) utilizzano questa tecnica che verrà approfondita nelle lezioni successive La tecnica deterministica: dà luogo a reti deterministiche, in cui ogni trasmissione avviene in un istante definito e sicuramente va a buon fine, dato che in quell’istante la stazione trasmittente è l’unica a possedere l’accesso al canale. Le prestazioni delle reti non a contesa possono essere determinate con precisione, rendendo le reti particolarmente adatte alle trasmissioni in real time. Le più note tecniche deterministiche sono quelle basate su un token (gettone) che autorizza a trasmettere chi se ne impossessa. Lo standard Token Ring (IEEE 802.5) utilizza questa tecnica Le architetture di rete hanno dovuto tenere conto delle diverse tecnologie e dei metodi di accesso alternativi standardizzati dal Progetto 802. In particolare il livello Data Link di ISO/OSI è stato suddiviso in due sottolivelli: LLC (Logical Link Control) e MAC (Media Access Control) che rappresentano il cuore del Progetto 802

In questo senso i due grandi problemi descritti in precedenza sono stati risolti definendo i due sottolivelli: - LLC --> soluzione al problema dell'interfaccia unificata verso il livello Network - MAC --> soluzione al problema dell'accesso al mezzo trasmissivo condiviso Analizziamoli nel dettaglio.

Sottolivello superiore LLC: 802.2

Il sottolivello superiore è l’LLC che ha il fondamentale compito di fornire un’interfaccia unificata verso il livello Network, pur a fronte di tecnologie trasmissive e mezzi fisici differenziati. Può inoltre occuparsi del controllo del flusso di trasferimento dei dati Il formato della trama dell'LLC è il seguente:

Poiché a livello di Network possono operare vari protocolli (il principale è IP), il sottolivello LLC deve individuare qual è il protocollo usato per la comunicazione. Proprio per questo scopo il frame di LLC contiene due indirizzi, da un byte ciascuno, detti DSAP (Destination Service Access Point) e SSAP (Source Service Access Point), che rappresentano rispettivamente l’identificatore del protocollo di livello superiore, cui deve essere consegnato il frame (PDU) ricevuto, e l’identificatore del protocollo di livello superiore, da cui il packet è arrivato nel dialogo tra due peer entity.

Il bit meno significativo (LSB) dell'indirizzo DSAP (Destination Service Access Point) nell'LLC (Logical Link Control), fare attenzione, da specifica 802.2 il LSB è quello a sinistra, indica se l'indirizzo si riferisce a un singolo SAP (Service Access Point) o a un gruppo di SAP. Nello specifico, se il bit meno significativo è 0, si tratta di un indirizzo individuale, mentre se è 1, si tratta di un indirizzo di gruppo. Analogamente il LSB del SSAP vale 0 se si tratta di un comando mentre vale 1 se si tratta di una risposta. Il sottolivello LLC prevede 3 modi di funzionamento: - Unacknowledged Connectionless Service: costituito solo da primitive di trasferimento dati, è un servizio non affidabile e non orientato alla connessione. - Connection Oriented Service: costituito da primitive di trasferimento e di apertura e chiusura di una connessione con le funzioni per il controllo di errore, di flusso e di conservazione della sequenza - Semireliable Connectionless Service: costituito anch’esso solo da primitive di trasferimento dati ma, pur essendo non orientato alla connessione, prevede una conferma di ricezione (ACK) per i datagrammi inviati e garantisce la consegna ordinata dei dati trasmessi Il campo Control può essere lungo 1 o 2 byte e avere 3 formati: - il formato information è usato per le trame che trasportano i dati in modalità connessa e ha anche la possibilità di trasportare un acknowledge (ACK) per la trasmissione nella direzione inversa (tecnica detta di piggybacking). Le trame di questo formato sono dette I-frame; - il formato supervisor non prevede la presenza del campo information nella trama ed è usato per trasportare informazioni di controllo relative agli I-frame; per esempio, fornire un ACK in assenza di traffico nella direzione inversa oppure operare il controllo di flusso. Le trame di questo formato sono dette S-frame; - il formato unnumbered è utilizzato per due scopi diversi: trasportare dati di utente in modalità non connessa e trasportare messaggi di controllo del collegamento (inizializzazione, diagnostica, ecc.). Le trame di questo formato sono dette U-frame. Il campo NETWORK PDU (o information) può avere 0 o più byte (non è stabilito un limite massimo, ma PDU troppo grandi potrebbero essere frammentate dal sottolivello MAC) che contengono la PDU che il livello superiore (Network Layer) si attende di ricevere dal sottolivello MAC in ricezione o invia al sottolivello MAC in trasmissione.

Sottolivello inferiore MAC: 802.3 - Ethernet

Tutto quanto descritto nel documento 802.3 rappresenta di fatto tutta la tecnologia Ethernet, o meglio, una famiglia di tecnologie che comprende sia protocolli del livello Data Link, sia le tecnologie del livello Fisico a essi associate

Ethernet è nata a metà anni ’70 nei laboratori Xerox PARC (Palo Alto Research Center - California), presso i quali Robert Metcalfe progettò una rete con topologia a bus con cavi coassiali

Gli standard attuali, definiti nello standard IEEE 802.3, privilegiano: - una topologia a stella con uno switch come centro della stella - un cablaggio realizzato con doppini di rame intrecciati o cavi in fibra ottica (il cavo coassiale è ormai superato) con velocità che vanno dai 100 Mbps fino a 100 Gbps - la trasmissione dei dati in banda base: il segnale che contiene l'informazione è inviato direttamente, senza essere modulato, e quindi, senza essere trasferito in una banda di frequenza diversa dalla propria - la codifica Manchester e le sue varianti Come detto in precedenza, il sottolivello inferiore MAC risolve il problema dell’accesso al mezzo trasmissivo condiviso. Cioè il suo compito è arbitrare l’accesso all’unico mezzo trasmissivo comune tra tutti i sistemi che hanno necessità di trasmettere in una determinata rete. Quindi mentre l’LLC è unico, si avrà invece uno standard MAC (condiviso tra sottolivello MAC e livello Physical) diverso per ogni tipo di rete e mezzo fisico di trasmissione. Una trama del sottolivello MAC – Ethernet è costituita da: - un’intestazione (header); - i dati ricevuti dal livello LLC; - una coda (trailer). In particolare, la trama «Ethernet II» (la versione che ha sostituito quella iniziale) hanno una lunghezza variabile da 64 e 1518 byte (escludendo preambolo ed SFD) e prevede i campi mostrati nella figura seguente:

- Preambolo (7 byte): serve per delimitare la trama (framing). È una sequenza di bit (1 e 0) che si alternano per permettere al ricevente di sincronizzarsi con il trasmittente; - SFD (Start Frame Delimiter) (1 byte): è sempre impostato con i bit «10101011». Avvisa il ricevente che i successivi 6 byte sono l’indirizzo di destinazione; - Indirizzo MAC di destinazione (6 byte): contiene l’indirizzo MAC della scheda di interfaccia di rete del dispositivo a cui è destinato il messaggio; - Indirizzo MAC di origine o mittente (6 byte): contiene l’indirizzo MAC della scheda di interfaccia di rete del dispositivo che genera il messaggio; - Tipo (2 byte): in «Ethernet II» questo campo contiene un numero che identifica il protocollo di rete sovrastante, incapsulato nella trama Ethernet. I valori presenti nel campo Tipo sono, per esempio, 0800 (in esadecimale) per IPv4 o 86DD per IPv6; - Dati (minimo 46 byte, massimo 1500 byte): contiene i dati ricevuti dal livello superiore (la trama del livello LLC). Se il campo ha una lunghezza inferiore, allora deve essere “completato” con caratteri di riempimento. Questo garantisce che la dimensione del frame raggiunga almeno 64 byte, essenziale per evitare che la trasmissione di frame troppo corti provochi la mancata rilevazione delle collisioni che possono capitare quando due stazioni trasmettono nello stesso istante; - FCS (Frame Check Sequence) (4 byte): contiene il codice a 32 bit, generato con la ecnica dei polinomi a ridondanza ciclica (CRC) per la rilevazione deglierrori Non esiste un segnalatore di fine frame. Tale ruolo è assunto dall’inter-frame spacing (o IFG inter-packet GAP), che ha lo scopo di definire lo spazio temporale minimo tra due frame consecutivi. Il valore minimo standardizzato per l’inter-frame spacing delle reti Ethernet è di 96 bit time. Lo spazio temporale minimo tra due frame consecutivi dipende dalla velocità trasmissiva, quindi 96 bit time corrispondono a 9,6 μs a 10 Mbps, 960 ns a 100 Mbps, 96 ns a 1 Gbps, 9,6 ns a 10 Gbps e così via per le altre velocità. Notare come la distanza minima in termini temporali tra due frame consecutivi si riduca molto all’aumentare della velocità trasmissiva. Gli indirizzi MAC L’indirizzo MAC, o fisico (Physical Address), è formato da 6 byte (48 bit), e individua univocamente una scheda di rete a livello mondiale: - i fornitori dei dispositivi ricevono da IEEE un codice univoco di 3 byte (6 cifre esadecimali), chiamato identificatore univoco dell’organizzazione (OUI – Organizationally Unique Identifier), - a questo codice è aggiunto un numero di serie di 3 byte per ogni singola scheda, chiamato Network Interface Controller Specific

Un indirizzo MAC identifica il dispositivo o, meglio, la sua «interfaccia di rete». È cablato nella ROM della scheda NIC (Network Interface Card) (Figura 6), e viene caricato nella RAM all’avvio del sistema. È compito del produttore garantire che ogni suo dispositivo abbia un indirizzo MAC differente. Gli indirizzi MAC possono essere: - unicast: individuano una singola stazione - multicast: individuano un gruppo. Ad esempio FF:FF:FF:X:XX:XX indica tutti gli host con scheda di rete di qualsiasi produttore e con prima cifra del 3° byte compresa tra 0 e F - broadcast: individuano tutti gli host connessi alla rete e può essere solo FF:FF:FF:FF:FF:FF Per ambienti Windows possiamo identificare l'indirizzo MAC digitando il comando ipconfig/all al prompt dei comandi:

Ricercando in rete E8-F4-08 ad esempio dal sito https://maclookup.app/ otteniamo:

Per ambienti LINUX possiamo identificare i MAC address attraverso il comando ifconfig -a Quando una stazione vuole inviare un messaggio, deve inserire nei campi dell’intestazione della trama il proprio indirizzo e quello di destinazione (Figura). Quando una stazione riceve il messaggio, deve controllare se l’indirizzo MAC di destinazione corrisponde al proprio. In questo caso l’adattatore di rete estrae i dati e li passa al livello superiore.

Rilevamento delle collisioni Ethernet - CSMA/CD Iniziamo con la definizione di due importanti concetti: Il dominio di collisione di una rete è un’area in cui può verificarsi una collisione. Una collisione è la sovrapposizione di due segnali su un canale di trasmissione. Le collisioni si verificano nelle comunicazioni half-duplex, non in quelle full-duplex. Se c’è una collisione, i due computer coinvolti devono interrompere l’invio dei dati e riprovare successivamente a trasmettere. Gli hub e i repeater creano un unico dominio di collisione uno per ciascuna porta. Il dominio di broadcast di una rete è l’insieme degli host che ricevono un messaggio trasmesso in broadcast da uno di essi. Nella tabella seguente si evidenzia come l’impiego nelle LAN di apparati di rete quali hub, switch o router, abbia conseguenze sui domini di collisione e di broadcast presenti nella rete

In questo articolo, Il livello data link del modello ISO/OSI, analizziamo il secondo livello dello stack che si occupa di offrire ai livelli superiori la possibilità di inviare dati senza preoccuparsi dell'hardware di rete e dei problemi di interfacciamento al mezzo fisico

Indice dei contenuti

- Introduzione al livello Data Link - Framing - Controllo errori in trasmissione- Tecniche di rilevazione degli errori- Controllo di parità - Checksum - Controllo a ridondanza ciclica (CRC – Ciclic Redundancy Check) - Tecniche di correzione dell'errore- Combinazione di Vertical redundancy check (VRC) e Longitudinal redundancy check, LRC - Codici di Hamming- Esempio: invio del messaggio D = 1 0 1 1 (D1, D2, D3, D4) - Calcolo dei bit di parità:- P1 (controlla 3, 5, 7): - P2 (controlla 3, 6, 7): - P4 (controlla 5, 6, 7): - Simuliamo un errore: bit n.5 (da 0 a 1) - Ricalcolo delle parità ricevute:- Controllo P1 (1,3,5,7): - Controllo P2 (2,3,6,7): - Controllo P4 (4,5,6,7): - Controllo del flusso- Tecnica PAR (Positive Acknowledgement and Retry)- Funzionamento - Tecnica Sliding Window- Concetti chiave

Introduzione al livello Data Link

Il livello Data Link si occupa di consegnare il contenuto informativo da un punto A a un punto B (comunicazione punto-punto) con A e B nodi della rete fisicamente collegati. In fase di invio riceve il pacchetto dal livello Network, inserisce un header (intestazione) di livello 2 e un trailer (una coda) definendo il FRAME (trama) che sarà poi inviato al livello fisico. In fase di ricezione, riceve i bit dal livello fisico, riconosce inizio e fine FRAME, elimina intestazione e coda del livello fisico e invia il frame al livello Network È il livello che, attraverso i propri protocolli, garantisce: - Framing: formattazione dei bit - Controllo del flusso: per la sincronizzazione tra mittente e ricevente - Rilevazione errori in fase di trasmissione Ed, inoltre, definisce precise regole di comunicazione tra i due nodi. La comunicazione avvene attraverso 3 fasi: - Apertura: i nodi A e B attraverso l'handshake iniziale si mettono d'accordo su come sincronizzare la comunicazione - Mantenimento: fase di comunicazione regolata dal controllo del flusso - Chiusura: fine della comunicazione

Framing

Il framing consiste nella definizione della struttura del flusso di bit in frame (trame). Ogni frame è costituito da: - Header: contenente tra le altre informazioni gli indirizzi fisici del mittente e del destinatario ed un campo di controllo. - Payload: campo informativo - Trailer: bit ridondanti utili alla rilevazione di errori in fase di trasmissione

Esistono diverse tecniche che consentono di delimitare una trama ma le più comunemente utilizzate sono: - character stuffing: questa tecnica si usa nella trasmissione orientata al byte (la trama mantiene la suddivisione in byte). Il frame viene preceduto dalla sequenza di caratteri ASCII DLE STX (Data Link Escape Start of TeXt) e finisce con la sequenza DLE ETX (Data Link Escape End of TeXt). Se un frame si rovina e la destinazione perde la sincronizzazione basta trovare il successivo DLE STX o DLE ETX. Il carattere DLE però può comparire casualmente dentro al frame; perché questi caratteri non interferiscano viene aggiunto un ulteriore DLE (che viene rimosso a destinazione prima di passare al frame al livello di rete) in modo che solo i DLE singoli vengano interpretati come delimitatori; questa tecnica si chiama character stuffing - bit stuffing: ogni frame inizia e finisce con la sequenza 01111110 chiamata flag: questa sequenza può comparire casualmente nei dati, perciò in trasmissione dopo cinque 1 consecutivi viene sempre inserito uno 0 nel flusso di bit, indipendentemente dal fatto che il bit successivo sia 1 o 0, mentre in ricezione bisogna provvedere ad eliminare i bit inseriti, rimuovendo sempre uno 0 dopo cinque 1; questa tecnica è chiamata bit stuffing

Controllo errori in trasmissione

Per la gestione degli errori in fase di trasmissione si utilizzano dei bit di ridondanza che vengono aggiunti al trailer. Esistono diverse tecniche in base alle quali è possibile solo rilevare gli errori in fase di trasmissione senza correggerli ed altre tecniche che consentono sia la rilevazione che la correzione degli errori Tecniche di rilevazione degli errori Controllo di parità Prevede l'aggiunta di un bit ridondante ai dati, calcolato a seconda che il numero di bit che valgono 1 sia pari o dispari. I bit di parità è uno dei codici di rilevazione più semplici. Ci sono due varianti del bit di parità: - bit di parità pari (EVEN): si pone tale bit uguale a 1 se il numero di "1" in un certo insieme di bit è dispari (facendo diventare il numero totale di "1", incluso il bit di parità, pari). - bit di parità dispari (ODD): si pone tale bit uguale a 1 se il numero di "1" in un certo insieme di bit è pari (facendo diventare il numero totale di "1", incluso il bit di parità, dispari) Esempio: il valore della parità calcolato da B corrisponde con il valore del bit di parità aspettato -> nessun errore

Esempio: Il valore della parità calcolato da B (1) non è in accordo con il bit (0) che ha ricevuto --> errore in fase di trasmissione

Il bit di parità garantisce di rilevare solo un numero dispari di errori. Se avviene un numero pari di errori, non funziona. Si consideri il seguente esempio con un numero di errori pari:

B osserva una parità pari, come aspettato, e quindi fallisce nel cercare due errori Per la sua semplicità, la parità è usata in molti dispositivi hardware dove le operazioni possono essere ripetute in caso di difficoltà, o se è solo utile sapere che è avvenuto un errore. Per esempio i bus SCSI e PCI usano la parità per trovare errori di trasmissione, inoltre molte cache di microprocessori includono tale sistema di protezione. In definitiva la tecnica è usata per trasmissioni seriali asincrone a bassa velocità e a breve distanza. Checksum Consiste nel sommare il valore binario corrispondente alla codifica ASCII dei caratteri, modulo 256. Lato mittente viene fatto il complemento bit a bit della somma di tutti i caratteri del frame; se c’è un riporto finale, questo è sommato al bit meno significativo. Il risultato è posto nel campo di controllo apposito (se il campo è a 16 bit si sommano parole di 16 bit).

Controllo a ridondanza ciclica (CRC – Ciclic Redundancy Check) Il CRC prevede la generazione di una stringa di bit di controllo che viene normalmente trasmessa assieme ai dati e il calcolo è basato sull'aritmetica modulare. Un codice CRC è definito dal suo polinomio generatore: ad esempio il codice CRC-16-CCITT, molto usato in ambito di telecomunicazioni, è definito dal polinomio generatore x 16 + x 12 + x 5 + 1 . Il calcolo del CRC inizia con il messaggio che viene associato a un polinomio b(x) di grado pari al numero di bit del messaggio meno uno, grado che indicheremo con (n −1) Per esempio, il messaggio 10011010 ( n − 1 = 7 ) produce il polinomio b (x) = x 7 + x 4 + x 3 + x 1 poichè i bit a 1 corrispondono ai coefficienti del polinomio b(x) L'algoritmo prevede di: - convertire il polinomio generatore in sequenza di bit - aggiungere in coda al messaggio da trasmettere tanti zeri corrispondenti al grado del polinomio generatore - eseguire la divisione XOR tra il nuovo messaggio e la sequenza relativa al polinomio generatore - il resto della divisione rappresenta il CRC e va accodato al messaggio originario che verrà poi trasmesso

Il ricevente può effettuare il controllo in due modi: il primo consiste nel dividere tutto il messaggio ricevuto, compreso il resto della divisione, per il polinomio generatore: se il resto della divisione è 0, allora il messaggio è corretto. Il secondo modo consiste nell’eliminare il resto della divisione dai dati ricevuti e dividerlo per il polinomio generatore: se il resto ottenuto è uguale a quello tolto dai dati ricevuti, allora il messaggio è corretto Tecniche di correzione dell'errore Combinazione di Vertical redundancy check (VRC) e Longitudinal redundancy check, LRC Il controllo di ridondanza longitudinale o controllo di ridondanza orizzontale (HRC) è una forma di controllo di ridondanza che si applica indipendentemente a ciascuno dei gruppi paralleli di bit di un flusso dati. I dati devono essere divisi in blocchi di trasmissione, ai quali il blocco di controllo addizionale viene accodato In un sistema con controllo bidimensionale di parità (combinazione di VRC e LRC), il messaggio trasmesso comprende: - I bit di dati (organizzati in una matrice: righe × colonne), - I bit di parità per ogni riga (VRC), - I bit di parità per ogni colonna (LRC), che costituiscono una riga aggiuntiva. In sostanza, si trasmette una matrice estesa, in cui: Alla fine delle righe si aggiunge una riga di parità LRC, che ha i bit di parità di colonna e il bit di parità finale di se stesso. Ogni riga di dati ha un bit di parità finale. Supponiamo di voler trasmettere i seguenti 4 nibble: 1011 0100 1101 0011 Il messaggio vene riorganizzato in una matrice 4 x 4 in cui i 4 nibble sono le righe: Righe → / Colonne ↓Bit1Bit2Bit3Bit4R11011R20100R31101R40011 A questo punto si calcolano i bit di parità pari per ogni riga aggiungendo i bit di VRC: Righe / ColonneB1B2B3B4Parità rigaR110111R201001R311011R400110 Ora si calcolano i bit di parità di ogni colonna aggiungendo la quinta riga LRC: Righe / ColonneB1B2B3B4Parità rigaR110111R201001R311011R400110LRC00011 Il messaggio trasmesso sarà: 10111 01001 11011 00110 00011 In fase di ricezione supponendo un errore in trasmissione sul bit 2 della riga 2 (da 1 a 0) il ricevente vedrà: 10111 00001 11011 00110 00011. Strutturerà la matrice per righe: Righe / ColonneB1B2B3B4Parità rigaR110111R200001R311011R400110LRC00011 e calcolerà i bit di parità di riga che saranno: 10101 e i bit di parità di colonna 01011. Li confronterà con i bit di parità ricevuti e capirà che nella posizione (2,2) c'è stato un errore per cui modificherà il valore di quel bit Codici di Hamming È un codice lineare che aggiunge dei bit di parità ai dati, calcolati in modo tale da poter determinare esattamente la posizione del bit errato in caso di errore singolo. La tecnica prevede di calcolare e posizionare i bit di ridondanza nelle posizioni che corrispondono alle potenze del 2. Dato il messaggio da trasmettere costituito da m bit, la tecnica prevede di calcolare i k bit di ridondanza in modo da inviare un messaggio n di lunghezza m+k che è chiamato codeword. il numero k di bit di ridondanza si ottiene per tentativi risolvendo la disequazione: 2k - 1 >= m+k. Se ad esempio m=4 -> k = 3 Il codice di Hamming standard è noto come (7,4): - 4 bit di dati - 3 bit di parità - Totale: 7 bit trasmessi Nei 7 bit, i bit di parità sono posizionati nelle posizioni che sono potenze di 2: (1, 2, 4) Ecco la struttura del codice Hamming (7,4): Posizione1234567TipoP1P2D1P4D2D3D4 Esempio: invio del messaggio D = 1 0 1 1 (D1, D2, D3, D4) Posizioniamo i bit: Posizione1234567Contenuto??1?011 Vediamo quali bit sono controllati dai bit di ridondanza PosizioneCodificaControllo10013,5,720103,6,73011-41005,6,75101-6110-7111- Quindi: - P1 controlla: 3, 5, 7 - P2 controlla: 3, 6, 7 - P4 controlla: 5, 6, 7 Calcolo dei bit di parità: P1 (controlla 3, 5, 7): → XOR di 1 (pos 3), 0 (pos 5), 1 (pos 7): 1 ⊕ 0 ⊕ 1 = 0 -> quindi il bit in posizione 1 avrà valore 0 P2 (controlla 3, 6, 7): → XOR di 1 (pos 3), 1 (pos 6), 1 (pos 7): 1 ⊕ 1 ⊕ 1 = 1 -> quindi il bit in posizione 2 avrà valore 1 P4 (controlla 5, 6, 7): → XOR di 0 (pos 5), 1 (pos 6), 1 (pos 7): 0 ⊕ 1 ⊕ 1 = 0 -> quindi il bit in posizione 4 avrà valore 0 Messaggio trasmesso: Posizione1234567Contenuto0110011 Messaggio Trasmesso: 0110011 Simuliamo un errore: bit n.5 (da 0 a 1) Messaggio Ricevuto: 0110111 Ricalcolo delle parità ricevute: Controllo P1 (1,3,5,7): 1 (3) ⊕ 1 (5) ⊕ 1 (7) = 1 ⊕ 1 = 0, 0 ⊕ 1 = 1 → Parità non corretta → P1 = 1 Controllo P2 (2,3,6,7): 1 (2) ⊕ 1 (3) ⊕ 1 (6) ⊕ 1 (7) = 1 ⊕ 1 = 0, 0 ⊕ 1 = 1, 1 ⊕ 1 = 0 → Parità corretta → P2 = 0 Controllo P4 (4,5,6,7): 0 (4) ⊕ 1 (5) ⊕ 1 (6) ⊕ 1 (7) = 0 ⊕ 1 = 1, 1 ⊕ 1 = 0, 0 ⊕ 1 = 1 → Parità corretta → P4 = 1 Rileggendo le parità nell'ordine inverso (P4,P2,P1) -> 101 -> convertito in decimale da 5 -> errore in posizione 5

Controllo del flusso

Il controllo del flusso consiste nella regolazione delle velocità del flusso dei dati dal trasmettitore al ricevitore. È utilizzato dalla stazione ricevente per in- formare la sorgente del suo stato ed evitare di essere sommersa dalle trame che le arrivano. Il ricevitore, con un meccanismo di retroazione, è in grado di regolare il flusso dei dati, assicurando che il ritmo con cui il trasmettitore inoltra le trame sul ca- nale non ecceda quello con cui il ricevitore può riceverle ed elaborarle, evitando di mandare in overflow il buffer del ricevitore con la conseguente perdita di dati. È realizzato con due tecniche: - ARQ – Automatic Repeat-reQuest, il trasmettitore deve attendere la conferma di una trama prima di inviare la successiva; - finestra scorrevole (sliding window), in cui il ricevitore dà il permesso al trasmettitore di inviare dati fino al raggiungimento della capacità massima del buffer di memoria. La prima tecnica viene utilizzata nei protocolli di livello accesso alla rete dello stack TCP/IP (protocollo HDLC e protocollo PPP) La seconda tecnica viene utilizzata nel protocollo LLC di IEEE 802 (che studieremo in seguito) definito a livello accesso alla rete dello stack TCP/IP, nel protocollo HDLC e nel protocollo TCP (che studieremo in seguito) definito a livello trasporto dello stack TCP/IP Tecnica PAR (Positive Acknowledgement and Retry) E' una tecnica basata su ARQ. Garantisce che ogni frame inviato sia stato ricevuto correttamente. Se il mittente non riceve conferma (acknowledgement), ritrasmette il frame. Funzionamento Il processo si ripete finché il frame non viene confermato. Il mittente invia un frame al destinatario. Il destinatario verifica l’integrità del frame (ad es. tramite CRC). Se il frame è corretto, invia un acknowledgement (ACK). Se ha riscontrato errori invia un Not Acknoledgement (NACK) per esempio se al messaggio originario si e' sovrapposto rumore elettromagnetico modificando il valore di qualche bit. Se il mittente non riceve l’ACK entro un certo timeout, ritrasmette il frame.

In questo articolo, Il cablaggio strutturato, descriviamo le norme che regolamentano le modalità con cui vengono realizzate le interconnessioni fisiche tra dispositivi, o nodi, nella rete

Indice dei contenuti

- Introduzione - Le componenti del cablaggio strutturato - Standard per il cablaggio strutturato - Certificazione di un sistema di cablaggio strutturato

Introduzione

La realizzazione degli impianti che permettono la comunicazione dei dati prende il nome di cablaggio. Per cablaggio si intende l'insieme dei componenti passivi che vengono posati ed installati per poter fornire in modo capillare dei punti di connessione per apparati attivi che realizzano i sistemi di comunicazione. Per cablaggio strutturato si intende un sistema standardizzato di cablaggio che fornisce le norme per un corretto cablaggio degli edifici, al fine di supportare i sistemi di comunicazione all'interno di un generico comprensorio privato detto campus (insieme di edifici (building) ciascuno dei quali può avere un certo numero di piani (floor) collocati su suolo privato in cui sono presenti un certo numero di reti locali interconnesse localmente e con l'esterno).

Le componenti del cablaggio strutturato

I componenti passivi che realizzano un sistema di cablaggio strutturato sono: - CAVI a seconda dei casi si possono avere cavi in fibra ottica multimodale o monomodale o cavi a coppie simmetriche (twisted pair); i cavi si suddividono in cavi da esteno (outdoor), cavi da interno (indoor) e cavi universali - SISTEMI DI PERMUTAZIONE Sono costituiti da pannelli di permutazione (patch panel) e permutatori (cross connect) ; consentono di interconnettere in modo flessibile fibre ottiche e cavi a coppie per realizzare le interconnessioni desiderate tra gli apparati attivi. Un patch panel presenta un certo numero di porte a cui sono attestate le linee entranti e uscenti che vengono connesse in modo semi permanente (modificabile) tramite opportuni cavetti di permutazzione (patch cord) o bretelle - PRESE UTENTE sette anche Telecommunication outlet (TO). Di norma si forniscono almeno due TO per area di lavoro (working area WA). Le prese utente e i patch panel sono dotati di connettori RJ45 per i cavi in rame e connettori SC, LC, ST per le fibre ottiche. Si chiama patch cable o working area cable WAC il cavo con cui si interconnettono le stazioni di lavoro alle prese utente mentre il cavo che interconnette il permutatore ad un apparato di rete (switch) viene detto Equipment cable (EC) patch panel

Standard per il cablaggio strutturato

Sono definiti dalle norme ISO/IEC 11801 (standard internazionale), EN 50173 (standard europeo), TIA/EIA 568A-568B (standard statunitense). Tutti gli standard, seppur con minime differenze soprattutto nella nomenclatura dei sottosistemi, definiscono i mezzi trasmissivi da utilizzare, la topologia, le distanze massime supportate, i tipi di connettori, le norme per l'installazione e per il collaudo. Nel cablaggio strutturato si adotta la topologia a stella come indicato nell'immagine seguente:

tutti gli standard definiscono 3 sottoinsiemi: SottosistemaCaratteristiche principaliEsempio praticoCampus Backbone- Connette edifici diversi all'interno di un campus - Alta velocità e larghezza di banda - Utilizzo di fibra ottica - Topologia a stella o mesh - il centro stella viene detto Campus Distributor (CD) o Main Cross Connect (MC)Connessione in fibra tra l’edificio amministrativo e la biblioteca universitariaVertical Cabling (cablaggio a distribuzione verticale)- Connette i diversi piani di un edificio - Spesso chiamato anche Backbone Building - Usa fibra ottica o cavi in rame - Include canaline e montanti - il centro stella viene detto Building Distributor (BD) o Intermediate Cross Connect (IC). Da esso si dipartono i cavi per i diversi piani su ciascuno dei quali è presente un armadio di distribuzione detto Floor Distributor (FD)Collegamento tra il rack del piano terra e il rack del terzo piano di un’aziendaHorizontal Cabling (cablaggio a distribuzione orizzontale)- Connette le postazioni di lavoro ai closet di piano (telecom room) - Lunghezza max: 90 metri (più 10 metri di patch cord) - Usa cavi UTP, FTP, STP o fibra - il centro stella viene detto Floor Distributor (FD) o Horizontal Cross Connect (HC). Da esso si dipartono i cavi fino alle prese utenteCollegamento tra una presa a muro in ufficio e il pannello di permutazione nel rack del piano

I CD e i BD sono collocati in appositi locali tecnicie armadi di distribuzione. Essi consentono di collegare in modo semipermanente le linee attestate sui due lati del permutatore. Allo stesso modo i FD consentono di collegare le linee della dorsale con quelle che portano alle TO

Certificazione di un sistema di cablaggio strutturato

Per essere certificato un sistema deve essere sottoposto ad una serie di test che valutano i parametri tipici con cui si esprime la qualità dei collegamenti. Alcuni di questi parametri sono: - Parametri elettrici generali (parametri che caratterizzano il grado di bilanciamento delle coppie, velocità di propagazione, differenza di ritardo tra le coppie, impedenza di trasferimento e wire map (corretta intestazione di un cavo)) - Parametri trasmissivi generali Attenuazione, banda passante - Parametri di diafonia tra le coppie di un cavo attenuazione di paradiafonia (NEXT near end cross talk), rapporto S/N , rapporto di potenza del segnale utile ecc. Nel contesto della certificazione vengono definiti: - permanent link: collegamento non rimovibile da TO fino al primo patch panel del cablaggio orizzontale (max 90m) - channel link: collegamento completo che va dalla stazione di lavoro fino allo switch. Comprende quindi patch cable lato utente (WAC, max 5m) e Equipment cord (max 5m)

In questa guida, Guida alla creazione e al test di API REST con PHP, vedremo come creare Api Rest con PHP e come testare il nostro servizio WEB con i metodi CRUD

Indice dei contenuti

- Introduzione- I Web Services REST - Principi di un Web Service REST: - Il progetto - Creazione del database - Realizzazione del progetto con metodo procedurale- connessione.php- Perché usare echo json_encode(...): - header.php - rubrica.php - Case : 'GET' - Case 'POST' - Case 'PUT' - Case 'DELETE' - Realizzazione del progetto con metodo OOP- connessione.php - rubrica.php - Test dei Metodi CRUD con Postman o Thunder Client- Lettura (GET, Read) - Creazione (POST, Create) - Aggiornamento (PUT/PATCH, Update) - Eliminazione (DELETE) - Postman

Introduzione

I Web Services REST I Web Services REST (Representational State Transfer) sono un’architettura software per sistemi distribuiti. Permettono la comunicazione tra client e server tramite il protocollo HTTP, utilizzando i metodi standard: - GET: recupera dati - POST: inserisce dati - PUT: aggiorna dati - DELETE: elimina dati Un servizio REST è spesso impiegato per fornire un’interfaccia API, che espone operazioni su dati rappresentati in formato JSON. Principi di un Web Service REST: Separazione Client/Server. Stateless: ogni richiesta è indipendente. Accessibilità: accessibile via URL. Formato dei dati: solitamente JSON o XML. Il progetto Ci proponiamo di realizzare un servizio WEB con API REST in PHP che consenta di ineragire con le risorse memorizzate in una tabella di un database attraverso le operazioni CRUD. Si tratta di una rubrica per cui saremo in grado di leggere i record, inserire nuovi utenti, modificare i dati degli utenti e cancellare gli utenti.

Creazione del database

Apriamo l'interfaccia PHPMyAdmin cliccando sul tasto "Admin" in corrispondenza di MySQL nel pannello di XAMPP e creiamo il database"rubrica" con la tabella "utenti" CopyCREATE DATABASE rubrica; USE rubrica; CREATE TABLE utenti( id INT AUTO_INCREMENT PRIMARY KEY, cognome VARCHAR(50) NOT NULL, nome VARCHAR(50) NOT NULL, email VARCHAR(100), via VARCHAR(100), citta VARCHAR(50), provincia VARCHAR(2), cap VARCHAR(10), telefono VARCHAR(20), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); popoliamo la tabella utenti: CopyINSERT INTO utenti (cognome, nome, email, via, citta, provincia, cap, telefono) VALUES ('Rossi', 'Mario', '[email protected]', 'Via Roma 12', 'Milano', 'MI', '20121', '3201234567'), ('Verdi', 'Luca', '[email protected]', 'Via Torino 45', 'Torino', 'TO', '10121', '3339876543'), ('Bianchi', 'Giulia', '[email protected]', 'Viale Italia 8', 'Firenze', 'FI', '50100', '3471112233'), ('Russo', 'Anna', '[email protected]', 'Corso Venezia 5', 'Napoli', 'NA', '80100', '3894455667'), ('Gallo', 'Stefano', '[email protected]', 'Via Garibaldi 22', 'Genova', 'GE', '16100', '3925544332'), ('Ferrari', 'Elena', '[email protected]', 'Via Dante 14', 'Bologna', 'BO', '40121', '3406677889'), ('Marino', 'Francesca', '[email protected]', 'Via Mazzini 3', 'Roma', 'RM', '00100', '3289988776'), ('Conti', 'Paolo', '[email protected]', 'Via Manzoni 9', 'Palermo', 'PA', '90100', '3367766554'), ('De Luca', 'Alessandro', '[email protected]', 'Via Foscolo 1', 'Bari', 'BA', '70121', '3481122334'), ('Ricci', 'Laura', '[email protected]', 'Via Verdi 18', 'Venezia', 'VE', '30100', '3514433221'); Realizziamo ora il progetto utilizzando due diversi metodi: procedurale e OOP. Iniziamo con il metodo procedurale

Realizzazione del progetto con metodo procedurale

Svolgimento della Simulazione Tema d'esame CASA EDITRICE seconda prova di Informatica per l’indirizzo informatico degli Istituti Tecnici Industriali - Testo - Soluzione- Analisi della realtà di riferimento - Creazione delle tabelle - Realizzazione delle pagine per il sistema informativo della casa editrice - Test dell' applicazione

Testo

Una casa editrice desidera archiviare in un database le informazioni riguardanti gli abbonamenti alle riviste ed ai giornali pubblicati tra il 1995 ed il 2006. Per ogni abbonato si richiede di memorizzare i dati anagrafici, per ogni abbonamento la data ed il periodo di validità (trimestrale, semestrale, annuale). Bisogna considerare che gli abbonati possono avere abbonamenti anche per più pubblicazioni. Per ogni giornale o rivista occorre archiviare il titolo, la periodicità (quotidiano, settimanale, mensile, il prezzo dell’abbonamento e gli argomenti trattati. Inoltre deve essere mantenuto un indice con i titoli dei principali articoli pubblicati ed a ciascun articolo deve essere associata la pubblicazione in cui è comparso. Dopo aver realizzato lo schema concettuale, logico e fisico della base di dati si realizzino: - una pagina index.php contenente un form di login (username e password) ed un link a registrazione.php -  una pagina registrazione.php -  una pagina landing_page.php L'utente accede a index.php. Se è già registrato effettua il login ed accede a landing_page.php. Se non è registrato effettua la registrazione e, se questa è andata a buon fine, viene reindirizzato a login.php Nella landing_page (completa di CSS) inserire una barra laterale contenente 8 pulsanti corrispondenti alle seguenti 8 query: - Q1: Dato il titolo di una pubblicazione, ricercare gli articoli pubblicati in un determinato anno; - Q2: Dato il titolo di una pubblicazione, ricercare gli abbonati annuali; - Q3: Dato il nominativo di un abbonato, stabilire a quante riviste è abbonato; - Q4: Dato un argomento, elencare le pubblicazioni in cui è trattato; - Q5: Riportare per ogni pubblicazione il numero di abbonamenti; - Q6: Visualizzare i giornali con almeno 5000 abbonati annuali; - Q7: Dati i titoli di due pubblicazioni, visualizzarne gli abbonati comuni; - Q8: Dato il titolo di una pubblicazione, elencare le pubblicazioni che trattano i suoi stessi argomenti La pressione di un pulsante deve consentire la visualizzazione del risultato della query. Fare attenzione ai casi in cui si richiede un form prima di visualizzare i risultati. La landing_page deve avere un pulsante "Logout" che reindirizza alla pagina di login.php

Soluzione

Svolgimento del Tema d'esame CONSORZIO DI UN FORMAGGIO TIPICO assegnato alla seconda prova di Informatica per l’indirizzo informatico degli Istituti Tecnici Industriali nel 2015 - Testo - Soluzione- Analisi della realtà di riferimento - Creazione delle tabelle - Realizzazione delle pagine per il sistema informativo del consorzio - Test dell' applicazione

Testo

Il Consorzio di un Formaggio Tipico riunisce più di 400 produttori, sparsi nella zona di produzione. Il Consiglio del Consorzio decide di operare un forte rinnovamento tecnologico al duplice scopo di monitorare al meglio la raccolta di latte e la produzione del formaggio, nonché avere un sito di riferimento che permetta al pubblico di cercare, identificare e 'visitare' virtualmente i vari caseifici. A tale scopo intende realizzare un sistema informativo automatizzato che, per ogni caseificio, raccolga giornalmente i dati relativi alla quantità di latte lavorata, a quella impiegata nella produzione di formaggio, alla quantità di forme prodotte e al numero di quelle vendute. Per ciascuna forma venduta interessa conoscere la stagionatura raggiunta (12, 24, 30 o 36 mesi), nome e tipo dell’acquirente (grande distribuzione, grossisti, ecc.) e se è di prima o di seconda scelta (forma con difetti di produzione). Tali informazioni vengono inserite direttamente dai caseifici a fine giornata, mediante accesso ad un’area riservata dell’interfaccia Web del sito del consorzio. Ciascun caseificio ha un codice numerico di 4 cifre col quale vengono marchiate le forme, sulle quali viene anche apposta la data di produzione (mese ed anno) ed il numero progressivo all’interno del mese.(immagini) Il Consorzio è anche interessato a registrare le informazioni relative ai luoghi di produzione, a partire dal nome, indirizzo, dati di geolocalizzazione, nome del titolare, ed una serie di fotografie del caseificio per realizzare un “tour virtuale” . Il candidato, fatte le opportune ipotesi aggiuntive, sviluppi - un’analisi della realtà di riferimento individuando le possibili soluzioni e scelga quella che a suo motivato giudizio è la più idonea a rispondere alle specifiche indicate - lo schema concettuale della base di dati - lo schema logico della base di dati - la definizione in linguaggio SQL di un sottoinsieme delle relazioni della base di dati in cui siano presenti alcune di quelle che contengono vincoli di integrità referenziale e/o vincoli di dominio, laddove presenti. - le seguenti interrogazioni espresse in linguaggio SQL: a) Visualizzare il numero di forme prodotte da ciascun caseificio tra due date fornite b) Visualizzare la media del latte lavorato giornalmente nell’anno corrente dai caseifici provincia per provincia c) Visualizzare i dati del caseificio che ha venduto il maggior numero di forme di prima scelta in un anno impostato dall’utente d) Visualizzare l’elenco dei caseifici che, in un certo periodo individuato da due date fornite dall’utente, hanno venduto meno di 10 forme di seconda scelta - il progetto della Home page dell’interfaccia WEB che si intende proporre per la gestione del DataBase e delle gallerie di immagini dei luoghi di produzione. - la codifica in un linguaggio a scelta di un segmento significativo dell'applicazione Web che consente l'interazione con la base di dati.

Soluzione

Analisi della realtà di riferimento Lo scopo di questa guida è quello di realizzare l'interfaccia Web che consente la visualizzazione dei dati e l'interazione con il database realizzando la parte backend in PHP e la parte frontend in HTM-CSS. Nello specifico ci proponiamo di non sviluppare nel dettaglio i punti 1-5 delle richieste ma ci soffermiamo sugli ultimi due punti. Ovviamente per testare la nostra interfaccia Web dovremmo già avere la struttura del database completa con le tabelle popolate e le relative query. Andremo molto velocemente nella definizione di questa prima parte per poi approfondire la seconda parte di codice. Creazione delle tabelle Chiaramente dovremo avere una tabella caseifici(id, nome, indirizzo, citta, provincia, latitudine, longitudine, titolare). Per soddisfare le specifiche, id dovrà essere una stringa alfanumerica di 4 cifre e provincia dovrà essere una stringa di 2 caratteri alfabetici quindi possiamo: - far partire XAMPP - avviare Apache e MySQL - aprire l'interfaccia PHPMyAdmin - nella scheda SQL inseriamo il seguente codice che crea il database "consorzio" e crea la tabella "caseifici": CopyCREATE DATABASE consorzio_formaggi; USE consorzio_formaggi; CREATE TABLE caseificio ( id VARCHAR(4) PRIMARY KEY, -- id è una stringa di 4 caratteri alfanumerici nome VARCHAR(255) NOT NULL, -- nome del caseificio indirizzo VARCHAR(255) NOT NULL, -- indirizzo citta VARCHAR(100) NOT NULL, -- città provincia CHAR(2) NOT NULL, -- provincia è una stringa di 2 caratteri latitudine DECIMAL(9,6), -- latitudine con 6 decimali longitudine DECIMAL(9,6), -- longitudine con 6 decimali titolare VARCHAR(255) NOT NULL -- nome del titolare ); Adesso possiamo popolare la tabella inserendo, ad esempio, 20 record: CopyINSERT INTO caseificio (id, nome, indirizzo, citta, provincia, latitudine, longitudine, titolare) VALUES ('A123', 'Caseificio Bella Vita', 'Via delle Rose 12', 'Milano', 'MI', 45.4642, 9.1900, 'Giovanni Rossi'), ('B234', 'Caseificio La Fattoria', 'Via Roma 45', 'Torino', 'TO', 45.0703, 7.6869, 'Marco Bianchi'), ('C345', 'Caseificio del Sole', 'Via del Mare 8', 'Napoli', 'NA', 40.8522, 14.2681, 'Antonio Verdi'), ('D456', 'Caseificio Latteria 9000', 'Piazza Vittoria 22', 'Bologna', 'BO', 44.4949, 11.3426, 'Lucia Neri'), ('E567', 'Caseificio Fattoria di Montagna', 'Via delle Alpi 3', 'Trento', 'TN', 46.0660, 11.1216, 'Paolo Galli'), ('F678', 'Caseificio Casale dei Sogni', 'Via S. Maria 10', 'Firenze', 'FI', 43.7697, 11.2550, 'Francesca Colombo'), ('G789', 'Caseificio Il Girasole', 'Via del Bosco 18', 'Venezia', 'VE', 45.4408, 12.3155, 'Giuseppe Russo'), ('H890', 'Caseificio Verde Prato', 'Strada Nazionale 27', 'Verona', 'VR', 45.4384, 10.9916, 'Anna Ferri'), ('I901', 'Caseificio La Buona Tavola', 'Via Pio XII 56', 'Pescara', 'PE', 42.4611, 14.2130, 'Giorgio Di Stefano'), ('J012', 'Caseificio Il Cielo', 'Viale Europa 11', 'Perugia', 'PG', 43.1107, 12.3908, 'Claudia Ricci'), ('K123', 'Caseificio Sole di Toscana', 'Via Fiume 30', 'Livorno', 'LI', 43.5480, 10.3106, 'Francesco Rossi'), ('L234', 'Caseificio Monti Azzurri', 'Piazza Grande 14', 'Ancona', 'AN', 43.6158, 13.5185, 'Matteo Gatti'), ('M345', 'Caseificio La Stella', 'Strada della Valle 9', 'Roma', 'RM', 41.9028, 12.4964, 'Valeria Bianchi'), ('N456', 'Caseificio Fattoria Verde', 'Via Tiberina 4', 'Cagliari', 'CA', 39.2238, 9.1217, 'Luigi Amato'), ('O567', 'Caseificio La Riva', 'Via del Porto 7', 'Genova', 'GE', 44.4056, 8.9463, 'Silvia Moretti'), ('P678', 'Caseificio Il Sorriso', 'Corso Italia 19', 'Bari', 'BA', 41.1175, 16.8719, 'Antonio Fiore'), ('Q789', 'Caseificio La Nuova Era', 'Via del Vento 12', 'Reggio Calabria', 'RC', 38.1100, 15.6613, 'Francesco Perri'), ('R890', 'Caseificio Il Campanile', 'Via della Chiesa 3', 'Catania', 'CT', 37.5079, 15.0830, 'Salvatore Licata'), ('S901', 'Caseificio Il Castello', 'Strada Provinciale 8', 'Messina', 'ME', 38.1938, 15.5540, 'Carmela Marino'), ('T012', 'Caseificio La Via Lattea', 'Piazza del Duomo 20', 'Lecce', 'LE', 40.3520, 18.1752, 'Marco Gentile'); Ad ogni caseificio sono associate alcune foto. Dobbiamo creare una tabella foto(id, caseificio_id, path). Ogni record della tabella deve essere ovviamente collegato ad un caseificio quindi avrà la chiave esterna caseificio_id. Inseriremo poi alcune foto in una cartella e, nell'interfaccia, quando un utente sceglie un caseificio visualizzarà i dati e le foto di quel caseificio. Procediamo allora alla creazione della tabella "foto": CopyCREATE TABLE foto ( id INT AUTO_INCREMENT PRIMARY KEY, caseificio_id VARCHAR(4), path VARCHAR(255) NOT NULL, FOREIGN KEY (caseificio_id) REFERENCES caseificio(id) ON DELETE CASCADE ON UPDATE CASCADE ); Come vedremo in seguito il nostro obiettivo è quello di realizzare la home_admin cioè l'interfaccia che consenta di visualizzare le quattro query. In nessuna di esse è richiesta la visualizzazione delle foto dei caseifici per cui non popoliamo questa tabella. Si lascerà il completamento e la soluzione completa all'utente che avrà cura di inserire le foto in una directory all'interno del progetto strutturandola in questo modo:

In questa "Guida alla creazione dell'ambiente di lavoro per applicazioni con SOCKET in JAVA" vediamo come preparare l'ambiente di lavoro per realizzare e testare le nostre applicazioni. Come si installa Visual Studio Code, il Java Developement Kit e come creare le opportune directories

Indice dei contenuti

In questo articolo, Il Formato dati JSON, vediamo come è possibile rappresentare dati con un formato semplice e flessibile: JSON

Indice dei contenuti

- Cos'è JSON - Differenze tra XML e JSON - Formato JSON - Oggetti letterali JSON - Tipi di dato JSON - A cosa serve JSON? - Creare file JSON - Leggere file JSON - Manipolare dati JSON

Cos'è JSON

JSON (JavaScript Object Notation) è un formato di dati strutturati leggero e ampiamente utilizzato per lo scambio di informazioni tra applicazioni e sistemi. La sua semplicità e flessibilità lo rendono una scelta popolare per diverse attività. La facilità di scrittura e di analisi della notazione JSON ne ha fatto uno dei suoi punti di forza e ne ha diffuso l’utilizzo tra gli sviluppatori.

Differenze tra XML e JSON

Rispetto al formato di dati XML, la dimensione del documento JSON è molto inferiore: infatti JSON è privo di schemi e quindi è necessario “gestire e manovrare” elementi strutturali come spazi dei nomi e involucri. JSON si basa su un sottoinsieme del linguaggio di programmazione JavaScript, Standard ECMA-262 Terza Edizione (1999), ma è un formato indipendente dalla piattaforma e viene utilizzato in più linguaggi di programmazione tra cui Java, Python, PHP, Ruby ecc. Qualsiasi linguaggio in grado di analizzare una stringa può gestire JSON. Douglas Crockford ideò JSON nei primi anni 2000 per lo scambio dei dati tra client e server in una WEB Application. Questo linguaggio è direttamente utilizzabile da uno script JavaScript lato client ma anche da script PHP, ad esempio, lato server e ciò ha contribuito al suo successo Differenze con XML Nei casi molto articolati XML risulta a volte poco comprensibile. La “vista d’insieme del documento” richiede un’accurata analisi in tutta la sua interezza per comprendere l’organizzazione dei dati. Anche JSON è un formato per lo scambio di dati, ma possiede una struttura ancora più semplice di XML, che consente di capire quasi immediatamente il significato di ciò che descrive: questa particolarità è utile specialmente quando si lavora a progetti molto grandi e, soprattutto, quando al progetto collaborano più programmatori che utilizzano linguaggi diversi, da C a Java oppure Perl o Python Sotto possiamo vedere il confronto tra documento XML e oggetto JSON Copy Mark Twain Le avventure di Huckleberry Finn 9.90 Herman Melville Moby Dick 15.10 Copy { "libri": { "libro": } }

Formato JSON

JSON è costituito da due sole strutture: - un insieme di coppie (nome, valore); - una lista ordinata di valori.

Oggetti letterali JSON

Un oggetto letterale può essere definito con un insieme di coppie proprietà/valori separate dalla virgola: l’intero oggetto viene racchiuso tra parentesi graffe

Rispetto a JavaScript sottolineiamo che JSON ammette solo valori semplici e atomici (stringhe, numeri, array, oggetti letterali, true, false, null) e, quindi, non può contenere funzioni

Tipi di dato JSON

Numbers: supporta solo numeri in virgola mobile a doppia precisione Non sono previsti ottale, esadecimale, NaN o infinity. Esempio: var giorni = {marzo:31} String: Sequenza di caratteri UNICODE racchiusi tra virgolette. Ogni carattere è una stringa unitaria. Esempio: var alunno = {nome: "Mario"} Boolean: Valori true o false Esempio: var alunno = {nome: "Mario", promosso: true} Array: Insieme ordinato di valori racchiusi tra parentesi quadre e separati da virgole. Indicizzazione inizio=0 oppure inizio=1 Esempio:

Object: Insieme non ordinato di valori racchiusi tra parentesi graffe. Ogni nome è seguito dai due punti e le coppie nome/valore sono separate da virgole. Esempio:

Whitespace: Inseribile per migliorare la leggibilità. Esempio: var x = " ascissa" null: Inizializzazione variabili Esempio: var x = null

A cosa serve JSON?

La sua semplicità e flessibilità lo rendono una scelta popolare per diverse attività, tra cui: - Scambio di dati nella comunicazione client/server nel WEB: JSON è spesso utilizzato per formattare le richieste e le risposte tra server e client nel WEB. - Archiviazione di dati: JSON può essere utilizzato per archiviare dati strutturati in file, come configurazioni di applicazioni o informazioni utente. - Trasmissione di dati tra linguaggi di programmazione: JSON è un formato indipendente dal linguaggio, il che lo rende ideale per lo scambio di dati tra applicazioni scritte in linguaggi diversi.

Creare file JSON

La creazione di file JSON è relativamente semplice e può essere effettuata utilizzando un editor di testo semplice. La sintassi è chiara e intuitiva, rendendola facile da leggere e scrivere anche per i principianti. Esistono anche diverse librerie e strumenti disponibili per i linguaggi di programmazione più diffusi che semplificano la creazione e la manipolazione di dati JSON.

Leggere file JSON

La lettura di file JSON è altrettanto semplice quanto la loro creazione. I dati JSON possono essere letti da file o stringhe utilizzando librerie o strumenti specifici per il linguaggio di programmazione utilizzato. Una volta letti, i dati JSON possono essere facilmente manipolati e utilizzati all’interno dell’applicazione.

Manipolare dati JSON

In questo articolo, API e WEB Services impariamo a conoscere cosa sono le Application Programming Interfaces e i WEB Service. Dopo aver imparato i concetti fondamentali possiamo fare riferimento alla guida PHP all'interno della quale troviamo una sezione per implementare un WEB Service in PHP e come testarlo

Indice dei contenuti

- Introduzione- Il Web come piattaforma applicativa distribuita - Le sfide dell’integrazione - Architetture distribuite e l’avvento dei Web Services - Web Services: Una nuova frontiera - Capitolo 1: Le API - Il Cuore dell'Interoperabilità- Cosa sono le API? - Struttura di un'API - Tipologie di API - Come funzionano? - L'importanza delle API nel Web moderno - Capitolo 2: I Web Service - Fondamenti e Implicazioni- La definizione di W3C - Cosa sono i Web Service e a cosa servono? - L'integrazione tra API e Web Services - Il "Web" nei Web Services: una piattaforma M2M - Dalle RPC ai Web Services: un'evoluzione - Capitolo 3: Modelli per Web Service - SOAP e REST- SOAP: Un approccio evolutivo alla comunicazione tra sistemi- Caratteristiche chiave di SOA - Attori nell'architettura SOA - Le fasi del ciclo di vita di un Web Service SOAP - Comunicazione SOAP: Un processo dettagliato - La pila protocollare SOAP - REST: Un approccio leggero e flessibile per i Web Service- Differenze tra REST e SOAP - Caratteristiche dell’architettura REST - Esempi di URI REST - I vantaggi di REST rispetto a SOAP - Le operazioni CRUD e i metodi HTTP - RESTful API - Conclusioni

Introduzione

Il Web è emerso come una delle più grandi piattaforme per la condivisione di documenti in formato ipertestuale, interconnessi mediante parole chiave. Questa condivisione avviene indipendentemente dalla piattaforma hardware o software utilizzata. Col tempo, il Web ha subito una continua evoluzione, grazie anche alla standardizzazione di concetti fondamentali come: - URI (Uniform Resource Identifier): Un meccanismo per individuare risorse in rete. - HTTP (Hypertext Transfer Protocol): Un protocollo semplice e leggero per la comunicazione tra client e server. - HTML (HyperText Markup Language): Un linguaggio per la rappresentazione e formattazione dei contenuti. Nel 1994, la necessità di definire regole comuni ha portato alla creazione del World Wide Web Consortium (W3C). Questo organismo ha rivestito un ruolo cruciale nello sviluppo del Web, proponendo standard noti come W3C Recommendations, basati sulle necessità delle organizzazioni e delle aziende. Il Web come piattaforma applicativa distribuita Dalla semplice condivisione di documenti, il Web si è trasformato in una vera e propria piattaforma applicativa. Ai documenti testuali si sono aggiunti contenuti multimediali e l'interazione tra componenti software è diventata un elemento chiave. L'introduzione di applicazioni interoperabili lato server, come CGI, JSP, PHP e ASP, ha segnato una svolta verso la dinamicità, permettendo alle pagine HTML di evolversi da statiche a dinamiche. Le sfide dell’integrazione Nonostante i progressi, l'evoluzione del Web ha introdotto problemi significativi, tra cui: - Integrazione tra applicazioni sviluppate indipendentemente: Le applicazioni create in diverse parti del mondo spesso non erano progettate per comunicare tra loro. - Integrazione all'interno di una singola azienda: La coesistenza di tecnologie eterogenee ha reso complessa la connessione tra sistemi interni. Il successo del Web ha inoltre portato alla necessità di interazioni più sofisticate tra applicazioni in contesti sempre più vari. Architetture distribuite e l’avvento dei Web Services Con la diffusione delle architetture distribuite negli anni '90, era necessario stabilire regole di interoperabilità. Sono nate quindi soluzioni come: - CORBA (1992): Standard multipiattaforma per linguaggi orientati agli oggetti. - Java RMI (1996): Specifico per l'ecosistema Java. - DCOM (1996): Tecnologia proprietaria di Microsoft. Tuttavia, questi approcci soffrivano di limitazioni legate ai protocolli di comunicazione e alle tecnologie coinvolte. Per superare tali ostacoli, si sono proposte soluzioni basate su RPC (Remote Procedure Call) e XML, che garantivano l'interoperabilità tra piattaforme software/hardware diverse. Web Services: Una nuova frontiera L’introduzione dei Web Services ha rappresentato un passo avanti nella standardizzazione delle tecnologie, consentendo l'interazione trasparente tra applicazioni sviluppate in linguaggi di programmazione differenti e operanti su sistemi eterogenei. In sintesi, un Web Service è un sistema software progettato per supportare l’interazione tra applicazioni, sfruttando le tecnologie e gli standard del Web.

Capitolo 1: Le API - Il Cuore dell'Interoperabilità

Cosa sono le API? Le API, acronimo di Application Programming Interface, rappresentano un insieme di regole e protocolli che consentono a diverse applicazioni software di comunicare tra loro. Immaginiamole come un ponte che collega programmi e sistemi, rendendo possibile lo scambio di informazioni e funzionalità in modo standardizzato. Un'API non è un software completo, ma una porta d'accesso che permette agli sviluppatori di utilizzare funzionalità preesistenti senza doverle programmare da zero. In sostanza, le API facilitano l'integrazione e l'interoperabilità tra componenti software che, altrimenti, non sarebbero in grado di comunicare.

Struttura di un'API Tipicamente, un'API è composta da: - Endpoint: Rappresentano i punti di contatto attraverso cui il client invia richieste al server. - Metodi: Ogni API supporta diversi metodi, come GET, POST, PUT e DELETE, che determinano le azioni da eseguire. - Formati di scambio dati: I dati vengono scambiati utilizzando formati standardizzati come JSON (JavaScript Object Notation) o XML (eXtensible Markup Language). Tipologie di API Le API possono essere classificate in diverse categorie in base al loro utilizzo e alla loro accessibilità: - API Pubbliche (o Aperte): Accessibili a chiunque, spesso utilizzate per promuovere l'integrazione di terze parti e favorire l'innovazione. - API Private: Restrizioni sull'accesso per garantire la sicurezza e l'integrità delle applicazioni interne a un'organizzazione. - API Partner: Progettate per essere condivise tra aziende o organizzazioni con rapporti di collaborazione. - API Composite: Combina più API per creare flussi di lavoro complessi e aumentare l'efficienza. - API WEB: Utilizzano HTTP per la comunicazione nel WEB e sono basate su diversi standard (REST, SOAP,..) - API di libreria: forniscono un insieme di funzioni e procedure per l'utilizzo di codice - API di Sistema Operativo: consentono alle applicazioni di accedere alle funzionalità del sistema operativo Come funzionano? Il processo di utilizzo di un'API segue un modello client-server. Il client invia una richiesta al server attraverso l'endpoint dell'API e riceve una risposta strutturata. Questo meccanismo permette di accedere a servizi e dati senza la necessità di conoscere i dettagli interni del software del server. Un esempio pratico? Le API di Google Maps consentono a siti web e app di incorporare mappe interattive e di sfruttare funzionalità di navigazione senza dover sviluppare una piattaforma cartografica da zero. L'importanza delle API nel Web moderno Nel contesto delle architetture distribuite, le API giocano un ruolo cruciale. Consentono agli sviluppatori di creare applicazioni modulari, migliorando la scalabilità, la manutenibilità e la velocità di sviluppo. Grazie alle API, il Web non è solo un insieme di pagine, ma una rete dinamica di servizi che collaborano per offrire esperienze sempre più personalizzate e coinvolgenti.

Capitolo 2: I Web Service - Fondamenti e Implicazioni

La definizione di W3C

Il World Wide Web Consortium (W3C), fondato nel 1994 da Tim Berners-Lee, è l'organizzazione principale responsabile della standardizzazione del Web. Il suo obiettivo primario è quello di garantire uno sviluppo coerente e interoperabile delle tecnologie Web. Attraverso la definizione di raccomandazioni tecniche, il W3C assicura che le innovazioni siano accessibili e compatibili su scala globale. Cosa sono i Web Service e a cosa servono? Un Web Service è una tecnologia che consente a diverse applicazioni software di comunicare tra loro attraverso Internet. Basati su protocolli standard come HTTP e SOAP, i Web Service permettono l'integrazione tra sistemi e linguaggi di programmazione eterogenei. Il loro scopo principale è quello di facilitare l'interoperabilità, offrendo la possibilità di condividere dati e funzionalità tra applicazioni distribuite. In concreto, i Web Service fungono da "mediatori" che trasmettono richieste e risposte tra componenti software, indipendentemente dalla piattaforma o dal linguaggio utilizzato. L'integrazione tra API e Web Services Le API e i Web Services sono strettamente correlati ma distinti. Mentre un'API definisce un set di regole per la comunicazione tra applicazioni, i Web Services implementano queste regole utilizzando i protocolli e le tecnologie Web. In altre parole, un Web Service può essere considerato un tipo di API progettata per funzionare su Internet. Questo rapporto consente agli sviluppatori di sfruttare il potenziale di entrambi. Le API forniscono il "linguaggio comune" necessario, mentre i Web Services estendono questa capacità al livello delle comunicazioni globali attraverso il Web. Il "Web" nei Web Services: una piattaforma M2M Nonostante il termine "Web", i Web Services non sono rivolti agli utenti finali tramite un'interfaccia utente, come accade con i siti Web. Piuttosto, rappresentano un sistema Machine-to-Machine (M2M). Questo significa che comunicano direttamente con altre applicazioni attraverso protocolli Web standard, come HTTP e XML. Il loro utilizzo è fondamentale per molte applicazioni moderne, dalle integrazioni aziendali alle piattaforme di e-commerce, fino alle tecnologie IoT (Internet of Things). Dalle RPC ai Web Services: un'evoluzione L'origine dei Web Services risale al concetto di Remote Procedure Call (RPC), introdotto per consentire a un programma di eseguire procedure su un server remoto. Con l'uso di formati come XML, le RPC hanno permesso la comunicazione tra sistemi differenti. Tuttavia, le limitazioni delle RPC, legate alla mancanza di standardizzazione universale, hanno aperto la strada ai Web Services. I Web Services hanno superato queste barriere implementando protocolli come SOAP e REST, che garantiscono una maggiore flessibilità e interoperabilità. SOAP, ad esempio, utilizza XML per il formato dei messaggi, mentre REST sfrutta i metodi HTTP per la comunicazione, risultando più leggero e adatto alle esigenze moderne.

Capitolo 3: Modelli per Web Service - SOAP e REST

In questo articolo, Programmazione di rete con i SOCKET, esploreremo i concetti fondamentali della programmazione con i socket, con un focus su tipologie, modelli di comunicazione, e una guida pratica all'implementazione in linguaggi come Java. Partiremo dai principi base per arrivare a una panoramica sugli stream socket e datagram socket, passando per le API storiche come quelle di Berkeley e i paradigmi di programmazione client-server. Inoltre, toccheremo temi come l'identificazione tramite IP e porte logiche, l'uso del multicast e i protocolli più utilizzati come TCP e UDP.

Indice dei contenuti

- Introduzione - Capitolo 1: Introduzione alla Programmazione di Rete e ai Socket- API : una panoramica - Programmazione a Livello Applicativo - Berkeley Socket API e le Alternative - Capitolo 2: definizione di Socket - Capitolo 3: Famiglie di Socket- Stream Socket (SOCK_STREAM)- Ciclo Operativo degli Stream Socket - Ruoli di Server e Client - Comunicazione - Datagram Socket (SOCK_DGRAM)- Caratteristiche Operative - Ciclo di Comunicazione - Conclusioni

Introduzione

La programmazione di rete rappresenta una delle discipline fondamentali dell'informatica moderna, grazie al ruolo cruciale delle comunicazioni tra dispositivi. I socket sono una delle tecnologie principali alla base della programmazione di rete, permettendo la creazione di applicazioni che comunicano attraverso reti LAN e WAN. Dai videogiochi online alla messaggistica istantanea, i socket sono alla base di numerose applicazioni che utilizziamo quotidianamente.

Capitolo 1: Introduzione alla Programmazione di Rete e ai Socket

La programmazione di rete, o Networking Programming, è il processo di sviluppo di applicazioni software che comunicano tra loro utilizzando reti come LAN (Local Area Network) o WAN (Wide Area Network). Questa disciplina consente a dispositivi su computer distinti di scambiare dati in modo efficiente, aprendo le porte a innumerevoli applicazioni, dai sistemi di messaggistica istantanea ai servizi cloud. API : una panoramica I moderni sistemi operativi, come Windows e Linux, forniscono un'Application Programming Interface (API) che si colloca tra i protocolli di trasporto TCP (Transmission Control Protocol) o UDP (User Datagram Protocol) e i livelli superiori della comunicazione (sessione, presentazione e applicazione). Le API offerte da questi sistemi operativi consentono agli sviluppatori di interfacciarsi direttamente con i protocolli di rete. Inizialmente, queste API erano implementate principalmente attraverso funzioni in linguaggio C, ma oggi la maggior parte dei linguaggi di programmazione, come Java o Python, offre librerie e classi che semplificano l'accesso a tali funzionalità. Quando si utilizza direttamente questa interfaccia, la programmazione di rete è definita programmazione a livello di socket. Programmazione a Livello Applicativo Con la diffusione del modello client/server, la programmazione di rete si è orientata anche verso le API applicative che sfruttano protocolli come l'HTTP. Questo approccio, spesso definito programmazione a livello applicativo, semplifica ulteriormente la comunicazione e il trasferimento di dati tra macchine. Berkeley Socket API e le Alternative Le API per la programmazione a livello di socket sono nate nel 1981 presso l'Università di Berkeley, in California, all'interno del progetto Berkeley Software Distribution (BSD), una variante del sistema operativo Unix. Questo modello è diventato noto come Berkeley socket API. Sistemi operativi come Windows e Linux offrono supporto simile: - Windows utilizza una variante chiamata WinSock, molto simile alla Berkeley API. - Linux, invece, implementa direttamente la Berkeley socket API. Entrambe le API adottano il paradigma client/server e supportano due tipi principali di servizio a livello di trasporto: - TCP (affidabile e orientato alla connessione). - UDP (non affidabile e basato su datagrammi).

Capitolo 2: definizione di Socket

Affinchè un processo presente (mittente) su un host possa inviare dati ad un qualsiasi altro host (destinatario) in una rete è necessario che il mittente identifichi il destinatario in modo univoco Ogni PC ha una porta fisica di comunicazione ma necessita di ricevere ed inviare dati attraverso applicazioni diverse. Come facciamo ad identificare un servizio, un'applicazione in modo univoco? Attraverso le Porte logiche di comunicazione. Le porte logiche sono specificate attraverso 2 byte (possiamo avere dunque 65536 porte numerate da 0 a 65535). Ciascuna di queste porte identifica un canale di comunicazione. Le prime 1024 porte si chiamano Well Known Ports. Possono essere usate solo dai Server e riservate a servizi o applicazioni specifiche (HTTP, FTP, SMTP,..) Le porte dalla 1024 alla 49151 si chiamano Registered Ports sono riservate ad alcuni servizi e usate dai client Le ultime porte sono dette Dynamic and/or Private Ports e sono usate dai processi per essere assegnate dinamicamente

L'identificazione di un servizio avviene dunque combinando indirizzo IP e porta logica. La notazione è Il meccanismo di identificazione univoca associato ad un processo in esecuzione su un host attraverso la coppia è chiamato SOCKET Un host che vuole comunicare in rete con un altro host invia il messaggio attraverso il proprio socket (socket del mittente) che rappresenta l'interfaccia verso l'esterno. Occorre poi un "oggetto" che trasferirà il messaggio al destinatario (evidentemente al socket del destinatario) L'oggetto di cui parliamo è il protocollo utilizzato. Pertanto, se attraverso il socket identifichiamo in modo univoco un processo su un host, in che modo identifichiamo in modo univoco ogni singola connessione? Ogni connessione è identificata univocamente da una struttura chiamata ASSOCIATION costituita da una quintupla di elementi: - IP del mittente - numero di porta del mittente - IP del destinatario - numero di porta del destinatario - protocollo utilizzato

Capitolo 3: Famiglie di Socket

Stream Socket (SOCK_STREAM) Gli stream socket (SOCK_STREAM) sono fondamentali per la creazione di connessioni sequenziali e affidabili tra processi su reti. Questo tipo di socket consente una comunicazione full-duplex (bidirezionale simultanea) ed è caratterizzato da: - Connessione sequenziale: i dati vengono trasmessi in ordine, rispettando la sequenza di invio. - Asimmetria: le velocità di trasmissione tra i due estremi possono differire. - Affidabilità: garantisce che i dati arrivino correttamente e senza duplicati. - Stream di byte a lunghezza variabile: i dati vengono gestiti come flussi continui di byte. Operativamente, ogni processo coinvolto nella comunicazione crea un endpoint per lo scambio di dati. Questo processo si realizza invocando la primitiva socket() in C, o creando un oggetto socket in Java. In questa guida, faremo riferimento principalmente alle implementazioni in Java. Ciclo Operativo degli Stream Socket - Lato Server: - Il server si mette in ascolto su una porta specifica (listening socket), in attesa di connessioni. - Quando riceve una richiesta, utilizza la primitiva accept() per generare un nuovo socket dedicato alla connessione con il client. - Lato Client: - Il client si mette in coda sul socket del server. - Una volta accettata la connessione dal server, il client effettua automaticamente il binding alla propria porta locale. Ruoli di Server e Client Il processo server ha un controllo maggiore rispetto al client, in quanto: - È responsabile della creazione iniziale del socket e della gestione delle connessioni multiple. - Può essere associato a un solo socket per porta specifica. Il client, invece, deve conoscere l'indirizzo IP e la porta del server per iniziare una connessione. Il server acquisisce le informazioni del client, inclusi l'IP e la porta, solo al momento della connessione. Comunicazione Dopo l'accettazione della richiesta, il server crea un "canale virtuale" tra il client e un nuovo socket, lasciando il socket principale libero per ulteriori richieste. Durante la comunicazione, i due processi utilizzano: - La funzione read() per leggere i dati. - La funzione write() per scrivere i dati. La comunicazione continua fino a quando uno dei due processi chiude il canale tramite la funzione close(). Datagram Socket (SOCK_DGRAM) I datagram socket (SOCK_DGRAM) permettono di realizzare una comunicazione basata su pacchetti di dati, senza stabilire una connessione diretta tra le parti coinvolte. Questo tipo di socket è particolarmente utile per situazioni in cui la rapidità di invio è preferita all'affidabilità garantita, come nel caso del protocollo UDP (User Datagram Protocol). Il modello supporta una comunicazione di tipo "molti a molti", dove: - Un singolo socket può inviare dati a diverse destinazioni. - Può ricevere dati da più sorgenti. A differenza degli stream socket, i datagram socket non garantiscono: - L'ordine dei pacchetti. - La consegna affidabile dei dati (potrebbero esserci perdite). Caratteristiche Operative Ogni processo che utilizza un datagram socket crea un endpoint richiamando la primitiva che inizializza il socket. Successivamente, il processo può: - Inviare dati a un destinatario specifico. - Ricevere dati da una o più sorgenti, utilizzando le primitive appropriate. Per implementare questa comunicazione, si utilizzano funzioni e primitive disponibili nei linguaggi di programmazione. Ad esempio: - In Java, tramite i metodi send() e receive(). - In C, con le primitive recvfrom() e sendto(). Ciclo di Comunicazione - Lato Server: il server si mette in attesa di dati utilizzando la primitiva receive(). Una volta ricevuti i dati, può elaborare e inviare una risposta tramite la primitiva send(). - Lato Client: il client invia i dati al server utilizzando send() e può attendere una risposta dallo stesso server con receive(). Questa modalità di scambio dati offre una grande flessibilità, in quanto non richiede una connessione continua, ma ha il limite di non garantire né l'ordine né la certezza dell'arrivo dei pacchetti. I datagram socket sono utili in molte applicazioni, come: - Gaming online, dove la velocità è essenziale e la perdita di qualche pacchetto non compromette l'esperienza. - Streaming multimediale, in cui i piccoli ritardi o perdite di dati non influenzano in modo significativo il risultato.

Conclusioni

In questo articolo, Guida XML - Le basi del linguaggio, introdurremo le basi del linguaggio XML. Vedremo le caratteristiche e gli usi del linguaggio stesso - Introduzione all'XML: Comprendere il Meta-Linguaggio di Markup- L'Impatto dell'XML: Una Rivoluzione Silenziosa - Internet, Web e la Necessità degli Standard: La Nascita di XML - La Guerra dei Browser: Sfide e Lotte degli Anni '90 - La Risposta del W3C: La Creazione di XML - L'Evoluzione di XML: Dal Web a Contesti Diversificati - XML: Standard e Struttura al Servizio della Flessibilità - Un Ecosistema Intorno a XML: Tecnologie Correlate - Una Rivoluzione Universale - La Struttura dei Documenti XML- Rappresentare l'Informazione in un Documento XML - Cos'è un File XML? - Struttura Gerarchica - Esempio di Struttura ad albero in XML- Struttura Logica - Struttura Fisica - HTML vs XML: I Tag e la Sintassi- Annidamento e Gerarchia - Elementi Vuoti - Documenti Ben Formati: Regole Fondamentali per XML- Cosa Significa "Ben Formato"? - Esempi di Errori Comuni - Regole per i Nomi dei Tag - Caratteri e Codifica in XML - Entità e Caratteri Speciali - Sezioni CDATA - Documenti Validi: Scrivere e Convalidare Documenti XML con Grammatiche- La Necessità di una Grammatica- Ben Formato vs Valido - Creare Grammatiche per Documenti XML - Tipologie di Parser per Documenti XML - Convalidare Documenti XML con il Codice - Documenti Validi: Scrivere e Convalidare Documenti XML con Grammatiche - La Necessità di una Grammatica- Ben Formato vs Valido - Creare Grammatiche per Documenti XML - Tipologie di Parser per Documenti XML - Convalidare Documenti XML con il Codice - DTD: Definizione e Descrizione delle Grammatiche per Documenti XML- Struttura e Sintassi di un DTD- Dichiarazione degli Elementi- Esempio: - Elementi Vuoti e Contenuto di Testo - Definizione degli Attributi- Altri Tipi di Attributi: - Un Esempio Completo di DTD - Entità, Documenti e Considerazioni su XML- Definizione di Entità Personalizzate nei DTD- Creazione di un'Entità Personalizzata - Collegare un Documento XML al suo DTD - Vantaggi e Limiti dei DTD - XML Schema: Elementi e Struttura- Cos'è un XML Schema? - Le Differenze Principali tra XML Schema e DTD - Struttura Generale di un XML Schema - Definizione degli Elementi in XML Schema - Tipi di Dato: Semplici e Complessi - Vantaggi degli XML Schema - Integrazione di Grammatiche e Namespace- Collegare un Documento XML alla Sua Grammatica di Riferimento - Riferimento allo Schema XML nel Documento - Integrazione di Grammatiche Diverse - Namespace: La Soluzione alle Ambiguità- Esempio di Problema Risolto dai Namespace: - Riferimenti ai Namespace in un Documento XML - Validazione di Documenti con Namespace Multipli- Presentazione di XML con CSS - La Differenza tra HTML e XML nella Presentazione - Utilizzo di CSS con XML- Definire Regole di Stile - Differenze tra CSS per HTML e XML - Riferire un Foglio di Stile a un Documento XML - Limitazioni dell'Utilizzo di CSS con XML - Alternative: L'Introduzione di XSL - XSL: eXtensible Stylesheet Language- Introduzione a XSL - I Tre Componenti di XSL- 1. XPath: Navigare tra Dati XML - 2. XSLT: Trasformare Dati XML - 3. XSL-FO: Gestione Avanzata della Formattazione - Flessibilità di XSL - Combinare XML con XSLT - XPath: Espressioni e Funzioni- Introduzione a XPath - Sintassi Base di XPath- Esempi di Percorsi in XPath - Funzioni Utili in XPath- Posizione e Sequenza - Conteggio - Manipolazione di Stringhe - Manipolazione Numerica - Navigazione Relativa in XPath - Potenza di XPath - Elaborazione dei Documenti XML: I Parser- Cos’è il Parsing di un Documento XML? - Approcci Principali al Parsing in Java: DOM e SAX- 1. SAX (Simple API for XML): Parser Basato su Eventi - 2. DOM (Document Object Model): Parser Basato su Albero - SAX vs DOM: Un Confronto - DOM e la Programmazione Object-Oriented - Quando Usare SAX o DOM?

Introduzione all'XML: Comprendere il Meta-Linguaggio di Markup

Spesso si tende a pensare che l'XML (eXtensible Markup Language) sia semplicemente un altro linguaggio di markup o, peggio, una versione modernizzata dell'intramontabile HTML. Nulla di più lontano dalla verità. XML è un meta-linguaggio di markup, un sistema che consente di creare altri linguaggi di markup personalizzati. A differenza di HTML, che dispone di un set rigido di tag predefiniti per la creazione di pagine web, XML non ha un repertorio di tag standard né è pensato per la programmazione o per la generazione diretta di pagine web. Al contrario, il suo scopo è esclusivamente quello di definire nuovi linguaggi in base alle esigenze specifiche. Ma cosa si cela realmente dietro l'XML? In poche parole, non è altro che un insieme standard di regole sintattiche per organizzare e modellare la struttura dei dati e dei documenti. Queste regole, o meglio, specifiche tecniche, forniscono un framework per sviluppare linguaggi di markup personalizzati. Il World Wide Web Consortium (W3C) è l'organismo ufficiale che definisce tali specifiche, e le relative linee guida sono pubblicamente disponibili all'indirizzo http://www.w3.org/XML. L'Impatto dell'XML: Una Rivoluzione Silenziosa Perché l'XML è così discusso e acclamato nel mondo informatico? Quali possibilità apre questo meta-linguaggio e perché viene considerato una piccola rivoluzione? La risposta risiede nella sua flessibilità e nella capacità di gestire i dati in modo strutturato e interoperabile. Grazie a XML, è possibile definire formati di dati personalizzati che possono essere utilizzati per scambi di informazioni tra sistemi, integrazioni software e molto altro. Nella presente guida esploreremo le risposte a queste domande, offrendo una panoramica sulle tecnologie collegate a XML e il suo ecosistema. Ma prima, iniziamo col capire le motivazioni che hanno portato all'introduzione di questo potente strumento. Internet, Web e la Necessità degli Standard: La Nascita di XML Internet e il Web, per loro natura decentralizzata e aperta, sono progettati per essere accessibili a una vasta gamma di dispositivi e piattaforme. Tuttavia, proprio questa caratteristica richiede standard condivisi che garantiscano usabilità e progresso senza confusione o frammentazioni. Per rispondere a questa esigenza, nel dicembre 1994 nasce il World Wide Web Consortium (W3C), un'organizzazione con l'obiettivo di creare standard riconosciuti dai principali attori del settore, tra cui l'ormai onnipresente linguaggio HTML. La Guerra dei Browser: Sfide e Lotte degli Anni '90 Gli anni '90 segnarono il boom di Internet e l'ascesa esplosiva del Web, ma portarono con sé anche una delle più accese competizioni tecnologiche e commerciali: la guerra dei browser tra Netscape e Microsoft. In questa lotta serrata, ogni versione aggiornata di un browser introduceva estensioni proprietarie all'HTML, sfidando gli standard ufficiali. Le conseguenze furono disastrose: i siti che adottavano estensioni specifiche per un browser rischiavano di risultare incompatibili con altri. La situazione si aggravò ulteriormente con l'arrivo del Dynamic HTML (DHTML), il cui utilizzo variava ampiamente e arbitrariamente tra i diversi produttori di browser. Di fronte a questo scenario caotico, il W3C si trovò a rincorrere una continua evoluzione “de facto” dell'HTML, costretto a decidere quali nuove funzionalità integrare come standard ufficiali e quali invece escludere. La Risposta del W3C: La Creazione di XML In questo contesto emerse la necessità di un linguaggio che offrisse sia libertà nella definizione dei tag, sia un rigoroso rispetto degli standard. Per soddisfare questa esigenza, nel 1996 il W3C istituì l'XML Working Group con l'obiettivo di sviluppare un linguaggio di markup che garantisse compatibilità e flessibilità. La base di partenza della ricerca fu il linguaggio SGML (Standard Generalized Markup Language), un potente meta-linguaggio per la creazione di linguaggi di markup. Tuttavia, l'SGML si rivelò eccessivamente complesso per gli scopi prefissati, motivo per cui venne semplificato e snellito, portando alla nascita di XML. L'Evoluzione di XML: Dal Web a Contesti Diversificati Nel dicembre del 1997, le specifiche dell'XML furono pubblicate come Proposed Recommendation. Sebbene inizialmente concepito per risolvere le problematiche legate agli standard del Web, si scoprì rapidamente che il potenziale di XML andava ben oltre. Grazie alla sua versatilità, l'XML si adattava perfettamente a contesti diversi: dalla definizione di formati di dati personalizzati, alla struttura di documenti, dallo scambio di informazioni tra sistemi eterogenei, fino alla rappresentazione grafica di immagini. Questo aspetto ha trasformato XML in una vera e propria rivoluzione, capace di ridefinire il modo in cui i dati vengono organizzati e condivisi nel mondo digitale. XML: Standard e Struttura al Servizio della Flessibilità Come accennato in precedenza, XML (eXtensible Markup Language) rappresenta un insieme standard di regole sintattiche per modellare la struttura di documenti e dati. Due parole chiave nella sua definizione – standard e struttura – ne delineano l'essenza. L'adesione a uno standard significa che XML è indipendente da piattaforme specifiche, siano esse hardware o software, e da produttori particolari. In altre parole, definendo un linguaggio di markup basato su XML, possiamo essere certi che esistono strumenti compatibili su una vasta gamma di piattaforme, pronti a comprenderlo ed elaborarlo senza problemi. Inoltre, XML si concentra sulla struttura dei dati e dei documenti, lasciando da parte altri aspetti come il tipo di dati o la loro presentazione. Questi elementi, infatti, non rientrano nel dominio di XML, ma sono affidati a tecnologie complementari, alcune delle quali sono state sviluppate direttamente basandosi su XML stesso. Questo sottolinea la sua flessibilità e universalità. Un Ecosistema Intorno a XML: Tecnologie Correlate L'importanza di XML non risiede solo nel linguaggio in sé, ma anche nell'ecosistema tecnologico che lo circonda. Una serie di strumenti e linguaggi collaterali ampliano le potenzialità di XML, rendendolo versatile e adatto a numerosi contesti. Ecco alcune delle principali tecnologie che ruotano intorno a XML: - DTD e XML Schema: Permettono di creare grammatiche che definiscono formalmente la struttura dei dati, garantendo la possibilità di verificarne la correttezza. - CSS, XSL e XSL-FO: Consentono di gestire la presentazione dei dati e di trasformarli in altri formati, rendendoli adatti a esigenze specifiche. - XLink e XPointer: Offrono strumenti per collegare documenti XML tra loro, facilitando la creazione di reti di dati interconnessi. - XQuery e XQL: Permettono di eseguire query sui dati XML, estrapolando informazioni in base a criteri predefiniti. Una Rivoluzione Universale Gli esempi sopra mostrano chiaramente che XML non è semplicemente una revisione di idee preesistenti. Al contrario, rappresenta il cuore di un sistema che consente di ottenere risultati in una vasta gamma di applicazioni, mantenendo al contempo uno standard condiviso. Questa caratteristica lo rende un elemento fondamentale per l'interoperabilità e l'evoluzione tecnologica in ambiti diversi, dal Web alla gestione dei dati aziendali.

La Struttura dei Documenti XML

Le WEB application ed il modello Client-Server. Cosa sono le applicazioni WEB, come funziona il modello Client-Server, cosa si intende per architetture multi-tier...scopriamolo!

Indice dei contenuti

- Le WEB Application ed il Modello Client-Server: Introduzione - Cos'è una WEB Application? - Un modello basato su efficienza e scalabilità - Capitolo 1: Applicazioni Web e il Modello Client-Server- Generalità sulle Applicazioni Web - Tecnologie del Web- Tecnologie Client-Side - Tecnologie Server-Side - Scelte di Implementazione - Linguaggi del Web- Linguaggi di Mark-Up - Linguaggi di Programmazione - Evoluzione dei Linguaggi - Il Modello Client-Server- Schema di Funzionamento - Evoluzione e Applicazioni - Capitolo 2: Distinzione tra Server e Client e Architettura a Livelli- Differenze tra Server e Client - Processo di Comunicazione - Tipi di Comunicazione: Unicast e Multicast- Esempio Pratico: Trasmissione Multicast - Architettura a Livelli e Strati- Livelli (Tier) - Strati (Layer) - Unione di Livelli e Strati - Architetture a 1 livello (1-tier) - Architettura a Due Livelli (2-Tier)- Modelli di Architettura a Due Livelli - Evoluzione delle Architetture a Due Livelli - Architettura a Tre Livelli (3-Tier)- Vantaggi del Modello a Tre Livelli - Complessità del Modello a Tre Livelli - Architettura a N Livelli (N-Tier) - Applicazioni Multi-Tier - Capitolo 3: Il Modello ISO/OSI e le Applicazioni di Rete- Il Livello di Applicazione nel Modello ISO/OSI e TCP/IP - Modello ISO/OSI e Modello TCP/IP - Protocolli del Livello Applicazione - Applicazioni Generali e Proprietarie - Applicazioni di Rete - Applicazioni Distribuite - Comunicazione tra Processi - Identificazione di un Servizio mediante Socket - Indirizzo IP e Numero di Porta - Funzionamento del Socket - Processo di Comunicazione - Composizione di un’Applicazione di Rete - Esempio: Un Browser Web - Gestione della Concorrenza nei Server - Processo di Connessione e Concorrenza - Capitolo 4: Scelta dell’Architettura per l’Applicazione di Rete- Architettura Client-Server - Architettura Peer-to-Peer (P2P)- Tipi di Architetture P2P - Architetture Ibride - Capitolo 5: Servizi Offerti dallo Strato di Trasporto alle Applicazioni- Trasferimento Dati Affidabile - Ampiezza di Banda (Bandwidth) - Temporizzazione - Sicurezza - Conclusioni Le WEB Application ed il Modello Client-Server: Introduzione Negli ultimi decenni, le applicazioni web hanno trasformato il panorama digitale, rendendosi indispensabili in molti ambiti della nostra vita quotidiana, dal lavoro allo svago, passando per l'istruzione e il commercio. Ma cosa sono esattamente le applicazioni web? E come funzionano? Per comprenderlo, è fondamentale esplorare il loro cuore pulsante: il modello Client-Server. Cos'è una WEB Application? Una Web Application è un'applicazione software accessibile tramite un browser web e progettata per risiedere su server remoti piuttosto che sui dispositivi degli utenti. Contrariamente alle applicazioni tradizionali, che necessitano di installazioni locali, le Web Application sfruttano Internet per connettere gli utenti ai servizi. Questo rende possibile, ad esempio, utilizzare piattaforme come Gmail, Google Docs o social media come Instagram ovunque e da qualsiasi dispositivo. Un modello basato su efficienza e scalabilità Il funzionamento delle Web Application è strettamente legato al modello Client-Server, una struttura architettonica che organizza il flusso di comunicazione tra due entità principali: - Il Client, ovvero il dispositivo dell'utente (come un computer o uno smartphone) che invia richieste. - Il Server, una macchina remota che riceve, elabora e risponde a tali richieste.

Capitolo 1: Applicazioni Web e il Modello Client-Server

Generalità sulle Applicazioni Web Con il termine applicazione Web si intende un software sviluppato e utilizzato tramite tecnologie e linguaggi specifici per il Web. Questo tipo di software sfrutta la rete Internet per fornire servizi accessibili agli utenti da qualsiasi luogo e dispositivo connesso. Due concetti chiave ne caratterizzano il funzionamento: - Tecnologie client-side e server-side, ovvero dove avviene l'elaborazione dei dati. - Linguaggi di mark-up e linguaggi di programmazione, utilizzati rispettivamente per strutturare i contenuti e per scrivere le logiche operative. Tecnologie del Web Le tecnologie utilizzate nello sviluppo delle applicazioni Web si dividono in due categorie principali, in base a dove avviene l'elaborazione: sul dispositivo dell'utente (client-side) o su un server remoto (server-side). Tecnologie Client-Side Le tecnologie client-side permettono che l'elaborazione avvenga direttamente sul dispositivo dell'utente, tipicamente tramite il browser. Questa architettura segue un flusso composto da tre fasi: - L'invio di una richiesta HTTP dal client. - La ricezione della risposta HTTP dal server. - L'elaborazione e la visualizzazione dei dati sul browser. Un esempio pratico? Pagine scritte in linguaggi come HTML o JavaScript possono essere visualizzate anche senza un Web server, semplicemente aprendo il file salvato localmente. Inoltre, il codice sorgente delle pagine client-side è visibile direttamente dal browser, rendendo questo approccio trasparente all'utente. Tecnologie Server-Side Le tecnologie server-side, invece, prevedono che l'elaborazione avvenga su un server remoto, come un Web server. Le fasi del processo sono: - Il client invia una richiesta HTTP. - Il server elabora la richiesta. - Il server invia la risposta con i dati elaborati al client. A differenza del client-side, il codice sorgente delle pagine server-side non è visibile al browser dell'utente, poiché viene elaborato interamente sul server. Questo approccio è usato per elaborazioni che richiedono un'interazione con basi di dati o operazioni più complesse. Scelte di Implementazione La scelta tra tecnologie client-side e server-side dipende dalla natura delle elaborazioni richieste: - L'interazione con gli elementi di una pagina Web avviene tipicamente client-side. - L'interazione con database remoti o processi complessi avviene server-side. Linguaggi del Web Nel Web si utilizzano principalmente due categorie di linguaggi: Linguaggi di Mark-Up Questi linguaggi, come HTML o XML, servono a strutturare i contenuti e a definirne l'aspetto visivo. Si tratta di documenti "formattati" che includono tag per la struttura e lo stile. Linguaggi di Programmazione Linguaggi come Java o PHP sono progettati per scrivere programmi, ovvero sequenze di istruzioni operative. Evoluzione dei Linguaggi Negli ultimi anni, i confini tra queste categorie si sono sfumati: - Approcci "ibridi", come AJAX, combinano tecnologie client-side e server-side. - Con HTML5 è possibile inserire script direttamente nel codice HTML, rendendo più difficile distinguere tra mark-up e programmazione.

Il Modello Client-Server

Il modello client-server rappresenta il nucleo centrale delle applicazioni Web. Esso si basa su una rete di client (utenti) che richiedono servizi e server (processi) che li forniscono. È importante distinguere tra il servizio, entità astratta fornita, e il server, processo che lo esegue. Schema di Funzionamento Le attività principali del modello sono: - Il client invia una richiesta al server. - Il server riceve la richiesta. - Il server esegue il servizio richiesto. - Il server invia una risposta con i dati al client. - Il client riceve la risposta.

Evoluzione e Applicazioni Questo modello si è evoluto per gestire applicazioni complesse con caratteristiche come: - Supporto a numerosi utenti concorrenti. - Logica applicativa avanzata. - Gestione di dati distribuiti. - Elevati requisiti di sicurezza. Tra i servizi tipici troviamo HTTP, FTP, e protocolli come SMTP o IMAP4. La programmazione di rete è quindi cruciale per soddisfare le esigenze di connessione e scambio dati nelle applicazioni moderne.

Capitolo 2: Distinzione tra Server e Client e Architettura a Livelli

Differenze tra Server e Client In un modello client-server, il client è un programma che richiede servizi, mentre il server è un programma ospitato su un computer chiamato host, che fornisce tali servizi. Il server rimane in ascolto su una specifica porta tramite un socket, aspettando richieste di connessione dai client. Quando un client desidera comunicare con un server utilizzando il protocollo TCP/IP, deve: - Connettersi al socket dell'host dove il server è in esecuzione. - Specificare l'indirizzo IP e il numero di porta su cui il server è in ascolto. È importante notare che un host può ospitare più server, ciascuno in ascolto su porte diverse. Questo può essere semplificato con un'analogia: più persone possono vivere allo stesso indirizzo ma con numeri di interno diversi, dove i numeri di interno rappresentano le porte. Processo di Comunicazione Il server, una volta ricevuta una richiesta dal client, utilizza le sue risorse per eseguire il servizio richiesto. Eventualmente, restituisce i risultati al client, completando così il ciclo di comunicazione.

Tipi di Comunicazione: Unicast e Multicast

All'interno del modello client-server, si possono distinguere due tipi principali di comunicazione: - Unicast: Il server comunica con un solo client alla volta, accettando una richiesta di connessione solo se nessun altro client è già connesso. - Multicast: Il server può gestire più connessioni contemporaneamente, generando un nuovo thread per ogni richiesta. Questo meccanismo garantisce che il server resti disponibile per altre connessioni. Esempio Pratico: Trasmissione Multicast Un esempio classico di trasmissione multicast è l'interazione tra browser e Web server. Il server HTTP rimane in attesa sulla porta 80 e crea un thread dedicato per soddisfare ogni nuova richiesta di connessione, garantendo così servizi a più utenti contemporaneamente.

Architettura a Livelli e Strati

Le applicazioni client-server moderne sono organizzate in livelli (tier) e strati (layer), fornendo una struttura modulare e scalabile. Livelli (Tier) Ogni livello corrisponde a un nodo o gruppo di nodi di calcolo distribuiti, con il seguente funzionamento: - Un livello agisce da server per i suoi client nel livello precedente. - Lo stesso livello funge da client per il livello successivo. Strati (Layer) Dal punto di vista funzionale, ogni strato rappresenta un livello di astrazione. In generale, un'architettura client-server si basa su tre strati principali, noti come modello three-tier: - Presentation Tier (Front-End): L'interfaccia utente. Comprende maschere di input e moduli per la creazione di documenti HTML (es. Java Servlet, script PHP, ASP). - Business Logic Tier (Middle Tier): Il cuore della logica applicativa. Contiene algoritmi e definizioni delle relazioni tra le diverse entità (es. operazioni su conti bancari o acquisti online). - Data Tier (Back-End): Gestione dei dati persistenti tramite database. Se implementato con un DBMS, viene chiamato Data Access Layer (DAL). > Suggerimento per immagine: Inserire un diagramma che rappresenta l'architettura three-tier, con i tre livelli distinti: front-end, middle tier e back-end. Unione di Livelli e Strati In molte architetture moderne, livelli e strati si sovrappongono, creando sistemi complessi e flessibili. La suddivisione consente inoltre di gestire applicazioni enterprise con: - Numerosi utenti concorrenti. - Logica applicativa sofisticata. - Dati distribuiti e organizzati in grandi archivi. - Elevati standard di sicurezza. Architetture a 1 livello (1-tier) Storicamente, a partire dagli anni Settanta, le architetture si riducevano a un solo mainframe al quale erano collegati i terminali “stupidi”: quindi tutta l’elaborazione era effettuata dall’elaboratore centrale e i terminali servivano solo per le fasi di I/O.Questa architettura non rientra nella tipologia client-server e può essere classificata come architettura a un solo livello (1 tier) ed è la situazione che si presentava prima dell’avvento dei sistemi distribuiti, come mostrato nella figura.

Architettura a Due Livelli (2-Tier) Con l'avvento delle reti locali negli anni Ottanta, hanno preso forma le prime architetture client-server a due livelli, dove le funzionalità erano suddivise tra: - Un livello server, responsabile dell'elaborazione e gestione dei dati. - Un livello client, che si occupa dell'interfaccia e, in alcuni casi, della logica applicativa. Modelli di Architettura a Due Livelli - Modello Thin-Client In questo modello:- Il server gestisce sia la logica applicativa che la gestione dei dati.Il client si occupa esclusivamente della presentazione dei dati. - Modello Thick-Client (o Fat-Client) In questo caso:- Il server è responsabile della gestione dei dati.Il client gestisce sia la presentazione che la logica applicativa.

La comunicazione sul web avviene attraverso protocolli di rete che operano al livello applicazione, utilizzando il protocollo di trasporto TCP. Tra questi, il più diffuso è il protocollo HTTP (HyperText Transfer Protocol), che segue un modello di cooperazione asimmetrica tra due entità fondamentali: client e server. Questi due elementi hanno ruoli ben distinti all'interno del sistema di comunicazione.

Indice dei contenuti

- Il Client: Il Punto di Partenza della Comunicazione- Caratteristiche del Client: - Esempio di richiesta HTTP da un client: - Il Server: Il Fornitore di Risorse- Caratteristiche del Server: - Esempio di risposta HTTP da un server: - Il Protocollo HTTP- Come Funziona HTTP - Conversazione Client-Server- Esempio: Richiesta di una Pagina Web - Tipi di Connessioni HTTP- Connessione HTTP 1.1 Permanente - Messaggi HTTP- Messaggio di Richiesta: HTTP Request- Sintassi della Richiesta HTTP - Riga di Richiesta- Esempio di richiesta HTTP - Intestazione HTTP (Header) - Corpo del Messaggio (Message Body)- Esempio di richiesta HTTP completa - Messaggi di risposta: HTTP Response- Struttura della Response HTTP - Esempio di una Response HTTP - Gli Header HTTP - Il Corpo della Risposta (Body) - I Metodi HTTP- Il metodo GET - Il metodo POST - Il metodo PUT - Il metodo DELETE - Tabella dei Metodi HTTP - La Codifica URL - I Codici di Stato HTTP - Strumenti per Analizzare HTTP

Il Client: Il Punto di Partenza della Comunicazione

Il client è il dispositivo o processo che inizia la comunicazione con il server per richiedere informazioni o servizi. Nel contesto del web, il client è solitamente un browser o un'applicazione che esegue richieste HTTP verso un server web. Caratteristiche del Client: - ✅ È un processo attivo: prende l'iniziativa per avviare la comunicazione con il server. - ✅ Utilizza HTTP per stabilire una connessione con il server seguendo il modello client-server a client attivo. - ✅ Usa un URL (Uniform Resource Locator) per identificare le risorse richieste sul web. - ✅ Invia richieste HTTP specificando un indirizzo IP e un numero di porta del servizio desiderato (solitamente la porta 80 per HTTP e 443 per HTTPS). - ✅ Attende una risposta dal server, che potrebbe contenere pagine web, file multimediali o dati strutturati (ad esempio, in formato JSON o XML). Esempio di richiesta HTTP da un client: GET /index.html HTTP/1.1 Host: www.esempio.com User-Agent: Mozilla/5.0

Il Server: Il Fornitore di Risorse

Il server è il sistema che risponde alle richieste inviate dal client, fornendo i dati richiesti o eseguendo operazioni specifiche. Nel web, il server è rappresentato da software come Apache, Nginx o IIS, che gestiscono le richieste HTTP. Caratteristiche del Server: - 🔊 È un processo passivo: attende richieste dai client e risponde con i dati richiesti. - 🔊 Utilizza HTTP per gestire le richieste dei client seguendo il modello client-server a server passivo. - 🔊 Ascolta su una porta TCP specifica (di solito la porta 80 per HTTP e 443 per HTTPS). - 🔊 Ospita un processo server che rimane costantemente in attesa di richieste da parte dei client. - 🔊 Invia una risposta HTTP che contiene le risorse richieste o eventuali messaggi di errore (come il celebre "404 Not Found"). Esempio di risposta HTTP da un server: HTTP/1.1 200 OK Content-Type: text/html Content-Length: 1024 Pagina di Esempio

Benvenuto!

La comunicazione sul WEB

Il Protocollo HTTP

Il protocollo HTTP (HyperText Transfer Protocol) è un protocollo di testo che fornisce il livello di trasporto per tutti i protocolli applicativi basati su di esso. Possiamo considerare il Web (WWW) come il risultato della combinazione di diverse tecnologie fondamentali, tra cui: - HTML (HyperText Markup Language): il linguaggio utilizzato per la creazione di pagine web. - URL (Uniform Resource Locator): il sistema di indirizzamento per identificare risorse online. - HTTP: il protocollo che regola la comunicazione tra client e server. Il protocollo HTTP consente di inviare e ricevere risorse web, che possono essere documenti, pagine web o elementi di una singola pagina, attraverso una comunicazione tra un server (che ospita il contenuto) e un client (che lo richiede, ad esempio un browser web).

Come Funziona HTTP

Per stabilire una comunicazione, HTTP utilizza sessioni, ciascuna delle quali inizia con l'apertura di una connessione TCP al server. Di default, questa connessione avviene sulla porta TCP 80. Il processo si sviluppa nei seguenti passaggi: - Il client invia una richiesta (request) contenente un URL. - Il server elabora la richiesta e restituisce il file richiesto. - Il server chiude la connessione TCP immediatamente dopo (nella situazione più semplice).

Conversazione Client-Server

La comunicazione tra client e server avviene tramite un meccanismo di richiesta e risposta. - Il client crea un messaggio di richiesta HTTP e lo invia al server. - Il server riceve la richiesta, elabora i dati e restituisce un messaggio di risposta HTTP. Esempio: Richiesta di una Pagina Web Immaginiamo di voler accedere alla pagina: www.profgiagnotti.it/ Ecco i passaggi della comunicazione: - Il client richiede una connessione TCP con il server web all'indirizzo www.istitutovolta.edu sulla porta 80. - Il server accetta la richiesta e apre la connessione. - Il client invia un messaggio di richiesta (request message) contenente la URL della pagina richiesta. - Il server elabora la richiesta e invia il messaggio di risposta (response message) con il contenuto richiesto. - Il server chiude la connessione TCP. - Il client riceve la risposta, che contiene il file HTML della pagina. - Il client analizza il file HTML e rileva riferimenti a immagini e altri file multimediali (ad esempio, file PNG). - Per ogni immagine rilevata, il client ripete i passi da 1 a 5, richiedendo ogni elemento al server.

Tipi di Connessioni HTTP

Il protocollo HTTP utilizza TCP come protocollo di trasporto per gestire le connessioni tra client e server. La connessione HTTP viene attivata dal client, che stabilisce una connessione TCP con il server attraverso il three-way handshake. Una volta completato lo scambio iniziale, il client può inviare una richiesta HTTP. Dopo aver risposto, il server chiude la connessione tramite un ulteriore scambio di segmenti TCP. Connessione HTTP 1.1 Permanente Nella versione HTTP 1.1, la connessione TCP rimane aperta anche dopo l'invio della risposta. Questo consente di riutilizzare la stessa connessione per più richieste consecutive, migliorando l'efficienza della comunicazione. Le connessioni permanenti possono essere di due tipi: - Connessione permanente non incanalata: il client invia una nuova richiesta solo dopo aver ricevuto la risposta alla precedente. - Connessione permanente incanalata (pipelined): il client invia più richieste in sequenza senza attendere le risposte, che vengono elaborate nello stesso ordine. Di default, HTTP 1.1 utilizza la connessione incanalata, consentendo al client di inviare più richieste consecutive senza attese (metodo back-to-back).

Messaggi HTTP

Durante la comunicazione HTTP, client e server scambiano messaggi di richiesta e risposta, che seguono una struttura standard composta da: - Una riga iniziale (indica il tipo di messaggio) - Un'intestazione (header) (opzionale, contiene metadati sulla comunicazione) - Una riga vuota (separatore tra header e corpo) - Un corpo del messaggio (body) (opzionale, contiene i dati trasmessi) Messaggio di Richiesta: HTTP Request Una richiesta HTTP ( Request) è composta da tre elementi fondamentali: - Riga di richiesta - Intestazione HTTP (header) - Corpo del messaggio (message body) (se necessario) Sintassi della Richiesta HTTP // Riga di richiesta // Intestazione CRLF // Riga vuota // Corpo del messaggio Dove CRLF (Carriage Return Line Feed) indica un ritorno a capo per separare le sezioni del messaggio. Riga di Richiesta La riga di richiesta contiene: - Metodo (Method): indica l'operazione richiesta. - HTTP/0.9: GET - HTTP/1.0: DELETE, GET, HEAD, LINK, POST, PUT, UNLINK - HTTP/1.1: CONNECT, DELETE, GET, HEAD, OPTIONS, POST, PUT, TRACE - URI (Uniform Resource Identifier): identifica la risorsa richiesta. - Versione del protocollo HTTP: ad esempio HTTP/1.0 o HTTP/1.1. Esempio di richiesta HTTP GET /percorso/file.html HTTP/1.1 - Metodo: GET - URI: /percorso/file.html - Versione: HTTP/1.1 In questo caso, il client richiede il file HTML situato nella sottodirectory /percorso del server. Intestazione HTTP (Header) L'intestazione HTTP contiene informazioni sul messaggio e segue il formato: nome_header: valore CRLF Le intestazioni si suddividono in: - Intestazioni generali: informazioni comuni a richiesta e risposta. - Intestazioni della richiesta: dettagli specifici della richiesta. - Intestazioni del corpo dell'entità: metadati sui contenuti trasmessi. Esempio di header in una richiesta HTTP: Accept: image/gif, image/jpeg, image/png, */* Accept-Language: it Accept-Encoding: gzip, deflate Host: www.magistricumacini.it If-Modified-Since: Fri, 14 Mar 2018 10:54:03 GMT User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Quando si utilizza il metodo GET, il corpo dell'entità (entity body) non viene incluso nella richiesta. Corpo del Messaggio (Message Body) Il corpo del messaggio contiene i dati trasmessi nella richiesta. La sua presenza dipende dal metodo HTTP utilizzato. Ad esempio, nei metodi POST e PUT, il corpo del messaggio include i dati da inviare al server. Esempio di richiesta HTTP completa GET / HTTP/1.1 Accept: image/gif, image/jpeg, image/png, */* Accept-Language: it Accept-Encoding: gzip, deflate Host: www.magistricumacini.it If-Modified-Since: Fri, 14 Mar 2018 10:54:03 GMT User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Messaggi di risposta: HTTP Response Quando un server HTTP riceve una richiesta da un client, intraprende una serie di azioni per fornire la risorsa richiesta. Queste azioni possono includere l'esecuzione di uno script server-side o il recupero di una risorsa statica dal server. Una volta completato il processo, il server invia una risposta HTTP al client. Vediamo in dettaglio come si struttura una risposta HTTP. Struttura della Response HTTP La risposta HTTP è organizzata in modo simile a una richiesta HTTP, ma con una differenza fondamentale: invece della riga di richiesta, la risposta inizia con una riga di stato. La risposta HTTP è composta da tre parti principali: - Riga iniziale: La prima parte della risposta, che contiene la versione del protocollo HTTP e il codice di stato. - Intestazione (Header): Una serie di coppie chiave-valore che forniscono informazioni aggiuntive sulla risposta. Gli header possono essere generali, specifici dell'entità trasmessa o relativi alla richiesta. - Corpo (Body): La sezione del messaggio che contiene la risorsa o il dato richiesto, come una pagina HTML, un'immagine o un file JSON. Esempio di una Response HTTP Un esempio di intestazione tipica di una risposta HTTP potrebbe essere: HTTP/1.1 200 OK Transfer-Encoding: chunked Date: Sat, 28 Nov 2021, 04:33:04 GMT Server: Apache/1.4 Connection: close Expires: Sat, 28 Nov 2021, 05:33:04 GMT Cache-Control: max-age=3600, public Content-Type: text/html Nel corpo della risposta (body), troviamo il contenuto richiesto, ad esempio una pagina HTML: Il protocollo HTTP

Benvenuti alla lezione sul protocollo HTTP!

Indice dei contenuti

- Evoluzione dell'architettura hardware- Classificazione di Flynn - Descrizione delle architetture - Cluster Computing: Un'Evoluzione dei Sistemi Distribuiti- Caratteristiche Distintive dei Cluster - Tipologie di Architettura nei Cluster - Grid Computing: Un Sistema Distribuito Decentralizzato- Origine e Obiettivi del Grid Computing - Evoluzione verso un’Architettura Service-Oriented - Sistemi Distribuiti Pervasivi: L’Informatica Ovunque- Requisiti Chiave dei Sistemi Pervasivi - Reti Domestiche e Domotica: L’Automazione della Vita Quotidiana- Struttura delle Reti Domestiche - L’Innovazione della Domotica - Wearable Computing: Tecnologia Indossabile e Monitoraggio Biometrico- Applicazioni Principali - Sfide Tecnologiche e di Sicurezza - Reti di Sensori e Integrazione con il Wearable Computing - Architetture Distribuite Software: Dai Terminali Remoti ai Sistemi Completamente Distribuiti- Architettura a Terminali Remoti - Architettura Client-Server - Architettura Web-Centric - Architettura Cooperativa - Architettura Completamente Distribuita - Architettura a livelli- Obiettivi del Middleware - Funzionalità del Middleware - Limitazioni del Middleware - Conclusione In questo articolo spiego in che modo l'evoluzione dei sistemi distribuiti ha portato a un significativo progresso nell'architettura hardware, consentendo un aumento della potenza di calcolo senza dover spingere al limite la velocità delle singole CPU. Questa evoluzione ha portato allo sviluppo di sistemi con più unità di elaborazione, noti come macchine parallele o sistemi ad architettura parallela.

Evoluzione dell'architettura hardware

Per superare i limiti imposti dall'aumento della velocità di una singola CPU, si è optato per l'integrazione di più processori all'interno di un sistema. Ciò ha permesso di distribuire il carico computazionale e migliorare le prestazioni complessive del sistema. Uno dei principali criteri per classificare le architetture hardware è stato proposto da Michael J. Flynn nel 1972. La sua classificazione si basa sulla combinazione di due flussi di informazioni presenti nei calcolatori: - Flusso delle istruzioni: rappresenta l'insieme di operazioni eseguite dalla CPU. - Flusso dei dati: indica il modo in cui i dati vengono elaborati e trasferiti all'interno del sistema. Classificazione di Flynn Flynn ha identificato quattro categorie principali di architetture, basate sulla combinazione dei flussi di dati e istruzioni: Tipo di ArchitetturaFlusso di IstruzioniFlusso di DatiSISD (Single Instruction Single Data)SingoloSingoloSIMD (Single Instruction Multiple Data)SingoloMultiploMISD (Multiple Instruction Single Data)MultiploSingoloMIMD (Multiple Instruction Multiple Data)MultiploMultiplo Descrizione delle architetture - Macchine SISD (Single Instruction Single Data) - Questa è l'architettura tradizionale dei calcolatori sequenziali, dove un singolo processore esegue una singola istruzione su un singolo flusso di dati alla volta. - Esempio: i primi computer mainframe e molti microprocessori tradizionali. - Macchine SIMD (Single Instruction Multiple Data) - Un'unica istruzione viene eseguita contemporaneamente su più flussi di dati. Questo tipo di architettura è particolarmente utilizzato nei supercomputer e nei processori grafici (GPU). - Esempio: elaborazione parallela nei moderni GPU per il rendering di immagini. - Macchine MISD (Multiple Instruction Single Data) - Molteplici istruzioni vengono applicate simultaneamente su un unico flusso di dati. Questa configurazione è meno comune e spesso utilizzata per sistemi specializzati, come l'elaborazione di segnali o alcuni sistemi fault-tolerant. - Esempio: pipeline nei sistemi di crittografia. - Macchine MIMD (Multiple Instruction Multiple Data) - Ogni processore esegue istruzioni indipendenti su diversi insiemi di dati. Questo tipo di architettura è alla base della maggior parte dei moderni sistemi multiprocessore e delle reti di calcolatori distribuiti. - Esempio: cluster di server, cloud computing, e supercomputer moderni.

tassonomia di Flynn

Cluster Computing: Un'Evoluzione dei Sistemi Distribuiti

Il Cluster Computing rappresenta un sistema distribuito in cui più nodi ad alte prestazioni sono interconnessi attraverso una rete locale ad alta velocità. Questi nodi devono essere omogenei, ovvero avere un hardware simile, lo stesso sistema operativo e condividere la stessa rete. Caratteristiche Distintive dei Cluster Rispetto a una semplice rete di PC, un cluster si distingue per: - Alta potenza di calcolo (High Performance Computing - HPC): La potenza complessiva è teoricamente pari alla somma di quella dei singoli nodi. - Trasferimento dati ultra-veloce: Le connessioni raggiungono velocità superiori a 1 Gbit/s. - Centralizzazione fisica: I PC sono montati su un unico rack per ridurre la latenza di comunicazione. - Gestione centralizzata: Un'applicazione di management permette di monitorare i nodi, distribuire carichi di lavoro e ottimizzare le prestazioni.

cluster computing Tipologie di Architettura nei Cluster Esistono due principali modelli organizzativi per i cluster: - Organizzazione Gerarchica con Nodo Principale (Beowulf) - Un nodo principale gestisce la comunicazione e il calcolo viene distribuito agli altri nodi. - Utilizza librerie di Message Passing Interface (MPI) per il calcolo parallelo. - Single System Image (MOSIX) - Il cluster viene visto come un unico sistema operativo distribuito. - Un algoritmo automatico di bilanciamento del carico ottimizza le prestazioni, migrando i processi tra i nodi.

Grid Computing: Un Sistema Distribuito Decentralizzato

Il Grid Computing è un modello di calcolo distribuito altamente decentralizzato, costituito da una rete di nodi interconnessi in una griglia virtuale (grid). A differenza dei cluster di calcolo, i sistemi grid sono caratterizzati da un elevato grado di eterogeneità, poiché i nodi possono avere: - Hardware e architetture differenti - Diversi sistemi operativi e tecnologie di rete - Politiche di sicurezza indipendenti Origine e Obiettivi del Grid Computing Il concetto di griglia computazionale è stato introdotto a metà degli anni ’90 con l’obiettivo di consentire la condivisione coordinata delle risorse all’interno di organizzazioni virtuali (Virtual Organization - VO). L’idea principale non si limita allo scambio di file, ma estende la condivisione a: - Risorse di calcolo (potenza CPU e GPU) - Software e applicazioni - Storage e database - Reti e infrastrutture IT

grid computing Evoluzione verso un’Architettura Service-Oriented Inizialmente, le grid erano strutturate su quattro livelli di specificità, ma con l’evoluzione tecnologica si è passati a un modello service-oriented noto come Open Grid Service Architecture (OGSA). In questo approccio, tutte le risorse—calcolo, storage, reti, programmi, database—sono trattate come grid services, migliorando l’accessibilità e la scalabilità.

Sistemi Distribuiti Pervasivi: L’Informatica Ovunque

I sistemi distribuiti pervasivi rappresentano una nuova generazione di tecnologie, caratterizzate da dispositivi piccoli, mobili e connessi via wireless. Questi sistemi sono spesso integrati in contesti più ampi, come: - Sistemi domestici (smart home, domotica) - Elettronica per l’assistenza sanitaria (telemedicina, dispositivi wearable) - Reti di sensori (monitoraggio ambientale, sicurezza) Requisiti Chiave dei Sistemi Pervasivi - Adattabilità al contesto: il sistema deve funzionare in ambienti dinamici con condizioni mutevoli. - Composizione ad hoc: ogni nodo può essere utilizzato in modi diversi da utenti differenti. - Facilità di configurazione: deve essere semplice da installare e gestire senza competenze tecniche avanzate. - Condivisione come principio base: i nodi si attivano e si disattivano dinamicamente, fornendo informazioni e servizi condivisibili. Uno dei problemi principali in questi sistemi è il compromesso tra pervasività e trasparenza: mentre i sistemi distribuiti tradizionali cercano di nascondere la distribuzione per semplificare l’uso, nei sistemi pervasivi è spesso preferibile renderla esplicita per garantire un maggiore controllo agli utenti.

Reti Domestiche e Domotica: L’Automazione della Vita Quotidiana

Le reti domestiche rappresentano l’infrastruttura di base per la connessione di dispositivi all’interno di un’abitazione. A differenza delle reti aziendali, queste sono progettate per essere auto-configuranti e autogestite, poiché la maggior parte degli utenti non possiede conoscenze avanzate di connettività. Struttura delle Reti Domestiche Una soluzione comune per semplificare la gestione della rete domestica è l’utilizzo di un home box centralizzato, ovvero un router o gateway che connette wireless tutti i dispositivi, inclusi: - PC, tablet e smartphone - Dispositivi smart home (termostati, videocamere, assistenti vocali) - Elettrodomestici connessi (frigoriferi intelligenti, lavatrici, sistemi di irrigazione) - Dispositivi ospiti (smart TV, console di gioco, sensori IoT)

L’Innovazione della Domotica L’evoluzione tecnologica e l’integrazione sempre più stretta tra mondo fisico e digitale hanno spinto una forte crescita della domotica, un settore che si occupa dell’automazione degli ambienti domestici per migliorare la qualità della vita. Il termine "domotica" nasce dalla fusione di "domus" (casa) e "automatica", e si riferisce a un insieme di tecnologie che permettono il controllo intelligente della casa. Le aspettative dei consumatori sono cambiate negli ultimi anni, con una crescente domanda di case più intelligenti e dotate di sistemi interattivi, simili a quelli presenti negli smartphone. Questo ha portato alla nascita del concetto di Ambient Intelligence (Intelligenza Ambientale), definito da D.J. Cook come: “An Ambient Intelligence system is a digital environment that proactively, but sensibly, supports people in their lives.” (Un sistema di intelligenza ambientale è un ambiente digitale che supporta le persone in modo proattivo ma ragionato nella loro vita.)

Wearable Computing: Tecnologia Indossabile e Monitoraggio Biometrico

Il Wearable Computing (calcolo indossabile) è un settore in continua evoluzione, con applicazioni che spaziano dall'assistenza sanitaria al fitness, dalla sicurezza al settore industriale. Questi dispositivi sono progettati per essere indossati dagli utenti e per raccogliere, elaborare e trasmettere dati in tempo reale. Applicazioni Principali Attualmente, i sistemi di wearable computing sono prevalentemente utilizzati in ambito sanitario e medico, dove permettono il monitoraggio continuo dei parametri vitali e la gestione remota delle informazioni cliniche. Possiamo distinguere due principali modalità operative: - Memorizzazione locale dei dati – Il dispositivo raccoglie i dati e li archivia in un computer palmare (PDA, Personal Digital Assistant) o in uno smartphone. - Trasmissione remota dei dati – I dati vengono inviati a un sistema di archiviazione remoto o a un'infrastruttura cloud, permettendo l’accesso in tempo reale da parte di operatori sanitari. Sfide Tecnologiche e di Sicurezza Nonostante i progressi tecnologici, i dispositivi wearable presentano alcune sfide critiche: - Memorizzazione e gestione dei dati: i dispositivi devono garantire un'adeguata capacità di archiviazione senza compromettere le prestazioni. - Prevenzione della perdita di dati: meccanismi di backup e sincronizzazione sono fondamentali per evitare la perdita di informazioni cruciali. - Sicurezza e privacy: la trasmissione dei dati sanitari deve avvenire tramite protocolli criptati e con sistemi di autenticazione sicuri. - Gestione degli allarmi: in caso di rilevamento di valori anomali (es. battito cardiaco irregolare), il sistema deve attivare notifiche immediate per medici o familiari. Reti di Sensori e Integrazione con il Wearable Computing Le reti di sensori (Wireless Sensor Networks - WSN) sono un elemento chiave nei sistemi di wearable computing. Sono composte da numerosi nodi sensore (da 10 a 1000) che raccolgono informazioni sull’ambiente o sul corpo umano. Due possibili approcci per la gestione dei dati raccolti dai sensori: - Base di dati centralizzata: i dati vengono inviati a un server remoto o a un’infrastruttura cloud per essere elaborati. - Memorizzazione distribuita: ogni nodo della rete può memorizzare parte delle informazioni, creando di fatto un database distribuito. Questa seconda opzione è particolarmente utile in contesti in cui la connettività è intermittente o quando si vuole ridurre la dipendenza da un unico punto di raccolta dati.

Architetture Distribuite Software: Dai Terminali Remoti ai Sistemi Completamente Distribuiti

L'evoluzione delle architetture distribuite non ha riguardato solo l'hardware, ma anche il software, spesso anticipando i cambiamenti nei sistemi operativi e nelle infrastrutture tecnologiche. In questo articolo analizziamo le principali tappe dell'evoluzione del software nei sistemi distribuiti. Architettura a Terminali Remoti La prima forma di architettura distribuita era basata su terminali remoti connessi a un'unica entità centrale. In questo modello, tutti i processi di calcolo ed elaborazione erano eseguiti dal sistema centrale, mentre i terminali, privi di capacità computazionale, si limitavano a inviare e ricevere dati. Caratteristiche principali: - Terminali omogenei con funzionalità limitate. - Elaborazione centralizzata con gestione dedicata della memoria per ogni terminale. - Bassa scalabilità e dipendenza da un unico punto di elaborazione.

rete di terminali

Architettura Client-Server

In questo articolo, I modelli e le architetture di rete, spiego come sia possibile risolvere diverse problematiche legate alle reti (scelta del mezzo fisico, controllo degli errori, affidabilità, sicurezza) ed, in particolare, come sia possibile raggiungere l'obiettivo di trasmettere un messaggio da un host mittente ad uno destinatario

Indice dei contenuti

- Capitolo 1: Organizzare la complessità delle reti- Il modello di rete a strati: Un approccio sistematico- Un’analogia con la programmazione informatica - Un’analogia con la gestione di spedizioni - Il modello a strati: Struttura e funzionamento - Vantaggi del modello a strati - Problematiche affrontate dai livelli - Il principio dell’incapsulamento- Lato ricezione: Decapsulamento - Caratteristiche delle architetture di rete- Protocol Data Unit (PDU) - Primitive di servizio - Distinzione tra funzioni, servizi e primitive - Capitolo 2: Il modello ISO/OSI- Un modello di riferimento per le reti di computer - La suddivisione in strati - I sette livelli del modello ISO/OSI- 1. Physical Layer (Livello fisico) - 2. Data Link Layer (Livello di collegamento dati) - 3. Network Layer (Livello di rete) - 4. Transport Layer (Livello di trasporto) - 5. Session Layer (Livello di sessione) - 6. Presentation Layer (Livello di presentazione) - 7. Application Layer (Livello applicativo) - L’uso di OSI nelle reti - Capitolo 3: Lo stack TCP/IP- 3.1 I livelli di TCP/IP- I quattro livelli del modello TCP/IP - Confronto con il modello OSI

Capitolo 1: Organizzare la complessità delle reti

Le reti di comunicazione sono nate con l'obiettivo di rendere possibile la trasmissione di dati tra macchine, anche fisicamente distanti tra loro, e di favorire la condivisione delle risorse. La realizzazione di una rete è, tuttavia, un'attività complessa che richiede di affrontare numerose problematiche: dal mezzo fisico necessario per trasmettere i segnali, alla gestione degli errori di trasmissione; dall'identificazione dei sistemi coinvolti, fino alla garanzia di sicurezza e affidabilità della comunicazione. Affrontare questa complessità in modo unitario risulterebbe proibitivo. Per questo motivo, i progettisti hanno adottato un approccio modulare, suddividendo il problema in parti più semplici, ciascuna delle quali è gestita da moduli indipendenti ma cooperativi. L'obiettivo ultimo rimane quello di garantire il trasferimento affidabile di un messaggio da un mittente a un destinatario. Il modello di rete a strati: Un approccio sistematico Per semplificare la progettazione e l'implementazione delle reti, è stato introdotto il modello di rete a strati (o a livelli). Questo modello suddivide la comunicazione tra sistemi in funzioni elementari, ciascuna delle quali è assegnata a un livello specifico. Ogni livello ha il compito di risolvere una parte del problema complessivo, collaborando con gli altri per raggiungere l'obiettivo comune. Un’analogia con la programmazione informatica La progettazione a livelli trova corrispondenza nella metodologia top-down utilizzata in programmazione. Quando si affrontano problemi complessi, si tende a scomporli in sottoproblemi più semplici, risolti attraverso moduli funzionali. Questo approccio consente di evitare di progettare soluzioni monolitiche, difficili da gestire, e permette di concentrarsi su aspetti specifici del problema. Tuttavia, tale suddivisione richiede la definizione di regole precise per la comunicazione tra i vari moduli, sia per quanto riguarda i dati scambiati, sia per le modalità di input e output. Allo stesso modo, i modelli a livelli per le reti definiscono un sistema strutturato per ridurre la complessità della comunicazione tra macchine. Un’analogia con la gestione di spedizioni Un esempio pratico della suddivisione del lavoro in compiti più semplici può essere trovato nel processo di spedizione. Immaginiamo il responsabile acquisti di un’azienda italiana che desidera ricevere informazioni su un prodotto di una società americana. La comunicazione richiede diverse fasi: - Ruoli definiti: Identificare chi si occupa di specifici compiti, come il traduttore o l’addetto alle spedizioni. - Servizi tra le persone: Stabilire le attività svolte da ciascun ruolo, ad esempio la traduzione o il ritiro presso l’ufficio postale. - Regole operative: Stabilire procedure standardizzate, come inserire una lettera in una busta e apporvi un francobollo. Analogamente, il modello a strati suddivide il processo di comunicazione in compiti distinti e coordinati. Il modello a strati: Struttura e funzionamento Il modello a strati è tradizionalmente rappresentato in verticale, come una pila di livelli. Ogni livello comunica con il corrispondente livello dell'altro sistema (peer level) attraverso protocolli specifici. Allo stesso tempo, interagisce direttamente solo con i livelli immediatamente superiori e inferiori. Comunicazione tra livelli: - Logica (peer-to-peer): Ogni livello comunica con il livello corrispondente del sistema remoto attraverso protocolli, ma in realtà il messaggio passa attraverso gli strati intermedi. - Fisica (livelli adiacenti): Ogni livello elabora il messaggio ricevuto dal livello superiore, aggiungendo o rimuovendo informazioni, e lo trasmette al livello inferiore attraverso una interfaccia Ogni livello accede ai servizi offerti dal livello sottostante Questa modularità garantisce flessibilità e indipendenza tra i livelli. Qualsiasi modifica a uno strato non richiede modifiche agli altri, purché l’interfaccia tra livelli rimanga invariata.

Vantaggi del modello a strati Il successo del modello a strati deriva dai suoi numerosi vantaggi: - Riduzione della complessità: Grazie all’introduzione di livelli di astrazione. - Indipendenza dei livelli: Ogni livello ha un ruolo specifico e non è vincolato agli altri. - Interazione tramite interfacce: Ogni livello offre servizi al superiore e utilizza quelli del sottostante, senza interessarsi al modo in cui le funzioni interne sono implementate. - Progettazione modulare: È possibile aggiungere nuovi servizi modificando solo il livello interessato. - Flessibilità nei protocolli: Ogni livello può adottare protocolli diversi, ottimizzati per specifici compiti. Problematiche affrontate dai livelli Ogni livello si occupa di un aspetto specifico della comunicazione, come: - Identificazione delle entità peer. - Modalità di trasferimento (simplex, half-duplex, full-duplex). - Controllo degli errori e dell’ordine di invio. - Gestione del flusso e adattamento delle velocità di trasmissione. - Instradamento e frammentazione dei pacchetti. Questi aspetti saranno approfonditi nelle specifiche relative ai protocolli utilizzati nelle reti moderne, come quelle TCP/IP. Il principio dell’incapsulamento L’incapsulamento (encapsulation) è un principio fondamentale nelle architetture di rete basate sul modello a strati. Questo processo permette ai livelli della comunicazione di aggiungere informazioni utili per lo svolgimento delle funzioni specifiche. Quando un messaggio (M) passa dal livello superiore al livello immediatamente inferiore, viene arricchito con un header (H), ovvero un set di dati che contiene informazioni necessarie per gestire e instradare il pacchetto. Ad esempio, un messaggio proveniente dal livello 5 viene elaborato dal livello 4, che aggiunge il proprio header (H4). L’insieme risultante, formato da M + H4, viene quindi inviato al livello 3 come pacchetto completo. Lato ricezione: Decapsulamento Nel ricevere un pacchetto dati, il livello 4 estrae l’header H4 per ottenere le informazioni necessarie al proprio funzionamento, inviate dalla peer entity dell’host mittente. Successivamente, i dati rimanenti, privi dell’header H4, vengono trasmessi al livello superiore (livello 5), completando il processo di decapsulamento. Una eccezione al principio di incapsulamento si verifica solo nei primi e ultimi livelli, che non aggiungono né modificano gli header.

Caratteristiche delle architetture di rete Un’architettura di rete è il quadro concettuale che consente la comunicazione tra computer. Per realizzare un’architettura efficiente, è necessario seguire tre passaggi fondamentali: - Definizione del modello di riferimento: Si stabilisce il numero di strati, le funzioni svolte da ciascuno e le relazioni tra essi. - Descrizione dei servizi: Si identificano i servizi che ogni strato fornisce a quelli superiori e inferiori. - Formalizzazione dei protocolli e delle interfacce: Si specificano le modalità di implementazione e di interazione tra i livelli. Protocol Data Unit (PDU) Nella comunicazione tra sistemi, l’insieme dei dati scambiati, noto genericamente come “messaggio” o “pacchetto,” assume una definizione più formale nel contesto del modello a strati: la Protocol Data Unit (PDU). Ogni protocollo standard deve specificare il formato della sua PDU, dettagliando gli elementi che costituiscono i dati trasmessi. Primitive di servizio Le primitive di servizio sono le operazioni che un livello utilizza per interagire con quello immediatamente sottostante. Servono a: - Richiedere un servizio in trasmissione. - Ricevere informazioni in ricezione. I principali parametri delle primitive includono dati da trasferire, destinazione, caratteristiche del servizio e altro. Le primitive più comuni sono: - Connect Request: Richiesta di connessione con specifica dei parametri (ad esempio, dimensione massima dei pacchetti). - Connect Indication: Segnalazione al destinatario della richiesta di connessione. - Connect Response: Risposta del destinatario che accetta o rifiuta la connessione. - Connect Confirm: Conferma dell’esito della richiesta di connessione.

Distinzione tra funzioni, servizi e primitive - Funzioni: Operazioni interne svolte da un livello per gestire i dati. - Servizi: Offerti su un’interfaccia tra livelli adiacenti per garantire la comunicazione. - Primitive: Meccanismi che attivano i servizi e permettono l’interazione tra i livelli. Questa distinzione è essenziale per comprendere il ruolo di ciascun componente nel modello a strati e per garantire la modularità e l’efficienza dell’architettura di rete.

Capitolo 2: Il modello ISO/OSI

Un modello di riferimento per le reti di computer Il modello ISO/OSI (Open Systems Interconnection) è stato sviluppato nel 1978 dall'International Organization for Standardization (ISO) con l’obiettivo di definire una struttura formale per l’interconnessione tra computer. Pubblicato nel documento ISO 7498, il modello ISO/OSI è oggi un punto di riferimento universale per le reti di comunicazione. Il modello si basa su una struttura a strati, suddividendo le funzioni di rete in sette livelli distinti, ciascuno con responsabilità specifiche e interdipendenti. Questo approccio facilita la progettazione, il funzionamento e l'interoperabilità tra sistemi, garantendo che ogni livello si concentri su un aspetto fondamentale della comunicazione. La suddivisione in strati I sette livelli del modello ISO/OSI sono: - Lower Layers (livelli inferiori): I primi tre strati sono orientati alla rete e garantiscono le comunicazioni a livello di infrastruttura. - Intermediate Layer (livello intermedio): Il quarto livello separa l’ambiente della rete da quello delle applicazioni. - Upper Layers (livelli superiori): Gli ultimi tre strati sono dedicati alle funzioni di applicazione e interazione diretta con l’utente. Il principio dell’incapsulamento è centrale nella comunicazione tra due host. Durante la trasmissione, ogni livello aggiunge il proprio header ai dati, mentre nel processo inverso, al livello di ricezione, ogni strato analizza e rimuove il suo header, trasmettendo il payload al livello superiore.

I sette livelli del modello ISO/OSI 1. Physical Layer (Livello fisico) Gestisce la trasmissione di una sequenza di bit attraverso un mezzo fisico, come cavi elettrici, fibre ottiche o segnali radio. Le sue principali funzioni includono: - Definizione delle caratteristiche fisiche delle interfacce e del mezzo trasmissivo. - Rappresentazione dei bit come segnali da trasmettere. - Sincronizzazione tra mittente e destinatario per garantire una comunicazione senza interruzioni. - Organizzazione della topologia fisica della rete. Apparati: Schede di rete (NIC) e hub. 2. Data Link Layer (Livello di collegamento dati) Rende affidabile il collegamento fisico tra due dispositivi della stessa rete. Si occupa di: - Suddividere i dati in frame, ciascuno con un header che identifica mittente e destinatario. - Controllare il flusso per prevenire la congestione. - Correggere errori di trasmissione. - Gestire l’accesso al mezzo trasmissivo condiviso. Apparati: Bridge e switch. 3. Network Layer (Livello di rete) Responsabile dell’instradamento dei pacchetti attraverso diverse reti. I suoi compiti principali includono: - Suddividere i dati in packet o datagram. - Utilizzare indirizzi logici come l’indirizzo IP per comunicazioni tra reti. - Instradare i pacchetti verso la destinazione. Apparati: Router. 4. Transport Layer (Livello di trasporto) Assicura la consegna end-to-end dei messaggi tra mittente e destinatario. Si occupa di: - Identificare il processo corretto attraverso numeri di porta. - Suddividere i messaggi in segmenti e riassemblarli al destinatario. - Controllare il flusso e gli errori su scala end-to-end. - Gestire la connessione orientata (connection-oriented) o non orientata (connectionless). 5. Session Layer (Livello di sessione) Controlla e gestisce il dialogo tra i sistemi, suddividendo le interazioni in sessioni. I suoi compiti principali includono: - Sincronizzare il flusso dei dati. - Introdurre checkpoint per facilitare la ripresa delle comunicazioni in caso di interruzioni. 6. Presentation Layer (Livello di presentazione) Garantisce la correttezza sintattica e semantica dei dati. Funzioni principali: - Conversione dei dati in un formato comune per la trasmissione. - Crittografia e decrittografia delle informazioni. - Compressione dei dati per ottimizzare la trasmissione di file di grandi dimensioni. 7. Application Layer (Livello applicativo) Offre un’interfaccia utente per accedere ai servizi di rete come posta elettronica, trasferimento di file e terminale remoto. La PDU a questo livello è chiamata message. L’uso di OSI nelle reti Il modello ISO/OSI è adottato universalmente come modello di riferimento per l'organizzazione delle architetture di protocolli. Tuttavia, i protocolli definiti per i livelli Network e Transport del modello OSI hanno riscontrato scarso successo. Al contrario, l'architettura TCP/IP, anch’essa strutturata a strati, si è rapidamente imposta come standard grazie alla diffusione di Internet. I protocolli chiave dell’architettura TCP/IP, come IP per il livello Network e TCP per il livello Transport, sono incompatibili con quelli del modello OSI ma rappresentano un’alternativa valida e complementare. Per quanto riguarda la struttura generale, i due modelli sono equivalenti.

Capitolo 3: Lo stack TCP/IP