Extreme Enthusiasm

Summary: renewed interest in “push” applications for the web

Il rinascimento in atto di Javascript permette di realizzare applicazioni sempre più sofisticate. Un pezzo difficile da realizzare però è un meccanismo per mandare informazioni sulla pagina web in maniera asincrona: pensate a una chat che deve aggiornarsi su tanti browser ogni volta che qualcuno, da qualche parte, scrive qualcosa.

Il web non supporta nativamente questo tipo di funzionalità. La maniera tradizionale di sopperire è il polling, che consiste nel bombardare ripetutamente di richieste il server per vedere se c’è qualche evento da riferire. Il problema con il polling è che se la frequenza è troppo elevata, il carico sul server cresce anche quando non c’è vera attività. Se la frequenza è troppo bassa, l’applicazione risponde più lentamente agli eventi.

La maniera di evitare questo compromesso fra latenza e frequenza è di fare un “polling lungo,” ovvero tenere in piedi una connessione aperta dal browser al server. Il server, invece di chiudere la connessione, la tiene aperta e trasmette qualche cosa solo quando c’è un evento da riferire. Chiaro che per implementare questo meccanismo occorre un web server configurato in maniera particolare.

Per inciso, questo tipo di meccanismo non è una novità. Da parecchi anni esiste la libreria pushlets. E in una tipica forma di ingiustizia informatica, il concetto si sta popolarizzando ora sotto il nome di comet.

Uno dei problemi di comet è che i web server non sono architettati per il tipo di traffico di queste applicazioni push. Di solito si assume che le connessioni al web server abbiano vita breve; in questo caso abbiamo invece un numero di connessioni che restano aperte pari al numero di client. Un web server di solito usa un algoritmo per cui per ogni connessione viene allocato un thread o un processo; ma questo meccanismo diventa troppo costoso in ambiente comet.

Il web server Jetty usa un’architettura più furba, basata su continuations, per cui quando una connessione comet è inattiva non ha associato nessun thread. I thread vengono pescati da un pool solo quando ci sono dati da trasmettere su una connessione, e subito dopo vengono restituiti al pool. Questo permette di gestire un numero di connessioni molto maggiore del numero di thread.

Su questa base Jetty fornisce non uno ma due meccanismi per realizzare un server push; il primo si basa su un tradizionale ActiveMQ, che è una tecnologia matura e ben integrata con Java tramite il protocollo JMS. Il secondo è un meccanismo più semplice, implementato direttamente in Jetty, basato sul protocollo Bayeux di Cometd. Mentre ActiveMQ fornisce tutte le garanzie di transazionalità di JMS, Cometd è più semplice, non richiedendo un processo addizionale.

Ci sono almeno due librerie Javascript che forniscono l’interfaccia lato client per comet. E uno sviluppo interessante è integrare Rails con comet. E’ possibile, e quelli di lingr l’hanno fatto.

This entry was posted on 25 January 2007 at 09:18 and is filed under Agile. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.