Messaggi volatili. Matteo Zignani. 10 gennaio 2015

Transcript

1 UNIVESITÁ DEGLI STUDI DI MILANO LAUREA TRIENNALE IN COMUNICAZIONE DIGITALE PROGETTO LABORATORIO DI RETI DI CALCOLATORI Messaggi volatili Matteo Zignani 10 gennaio PRESENTAZIONE DEL PROBLEMA Lo studente deve sviluppare un servizio di messaggistica che limita l invio e la ricezione dei messaggi solo agli utenti che appartengono alla cerchia degli amici del mittente. Ogni messaggio, inoltre, è caratterizzato da una data di scadenza che ne limita il ciclo di vita. Scaduto il messaggio, questo viene cancellato e non è più disponibile per la sua visualizzazione. Il servizio che lo studente deve implementare si basa su un architettura client/server. Il server deve gestire la rete sociale tra gli utenti iscritti e rendere disponibili alcune risorse per l invio dei messaggi. A tal fine, il server mette a disposizione diverse risorse richiedibili utilizzando il protocollo HTTP che permettono la creazione di utenti e di relazioni d amicizia, l invio e la ricezione dei messaggi. Lo studente deve sviluppare solamente la parte server dell architettura descritta. Per quanto riguarda il client si possono utilizzare per la fase di test: telnet (Linux e Mac) oppure putty (Windows). Le funzionalità verranno testate dal docente con questi due strumenti. Il server DEVE essere MULTITHREAD; di consequenza come meccanismi di getstione dei thread sono ammessi sia thread-pool sia... 2 API Nelle seguenti sottosezioni vengono descritti le componenti del server e le risorse che esso mette a disposizione. Gli esempi presentati di seguito sono da considerarsi come tali, pertanto nella costruzione delle richieste e delle risposte HTTP ci si deve rifare alla sintassi HTTP presentata nel libro di testo. 1

2 2.1 FORMATO DELLA RICHIESTA Il server riconosce come valide le richieste che seguono il protocollo HTTP. In particolare il server riconosce solo richieste con metodo di accesso di tipo GET. Per questo motivo lo studente NON deve implementare tutti i metodi di accesso HTTP ma solo un piccolo sottoinsieme. Un esempio di possibile richiesta valida può essere: GET <URL Risorsa con eventuali parametri> HTTP/1.0 Il server deve verificare la validità della riga di intestazione e ignorare tutti i campi settati nella definizione dell header, tranne nel caso in cui si esplicitamente menzionato il contrario nella descrizione della risorsa. Una volta rilevata la stringa vuota di terminazione della richiesta, il server deve eseguire l operazione richiesta dall URL e rispondere secondo il formato HTTP. Si noti che l URL della riga di intestazione della richiesta deve seguire la sintassi specifica di un URL (vedi slide corso). Se la richiesta è andata a buon fine, il formato della risposta è: <messaggio> dove < messag g io > è un messaggio testuale che dipende dalla risorsa invocata. In caso di errore il formato della risposta sarà: HTTP/ ERRORE <messaggio> Anche in questo caso < messag g io > contiene un messaggio di errore dipendente dalla risorsa invocata. Vincoli imposti sulle richieste: Tutte le seguenti risorse, parametri e valori sono case-sensitive. L ordine dei parametri nella richiesta non ha importanza. I field name nell header HTTP NON sono case-sensitive. 2.2 CREAZIONE DI UN NUOVO UTENTE Al momento dell avvio il server non contiene alcun utente. Per inserire un nuovo utente, il server mette a disposizione la risorsa ag g iung iutente. Tale risorsa accetta come unico parametro valido idutente, che indica il nome dell utente che si vuole inserire. Un possibile esempio di richiesta valida è: 2

