un`infrastruttura distribuita basata su jxta per la

AICA convegno
UN’INFRASTRUTTURA DISTRIBUITA BASATA SU JXTA
PER LA VISUALIZZAZIONE REMOTA DI MODELLI 3D
Andrea Sanna, Luigi Ciminiera, Claudio Zunino, Fabrizio Lamberti
Dipartimento di Automatica e Informatica
Politecnico di Torino
Corso Duca degli Abruzzi 24, 10129 Torino
{andrea.sanna, luigi.ciminiera, claudio.zunino, fabrizio.lamberti}@polito.it
SOMMARIO
I dispositivi mobili stanno cambiando velocemente l’interazione
uomo-macchina in quanto PDA, Tablet PC e telefoni cellulari dell’ultima
generazione consentono un accesso alle risorse della rete indipendente
dalla locazione fisica.
La possibilità di accedere a risorse remote è sicuramente un aspetto
positivo che però fa nascere il problema dell’efficienza nella ricerca e nel
reperimento delle risorse medesime.
Questo articolo presenta un’infrastruttura distribuita per la ricerca di
modelli tridimensionali; tutte le risorse del sistema sono fornite da entità
denominate provider, mentre le interrogazioni dell’utente sono gestite da
altre entità dette broker. Quando un modello è stato identificato è possibile
effettuarne la visualizzazione anche su dispositivi mobili utilizzando la
potenza di calcolo di server di rendering remoti.
1. INTRODUZIONE
I dispositivi mobili offrono nuovi e affascinanti scenari di interazione uomomacchina. In particolare, la possibilità di un accesso indipendente dalla locazione
fisica permette all’utente di disporre senza limiti spaziali e temporali di enormi
quantità di informazioni. Per contro, i dispositivi mobili non possono ancora essere
confrontati con sistemi desktop in termini di potenza di calcolo e storage. Questo
diventa un serio limite in applicazioni come la grafica tridimensionale, dove l’utente
deve essere poter visualizzare in modo interattivo scene costituite da centinaia di
migliaia di poligoni texturizzati. Navigare scene con queste caratteristiche può essere
fatto solo utilizzando l’hardware specializzato di server di calcolo grafico.
Questo lavoro presenta un’infrastruttura distribuita basata sulla tecnologia JXTA
[Gong, 2001] (http://www.jxta.org). Nell’architettura sono presenti tre “ruoli”: provider,
AICA convegno
broker e gateway (vedi Figura 1). I provider sono quelli che forniscono le risorse del
sistema, ovvero dati (i modelli 3D) e le risorse di calcolo per il rendering remoto. Un
provider di dato (denominato nel seguito Data Provider) memorizza dati, i modelli veri
e propri, e metadati, ovvero descrizioni in formato XML [Harold e Means, 2002] delle
risorse stesse. I provider di calcolo (denominati Service Provider) sono realizzati, in
questo caso, mediante cluster di calcolatori equipaggiati con schede video
acceleratici e connessi tra loro da una rete locale ad alta velocità (Fast o Giagabit
Ethernet). I broker gestiscono i vari provider e “servono” le interrogazioni dell’utente;
quando un broker riceve la query di un utente la veicola ai data provider ad esso
collegati e ai suoi broker vicini. Incrementalmente, il broker che riceve la query,
presenta i risultati man mano che arrivano dai suoi data provider e dagli altri broker
dell’architettura. Il punto di accesso al sistema è costituito dai gateway che
permettono all’utente di formulare le query e presentano i risultati provenienti dai
broker. Quando l’utente seleziona un modello questo viene trasferito dal data
provider ad un service provider disponibile; a questo punto la comunicazione è diretta
tra il service provider e il client (vedi linee tratteggiate in Figura 1). Il service provider
invia uno stream video MPEG al client, mentre l’utente, tramite un’apposita
interfaccia, può inviare una serie di comandi per navigare la scena e analizzare gli
oggetti.
Figura 1 Architettura del sistema.
L’articolo è organizzato come segue: la Sezione “Tecnologie grid e P2P” rivede
le tecnologie grid e P2P più significative. La sezione successiva presenta
brevemente JXTA, mentre la Sezione “Visualizzazione remota” descrive lo stato
dell’arte delle tecniche di visualizzazione remota. La sezione “L’architettura proposta”
analizza nei dettagli le varie componenti del sistema; infine, la sezione “Test”
presenta alcuni risultati ottenuti realizzando una piccola griglia tra le varie sedi del
Politecnico di Torino.
2. TECNOLOGIE GRID E P2P
Due tipi di tecnologie sono note per realizzare ambienti distribuiti votati al
calcolo distribuito e alla condivisione di risorse: griglie e P2P. Sebbene queste ultime
siano nate con lo scopo primario di permettere agli utenti di condividere file, la
distinzione attuale tra griglie e P2P è sempre più difficile da individuare: le tecnologie
grid incorporano sempre più soluzioni e caratteristiche del P2P e viceversa. Un P2P
propriamente detto prevede un accesso diretto tra due nodi (peer) della rete che
vogliono comunicare; un peer può fungere sia da client sia da server e alcune volte
AICA convegno
viene detto servent. Per contro, il classico paradigma del grid prevede un approccio
client-server.
Sia le griglie che le tecnologie P2P hanno l’obiettivo di rendere disponibili
risorse di calcolo e di memorizzazione interconnesse da un sistema di
comunicazione e coordinate da sistemi informativi e decisionali in grado di sfruttare al
meglio ciascuna risorsa. L’interoperabilità è un elemento molto importante in un
ambiente distribuito, perché bisogna assicurare che le richieste di condivisione di
risorse possano essere iniziate da una parte arbitraria ospitando nuovi partecipanti
dinamicamente attraverso differenti piattaforme, linguaggi e ambienti di
programmazione. Il sistema distribuito deve offrire al generico utente tutta la risorsa
computazionale o di memorizzazione richiesta, evitandogli la necessità di una diretta
gestione e mantenimento. In altri termini, l’utente vede il sistema come un’unica
risorsa alla quale sottomette una propria richiesta. Le griglie sono attualmente
oggetto di ricerche in differenti nazioni. In particolare, esistono due progetti che si
occupano della definizione dei servizi necessari alla gestione di una griglia. Uno dei
due progetti prende il nome di Globus [Foster e Kesselman, 1997] [Foster e
Kesselman, 1998] [Foster et al, 2001] ed è supportato da enti quali DARPA, NASA e
National Science Foundation. Il progetto Globus mira a sviluppare tecnologie di base
necessarie a costruire una griglia computazionale [Bester et al, 1999] [Foster et al,
1998a] [Foster et al, 1998b] [Foster et al, 1999] [Laszewski e Foster, 1999]
[Laszewski et al, 2000] [Lee et al, 1998] [Lee et al, 1999] [Stelling et al, 1998]. L’altro
progetto è chiamato Condor [Basney et al, 1997], il cui obiettivo principale è quello di
sviluppare, implementare, e valutare meccanismi e politiche tali da supportare l'High
Throughput Computing (HTC) su vasti insiemi di risorse di calcolo.
Come detto in precedenza, in un’architettura P2P non esiste un server centrale;
in particolare, in un P2P “puro” tutto i peer hanno lo stesso ruolo, ad esempio in
Gnutella [Clip2] e Freenet [Clarke et al, 2000]. Nei P2P parzialmente centralizzati, ci
sono alcuni nodi che assumo un ruolo più importante degli altri (ad esempio
Morpheus e Kazaa), mentre nei P2P strutturati l’allocazione dei dati dipende dalla
topologia della rete (ad esempio Chord [Stoica et al, 2001], Can [Ratnasamy et al,
2001] e Pastry[Rowstron e Druschel, 2001]). Per una più dettagliata descrizione vedi
[Androutsellis, 2002].
3. JXTA
JXTA è un progetto open-source che definisce un insieme di protocolli per il
P2P. Tali protocolli permettono di stabilire una rete virtuale sopra Internet, o sopra
una rete non basata sul protocollo IP, in modo che i peer possano direttamente
interagire e organizzarsi indipendentemente. JXTA è stata pensata per essere
indipendente dai linguaggi di programmazione, dal sistema operativo e
dall’infrastruttura di rete sottostante. L’architettura di JXTA è divisa in tre layer (vedi
Figura 2):
- platform layer (core)
- service layer
- application layer
Il platform layer contiene le primitive essenziali che sono comuni a tutte le reti P2P;
ad esempio, include i meccanismi per la creazione dei peer e dei peer group, nonché
i meccanismi di discovery ad essi associati. Il service layer include i servizi di rete
che possono non essere necessari, ma sono comuni e desiderabile. Infine,
l’application layer include la realizzazione di applicazioni come l’instant messaging, il
AICA convegno
resource sharing e così via. Un’architettura JXTA consiste di una serie di nodi
interconnessi (i peer) che possono essere: sensori, Personal Computer, PDA,
telefoni cellulari, server, super-computer. Ogni peer agisce indipendentemente e
asincronamente ed è univocamente identificato da un peer identifier. I peer possono
essere organizzati in gruppi che logicamente forniscono un insieme comune di
servizi. Un peer comunica la lista di servizi che mette a disposizione mandando agli
altri nodi dei messaggi in formato XML detti advertisement. Gli advertisement
abilitano gli altri peer della rete a connettersi e ad usufruire dei servizi che un certo
nodo mette a disposizione. JXTA usa delle strutture denominate pipe per lo scambio
dei messaggi tra i peer; le pipe funzionano in modo asincrono e unidirezionale. JXTA
prevede la presenza di due tipi di peer: rendezvous e edge. I peer rendezvous
funzionano come un router in una rete, ovvero hanno il compito di instradare i
messaggi per permettere a edge peer che non si conoscono direttamente di
comunicare. I rendezvous peer danno inoltre la possibilità di aggirare configurazioni
di rete protette da firewall e NAT.
Figura 2 Organizzazione a livelli di JXTA.
La convergenza tra le tecnologie grid e P2P, e in particolare con JXTA, è comprovata
da progetti come jxta-grid (http://jxta-grid.jxta.org/) che mirano ad unire la flessibilità,
tipica delle tecnologie P2P, e la stabilità tipica del grid. Jxta-grid usa Globus (nella
versione OGSA) per l’allocazione dei job e in generale per la gestione delle risorse,
mentre JXTA fornisce i meccanismi per la gestione dell’infrastruttura distribuita al fine
di consentire ai vari peer di trovarsi e pubblicizzare i servizi offerti. La SUN ha inoltre
sviluppato JxGrid che va ad aggiungere una serie di servizi per il grid al livello JXTA
Service e una serie di applicazioni, sempre orientate al grid, al livello JXTA
Applications. L’utilizzo di JXTA è allo studio anche del progetto Commodity Grid Kits
(CoG - http://www-unix.globus.org/cog/) dove si analizza l’uso della tecnologie P2P
per la costruzione di servizi orientati al grid.
4. VISUALIZZAZIONE REMOTA
In letteratura sono note alcune soluzioni che permettono la visualizzazione
locale su dispositivo mobile di grafica tridimensionale (ad esempio quelle basate su
PocketGL, una versione per palmari delle popolari OpenGL [Shreiner et al, 2003]) ma
si sono rivelate insufficienti per la manipolazioni di scene complesse. La soluzione,
ben nota in questi casi, è quella di affidare il compito di visualizzare la scena ad un
sistema remoto e di inviare poi la scena renderizzata al front-end dell’utente.
AICA convegno
Un sistema di volume rendering distribuito è stato sviluppato in [Bethel, 2000];
questa applicazione prende il nome di Visapult e fornisce capacità di visualizzazione
interattiva remota utilizzando due componenti: un motore di volume rendering
parallelo e un visualizzatore basato su OpenGL. Engel ed altri proposero in [Engel et
al, 2000] un’architettura dove un server di visualizzazione inviava immagini
compresse a client Java e l’interazione con l’applicazione si otteneva inviando
richieste CORBA [Bolton, 2001]. Una soluzione per dati varianti nel tempo è stata
proposta in [Ma e Camp, 2000]; l’architettura è composta da due parti: la prima riceve i
dati dal processo di rendering, comprime le informazioni e manda le informazioni alla
seconda parte che le decomprime e le presenta all’utente. Una soluzione generica
per la visualizzazione remota basata su hardware accelerato è presentata in
[Stegmaier et al, 2002] ed è basata sul concetto di link dinamico e delle funzionalità
di un’estensione delle OpenGL per il sistema X-Window. Le applicazioni OpenGL
vengono eseguite localmente ad un server di rendering ma l’output è configurato in
modo da essere mandato ad un client di visualizzazione. Il sistema usa l’infrastruttura
Virtual Network Computing (VNC) per la trasmissione dell’immagine tra client e
server. Lamberti ed altri [Lamberti et al, 2003] proposero un’architettura basata su
Chromium [Humphreys et al, 2002]; Chromium permette di dividere il calcolo del
rendering di una scena tra le schede video di un cluster di elaboratori e poi di
riassemblare l’immagine risultante. In [Humphreys et al, 2002], l’immagine statica
calcolata dal cluster veniva trasmessa ad un PDA client che mostrava l’immagine
contornata da un’apposita interfaccia mediante la quale l’utente poteva impartire
comandi di roto-traslazione ed ottenere informazioni sul modello e sulle prestazioni
(vedi Figura 3).
Figura 3 Esempio di visualizzazione remota su PDA [28].
Silicon Graphics Inc. ha proposto una soluzione commerciale denominata
Vizserver (http://www.sgi.com/) che permette a singoli server grafici proprietari (ad
esempio macchine della famiglia Onyx) di configurarsi come server di rendering
multiuser, abilitando sessioni di visualizzazione remote e collaborative.
5. L’ARCHITETTURA PROPOSTA
Come detto, la Figura 1 mostra l’architettura proposta. Broker e data provider
sono stati sviluppati come applicazioni Java in modo da soddisfare i requisiti di
AICA convegno
portabilità. Sebbene concettualmente differenti, entrambi sono stati realizzati come
una gerarchia di moduli (vedi Figura 4):
- al livello più basso della gerarchia si trovano i moduli di storage e network. Il primo
è quello che permette di immagazzinare e indicizzare le risorse (i modelli 3D).
Data provider e broker differiscono perché questi ultimi non hanno il modulo di
storage. Il modulo network è stato sviluppato in modo da interagire con il
middleware sottostante (JXTA) per gestire l’infrastruttura di rete
- un modulo manager che deve gestire gli altri moduli e gli eventi da essi generati.
In particolare, il modulo event manager ha il compito di instradare gli eventi dai
moduli all’interfaccia e viceversa
- al livello più alto della gerarchia si trova l’interfaccia dell’applicazione che permette
di aggiungere-eliminare delle risorse e ottenere delle informazioni sulla topologia
del sistema
A livello di configurazione JXTA, i broker sono inizializzati come rendezvous
peer, mentre i provider come edge peer. Ogni broker ha una lista di “broker vicini” ai
quali inoltrerà messaggi provenienti da provider, da lui direttamente gestiti, che
hanno come destinatario un peer non appartenente al gruppo da lui gestito. Come
detto precedentemente, un rendezvous peer, e quindi un broker, può essere pensato
come un router che coordina tutte le macchine di una rete locale (l’equivalente degli
edge peer). Se un peer manda un messaggio ad un nodo non coordinato dallo
stesso rendezvous, quest’ultimo provvederà ad inoltrare l’informazione agli altri
rendezvous a lui noti.
Quando un broker riceve una query da un gateway esegue una serie di
operazioni che servono per interrogare tutti i data provider del sistema:
- propaga la query ai data provider direttamente connessi (se esistono)
- propaga la query ai broker vicini (se esistono) usando il metodo dei walker
[Traversat et al, 2003]
- riassembla i risultati che arrivano dai data provider e li presenta all’utente
Figura 4 Struttura dell'applicazione che realizza broker e data provider. I broker non hanno il
modulo di storage.
Allo stesso modo, quando un broker riceve un walker lo propaga ai broker a lui
direttamente collegati; il meccanismo dei walker di JXTA garantisce che non si
verifichino loop nella propagazione delle query. L’utente può scegliere da quale
locazione scaricare una risorsa nel caso questa sia presente su più data provider; la
scelta può avvenire in base al tempo di risposta dei provider stessi che può essere
interpretato come una sorta di qualità del servizio (QoS).
AICA convegno
Il modello selezionato dall’utente è scaricato sul broker che ha ricevuto la query
dal gateway. I broker hanno la lista dei service provider presenti nel sistema, quindi,
possono mandare il modello ad un service provider ed inviare al client tutte le
informazioni per avviare una sessione (indirizzo IP, numero di porta, e così via).
Quando un service provider instaura una sessione di visualizzazione con un client,
informa il broker a cui è direttamente connesso che non sarà in grado di accettare
altre connessioni; il broker veicolerà questa informazione a tutti i broker con un
meccanismo analogo a quello di propagazione delle query affinché il service provider
venga marcato come “non disponibile” nelle liste dei broker.
L’architettura di un service provider è mostrata in Figura 5. Un service provider
può essere disponibile (pronto a calcolare lo stream MPEG di visualizzazione per un
client) o non disponibile (ad esempio perché l’hardware grafico, che non è utilizzabile
in time sharing, è già in uso da un altro processo di rendering). Ogni service provider
è descritto mediante un documento XML che riporta tutti i parametri necessari per
stabilire una connessione remota tra il provider stesso e un client.
Figura 5 Architettura dei service provider.
Un modulo denominato Interaction Module (in esecuzione su una macchina
master del service provider) controlla la comunicazione tra l’applicazione che viene
eseguita sul provider e l’applicazione di visualizzazione lato client. In particolare,
questo modulo riceve i comandi di roto-traslazione che permettono all’utente di
analizzare la scena e restituisce uno stream MPEG. Il rendering è diviso tra le
schede grafiche degli elaboratori slave del service provider mediante una Stream
Processing Unit (SPU) di Chromium, quindi, ogni slave è incaricato di calcolare una
porzione di ogni fotogramma. Finito il calcolo, ogni slave invia la sua parte
all’elaboratore master su cui si trova l’Interaction Module che riassembla il
fotogramma, crea lo stream MPEG e lo manda al client remoto.
L’applicazione di visualizzazione (vedi Figura 6) in esecuzione su un client non
fa realmente parte dell’architettura del sistema. L’utente può impartire i comandi
agendo sul touch-screen del dispositivo e/o usando il directional pad o gli application
button in caso di un dispositivo PDA.
AICA convegno
L’applicazione di visualizzazione è stata sviluppata usando l’ambiente Microsoft
Visual C++ per WindowsCE 3.0 e l’SDK per PocketPC. L’applicazione è composta da
tre moduli:
- l’interfaccia grafica (GUI)
- il generatore di comandi
- il decodificatore
L’interfaccia gestisce gli eventi prodotti dai dispositivi di input (il pennino, il
navigation pad e gli application button) e li trasmette, previa una conversione di
formato, al generatore di comandi che li invia al service provider. Il decoder riceve lo
stream MPEG dal service provider lo decodifica e aggiorna la porzione di video
dedicata alla visualizzazione.
Figura 6 Applicazione di visualizzazione dei modelli 3D lato client.
6. TEST
Al fine di collaudare il sistema, si è realizzata un’architettura distribuita
geograficamente tra le varie sedi del Politecnico di Torino. In ogni sede è stato
installato un broker incaricato di gestire due o tre data provider; un unico service
provider è stato installato nella sede di Torino (il service provider era costituito da un
cluster di otto PC equipaggiati con schede grafiche Nvidia GeForce2 e interconnessi
mediante uno switch Gigabit-Ethernet; una delle otto macchine era configurata come
server e quindi incaricata di dividere il calcolo tra gli elaboratori slave e di
riassemblare i risultati). Il dispositivo mobile di prova scelto è un PDA Compaq iPaq
H3630 equipaggiato con un processore StrongARM a 206MHz.
L’analisi del sistema può essere divisa in due parti: il reperimento dei dati
(ovvero del modello) e la visualizzazione dei medesimi. Le prestazioni della prima
fase dipendono strettamente dalla velocità delle connessioni di rete; nei nostri
esempi i database dei data provider erano popolati con un centinaio di modelli,
perciò, il ritardo introdotto dai database per gestire le query è risultato trascurabile. I
tempi di risposta hanno variato da alcuni decimi di secondo a alcune decine di
secondi. Allo stesso modo i tempi di trasferimento dei file sono dipesi dalle velocità
delle connessioni di rete (il traferimento di file dell’ordine di alcuni MB ha richiesto
tempi dell’ordine delle decine di secondi). La latenza dovuta alla visualizzazione
dipende da:
- il ritardo per trasmettere un comando dal client all’Interaction Module
- l’applicazione del comando
- la trasmissione dello stream video
AICA convegno
- la decodifica dello stream e l’aggiornamento dell’area di visualizzazione sul
dispositivo client
Un’attenta analisi ti tutti questi parametri ha permesso di identificare la soglia
dei 25 fotogrammi per secondo (ad una risoluzione di 240x240 pixel) come il frame
rate massimo ottenibile sul PDA scelto. La Figura 7 mostra un esempio di
visualizzazione di un modello sia sulla console del server di rendering sia sul
dispositivo palmare.
Figura 7 Visualizzazione di un modello di automobile sulla console del service provider e del
dispositivo PDA.
7. CONCLUSIONI
L’articolo propone un’infrastruttura distribuita basata su tre ruoli: broker,
provider e gateway. I gateway sono i punti di accesso al sistema e permettono
all’utente di cercare risorse (modelli tridimensionali) e ottenere servizi di calcolo (la
visualizzazione in tempo reale dei modelli da parte di sistemi di rendering
specializzati). I broker hanno il compito di gestire le query provenienti dai gateway,
smistando le richieste ai provider (che posso fornire dati o calcolo) e raccogliendo i
risultati da presentare all’utente.
Il sistema si configura come un’infrastruttura ibrida tra una griglia (i broker
costituiscono un meccanismo “centralizzato” di controllo sia della topologia
dell’infrastruttura sia delle risorse del sistema) e una rete P2P dove i nodi possono
agevolmente aggiungersi per offrire nuovi servizi. I meccanismi di costituzione della
rete si basano su JXTA, che permette di configurare dei peer come rendezvous
garantendo così estrema flessibilità nella costituzione di peer-group e nella scoperta
dei servizi e delle risorse.
Il lavoro proposto è collocabile nell’ambito di quei progetti che mirano a unire gli
aspetti positivi del grid e del P2P (nella fattispecie di JXTA) unendo affidabilità e
flessibilità. La possibilità di un discovery dinamico delle risorse e dei peer esistenti
“alleggerisce” il carico di lavoro di un manager centralizzato tipico delle infrastrutture
grid, mentre una topologia controllata permette di ottenere bilanciamento del carico e
un efficiente utilizzo delle risorse.
BIBLIOGRAFIA
Androutsellis-Theotokis S., A Survey of Peer-to-Peer File Sharing Technologies, White paper, Athens
University of Economics and Business, 2002
Basney J., Livny M., Tannenbaum T., High Throughput Computing with Condor, HPCU news, 1, 2,
1997.
AICA convegno
Bester J., Foster I., Kesselman C., Tedesco J., Tuecke S., GASS: A Data Movement and Access
Service for Wide Area Computing Systems. Sixth Workshop on I/O in Parallel and Distributed
Systems, 1999.
Bethel W., Visualization viewpoints: Visualization dot com. IEEE Computer Graphics and Applications,
20, 3, 2000, 17-20.
Bolton F., Pure Corba, Pearson International, 2001.
Clarke I., Sandberg O., Wiley B., Freenet: A distributed anonymous information storage and retrieval
system, In Proceedings of the Workshop on Design Issues in Anonymity and Unobservability, 2000.
Clip2, The Gnutella Protocol Specification v0.41, Document Revision 1.2.
Engel K., Sommer O., Ertl T., A Framework for Interactive Hardware Accelerated Remote 3DVisualization, In Proceedings of EG/IEEE TCVG Symposium on Visualization VisSym00, 2000,
pp.167-177.
Foster I., Kesselman C., Globus: A Metacomputing Infrastructure Toolkit, Intl J. Supercomputer
Applications, 11, 2, 1997, 115-128.
Foster I., Kesselman C, The Globus Project: A Status Report, Proc. IPPS/SPDP '98 Heterogeneous
Computing Workshop, 1998, pp.4-18.
Foster I., Kesselman C., Tsudik G., Tuecke S., A Security Architecture for Computational Grids, Proc.
5th ACM Conference on Computer and Communications Security Conference, 1998, pp.83-92.
Foster I., Karonis N.T., Kesselman C., Tuecke S., Managing Security in High-Performance Distributed
Computing. Cluster Computing, 1, 1, 1998, 95-107.
Foster I., Kesselman C., Lee C., Lindell R., Nahrstedt K., Roy A., A Distributed Resource
Management Architecture that Supports Advance Reservations and Co-Allocation, Intl Workshop on
Quality of Service, 1999.
Foster I., Kesselman C., Tuecke S., The Anatomy of the Grid: Enabling Scalable Virtual
Organizations, Intl. J. Supercomputer Applications, 2001.
Gong, L., JXTA: A network programming environment, IEEE Internet Computing, 5, 2001, 88–95.
Harold E.R., Means W.S., XML in a Nutshell, 2nd edition, O’Reilly & Associates, 2002.
Humphreys G., Houston M,.Ng R, Frank R., Aherns S., Kirchner P.D., Klosowski J T, Chromium: a
stream-processing framework for interactive rendering on clusters, In Proceedings of the 29th annual
conference on Computer graphics and interactive techniques, ACM Press, 2002, pp.693–702.
Lamberti F., Zunino C., Sanna A., Fiume A., Maniezzo M., An Accelerated Remote Graphics
Architecture for PDAs, Proceedings of ACM/SIGGRAPH Web3D 2003 Symposium, 2003, pp.5561:203.
Laszewski G. von, Foster I., Grid Infrastructure to Support Science Portals for Large Scale
Instruments. Proc. of the Workshop Distributed Computing on the Web (DCW), 1999.
Laszewski G. von, Foster I., Gawor J., Smith W., Tuecke S., CoG Kits: A Bridge between Commodity
Distributed Computing and High-Performance Grids, ACM 2000 Java Grande Conference, 2000.
Lee C., Kesselman C., Stepanek J., Lindell R., Hwang S., Michel B.S., Bannister J., Foster I., Roy A.,
The Quality of Service Component for the Globus Metacomputing System, Proc. IWQoS, 1998,
pp.140-142.
Lee C., Wolski R., Foster I., Kesselman C., Stepanek J., A Network Performance Tool for Grid
Computations, Supercomputing, 1999.
Ma K.L., Camp D.M., High performance visualization of time-varying volume data over a wide-area
network status, In Proceedings of the 2000 ACM/IEEE conference on Supercomputing (CDROM),
IEEE Computer Society Press, 2000.
Ratnasamy S., Francis P., Handley M., Karp R., Shenker S., A Scalable Content-Addressable
Network, , In ACM SIGCOMM, 2001, pp.161-172.
AICA convegno
Rowstron A., Druschel P., Pastry: Scalable, Distributed Object Location and Routing for Large-Scale
Peer-to-Peer Systems, In Proceedings of the IFIP/ACM International Conference on Distributed
Systems Platforms, 2001.
Shreiner D., Woo M., Neider J., Davis T., OpenGL Architecture Review Board, OpenGL Programming
Guide: The Official Guide to Learning OpenGL, Version 1.4, 4th edition, Addison-Wesley, 2003.
Stelling P., Foster I., Kesselman C., Lee C., Laszewski G. von., A Fault Detection Service for Wide
Area Distributed Computations, Proc. 7th IEEE Symp. on High Performance Distributed Computing,
1998, pp.268-278.
Stegmaier S., Magallón M., Ertl T., A Generic Solution for Hardware-Accelerated Remote
Visualization. In Procceedings of EG/IEEE TCVG Symposium on Visualization VisSym02, 2002,
pp.87-94.
Stoica I., Morris R., Karger D., Kaashoek M.F., Balakrishnan H., Chord: A Scalable Peer-to-Peer
Lookup Service for Internet Applications, In ACM SIGCOMM, 2001, pp.149-160.
Traversat B., Abdelaziz M., Pouyoul E., Project JXTA: A Loosely-Consistent DHT Rendezvous
Walker, 2003, http://www.jxta.org/docs/jxta-dht.pdf