Moe: il nuovo sistema di segnalazione delle presenze in auletta

Documentazione Leave a reply

Come avrete notato, di recente è apparso un nuovo strumento sulla barra laterale del nostro sito che mostra chi è presente in auletta. Questo tool è stato pensato per permettere alle persone che necessitano di ricevere assistenza di sapere se c’è qualcuno disponibile ad aiutarlo. Il sistema di notifica è completamente automatizzato e fa parte del progetto del Roma2LUG denominato Moe. Il codice sorgente è distribuito liberamente su GitHub ed è raggiungibile a questo indirizzo. Di seguito vedremo come funziona.

L’idea alla base del progetto è stata quella di sfruttare qualcosa di personale che potesse essere tracciato ogni qualvolta un membro del LUG entrasse in auletta. Il MAC address si è rivelata la scelta migliore: tutti gli smartphone hanno un’interfaccia di rete wireless e per ogni interfaccia c’è un indirizzo MAC univoco che può essere collegato al possessore del telefono. Quando una scheda wireless fa il suo ingresso in una rete, a meno di configurazioni statiche, tenta di negoziare un nuovo indirizzo IP con il server DHCP; questa procedura richiede che il dispositivo invii il proprio MAC address al server e che questo lo associ all’IP che d’ora in avanti lo identificherà fino alla scadenza del lease time.

Il nostro sistema è composto da cinque parti: il server DHCP opportunamente modificato, il sender, il receiver, il database, che contiene la lista di MAC address noti, ed infine il front end in PHP con cui si interfaccia il sito del LUG. Data la natura distribuita del sistema abbiamo optato per dividere il carico tra due macchine, UomoTalpa e Holly, e ridurre il più possibile il lavoro svolto da UomoTalpa che funge già da router per la nostra rete locale. L’immagine che segue mostra la struttura complessiva del sistema.

Moe

Analizziamo le componenti singolarmente.

Server DHCP

Il server DHCP usato per la rete locale della nostra auletta è isc-dhcp-server. Partendo dai sorgenti abbiamo modificato alcune sue funzioni in modo tale da notificare al nostro sistema tutti gli host che chiedono un indirizzo IP: quando viene ricevuta una richiesta DHCP è compito del server prelevare un IP dal proprio pool, notificarlo al richiedente e, se questo lo accetterà, marcare l’indirizzo come “in uso” per un tempo definito dal lease time. Durante quest’ultima fase entra in gioco la nostra modifica al servizio: oltre a registrare il nuovo ingresso nella rete, isc-dhcp-server invoca la componente sender, incaricata di inviare le informazioni sul nuovo ingresso nella rete al receiver.

Sender

Il processo sender richiede due parametri per l’invocazione: un MAC address e il suo lease time espresso in tempo assoluto (istante di tempo in cui scade il lease). Queste due informazioni vengono inviate al receiver attraverso una connessione TCP. Se gli orologi del sender e del receiver non sono sincronizzati potrebbe accadere che, mandando il lease time assoluto, il receiver registri un’informazione errata, per questo è importante utilizzare un tempo relativo (quanti secondi mancano prima della scadenza della validità dell’indirizzo IP) durante la fase di trasmissione del messaggio. Dato che isc-dhcp-server lavora con tempi assoluti, è compito del sender convertire i lease time in tempi relativi prima di inviare il messaggio sulla rete.

Receiver

Il demone receiver resta in ascolto di una connessione TCP su una porta definita staticamente nel codice. Alla richiesta di connessione del sender crea un nuovo thread che riceve dall’host remoto il MAC address e il suo lease time relativo. Dopo aver riportato il tempo ad un’informazione assoluta, viene fatta una query sul database, dove viene aggiornata la voce relativa al MAC address, sostituendo il suo ultimo lease time registrato con il nuovo valore appena ricevuto.

Database

Il database che abbiamo utilizzato è di tipo sqlite, perché è semplice, leggero ed è facilmente integrabile con un gran numero di linguaggi di programmazione. Per i nostri scopi è bastata una tabella composta da triple <MAC, Nome della persona, Scadenza lease>, con MAC come chiave primaria; questa ultima specifica permette di associare ad ogni nome, non essendo chiave univoca della tabella, più MAC Address, in modo da aumentare l’efficacia del meccanismo.

Front end

L’unica parte esposta all’esterno è il web server che, quando interrogato, risponde con una pagina codificata in json contenente l’elenco delle persone presenti in auletta al momento della richiesta. Per determinare se un membro del LUG è presente o meno si verifica che ci sia almeno un lease, associato ad uno dei suoi MAC address, che non sia ancora scaduto. Tutto questo viene fatto da una pagina PHP che recupera dal database i nomi e i lease time dei suoi MAC e filtra tutte le tuple scadute.

Il widget finale

Per concludere la catena di eventi, quando un utente apre la home page di questo sito, viene caricato nella sidebar un widget con del codice PHP. Questo invia una richiesta al web server dell’auletta ricevendo la pagina json, la decodifica e pubblica la lista dei presenti. Se non c’è nessuno, viene mostrato un messaggio alternativo che invita l’utente a prenotarsi per un’assistenza.

Note conclusive

L’architettura che è stata esposta in questo articolo è derivata da una serie di ottimizzazioni e riflessioni che sono state fatte in fase di progettazione. La soluzione proposta è economica dal punto di vista prestazionale perché ogni componente viene richiamata solo quando si verifica un evento esterno: ad esempio un nuovo dispositivo connesso nella rete locale porta ad aggiornare il database, mentre una connessione al nostro sito provoca un accesso al web server e quindi al database. Di contro, però, è soggetta a periodi di inconsistenza che dipendono dalla lunghezza del lease time scelto per il server DHCP. Può accadere che un membro entri in auletta ed esca subito dopo; nel database verrà registrato l’ingresso, ma non l’uscita. Quindi, finché il lease non scade, quella persona risulterà presente. Da questo ne consegue che riducendo il massimo lease time offerto dal DHCP si riduce il tempo di inconsistenza delle informazioni, a costo di un maggior numero di richieste DHCP che transitano nella rete locale. Abbiamo visto empiricamente che un valore ottimale per il tempo di lease si attesta sui 300 secondi, che vuol dire un periodo massimo di inconsistenza delle informazioni di 5 minuti. Un valore più che accettabile. Ma cosa accade se il lease time scadesse prima dell’uscita di un membro? Il problema è risolto direttamente dal protocollo DHCP che prevede una nuova negoziazione dell’IP prima della sua scadenza.

Come si vede dal nostro sito, il progetto è già attivo e funzionante. Chiunque voglia approfondire l’argomento è invitato a scaricare il codice sorgente e a contattarci, tramite i nostri canali di comunicazione, per dubbi, suggerimenti o altro.

Vi lasciamo, infine, con il video che è stato di ispirazione per il nome di questo progetto.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *