NamedPipe

← →
andrey__ (2004-11-03 16:26) [0]

Вопрос такой: Подскажите можно ли после того как произошёл разрыв соединения между сервером канала и клиентом (клиент был закрыт) новому клиенту соединится к этому же экземпляру канала сервера.

← →
Игорь Шевченко © (2004-11-03 16:40) [1]

Можно.

← →
Digitman © (2004-11-03 16:56) [2]

> andrey__ (03.11.04 16:26)

можно.

толькло не забудь сделать экз-ру DisconnectNamedPipe, прежде чем ты сотворишь ему новый ConnectNamedPipe

← →
andrey__ (2004-11-03 17:07) [3]

подскажи пожалуста как это сделать:
- каким образом сервер узнает что его экземпляр канала освободился
- для соединения нового клиента к освободившемуся экземпляру канала сервер повторно должен использовать ConnectNamedPipe(hPipe, nil) ?

← →
Digitman © (2004-11-03 17:30) [4]

> для соединения нового клиента к освободившемуся экземпляру
> канала сервер повторно должен использовать ConnectNamedPipe(hPipe,
> nil) ?

да, разумеется ... если ты не сделал перед этим Closehandle(hPipe)

насчет nil 2-м параметром - это требует отдельной дискуссии.

> каким образом сервер узнает что его экземпляр канала освободился

все зависит от синхр. или асинхр. режима использования пайпа.
конкретизируй режим.

← →
andrey__ (2004-11-04 11:38) [5]

>Digitman © (03.11.04 17:30) [4]

Более подробно опишу свою задачу: 2-ва приложения
- одно сервис работает постоянно
- второе програмка управления работой сервиса (изменение параметров работы)
Общение между приложениями решил организовать посредством NamedPipe

Т.к. информации я нашёл мало по NamedPipe (может плохо искал) отталкивался я в своей работе от статьи http://www.delphimaster.ru/articles/named_pipes/index.html#PageTop (это на случай если вы читали)

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

> - одно сервис работает постоянно
> - второе програмка управления работой сервиса (изменение
> параметров работы)
> Общение между приложениями решил организовать посредством
> NamedPipe

это понятно.
ничего против идеи не имею - пайпы значит пайпы ..

> В ней используется асинхронный режим (если у вас есть сомнения
> насчёт того что он плохо подходит для моей задачи прошу
> написать мне об этом).

сомнений у меня никаких нет.

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

касаемо выбора упомянутого режима можно лишь дать самые общие рекомендации.

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

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

andrey__ (04.11.04 11:38) [5]

Абсолютно разумная идея.

Пример ее реализации можно найти в Рихтер,Кларк "Программирование серверных приложений" или в Platform SDK\Samples\...\Service

а я обычно на сокетах всё делаю :)))

NamedPipe Найти похожие ветки