Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Служба [D6, NT4, Win2k, WinXP]

Страницы: 1 2 >
MU © (2005-12-14 15:52:00)
Есть некая служба, которая читает данные, допустим, из COM порта или по TCP/IP и складывает их в файл на диске. (он читается и удаляется другой программой)
Видимо, пользователю нужна программа-монитор, висящая в трее, с помощью которой он мог бы запустить, остановить, настроить эту службу (тут, вроде бы, все понятно). но и наблюдать за процессом чтения.
Вопрос: Как лучше организовать этот просмотр?
Использовать файлы, проецируемые в память?

Набережных С. (2005-12-15 12:11:00) [1]
По-моему, не упомянут еще один способ - COM-сервер в сервисе, извиняюсь, если не заметил. Имхо, возни с ним меньше всего, все заботы берет на себя надежный системный механизм. Как и у других перечисленных - все возможности защиты, в том числе и отсутствие ее, имперсонация. По мне так самое удобное.

Игорь Шевченко (2005-12-15 10:11:00) [2]
BiN © (14.12.05 20:02) [25]

> Момент о переключении контекстов выделил желтым.

Выделенное желтым относится к NT 3.51, насколько я понимаю.
Похоже, что я когда писал о том, что читал про переключение, попался в те же сети, fast lpc был до NT4

С уважением,

BiN (2005-12-15 09:48:00) [3]

> Leonid Troyanovsky © (15.12.05 08:43) [26]
>
> Спасибо, посмотрел.
> Это где fast LPC? Спрашиваю, потому как выделение не нашел.
>

Файл Key System Components.doc. Поиск по слову LPC.

Leonid Troyanovsky (2005-12-15 08:43:00) [4]

> BiN © (14.12.05 20:02) [25]

> Вот выложил 2 отрывка из Inside w2k об lpc
>
> http://binary.front.ru/downloads/lpc/
>
> на-английском, правда. Момент о переключении контекстов
> выделил желтым.

Спасибо, посмотрел.
Это где fast LPC? Спрашиваю, потому как выделение не нашел.

--
Regards, LVT.

BiN (2005-12-14 20:02:00) [5]

> Leonid Troyanovsky © (14.12.05 18:12) [21]
>
>
>
> Ай, блин, а чего оно все загружать просит?
> И текст в глазах рябит :(
> Можно своими словами, если не влом?

Вот выложил 2 отрывка из Inside w2k об lpc

http://binary.front.ru/downloads/lpc/

на-английском, правда. Момент о переключении контекстов выделил желтым.

Leonid Troyanovsky (2005-12-14 18:53:00) [6]

> Игорь Шевченко © (14.12.05 18:37) [23]

> Зато нашел диаграмму взаимодействия клиента и сервера через
> LPC
> http://flinflon.brandonu.ca/Dueck/2003/62306/MessagePassing.
> htm

Все равно, Большое тебе Программистское Спасибо.
Диаграмму я даже распечатал для отпугивания начальства.

Даже нашел про 304 байта.

Но, что ж у них всех со шрифтами,
млин, или очки новые нужно заказывать :(

--
Regards, LVT.

Игорь Шевченко (2005-12-14 18:37:00) [7]
Похоже, что с отсутствием переключения контекстов я погорячился.

Зато нашел диаграмму взаимодействия клиента и сервера через LPC
http://flinflon.brandonu.ca/Dueck/2003/62306/MessagePassing.htm

Игорь Шевченко (2005-12-14 18:31:00) [8]
Leonid Troyanovsky © (14.12.05 18:08) [20]

Судорожно пытаюсь вспомнить, где именно я это читал, не у Руссиновича, это точно, они с Соломоном про LPC немного пишут, как вариант - у Танненбаума или где-то в тырнете.

Leonid Troyanovsky (2005-12-14 18:12:00) [9]

> BiN © (14.12.05 18:05) [18]

> В качестве "малого" объема информации по LPC-порту можно
> передать 304 (324?) байта + информация о процессе и потоке
> клиента. Для бОльших объемов LPC использует MMF.

Ладно, пойду почитаю :)

Ай, блин, а чего оно все загружать просит?
И текст в глазах рябит :(
Можно своими словами, если не влом?

--
Regards, LVT.

Leonid Troyanovsky (2005-12-14 18:08:00) [10]

> Игорь Шевченко © (14.12.05 18:03) [17]

> Правильно говорят. В каком-то месте я даже читал, что контекст
> не переключается.

Вот, ты б это место напомнил, было б тебе от меня большое
программистcкое спасибо.

А то я свои книжки растерял, при переезде :(

--
Regards, LVT.

BiN (2005-12-14 18:08:00) [11]

> Игорь Шевченко © (14.12.05 18:03) [17]
>
>
> Вот так вот :)

CreatePipe
CallNamedPipe
ConnectNamedPipe
CreateNamedPipe
DisconnectNamedPipe
GetNamedPipeHandleState
GetNamedPipeInfo
PeekNamedPipe
SetNamedPipeHandleState
TransactNamedPipe
WaitNamedPipe

Их намного меньше?
-)

BiN (2005-12-14 18:05:00) [12]

> Leonid Troyanovsky © (14.12.05 17:59) [15]
>
> > факт, что на локальных машинах в качестве IPC Remote Procedure
>
> > Call использует не каналы, а, собственно, LPC.
>
>
> Для передачи 4 (8?) байт - LPC, ну, а более - проекции файла.
>

В качестве "малого" объема информации по LPC-порту можно передать 304 (324?) байта + информация о процессе и потоке клиента. Для бОльших объемов LPC использует MMF.

Игорь Шевченко (2005-12-14 18:03:00) [13]
BiN © (14.12.05 17:45) [11]

> Набор функций LPC мало отличается от pipe-функций.

Вот так вот :)