3 GET /aggiungiutente?idutente=mario HTTP/1.0 Utente mario inserito con successo. Possibili errori da gestire sono l inserimento di un utente già esistente. 2.3 AGGIUNGERE UNA RELAZIONE DI AMICIZIA Un utente può aggiungere un amico alla sua cerchia utilizzando la risorsa ag g iung i Amico. La risorsa aggiungiamico accetta come unici parametri validi idutente e id Amico, il primo indica l utente che vuole creare l amicizia, mentre il secondo indica il nome (stringa) dell utente verso cui creare una relazione di amicizia. Non è necessario che l utente destinatario della richiesta accetti la creazione della relazione. Un possibile esempio di richiesta valida è il seguente: GET /aggiungiamico?idamico=ambrogio&idutente=mario HTTP/1.0 Amicizia con ambrogio creata con successo Possibili errori da gestire sono l assenza del nodo di destinazione/sorgente della richiesta o la richiesta di creazione di una relazione che già esiste. 2.4 LISTA DEGLI AMICI Un utente può visualizzare i propri amici utilizzando la risorsa vedi Amici. La risorsa necessita dell argomento i du t ent e: l utente che richiede la lista degli amici. Nel corpo della risposta, ved i Ami ci restituisce serie di righe, ognuna delle quali contenente lo username dell amico. Ogni riga rispetta il formato: idutente :< nomeutente > Si noti la presenza dei doppi apici prima e dopo la stringa idutente. Un possibile esempio di richiesta valida è il seguente: 3

4 GET /vediamici?idutente=mario HTTP/1.0 "idutente": ambrogio "idutente": michele "idutente": marco Possibili errori sono costituiti dall errata sintassi della risorsa oppure da un nome utente non esistente. Un secondo insieme delle risorse disponibili riguarda l invio e la ricezione dei messaggi temporizzati. I messaggi possono essere inviati solo ad amici. Conseguentemente le eventuali risposte ad un messaggio possono essere inviate solo agli amici. Ogni messaggio (nuovo o risposta) è caratterizzato da un identificatore univoco all interno del servizio. L identificatore del messaggio è contenuto del campo id m es. Ad ogni messaggio è associata una data di creazione e una durata. La data di creazione è relativa al momento dell inserimento del messaggio sul server, mentre la durata indica dopo quanti secondi dalla data di creazione il messaggio deve essere cancellato dal server. Per esempio se l utente A invia al suo amico B il messaggio Ciao alle ore 12:00 del 23/12/2014 con durata 30 sec, il server memorizza il messaggio con data di creazione uguale a 23/12/ :00:23 (data di inserimento del messaggio nel server) e dovrà cancellare il messaggio alle ore 12:00:53 del 23/12/ INVIO DI UN MESSAGGIO La risorsa invi a permette ad un utente di inviare un messaggio ad un amico specificandone la durata. La risorsa richiede tre parametri: idutente: lo username dell utente che vuole inviare un messaggio id Amico: lo username dell amico a cui si vuole inviare un messaggio text: il testo del messaggio. Si assuma che il testo sia codificato secondo le specifiche URL (vedi slide corso e classe StringQuery) dur at a: la durata in secondi del messaggio L invio del messaggio comporta l inserimento del messaggio stesso nel server. Ad ogni messaggio inserito è associato un identificatore univoco all interno del servizio. L identificatore del messaggio viene restituito nel messaggio di risposta del server. La risposta non segue 4

