C ++ — Что такое хороший метод межпроцессного взаимодействия между C и PHP в Linux
Я на самом деле не знаю, задаю ли я правильный вопрос. Позвольте мне сначала описать мою проблему.
Конечный пользователь <-1-> веб-сервер (по PHP) <-2-> внутренний процесс (на C или C ++) <-3-> внешнее оборудование
1 должен быть чем-то вроде запроса ajax.
2 должно быть чем-то вроде межпроцессного взаимодействия.
3 должен быть UART RS232 связи.
Конечный пользователь запросит изменение некоторых параметров оборудования, затем запрос будет распространен на оборудование. Аппаратное обеспечение отвечает успешно или неудачно, а затем результат будет передан обратно пользователю. Аппаратная задержка ответа может быть в пределах 1 секунды.
Поэтому, когда веб-сервер получает ajax-запрос от конечного пользователя, он удерживает и отправляет IPC-запрос программе c / c ++. Программа c / c ++ будет отправлять через UART, удерживать и ждать ответа оборудования. Для части UART существует асинхронная модель UART, поэтому программе c / c ++ не нужно будет постоянно ожидать UART.
Веб-сервер будет ждать, пока программа c / c ++ вернется (снова через IPC), а затем перенаправит результат обратно конечному пользователю.
Поскольку у веб-сервера нет памяти, асинхронных вещей быть не может (насколько я понимаю).
Я могу думать о простом способе, который через файл или базу данных. Веб-сервер постоянно читает файлы или базу данных для ответа.
Но на самом деле я не думаю, что это хороший способ, потому что он приводит к потере процессорных циклов сервера.
Если я могу терпеть некоторые задержки, ну, это зависит, но я думаю, что несколько секунд задержки на стороне пользователя — это нормально.
Можете ли вы предложить мне несколько хороших способов IPC для достижения моей цели?
И, если вы думаете, что есть лучшее решение (чем мое описание выше) для всего процесса или любой конкретной ссылки (включая ссылку 1, 2 & 3), пожалуйста, поделитесь своим 2cent.
Надеюсь, я четко задал свой вопрос.
Благодарю.
Решение
Возможно, самое простое решение, которое вы можете найти, это использовать трубы. У процессов будет открытый канал для чтения «вызовов» и ответа на них таким же образом.
Один из возможных способов настроить это — иметь пару именованных каналов (mkfifo) в определенном или переменном месте. Такие каналы известны как этому процессу, так и PHP. Процесс блокирует чтение цикла для запросов / команд в некотором текстовом «протоколе» и обратную запись в PHP через другой канал. Таким образом, как PHP, так и внешние процессы могут быть остановлены / уничтожены и перезапущены, а путь связи будет по-прежнему стабильным.
Возможно, вам придется сделать что-то еще, чтобы проверить, действительно ли процесс запущен, если это необходимо, но простой команды «ping» над этим «протоколом» будет достаточно.
Это предполагает:
- у вас есть возможность вносить улучшения в процессы, которые взаимодействуют с оборудованием (в противном случае вы связаны с тем, что оно уже предлагает)
- у вас нет высоких требований к производительности (трубы работают относительно медленно)
- нет никакой проблемы параллелизма в случае одновременного доступа из сценария PHP к обработке (если вы не сделаете некоторую блокировку, 2 параллельных запроса будут записаны смешанными в конвейере)
Конечно, есть и другие способы достижения этого, но мне трудно найти другой способ, который так прост, как этот. Организация очередей (d-bus, другие), как предлагается в некоторых комментариях, просто строится на основе этой идеи, но добавляет ИМХО большей сложности, поэтому, если не требуется функциональность, предоставляемая этими другими службами, каналов должно быть достаточно.
Другие решения
Просто мои 2 цента (должен быть комментарий, но у меня нет репутации) используют zeromq или другую известную библиотеку очередей для вашего ipc.
Теоретически очень просто использовать fifo и доменные сокеты, однако на практике существует множество крайних случаев, для которых вам нужно было бы написать код. Например, высокая отметка, повторное подключение и т. Д.