Варианты веб-уведомлений и обновлений в режиме реального времени с использованием технологий Comet / XMPP и WebSocket в стеке Microsoft? - PullRequest
10 голосов
/ 15 февраля 2012

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

Претенденты на это - технологии на основе Jabber / Comet / XMPP и WebSocket.

Лагерь кометы:

Лагерь WebSockets:

Поскольку существующая инфраструктура представляет собой стек Microsoft, я бы не стал вводить серверы на основе Java в набор. Сказав это, он оставляет (очень привлекательный) WebSync (Comet) и SuperWebSocket (WebSockets). Однако интеграция Pokein с DLL довольно прозрачна и для проекта .Net.

Существуют ли еще реальные инициативы WebSocket для .Net? Не слишком ли рано внедрять WebSockets в стек Microsoft и стоит ли мне переходить на что-то вроде Kazing?

Я все еще жду отчета о типах и версиях браузеров нашей текущей пользовательской базы (проверка совместимости с HTML5). Я подозреваю, что это число будет низким (старшая база пользователей). Если это так, опция Comet будет победителем.

Что еще нужно учесть?

Глядя на некоторые из инициатив .Net, таких как Sockets.IO и другие, я думаю, что это может быть слишком много в зачаточном состоянии, чтобы применить к крупномасштабной производственной системе.

Могу ли я получить комментарии от любого, кто использовал какие-либо технологии и продукты, перечисленные выше?

Спасибо.

UPDATE

Я все еще ищу некоторые хорошие серверы WebSocket, которые надежны на производственном уровне. Я недавно добавил XSockets и SignalR в лагерь Websockets. Однако на данный момент есть еще два основных претендента. Это может быть только из-за того, что у них есть удивительно хорошие маркетинговые команды, хороший материал, доступный для разработчиков - API и видео. Многие другие реализации, похоже, все еще находятся в фазе новорожденного, где приводятся примеры подключения только с несколькими клиентами. Хотя это демонстрирует технологию, эти демонстрации не подкреплены значительными данными полезной нагрузки / грузоподъемности. Kaazing и LightStreamer соответствуют следующим требованиям.

В XSockets есть несколько хороших примеров, но опять же отсутствуют некоторые реальные показатели производства.

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

Основные требования:

  1. Возможность реализации резервной технологии (если HTML5 / WebSockets нет в наличии)
  2. Большое количество одновременных подключений и количество сообщений в второй
  3. Масштабируемость - возможность добавления дополнительных серверов / узлов для больших требования к трафику

Ответы [ 5 ]

2 голосов
/ 29 ноября 2012

WebSync v4 использует WebSockets в дополнение к необходимости возврата к длинному опросу / обратному вызову. WebSockets в WebSync также используются по всем стандартным портам HTTP, поэтому проблем с маршрутизаторами / filrewalls / и т. Д. Не возникнет.

В "нормальной" системе вы должны видеть ~ 20k одновременных (на узел) и ~ 100k сообщений / сек. Это очень грубые числа, хотя, поскольку это кардинально зависит от вашей системы и типов сообщений, которые вы отправляете, и т. Д. Мы видели до 50 000 пользователей (на узел) и (в другом тест) 300 тыс. сообщений в секунду.

(Отказ от ответственности: я работаю на Frozen Mountain)

1 голос
/ 16 февраля 2012

По причинам вкл. те, что уже указаны выше, я бы пошел с WebSockets.

Если вы используете WebSockets, вы также можете рассмотреть возможность использования Autobahn WebSockets, высокопроизводительного сервера WS, который поддерживает Windows, где он работает поверх IOCP (порты завершения ввода / вывода).

Последнее важно, если вы хотите масштабировать до больших номеров соединений (сотни тысяч).

Отказ от ответственности: я являюсь автором Autobahn WebSockets. Базовая технология - OSS. В настоящее время мы готовим коммерческое предложение, концентратор обмена сообщениями в режиме реального времени, предоставляемый в качестве виртуального устройства (работает на VMware /phere). Полностью интегрированное защищенное устройство. Последний также позволяет отправлять уведомления через концентратор с использованием простого старого HTTP / POST. У него есть REST API, который позволяет отправлять сообщения клиентам, подключенным через WS. Если вы заинтересованы в приватном бета-тестировании, свяжитесь со мной ..

1 голос
/ 16 февраля 2012

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

Итак, что может быть дальше? Например, PokeIn собирается разместить все аспекты веб-приложения поверх VisualJS.NET ; Видео-1 , Видео-2

Здесь также показаны встроенные возможности этой библиотеки и варианты, которые вы можете сделать.

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

ОБНОВЛЕНИЕ: PokeIn 2.0 имеет встроенную поддержку WebSockets.

0 голосов
/ 03 октября 2013

СигналR побед.

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

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

0 голосов
/ 15 февраля 2012

Прирост производительности, который вы получаете с WebSockets по сравнению с традиционными кометными решениями, находится в диапазоне нескольких порядков; Я определенно пошел бы с лагерем WebSockets. Здесь - это сравнение двух технологий традиционным вендорным вендором, измеряющее более чем 150-кратный коэффициент в пользу WebSockets (700 мс против 3 мс при 50 000 пользователей).

Несколько замечаний от имени Каазинга:

Kaazing полностью поддерживается в Microsoft как серверная платформа. Также, как вы заметили, Kaazing поддерживает множество клиентских библиотек и технологий, включая стек Microsoft: .NET и Silverlight, которые с удовольствием используют многие наши клиенты.

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

О поддержке браузера: Kaazing обеспечивает исключительно хорошую эмуляцию WebSocket, поддерживая все существующие браузеры, включая старые, вплоть до IE6. Вы можете прочитать больше об этом в этом блоге .

Относительно зрелости: Kaazing WebSocket Gateway поставляется с 2009 года и имеет большое количество крупных клиентов во многих отраслях, включая финансовые, логистические, игровые и розничные; очень зрелая платформа с поддержкой на высшем уровне.

...