Transferir datos grandes entre aplicaciones .net en la misma computadora

Question

Tengo dos aplicaciones .net que se ejecutan en la misma máquina. La primera aplicación es el 'Motor'. Construye imágenes: el tamaño de la imagen es de aproximadamente 4 millones. La segunda aplicación es el 'Visor'. Muestra las imágenes que envía el 'Motor'. El motor envía imágenes cada 10-15 segundos.

Mi pregunta es ¿cuál es la forma de bast para pasar las imágenes del motor al espectador. Actualmente, estoy usando FileSystem para esto. El motor escribe la imagen en la carpeta del sistema de archivos y el espectador obtiene este archivo usando FileSystemWatcher.

¿Es ese enfoque correcto? Es eso confiable?

Answer 1

Hay varias buenas opciones:

• Message Queue
• Canalizaciones con nombre (directamente)
• Archivos mapeados de memoria
• WCF on Named Pipes o MSMQ

Cualquiera de estos es más que suficientemente rápido, por lo que sugeriría que sea más fácil de implementar.

Message Queue (MSMQ) en mi opinión es el más simple de usar, le da transferencia de objeto (a diferencia de las secuencias) y le da persistencia de transporte opcional (útil en caso de que el remitente o el receptor no se estén ejecutando). Todo esto es cierto para WCF sobre MSMQ pero WCF significa más sobrecarga, complejidad y configuración involucradas y ningún valor adicional (en este caso).

Enviar esta manera:

MessageQueue queue = new MessageQueue(".\\private$\\ImagesQueue"); 
Message msg = new Message 
{ 
    Formatter = new BinaryMessageFormatter(), 
    Body = myImage, 
    Label = "Image" 
}; 
queue.Send(msg); 

reciben:

MessageQueue queue = new MessageQueue(".\\private$\\ImagesQueue"); 
msg = queue.Receive(TimeSpan.FromMilliseconds(100)); 
if (msg != null) 
{ 
    msg.Formatter = new BinaryMessageFormatter(); 
    myImage = (MyImage)msg.Body; 
} 

Queue tiene que ser creado antes de su uso. Usted puede hacer eso cuando la aplicación se inicia

tienen esta en su clase:

private const string queueName = ".\\private$\\ImagesQueue"; 

y en la solicitud de inicialización/puesta en marcha asegúrese de que tiene la cola:

if (!MessageQueue.Exists(queueName) 
{ 
    MessageQueue myQueue = MessageQueue.Create(queueName); 
} 

Con este mecanismo de cola, El motor no tiene que esperar a que se complete el visor. Esto mejoraría mucho el rendimiento percibido porque puede generar la siguiente imagen (en realidad, el número de ellas), mientras que la anterior aún se está viendo. No es tan fácil de lograr con archivos mapeados en la memoria.

MSMQ es un componente estándar de Windows pero debe habilitarse en las características de Windows.

Answer 2

Desde .NET Framework 4.0 puede utilizar archivos asignados de memoria para esto, creo que sería más rápido que el enfoque basado en el sistema de archivos ya que no necesita costosas operaciones de IO del sistema de archivos.

Un archivo mapeado en memoria contiene el contenido de un archivo en la memoria virtual . Esta asignación entre un archivo y espacio de memoria habilita una aplicación , que incluye procesos múltiples, para modificar el archivo por leyendo y escribiendo directamente en la memoria. Los archivos mapeados en memoria se pueden compartir en varios procesos. Los procesos pueden correlacionarse con el mismo archivo mapeado en memoria> mediante el uso de un nombre común que se asigna por el proceso que creó el archivo

Así que comparten MMF a través de múltiples procesos sólo tiene que compartir un nombre MMF, por lo que puede considerar siguiente enfoque:

• motor crea un archivo MMF y compartir con Visor sólo un nombre (cadena)
• Vista acceso al MMF usando MemoryMappedFile.OpenExisting(sharedName) método (ver MSDN para un ejemplo para acceder misma MMF de diferentes procesos)

Enlaces de interés:

• Memory-Mapped Files
• Working with memory mapped files in .NET 4 - recomiendo leer este artículo que describe por qué MMF realmente "is the most efficient way for multiple processes on a single machine to communicate with each other". Básicamente muestra que todas las demás opciones de IPC están basadas en MMF.

(Desde el mencionado anteriormente artículo) Si comprobamos otros métodos IPC podemos ver la siguiente arquitectura:

Answer 3

Sí, ese es un enfoque válido. Y suponiendo que su código no contiene errores, sí, es confiable.

Pero es lento. Si el rendimiento es una preocupación, es posible que necesite utilizar Sockets (si alguna vez desea dividir el motor y el visor en diferentes máquinas) o conductos con nombre (para las comunicaciones entre procesos en la misma máquina).

Answer 4

Use ZeroMQ. Es muy fácil de usar (más fácil que WCF si solo envía un tipo de mensaje), no tiene demasiados gastos generales y, en general, es una buena solución para muchos problemas de comunicación entre procesos.