un`infrastruttura distribuita basata su jxta per la
Transcript
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