имеется рабочий проект : приложение работающее как сервер, соединение с клиентами через сокеты виндавз.
и вот понадобилось чтоб этот сервер работал еще и как сервис NT. Ничего сложного вроде нет. Но вот еще требуется чтоб работал он с GUI-интерфейсом, когда юзер залогинился, чтоб можно было на лету конфигурировать его (недопустима перезагрузка или останов сервера) — настройки менять, отслеживать состояния сервера, с учетными записями работать и так далее. В голову приходит мысль об интерактивном сервисе. Это как вариант. Другой вариант использование локального com(out-proc) или dcom (к сожалению ни с тем ни с другим пока не имел опыта).
поделитесь мыслями
Прошу прощения за Аноним, только сейчас зарегестрироваться смог...
Вообще подобных решений наверняка туева хуча, только сколько не искал нигде вразумительной инфы не нашел...
Здравствуйте, Tom, Вы писали:
Tom>Microsoft в таких случаях использует чистый RPC. Почему они не используют COM я не знаю, но в принципе эта задача может быть решена, на основе COM просто и элегантно.
Интересно было бы поиметь инфу про "такие случаи", вопрос довольно распространенный насколько я понимаю, но нигде (в MSDN в частности) ничего не видел (наверное плохо смотрел, хотя это камень в огород микромягкого).
Меня что смущает при реализации через COM:
1. Сервис работает в систем логон сессии и какие из этого грабли возникнут (или не возникнут)
2. Вот первый сценарий работы :
2.а. Включился комп, загрузилась винда, запускается сервис
2.б. Сервис регистрирует фабрики (CoRegisterClassObject)
2.в. Заходит юзер ушастый в систему через логин, получает свой рабстол с позорными обоями...
2.г. Юзер запускает тот же экзешник (который запущен уже как сервис)
2.д. И вот тут запрашивается COM-интерфейс (который в сервисе, типа)
2.е. Ну допустим запросили, получили и работаем с этим интерфейсом...
2.ж. Трабл : допустим юзер взял и остановил сервис (что ? не давать ему это сделать ??? или еще и грохнуть процесс клиента подключенного ??? жестоко по отношению к клиенту...)
3. Второй сценарий :
3.а. Сервис не запущен, но юзер запустил его как приложение в своей раб станции.
3.б. И тут же зачем то и сервис запускает (ваще дурной!!!), ну и ладно...
3.в. А затем хочет выгрузить запущенное приложение в котором зарегестрированы фабрики !!!
3.г. Трабл : не давать ему закрывать приложение ??? нелогично ведь... вот хочется ему закрыть его, мешает ему этот процесс
4. Один важный момент, который очень непонятен мне : статистика подключений должна обновляться и выводиться в GUI-интерфейс,то есть что то вроде виртуальных функций интерфейса !!! это в голове пока не укладывается, или в действительности тут ничего такого нет...
5. А еще смущает написание prox\stub (что для com и для rpc), хотя без этого просто не обойтись видимо.
кстати COM для межпроцессной связи использует LPC (local procedure call). Оно работает на основе RPC.
P>1. Сервис работает в систем логон сессии и какие из этого грабли возникнут (или не возникнут)
Что такое "систем логон сессия"?
P>2. Вот первый сценарий работы :
P>2.а. Включился комп, загрузилась винда, запускается сервис
P>2.б. Сервис регистрирует фабрики (CoRegisterClassObject)
P>2.в. Заходит юзер ушастый в систему через логин, получает свой рабстол с позорными обоями...
P>2.г. Юзер запускает тот же экзешник (который запущен уже как сервис)
Пользователь может запускать тот же EXE, где находится сервис, но так обычно не делают. Клиентское и серверное
приложения делят по разным исполняемым модулям.
P>2.д. И вот тут запрашивается COM-интерфейс (который в сервисе, типа)
Тут создаётся обьект, при помощи фабрики.
P>2.е. Ну допустим запросили, получили и работаем с этим интерфейсом...
P>2.ж. Трабл : допустим юзер взял и остановил сервис (что ? не давать ему это сделать ??? или еще и грохнуть процесс клиента подключенного ??? жестоко по отношению к клиенту...)
Если пользователь случайным образом останавливает системные сервисы, то от такого пользователя ничего не спасёт. И защиты такой обычно не делают. Максимум, что можно придумать — это сообщение пользователю, но и это не есть хорошо.
P>3. Второй сценарий :
P>3.а. Сервис не запущен, но юзер запустил его как приложение в своей раб станции.
P>3.б. И тут же зачем то и сервис запускает (ваще дурной!!!), ну и ладно...
P>3.в. А затем хочет выгрузить запущенное приложение в котором зарегестрированы фабрики !!!
Фабрика в сервисе и фабрика в простом EXE рассматриваются, как разные.
P>3.г. Трабл : не давать ему закрывать приложение ??? нелогично ведь... вот хочется ему закрыть его, мешает ему этот процесс
P>4. Один важный момент, который очень непонятен мне : статистика подключений должна обновляться и выводиться в GUI-интерфейс,то есть что то вроде виртуальных функций интерфейса !!! это в голове пока не укладывается, или в действительности тут ничего такого нет...
Не понятно о чём идёт речь
P>5. А еще смущает написание prox\stub (что для com и для rpc), хотя без этого просто не обойтись видимо.
За 4 года использования COM мне понадобилось написать ручками proxy/stub только однажды и то для самообразования.
P>кстати COM для межпроцессной связи использует LPC (local procedure call). Оно работает на основе RPC.
