2010-08-12 13 views
8

Tengo una aplicación (A) que necesita iniciar otra aplicación (B). Necesito pasar datos entre las aplicaciones. Puedo pensar en dos enfoques. El primero es abrir un socket. El segundo es compartir datos a través de un dll.¿Cuál es la forma preferida de pasar datos entre dos aplicaciones en el mismo sistema?

El enfoque de la toma de apertura es sencillo.

El enfoque dll Tengo algunas preguntas? Puedo cargar dlls de plugin en B. Quiero crear un dll que A pueda usar para pasar datos a B. Cuando cargue dlls, ¿solo se carga una instancia del dll? Si es así, ¿significa esto que los datos se pueden compartir entre las aplicaciones que cargan el dll?

¿Cuál es la mejor opción?

¿Hay otras formas de hacerlo?

Respuesta

13

No puede compartir datos de manera efectiva a través de una DLL. Otras formas:

  • archivos de disco
  • tuberías
  • memoria compartida
  • mensajes
  • RPC
  • CORBA
  • COM
  • etc.
+0

¿Cuál es el problema de compartir datos a través de un dll? – zooropa

+2

@zoo Es muy difícil de controlar, no funciona si la DLL se descarga, y requiere una compilación especial de la DLL: los datos en las DLL no se comparten de forma predeterminada. –

+1

mira en #pragma data_seg para obtener más información sobre cómo compartir datos entre dlls –

0

Puede tener un caché compartido (por ejemplo, un servicio de Windows o un proceso oculto) que puede estar escuchando, devolviendo datos a todos los suscriptores. Esto usando un enfoque de patrón Observador.

5

El método más simple (suponiendo de Windows ya que lo mencionas un archivo DLL) es probablemente usar CreateProcess y abrir una tubería para el proceso hijo, tal como se describe en forma simplificada aquí: http://msdn.microsoft.com/en-us/library/ms682499.aspx

canalizaciones con nombre puede ser una alternativa, especialmente si no tienes el control de la duración de todos los procesos. http://msdn.microsoft.com/en-us/library/aa365590.aspx

Para casos simples, los mailslots pueden ser una alternativa suficiente.

http://msdn.microsoft.com/en-us/library/aa365574.aspx#base.using_a_mailslot_for_ipc

He aquí una lista más larga de diversas técnicas de comunicación entre procesos para Windows. http://msdn.microsoft.com/en-us/library/aa365574.aspx

Para algo que ocurre localmente, usar sockets parece una especie de exceso. Además, debe implementar su propio mecanismo de seguridad para evitar ataques de falsificación, en lugar de depender del mecanismo de seguridad integrado de la mayoría de los otros métodos de IPC.

+0

¿Sabías que has publicado enlaces antiguos? –

+0

No, todos vinieron de nuevas consultas de Google cuando publiqué ... ah, veo que la versión de VS está especificada en ellos. Sin embargo, no creo que el contenido haya cambiado. – JasonTrue

1

Siempre es bueno explorar soluciones posibles alternativas, pero personalmente creo que el uso de sockets como una capa de transporte de datos entre aplicaciones no solo es a prueba de futuro, sino también escalable. El uso de sockets eliminará la necesidad de que escriba grandes cantidades de código específico del sistema operativo, lo que podría impedirle transferir su aplicación en el futuro a sistemas operativos que no sean de Windows.

Sugeriría enchufes.

+1

Sin embargo, requerirá que escriba cantidades copiosas de código neutral del sistema operativo y luego lo mantenga. –

+0

Sí. Punto a favor :) – carribus

0

Estoy de acuerdo con Juan Zamora M, excepto que el servicio que proporciona los datos debe tener una API que se puede solicitar cuando no se necesita presionar cuando se cambia a través de oyentes.

Cuestiones relacionadas