Межпроцессного взаимодействия

Ответ 1

Вы можете сделать это проще, поскольку вы просто пытаетесь выяснить, работает ли одно приложение с другого. Пока они работают на одной машине одним и тем же пользователем, вы можете просто использовать X FindWindow(), чтобы увидеть, что Y в настоящее время работает. Просто убедитесь, что вы даете Y значащее имя (в примере ниже, это TXMLFormatterForm):

var
  XMLWindow: HWnd;
begin
  XMLWindow := FindWindow('TXMLFormatterForm', nil);
  if XMLWindow > 0 then
    // Y is running
end;

Вы также можете использовать заголовок окна Y (заголовок), если вы уверены, что он отличается:

XMLWindow := FindWindow(nil, 'Workshop Alex XML Formatter');

Ответ 2

Взгляните на мой IPC по адресу:

http://www.cromis.net/blog/downloads/cromis-ipc/

Он быстрый, бесплатный и имеет заданный тайм-аут, поэтому вы можете установить его в очень маленькую сумму (например, 50 мс). Поскольку это очень быстро (типичный запрос цикла сообщения → процесс → ответ занимает менее 1 мс, около 0,1 мс), вы можете иметь очень малые таймауты. В него встроен клиентский сервер, поэтому многие клиенты не проблема. Он работает с потоком с пулом задач, поэтому он не затормозит вашу программу и имеет очень гибкие пакеты данных, чтобы облегчить запись/чтение данных.

Как уже говорилось, вы даже можете проверить с помощью других средств, если отладчик работает.

• Проверить процесс
• Проверить основное окно процесса
• Использовать Mutex
• ...

Ответ 3

Вы могли бы написать X свой вывод в файл с отображением памяти - Y может извлекать данные, если он запущен. Таким образом, X не волнует, вверх или нет Y.

X может написать какую-то информацию управления в известном месте (например, хранить смещения последних 1000 письменных XML файлов, начиная со смещения 0 в сопоставленном файле) и использовать остальную часть файла в качестве циклического буфера для исходных данных.

Если вам нужно, чтобы Y был определяющим фактором для действий в X, Y создайте сопоставленный файл, а затем используйте его присутствие/отсутствие в качестве проверки на производство данных на стороне X "канала". Ниже приведен пример кода для создателя и второго пользователя здесь.

Ответ 4

Именованные каналы бывают быстрыми, потому что они основаны на файлах с отображением памяти для их реализации. Что может быть медленным, это таймаут в случае сбоя сервера...

Если вам нужен быстрый ответ на том же компьютере, почему бы вам не использовать старые добрые сообщения GDI?

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

Хитрость заключается в обработке сообщений WM_COPYDATA. См. Например, наш класс TSQLRestClientURIMessage и методы ExportServerMessage/AnswerToMessage TSQLRestServer, реализованные в http://synopse.info/fossil/finfo?name=SQLite3/SQLite3Commons.pas

На практике я узнал, что сообщения GDI намного быстрее, чем именованные каналы для небольшого объема данных (до 64 КБ или таких сообщений).

У вас есть альтернативы в Поиск альтернативы сообщениям Windows, используемым в межпроцессной коммуникации

Ответ 5

Вот некоторые реальные данные о скорости, согласно различным исследованиям клиент/сервер.

Все тесты выполнялись локально на одном компьютере. Вы можете получить более 15000 запросов в секунду при прямом доступе, 4300 запросов в секунду на удаленный доступ HTTP/1.1. Это было проверено на ноутбуке с использованием CPU Centrino2 с включенным AntiVirus.

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

Этот тест проверяет скорость клиента и сервера и не многопоточен (даже если наша инфраструктура является многопотоковой).

Итак, вы можете догадаться, что для блока данных размером 4 КБ содержимого JSON для каждого запроса:

• Прямой доступ (например, ваш подход к dll) является самым быстрым и менее ресурсоемким.
• Затем сообщения GDI.
• Затем именованные каналы.
• Затем FastCGI и HTTP (в зависимости от вашего веб-сервера для FastCGI классы HTTP очень мало потребляют).

Сохранять живые соединения - это соединения HTTP/1.1, а multi-соединение - простой HTTP/1.0, с новым соединением для каждого запроса. Multi-connect не так уж плох, потому что с точки зрения сервера мы использовали эффективный пул потоков на основе портов завершения ввода-вывода.

См. http://synopse.info/forum/viewtopic.php?id=90

Ответ 6

Использовать файлы с отображением памяти. Они отлично подходят для ваших конкретных задач. И наш MsgConnect с ним переносит транспорт MMF, если у вас нет времени или намерения реализовать пользовательскую схему.

Ответ 7

Я бы направил направление файлов с отображением памяти, но я бы не реализовал прямо в пути к коду. Вместо этого я бы прошел через промежуточный объект, который будет выполнять запись в файл с отображением памяти, таким образом, он может быть заменен на который просто отбрасывал данные, если он не был на месте.

Когда программа сначала запускается (или ей предлагается проверить с помощью изменения конфигурации), система будет либо создавать заглушку "ничего не делать", либо объект "log to memory mapped files". Это также дает возможность добавлять более поздний отладчик, когда возникает такая необходимость... например, логгер UDP для ведения журнала сети и т.д.

Вы можете использовать вызов "FindWindow", чтобы узнать, работает ли ваш отладчик.

Ответ 8

Если вы хотите использовать временный файл в качестве транспорта, то это будет легко

• Обе программы регистрируют одно и то же сообщение при запуске MsgAppNotifyID: = RegisterWindowMessage (......);

• Программа Y должна иметь коды для обработки настраиваемого сообщения используя SetWindowLong или что-то подобное

• Программа X, используя FindWindow, чтобы проверить, работает ли программа Y или нет

• Программа X, если Y запущена, создайте временный файл в известном каталоге location/of the end с использованием согласованного имени файла, такого как формат XXYY1234 (XXYYn), где 1234 = n

• Программа X, используйте BroadcastSystemMessage для передачи сигнала Y NotifyRecipients: = BSM_APPLICATIONS; BroadcastSystemMessage (BSF_IGNORECURRENTTASK или BSF_POSTMESSAGE или BSF_FORCEIFHUNG, @NotifyRecipients, MsgAppNotifyID, любое пользовательское значение, n);

• Программа y, обрабатывает выше сообщение с использованием WParam как n и восстанавливает файл для процесса

Приветствия Удачи.

Ответ 9

работает TCP-сервер, который просто подключается (как триггер) очень быстро и должен делать то, что вы хотите