Comunicación entre procesos para Windows en C#(.NET 2.0)
ipc (6)
Nunca antes tuve que hacer IPC en Windows. Actualmente estoy desarrollando un par de programas, una aplicación GUI / CLI estándar y un servicio de Windows. La aplicación tiene que decirle al servicio qué hacer. Entonces, suponiendo que la comunicación es solo local, ¿cuál sería el mejor método de comunicación para estos dos procesos?
Donde mejor se define como más robusto y menos propenso a errores, no es el más eficiente ni el más fácil de codificar.
Los ejemplos de código serán muy bienvenidos, pero no son obligatorios :-)
Tenga en cuenta que estoy preguntando qué usar, un socket TCP estándar, named pipes, u otro medio de comunicación solamente.
¡Gracias!
Dado que está limitado a .Net 2.0 WCF quizás no sea una opción. Podría usar .Net remoto con memoria compartida como el mecanismo de comunicación subyacente entre los dominios de la aplicación en la misma máquina. Con este enfoque, puede colocar fácilmente sus procesos en diferentes máquinas y reemplazar el protocolo de memoria compartida con un protocolo de red.
El método estándar de comunicación con un servicio de Windows es usar códigos de control de servicio. Los servicios de Windows pueden recibir códigos de 0 a 255. 0-127 está reservado para el sistema. 128 a 255 se puede utilizar para comandos personalizados.
Si necesita enviar objetos complejos al servicio use base de datos, xml, archivo, tcp, http, etc. Aparte de eso para enviar comandos de control como volver a cargar la configuración, procesar elementos, etc., se deben usar estos códigos de control.
Hay funcionalidades adicionales disponibles, como consultar el servicio. Consulte la documentación del servicio de Windows y la API.
IPC en .Net se puede lograr usando:
WCF
el uso de conductos con nombre requiere .Net 3.0 y superior.
Ejemplo de código
- La clase WCF NetNamedPipeBinding se puede usar para la comunicación entre procesos en la misma máquina. La documentación de MSDN para esta clase incluye un ejemplo de código que cubre este escenario http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx
Remoting
El marco original de IPC lanzado con .Net 1.0. Creo que la comunicación remota ya no se desarrolla activamente, y se recomienda usar WCF en su lugar
Ejemplo de código
Comunicación entre procesos a través de Remoting : utiliza un canal tcp
Recursos
- GenuineChannels, venda un conjunto de herramientas remoting que incluye un canal de memoria compartido. http://www.genuinechannels.com/Index.aspx
- Ingo Rammer , escribió el libro definitivo de .Net Remoting, Advanced .NET Remoting, Segunda Edición
Win32 RPC usando csharptest-net RpcLibrary
Recientemente me encontré con un proyecto que completó la biblioteca Win32 RPC y creó una biblioteca de clases .net que se puede usar para RPC local y remoto.
Página principal del proyecto : http://csharptest.net/projects/rpclibrary/
Referencias de MSDN:
- Cómo funciona rpc: http://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx
- Funciones de RPC: http://msdn.microsoft.com/en-us/library/aa378623(v=VS.85).aspx
También tiene un cliente rpc de búfers de protocolo de Google que se ejecuta en la parte superior de la biblioteca: https://code.google.com/p/protobuf-csharp-rpc/
WM_COPYDATA
Para completarse, también es posible usar el método WIN32 con el mensaje WM_COPYDATA . Ya utilicé este método en .Net 1.1 para crear una aplicación de instancia única que abre múltiples archivos desde el explorador de Windows.
Recursos
Zócalos
Usando un protocolo personalizado (más difícil)
Me gustaría agregar a esta discusión. Por favor, reprendeme si esto está fuera, pero ¿no podría usarse un semáforo (o múltiples semáforos) para una comunicación rudimentaria?
Solo localmente, hemos tenido éxito usando Named Pipes. Evita la sobrecarga de TCP, y es más o menos (al menos para .NET) tan eficiente como puede obtener a la vez que tiene una API decente para trabajar.
Su mejor opción es usar WCF. Podrá crear un host de servicio en el servicio de Windows y exponer una interfaz bien definida que la aplicación GUI puede consumir. WCF le permitirá comunicarse a través de conductos con nombre si lo desea, o puede elegir cualquier otro protocolo de comunicación como TCP, HTTP, etc. Con WCF obtiene una gran compatibilidad con la herramienta y mucha información disponible.