C# Sockets vs Pipes

Question

Actualmente estoy trabajando en una aplicación de escritorio multiproceso en Windows. Esta aplicación será una aplicación retráctil que se implementará en máquinas cliente de todo el mundo. Si bien podemos tener amplias especificaciones para las máquinas, p. Windows XP SP3 con .Net 4.0 CF, no tenemos control sobre ellos y no podemos ser demasiado específicos en cuanto a su configuración, por ej. no podemos especificar que la máquina debe tener un procesador gráfico compatible con cuda 1.4, etc.

Algunos de estos procesos se administran (.Net 4.0) y otros no están administrados (C++ Win32). Los procesos necesitan compartir datos. Las opciones que he evaluados hasta la fecha son

• sockets TCP
• canalizaciones con nombre

Tubos parecen funcionar un poco mejor, pero para nuestras necesidades - el rendimiento de ambos son aceptables. Y las tomas nos dan la flexibilidad de cruzar la máquina (y los sistemas operativos - nos gustaría admitir eventualmente los sistemas operativos que no sean de Microsoft) en el futuro, de ahí nuestra preferencia por ir con enchufes.

Sin embargo, mi mayor preocupación es la siguiente: si usamos conectores Tcp, ¿es probable que tengamos problemas con los firewalls? ¿Alguien más ha implementado aplicaciones/programas de escritorio que usan TCP para IPC y problemas experimentados? Si es así, ¿qué tipo?

Sé que esta es una pregunta bastante abierta y me alegraré de reformularla. Pero realmente me gustaría saber qué tipo de problemas potenciales podemos enfrentar.

edición: Para arrojar un poco más de luz, solo estamos transportando algunos POD, ints, flotadores y cuerdas. Hemos construido una capa de abstracción que ofrece 2 paradigmas: una solicitud/respuesta y suscripción. La capa de transporte se ha abstraído y actualmente tenemos dos implementaciones, basadas en tuberías y basadas en TCP.

Answer 1

El rendimiento de las tuberías suele ser mejor en una LAN rápida, pero TCP suele ser mejor en redes más lentas o WAN. Vea los puntos msdn a continuación.

TPC es más también más configurable. Con respecto a los firewalls, le permiten abrir/cerrar puertos de comunicación. Si eso no es una opción o una preocupación, otra opción sería http (REST/json, servicio web, xml rpc, etc.) pero no estoy seguro de si la sobrecarga http es aceptable. Asegúrese de probarlo con conjuntos de datos del mundo real (pasar datos triviales en una prueba hace que los gastos generales parezcan irrazonables; a menudo, es menor comparado con un conjunto de datos del mundo real).

Algunos otra información de msdn:

En una red de área local rápida (LAN), Control de Transmisión Protocolo/Protocolo de Internet (TCP/IP) Desmontes y canalizaciones con nombre clientes son comparables en términos de actuación. Sin embargo, la diferencia de rendimiento entre los sockets TCP/IP y los clientes de Canalizaciones con nombre se convierte en aparente con redes más lentas, como en redes de área amplia (WAN) o redes de acceso telefónico. Esto se debe a las diferentes formas en que los mecanismos de comunicación entre procesos (IPC) se comunican entre pares.

Para canalizaciones con nombre, las comunicaciones de red suelen ser más interactivas . Un par no envía datos hasta que otro par lo solicita usando un comando de lectura.Una lectura de red generalmente implica una serie de peek named pipes messages antes de que comience a leer los datos. Estos pueden ser ser muy costosos en una red lenta y causar un tráfico de red excesivo, que a su vez afecta a otros clientes de la red.

También es importante aclarar si está hablando de tuberías locales o tuberías de red. Si la aplicación de servidor se ejecuta localmente en el equipo que ejecuta una instancia de Microsoft® SQL Server ™ 2000, el protocolo local Canalizaciones con nombre es una opción. Los conductos con nombre locales se ejecutan en el modo kernel y es extremadamente rápido.

