Kometa, użycie responseText i pamięci

Question

Czy istnieje sposób na wyczyszczenie obiektu responseText obiektu XHR bez zniszczenia obiektu XHR?

muszę mieć otwarte stałe połączenie z serwerem WWW karmić dane dożyć przeglądarce. Problem polega na tym, że pojawia się stosunkowo duża ilość danych (kilkaset K na sekundę stale), więc użycie pamięci jest dużym problemem, ponieważ to połączenie musi pozostać otwarte przez co najmniej kilka minut. responseText bardzo szybko staje się bardzo duży, mimo że JSON, który wysyłam, został zmiażdżony tak mały, jak to tylko możliwe.

Ze względu na sposób działania aplikacji po stronie serwera, jeśli używam krótkiego sondowania w stylu AJAX i po prostu niszczę obiekt XHR, gdy go skończę, brakuje mi istotnych ilości ważnych danych nawet w ciągu kilku milisekund. trwa przetwarzanie odpowiedzi, tworzenie nowego XHR i wysyłanie go. Nie mam możliwości korzystania z nakładających się żądań, ponieważ serwer internetowy akceptuje tylko jedno połączenie naraz. (Nie pytaj.) Więc Comet jest dokładnie tym modelem, którego potrzebuję.

Co chcę zrobić, to przeanalizować każdą porcję JSON, gdy wraca z serwera, a następnie wyczyścić tekst responseText, aby móc nadal używać tego samego połączenia. Jednak responseText jest tylko do odczytu. Nie można go bezpośrednio opróżnić za pomocą jakiejkolwiek znalezionej metody.

Czy brakuje tu części obrazu? Czy ktoś wie jakieś sztuczki, które można użyć do zwolnienia responseText, gdy skończysz go czytając? Czy istnieje inne miejsce, w którym można uzyskać odpowiedzi serwera?

Nie uwzględniam kodu, ponieważ jest to właściwie pytanie niezastrzeżone przez kod. Procedury JavaScript, które odradzają XHR i obsługują zwrócone dane, są bardzo, bardzo proste.

Answer 1

Tak właśnie działa głosowanie długotrwałe. Zachowujesz indeks do ostatniego przeczytanego numeru linii i przy każdym teście interwału czyta się od tego momentu. To jedno długie połączenie, a więc jedna długa odpowiedź.

Świeży responseText oznaczałoby świeże połączenie. Ale wtedy nie byłoby już kometa;)

Answer 2

przeciwieństwie do innych odpowiedzi, „long-polling” nie jest jeden długi związek. "Long-polling" to wiele połączeń po kolei, każde skonfigurowane tak, aby pozostawały podłączone przez odpowiednio długi czas, jeśli nie jest potrzebna reakcja. Zostają one wylogowane (zwykle około 25-30 sekund), a następnie ponownie nawiązują nowe połączenie. Ponieważ protokół HTTP1.1 pozwala na ponowne wykorzystanie istniejących połączeń, połączenie nie musi być renegocjowane, a zatem można je przywrócić praktycznie natychmiast.

Po prostu użyj wielu żądań. Ponieważ naprawdę niewiele jest na głowie, aby ponownie nawiązać połączenie, a każde nowe połączenie pozwoli ci zniszczyć poprzedni tekst odpowiedzi, jest to całkowicie opłacalne rozwiązanie z perspektywy wydajności/narzutowej i rozwiąże również problemy z pamięcią.

[Edytuj] Mówię z doświadczenia, jako jeden z autorów WebSync.