Comet, responseText e della memoria

Question

C'è un modo per cancellare la responseText di un oggetto XHR senza distruggere l'oggetto XHR?

Ho bisogno di mantenere una connessione permanente aperta a un server web per alimentare dati in tempo reale a un browser. Il problema è che c'è una quantità relativamente grande di dati provenienti attraverso (diverse centinaia K al secondo costante), quindi l'utilizzo della memoria è un grosso problema, perché questa connessione deve rimanere aperta per almeno diversi minuti. responseText diventa molto grande molto rapidamente, anche se il JSON rimando è stato scricchiolava piccolo come si può ottenere.

A causa del modo in cui l'applicazione lato server funziona, se uso in stile AJAX breve polling e solo distruggere l'oggetto XHR quando ho finito con lui, mi manca una notevole quantità di dati importanti anche nei pochi millisecondi ci vuole per analizzare la risposta, creare un nuovo XHR e inviarlo. Non ho la possibilità di utilizzare le richieste sovrapposte, come il web server accetta una sola connessione alla volta. (Non chiedere.) Così Comet è esattamente il modello di cui ho bisogno.

Quello che vorrei fare è analizzare ogni blocco JSON come si ritorna dal server, e quindi sgombrare responseText in modo che possa continuare a utilizzare la stessa connessione. Tuttavia, responseText è di sola lettura. Non può essere svuotato direttamente mediante qualsiasi metodo che ho trovato.

C'è una parte del quadro che mi manca qui? Qualcuno sa qualsiasi trucchi che posso usare per liberare responseText quando ho finito di leggerlo? O c'è un altro luogo le risposte del server possono andare?

Non ho incluso il codice perché questo è davvero quasi una domanda di code-agnostico. Le routine JavaScript che depongono le uova le XHR e gestiscono i dati restituiti sono molto, molto semplice.

Answer 1

Questo è solo come funziona a lungo polling. Continui a un indice nell'ultima numero di riga leggere e con ogni tick del vostro intervallo di leggere da quel punto in avanti. Si tratta di una connessione a lungo, così una risposta a lungo.

Un responseText fresco significherebbe una connessione fresca. Ma allora non sarebbe la cometa più;)

Answer 2

Contrariamente alla altra risposta, "a lungo polling" non è un collegamento lungo. "Long-polling" è molte connessioni in sequenza, ogni set fino a rimanere connessi per un periodo ragionevolmente lungo di tempo, se non è necessaria alcuna risposta. Essi do time out (in genere circa 25-30s), e poi ri-stabilire una nuova connessione. Dal momento che HTTP1.1 permette per il riutilizzo delle connessioni esistenti, il collegamento non deve essere rinegoziato, e può quindi essere ristabilita praticamente all'istante.

Quindi, basta usare più richieste. Poiché non v'è davvero in testa trascurabile per ristabilire la connessione, e ogni nuova connessione vi permetterà di distruggere il testo di risposta precedente, questa è una soluzione perfettamente valida dal punto di vista delle prestazioni / in testa, e avrebbe risolto i vostri problemi di memoria pure.

[Modifica] Sto parlando per esperienza, come uno degli WebSync gli autori.