Scarica

Rapporto trimestrale attività svolta
L’attività di studio e di ricerca che sto svolgendo ha come tema il “Sistema di cooperazione a
distanza Access Grid”. Come proposto in fase di selezione per l’assegnazione della borsa, durante il
primo periodo di lavoro ho portato avanti uno studio approfondito del software sui sistemi operativi
maggiormente in uso, Windows, Linux e OS-X, per comprenderne appieno il funzionamento dal
punto di vista dell’utilizzatore e per far emergere quelli che sono i problemi che più comunemente
incontra l’utente che si approccia ad Access Grid e che spesso sono causa di abbandono del suo
impiego.
Il progetto Access Grid è nato nel 1998 con l’intento di realizzare un sistema che permettesse la
cooperazione a distanza sfruttando le tecnologie a disposizione e che potesse seguire l’evoluzione
dell’hardware e della rete Internet così da permettere collaborazioni sempre più performanti con
l’avanzamento della tecnologia. Access Grid è un software che permette la costruzione di ambienti
cooperativi distribuiti (nodi Access Grid), con lo scopo di rendere il più agevole possibile
l’interazione tra gruppi di lavoro remoti per la realizzazione di convegni scientifici, seminari e
incontri di altro genere. Progettato per la collaborazione group-to-group, non ha un limite stabilito
al numero di nodi che possono collegarsi per partecipare ad un meeting, inoltre da ogni nodo è
possibile mandare più flussi video a seconda del numero di videocamere che si ha a disposizione.
L’interfaccia sviluppata per la gestione e la configurazione di Access Grid è la Venue Client. In
Figura 1 ne è rappresentato uno screenshot effettuato durante una sessione di test. La barra dei
menu visibile in alto è utilizzata per la configurazione del sistema. La barra degli indirizzi serve per
connettersi ad una specifica Virtual Venue, uno spazio virtuale nel quale gli utenti che si trovano
fisicamente in luoghi differenti possono incontrarsi per collaborare con Access Grid. Le icone tra la
barra dei menu e quella degli indirizzi sono utilizzate per le configurazioni più frequenti, tra le
quali: abilitare o disabilitare audio e video e scegliere i servizi. La finestra più grande in alto è
quella che permette di vedere i partecipanti alla sessione, i dati che vengono caricati e resi
disponibili per tutti e le applicazioni disponibili. La finestra di sinistra è quella che permette di
spostarsi tra le virtual rooms disponibili ad un determinato address come ad esempio quella dedicata
ai test per le configurazioni che troviamo sotto la home venue. La finestra più in basso contiene una
chat testuale che permette di scrivere e leggere quello che gli altri partecipanti scrivono.
Figura 1. Venue Client
Il software provvede inoltre alla comunicazione tra gli utenti connessi fornendo tool audio e video,
che rendono possibile vedere e sentire gli altri partecipanti una volta effettuata la connessione. Il
tool utilizzato per la trasmissione video tra gli users è il VIC (sta per Video Conference). E’ un tool
per videoconferenze che permette a gruppi di utilizzatori di trasmettere e ricevere flussi video verso
e da ogni partecipante su una rete IP multicast. L’hardware richiesto per poter utilizzare VIC
consiste di un device per acquisizione video, come una semplice webcam, nel caso in cui si voglia
trasmettere un flusso dal nostro nodo, mentre per ricevere non è necessario alcun hardware
particolare se non quello già utilizzato per Access Grid. La codifica video impostata di default
dipende dal dispositivo hardware utilizzato dal pc per catturare l’immagine. Nel caso in cui la
codifica utilizzata sia la H.261 la qualità dell’immagine è discreta ma la dimensione è piuttosto
piccola. Per avere un miglioramento dell’immagine in qualità e dimensioni, sempre che la banda a
disposizione permetta una bit rate da dedicare al video che va da un minimo di circa 0.8 Mb/s ad un
massimo di 1.5 Mb/s, dobbiamo utilizzare una codifica H.264 anche questa supportata dal tool. In
Figura 2 è rappresentato uno screenshot della finestra nella quale sono visibili i flussi video
provenienti dai vari nodi durante una sessione di test. E’ possibile ingrandire ciascuna immagine,
portandola alla dimensione originale, cliccandoci sopra. Ad esempio per avere una visione più
chiara possibile delle persone che partecipano al meeting o volendo scegliere quelle con le quali si
ha più interesse ad interagire, è possibile cliccare sulle immagini che interessano in modo da
ingrandirle e poi distribuirle ad occupare il monitor o quello che si utilizza come display. Ad ogni
flusso in ingresso sono associate alcune informazioni, quali la bit rate, i frame al secondo ricevuti e
il nome del nodo dal quale proviene il flusso. Sono presenti anche informazioni riguardanti
l’indirizzo (multicast o unicast) verso il quale sono diretti i flussi, la porta e il time to live.
Figura 2. Finestra dei flussi video
L’audio è gestito dal RAT (sta per Robust Audio Tool) la cui finestra permette ai partecipanti di
gestire le opzioni quali il sample rate e la scelta dei codec, poter vedere i flussi in ingresso ed
abilitare o disabilitare il proprio. Sono visibili inoltre i nomi dei dispositivi utilizzati in input ed
output per la gestione dell’audio con il relativo volume. La figura 3 mostra la finestra RAT durante
un collegamento alla Venue Bridgeport raggiungibile dalla Home venue. I triangoli colorati alla
sinistra del nome di ciascun partecipante sono un indicatore della qualità dell’audio. Il colore verde
indica un’alta qualità mentre passando all’arancione e nel caso peggiore al rosso si ha un
deterioramento della qualità. Come per il VIC anche in questo caso compare l’indirizzo verso il
quale è diretto l’audio, la porta e il time to live. Entrambi i tool sono un’evoluzione di VIC e RAT
sviluppati con Mbone.
Figura 3. Robust Audio Tool
L’audio e i video service sono controllati dai service manager, che sono installati su una singola
macchina nel caso in cui il nodo Access Grid abbia una configurazione semplice realizzata ad
esempio da un utente sul proprio desktop o laptop. Nel caso in cui il nodo Access Grid sia invece
configurato per ospitare una sala conferenze, potrebbe esser necessario distribuire i service manager
su macchine distinte e remotizzare i servizi. Una configurazione possibile ad esempio prevede una
macchina per la gestione dell’audio e altre due per gestire il video (quello in input e quello in
output). Nella figura 4 è rappresentato proprio questo caso. Il node sevice, che può essere su una
qualunque delle tre macchine, controlla i service manager i quali a loro volta comunicano con i
service audio e video sulla specifica macchina. Per remotizzare un servizio è sufficiente,
direttamente dalla Venue Client, selezionare ‘add service manager’ e digitare l’indirizzo IP o
l’hostname delle macchine alle quali affidare il particolare servizio. Questa applicazione può
funzionare sia nel caso in cui le macchine facciano parte dello stesso nodo, sia che siano su nodi
differenti ed è utile per varie applicazioni. Se per esempio da un nodo Access Grid per qualche
motivo volessi mandare un flusso video o audio con il mio nome (ovvero come fosse proveniente
da una videocamera del mio nodo) ma con immagini o suoni catturati da un altro pc su un altro
nodo, sarebbe sufficiente conoscere quell’IP. Ancora, se ci fosse la necessità di partecipare ad una
videoconferenza mandando flussi in uscita da stanze fisiche separate ma risultanti sullo stesso nodo.
Node
Management
Service
Manager
Service
Manager
Service
Manager
Video
Video
Producer
Producer
Service
Service
Video
Consumer
Service
Audio
Service
Figura 4. Esempio di struttura logica di un nodo
Il problema che potrebbe nascere nel primo degli esempi presi in considerazione è che
quest’operazione non richiede apparentemente alcun tipo di controllo. Sembrerebbe dunque
sufficiente conoscere un indirizzo IP di una macchina collegata ad Access Grid per poter assumere
il controllo di qualunque service audio o video su quella macchina. Ho intenzione di approfondire
questo aspetto più avanti per capire se ci sia una qualche impostazione che impedisca che ciò
avvenga.
Per testare il software ho installato la Development release 3.2 beta1 di Access Grid sui sistemi
operativi precedentemente citati. Trattandosi di software gratuito, open source, è possibile effettuare
il download direttamente dal sito ufficiale all’URL: http://www.accessgrid.org/sofware. Nel sito
sono disponibili i link per scegliere la versione o la distribuzione sulla quale effettuare
l’installazione del software. Il comportamento sulle tre piattaforme sulle quali ho effettuato i test è
simile, con alcune differenze dovute principalmente alle difficoltà di installazione e configurazione
dei diversi applicativi e ad alcuni problemi che ad esempio ho incontrato su Mac e non su Linux e
Windows e viceversa.
Il primo sistema operativo sul quale ho installato Access Grid è un Mac OS-X con processore Intel.
Diversamente dalle informazioni riportate sul sito ufficiale di Access Grid, ho riscontrato problemi
di compatibilità tra l’ultima versione del software, la 3.2 beta1, con le versioni precedenti alla 10.5
del sistema operativo. In particolare con la versione 10.4, pur avendo effettuato i settaggi necessari
per la configurazione delle periferiche e della Venue Client e aver riavviato Access Grid per esser
sicuro del salvataggio delle modifiche, non è stato possibile ricevere e trasmettere alcun flusso
video. La parte audio funzionava invece correttamente sia per i flussi in ingresso che per quelli in
uscita. Ho effettuato un update del sistema operativo aggiornandolo alla versione 10.5 e in seguito
reinstallato Access Grid 3.2 beta 1. Con la nuova combinazione di software e sistema operativo ho
risolto i problemi inizialmente incontrati.
Per testare il sistema ho effettuato collegamenti alla Virtual Venue sia in modalità multicast che è
quella di default, supportata dalla rete sulla quale lavoro, sia utilizzando un multicast-unicast
bridge. Quest’ultimo potrebbe rendersi necessario in caso di problemi sulla rete multicast dovuti per
esempio al firewall mal configurato o nel caso in cui tale tecnologia non sia supportata dalla rete.
Connettendosi ad Access Grid in modalità Unicast siamo automaticamente connessi al più vicino
(in termini di millisecondi) Unicast Bridge disponibile. Se la rete lo consente è comunque
preferibile utlizzare Access Grid direttamente in modalità Multicast. Il software, infatti, è stato
pensato e realizzato per scambiare dati (audio, video ed altro) sfruttando tale tecnologia. Per questo
motivo non richiede l’utilizzo di un MCU come invece accade con altri sistemi di videoconferenza
e consente di trasmettere e ricevere un elevato numero di flussi video separati. Questi possono esser
distribuiti a piacimento anche su più schermi per dare così ai partecipanti l’idea della presenza fisica
delle persone collegate da remoto. Affinché Access Grid lavori correttamente è necessario che i
firewall siano configurati per permettere il traffico UDP ed il passaggio di indirizzi multicast in
ingresso e in uscita. Il gruppo multicast verso il quale mandiamo pacchetti e dal quale li riceviamo è
quello dei partecipanti connessi alla Virtual Venue. Per regolare l’accesso al gruppo multicast è
possibile utilizzare un certificato X.509 (tema questo che ho intenzione di approfondire in seguito).
Come detto l’alternativa al multicast è quella di utilizzare dei bridge e anche in questo caso ogni
firewall tra il bridge e la Venue Client deve essere configurato per permettere il protocollo
connectionless UDP.
Un aspetto molto importante di Access Grid e che lo distingue da un comune sistema di
videoconferenza con il quale fare semplici video telefonate, è quello delle Shared Application.
Queste, come suggerisce il nome, permettono la cooperazione tra i partecipanti fornendo la
possibilità di condividere documenti quali le presentazioni, ambienti di lavoro come il desktop
nonché poter navigare su pagine web contemporaneamente attraverso lo Shared Browser. Access
Grid non è limitato alle applicazioni che troviamo installate nella Virtual Venue. Ne esistono altre
pronte da installare disponibili tra i Projects sul sito ufficiale di Access Grid e inoltre chi lo volesse
può implementare tramite una interfaccia API, disponibile in linguaggio python, shared application
realizzabili a seconda delle esigenze. Quella che troviamo di default nella Venue Client in seguito
all’installazione su Mac è la Shared Presentation che permette di condividere presentazioni power
point. E’ sufficiente che il partecipante che vuol condividere il proprio documento ppt lo carichi tra
i ‘Data’ e aggiunga nella ‘Application Session’ una nuova Shared Presentation. Gli altri partecipanti
interessati alla condivisione del documento possono a quel punto aprire la presentazione, a patto che
abbiano Power Point installato sul pc, che scorrerà su ciascuno schermo gestita dal presentatore.
Dopo aver preso in esame le applicazioni disponibili per Access Grid su Mac, ho installato lo
Shared Desktop che permette appunto la condivisione del desktop da remoto sia come client che
come server. Affinché possa funzionare correttamente ci sono dei requirements da rispettare: è
necessario per prima cosa installare sulla propria macchina un client VNC (Virtual Network
Computing) e un server VNC, software per il controllo remoto del computer. La procedura
d’installazione dei requirements è riportata sul sito ufficiale www.accessgrid.org e può essere
facilmente seguita per la corretta installazione con un piccolo accorgimento: il nome del server
VNC di cui effettuiamo il download e che l’applicazione cercherà nel path all’avvio, è
OSXvnc.app. Purtroppo, dopo aver proceduto all’installazione seguendo i passi riportati nelle
istruzioni, all’avvio dell’applicazione compare un messaggio d’errore con scritto che non esiste un
server VNC e quindi che non è possibile condividere il proprio desktop. Controllando sul sito web
dal quale ho fatto il download del server mi sono accorto che l’applicativo ha semplicemente
cambiato nome: adesso non si chiama OSXvnc.app bensì Vine Server.app e per questo motivo non
viene riconosciuto. Basta così creare un link simbolico dalla shell per risolvere il problema. Fatto
questo ho provato Shared Desktop con un utente collegato da un pc linux. L’aspetto interessante di
tale feature è che tutte le persone collegate possono lavorare sulla medesima applicazione aperta su
ciascuno screen, prendendo a turno controllo del mouse. Il funzionamento sia come server che
come client non ha dato problemi, se non che l’aggiornamento dell’applicazione su Mac non è
immediato, ovvero è capitato che all’altro utente (su linux) comparisse la possibilità di condividere
il mio desktop quando invece avevo già disabilitato tale opzione. La procedura per il download e
l’installazione dei Requirements e dell’applicazione la descrivo in un howto apposito, soprattutto
per lasciare documentata la risoluzione del bug sul server VNC.
Il successivo sistema operativo sul quale ho installato Access Grid per studiarne il comportamento è
stato Linux. La distribuzione è la Ubuntu 9.10 (Karmic Koala). L’intenzione iniziale era quella di
creare una macchina virtuale di Ubuntu utilizzando un virtualizzatore e lavorare con Access Grid su
questo. Ho così installato sull’host Mac, Virtual Box, liberamente scaricabile dal sito
www.virtualbox.org, creato la macchina virtuale linux e su questa installato Access Grid. Per ciò
che riguarda il funzionamento del software non ho incontrato problemi, che invece ci sono stati nel
far riconoscere a Ubuntu ‘virtualizzato’ le periferiche connesse a Mac, quali l’isight per catturare il
video e le cuffie-microfono usb. Passando ad una webcam Logitech usb risolvo il problema del
video che adesso riesco a trasmettere. Ho provato poi ad utilizzare delle cuffie con microfono a
jack, inserendole nel Mac con un convertitore usb. Avviene così il riconoscimento ma la qualità
dell’audio è pessima. Nel fare prove per testare il sistema Access Grid e acquisire quella familiarità
necessaria a poter fornire in futuro supporto tecnico, devo sempre tener conto del fatto che un
utilizzatore non deve trovarsi di fronte ad un software instabile e sul quale dover operare troppe
configurazioni prima dell’utilizzo. Per questo motivo ho ritenuto opportuno abbandonare l’utilizzo
del virtualizzatore e testare direttamente Access Grid su un pc con sistema operativo Ubuntu 9.10.
L’installazione su una distribuzione Debian & Ubuntu richiede l’utilizzo di una shell ed è per alcuni
aspetti un po’ più complessa rispetto a quanto lo sia sulle altre piattaforme. Per semplificare il
processo d’installazione ad un potenziale utilizzatore ho compilato un howto che lo descrive:
Installazione di Access Grid 3.2 su Linux (Debian & Ubuntu). Durante il primo collegamento ho
riscontrato un problema connesso all’utilizzo dell’audio service RAT. Il tool non riconosceva infatti
la periferica microfono, o meglio, la riconosceva senza però dare la possibilità di impostare
l’utilizzo del dispositivo. Dopo alcuni tentativi di risoluzione del problema non andati a buon fine,
cercando nella documentazione ufficiale ho trovato un documento che descrive come configurare
l’audio service RAT su linux affinché lavori correttamente. Per risolvere il problema è sufficiente
cancellare il file .RATdefault nella directory di Accessgrid, aprire successivamente il tool dalla
shell (e non aprendolo come di prassi tramite Venue Client) e cambiare alcune configurazioni. Sul
sito www.accessgrid.org possiamo trovare un collegamento ad una serie di Howto tra i quali è
presente quello che interessa in questo caso: ‘Setting up rat’. La URL della pagina web che
cerchiamo è la seguente: http://www.vislab.uq.edu.au/research/accessgrid/howto/rat.html.
Durante una sessione di test, ho incontrato un altro inconveniente che potrebbe capitare
all’utilizzatore: scollegando un video device ad esempio una webcam usb, come potrebbe accadere
per errore, mentre questa è in funzionamento (modalità enabled) e successivamente ricollegandola,
non è riconosciuta dal sistema. L’effetto indesiderato che viene a crearsi è quello che la window
nella quale solitamente compare il flusso video che stiamo trasmettendo risulta vuota con soltanto il
messaggio ‘waiting for video’. Le soluzioni possibili che ho trovato sono due: riavviare la macchina
in modo da far caricare nuovamente le impostazioni necessarie oppure disattivare il driver del
dispositivo in questione e attivarlo nuovamente dalla shell.
Le Shared Application che vengono installate con Access Grid su Ubuntu sono la shared
presentation e lo shared browser. Come su Mac anche sul sistema operativo Linux ho installato
shared desktop. I requirements necessari sono al solito un client ed un server VNC: xvnc4viewer e
vnc4server. Alla URL http://www.westgrid.ca/support/collaboration/research/ace/shareddesktop è
descritta la procedura per il download e l’installazione dell’applicazione. Altre due applicazioni che
ho installato sono il recording tool AGVCR per la registrazione delle videoconferenze, che permette
una successiva consultazione in caso di necessità, e la TigerboardAG3. Quest’ultima applicazione
consente di condividere una lavagna virtuale tra i partecipanti al meeting ad esempio per lavorare su
un’immagine da più postazioni. Una volta scaricato il pacchetto, per l’installazione è sufficiente
caricare lo stesso nella sezione ‘Data’ di Access Grid e con il tasto destro del mouse scegliere open
così come suggerito nelle istruzioni.
L’altro sistema operativo sul quale ho installato Access Grid è stato Windows Vista. A differenza
degli altri due presi in esame, per windows esiste la possibilità di installare un pacchetto, chiamato
AccessGrid3 All in one Installer for Windows, che permette appunto di installare Access Grid
(versione 3.2 beta1) più una serie di applicazioni sviluppate separatamente. Durante il processo
d’installazione è necessario scegliere le applicazioni che vogliamo siano disponibili per l’utilizzo,
come ad esempio le varie Shared Application o anche il video service che utilizza il codec H.264 e
permette flussi video di miglior qualità. I tool VIC e RAT funzionano correttamente, garantendo
flussi video e audio di buona qualità. Rispetto ai pacchetti installati su Mac e su Linux, questo
pacchetto contiene molte delle Shared Application disponibili: shared browser, tigerboardAG3,
shared presentation, shared desktop e l’ AGVCR launcher. Grazie al pacchetto All in one Installer,
il funzionamento su Windows è più semplice se comparato alle altre piattaforme, almeno dal punto
di vista dell’utilizzatore. Per la realizzazione di un server AG devo ancora verificare.
Nell’arco di questi tre mesi ho avuto la possibilità di partecipare ad alcune videoconferenze che si
sono tenute nell’Area del CNR di Pisa in un’aula attrezzata appositamente per ospitare tali eventi.
Una in particolare è stata per me più interessante delle altre. I partecipanti all’incontro virtuale
erano un numero importante di ricercatori di tutta Europa che frequentemente hanno la necessità di
confrontare lo stato dei loro studi. Per evitare di viaggiare spesso, risparmiando così tempo e
denaro, hanno scelto di comune accordo la video cooperazione a distanza per la maggior parte dei
loro meeting. Il sistema di video cooperazione che utilizzano ad ogni incontro è Access Grid. Al
meeting vi erano partecipanti da nove postazioni differenti, collegati alla Venue tramite il
Multicast-Unicast Bridge AGCS. Ciascun nodo era stato attrezzato a seconda delle esigenze e del
numero dei partecipanti alla videoconferenza dal particolare nodo. Vi erano infatti postazioni con
molte persone, dotate di videoproiettori, microfoni ambientali, casse acustiche e videocamere per
inquadrature da più punti di vista, come anche nodi con una singola persona collegata dal proprio
desktop con cuffie (per evitare l’eco), un microfono e una webcam. Il nodo ag1-pisa, dal quale ho
partecipato all’incontro, era configurato su un pc con sistema operativo Windows xp con
AccessGrid 3.2 beta 1 più un secondo pc per la gestione di una matrice audio Nexia. Prima
dell’inizio della conferenza vera e propria è stata dedicata una mezz’ora al troubleshooting.
Trattandosi infatti non di un meeting face-to-face, bensì di una sessione con molti partecipanti, i
problemi che avrebbero potuto presentarsi sono da moltiplicarsi per l’elevato numero di nodi.
Problemi non necessariamente di natura tecnica ma anche semplicemente di logistica, come ho
potuto notare. Ad esempio un nodo si era connesso ad una Venue sbagliata, non trovando così
nessuno degli altri partecipanti. Contattato telefonicamente ha semplicemente corretto l’indirizzo
della Venue alla quale collegarsi. Un altro ancora, invece di utilizzare la codifica audio consigliata
(‘linear 16’), ne utilizzava un’altra con l’effetto di introdurre disturbo all’apertura del suo
collegamento audio. Grazie alla chat di testo presente nella Venue, che utilizza il protocollo jabber,
è possibile scambiarsi consigli per risolvere questi inconvenienti. La qualità della conferenza è stata
buona, anche grazie ai corretti settaggi operati in fase di troubleshooting. Ci sono state poche
interruzioni dei flussi video, che ritengo siano ‘fisiologiche’, e soltanto da un sito arrivava un audio
con un po’ di underwater effect molto probabilmente dovuto ad un hardware di qualità non troppo
elevata.
Le altre videoconferenze alle quali ho partecipato non utilizzavano Access Grid ma altri sistemi di
videoconferenza tradizionali H.323, come ad esempio Vconf (il client era il software Polycom), e
mi hanno dato la possibilità di poter fare un primo confronto diretto con altre tecnologie in uso.
Dopo questo primo periodo di studio nel quale ho approfondito il funzionamento del software dal
punto di vista dell’utilizzatore, trovando soluzione ad alcuni problemi incontrati, gli sviluppi futuri
dell’attività riguarderanno i seguenti temi:

Realizzazione e configurazione di un server Access Grid, se possibile su più piattaforme;

L’aspetto della confidenzialità per capire come poter realizzare video cooperazioni
impedendo l’accesso alla Venue ad utenti non autorizzati;

Lo studio dettagliato delle possibilità realizzative di un nodo Access Grid, prendendo in
considerazione l’hardware necessario alla realizzazione di sale di medie e grandi
dimensioni;

L’approfondimento di quello che è l’obiettivo di Access Grid: permettere la costruzione di
ambienti cooperativi distribuiti;

Un confronto con altri sistemi di cooperazione a distanza per comprenderne meglio pregi e
difetti.
Come fatto fino ad ora, ho intenzione di sfruttare le conoscenze acquisite per la stesura di howto
sulle parti più complesse di funzionamento del software e di istruzioni aggiornate in italiano. Inoltre
sarò a disposizione per fornire supporto tecnico a quelle persone o enti, facenti parte della comunità
GARR, che vorranno utilizzare Access Grid.