Двусторонняя связь с использованием Cromis IPC

Question

Я загрузил и сыграл игру с компонентами Cromis IPC от Iztok Kacin.

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

Я могу с радостью отправить сообщение от клиента на прослушивающий сервер, но, похоже, я не могу отправить сообщение клиенту, если он не является ответом.

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

Answer 1

Я являюсь автором компонентов, а другие уже сказали вам, что нет способа сделать двустороннюю связь на данный момент. Причина проста, ее работа по названию работает. Было бы очень сложно поддерживать постоянную связь между клиентом и сервером, и, честно говоря, IPC не об этом. Но поскольку есть моменты, когда вам нужно получать уведомления о наличии новых данных, я думаю о переходе независимого механизма сигнализации. Таким образом, сервер может уведомить клиента о том, что для него что-то есть. Затем клиент будет обращаться к данным так же, как и сейчас. Сейчас я выступаю за реализацию этого как совершенно отдельный компонент, который затем будет легко использоваться вместе с моим IPC.

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

Answer 2

Вам понадобятся сервер и клиент с обеих сторон.

Answer 3

Короткий ответ:

Cromis IPC является Названный реализация труб. Клиент отвечает за отправку набора команд, который должен быть определен как протокол приложения. Соответствующий сервер слушает клиентов и выступает в качестве процессора для обработки этих запросов протокола. В вашем случае вы хотите иметь двунаправленную связь, поэтому вы должны создать клиент и сервер для обоих процессов с двумя протоколами.

Длинный ответ:

Вы можете использовать Cromis IPC, чтобы сделать работу. Как я уже описал выше, вам необходимо определить два протокола для конкретных приложений и написать клиенты протокола и процессоры протокола самостоятельно. Это замечательная работа.

Недавно я столкнулся с Apache Thrift. Apache Thrift стремится обеспечить высокоэффективную инфраструктуру IPC. Одна из фантастических особенностей Apache Thrift заключается в том, что он может автоматически генерировать самый код для IPC. И он поддерживает Delphi.

Вам просто нужно определить конкретные протоколы приложений в файле спецификаций. Thrift создаст для вас соответствующий клиентский и процессорный код. Также он поддерживает не только Named Pipe, вы можете выбрать сокеты или другие транспортные реализации. Это действительно стоит попробовать.