Influenza da browser

Transcript

1 UNIVESITÁ DEGLI STUDI DI MILANO LAUREA TRIENNALE IN COMUNICAZIONE DIGITALE PROGETTO LABORATORIO DI RETI DI CALCOLATORI Influenza da browser Matteo Zignani 15 giugno PRESENTAZIONE DEL PROBLEMA In questo progetto lo studente deve gestire un meccanismo di social pressure che sfrutta le statistiche d uso dei browser utilizzati dagli utenti per effettuare le richieste al servizio. In particolare ogni utente ha la possibilità di influenzare lo stato di un altro utente secondo un meccanismo che sfrutta i browser utilizzati dagli amici dall influenzante e dagli amici dell utente influenzabile. 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 offrire dei servizi per gestire la social pressure. A tal fine, il server mette a disposizione diverse risorse richiedibili utilizzando il protocollo HTTP. Lo studente deve sviluppare solamente la parte server dell architettura descritta. Per quanto riguarda il client si consiglia di utilizzare telnet (Linux e Mac) oppure putty (Windows) in quanto permettono di modificare facilmente il campo user-agent nell header della richiesta HTTP. Le funzionalità verranno testate dal docente con questi due strumenti. Il server DEVE essere MULTITHREAD. 2 API Nelle seguenti sottosezioni verranno descritte 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, per esempio, 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 un server HTTP completo ma un suo 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 ad eccezione del campo user-agent. 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 conta. Ogni richiesta effettuata deve contenere obbligatoriamente il campo user-agent nell header HTTP. Dove specificato le risposte restituite sono in formato JSON. Risposte che non soddisfano il formato specificato rendono il progetto insufficiente. 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 nomeutente, che indica il nome dell utente che si vuole inserire. Al 2

3 momento della creazione dell utente viene inizializzato un contatore che memorizzerà il numero di richieste effettuate da ogni browser utilizzato dall utente nomeu t ent e. Un possibile esempio di richiesta valida è: GET /aggiungiutente?nomeutente=mario HTTP/1.0 Utente mario inserito con successo. Browser: Mozilla 5.0 A seguito della precedente richiesta viene inizializzato un contatore e il valore associato al browser Mozilla 5.0 sarà 1. Possibili errori da gestire sono l inserimento di un utente già esistente oppure la mancanza del campo user-agent. 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 nomeu t ent e e nome Ami co, 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. La relazione di amicizia è bidirezionale, mentre la risorsa non necessita che l utente destinatario della richiesta accetti la creazione. Un possibile esempio di richiesta valida è il seguente: GET /aggiungiamico?nomeamico=ambrogio&nomeutente=mario HTTP/1.0 Amicizia con ambrogio creata con successo Possibili errori da gestire sono l assenza del nodo di destinazione/sorgente della richiesta, la richiesta di creazione di una relazione che già esiste oppure la mancanza del campo useragent. 2.4 LISTA DEGLI AMICI Un utente può visualizzare i propri amici utilizzando la risorsa vedi Amici. La risorsa necessita dell argomento nomeu t ent e: l utente che richiede la lista degli amici. Nel corpo della risposta, ved i Ami ci restituisce un array JSON contenente una serie di oggetti JSON che rappresentano gli amici. Ogni oggetto JSON è costituito da due campi: idutente contenente il 3

4 nome utente (stringa) dell amico e br ow ser, una stringa indicante il browser più utilizzato dall amico. A tal proposito per ogni utente il server deve tener traccia del numero di richieste suddivise per browser utilizzato (vedi risorsa ag g iung iutente). Un possibile esempio di richiesta valida è il seguente: GET /vediamici?nomeutente=mario HTTP/1.0 [ {"idutente": "ambrogio", "browser": "Chrome"}, {"idutente": "michele", "browser": "Mozilla 5.0"}, {"idutente": "marco", "browser": "Internet Explorer"} ] Nell esempio michele, amico di mario, ho utilizzato prevalentemente Mozilla 5.0 nell effettuare le richieste al server. Possibili errori sono costituiti dall errata sintassi della risorsa, da un nomeutente non esistente oppure dall assenza del campo user-agent. 2.5 INFLUENZARE UN AMICO Un utente può influenzare un amico modificandone le statistiche d uso del browser per mezzo della risorsa in f luenza Amico. La risorsa prevede due parametri validi: nomeutente, nome Amico. Il secondo parametro rappresenta il nome dell amico che nomeutente vuole influenzare. Un utente può modificare le statistiche di uso del browser di un amico se e solo se i browser più utilizzati sono diversi. Quando nomeutente invoca la risorsa riceve m punti di influenza pari al numero di amici di nomeutente che usano più frequentemente lo stesso browser di nomeutente. Sfruttando lo stesso meccanismo nome Amico riceve dai suoi amici d punti di difesa. Se m d > 0 il valore contenuto nel contatore di nome Amico e associato al browser utilizzato da nomeutente viene incrementato di m d. GET /influenzaamico?nomeutente=mario&nomeamico=ambrogio HTTP/1.0 user-agent: Chrome Influenza avvenuta con successo 4

5 2.6 RICERCA DI UTENTI CON LO STESSO BROWSER La seguente risorsa deve essere implementata solo da chi consegna il progetto per il primo appello di Luglio Un utente può cercare utenti con lo stesso browser di più utilizzando usando la risorsa cer cautenti. La risorsa richiede il solo parametro nomeutente e restituisce come risposta un array JSON. Ogni elemento dell array è una stringa contenente il nome dell utente che utilizza più frequentemente un browser dello stesso tipo di nomeu t ent e. Tra gli utenti restituiti non devono essere inseriti gli amici dell utente passato come argomento. Un possibile esempio di richiesta è il seguente: GET /cercautenti?nomeutente=mario HTTP/1.0 [ "ugo","andrea","giovanni" ] Il server deve esser dotato di un meccanismo che ogni 5 min azzera tutte le statistiche d uso dei browser. 2.7 CHIEDI IL BROWSER La seguente risorsa deve essere implementata solo da chi consegna la correzione del progetto consegnato per il primo appello di Luglio 2015 ma valutato insufficiente e da coloro che consegnano per il progetto valido per il secondo appello di Luglio Un utente richiede il browser più utilizzato da un utente attraverso la risorsa chiedibr owser. Tale risorsa richiede il solo parametro nomeutente; l utente su cui eseguire la ricerca. La risorsa cerca su Google la stringa che indica il browser più utilizzato e resituisce nella risposta il contenuto della risposta HTTP inviata da Google. Un possibile esempio di richiesta è il seguente: GET /chiedibrowser?nomeutente=mario HTTP/1.0 <!doctype html><html itemscope="" itemtype=" lang="it" <head><meta content="/images/google_favicon_128.png" itemprop="image"><meta content="origi <title>chrome - Cerca con Google</title> <script>(function(){window.google={kei: 3SF7VcOFK8SuU6vVg-AP,kEXPI: , ,... 5

6 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 progettoluglio2015. La mail deve avere come oggetto ProgettoLuglio2015 e contenere nel corpo nome, cognome e numero di matricola dello studente. Il materiale deve essere consegnato entro le 18:59:59 del 14 luglio 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 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. 6