Comet, responseText и использование памяти

Есть ли способ очистить responseText объекта XHR, не уничтожая объект XHR?

Мне нужно поддерживать постоянное соединение с веб-сервером, чтобы передавать оперативные данные в браузер. Проблема в том, что проходит относительно большой объем данных (несколько сотен килобайт в секунду постоянно), поэтому использование памяти является большой проблемой, потому что это соединение должно оставаться открытым как минимум несколько минут. responseText очень быстро становится очень большим, даже несмотря на то, что JSON, который я отправляю обратно, был настолько мал, насколько это возможно.

Из-за того, как работает приложение на стороне сервера, если я использую короткий опрос в стиле AJAX и просто уничтожаю объект XHR, когда я закончу с ним, я пропускаю значительные объемы важных данных даже за те несколько миллисекунд, которые требуются для синтаксического анализа. ответ, создайте новый XHR и отправьте его. У меня нет возможности использовать перекрывающиеся запросы, так как веб-сервер принимает только одно соединение за раз. (Не спрашивайте.) Итак, Comet — именно та модель, которая мне нужна.

Что я хотел бы сделать, так это проанализировать каждый фрагмент JSON, когда он возвращается с сервера, а затем очистить responseText, чтобы я мог продолжать использовать одно и то же соединение. Однако responseText доступен только для чтения. Его нельзя очистить напрямую ни одним из найденных мной способов.

Есть ли часть картины, которую я здесь упустил? Кто-нибудь знает какие-нибудь приемы, которые я могу использовать, чтобы освободить responseText, когда я закончу его читать? Или есть другое место, куда могут отправляться ответы сервера?

Я не включаю код, потому что это действительно почти независимый от кода вопрос. Подпрограммы Javascript, которые порождают XHR и обрабатывают возвращаемые данные, очень и очень просты.


javascript ajax long-polling comet responsetext
person glomad    schedule 14.08.2009    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Именно так работает долгий опрос. Вы сохраняете индекс в последнем прочитанном номере строки и с каждым тиком вашего интервала читаете с этой точки вперед. Это одно длинное соединение, поэтому один длинный ответ.

Свежий responseText будет означать новое соединение. Но тогда это была бы уже не комета ;)

person Crescent Fresh    schedule 14.08.2009
comment
Спасибо. Я понимаю модель. Я просто надеялся, что есть способ поддерживать соединение без необходимости хранить все, что когда-либо было получено по этому соединению, в огромном буфере. В любом случае, длинный опрос — это хак, поэтому я думаю, что он многого требует, чтобы он работал именно так, как мне нужно :) - person glomad; 15.08.2009
comment
@ithcy: на самом деле это кажется разумным запросом. Я никогда особо не думал об этом, пока ты не спросил. xhr.flushResponseBuffer() или что-то в этом роде может быть полезным для длительных подключений и избавит от необходимости постоянно сохранять чертову ссылку на номер строки. - person Crescent Fresh; 15.08.2009

arrow_upward
4
arrow_downward

В отличие от другого ответа, «долгий опрос» — это не одно длинное соединение. «Долгий опрос» — это множество последовательных соединений, каждое из которых настроено так, чтобы оставаться на связи в течение достаточно длительного периода времени, если ответ не требуется. Они делают перерыв (обычно около 25–30 секунд), а затем восстанавливают новое соединение. Поскольку HTTP1.1 допускает повторное использование существующих соединений, повторное согласование соединения не требуется, и поэтому оно может быть восстановлено практически мгновенно.

Итак, просто используйте несколько запросов. Поскольку для восстановления соединения действительно незначительна дополнительная нагрузка, и каждое новое соединение позволит вам уничтожить предыдущий текст ответа, это вполне жизнеспособное решение с точки зрения производительности/накладных расходов, а также решит ваши проблемы с памятью.

[Изменить] Я говорю по своему опыту, как один из авторов WebSync.

person jvenema    schedule 01.04.2010