5 un formato specifico ma deve obbligatoriamente contenere un indicazione del valore dell identificatore. Il campo id Amico accetta un solo destinatario, quindi non è ammesso l invio multiplo. Per inviare lo stesso testo a più utenti si deve invocare la stessa risorsa mantenendo il testo e modificando il destinatario. Un possibile esempio di richiesta valida è il seguente: GET /invia?idutente=mario&idamico=michele&text=ciao+da+mario&durata=30 HTTP/1.0 id_mes: 10 Possibili errori possono essere causati dalla mancata presenza degli utenti, da un valore non naturale assegnato al campo durata oppure dalla mancata relazione di amicizia tra mittente e destinatario VISUALIZZAZIONE MESSAGGI RICEVUTI La risorsa vedi Messag g i permette ad un utente di vedere tutti i messaggi non scaduti inviatigli. La risorsa prevede un solo parametro denominato i du t ent e, indicante l utente che vuole interrogare la risorsa. La risposta generata da vedi Messag g i è costituita una serie di righe, ognuna delle quali corrisponde ad un messaggio. Ogni riga segue il seguente formato: id_mes:<id_msg>&from:<nome_utente>&testo:<testo_msg>&ttl:<secondi_mancanti> dove il campo t tl indica quanti secondi rimangono prima della scadenza del messaggio sul server. Un possibile esempio di richiesta valida è il seguente: GET /vedimessaggi?idutente=mario HTTP/1.0 id_mes:1&from:ambrogio&testo:come+stai&ttl:40 id_mes:5&from:aldo&testo:pizza+alle+10&ttl:45 id_mes:7&from:giovanni&testo:questo+%c3%a9+matto&ttl:45 id_mes:10&from:giuseppa&testo:ti+amo+tanto&ttl:33 Possibili errori possono essere dovuti all assenza di idutente nella rete sociale. 5

6 2.4.3 SEGNALA COME SPAM La seguente risorsa deve essere implementata anche da coloro che sono risultati insufficienti nel primo progetto di Febbraio. Un utente può segnalare un messaggio come spam attraverso la risorsa seg nal aspam. La risorsa riceve due parametri: idmessag io: identificatore del messaggio segnalato come spam idutente: username dell utente che il messaggio come spam. La risorsa elimina il messaggio dall insieme dei messaggi ricevuti dall utente i du t ent e. Il seguente vincolo deve essere implementato solo da chi consegna per la prima volta il progetto di Febbraio: se un utente segnala più di 3 messaggi inviati dallo stesso amico come spam, il server elimina la relazione di amicizia. Un possibile esempio di segnalazione di spam è dato dalla seguente richiesta: GET /segnalaspam?idutente=mario&idmessaggio=10 HTTP/1.0 host: localhost:8000 id_mes 10 segnalato come spam 3 MODALITÀ DI CONSEGNA Il progetto è individuale e verranno presi provvedimenti nel caso ci sia il sospetto di una eventuale copiatura. In particolare non verranno ammessi alla discussione del progetto e quindi saranno automaticamente esclusi dall appello quei progetti con almeno un file con indice di similarità superiore al 70% (moss, tool di Stanford). Questo per non incentivare progetti scritti singolarmente ma frutto di brain-storming troppo di gruppo. Il linguaggio da utilizzare per lo sviluppo è Java. Il codice del progetto e i relativi jar delle librerie utilizzate devono essere inviati al docente in una directory compressa (zip o tar.gz) denominata progettofebbraio La mail deve avere come oggetto ProgettoFebbraio e contenere nel corpo nome, cognome e numero di matricola dello studente. Il materiale deve essere consegnato entro le 23:59.59 del 10 febbraio Valgono tassativamente le seguenti regole: Il codice che non compila non verrà considerato I progetti consegnati dopo la data di consegna non saranno ritenuti validi Eventuali errori sintattici riscontrati nell implementazione del protocollo HTTP rendono il progetto insufficiente. 6

7 Per essere considerato sufficiente e quindi ammissibile per la discussione, il progetto deve implementare correttamente tutte le funzioni precedentemente illustrate. Principali criteri di valutazione del codice: Gestione di possibili errori nell input da parte dell utente Modularità del codice e rispetto del paradigma ad oggetti Gestione oculata delle eccezioni Uso appropriato dei commenti Gestione e risoluzione di eventuali problematiche legate alla concorrenza sia lato client sia lato server Per chiarimenti, dubbi potete contattare il docente all indirizzo matteo.zignani@unimi.it, specificando come oggetto obbligatorio ProgettoReti. Eventuali modifiche al testo del progetto saranno comunicate sulla pagina web del corso. 7