Как Gmail делает комету в Opera?

Я хотел бы знать, как Gmail (или кто-то еще) комет в Opera.

Вот что я знаю до сих пор из моих экспериментов.

  • Он не использует тег event-source, который нарушен в Opera 10.51.
  • Он не использует iframe, который отображает вращающийся пульсатор и активный курсор мыши.
  • Он не использует responseText в xmlhttprequest, когда readyState = 3, который, как известно, сломан на Opera.

Я попробовал посмотреть, как это было сделано на mibbit и etherpad, и я обнаружил, что они оба используют длительный опрос.

Bounty

Щедрость идет к тому, кто может сказать мне метод лучше, чем "источник событий" для потоковой передачи кометы Opera, или как gmail выполняет потоковое вещание (или длинный опрос, если он это делает).

ОТВЕТЫ

Ответ 1

GMail использует BrowserChannel (Docs | Source), который включен в Google Closure Library.

  • @fileoverview Определение класса BrowserChannel. Браузер BrowserChannel
  • имитирует двунаправленный сокет через HTTP. Это основа
  • Gmail Чат IM-соединения с сервером.

Ответ 2

Я действительно не знаю, что такое ответ. Но я знаю, что Opera поддерживает сервер-события: http://my.opera.com/WebApplications/blog/show.dml/438711. Может быть, это шаг в сторону андерсера? Я тоже не уверен, но я думаю, что они используют его в Opera Unite.

Ответ 3

Я думаю, что скорее кросс-браузерный (в том числе Opera) подход может состоять в потоковой передаче данных через приложение Adobe Flash. Хотя это и введет зависимость от плагина Flash и не очень популярно из-за этого.

Ответ 4

Я являюсь автором HTTP-сервера Progess С++, совместимого с goog.netBrowserChannel. Вы можете найти документы, которые я написал при изучении протокола здесь:

http://code.google.com/p/libevent-browserchannel-server/wiki/BrowserChannelProtocol

Короче говоря, BrowserChannel использует вечные фреймы для потоковой передачи IE и XHR во всех других браузерах. Протокол разделен на несколько этапов, первый из которых - тестирование сети:

1) проверьте сеть, чтобы обеспечить поддержку "потоковой передачи" (другими словами, нет прокси-сервера буферизации)
2) проверить доступ к множеству сетевых префиксов (чтобы сетевой администратор не заблокировал доступ к чату)

Тогда возможна фактическая передача данных. Данные делятся на два канала (вперед и назад). Обратный канал представляет собой серию долгоживущих (около 4 минут каждый) запросов, используемых сервером для "потока" контента для клиента. Для этого используется кодировка HTTP chunked. Клиент делает все возможное, чтобы убедиться, что один обратный канал всегда открыт. Сервер закроет его каждые 4 минуты, после чего клиент откроет новый задний канал. Прямой канал используется для отправки данных от клиента на сервер. Это нажатие данных производится по мере необходимости.