Работа с отсутствующими сообщениями в JavaScript при использовании BOSH - PullRequest
2 голосов
/ 25 апреля 2010

Мы недавно вышли на частную бета-версию нашего флагманского продукта и провели небольшое мероприятие по запуску. К сожалению, у места было ужасное беспроводное соединение, и пакеты отбрасывались влево и вправо и в центре, что приводило к хаосу в нашей системе, в основном это не могло работать вообще! К счастью, мы смогли переключиться на другую сеть и спасти демо. Это выдвинуло на первый план то, что, как я знал, уже было проблемой, но еще не поняло, насколько это может быть проблемой. Наша система в значительной степени опирается на BOSH и имеет довольно большую базу кода JavaScript, которая теперь довольно хорошо работает в хороших сетевых условиях. Однако нам нужно, чтобы он работал хорошо и в плохих сетевых условиях.

Из-за того, что XMPP работает, система запуска и забывания не так легко определить, было ли отправленное или полученное сообщение отправлено или предполагалось получить. Например, у нас есть система предложений, один пользователь отправит предложение другому через BOSH. Когда это сообщение принимается сервером, сообщение публикуется на PEP-узле предложения users_sent и аналогичное сообщение на PEP-узле offer_received принимающих пользователей. В то время как отправляющий пользователь может определить, было ли его предложение отправлено (относительно) легко, если уведомление получающему пользователю никогда не будет получено, этот пользователь никогда не узнает, что пропустил сообщение.

Немного о настройке JavaScript, она имеет 4 основных слоя:

  1. StropheJS
  2. Среда MVC для работы с низкоуровневыми задачами и построения на основе
  3. Прикладной уровень, который содержит логические маршруты приложения, модели контроллеров и т. Д., А также кеш браузера данных модели
  4. Уровень пользовательского интерфейса, который получает события и публикует события на уровне приложения и из него

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

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

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

Я подозреваю, что самым трудным вопросом для решения будет номер 2. Любые мысли по этому вопросу будут высоко оценены.

Ответы [ 2 ]

1 голос
/ 01 мая 2011

Вы должны использовать подтверждения запросов и ответов для решения этой проблемы: http://xmpp.org/extensions/xep-0124.html#acks Автор strophe.js упомянул, что он добавит поддержку этого в будущем.

1 голос
/ 05 мая 2010

Хорошего решения для этого нет, однако есть работоспособное решение.

Сеансы BOSH остаются действительными только в течение определенного времени (60 секунд по умолчанию в большинстве реализаций). Как только сессия истекает, фальшивое соединение c2s закрывается, и пользователь должен снова войти в систему.

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

Я хотел бы предложить, поскольку вы используете PEP в качестве хранилища, чтобы у вас была ловушка в клиенте при каждом создании сеанса, вы выбираете элементы из ваших узлов PEP для инициализации кэша на стороне клиента (см. раздел 6.5. XEP-0060 ).

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

...