net - Node.Js+Socket.IO vs SignalR contra C#WebSocket Server

websocket asp.net mvc 5

Question

Actualmente tengo una aplicación de servidor TCP escrita en .Net que recibe y envía mensajes a los clientes. Estoy buscando construir una aplicación web, así que necesito la capa de comunicación.

He creado una aplicación Node.JS + Socket.IO que se conecta a mi servidor TCP y luego envía la comunicación a la aplicación web y todo funciona bien.

Acabo de leer sobre SignalR como alternativa para mantenerlo en la pila de .Net.

Sin embargo, también he descubierto que podría escribir un C # Websocket Server, una demostración básica aquí

Supongo que este servidor básico es lo que SignalR es, pero obviamente con mucha más funcionalidad en él.

Lo que estoy tratando de decidir es: ¿acabo de anexar mi aplicación TCP actual con un servidor Websocket o voy por una ruta separada de SignalR o Node.js? Por interés, ¿cómo se ejecuta una aplicación SignalR, ya sea como un servicio de Windows, una aplicación de consola o un servicio IIS?

Answer 1

Algunas implicaciones que han sido pasadas por alto

He usado ambas tecnologías y trabajo en ambos lados de las pilas de .NET / nodos.

1. Aunque prefiero el nodo en estos días, si solo trabajas en .NET, SignalR es la opción obvia. Por el contrario, si construye todos sus proyectos en el nodo I iría con socket.io o sockjs . Si su alcance es lo suficientemente reducido como para que no tenga que preocuparse por los retrocesos y ese tipo de cosas, le recomiendo que revise el módulo ws ya que es más simple y más ligero en sus dependencias. En el pasado, socket.io ha sido un problema en Windows debido a problemas de instalación con node-gyp que no puede instalar dependencias nativas ( node-gyp requiere muchos pasos de configuración que varían enormemente según la versión de Windows que tenga pero que se requiere para C ++ módulos nativos construidos). ACTUALIZACIÓN Este bit de Windows ya no es tan relevante gracias a windows-build-tools .
2. Si tiene un equilibrador de carga y está planeando ejecutar SignalR, necesitará configurar SQL o Redis como un plano posterior para eludir el equilibrador de carga. Tendrá problemas similares para tratar en el lado de socket.io y hay [múltiples métodos admitidos] [1] (1 de los cuales también es redis).

Actualización: se eliminó la información de jquery porque ya no es aplicable

Answer 2

Desarrollar un servidor TCP escalable / seguro para subprocesos puede no ser una tarea fácil. Por otro lado, hay recursos muy buenos en internet para comenzar el tuyo. Por ejemplo, si solo está buscando algunos buenos proyectos de WebSocket de fuente abierta, mi consejo sería;

Alchemy Project : Open Source C # WebSocket Library

Proyecto Fleck : Open Source C # WebSocket Library

SignalR podría ser bueno, pero necesita Windows Server 8 / IIS 8 para proporcionar la función WebSocket.

En el lado del producto comercial, especialmente teniendo en cuenta que la función de websocket no está disponible en todos los navegadores, recomiendo PokeIn WebSocket y reverse Ajax Library. A partir de la versión 2.0, tiene un servidor WebSocket incorporado. Detalles disponibles desde aquí

Answer 3

SignalR es como Socket.IO porque admite la negociación / repliegue del transporte. Es un marco y no un servidor, por lo que debe alojarlo en un servidor de algún tipo. Tenemos hosts para ASP.NET, OWIN (por ejemplo, Kayak) y autohospedaje, por lo que puede ejecutarlo en su propio proceso fácilmente, por ejemplo, un servicio de Windows.

SignalR ha admitido clientes para navegadores (JS), .NET, Windows Phone 7 y Silverlight. También hay clientes contribuidos para cosas como iOS, Mono Touch, etc.

SignalR le dará un API de nivel mucho más alto que los sockets sin formato, lo cual es su gran ventaja, ya que le permite hacer cosas como "RPC" desde el servidor a los clientes de forma difusa (o dirigida).