1

Я строю систему, в которой у меня есть 2 группы, позволяет называть их пользователями и потребителями. Любой пользователь может отправить сообщение любому потребителю. Как они это делают, это не важно, но происходит то, что сообщение помещается в базу данных на сервере, и всякий раз, когда это происходит, уведомление должно быть отправлено конкретному потребителю (пользователям), представляющему интерес (определяется пользователем).сервер уведомляет конкретный браузер почти сразу

Итак, скажем, у нас есть 100 потребителей, тогда, вероятно, будет 1000 пользователей. ПОТРЕБНОСТИ ПОТРЕБИТЕЛЯ, чтобы получать уведомление почти мгновенно (не более 5 секунд), когда пользователь отправляет ему сообщение. Интерфейс потребителей - это стандартный угловой веб-сайт, и я использую tomcat для его размещения, но это не имеет решающего значения и может быть переключено на узел или, при необходимости, аналогично.

Теперь то, что я пытаюсь выяснить, это лучший способ уведомить потребителя о появлении сообщения. То, что я рассматривал, это websockets, SSE, Long-polling и plain pull-scheme, делающие ajaxrequest каждые 5 секунд. Я думаю, что все варианты выполнимы, но есть некоторые дополнительные проблемы:

- consumers are logged in (ideally in one session) around 18 hours a day. 
- Hardware is limited (Can't afford that much that's why I'm trying to optimize :)) 
- consumers probably only get new message(s) every 10 minutes or so but when they do they NEED to get the message(s) almost instantly (<5 seconds) 

Это представляет проблему безопасности, насколько я вижу (Помнить на той же сессии в браузере 18 часов в день может быть проблематичным Я думаю, что

Что касается аппаратного обеспечения, то я считаю, что отправка запроса ajax на сервер каждые 5 секунд для каждого потребителя быстро (дорого) будет стоить дорого, если у вас есть, скажем, 100 потребителей, как в примере выше.

Я не знаю, как дорого, если бы веб-камеры выполняли это долго, и если это возможно, chea чтобы сделать длинный запрос на опрос до тех пор, пока не появится ответ, а затем выполните новый?

Наконец-то я не совсем понимаю, как работает SSE. Является ли соединение открытым с сервера клиенту (-ам), и если да, то в чем разница между SSE и длительным опросом?

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

Если какой-либо разработка необходима, пожалуйста, просто спросите :)

+0

поэтому, чтобы сварить это в одном заявлении, вы ищете рекомендацию по правильной технологии для немедленного обмена клиентом и клиентом? – Claies

+0

Ну да нет. Мне кажется, что то, что вы кипятите, похоже больше на чат-приложение, тогда как у меня есть еще несколько нюансов. Я предполагаю, что я в основном ищут, может ли один метод или другой способ сохранить мне некоторое использование аппаратного обеспечения, поскольку таких сообщений не будет. – PNS

ответ

1

Для случая, когда задержка должна быть меньше, чем за 5 секунд, а новые сообщения только вероятными каждые 10 минут:

  • WebSockets, SSE и длинные -poll в основном идентичны и имеют нулевую задержку
  • ajax опрос хуже.

Первые три держать специальный сокет открыт, но только накладные расходы на подключение один раз (давно опрос имеет накладные расходы подключения через каждые 10 минут, но это никогда не будет узким местом системы), в то время как Ajax опрос имеет накладные расходы на создание нового соединения каждые N секунд и среднее время задержки на N/2 секунды.

Недостаток веб-узлов, см. И длительный опрос - они открывают розетку. Я не вижу там проблемы с безопасностью, но у вас есть потенциальная проблема с производительностью, так как каждый сокет будет использовать ресурсы на сервере. Но с 100 пользователями, я думаю, что средний экземпляр облачного сервера справится отлично.

Подумайте о SSE как о упрощенных веб-сайтах, предназначенных именно для вашего прецедента, или как стандартная версия длительного опроса, которая также сохраняет повторное соединение при получении данных. Подсказка: SSE - это технология, на которую вы должны пойти, с одной оговоркой. Plug: моя книга, Data Push Apps с поддержкой HTML5 SSE, более подробно отвечает на ваши вопросы ;-)

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

В вашем случае, поскольку вы только ожидаете новых данных каждые 10 минут, вы можете просто пойти на длинный опрос для всех браузеров: разница между этим и SSE - это микро-оптимизация.

В качестве другой рекомендации по этой теме, очень эффективная сеть браузера Илья Григорик очень хороша.

+0

Удивительный ответ! Спасибо, я посмотрю на обе книги. Старый браузер не будет проблемой в моем случае, но приятно с головами. – PNS

1

Посмотрите на Crossbar.io (http://crossbar.io). Это включает в себя публикацию & Подписывать маршрутизацию сообщений (это то, что вам нужно для вашего варианта использования). В браузере есть разъем для AngularJS, и у вас есть большой выбор языков для вашего базового компонента (для обоих см. http://wamp.ws/implementations). Это работает на довольно ограниченных ресурсах - мы справились с томом обмена сообщениями, как вы описываете на малине Pi. Долгосрочные соединения также не являются проблемой, и время до уведомления потребителя определяется главным образом задержка сети (таким образом, менее 5 секунд).

Полное раскрытие информации: Я работаю для Tavendo, которые являются сторонниками вышеупомянутого проекта. Это все с открытым исходным кодом, хотя и подходит для вашего прецедента.

+0

Удивительный! Скажите, посмотрите на него ☺ – PNS

Смежные вопросы