ServiceStack: выбор серверных событий вместо веб-сокетов

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

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

Мне просто была интересна причина выбора SSE вместо WebSockets.


websocket server-sent-events
person vm0112    schedule 21.08.2014    source источник
comment
Как и в случае с вашим последним вопросом, это не по теме, потому что вы задаете вопросы непосредственно команде ServiceStack относительно их дизайнерского решения использовать SSE через веб-сокеты; о которых только они могут говорить авторитетно. Как уже упоминалось, SO не является альтернативным контактом для прямого доступа к ServiceStack. Хотя Mythz дал хороший ответ (+1), этот вопрос следовало задать непосредственно в ServiceStack по электронной почте или через их сообщество поддержки.   -  person Scott    schedule 21.08.2014
comment
Понятно. В любом случае, спасибо Миф.   -  person vm0112    schedule 22.08.2014

Ответы (1)


arrow_upward
4
arrow_downward

Причины для поддержки событий, отправленных сервером, изложены в демонстрационном проекте Chat:

Отправленные сервером события (SSE) — это элегантный веб-технология для эффективного получения push-уведомлений с любого HTTP-сервера. Его можно рассматривать как сочетание длительного опроса и односторонних веб-сокетов, и он имеет множество преимуществ по сравнению с каждым из них:

  • Простой — события, отправленные сервером, — это всего лишь один долгоживущий HTTP-запрос, который может поддерживать любой HTTP-сервер.
  • Эффективность: каждый клиент использует одно TCP-соединение, и каждое сообщение позволяет избежать накладных расходов на HTTP-соединения и заголовки, которые часто быстрее, чем веб-сокеты.
  • Отказоустойчивость: браузеры автоматически определяют разрыв соединения и автоматически восстанавливают его.
  • Взаимозаменяемость. Поскольку это старый добрый HTTP, его можно анализировать с помощью ваших любимых HTTP-инструментов и даже работать через HTTP-прокси (с отключенной буферизацией и проверенным кодированием).
  • Хорошая поддержка — в качестве веб-стандарта он поддерживается во всех основных браузерах, кроме IE, который можно включить с помощью полифиллов.

то есть это прекрасно простой и элегантный веб-стандарт с лучшей точностью HTTP, чем WebSockets, это идеально подходит для серверных push-коммуникаций, которые работают как в ServiceStack ASP.NET, так и в SelfHosts, не требуя каких-либо дополнительных зависимостей .NET или требуя, чтобы на хосте Windows Server была включена поддержка WebSockets для использования. Поддержка IE может быть включена с помощью полифиллов.

Веб-сокеты могут поддерживаться позже, но для этого, вероятно, потребуются дополнительные внешние зависимости и требования для Windows Server, поддерживающего веб-сокеты.

person mythz    schedule 21.08.2014