Node.Js + Socket.IO против SignalR против C # WebSocket Server - PullRequest
Новая
       27

Node.Js + Socket.IO против SignalR против C # WebSocket Server

69 голосов
/ 02 марта 2012

В настоящее время у меня есть приложение-сервер TCP, написанное на .Net, которое принимает и отправляет сообщения клиентам.Я смотрю на создание веб-приложения, поэтому мне нужен коммуникационный уровень.

Я создал приложение Node.JS + Socket.IO, которое подключается к моему TCP-серверу, а затем передает связь с веб-приложением, и все работает нормально..

Я только что прочитал о SignalR как об альтернативе для сохранения его в стеке .Net.

Однако я также обнаружил, что могу написать C # Websocket Server, базовую демонстрацию * 1007.* здесь

Я предполагаю, что этот базовый сервер является тем, чем является SignalR, но, очевидно, с гораздо большей функциональностью в нем?

Что я пытаюсь решить, это просто добавить свойтекущее приложение TCP с сервером Websocket или я иду по отдельному маршруту SignalR или Node.js?Из интереса, как работает приложение SignalR, является ли оно службой Windows, консольным приложением или службой IIS?

Ответы [ 3 ]

72 голосов
/ 06 марта 2012

SignalR похож на Socket.IO в том, что он поддерживает согласование / откат транспорта. Это фреймворк, а не сервер, поэтому вам нужно разместить его на каком-то сервере. У нас есть хосты для ASP.NET, OWIN (например, Kayak) и self-host, поэтому вы можете легко запустить его в своем собственном процессе, например, служба Windows.

SignalR поддерживает клиенты для браузеров (JS), .NET, Windows Phone 7 и Silverlight. Также есть клиенты для iOS, Mono Touch и т. Д.

SignalR предоставит вам гораздо более высокий уровень API, чем необработанные сокеты, что является его большим преимуществом, позволяя вам выполнять такие вещи, как "RPC" от сервера к клиентам в широковещательном (или целевом) виде.

19 голосов
/ 15 марта 2015

Другие последствия

Я использовал обе технологии и работаю по обе стороны стека .NET / узлов.

  1. Хотя я предпочитаю сторону узлов в наши дни, если выработать только в .NET, SignalR является очевидным выбором.И наоборот, если вы строите все свои проекты в узле, я бы использовал socket.io или sockjs .Если ваша сфера действия достаточно узка, и вам не нужно беспокоиться об отказах и подобных вещах, я бы порекомендовал проверить модуль ws , поскольку он проще и легче для ваших зависимостей.В прошлом socket.io был проблемой для Windows из-за проблем с установкой node-gyp, не позволяющих установить собственные зависимости ( node-gyp требует много шагов настройки, которые сильно различаются в зависимости от того, какую версию Windows вы используетеесть, но требуется для встроенных модулей C ++). ОБНОВЛЕНИЕ Этот бит Windows больше не так важен благодаря windows-build-tools .
  2. Если у вас есть балансировщик нагрузки и вы планируете запустить SignalR, вынам нужно будет настроить SQL или Redis в качестве объединительной платы, чтобы обойти балансировщик нагрузки.У вас будут похожие проблемы на стороне socket.io, и есть [несколько поддерживаемых методов] [1] (1 из которых также redis).

Обновление - удален jqueryинформация, поскольку она больше не применима

15 голосов
/ 05 марта 2012

Разработка масштабируемого / поточно-ориентированного TCP-сервера может быть непростой задачей. С другой стороны, в Интернете есть очень хорошие ресурсы для того, чтобы начать свой собственный. Например, если вы просто ищете интересные проекты с открытым исходным кодом WebSocket, мой совет:

Проект Alchemy : библиотека C # WebSocket с открытым исходным кодом

Проект Fleck : библиотека C # WebSocket с открытым исходным кодом

SignalR может быть неплохим, но ему требуется Windows Server 8 / IIS 8, чтобы обеспечить функцию WebSocket.

Что касается коммерческого продукта, особенно учитывая, что функция websocket доступна не во всех браузерах, я рекомендую PokeIn WebSocket и обратную библиотеку Ajax. Начиная с версии 2.0 он имеет встроенный сервер WebSocket. Подробности доступны с здесь

...