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.
12 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.
22.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 >.
32.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.
5Puoi anche leggere
