Soluzione Esame di Stato II Prova Informatica Istituti Tecnici - Parte Sistemi e Reti (4 luglio 2019 - Sessione suppletiva)

Una possibile soluzione commentata della prova suppletiva di informatica. Come nostro solito, sviluppiamo e commentiamo una soluzione della sola porzione riguardante Sistemi e Reti. Non costituisce una soluzione corretta in modo assoluto, ma solo una possibile interpretazione con elementi, si spera, utili agli alunni che devono fronteggiare il nuovo Esame di Stato

PRIMA PARTE

La ditta InfoService offre servizi di assistenza hardware-software e consulenza informatica in genere. Essa opera a livello regionale ed al suo interno lavorano una cinquantina di dipendenti che si occupano di settori specifici quali assistenza hardware a dispositivi informatici, configurazione di server e relativi servizi, assistenza software e sviluppo di nuove applicazioni su richiesta dei clienti, personalizzazione di software già esistenti. Per ottimizzare la gestione degli interventi di assistenza presso i propri clienti, InfoService ha deciso di sviluppare un sistema di ticketing. Il sistema prevede che i clienti, accedendo al portale web attraverso le proprie credenziali, possano richiedere interventi di personale tecnico per la risoluzione di problemi di natura hardware o software relativi ai servizi offerti da InfoService. La richiesta comporta l’apertura di un ticket nel quale, oltre ai dati del richiedente, già presenti in quanto associati al suo account, il cliente descriverà il problema riscontrato per il quale richiede l’intervento. A seconda della problematica, l’intervento verrà effettuato da remoto oppure presso il cliente. Il personale di InfoService addetto all’helpdesk individuerà il tecnico a cui assegnare il ticket. Il tecnico, effettuato l’intervento, registrerà immediatamente in un report online l’attività svolta e il tempo impiegato: se il problema è stato risolto, provvederà a chiudere il ticket, altrimenti questo resterà aperto in attesa di ulteriori interventi. Il cliente dovrà convalidare il report, avendo anche la possibilità di esprimere un proprio commento. Il candidato analizzi la realtà descritta e, fatte le opportune ipotesi aggiuntive, individui una soluzione che a suo motivato giudizio sia la più idonea per sviluppare i seguenti punti:

1. il progetto, anche mediante rappresentazioni grafiche, dell’infrastruttura tecnologica ed informatica necessaria a gestire il servizio nel suo complesso, dettagliando:

a) le risorse hardware ed i servizi software necessari per sviluppare il sistema di ticketing;

b) le misure che possono essere adottate per gestire con la massima sicurezza le informazioni trattate dal sistema di ticketing;

c) le modalità con le quali i tecnici provvedono online alla compilazione del report approfondendo:

- le caratteristiche della connessione alla rete Internet sia della sede centrale di InfoService sia dei dispositivi in dotazione al personale tecnico in trasferta;

- gli aspetti di sicurezza relativi alla comunicazione tra i dispositivi client in dotazione al personale tecnico e il sistema centrale di InfoService;

- le modalità attraverso le quali il cliente convalida il report compilato dal tecnico, eventualmente esprimendo il proprio commento;

2. il progetto della base di dati per la gestione del sistema di ticketing: in particolare si richiede il modello concettuale ed il corrispondente modello logico;

3. lo sviluppo in linguaggio SQL delle query che consentono di ottenere le seguenti informazioni:
- elenco dei ticket attualmente aperti riportando il nome del cliente che li ha aperti, la data di apertura, il tecnico che li sta seguendo;
- tempo medio di chiusura dei ticket completati in un certo intervallo temporale fornito in ingresso
  
