[ главная ]   [ рейтинг статей ]   [ справочник радиолюбителя ]   [ новости мира ИТ ]



Ответов: 0
25-02-12 07:01







   Web - программирование
PHP


ASP






XML



CSS

SSI





   Программирование под ОС











   Web - технологии








   Базы Данных









   Графика






Данные




Операционные системы / Windows /

Программирование служб Windows 7 с триггерами (ч.1)

Несколько недель назад мы рассмотрели изоляцию Сессии 0 в свете программной совместимости. Поэтому вполне естественно, что мы возвращаемся к обсуждению служб в контексте Windows 7. Но на этот раз мы поговорим о некоторых выгодах оптимизации служб, доступных в Windows 7. Эта статья посвящена новой возможности Windows 7 - Trigger Start Services. Но прежде, чем мы обратимся к API, давайте обрисуем общий фон служб.

Что такое службы?
Служба - это внутренний механизм, встроенный в операционную систему Windows. Вы можете считать службы специальными приложениями, работающие вне зависимости от текущего пользовательского контекста. Службы отличаются от обычных приложений тем, что вы можете настроить службу на работу с момента включения (загрузки) системы и до ее выключения, не требуя присутствия пользователя, то есть, службы могут работать, даже если пользователь не выполнил вход в систему.

Мы предпочитаем считать службы запущенными задачами, работающими в фоновом режиме и не затрагивающими операции пользователя. Службы в Windows отвечают за все виды фоновой активности, начиная со службы Remote Procedure Call (RPC), Printer Spooler и вплоть до службы Network Location Awareness.

На протяжении многих лет Windows росла и вместе с ней росло число фоновых служб. Будем честны, фоновые службы в Windows ощущаются довольно болезненно - операционная система изначально поставляется с множеством служб. Помимо этого, независимые разработчики ПО (ISV) и их приложения добавляют еще больше служб. Назовем в пример хотя бы службы обновления программного обеспечения. Вместе с тем, некоторые службы критически важны и требуются в процессе загрузки, в то время как необходимость в других возникает позже, когда определенный пользователь выполняет вход в систему, а иные вовсе не нуждаются в запуске, пока не будут вызваны. Несмотря на это, когда вы смотрите на список запущенных в данный момент служб, вы видите множество служб, которым нет необходимости работать по схеме 24х7.
Что плохого в службах, работающих 24 часа в сутки 7 дней в неделю?
Есть несколько проблем, связанных с наличием служб, работающих по схеме 24х7. Во-первых, зачем что-то должно работать (пускай даже и в фоновом режиме), если в его работе нет нужды? Любой запущенный процесс (включая службы) использует драгоценную память и ресурсы ЦП, которые могли бы использоваться для других приложений и служб. Если вы подсчитаете все службы, запущенные в определенный момент, то они служатся в значительный объем памяти, дескрипторов, потоков и использование ЦП. Все эти "растрачиваемые" ресурсы понижают общую производительность компьютера, его отзывчивость и заставляют пользователя думать, что его компьютеры вялые и медлительные. К тому же, поскольку множество работающих служб настроены на автоматический запуск (начинают работать со входом в систему), эти службы влияют на время загрузки компьютера.

Во-вторых, эти растрачиваемые ресурсы непосредственным образом сказываются на потреблении электроэнергии. Чем больше нагрузки мы даем на ЦП, тем больше электроэнергии компьютер потребляет. Это может быть критически важно для ноутбуков и может сократить время работы батареи на несколько часов.

В-третьих, постоянная работа непродуктивного программного обеспечения может привести к утечкам памяти и общей нестабильности системы. Это может привести к сбою в работе приложения и, в конце концов, компьютера.

Наконец, если служба работает по схеме 24х7, и если это хорошо известная служба (которая может оказаться у каждого популярного приложения - например, у PDF Reader), то это создает большую поверхность для атаки. Злоумышленник может воспользоваться сведениями о том, что определенное популярное приложение устанавливает службу, работающую в режиме 24х7, и попытаться взломать ее для получения доступа к компьютеру.

