Progetto Gennaio 2018 - Reti di Calcolatori
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
U NIVESITÁ DEGLI S TUDI DI M ILANO L AUREA T RIENNALE IN C OMUNICAZIONE D IGITALE P ROGETTO L ABORATORIO DI R ETI DI C ALCOLATORI Progetto Gennaio 2018 04 dicembre 2017 1 P RESENTAZIONE DEL PROBLEMA In alcuni casi il lascito del Natale è costituito da un insieme di regali indesiderati. Questo fenomeno è la fortuna di molti siti di aste online, che dopo le festività vedono incrementa- re il numero di oggetti messi all’asta in attesa che qualche cliente faccia un’offerta. Questo sistema delle aste ha un piccolo difetto, specialmente in queste occasioni: può capitare che un nostro amico tenti di acquistare un oggetto che lui stesso ci ha regalato. Il progetto che lo studente deve sviluppare tenta di risolvere questo inconveniente. In particolare il servizio da implementare prevede che un utente iscritto possa vendere un oggetto e garantisce che l’oggetto non possa essere visualizzato e acquistato da uno dei suoi amici. Il servizio, quindi, deve gestire gli utenti connessi e la compravendita degli oggetti. Alla base dell’architettura client/server su cui si fonda il progetto, abbiamo una rete sociale rappresentante le relazioni di amicizia tra gli utenti iscritti. In generale il servizio permette di vendere e acquistare oggetti senza offendere i nostri amici. L’erogazione del servizio è garantita e gestita da una serie di API che il servizio stesso mette a disposizione. Le API e le modalità di richiesta delle stesse saranno descritte nella sezione successiva. Lo studente deve sviluppare solamente la parte server dell’architettura descritta. Per quan-to riguarda il client, si possono utilizzare per la fase di test: telnet (Linux e Mac), putty (Win-dows). Le funzionalità verranno testate dal docente con questi due strumenti. Il server DEVE essere MULTITHREAD. 1
2 API Nelle seguenti sottosezioni vengono descritti il formato delle API e le risorse offerte dal server inerenti la gestione della social network e della compravendita di oggetti. 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 sul libro di testo. 2.1 F ORMATO 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 stu- dente NON deve implementare un server HTTP completo ma un suo piccolo sottoinsieme. Un esempio di possibile richiesta valida può essere: GET HTTP/1.0 user-agent: Mozilla 5.0, Chrome, Safari host: localhost:6000 content-type: text/html Il server deve verificare la validità della riga di intestazione e ignorare tutti i campi settati nella definizione dell’header. Una volta rilevata la stringa vuota di terminazione della richiesta, il server deve eseguire l’operazione richiesta dall’URL e rispondere secondo il protocollo HTTP. Se la richiesta è andata a buon fine, il formato della risposta è: HTTP/1.0 200 OK dove < messag g i o > è un messaggio testuale che dipende dalla risorsa invocata. Nel caso di un qualsiasi errore il formato della risposta sarà: HTTP/1.0 400 ERRORE Anche in questo caso < messag g i o > 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. • Risposte che non soddisfano il formato specificato rendono il progetto insufficiente. 2
2.2 V ENDITA DI UN OGGETTO Un utente nomeU t ent e può vendere un oggetto utilizzando la risorsa vend i . La risorsa ven- di accetta come nomi di parametri validi nomeOg g et t o e pr ezzo. Il primo indica il nome (stringa) dell’oggetto da vendere mentre il secondo ne specifica il prezzo (numero intero). Un possibile esempio di richiesta di vendita valida è il seguente: GET /vendi?nomeOggetto=lampadaIkea&prezzo=20&nomeUtente=Aldo HTTP/1.0 user-agent: Mozilla 5.0, Chrome, Safari host: localhost:6000 content-type: text/html Una possibile risposta positiva è data da: HTTP/1.0 200 OK Oggetto lampadaIkea messa in vendita per 20 euro 2.3 A CQUISTI DISPONIBILI Un utente nomeU t ent e può visualizzare gli oggetti messi in vendita utilizzando la risorsa ved i P r od ot t i . La risorsa non prevede nessun parametro oltre a nomeU t ent e. Si noti che la risorsa restituisce SOLO oggetti che sono stati messi in vendita dai NON-amici dell’utente che effettua la richiesta. Per esempio se A e B sono amici e A vende una lampada, quest’ulti- ma non comparirà nella lista degli oggetti in vendita richiesta da B. Un possibile esempio di richiesta valida è il seguente: GET /vediProdotti?nomeUtente=Aldo HTTP/1.0 user-agent: Mozilla 5.0, Chrome, Safari host: localhost:6000 content-type: text/html Una possibile risposta positiva è data da: HTTP/1.0 200 OK lampadaIkea 20 sediaInFaggio 50 sopramobileInCeramica dentieraDellaNonna 1500 Il corpo della risposta contiene una serie di linee di testo e ogni linea segue il formato < pr od ot t o >< spazi o >< pr ezzo >. 3
2.4 C OMPRARE UN OGGETTO Un utente nomeU t ent e può comprare un oggetto utilizzando la risorsa compr a. Questa risorsa necessita dell’argomento nomeOg g et t o in cui si deve specificare il nome dell’oggetto da comprare. Una volta che l’oggetto è stato comprato non è più disponibile nella lista degli oggetti in vendita restituita dalla risorsa ved i P r od ot t i . Un possibile esempio di richiesta di acquisto valida è la seguente: GET /compra?nomeOggetto=lampadaIkea&nomeUtente=Aldo HTTP/1.0 user-agent: Mozilla 5.0, Chrome, Safari host: localhost:6000 content-type: text/html Una possibile risposta positiva è data da: HTTP/1.0 200 OK lampadaIkea è tuo!!! 2.5 V ENDITE EFFETTUATE Un utente nomeU t ent e può verificare quali oggetti messi in vendita dall’utente stesso sono stati venduti per mezzo della risorsa ved iV end i t e. La risorsa non prevede alcun parametro oltre a nomeU t ent e. Si noti che la risorsa restituisce SOLO gli oggetti che sono stati messi in vendita dall’utente loggato e successivamente venduti. Un possibile esempio di richiesta valida è il seguente: GET /vediVendite?nomeUtente=Aldo HTTP/1.0 user-agent: Mozilla 5.0, Chrome, Safari host: localhost:6000 content-type: text/html Una possibile risposta positiva è data da: HTTP/1.0 200 OK lampadaIkea dentieraDellaNonna 1500 2.6 C REAZIONE DELLA SOCIAL NETWORK Per quanto riguarda la rete sociale che impone i vincoli sulla vendita, essa viene caricata al momento della creazione del servizio e non può essere modificato durante l’esecuzione dello stesso. Il caricamento avviene per mezzo di un file chiamato listaAmici.txt e che contiene una lista degli archi non orientati presenti nella rete sociale. Ogni riga del file rappresenta un arco e segue il formato: 4
- dove < nomeU t ent e > rappresenta un segnaposto (< e > non vanno inseriti). Lo studente deve prevedere una classe per il caricamento della social network da un file. Il file listaAmi- ci.txt si trova sul sito del corso di Reti come materiale di supporto al progetto. 3 M ODALITÀ 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 55% (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 ’progettoGennaio2018'. La mail deve avere come oggetto ’ProgettoGennaio2018’ e contenere nel corpo nome, cognome e numero di matricola dello studente. Il materiale deve essere consegnato entro le 23:59:59 del 5 gennaio 2018. 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 pro- getto saranno comunicate sulla pagina web del corso. 5
Puoi anche leggere