Soluzione:
La parte di Sistemi & Reti in questa prova ricopre il punto 1. La traccia è molto vaga sulla reale natura progettuale specifica del sistema proposto. Per questo lo studente non deve preoccuparsi ma anzi far tesoro di tutte le conoscenze apprese con le esperienze svolte durante il corso dell'anno. Nel caso specifico dei miei alunni, molti elementi sono stati approfonditi in laboratorio con Cisco Packet Tracer (trovate molti esempi qui), ripresi e svisceratati ulteriormente nelle lezioni frontali. La parte difficoltosa potrebbe essere quella di una esposizione ordinata e particolareggiata.
 
Proviamo a fare delle considerazioni iniziali in base alle specifiche fornite dal testo dell'esercizio. La maggior parte delle attività vengono svolte su un software la cui logica principale è all'interno all'azienda. Il software in questione deve essere utilizzabile da tre tipologie di utenti: sia dal personale interno che utilizza presumibilmente postazioni fisse, sia i tecnici che si muovono dai clienti quindi con dispositivi portatili, sia dai clienti su dispositivi portatili o fissi per le recensioni. A tal proposito si considerino le seguenti rappresentazioni grafiche.
 
 

 

Il sistema software
Partiamo dall'immaginare per il nostro sistema di ticketing un Web Service, la cui definizione data dal World Wide Web Consortium (W3C), è: " un sistema software progettato per supportare l'interoperabilità tra diversi elaboratori su una medesima rete oppure in un contesto distribuito". Di web service e loro architetture ne esistono almeno tre:
  • SOAP (inizialmente acronimo di Simple Object Access Protocol, poi cancellato dal W3C).
  • XML-RPC o JSON-RPC (Remote Procedure Call).
  • REST (REpresentational State Transfer)

Nelle nostre lezioni abbiamo affrontato almeno quest'ultimo REST di cui potete trovare alcuni appunti qui. Senza scomodare troppe definizioni e semplificando, un web service è una applicazione che può permettere di far interagire gli stessi dati e funzionalità su di essi con un sito web convenzionale o con una app per smartphone in modo del tutto trasparente all'utente finale. La base portante è l'uso dello XML che consente lo scambio di informazioni tra linguaggi, piattaforme differenti, sistemi operativi diversi. L'intelligenza lato server può essere svolta da opportuna applicazione con PHP, molto noto agl istudenti o Python che ha forte usabilità anche per applicazioni web. L'interfaccia web la possiamo affidare al classico HTML integrato magari nei sempre più diffusi framework di interfaccia come React o Angular, che forniscono una spinta in più nella gestione, progettazione e sviluppo di web app e web service interattivi e anche gradevoli con svariate librerie di GUI "alla moda". Per i dispositivi dei tecnici, occorrerà realizzare una app  che si integri col sistema progettato. Non si fanno particolari considerazioni se non consigliare di svilupparle con tecnologie all'avanguardia e che permettono una compatibilità con dispositivi e s.o. differenti, vedi il prossimo Android 10 detto Fuchsia. In questo caso quindi si possono realizzare con il framework Flutter e il suo linguaggio Dart o alternativa con linguaggio React Native.

  
L'infrastruttura hardware
Lo schema mostra a destra la sede centrale della InfoService. Non conoscendo la disposizione fisica degli uffici, se ne propone una logica in cui vengono suddivise l'area amministrativa da quella contenente i server. Le due aree possono essere logicamente divise usando indirizzamenti di rete opportuni (ad es. 192.168.10.0/24 e 192.168.20.0/24) legate da un router. Nell'immagine, l'area amministrativa è esemplificata con due dispositivi fissi ma non è difficile immaginare che ci possano essere diversi uffici anche dislocati su più piani con diverso personale all'interno e dispositivi di utilità come stampanti di rete o telefoni anche con tecnologia VoIP. Il collegamento di questi uffici richiede l'uso di più switch per i singoli uffici collegati ad uno switch centrale di piano, con un collegamento di backbone tra i piani fino ad arrivare al router di confine. Può seguire le specifiche del classico "cablaggio strutturato" e delle normative annesse, che non trattiamo in questo quesito ma che gli alunni possono approfondire sui libri di testo. I cablaggi e i dispositivi potrebbero essere scelti con capacità di trasferimento a 1 Ggiabit/sec con cavi UTP/STP di categoria 6 o 7. La zona contenente i server è la classica zona DMZ, possibilmente isolata dagli uffici amministrativi, anche fisicamente su altro edificio per limitare presenze umane non autorizzate o possibili incidenti/guasti. La zona DMZ è spesso dedicata in una stanza separata opportunamente refrigerata per raffreddare i server, con porte tagliafuoco blindate sia per isolare da persone non autorizzate sia per ridurre l'impatto di un eventuale incendio. Nel suo interno possiamo trovare un UPS, gruppo di continuità, che alimenta i server in caso di mancanza di corrente o sbalzi di tensione, per consentirne uno spegnimento sicuro o una continuità di servizio per piccoli intervalli temporali. La zona DMZ può ulteriormente avere un secondo firewall per proteggere e regolare il traffico da e verso la zona amministrativa.