Учитывая все вышесказанное, вы можете удивиться, почему так много разработчиков настраивают свои службы на постоянную работу, если у них имеется другая возможность. Даже до Windows 7 было доступно несколько вариантов запуска служб:

  • Disabled (Отключена) полностью отключает службу и предотвращает ее запуск и запуск зависимых служб - это означает, что пользователь должен включить службу вручную из Панели управления или командной строки
  • Manual (Вручную) запускает службу по надобности (в связи с зависимостями других служб) или при вызове службы из приложения при помощи соответствующих API, как будет показано ниже
  • Automatic (Автоматически) запускает службу при входе в систему
  • Automatic Delayed (Автоматически (отложенный запуск) - более новый тип запуска, появившийся в Windows Vista, при помощи которого запуск службы происходит после завершения загрузки и выполнения первоначальных операций, что ускоряет запуск системы

 

К сожалению, многие ISV (включая саму Microsoft) продолжают настраивать свои службы на автоматический (Automated) или автоматический отложенный запуск (Automatic Delayed), поскольку для всех это представляется простейшим решением. Служба просто работает 24х7 и всегда доступна, устраняя любую необходимость проверки зависимостей или того, запущена ли служба.

Можно привести множество примеров существующих служб, которые могут расходовать куда меньше ресурсов и стать безопаснее, не работая 24х7. Например, подумайте о службе обновлений, которая проверяет наличие новых обновлений для приложения. Если компьютер не подключен к сети и не имеет IP-адреса, зачем работать этой службе? Она ничего не может сделать, так зачем оставлять работающей программу, которая ничего не делает? Подумайте о службе управления политиками, которая используется при изменении групповых политик или при подключении компьютера к домену или отключении от него, но сейчас, когда компьютер подключен к моей домашней сети, служба, опять же, работает впустую.

Появление служб с запуском по триггеру

Решение вышеуказанных проблем заключается в выведении службы из "состояния постоянной работы" в другие виды фоновой активности, такие как запланированные задачи или службы, запускаемые триггером. Эта статья посвящена Windows 7 Trigger Start Services. О Windows 7 Scheduled Tasks можно сказать очень много полезного, что и будет сделано в последующих статьях.

Службы, запускаемые по триггеру (англ. trigger-start service), впервые появились в Windows 7. По сути, это обычная служба, которую вы можете настроить на запуск (или остановку) в случае срабатывания триггера, то есть в определенном случае или состоянии, которые вы сами задаете (например, когда становится доступным IP-адрес или когда он исчезает). Ниже приведен список доступных триггеров, с помощью которых вы можете настроить режим запуска вашей службы:

 

  • Подключение или отключение устройства
  • Вход в домен или выход из него
  • Открытие или закрытия порта брандмауэра
  • Изменение в групповых политиках
  • Доступность первого IP-адреса / исчезновение последнего IP-адреса
  • Настраиваемое событие - Трассировка событий для Windows (ETW)

 

Последний пункт указывает на расширяемость. Будучи разработчиком, вы можете настроить любое событие ETW в качестве триггера для службы, что дает вам очень хороший инструмент для управления запуском и остановкой служб вашего приложения.

Так что же такое триггер?

Триггер состоит из:

 

[lst]

  • Типа события триггера
  • Подтипа события триггера
  • Действия, которое должно быть предпринято при совершении события триггера
  • Одного или более элементов данных, связанных с триггером (для определенных типов событий триггера)
    Подтип и связанные с триггером элементы данных вместе устанавливают состояние для уведомления службы о событии. Формат элемента данных зависит от типа события триггера; элемент данных может состоять из бинарных, строковых или многостроковых данных.


    Работа с Trigger Start Services
    К сожалению, в пользовательском интерфейсе консоли Windows 7 Services MMC нет графического представления Trigger Start Services. Однако у вас есть две возможности. Вы можете по-прежнему использовать старый добрый sc.exe (программа командной строки Service Configuration) или воспользоваться методом WIN32 ChangeServiceConfig2 для программной настройки опций запуска службы, как будет показано в этой статье.

    Использование SC.exe для запроса данных триггера службы (Query Service Trigger Information)
    Пора повеселиться. Начнем с получения сведений о конфигурации некоторых служб. Общая форма для использования конфигурации службы выглядит следующим образом:

    Код:
    sc <server> [command] [service name] <option1> <option2>...

    Где server опционален, а по умолчанию вы работаете с локальным компьютером:

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

    Начнем с запроса определенной службы о ее конфигурации триггера. Для этого нам понадобится запустить окно Windows Shell:

    [ist]1. Откройте меню "Пуск".
    2. Введите CMD в поле поиска.
    3. Выберите cmd.exe.
    4. Введите sc qtriggerinfo w32time и нажмите клавишу ввода.
    Вот, как это должно выглядеть:



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

    Microsoft в Windows 7 обновила приложение командной строки sc.exe для поддержки конфигурации и получения сведений о поддерживаемых триггерах. Введите sc triggerinfo в окне Windows Shell и нажмите клавишу ввода. Результат будет похож на тот, что приведен ниже, и будет содержать все триггеры и сведения о том, как настроить службы на их использование.

    Код:
    ОПИСАНИЕ:
    Изменяет параметры активации службы.
    USAGE:
    sc <сервер> triggerinfo [имя службы] <параметр1> <параметр2>...

    ПАРАМЕТРЫ:
    start/device/UUID/HwId1/... <Запуск службы после получения строки UUID указанного класса интерфейса устройства с одной или несколькими строками кода оборудования или совместимыми строками кода>
    start/custom/UUID/data0/.. <Запуск службы после получения события от строки UUID указанного настраиваемого поставщика трассировки событий Windows с одним или несколькими двоичными элементами данных в формате шестнадцатеричной строки, например,r ABCDABCD, для задания 4 байтов данных>
    stop/custom/UUID/data0/... <Остановка службы после получения события от строки UUID указанного настраиваемого поставщика трассировки событий Windows с одним или несколькими двоичными элементами данных в формате шестнадцатеричной строки, например, ABCDABCD, для задания 4 байтов данных>
    start/strcustom/UUID/data0/.. <Запуск службы после получения события от строки UUID указанного настраиваемого поставщика трассировки событий Windows с одним или несколькими необязательными элементами данных>
    stop/strcustom/UUID/data0/.. <Остановка службы после получения события от строки UUID указанного настраиваемого поставщика трассировки событий Windows с одним или несколькими необязательными элементами данных>
    start/networkon <Запуск службы при первом IP-адресе>
    stop/networkoff <Остановить службу при отсутствии IP-адресов>
    start/domainjoin <Запуск службы при подключении к домену>
    stop/domainleave <Остановка службы при отсоединении от домена>
    start/portopen/параметр <Запуск службы при открытии сетевого порта. Параметр имеет следующую форму: номер_порта;имя_протокола; путь_к_образу;имя_службы>
    stop/portclose/параметр <Остановка службы при закрытии сетевого порта. Параметр имеет следующую форму: номер_порта;имя_протокола; путь_к_образу;имя_службы>
    start/machinepolicy <Запуск службы при изменении групповой политики компьютера или при ее наличии на момент загрузки>
    start/userpolicy <Запуск службы при изменении групповой политики пользователя или при ее наличии на момент загрузки>
    delete <Удаление текущих параметров активации>

    Так всё, что вам нужно для настройки службы на запуск при появлении IP-адреса, - это ввести sc triggerinfo [имя вашей службы] start/networkon, где "имя вашей службы" заменено на имя той службы, которую вы хотите настроить.

    Программная настройка Trigger Start Services при помощи ChanceServiceConfig2
    Более интересным с точки зрения разработчиков аспектом является создание служб, зависящих от триггера, и использование кода для конфигурации службы. В Windows 7 вы можете использовать функцию ChangeServiceConfig2 для настройки данных триггера службы и функцию QueryServiceConfig2 для их вызова.

    Регистрация триггера службы производится вызовом ChangeServiceConfig2 использованием SERVICE_CONFIG_TRIGGER_INFO для параметра dwInfoLevel и представлением данных регистрации триггера в структуре SERVICE_TRIGGER_INFO посредством параметра lpInfo. К тому же, могут быть указаны дополнительные связанные с триггером данные. Ниже приведен пример функции установщика службы, который создает триггер USB-устройства для службы под названием MyService:

    Код:
    define SERVICE_NAME L"MyService"
        //set the device guid
        static const GUID GUID_USBDevice = {
           0x53f56307, 0xb6bf, 0x11d0,
           {0x94, 0xf2, 0x00, 0xa0, 0xc9,
           0x1e, 0xfb, 0x8b }};

    BOOL _SetServiceToStartOnDeviceTrigger()
    {
        BOOL fResult = FALSE;

        SC_HANDLE hScm = OpenSCManager(
            NULL, //local machine
            NULL, //active database
            SC_MANAGER_CONNECT);

        if(hScm != NULL)
        {
            SC_HANDLE hService = OpenService(
                hScm,
                SERVICE_NAME,
                SERVICE_ALL_ACCESS);

            If( hService != NULL)
            {

               LPCWSTR lpszDeviceString = L"USBSTOR\GenDisk";
               SERVICE_TRIGGER_SPECIFIC_DATA_ITEM deviceData = {0};
               deviceData.dwDataType = SERVICE_TRIGGER_DATA_TYPE_STRING;
               deviceData.cbData =
                           (wcslen(lpszDeviceString)+1) * sizeof(WCHAR);   
               deviceData.pData = (PBYTE)lpszDeviceString;


               
               SERVICE_TRIGGER st;
               st.dwTriggerType =
                           SERVICE_TRIGGER_TYPE_DEVICE_INTERFACE_ARRIVAL;
               st.dwAction = SERVICE_TRIGGER_ACTION_SERVICE_START;
               st.pTriggerSubtype = (GUID *) &GUID_USBDevice;
               st.cDataItems = 1;
               st.pDataItems = &deviceData;

               
               SERVICE_TRIGGER_INFO sti;
               sti.cTriggers = 1;
               sti.pTriggers = &st;
               sti.pReserved = 0;

               fResult = ChangeServiceConfig2(
                            hService,
                            SERVICE_CONFIG_TRIGGER_INFO,
                            &sti);
            }
            CloseServiceHandle (hService);
        }
        CloseServiceHandle (hScm);

        if(!fResult)
        {
            printf("Service trigger registration failed (%d)\n",
                     GetLastError());
        }
        return fResult;
    }

    Примечание: все службы контролируются Service Control Manager (SCM), который мы рассмотрим в другой статье.

    Вы можете видеть, как в приведенном выше фрагменте кода мы сначала берем дескриптор (hScm) к SCM вызовом openSCManager. Далее мы вызываем openService и проходим дескриптор к SCM - hscm, и имя службы - SERVICE_NAME, к которой мы хотим получить доступ. Последний параметр, SERVICE_ALL_ACCESS, указывает, что у нас имеется полный доступ к службам. Полагая, что теперь у нас в службе имеется верный дескриптор, мы начинаем создавать отдельную структуру, которой воспользуемся вскоре для настройки службы.

    SERVICE_TRIGGER_SPECIFIC_DATA_ITEM задает тип события триггера. Он содержит данные о событии триггера службы. В нашем случае, мы задаем строку, описывающую подключение USB-диска.

    Затем мы задаем структуру SERVICE_TRIGGER, которая представляет события триггеру службы. Заметьте, что именно здесь мы задаем тип триггера (подключение устройства), действие (запуск службы), и подтип триггера (определенный род USB-дисков). Следом мы определяем конкретное устройство, которое будет вызывать службу. Заметьте, что вы можете задать список устройств и их GUID. Также следует отметить, что мы не хотим срабатывания триггера запуска службы при подключении любого USB-устройства, как то мышь или камера. Мы хотим, чтобы служба запускалась только при появлении USB-диска.

    Наконец, мы задаем структуру SERVICE_TRIGGER_INFO, которая содержит данные события триггера службы. Эта структура просто указывает на структуру SERVICE_TRIGGER, которую мы задали ранее, и количество триггеров, число которых в данном случае равно одному.

    Теперь мы можем вызвать функцию ChanceServiceConfig2 и пройти дескриптор к службе, которую мы хотим настроить, параметр SERVICE_CONFIG_TRIGGER_INFO, который указывает, что мы хотим настроить триггер службы, и Null.

    Вот и все. Если вы все сделали правильно, то служба запуститься при подключении USB жесткого диска.

    В следующей статье я рассмотрю, как написать простую реализацию службы .NET, которую мы настроим на запуск при подключении диска USB.

    Вы можете узнать больше о Windows 7 при помощи Windows 7 Training Kit for Developers или просмотрев видео, посвященные Windows 7, на Channel 9.

    Вы также можете потренироваться в работе с Windows 7 Trigger Start Services при помощи тренинга Windows 7 Online, являющегося частью Channel 9 Learning Center.

  • Источник: TheVista




Комментарии

 Ваш комментарий к данному материалу будет интересен нам и нашим читателям!



Последние статьи: Операционные системы / Windows /

Спасение WINDOWS XP
27-05-2010   

Windows крайне ненадежная операционная система. Сколько бы ни говорили, что XP не такой все это неправда. Он летит просто чуть меньше своих собратьев. Ну, еще, правда он имеет некоторые функции восстановления . Как раз о них я и расскажу в этой статье... подробнее

Кол. просмотров: общее - 3319 сегодня - 1

Реестр WINDOWS XP
27-05-2010   

Реестр. Огромная база данных где хранятся настройки нашей ос. Чего тут только нет! Любой программист создающий достаточно серьезную программу обязательно работает с реестром... подробнее

Кол. просмотров: общее - 3247 сегодня - 0

Командная строка Windows XP + .bat
27-05-2010   

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

Кол. просмотров: общее - 3328 сегодня - 0

Общие сведения о драйверах устройств в системе Windows
17-05-2010   

Естественно, каждая операционная система имеет собственную архитектуру и свои особенности функционирования драйверов. Но практически во всех современных ОС можно выделить следующие особенности, характерные для работы подсистемы ввода-вывода... подробнее

Кол. просмотров: общее - 3020 сегодня - 0

Система ввода-вывода в Windows
17-05-2010   

На данный момент наиболее распространены два семейства ОС Windows: Windows NT, куда относятся Windows NT, 2000, XP, и Windows 9x (Win 95, 98, ME). При этом отмечается тенденция к отмиранию ветки 9х, хотя такие системы будут встречаться еще достаточно долго... подробнее

Кол. просмотров: общее - 3207 сегодня - 4



  WWW.COMPROG.RU - 2009-2012 | Designed and Powered by Zaipov Renat | Projects