XHR постоянное соединение, как так?

Question

Я только что читал, как FaceBook разработал свою систему чата, и там написано: "и наличие этого iframe JavaScript отправляет HTTP-запрос GET через постоянное соединение, которое не возвращается, пока на сервере не будет данных для клиента. Запрос восстанавливается, если он прерывается или истекает время ожидания. Это никоим образом не является новой техникой : это вариант Comet, в частности, длинный опрос XHR и / или BOSH. "

Может кто-нибудь объяснить, как вы можете постоянный запрос к веб-серверу?

Answer 1

По сути, вы просто удерживаете запрос на сервере, пока либо 1) не появятся доступные данные, либо 2) сервер не достигнет порогового значения и не скажет: «забудь это, восстанови, чтобы я знал, что ты действительно все еще там».Сложность этого подхода заключается в масштабируемости серверной стороны, поскольку обычно веб-серверы предназначены для максимально быстрого выполнения, а порождение большого количества потоков / процессов для входящих «долго удерживаемых» запросов затруднено.

Этот длительный запрос обычно Xhr, если он находится в одном домене, или JSONP, если он междоменный.

Мы написали полный кометный клиент для нашего сервера IIS / ASP.NET Comet ( WebSync ), который вы можете проверить и, возможно, получить представление.Найдите в источнике файл client.js (отметьте? Debug = true, чтобы увидеть несжатую версию), и вы увидите некоторые ссылки на запросы "connect" - это запросы на длинный опроссервер, который ожидает ~ 25 с каждого запроса, при условии, что данные не поступают.

Answer 2

Взгляните на эту страницу . Я экспериментировал с долгим опросом. По сути, он не работает в отличие от обычного XmlHTTP-запроса (XHR, post или get) к серверу. Это сервер, который поддерживает соединение открытым, клиент (браузер) просто ждет ответа. Пока сервер не закрывает соединение (readyState <4), вы можете что-то сделать с ответом. Если соединение закрыто (readyState 4), XHR перезапускается. </p>

В этом месте вы можете найти очень простой и неполный эксперимент ( работает только в Firefox ), где сервер отправляет кортеж RGB через произвольные интервалы в течение некоторого времени. Проблема с непрерывным readyState <4 заключается в считывании последнего отправленного значения, потому что вы не можете сказать, когда закончился последний блок ответа. Ну, это может дать вам представление, как это можно сделать <em>.