2012-02-23 61 views
12

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.Transferir datos grandes entre aplicaciones .net en la misma computadora

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?

+0

Ser pedante aquí ... sus propias pruebas unitarias deberían probar si es correcto y confiable. –

+0

@ AdamHouldsworth No me di cuenta de que el OP dice que incluso están usando pruebas unitarias. Significando que esa declaración también era algo irrelevante. –

+0

@ Mr. Disppointment Realmente no. Las pruebas unitarias se destinarían a demostrar la fiabilidad y el éxito funcional del enfoque: las piedras angulares de la pregunta. También el punto pedante fue que si no estuvieran usando pruebas unitarias para probar esto, deberían hacerlo. –

Respuesta

5

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.

+0

Gracias. Me gusta el enfoque de Message Queue por lo que escribió: "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 receptor no se esté ejecutando). " Gracias. – MTs

+0

Glad podría ayudar. He ampliado mi respuesta con más detalles sobre cómo crear cola en el inicio de la aplicación. –

11

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:

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: enter image description here

0

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).

0

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.

+0

No creo que ZMQ sea una gran opción en este escenario: ZMQ es genial cuando se envían muchos mensajes pequeños, y el orden en que se reciben no tiene que garantizarse (o incluso que lleguen) . Útil para algo así como una cotización bursátil que se actualiza 60 veces por segundo. En este caso, aunque tenemos un mensaje muy grande que se envía cada 10-15 segundos, ZMQ no es ideal para este caso de uso. – MattDavey

+0

Sí, pero está enviando mensajes entre dos componentes en la misma máquina. No experimentará ninguna pérdida de datos asociada con UDP. – zmbq

Cuestiones relacionadas