«Веб-» push-уведомления для внутреннего приложения

Question

Я уже перебираю решение, но так как я не делал что-то подобное, прежде чем я хотел проверить, что думает SO перед реализацией.

В основном мне нужно изменить существующее веб-приложение, в котором около 20 пользователей, чтобы добавить push-уведомления. Важно, чтобы пользователи получали уведомления одновременно (ПК-А не должен получать предупреждение за 20 секунд до ПК-Б). В настоящее время система обрабатывает запросы AJAX, отправляя серверу каждые 20 секунд и запрашивая обновления, и каждый раз полностью перестраивает таблицу данных (даже если данные не изменились). Это кажется очень неаккуратным, поэтому есть два метода, которые я придумала.

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

2. Продолжайте работу с запросом AJAX, но отвечайте только с интервалами. Второе решение, о котором я подумал, состоит в том, чтобы позволить клиентам отправлять запросы AJAX как обычно (в настоящее время каждые 20 секунд). ) но сервер должен отвечать только с интервалом в 30 секунд (например, 2:00:00 и 2:00:30 независимо от того, сколько запросов AJAX он получает за этот промежуток времени). Это потребует корректировки таймаута для запроса AJAX, чтобы предотвратить тайм-аут запроса, но теоретически это звучит нормально, по крайней мере, для меня.

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

Редактировать

В первую очередь ищет плюсы и минусы каждого подхода. У DashK есть еще один интересный подход, но мне интересно, имеет ли кто-либо опыт работы с любым из этих методов и может ли он подтвердить сильные и слабые стороны каждого подхода или, возможно, другого метода.

Answer 1

Если я хорошо понимаю ваши потребности, думаю, вам стоит взглянуть на Comet

Comet - это модель веб-приложения, в которой длительный HTTP-запрос позволяет вебсервер для отправки данных в браузер, без явного запроса браузера.Комета является общим термином, охватывающим несколько методов для достижения этого взаимодействия.Все эти методы основаны на функциях, включенных по умолчанию в браузерах, таких как JavaScript, а не на плагинах не по умолчанию.

Подход Comet отличается от исходной модели сети, в которой браузер запрашивает полную сетьстраница за раз.

Answer 2

Как насчет использования сервера XMPP для решения проблемы?

Первоначально разработанная для платформы обмена мгновенными сообщениями, XMPP - это протокол обмена сообщениями, который позволяет пользователям системы обмениваться сообщениями. (Это еще не все - но давайте будем простыми.)

Давайте немного упростим сценарий. Представьте себе следующее:

Вы системный администратор. Когда система есть проблема, вы должны позволить всем сотрудники, около 20 из них, знают, что система не работает.

В старые времена каждый сотрудник будет спросить вас: "Система работает?" каждый час или около того, и вы ответите пассивно. Пока это работает, вы перегружен - не исправляя система отключение, но 20 человек просят состояние системы каждый час.

Теперь, AIM изобретен! Так как каждый сотрудник имеет доступ к AIM, вы подумал: «Эй, как насчет того, чтобы каждый один из них присоединяется к системе Статус 'чат, а я просто вышлю сообщение в комнату, когда система вниз (или вернулся)? " сотрудники, которые заинтересованы в зная статус системы просто присоединится комната «Состояние системы», и будет уведомление об обновлении состояния системы.

Возвращаясь к проблеме, которую мы пытаемся решить ...

• Системный администратор = "Система", которая хочет уведомлять пользователей веб-приложения.
• Сотрудники = пользователи веб-приложений, которые хотят получать уведомления.
• Состояние системы чата = Still, состояние системы чата

Когда пользователь веб-приложения входит в ваше веб-приложение, заставляет страницу автоматически регистрировать его на сервере XMPP и присоединяется к чату состояния системы.

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

Используя XMPP, вам не нужно беспокоиться о:

• Настройка «Постоянного соединения». Некоторые серверы XMPP с открытым исходным кодом, eJabberd / OpenFire, имеют встроенную поддержку BOSH, реализацию XMPP модели Comet.
• Как доставлено сообщение

Однако вам потребуется следующее:

• Найдите библиотеку Javascript, которая может помочь вам войти на сервер XMPP. (Только Google. Их много.)
• Найдите библиотеку XMPP для серверного кода. (Библиотека XMPP существует как для Java, так и для C #. Но я не уверен, какую систему вы используете за кулисами.)
• Вручную подготовьте каждого пользователя на сервере XMPP (похоже, у вас есть только 20 человек. Это должно быть легко - однако, если группа становится больше, вы можете захотеть выполнить автоматическую инициализацию - что достижимо с помощью клиентского Javascript Библиотека XMPP.)

Что касается длительных вызовов AJAX, эта реализация ограничена проблемой не более 2-х соединений с одним доменом. Если вы использовали одно соединение для этого вызова XMPP, у вас есть только еще одно соединение для выполнения других вызовов AJAX в веб-приложении. В зависимости от того, насколько сложным является ваше веб-приложение, это может быть или не быть желательным, поскольку, если 2 AJAX-вызова уже были сделаны, любой последующий AJAX-вызов должен будет ожидать освобождения одного из AJAX-конвейеров, что может привести к «замедлению» в работе. ваше приложение.

Это можно исправить, преобразовав все вызовы AJAX в сообщения XMPP, и пригласив на сервер пользователя-бота для прослушивания этих сообщений и ответа на него, скажем, путем отправки обратно фрагментов HTML / объектов JSON с данными , Однако это может быть слишком много для того, чего вы пытаетесь достичь.

Ааа. Надеюсь, это имеет смысл ... или нет. : Р

Answer 3

См. http://ajaxpatterns.org/HTTP_Streaming

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

Answer 4

Если вы можете попросить каждого пользователя использовать определенный браузер (последний Safari или Chrome), вы также можете попробовать WebSockets.

Answer 5

В дополнение к двум другим отличным вариантам, приведенным выше, вы можете посмотреть на Web Workers, если знаете, что у них установлены последние версии Chrome, Safari, FF или Opera для браузера.

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

Рабочие могут получать данные несколько раз и асинхронно. Вы устанавливаете обработчик onmessage так, чтобы он работал каждый раз, когда он что-то получает.