Premetto che non si tratta di comete come Comet Holmes...

Cos'è Comet?
Bisogna partire, come nell'articolo su CSRF, dal meccanismo richiesta/risposta del web.

Molto semplicisticamente, ogni volta che vogliamo una risorsa dal web (ad esempio una pagina di wikipedia) inviamo una richiesta e otteniamo una risposta, o meglio apriamo un "canale" inviamo la richiesta sul canale, riceviamo una risposta sul canale e chiudiamo il canale. Un canale eh? Immaginate un tubo che va dal vostro PC al server dove risiede la risposta che desiderate.

Un tempo le richieste erano per lo più fatte per ottenere pagine intere. Oggi, grazie all'hype generato dalla parola AJAX molte volte ci troviamo a non richiedere pagine intere ma pezzetti di pagine, ad esempio se rimanete a fissare -intensamente- GMail vedrete che la vostra pagina s'aggiorna con le nuove email senza essere completamente ricaricata.
Per fare ciò (ritirare pezzetti) si usa comunque un meccanismo di richiesta risposta ma in questi casi la richiesta viene fatta automaticamente senza bisogno di cliccare alcun che, è questa la "magia" di AJAX (anche se possibile già prima di AJAX...ma questa è un altra storia). [GMail di tanto in tanto apre il canale, manda una richiesta "C'è nuova posta?" al server, che risponde "no" oppure "si, questa: ..." e poi chiude il canale: se avete firebug rendetelo visibile e guardate il tab "NET" vedrete di tanto in tanto che scarica qualcosa].

Ma sto Comet? Dunque con l'approccio "ogni tanto invio la richiesta" ci sono 2 principali svantaggi:


  • il primo (poco comprensibile se non si hanno nozioni di http...) è il ripetersi degli header che genarano traffico inutile sulla rete (spreco di banda insomma).

  • il secondo sta nella latenza dei dati, cioè il tempo tra quando il dato è disponibile e quando arriva nella vostra pagina. Immaginate che vi inviino una mail ogni minuto. Se gmail chiedesse al server se ci sono nuove mail ogni 2 minuti, sicuramente non tutte le mail vi arriverebbero il prima possibile. In generale questo può essere più o meno un problema a seconda dei dati di cui si parla (immaginate un trader che aspetta le ultime quotazioni).



Qui entra in gioco Comet che stravolge questo meccanismo. Con comet il canale viene aperto, la richiesta inviata ma la risposta può:

  • Non essere immediata (caso long-polling e streaming). Non c'è più necessita che il server di GMail risponda "non c'è nuova posta" e chiuda il canale, con questo approccio tal server potrebbe semplicemente aspettare col canale aperto e non appena una nuova mail è disponibie mandarla, il tutto senza dover mai mandare risposte negative (meno banda e meno latenza). [In una situazione di long-polling dopo la risposta il canale verrebbe chiuso e subito riaperto, in caso streaming sarebbe tenuto aperto].

  • Essere più di una (caso streaming). Aprire il canale e inviare la richiesta implica dei tempi "lunghi" e uno scambio di headers. Potendo ricevere più risposte sullo stesso canale si eliminano in buona parte questi tempi e questi headers (ancora meno banda e ancora meno latenza). Lo streaming può essere fondamentale per questi motivi in alcune situazioni. Pensate al buon vecchio trader che deve avere sempre la quotazione più fresca possibile, non può ad ogni nuova quotazione "aspettare" che il canale venga chiuso e poi riaperto col rischio di avere alcuni dati con latenza maggiore!


Ora è chiaro cos'è comet?
Eccovene un paio di esempi live, quelli che sono secondo me più rappresentativi:
Simulazione di quotazioni
Basilare simil-chat carattere per carattere (per goderla appieno aprirla su 2 finestre differenti o farla aprire a qualcun'altro contemporaneamente a voi)
Se non vi bastano ce ne sono comunque altre.
E infine se volete vedere un'applicazione (cioè non una demo) vi consiglio igindex, il box centrale "Live prices" e l'applicazione interna accessibile previa registrazione sono aggiornate con Comet.

Il paper (come si dice in italiano??) Changing the Web Paradigm di Alessandro Alinone è un approfondimento consigliato.