interacción remota vs toma

Question

lo que es el diff, ventajas y desventajas entre la comunicación remota y el zócalo ... cuál es el mejor camino para la funcionalidad de cliente-servidor ....

Answer 1

sockets son corrientes binarias primas entre dos puntos finales. Debería envolver su propia capa RPC (etc.) para procesar los mensajes y manejar gran cantidad de código de infraestructura. Sin embargo, dado que están tan cerca del metal, esto puede ser muy, muy eficiente. No está vinculado a ninguna arquitectura específica, siempre y cuando ambos extremos tengan el mismo formato de mensaje. Las herramientas como protobuf-net pueden ayudarlo a construir mensajes binarios para transmisiones (en lugar de desplegar su propio código de serialización).

Remoting es una herramienta específica de .NET, y es muy frágil de versiones. No recomendaría la comunicación remota para el cliente/servidor: use cosas como WCF.

WCF es una pila de comunicaciones más flexible: mucha potencia y complejidad, pero podría decirse que también un poco de hinchazón (xml, seguridad compleja, etc.). Está basado en un contrato de datos, por lo que aproximadamente abierto (el cliente/servidor puede ser diferente), pero aún un poco enfocado en .NET.

---

edición Para información, protobuf-net proporciona una pila RPC también; por el momento, solo se proporciona una implementación de HTTP, pero en algún momento agregaré TCP/IP en bruto.

Answer 2

En segundo lugar, más que Marc Gravell escribió: específicamente la comunicación remota y la serialización interna son "fáciles" pero son muy fáciles de romper y no se adaptan bien a una red pública (no estoy familiarizado con .net remoto, pero Supongo que necesita un servicio de registro bien conocido que a menudo es problemático al salir del entorno de laboratorio limpio).

Implementar un RPC estándar o incluso rodar por su cuenta es más difícil pero más seguro a largo plazo: no tiene problemas con las revisiones de código (o son más fáciles de controlar), la escala está completamente controlada por su propio código, y es fácil de desarrollar componentes utilizando diversas tecnologías.

Hay muchas muchas herramientas que te ayudan a construir fácilmente mecanismos RPC sobre sockets, pero realmente me gusta usar HTTP antiguo simple: obtener un servidor HTTP incorporado dentro del proceso del servidor y tu cliente solo necesita tener un HTTP cliente para enviar mensajes. Si desarrolla su propia semántica de llamadas RESTful (en lugar de utilizar un formato de mensaje inflado como SOAP o XML-RPC), entonces realmente no hay casi nada que hacer :-)

Answer 3

Yo diría que elegir entre tomas y remoting considere mejor qué tipo de aplicación está desarrollando. Los zócalos son definitivamente para sus propias implementaciones de protocolo, programación de bajo nivel y el único camino a seguir si tiene que comunicarse con las otras aplicaciones tcp/ip. Remoting es una forma preferida de desarrollar nuevas aplicaciones de comunicación .NET, donde no necesita bajar a tcp/ip stack y asegurarse de que su aplicación se comunica con las demás (probablemente aplicaciones heredadas). En caso de que solo pueda utilizar .NET, es mejor elegir .NET 3.5 y WCF framework en lugar de .NET 2.0 remoto, el último es tecnología muerta y no compatible.

Answer 4

La manipulación directa del zócalo puede proporcionarle más potencia, flexibilidad, rendimiento y, por desgracia, complejidad en comparación con Remoting o WCF. Sin embargo, si necesita los beneficios de TCP/IP de bajo nivel, como IO sin bloqueo y protocolos personalizados, herramientas como Ragel y frameworks como Mina pueden aliviar la carga de complejidad. Recomiendo probar primero las API de nivel superior como WCF y solo usar sockets directos si estos no satisfacen sus necesidades.