Para tomas TCP/IP, las transmisiones de datos son más sencillas y tienen menos sobrecarga. Las transmisiones de datos también pueden aprovechar TCP/IP Mecanismos de mejora del rendimiento de los sockets, como ventanas, retrasos en los reconocimientos , etc., que pueden ser muy beneficiosos en una red lenta . Dependiendo del tipo de aplicaciones, dichas diferencias de rendimiento pueden ser significativas.

sockets TCP/IP también admite una cola de registro, que puede proporcionar un efecto de suavizado limitada comparación con canalizaciones con nombre que pueden conducir a errores de tubería ocupado cuando intenta conectarse a SQL Server.

> En general, los zócalos se prefieren de una forma lenta LAN, WAN o de acceso telefónico a la red, mientras que las canalizaciones con nombre pueden ser una mejor opción cuando la velocidad de la red no es el problema, ya que ofrece una mayor funcionalidad, facilidad de uso, y opciones de configuración.

Para obtener más información acerca de TCP/IP, consulte la documentación de Microsoft Windows NT® .

Answer 2

Si necesita impersonate the named pipe client's security credentials, no hay realmente sólo una opción :) y canalizaciones con nombre también tienen nombres más agradables (aunque los registros SRV de DNS pueden proporcionar los de los puertos TCP también).

De lo contrario, no hay mucha diferencia. Ambos tratan los datos como una secuencia de bytes, dejándote responsable de encontrar los límites del mensaje por ti mismo. Los conductos con nombre tienen una opción adicional de mantener los límites del mensaje para usted, pero tenga cuidado, ambos deben crear el conducto en el modo de mensaje y establecer explícitamente el modo de lectura también.

Answer 3

Si entiendo correctamente sus requisitos, debe comunicar entre procesos que se ejecutan en la misma computadora. Es probable que los procesos se ejecuten en el mismo contexto de seguridad del usuario que inicia sesión interactivamente.

En el caso debo mencionar que hay diferentes aspectos de la solución. Un problema es solo para compartir los datos entre las aplicaciones. Otro problema es el protocolo que define cómo se puede acceder y modificar a los datos comunes y cómo se lleva a cabo la comunicación entre los procesos. Puede tener, por ejemplo, un proceso que proporciona los datos y todos los demás suscriba los datos. Otro caso: puede tener datos comunes que pueden leerse o modificarse en todas las aplicaciones, y solo debe asegurarse de que nadie modifique los datos compartidos al mismo tiempo o que nadie acceda a los datos durante otra modificación. Por lo que podría ser muchos otros escenarios de comunicación diferentes.

Bajo el aspecto que se podría sugerir otras dos opciones, que no incluyó en su pregunta:

• uso de memoria mapeada archivos (ver here y here)
• el uso de la interfaz COM

Ambas maneras se pueden implementar bien tanto en .NET como en C++ no administrado. El uso de archivos mapeados en memoria es la mejor manera desde el punto de vista del rendimiento. Si crea una vista que no estará asociada con algún archivo físico, tendrá solo una memoria común que se puede usar entre procesos. Puede usar adicionalmente un Mutex o Evento para controlar que la memoria no será utilizada al mismo tiempo por múltiples aplicaciones.

En el escenario más simple que usted puede incluso utilizar #pragma data_seg en C++ para colocar algunos datos en la sección llamada de DLL y utilizar /SECTION opción (como /SECTION:.MYSEC,RWS) para que los datos compartidos . Puede usar la DLL en todas sus aplicaciones .NET y en todas las aplicaciones C++ no administradas para acceder a los datos comunes. En el camino, tendrás una forma simple de acceder a los datos comunes.

Si necesita tener un escenario de comunicación más complejo, el enfoque con la interfaz COM en C++/.NET podría ser la mejor opción. En caso de que yo te recomiende the article que describe paso a paso cómo implementar el ensamblado primario de interoperabilidad con la interfaz COM solo en .NET y lo usa tanto en .NET como en C++ COM para la comunicación.