Per i server, caratteristiche standard di interesse potrebbero essere:

  • CPU: 2x Intel Xeon E5 con 6 Cores
  • RAM 32 GB DDR4 con bit di parità per prevenire errori
  • 3 Hard Disk da 3Tera Byte l'uno, in tecnologia non necessariamente SSD ma con piatto rotante/meccanico per contenere i costi. Invece 2 SSD per il sistema operativo in RAID5 per maggiori performance. L'array di 3 HD per lo storage backup  è conveniente metterli con il RAID1 detto "mirroring" per avere una copia di scorta dei dati elaborati dai dischi principali. Il backup può essere perfezionato ulteriormente in un sistema cloud con cui ripristinare in locale eventuali anomalie/malfunzionamenti o una sostituzione degli hd danneggiati con un sistema di rimozione a caldo Hot Swap per la sostituzione
  • Due schede di rete 10 GBit (una ridondante di backup)
  • Doppio alimentatore ridondato
  • Software: in questo caso possiamo ricorrere ad un semplice server Apache con PHP7 sul server web e MySQL con InnoDB sul server Dati.  Alternativa ad Apache è Nginx che si sta diffondendo molto rapidamente e ha svariate funzionalità interessanti anche per il Python e in alcune applicazioni risulta anche più performante di Apache stesso.
  • Sistema Operativo Linux, come Mint, CentOS, Red Hat o Debian, specifiche distribuzioni per server di produzione.

