Sistema de datos compartidos ancho

Question

Buenas tardes. Estoy buscando un método para compartir datos de mi aplicación en todo el sistema, para que otras aplicaciones puedan leer esos datos y luego hacer lo que quieran con él (por ejemplo, formatearlo para visualizarlo, usarlo para iniciar sesión, etc.). Los datos deben actualizarse dinámicamente en el método en sí.

Primero vino a la mente WMI, pero luego tiene el problema de las aplicaciones deteniéndose mientras lee de WMI. Además, no tengo una idea real de cómo configurar mi propio espacio de nombres o clases si eso es posible en Delphi.

Usar archivos es otra idea, pero podría hacer que el disco sea pesado, y es un método realmente horrible de usar para datos en tiempo real.

Usar un controlador probablemente sea la mejor opción, pero eso es un poco demasiado intrusivo para los usuarios como para mi gusto, y no tengo ni idea de dónde comenzar con él.

WM_COPYDATA sería genial, pero no estoy seguro si eso es lo suficientemente dinámico, y si va a ser pesado en recursos o no.

El uso de TCP/IP sería la mejor opción para la red, pero obviamente es de poca utilidad cuando se ejecuta en un solo sistema sin requisitos de red.

Como puede ver, estoy luchando para descubrir a dónde ir con esto. No quiero entrar en un método solo para descubrir que al final no va a funcionar. Básicamente, algo así como un servicio, o proceso en segundo plano, para registrar datos y luego permitir que otras aplicaciones lean esos datos. Solo estoy seguro de los métodos. Preferiría NO necesitar elevación/UAC para hacer esto, pero si es necesario, me conformaré con eso.

Me estoy ejecutando en Delphi 2010 para este ejercicio.

¿Alguna idea?

Answer 1

¿Quieres crear una arquitectura cliente-servidor, que es también llamado IPC.

Usar WM_COPYDATA es una muy buena idea. Descubrí que es muy rápido, liviano y eficiente en una máquina local.Y puede transmitirse a través del sistema, a todas las aplicaciones a la vez (para ser utilizado con cuidado si alguna aplicación no lo maneja correctamente).

También puede compartir algo de memoria, usando archivos asignados de memoria. Esta puede ser la opción más rápida de IPC para una gran cantidad de datos, pero la sincronización es un poco compleja (si desea compartir más de un búfer a la vez).

Las tuberías con nombre son buenas candidatas locales. Tienden a ser difíciles de implementar/configurar en una red, debido a problemas de seguridad en las versiones modernas de Windows (y están usando TCP/IP para la comunicación de red, por lo que debería usar directamente TCP/IP en su lugar).

Mi consejo personal es que deberá implementar el intercambio de datos con clases abstractas, y podrá proporcionar varias implementaciones. Puede usar WM_COPYDATA primero, luego cambiar a canalizaciones con nombre, TCP/IP o HTTP para distribuir su aplicación a través de una red.

Para nuestro ORM de servidor de código abierto ORM, we implemented several protocols, incluido WM_COPY_DATA, named pipe, HTTP o acceso directo en proceso. Puede echar un vistazo al código fuente proporcionado para los patrones de implementación. Aquí están algunos puntos de referencia, para darle los datos de las implementaciones reales:

Client server access: 
    - Http client keep alive: 3001 assertions passed 
    first in 7.87ms, done in 153.37ms i.e. 6520/s, average 153us 
    - Http client multi connect: 3001 assertions passed 
    first in 151us, done in 305.98ms i.e. 3268/s, average 305us 
    - Named pipe access: 3003 assertions passed 
    first in 78.67ms, done in 187.15ms i.e. 5343/s, average 187us 
    - Local window messages: 3002 assertions passed 
    first in 148us, done in 112.90ms i.e. 8857/s, average 112us 
    - Direct in process access: 3001 assertions passed 
    first in 44us, done in 41.69ms i.e. 23981/s, average 41us 
    Total failed: 0/15014 - Client server access PASSED 

Como se puede ver, más rápido es el acceso directo y, a continuación WM_COPY_DATA, a continuación, tuberías con nombre, a continuación, HTTP (es decir, TCP/IP). El mensaje contenía alrededor de 5 KB de datos JSON que contenían 113 filas, se recuperaron del servidor y luego se analizaron en el cliente 100 veces (sí, nuestro marco es rápido :)). Para grandes bloques de datos (como 4 MB), WM_COPY_DATA es más lento que named pipes o HTTP-TCP/IP.

Answer 2

Donde hay varios métodos IPC (comunicación entre procesos) en Windows. Su pregunta es bastante general, puedo sugerir archivos mapeados en memoria para almacenar sus datos compartidos y transmisión de mensajes a través del PostMessage para informar a otras aplicaciones que los datos compartidos han cambiado.

Answer 3

Si no le importa ejecutar otro proceso, puede usar una de las bases de datos NoSQL.

Estoy bastante seguro de que muchos de ellos no tendrán controladores Delphi, pero algunos de ellos tienen controladores REST y, por lo tanto, se pueden extraer de casi cualquier cosa.

Answer 4

Memcached es una manera fácil de compartir datos entre aplicaciones. Memcached es un almacén de valores-clave en memoria para pequeños fragmentos de datos arbitrarios (cadenas, objetos).

Un Delphi 2010 cliente para Memcached se puede encontrar en Google código:

http://code.google.com/p/delphimemcache/

pregunta relacionada:

Are there any Caching Frameworks for Delphi?

Answer 5

Google para 'delphi interprocess communication' le dará muchos consejos.

le sugiero que eche un vistazo a http://madshi.net/, especialmente MadCodeHook (http://help.madshi.net/madCodeHook.htm)

Tengo buena experiencia con el producto.