Progetto Febbraio 2013 - Appello 1: Diffusione di tweets sul grafo di Twitter
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
U NIVERSITÀ DEGLI S TUDI DI M ILANO,
D IPARTIMENTO DI I NFORMATICA
L AUREA T RIENNALE IN C OMUNICAZIONE D IGITALE
C ORSO DI R ETI DI C ALCOLATORI
A NNO A CCADEMICO 2011/2012
Progetto Febbraio 2013 - Appello 1:
Diffusione di tweets sul grafo di Twitter
24 Dicembre 2012 ore 15:50
1 FASE 1: C OSTRUZIONE DEL GRAFO DEI FOLLOWER DI T WITTER
La prima fase di questo progetto consiste nel costruire un grafo non orientato partendo dal-
la relazioni di tipo ’follower’ che caratterizzano gli utenti iscritti al servizio di microblogging
Twitter. Attraverso la creazione di una relazione di ’following’ un utente può ricevere tutti i
tweets dell’utente che sta seguendo. La relazione di ’follower’ viene descritta come un arco
orientato che dall’utente che segue si dirige verso l’utente seguito. E’ possibile, quindi, co-
struire un grafo orientato a partire dalla relazione ’follower’, in cui i nodi sono rappresentati
dagli account di Twitter e gli archi sono le relazioni. Il primo obiettivo è quindi la creazione
di un sottografo del più grande grafo di Twitter attraverso le API che il servizio mette a di-
sposizione. Di seguito vengono descritte le modalità di costruzione (crawling degli utenti e
inserimento degli archi) e le API utilizzare.
1.1 C OSTRUZIONE DEL SOTTOGRAFO
Il processo di costruzione del grafo avviene seguendo una visita in ampiezza del grafo di Twit-
ter a partire da un’utente specificato. L’identificativo dell’utente è comune per tutti i singoli
progetti e corrisponde l’account Twitter del docente (screen_name=zignoai e user_id=211787094).
La visita in ampiezza permette di inserire tutti i nodi a distanza minore o uguale a l (numero
di archi nel cammino minimo dal nodo di riferimento verso gli altri nodi). Nel nostro caso,
1(a) Nodo di partenza (b) Nodi a distanza 1 (c) Nodi a distanza 2
Figura 1.1:
sia per problemi di dimensioni del grafo risultante sia per limitazioni nelle API imposte da
Twitter, l = 2. Ciò comporta che nel sottografo si devono inserire al massimo i followers dei
followers del nodo di partenza. Gli archi da inserire corrispondono a tutte le relazioni ’follo-
wer’ del nodo di partenza e tutte le relazioni ’follower’ dei follower del nodo corrispondente al
docente. Un esempio di visita in ampiezza è mostrato nella figura 1.1 mentre una descrizione
ad alto livello dell’algoritmo per la costruzione del grafo è riportata di seguito:
Q = insieme di nodi vuoti
inserisci nodo iniziale i in G
foreach follower f di i
-inserisci il nodo f in G
-crea un arco non orientato (i,f) in G
-inserisci il nodo f in Q
foreach elemento e di Q
-foreach follower f di e
--inserisci il nodo f in G se non è già presente
--crea un arco non orientato (e,f) in G
Graficamente il primo foreach inserisce i nodi e gli archi arancioni nel grafo, mentre i due
cicli foreach innestati aggiungono nel grafo gli archi e i nodi gialli. Il grafo creato, a differenza
dell’originale Twitter, non è diretto bensì non orientato.
1.2 C OME FARSI RESTITUIRE I FOLLOWERS
Per farsi restituire i followers di un account Twitter si possono utilizzare le API messe a dispo-
sizione da Twitter. In particolare la richiesta da inviare è la seguente:
http://api.twitter.com/1/followers/ids.format
il quale richiede come argomenti obbligatori o lo user id o lo screen name dell’utente. Per ul-
teriori informazioni si può consultare la pagina web https://dev.twitter.com/docs/api/1/get/followers/ids.
Nella costruzione e nell’implementazione della procedura di creazione precedentemente espo-
sta si devono tener conto dei limiti imposti da Twitter nell’uso di richieste da parte di utenti
non autenticati; in particolare si possono eseguire fino a 150 richieste in un’ora.
2Nota bene: Per evitare che in fase di testing e valutazione del progetto il numero di richie-
ste superi il limite consentito, il server, al momento dell’avvio deve permettere la scelta tra la
costruzione precedentemente esposta e la costruzione a partire da un file .dgs che contiene
una copia del sottografo di Twitter. Per tale motivo il server può ricevere da linea di comando
una qualsiasi stringa indicante l’opzione di avvio. Nel caso non venga inserita nessuna strin-
ga (l’array ar g s[] è vuoto) il grafo viene caricatto da file, altrimenti (ar g s[] ha lunghezza 1) il
grafo viene creato utilizzando le Twitter API e poi viene salvato su un file .dgs.
2 FASE 2: A PPLICAZIONE C LIENT-S ERVER PER LA DIFFUSIONE DEI
TWEET
Una volta definito il grafo il progetto prevede un’applicazione Client-Server per la diffusione
di tweets sul grafo appena creato. La parte server, oltre all’interazione con i diversi client, si
interfaccia con il grafo muovendo e diffondendo, secondo alcune regole che verranno speci-
ficate in seguito, i tweets associati ad un particolare vertice del grafo. Ogni vertice v è caratte-
rizzato, oltre che dall’identificativo univoco, da due insiemi di tweets t , l’insieme query Que
contenente i risultati di una richiesta di tipo search fatta a Twitter API, e l’insieme Di f f che
contiene i tweets che sono stati inviati da altri nodi mediante il meccanismo di diffusione.
All’atto della connessione da parte del client, il server in ascolto (la scelta della porta priva
di vincoli) assegna il client ad nodo presente nel grafo in modo casuale. Fino al termine della
connessione il client e il nodo coincidono; inoltre ad un nodo può essere associato solo e un
solo client. Avvenuta la connessione, il server invia al client una risposta JSON che rispetta il
seguente formato:
{"user_id":"";
"degree":"";
"clustering":"";
"num_que":"";
"num_diff":"";
"followers": ["","",...,"",""];}
Dove in questo caso f ol l ower s indica i vicini del nodo nel sottografo di Twitter, non i follo-
wers del nodo in Twitter.
All’atto della ricezione della risposta il client visualizza immediatamente i valori relativi ai
campi user_id, degree e clustering.
Il client, inoltre, riconosce e implementa due comandi: push e publish. Il comando push
chiede al server di eseguire il meccanismo di diffusione dei tweet da parte del nodo associato
al client, mentre publ i sh chiede al server di restituire un tweet contenuto nell’insieme Di f f
associato al nodo, il quale verrà poi pubblicato dal client sulla bacheca dell’account Facebook
dell’utente che sta utilizzando il client. Per poter implementare la seconda funzione è neces-
sario passare al client, attraverso argomenti da linea di comando, l’id dell’utente Facebook e
l’access token relativo ai permessi di scrittura in bacheca. Entrambe le informazioni sono di-
sponibili utilizzando Facebook Graph API Explorer (si vedano le slide del corso per il relativo
indirizzo web).
3Il client deve mettere a disposizione una semplice e funzionale user interface (UI) (non
sono ammesse interfacce grafiche, basta una semplice interfaccia testuale) che permette al-
l’utente di inserire il nome del comando e i relativi parametri. La UI ha il compito, quindi, di
reperire tutte le informazioni per la costruzione dell’effettiva richiesta da inviare al server. La
richiesta corrisponde ad una versione semplificata dell’intestazione di una richiesta HTTP, in
particolare l’unico metodo accettato è GET, mentre le uniche risorse (URL) valide sono push
e publ i sh seguite da un’eventuale parte relativa alla query (stessa sintassi di un URL - URI,
come definito nelle slide). Un possibile esempio di richiesta valida è data da:
GET push?parametro1=valore1¶metro2=valore2
2.1 I L COMANDO PUSH
Il comando push richiede 3 parametri:
• q: url-encoded query di ricerca codificata in UTF-8. Ha lo stesso significato del para-
metro q della risorsa fornita dalle Twitter API,
GET search (https://dev.twitter.com/docs/api/1/get/search).
• rpq: questo parametro può assumere solo valori interi strettamente maggiori di 0 e
indica quanti tweets devono essere cercati
• rpd: questo parametro può assumere solo valori interi strettamente maggiori di 0 e
indica quanti tweets devono essere diffusi.
Attraverso il comando push il client indica al server di cercare r pq tweets che soddisfano la
query q e metterli nell’insieme Que associato al nodo. Una volta inseriti i tweets in Que, il
nodo diffonde r pd tweets presi in modo casuale dall’unione degli insiemi Que e Di f f . Il
tweet estratto viene eliminato dall’insieme di appartenenza; in questo modo un tweet non
può venire estratto più volte.
La diffusione avviene secondo la seguente modalità: per ogni tweet estratto nella fase pre-
cedente viene scelto in modo casuale un vicino del nodo associato al client e viene inserito
nell’insieme Di f f del nodo di destinazione. Per esempio, supponiamo che il client venga as-
sociato al nodo 100 i cui insiemi Que e Di f f contengono rispettivamente i valori {’Ciao bel-
li’,’Belli e dannati’,’Paolo Belli suona la tromba?’} e {’Boom Baby’,’C’è sempre qualcosa sotto’,’E
il momento di far festa’}. Il client invia il comando
GET push?q=vesuvio&rpq=1&rpd=3
Il server cerca in Twitter un tweet che soddisfi la query vesuvio, per esempio ’Hamsik è il
Vesuvio del San Paolo’ e inserisce (diffonde) 3 tweets:
’Ciao belli’
’Hamsik è il Vesuvio del San Paolo’
’Boom Baby’
4negli insiemi Di f f di tre vicini scelti a caso. Dopo la diffusione gli insiemi associati al nodo
100 saranno Que ={’Belli e dannati’,’Paolo Belli suona la tromba?’} e Di f f ={’C’è sempre
qualcosa sotto’,’E il momento di far festa’}.
Funzione da implementare solo per il secondo appello di Febbraio: La richiesta push
deve essere estesa introducendo un terzo parametro denominato idfollower, il quale accetta
come valore l’id di un vicino del nodo a cui il client è associato e che viene restituito nel JSON
al momento della connessione al server. La sintassi sarà quindi del tipo
GET push?q=&rpq=&rpd=&idfollower=
Dal punto di vista semantico tale richiesta è simile alla push precedente ma, in questo caso,
il vicino non viene scelto a caso ma è indicato dal parametro. I tweet da diffondere saranno
quindi inviati solo al vicino, il quale riceverà r pd tweets.
2.2 I L COMANDO PUBLISH
Il comando publish richiede che il server restituisca al client un tweet casuale estratto dal-
l’insieme Di f f . Anche in questo caso la richiesta corrisponde ad una versione semplificata
dell’intestazione di una richiesta HTTP:
GET publish
Il server risponde al client mediante una risposta in formato JSON del tipo:
{"publish":"";}
Il client elabora la risposta e pubblica il tweet sulla bacheca dell’utente identificato dall’id
passato come primo argomento. Per la pubblicazione di un post in bacheca si veda la pa-
gina delle Facebook API https://developers.facebook.com/docs/reference/api/user/#posts.
La pubblicazione non deve avvenire utilizzando Graph API Explorer ma deve sfruttare l’ac-
cess token che essa restituisce.
Estensione valida solo per il secondo appello di Febbraio Si deve introdurre una nuova
richiesta del tipo
GET publish2
la quale invia al server due tweets scelti a caso dall’insieme Di f f mediante una risposta in
formato JSON del tipo:
{"publish":"";
"comment":"";}
Il client elabora la risposta e pubblica il < t weet 1 > sulla bacheca dell’utente identificato
dall’id passato come primo argomento, mentre il < t weet 2 > viene usato per commentare il
post appena pubblicato.
N.B. Il server deve essere multithread.
53 C ONSEGNA
Il progetto è individuale e verranno presi provvedimenti nel caso ci sia il sospetto di una
eventuale copiatura. Il linguaggio da utilizzare per lo sviluppo è Java. Non ci sono vincoli
sulle librerie da utilizzare per lo svolgimento, tuttavia é consigliato l’uso della libreria Graph-
Stream per quanto riguarda la parte inerente al grafo. 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 ’progettoFebbraio1’. La mail deve avere come oggetto ‘ProgettoFebbraio1Reti’ e
contenere nel corpo nome, cognome e numero di matricola dello studente. Il materiale deve
essere consegnato entro le 23:59:59 del 26 gennaio 2013.
Il codice del progetto per il secondo appello di Febbraio e i relativi jar delle librerie utiliz-
zate devono essere inviati al docente in una directory compressa (zip o tar.gz) denominata
’progettoFebbraio2’. La mail deve avere come oggetto ‘ProgettoFebbraio2Reti’ e contenere
nel corpo nome, cognome e numero di matricola dello studente. Il materiale deve essere
consegnato entro le 23:59:59 del 20 febbraio 2013.
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.
6Puoi anche leggere