NtAcceptConnectPort
NtCompleteConnectPort
NtConnectPort
NtCreatePort
NtImpersonateClientOfPort
NtListenPort
NtQueryInformationPort
NtReplyPort
NtReplyWaitReceivePort
NtReplyWaitReplyPort
NtRequestPort
NtRequestWaitReplyPort
NtSecureConnectPort

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

> А по скорости: Руссинович с Соломоном, помнится, говорят,
> что LPC самый быстродейственный механизм межпроцессовой
> коммуникации

Правильно говорят. В каком-то месте я даже читал, что контекст не переключается.

Leonid Troyanovsky (2005-12-14 18:01:00) [14]

> BiN © (14.12.05 17:55) [14]

> Хорош, но требуется отдельно организовывать синхронизацию.

А зачем? Он же r/o и на момент обработки запроса.

--
Regards, LVT.

Leonid Troyanovsky (2005-12-14 17:59:00) [15]

> BiN © (14.12.05 17:45) [11]

> факт, что на локальных машинах в качестве IPC Remote Procedure
> Call использует не каналы, а, собственно, LPC.

Для передачи 4 (8?) байт - LPC, ну, а более - проекции файла.
Но, не буду врать, давно не перечитывал.

--
Regards, LVT.

BiN (2005-12-14 17:55:00) [16]

> Leonid Troyanovsky © (14.12.05 17:54) [13]
>
>
> Дык, локально и возврат клиенту read only MMF был бы хорош.
>

Хорош, но требуется отдельно организовывать синхронизацию.

Leonid Troyanovsky (2005-12-14 17:54:00) [17]

> BiN © (14.12.05 17:47) [12]

> > Ну, то ж локально.

> Кто ж спорит?

Дык, локально и возврат клиенту read only MMF был бы хорош.

--
Regards, LVT.

BiN (2005-12-14 17:47:00) [18]

> Leonid Troyanovsky © (14.12.05 17:35) [10]
>
>
> Ну, то ж локально.

Кто ж спорит?

BiN (2005-12-14 17:45:00) [19]

> Игорь Шевченко © (14.12.05 17:27) [9]
>
>
> Named pipes клиента я делал, даже небольшую статейку писал.
> А вот про LPC-обмен читал у Неббета, показалось, что писанины
> там на порядок больше.
>

К сожалению, не могу сейчас посмотреть пример Неббета, но "на порядок" - имхо, громко сказано. Набор функций LPC мало отличается от pipe-функций.

У LPC есть полезное свойство - идентификация клиентского процесса и потока.
А по скорости: Руссинович с Соломоном, помнится, говорят, что LPC самый быстродейственный механизм межпроцессовой коммуникации, о чем может косвенно свидетельствовать тот факт, что на локальных машинах в качестве IPC Remote Procedure Call использует не каналы, а, собственно, LPC.

Leonid Troyanovsky (2005-12-14 17:35:00) [20]

> BiN © (14.12.05 17:23) [8]

> Имхо, реализация клиент-сервера LPC не сложнее создания
> канального IPC.

Ну, то ж локально.

--
Regards, LVT.

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »