longpoll XHR vs iframe [закрыто]

Я реализую типичное серверное push-приложение (comet). Я выбираю между двумя вариантами: longpoll XHR и iFrames. Каковы их плюсы и минусы? Я знаю о кросс-сайтовых ограничениях и о том, что iFrame-довольно тяжелый компонент... есть ли еще какие-то отличия? Например, "надежность" транспортировки или уровень контроля над компонентом? Как вы думаете, есть ли один правильный ответ, какой подход лучше, или есть варианты использования для них обоих?

Заранее благодарю.

P.S. Я получил довольно хорошую рабочую реализацию XHR, но я хочу рассмотреть альтернативы.

6 12
javascript iframe comet xmlhttprequest

6 ответов:

Вы должны использовать socket.io или эквивалентная библиотека. Он поддерживает оба способа, которые вы упоминаете, и многое другое:

Http://socket.io/#transports

Однако давайте предположим, что вы используете соответствующий уровень абстракции, и теперь хотите решить, какой транспорт использовать. :)

IMO, deal-breaker для iframes-это обработка ошибок. Постоянно нагружать технику для iframe делает его Много труднее сделать обработку ошибок. Вы не информированы через удобное событие 404s или таймауты, поэтому вы должны установить интервал в JavaScript, чтобы следить за ошибками.

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

Еще один интересный факт заключается в том, что браузеры ограничены двумя параллельными запросами к серверу по стандарту, но Mozilla сделала исключение только для XHR:

Https://developer.mozilla.org/en/XMLHttpRequest

Когда вы делаете длинные запросы, ограничение на соединение 2 действительно важно: если вы свяжете обе трубы, ничто другое не сможет пройти! Вы должны быть внимательны, чтобы настроить один канал, который разделяет весь код на странице. Но в Firefox, теперь вы получите некоторое пространство для маневра, если и только если вы используете XHR.

Iframes имеют то преимущество, что они могут создавать кросс-домен запросы.

2

Я бы предложил третий вариант: websockets. WebSockets api-это эволюция от длительного опроса и разработан для связи клиент-сервер в режиме реального времени.

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

Есть библиотеки, которые хорошо деградируют (если websockets доступны, они используют их, иначе они возвращаются к длинному опросу). У вас есть socket.io (поддержка все обозреватели). Альтернативой jQuery является jquery-graceful-websocket. Обе библиотеки предоставляют api websocket, но при необходимости возвращаются к альтернативам для обмена данными.

2

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

Поскольку метод iframe передает веб-страницу с некоторым JS в ней, он выглядит более похожим на веб-страницу для носителя и с большей вероятностью будет испорчен носителем. В данном случае, они прячут его так, чтобы он не мог просочиться, было бы моей главной заботой - они вряд ли это сделают. измените значение вашего фактического JS.

XHR (особенно если вы действительно возвращаете XML) с меньшей вероятностью будет испорчен носителем.

Конечно, хороший перевозчик поймет, что происходит, и позволит работать обоим методам. Однако не все носители хороши.

Трудно судить и планировать, но стоит подумать.

1

Я не знаю, что вы имеете в виду, сравнивая iframe с longpull, но, на мой взгляд, iframes очень рискованны и усложняют разработку во много раз из-за упомянутых вами ограничений браузера. И с другой стороны longpull XHR должно быть проще реализовать с вашей текущей реализацией XHR. Это также дает синхронизацию по сравнению с асинхронным XHR.

0

Безусловно, XHR является более чистым решением и имеет все ранее упомянутые преимущества.

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

Тогда докладывай!

0

Я думаю, что longpoll XHR-лучший маршрут, чтобы пойти по нескольким причинам:

  1. Это будущее. iframe-это потерять землю быстро.

  2. Я думаю, что это лучшее разделение данных и отображения. Вы можете получить данные, а затем обработать отображение в клиенте. Это также позволит вам иметь один и тот же источник данных и отображать его по-разному для разных платформ. Дисплей в веб-браузере ПК будет отличаться от дисплея на iPhone.

-1