AMQP Broker
Architettura
L'architettura si basa su piu' protocolli e linguaggi di programmazione nonché su un programma denominato broker per la gestione di messaggi (RabbitMq) e un programma di conversione dei file chiamato ffmpeg. I protocolli utilizzati sono: HTTP, per l'interfaccia web sul server web (SW) messa a disposizione dell'utente per il download e l'upload dei file multimediali; AMQP(Advanced Message Queuing Protocol), per lo scambio di messaggi fra il SW e i server di conversione (SC); RSS per permettere all'utente di accorgersi quando i file convertiti sono disponibili per il download. I linguaggi di programmazione utilizzati sono il php e l'html mentre il broker e' scritto in Erlang. Funzionamento La pagina di upload e' protetta da un sistema di login basato su credenziali salvate in una tabella su un DBMS. Per rendere HTTP statefull e quindi mantenere memoria dei login effettuati dagli utenti, si e' scelto di utilizzare anche un cookie che memorizza la sessione di login di ogni utente per un determinato periodo. Dopo aver effettuato il login, l'utente si ritrova nella pagina contenente la form di upload in cui gli viene chiesto il nome del file e la data. Una volta compilati i campi, all'utente viene chiesto di scegliere il file da caricare dal suo dispositivo. Cliccando su “Upload” avviene l'upload vero e proprio. Il nome e la data vengono salvati in due variabili php con due chiamate POST, il file viene salvato con il nome composto dalla data_nome in una cartella sul SW con un’ulteriore chiamata POST. A questo punto il nome e la data e il path del file vengono incapsulati in un messaggio insieme alla chiave di exchange che identifica a quale server deve essere spedito il messaggio (SC1 o SC2) e il messaggio viene inviato al broker locale (127.0.0.1) che si occupa dell'invio vero e proprio su protocollo AMQP al SC in ascolto e solo a lui. Quando l'SC riceve il messaggio contenente i dati delle variabili, viene attivata una funzione php che legge il path del file in remoto; di conseguenza, si attiva una sessione rsync da SC a SW che copia il file in una directory locale di SC, vengono attivate le conversioni del file nei 3 formati e vengono letti il nome e la data che comporranno i nomi dei file di output con 3 estensioni diverse (.avi .mp3 e .mp4). Quando le conversioni sono terminate si attiva una seconda sessione rsync che ri-sincronizza la cartella locale con la cartella remota, caricando quindi di fatto i 3 file di output sul SW. A questo punto l'RSS avviserà l'utente della comparsa dei tre file e potrà collegarsi alla pagina web per scaricarli.
Applicazione
L'applicazione principale di questo sistema e' attualmente quella di convertire lezioni registrate di corsi universitari, in formati standard che gli studenti possono scaricare, per poter essere visti sia su pc che su dispositivi mobili. La form di inserimento prevede un primo campo data modificabile per garantire all'operatore che sta effettuando l'upload la possibilità di caricare vecchie lezioni; se il campo data non viene valorizzato usa di default la data e l'ora in cui si sta effettuando l'upload. Viene quindi richiesto l'inserimento di un secondo campo materia selezionabile da una lista di nomi separati per corso di insegnamento.
L'insieme di questi due campi forma il nome del file che verra' passato al sistema e utlizzato d'ora in poi per identificare il file. Il formato del nome sara' quindi YYMMDD_materia.estensione. Il sistema e' configurato per gestire le lezioni suddividendole in directory, una per ogni materia. All'interno della directory della materia troveremo altre 3 directory (audio, video, mobile) che conterranno a loro volta i file multimediali prodotti dalla conversione e un file php che genera gli RSS. La sincronizzazione comprende l'intera directory della materia spostando solo i file nuovi. Una volta terminata la conversione e la sincronizzazione della cartella contenete i file prodotti, l'RSS avvisa l'utente della presenza di nuove lezioni disponibili per il download.
Perché AMQP
Il vantaggio di usare un broker di invio messaggi basato su AMQP sta tutta nel fatto che e' un protocollo di gestione di code di messaggi asincrono. Il broker mantiene una coda dei messaggi da inviare agli SC sia quando questi sono of-line, sia quando sono occupati nella conversione di altri file. La caduta di un SC infatti non comporta la perdita del messaggio a lui destinato: il messaggio resterà quindi in coda presso il broker fintanto che il broker non riuscirà a spedire il messaggio.
