Обмен данными всей системы

Question

Добрый вечер. Я ищу способ обмена данными из моего приложения в масштабе всей системы, чтобы другие приложения могли считывать эти данные и затем делать с ними все, что захотят (например, отформатировать их для отображения, использовать для регистрации и т. Д.). Данные должны обновляться динамически в самом методе.

Сначала на ум пришло WMI, но затем возникла проблема приостановки приложений во время чтения из WMI. Кроме того, я не знаю, как настроить собственное пространство имен или классы, если это даже возможно в Delphi.

Использование файлов - еще одна идея, но это может привести к перегруженности диска, и это действительно ужасный метод для использования в режиме реального времени.

Использование драйвера, вероятно, было бы лучшим вариантом, но это слишком навязчиво для пользователей, на мой взгляд, и я не знаю, с чего начать.

WM_COPYDATA было бы здорово, но я не уверен, достаточно ли это динамично, и будет ли это тяжело использовать ресурсы или нет.

Использование TCP / IP было бы лучшим выбором для сети, но, очевидно, малопригодно при работе в одной системе без сетевых требований.

Как видите, я изо всех сил пытаюсь понять, куда идти с этим. Я не хочу вдаваться в один метод только для того, чтобы понять, что в итоге он не сработает. По сути, что-то вроде службы или фонового процесса, для записи данных, а затем позволяет другим приложениям читать эти данные. Я просто не уверен в методах. Я бы предпочел НЕ требовать повышения / UAC, чтобы сделать это, но если потребуется, я согласен на это.

Я участвую в Delphi 2010 для этого упражнения.

Есть идеи?

Answer 1

Вы хотите создать некую архитектуру клиент-сервер, которая также называется IPC.

Использование WM_COPYDATA - очень хорошая идея. Я обнаружил, что это очень быстро, легко и эффективно на локальной машине. И он может быть передан по системе всем приложениям одновременно (для осторожного использования, если какое-либо приложение не обрабатывает его правильно).

Вы также можете разделить некоторую память, используя файлы с отображенной памятью. Это может быть самый быстрый вариант IPC для огромного количества данных, но синхронизация немного сложна (если вы хотите использовать более одного буфера одновременно).

Именованные каналы являются хорошими кандидатами для местных. Их, как правило, сложно реализовать / настроить по сети из-за проблем безопасности в современных версиях Windows (и они используют TCP / IP для сетевого взаимодействия, поэтому вместо них лучше использовать напрямую TCP / IP).

Мой личный совет заключается в том, что вы должны реализовать обмен данными с абстрактными классами, способными обеспечить несколько реализаций. Вы можете сначала использовать WM_COPYDATA, а затем переключиться на именованные каналы, TCP / IP или HTTP, чтобы распространить свое приложение по сети.

Для нашего открытого клиент-серверного ORM мы реализовали несколько протоколов , включая WM_COPY_DATA, именованный канал, HTTP или прямой внутрипроцессный доступ. Вы можете взглянуть на исходный код, предоставленный для шаблонов реализации. Вот некоторые тесты, чтобы дать вам данные из реальных реализаций:

 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

Как видите, наиболее быстрым является прямой доступ, затем WM_COPY_DATA, затем именованные каналы, затем HTTP (т. Е. TCP / IP). Сообщение содержало около 5 КБ данных JSON, содержащих 113 строк, полученных с сервера, а затем проанализированных на клиенте 100 раз (да, наша структура работает быстро :)). Для огромных блоков данных (например, 4 МБ) WM_COPY_DATA медленнее, чем именованные каналы или HTTP-TCP / IP.

Answer 2

Если вы не против запустить другой процесс, вы можете использовать одну из баз данных NoSQL.

Я почти уверен, что у многих из них не будет драйверов Delphi, но некоторые из них имеютДрайверы REST и, следовательно, могут управляться практически чем угодно.

Answer 3

Где в Windows несколько методов IPC (межпроцессное взаимодействие). Ваш вопрос довольно общий, я могу предложить отображаемые в памяти файлы для хранения ваших общих данных и трансляции сообщений через PostMessage, чтобы сообщить другому приложению об изменении общих данных.

Answer 4

Memcached - это простой способ обмена данными между приложениями.Memcached - это хранилище значений ключей в памяти для небольших фрагментов произвольных данных (строк, объектов).

Клиент Delphi 2010 для Memcached можно найти в коде Google:

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

связанный с этим вопрос:

Существуют ли какие-либо механизмы кэширования для Delphi?

Answer 5

Поиск в Google по «межпроцессному взаимодействию delphi» даст вам множество советов.

Я предлагаю вам взглянуть на http://madshi.net/, особенно MadCodeHook (http://help.madshi.net/madCodeHook.htm)

У меня хороший опыт работы спродукт.