Come visibile dalla figura di massima, server web e dati sono collegati attraverso uno switch Gigabit Ethernet ad un Firewall con capacità di packet filtering e di proxy per bloccare traffico in entrate ed uscita non gradito, escludere visione di siti non consoni, utilizzo di protocolli e software che utilizzano porte anomale diverse da quelle destinate al server web e il database. Il firewall a questo punto può essere collegato ad un router di frontiera, probabilmente collegato ad una rete telefonica tradizionale con una compagnia telefonica che fornisce accesso ADSL in fibra ottica (possibilmente con tecnologia FTTH, Fiber To The Home per avere tutto il cablaggio in fibra e avere prestazioni elevate). In questo caso il servizio non riteniamo sia così complesso ed oneroso da prevedere uso di più server o cluster in load balancing, ne di router ridondati per il balancing del traffico. La soluzione proposta prevede la gestione in house dei server, ma nulla vieta che il servizio sia installato su in sistema cloud/hosting gestito da terze parti per abbattere alcuni costi hardware e sul personale che li deve gestire. Diamo per scontato che  il servizio, essendo gestito dal comune, sia possibile ospitarlo in un opportuno CED che ha già carico di spese di gestione di hardware. Occorre poi stabile una policy per gestire l'affidabilità e continuità del servizio: ad esempio attraverso l'uso di UPS per la fornitura di corrente e protezione dagli sbalzi di tensione, backup periodici degli hd sostituibili comodamente con cassetti hot-swap e salvataggi in cloud o altri sistemi NAS separati fisicamente dalla zona DMZ, prevenzione dei D-DOS e aggiornamento periodico dei software e S.O.

 Per i tecnici, l'azienda può prevedere l'acquisto di tablet di fascia media di profilo prettamente commerciale visto che non ci sono richieste particolari di robustezza e resistenza ad urti o acqua. Caratteristiche tipo possono essere:
  • Schermi luminosi, con buoni angoli di visione e diagonale di 10 pollici
  • Hardware: CPU con tecnologia ARM, come i Cortex o simili di altre case come NvIdia, Intel e RAM di almeno 3 GigaByte. Valutare la predisposizione all'uso di un pennino touch per operazioni di firma o appunti veloci.
  • Autonomia: batterie abbastanza capienti da assicurare autonomie per i lunghi viaggi o sistemi di risparmio energetico particolarmente efficienti
  • Connettività: la connettività Wi-Fi ormai è su tutti i dispositivi e nelle case dove i tecnici operano ma per motivi di privacy potrebbe non essere utilizzabile se non fosse presente una rete Guest su misura. Si consiglia di avere anche un modulo 4G che permetta la connessione alla rete in modo autonomo dei dispositivi sfruttando la convenzionale rete GSM. Non sono richieste particolari prestazioni della piattaforma, quindi sconsigliamo l'acquisto di moduli 5G che al momento in cui scriviamo sono ancora poco diffusi e costosi.
  • Fotocamera: nessuna specifica particolare
  • Software applicativi: i software possono essere delle tipologie più disparate ma devono mantenere un buon bilanciamento fra semplicità, fluidità e numero di funzioni
  • Memoria interna: consigliata 16GByte o 32GB
  • Sistema Operativo: Android 8

Per la zona amministrativa, si prevedono l'uso di normalissimi pc, stampanti di rete e sistemi NAS di rete per la condivisione e backup di documenti. Non sono necessarie particolari accortezze se non quelle di utilizzare piccoli ups per ogni pc o almeno prese di corrente filtrate. I pc di fascia medio/alta potrebbero avere caratteristiche tipo:

  • Hardware: CPU Intel di ottava o nona generazione come I5-8500, con 8GByte di RAM DDR4,
  • Memoria: Hard Disk SSD da 250GB per il sistema operativo e il software principale accompagnato da un HD tradizionale meccanico/magnetico per i dati da 1 TeraByte
  • Sistema operativo: Visto l'utilizzo limitato al semplice uso di browser web per accedere all'applicativo, possiamo risparmiare sulla licenza Windows e installare un s.o. Linux, magari di larga diffusione e semplicità di utilizzo come Ubuntu. Questo ci consentirà anche una maggiore sicurezza e protezione da malware convenzionali, o di dover aggiornare e mantenere periodicamente antivirus vari e loro definizioni.
  • Software: probabilmente basta un browser di quelli convenzionali come Firefox o Chrome, accompagnato da software applicativo da ufficio come Libre Office, suite di programmi di videoscrittura come Word o fogli di calcolo come Excel, ma open source e che sta trovando molto spazio nelle amministrazioni pubbliche (anche nel nostro comune di Teramo!)
  • Monitor: 22 pollici

In entrambi i casi dei tecnici e del personale interno, l'accesso alla piattaforma potrebbe essere effettuato con una classica login con autenticazione a due fattori con password e pin via sms e smartphone o mail o direttamente impronta digitale. Le tecniche qualcosa che so/qualcosa che ho devono poi essere accompagnate da una connessione con protocollo HTTPS, la versione sicura del protocollo HTTP basata su tecnologia SSL/TLS che garantisce la riservatezza dello scambio di dati anche sensibili tra i client/server. Per gli utenti è già citato nel testo dell'esercizio l'obbligo di un account e relativa registrazione nel sistema, ovviamente garantendo il salvataggio delle password attraverso impronta SHA2 o SHA3. Nell'account può comparire una notifica di intervento effettuato dal tecnico con relativa possibilità di accedere ad una pagina per commentare e fornire un feedback dell'intervento. Notifica analoga può essere inviata alla mail registrata dall'utente. Ovviamente in fase di registrazione, gli utenti devono essere informati del trattamento delle informazioni e dati personali con opportuno testo del GDPR, contenente il nominativo di un responsabile del trattamento e come verranno utilizzati i dati, i cookies tecnici e di terze parti.

 

