Задача такова: из приложения передать сервису команду и дождаться ее выполнения. Кроме того, в процессе выполнения сервис должен возвращать приложению протокол выполнения и прочие данные. Клиентское приложение после отправки команды, в свою очередь, должно приостановить свое выполнение и в цикле принимать данные от сервиса.

ВОПРОС: Какой метод обмена данными (pipes, dde, wm_copydata и т.д.) правильнее использовать в данном случае.

Спасибо.

ЗЫ: Буду весьма признателен за ссылки, где почитать на эту тему.

TCP

http

pipes

Я в итоге остановился на именованных каналах, чегой-то они мне больше всех понравились + нет проблемы со всякими фаерволами, как в случае использования TCP, никто не мучает пользователя вопросами, разрешить этот порт или нет? :)
У себя в сервисах использую вот эту реализацию: http://rouse.drkb.ru/network.php#fwiocompletionpipe

> Rouse_ ©


Спасибо.

> [4] Rouse_ ©   (01.03.11 15:26)

тоже использую pipe'ы, видимо это оптимальный вариант, т.к. его использует и ОС.

> Eraser ©   (01.03.11 19:55) [6]

> тоже использую pipe'ы, видимо это оптимальный вариант, т.
> к. его использует и ОС.

Мне хттп нравится.

После общения, с интеллектуальным устройством
чувствуешь себя намного умней.

--
Regards, LVT.

> [7] Leonid Troyanovsky ©   (01.03.11 20:11)

А с безопасностью как быть? С пайпами все просто и понятно.

> А с безопасностью как быть?

А что с ней не так?

> А с безопасностью как быть?
хттпs, всем инетом "дырки" ищут. проверено перепроверено.

> С пайпами все просто и понятно.
а что не понятного с хттп?

не путаешь кстати протокол, и данные по нему передающиеся? у меня такое впечатление, что безопасность "всплыла" из-за твоей уверенности, что по хттп только "открытый текст" передается/обязывают передавать.

> [10] sniknik ©   (02.03.11 16:48)


> хттпs

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

про http(s) это не я предложил, но суть понятна. в некоторых случаях действительно оправдано.

> в некоторых случаях действительно оправдано

когда web-service, например, типа платежной системы.
А если в локалке или вообще на одном компе, нафига пушка для воробьев?

нафига пушка для воробьев?

например чтобы иметь и поддерживать одну пушку, а не две.

серверный код и клиентскую программу.

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

что-то не совсем уловил мысль...
мне в хттп видится плюс только в случае потенциального выхода общения клиента с сервером за рамки локалки. А если это 100 лет никому не понадобится?

> А если это 100 лет никому не понадобится?
значит 100 лет никто этим не будет пользоваться... а на 101-й какой нибудь "Архимед" воскликнет "вона, что тута есть оказывается, то что нужно!".

при примерно равных "трудозатратах"(а то и проще) этого в сравнении с остальным.

что-то не совсем уловил мысль...

да все просто.
имеем транспорт в виде пайпа.
из этого вытекает, что на обоих его концах надо програмировать.

например клиент придумал новый тип запроса. сервер должен его уметь обрабатывать.

итого: программируем две "пушки".

а если будет шттп, то клиентская пушка (браузер) уже готова.

> клиентская пушка (браузер) уже готова

браузеры, слава Всевышнему, пока еще не заменили все остальные приложения. И в [0] под приложением вовсе не обязательно речь идет о браузере

> clickmaker ©   (02.03.11 22:19) [18]

> приложения. И в [0] под приложением вовсе не обязательно
> речь идет о браузере

Вовсе необязательно.
Но, приятней из браузера.

--
Regards, LVT.