Служба

← →
MU © (2005-12-14 15:52) [0]

Есть некая служба, которая читает данные, допустим, из COM порта или по TCP/IP и складывает их в файл на диске. (он читается и удаляется другой программой)
Видимо, пользователю нужна программа-монитор, висящая в трее, с помощью которой он мог бы запустить, остановить, настроить эту службу (тут, вроде бы, все понятно). но и наблюдать за процессом чтения.
Вопрос: Как лучше организовать этот просмотр?
Использовать файлы, проецируемые в память?

← →
Digitman © (2005-12-14 16:09) [1]

я бы предпочел NamedPipes

← →
BiN © (2005-12-14 16:19) [2]

а я бы - LPC

← →
MU © (2005-12-14 16:34) [3]

>> Digitman © (14.12.05 16:09) [1]
видел (читал про такое)
>> BiN © (14.12.05 16:19) [2]
где можно почитать об этом?

← →
Игорь Шевченко © (2005-12-14 16:39) [4]

BiN © (14.12.05 16:19) [2]

Мозолей на пальцах прибавится

← →
Digitman © (2005-12-14 16:43) [5]

> MU © (14.12.05 16:34) [3]
> видел (читал про такое)

почему бы не попробовать-задействовать ?

для MS - наиболее "родной" и наиболее высокопроизводительный способ интерпроцессных коммуникаций ..

← →
MU © (2005-12-14 16:46) [6]

всем спасибо.

← →
Digitman © (2005-12-14 16:57) [7]

всем носить не стаптывать.

← →
BiN © (2005-12-14 17:23) [8]

> MU © (14.12.05 16:34) [3]
>
> >> BiN © (14.12.05 16:19) [2]
> где можно почитать об этом?

http://www.windowsitlibrary.com/Content/356/08/2.html
http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Port/NtConnectPort.html

у Неббета тоже об этом вроде есть.

> Игорь Шевченко © (14.12.05 16:39) [4]
>
> BiN © (14.12.05 16:19) [2]
>
> Мозолей на пальцах прибавится

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

зы.
Мазолей не прибаваляется. -)

← →
Игорь Шевченко © (2005-12-14 17:27) [9]

BiN © (14.12.05 17:23) [8]

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

Named pipes клиента я делал, даже небольшую статейку писал. А вот про LPC-обмен читал у Неббета, показалось, что писанины там на порядок больше.

← →
Leonid Troyanovsky © (2005-12-14 17:35) [10]

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

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

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

--
Regards, LVT.

← →
BiN © (2005-12-14 17:45) [11]

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

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

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

← →
BiN © (2005-12-14 17:47) [12]

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

Кто ж спорит?

← →
Leonid Troyanovsky © (2005-12-14 17:54) [13]

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

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

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

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

--
Regards, LVT.

← →
BiN © (2005-12-14 17:55) [14]

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

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

← →
Leonid Troyanovsky © (2005-12-14 17:59) [15]

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

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

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

--
Regards, LVT.

← →
Leonid Troyanovsky © (2005-12-14 18:01) [16]

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

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

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

--
Regards, LVT.

← →
Игорь Шевченко © (2005-12-14 18:03) [17]

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 самый быстродейственный механизм межпроцессовой
> коммуникации

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

← →
BiN © (2005-12-14 18:05) [18]

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

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

← →
BiN © (2005-12-14 18:08) [19]

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

CreatePipe
CallNamedPipe
ConnectNamedPipe
CreateNamedPipe
DisconnectNamedPipe
GetNamedPipeHandleState
GetNamedPipeInfo
PeekNamedPipe
SetNamedPipeHandleState
TransactNamedPipe
WaitNamedPipe

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

← →
Leonid Troyanovsky © (2005-12-14 18:08) [20]

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

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

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

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

--
Regards, LVT.

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

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

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

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

--
Regards, LVT.

Leonid Troyanovsky © (14.12.05 18:08) [20]

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

Похоже, что с отсутствием переключения контекстов я погорячился.

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

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

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

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

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

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

--
Regards, LVT.

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

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

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

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

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

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

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

--
Regards, LVT.

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

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

BiN © (14.12.05 20:02) [25]

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

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

С уважением,

По-моему, не упомянут еще один способ - COM-сервер в сервисе, извиняюсь, если не заметил. Имхо, возни с ним меньше всего, все заботы берет на себя надежный системный механизм. Как и у других перечисленных - все возможности защиты, в том числе и отсутствие ее, имперсонация. По мне так самое удобное.

Служба Найти похожие ветки