SECONDA PARTE
I. In relazione al tema proposto nella prima parte, si consideri che solo i dirigenti di InfoService possano monitorare l’attività del personale tecnico che effettua interventi di assistenza. Il candidato, dopo aver apportato le opportune modifiche al database sviluppato nella prima parte, progetti l’architettura di massima delle pagine necessarie ad implementare la funzione sul portale web del sistema di ticketing. Codifichi poi in un linguaggio a sua scelta le pagine che consentono al solo personale dirigente di visualizzare le statistiche relative agli interventi di assistenza (come ad es. la seconda query del punto 3 della prima parte).
 
La domanda è a cavallo tra le discipline Informatica (per la porzione del database citato), Sistemi e Reti e Tecnologie e progettazione di Sistemi Informatici (per la progettazione di UI/UX). Cerchiamo di dare una idea di massima delle funzioni del portale web di ticketing con un diagramma UML dei casi d'uso come elemento progettuale, dato che la progettazione di interfacce grafiche non viene approfondita in modo esaustivo generalmente nei corsi scolastici, se non con buone pratiche. Ogni caso d'uso può, semplificando, essere esposto come pagina web opportuna. Il grafico è realizzato con https://www.draw.io/
 
 
Per il nostro codice facciamo riferimento a query sulla tabella Ticket. Evitando la trattazione del modello E/R prevista dalla prima parte della traccia, per brevità, forniamo una possibile struttura della tabella Ticket, con chiavi esterne verso le tabelle Cliente e Tecnico. Il codice SQL per crearla è quindi il seguente:
--
-- Struttura della tabella `Ticket`
--
CREATE TABLE `Ticket` (
  `ID` int(11) NOT NULL,
  `ID_Cliente` int(11) NOT NULL,
  `ID_Tecnico` int(11) NOT NULL,
  `Apertura` datetime NOT NULL,
  `Chiusura` datetime NOT NULL,
  `Stato` varchar(20) NOT NULL,
  `Nome` varchar(30) NOT NULL,
  `Descrizione` varchar(120) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

--
-- Indici per le tabelle `Ticket`
--
ALTER TABLE `Ticket`
  ADD PRIMARY KEY (`ID`),
  ADD KEY `Cliente` (`ID_Cliente`),
  ADD KEY `Tecnico` (`ID_Tecnico`),
  ADD KEY `Stato` (`Stato`);

--
-- AUTO_INCREMENT per la tabella `Ticket`
--
ALTER TABLE `Ticket`
  MODIFY `ID` int(11) NOT NULL AUTO_INCREMENT;

--
-- Limiti per la tabella `Ticket`
--
ALTER TABLE `Ticket`
  ADD CONSTRAINT `Cliente` FOREIGN KEY (`ID_Cliente`) REFERENCES `Cliente` (`ID`) ON DELETE RESTRICT ON UPDATE RESTRICT,
  ADD CONSTRAINT `Tecnico` FOREIGN KEY (`ID_Tecnico`) REFERENCES `Tecnico` (`ID`) ON DELETE RESTRICT ON UPDATE RESTRICT;
  ADD CONSTRAINT `Tecnico` FOREIGN KEY (`ID_Tecnico`) REFERENCES `Tecnico` (`ID`) ON DELETE RESTRICT ON UPDATE RESTRICT;
COMMIT;

Possiamo così procedere alla realizzazione della query che ci interessa per l'esempio che è proprio quella suggerita dall'esercizio. Lo studente, in queste circostanze, può anche scegliere una query differente se non viene imposto dal testo dell'esercizio, anche una banale se si fosse in difficoltà con una semplice select * from tabella, per aggirare l'ostacolo. Nel nostro caso avremmo: 

SELECT AVG(Ticket.Chiusura - Ticket.Apertura) 
FROM `Ticket` 
WHERE Ticket.Stato = 'Chiuso' 
   && Ticket.Chiusura <= [chiusura]
   && Ticket.Apertura >= [apertura];

Forti di questa struttura e query, procediamo a realizzare la pagina richiesta. Per brevità, creiamo form e script di elaborazione tutto in un unico file.

<!DOCTYPE html>
<html lang="it">
	<head>
		<title>Statistiche ticket</title>
	</head>
<body>
<h1>Statistiche</h1>
<form method="post" action="statistiche.php">
	<fieldset>
	<legend>Scegli date</legend>
		<label for="DateFrom">Da: </label><input type="date" id="DateFrom" name="DateFrom"> 
		<label for="DateTo"> A: </label><input type="date" id="DateTo" name="DateTo"> <input type="submit" value="Cerca" >

	</fieldset>
</form>
<br>

<?php 
require_once("config.php");
if (isset($_POST['DateFrom']) && isset($_POST['DateTo']))
{
	$connessione = mysqli_connect($mysql_host,$mysql_user,$mysql_pass,$mysql_db);
	if (mysqli_connect_errno())
	  die("Connessione non riuscita: " . mysqli_error($connessione));

	$datefrom = mysqli_real_escape_string($connessione, stripcslashes(trim($_POST['DateFrom'])));
	$dateto   = mysqli_real_escape_string($connessione, stripcslashes(trim($_POST['DateTo'])));

	//"SELECT AVG(TIME_TO_SEC(TIMEDIFF(Ticket.Chiusura,Ticket.Apertura))) as media
	$query = "SELECT AVG(Ticket.Chiusura - Ticket.Apertura) as media
	          FROM Ticket 
			  WHERE Ticket.Stato = 'Chiuso'
				 AND Ticket.Chiusura <= '$dateto' 
				 AND Ticket.Apertura >= '$datefrom'";
 	$res = mysqli_query($connessione,$query) or die("Errore nella login: " . mysqli_error($connessione));
	$row = mysqli_fetch_assoc($res);
	$avg = $row['media'] / 1000000;
	mysqli_close($connessione);

	echo "<b>Media Ticket tra $datefrom - $dateto:</b> $avg giorni";
}

?>
</body>	
</html>

 Nel codice è anche annotata, ma commentata, un'altra versione di media e differenza date usando le funzioni standard di MySQL, ma sono piuttosto farraginose da ricordare e difficilmente sono utilizzate nelle esercitazioni scolastiche. Lo script è piuttosto semplice e privo di fronzoli: porzione di form HTML, gestione dei dati in ingresso con le variabili supeglobali $_POST e le varie funzioni per prevenire SQL Injection, connessione al db, la query e la gestione della risposta col solito array associativo di ritorno. Si noti come spesso sia utile la ridenominazione con AS delle funzioni di aggregazione SQL come AVG o SUM per semplificare la gestione del risultato. Il risultato, forse meno noto agli alunni, è tornato sotto forma di timestamp che va semplificato.

 

  
 
II. In relazione al tema proposto nella prima parte, il candidato definisca il piano di indirizzamento della rete interna della sede principale di InfoService e le modalità con le quali viene controllato l’accesso di dispositivi wifi alla stessa. Approfondisca quindi i fattori che consentono di garantire la continuità del servizio dettagliando le risorse hardware e i servizi software che ritiene idonei per il caso in questione.
 
Nella rete interna abbiamo individuato due aree: la DMZ con i server e l'area amministrativa. In virtù del numero di utenti, possiamo suddividere le due aree in modo logico con due reti ad es. 192.168.10.0/24 per la DMZ e 192.168.20.0/24 per la zona Amministrativa. I server avranno IP impostati in modo statico ad es  192.168.10.10/24, 192.168.10.20/24, 192.168.10.30/24 con la bocca del router impostata come Gateway 192.168.10.1/24. Per la rete amministrativa, possiamo ipotizzare l'uso di un servizio DHCP, magari erogato dal Router e la bocca della rete in questione che possiamo impostare come gateway a 192.168.20.1/24. Il resto della rete potrebbe cominciare col DHCP configurato da 192.168.20.100 in poi con un numero di dispositivi limitato a 50. La presenza di una rete wireless potrebeb essere integrata aggiungendo una interfaccia al router collegata in cascata ad uno switch che serve uno o più access point. La rete wireless è sempre bene separarla magari con una rete 192.168.30.0/24 sempre configurata con opportuno DHCP. L'access point potrebbe essere dotato di una lista filtro di MAC address per autorizzare solo determinati dispositivi. Sappiamo in realtà che gli indirizzi MAC, anche se fisicamente marchiati sul dispositivo di rete, possono essere dissimulati con relativa facilità. Ecco perché la rete deve essere necessariamente protetta da WPA2 o WPA3 con password condivisa. Se la wifi è prettamente aziendale, potrebbe essere opportuno utilizzare un server RADIUS per autenticare individualmente gli utenti ed identificare quindi anche traffico anomalo o eventuali responsabilità di manomissioni sulla rete in determinati istanti. Il RADIUS è spesso utilizzato col WPA2 in modalità Enterpreise meglio noto come WPA-802.1X. Sistema perfetto per le reti Guest/Ospite potrebbe essere l'uso di un Captive Portal che integra anche funzioni RADIUS per l'autenticazione semplificata degli utenti. La continuità del servizio, tralasciando le considerazioni fatte sui server, richiede di studiare i punti deboli della nostra infrastruttura. Questo però va fatto in funzione anche delle risorse economiche della azienda. Punto debole è sicuramente il router di confine. Questo potrebbe essere raddoppiato mantenendo una sola linea oppure raddoppiando anche le linee adsl per avere sempre una linea di riserva o per bilanciare il carico in situazioni normali con un Load Balancing opportuno attraverso server come Linux LVS. Ben più economico è raddoppiare gli switch di piano o che servono uffici. Per quanto riguarda i server, l'alunno può riadattare le medesime cose dette in fase di progetto del punto 1 (raid, ridondanza ecc)
 
  
 
III. Lo sviluppo della rete Internet e l’incremento esponenziale del numero di dispositivi che si prevede verranno ad essa connessi, anche in conseguenza del forte impulso dato in tal senso dall’internet delle cose (IoT), sta favorendo la diffusione del protocollo IPv6. Si espongano le caratteristiche del suddetto protocollo e le differenze rispetto al protocollo IPv4.
 
L'argomento è molto interessante soprattutto perché, solitamente per i programmi sviluppati dai libri di testo più diffusi, viene affrontato nel quarto anno di un istituto tecnico tecnologico informatica. IPv6 è uno versione di IP disponibile dal lontano 2004 e, si presume, sostituirà definitivamente la versione 4 entro il 2025. La necessità di questa miglioria deriva essenzialmente per risolvere la critica carenza di indirizzi IP. Non è difficile contare come gli IPv4 in totale siano 2554, un numero che , anche non volendo considerare gli IP provati e quelli riservati, arriva a circa 4 miliardi. E' abbastanza intuitivo osservare che ognuno di noi ha svariati dispositivi personali connessi alla rete internet h24  Se a questo aggiungiamo uno spreco generale tra indirizzi assegnati ma non realmente utilizzati per svariati motivi, possiamo immaginare cosa accadrà quando avremo in casa decine di dispositivi connessi quali luci, elettrodomestici, oppure dei semafori intelligenti alla cartellonistica smart per strada che necessiteranno di indirizzi IP in quantità decisamente superiore a quelli disponibili. L'IP v6 utilizza invece dei 32 bit dell'IP v4, ben 128 bit passando da da un ordine di grandezza di 109 a 1038, che risolve in modo definitivo il problema del consumo ed anche della frammentazione nell'assegnazione di blocchi di indirizzi ai singoli operatori telefonici. Gli indirizzi IPv6 sono composti di 128 bit e sono rappresentati come 8 gruppi, separati da due punti, di 4 cifre esadecimali come ad esempio 2003:0db7:85a3:0000:2329:8a2e:0361:734. Il pacchetto IP v6 ha inoltre delle differenze e migliorie rispetto al fratello maggiore v4 come l'eliminazione del checksum già presente nei livelli superiori e un campo Traffic Class che permetterà di gestire QoS (Qualità del Servizio) direttamente col pacchetto IP senza dover ricorrere ad altre strategie o VPN Trusted. Il passaggio da IPv4 a 6 è gia in corso sotto i nostri occhi. Molti dispositivi in commercio già supportano la nuova versione, la cui transizione, non è agevole e richiederà di aggiornare dispositivi fisici, schede, router e server DNS. IPv4 dovrebbe andare in pensione nel 2025 secondo la road-map dell'ICANN. 
 
  
 
IV. Nell’interazione con un’applicazione web dinamica, l’utente compie azioni che richiedono l’invio di dati al server. Il candidato esamini i metodi attraverso cui è possibile trasferire al server i dati generati lato client dall’utente durante l’uso dell’applicazione, evidenziandone le specificità e i differenti usi. Fornisca al riguardo esempi di casi di utilizzo per le differenti modalità.
 
Il tema è ampiamente trattato durante il corso di Sistemi e Reti della classe conclusiva e del quarto anno. In particolare, uno dei modi visti per trasferire dati ad un server è quello della comunicazione Socket. Questa procedura agisce a quarto livello TCP/UDP della pila ISO/OSI. Trovate un esempio già sviluppato in questo articolo del nostro sito qui. Questo modo risulta molto vantaggioso e performante quando si ha la possibilità di creare e, compilare magari, da zero il software client e server in ascolto che ottimizzano le comunicazioni e scambi odi messaggi. Molti servizi però sono più orientati al web e nascono al livello 6 e 7 della pila ISO/OSI esplicitamente come servizi. Qui il server ospita un software Apache o NGIX o IIS che va a parsificare ed eseguire uno script di codice PHP, CGI, ASP. A questi script le informazioni possono essere passate attraverso i metodi POST e GET delle classiche form HTML o degli URI della barra del browser. Il server con il suo script PHP può sempre reperire i dati con le variabili $_GET['qualcosa'] o $_POST['qualcosa'] ed utilizzarle per il flusso software di interesse.
Pecca dell'invio con POST e GET è la necessità tecnica di caricare una nuova pagina (a anche la stessa in alcuni casi), interropendo il flusso software ed obbligando l'utente ad una attesa del nuovo caricamento. Nei software che usiamo sui nostri pc o smartphone siamo abituati ad un flusso continuo ed una interattività maggiore che vogliamo anche sui nostri applicativi online. Qui ci viene incontro l'AJAX, acronimo di Asynchronous JavaScript and XML, è una tecnica di sviluppo software per la realizzazione di applicazioni web interattive (Rich Internet Application). Lo sviluppo di applicazioni HTML con AJAX si basa su uno scambio di dati in background fra browser e server, che consente l'aggiornamento dinamico di una pagina web senza ricaricamento da parte dell'utente o una qualsivoglia interruzione del flusso dell'esperienza utente. Un esempio di utilizzo di AJAX lo potete trovare anche su questo sito a questo link. Parte fondamentale della tecnologia AJAX sono XML e JSON, utili a mandare al server dati più complessi di una semplice stringa di testo, ad esempio nella trasmissione del contenuto di una query articolata in più campi.
 
 

Stampa