ГЛАВА 8. ТЕХНОЛОГИИ ОБМЕНА ИНФОРМАЦИЕЙ В ОС WINDOWS 6 глава




 

WSAAsyncGetServByPort

 

WSAAsyncSelect

 

WSACancelAsyncRequest

 

WSACleanup

WSACloseEvent

WSAConnect

 

 

WSACreateEvent

WSADuplicateSocket

 

 

WSAEnumNameSpaceProviders

 

WSAEnumNetworkEvents

 

WSAEnumProtocols

 

WSAEventSelect

 

 

WSAGetLastError

 

 

WSAGetOverlappedResult

 

WSAGetQOSByName

 

 

WSAGetServiceClassInfo


 

 

Получает информацию о сервисе по заданному

номеру порта и протоколу

Просит Windows присылать сообщения о собы-

тиях, происходящих в указанном гнезде

Отменяет незавершенную асинхронную опера-

цию с гнездом

Завершает работу с библиотекой Winsock.DLL

Закрывает дескриптор объекта-события

Подключается к одноранговому узлу, осуществ-

ляет обмен данными о соединении и устанавли-

вает необходимое качество сервиса на основании

заданной спецификации потока

Создает новый объект-событие

Возвращает структуру WSAPROTOCOL_INFO,

которая может использоваться для создания де-

скриптора нового коллективного гнезда

Читает информацию о доступных провайдерах

пространства имен

Читает информацию о событиях, которые про-

изошли в заданном гнезде

Считывает информацию о доступных транспорт-

ных протоколах

Указывает объект-событие, который должен быть

связан с заданными сетевыми событиями

(FD_xxx)

Возвращает код ошибки последней некорректной

операции, выполненной в рамках интерфейса

Winsock

Возвращает результат асинхронной операции в

заданном гнезде

Инициализирует структуру QoS (Quality of Ser-

vice— качество сервиса) на основании именован-

ного шаблона

Запрашивает информацию о классе сервиса у за-

данного провайдера пространства имен


WSAGetServiceClassNameByClassId Возвращает обобщенное имя сервиса для задан-

ного типа сервисов


WSAHtonl

 

WSAHtons

 

WSAlnstallServiceClass

 

WSAloctl

 

 

WSAJoinLeaf


Преобразует длинное целое без знака из базового

формата в сетевой

Преобразует короткое целое без знака из базово-

го формата в сетевой

Регистрирует схему класса сервисов в простран-

стве имен

Задает режим работы указанного гнезда, а также

конфигурирует гнезда для осуществления безо-

пасной связи с помощью протокола SSL или РСТ

Окончание табл. 8.4

Подключается к концевому узлу в сеансе групповой свя-

зи, осуществляет обмен данными о соединении и устанав-

ливает необходимое качество сервиса на основе заданной

 



 

 

WSALookupServiceBegin

 

 

WSALookupServiceEnd

WSALookupServiceNext

 

WSANtohl

 

WSANtohs


 

 

спецификации потока

Возвращает дескриптор, который может использоваться в

последующих клиентских запросах для поиска нужной

информации о сервисе

Освобождает дескриптор, созданный функцией

Возвращает следующий набор информации о сервисе, ис-

пользуя заданный дескриптор

Преобразует длинное целое без знака из сетевого формата

в базовый

Преобразует короткое целое без знака из сетевого форма-

та в базовый


WSAProviderConfigChange Информирует приложение об изменении конфигурации

провайдера


WSARecv

WSARecvDisconnect

 

 

WSARecvEx

WSARecvFrom

WSARemoveServiceClass

WSAResetEvent

 

WSASend

 

WSASendDisconnect

 

WSASendTo

 

 

WSASetEvent

 

WSASetLastError

 

WSASetService

 

WSASocket

 

 

WSAStartup

 

WSAStringToAddress


Считывает данные из заданного гнезда

Прекращает прием данных из заданного гнезда, возвра-

щая данные о разрыве соединения, если таковые посту-

пают

Аналогична функции WSARecv

Считывает дейтаграмму и исходный адрес

Отменяет регистрацию схемы класса сервисов

Сбрасывает заданный объект-событие в несигнальное со-

стояние

Посылает данные в подключенное гнездо, разрешая вы-

полнение асинхронной операции ввода/вывода

Инициирует прекращение связи с заданным гнездом и пе-

редает данные о разрыве соединения

Отправляет данные по указанному адресу, в случае необ-

ходимости используя асинхронные операции вво-

да/вывода

Устанавливает заданный объект-событие в сигнальное

состояние

Устанавливает код ошибки, который возвращается при

последующих вызовах функции WSAGetLastError

Регистрирует или отменяет регистрацию экземпляра сер-

виса в пределах одного или нескольких пространств имен

Создает гнездо, связанное с указанным провайдером

транспортных услуг, создавая при необходимости группу

гнезд или подключаясь к уже существующей группе

Инициирует применение процессом библиотеки Win-

sock.DLL

Преобразует строку адреса в структуру адреса гнезда


WSAWaitForMultipleEvents Завершается, если один или все указанные объекты-

события переходят в сигнальное состояние или если за-

вершается период ожидания

 

§ 8.4.Обменинформациейпотехнологиидинамическогообменаданными

 

8.4.1. Общие положения

 

 



 

 

Технология динамическогообменаданными (Dynamic Data Exchange, DDE) обес-

печивает прямой обмен информацией между приложениями, установившими диалог, не

делая эти данные доступными для каких-либо других программ. Кроме того, в отличие

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

ресурс, между двумя или более DDE-при-ложениями может одновременно устанавли-

ваться несколько независимых друг от друга DDE-диалогов [6, 12].

Технология DDE не пригодна для распределенной обработки информации или для

интенсивного совместного использования данных в тех ситуациях, когда первоочеред-

ным, определяющим фактором является быстродействие. Основная черта DDE заключа-

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

предназначенные специально для этой цели. Приложения должны только распознавать

предлагаемые форматы данных и договориться друг с другом о способе передачи, о со-

вместимых темах, элементах и т.д.

DDEпредставляетсобой основанную на сообщениях систему обмена данными

между приложениями, которая аналогична системе внутренних сообщений Windows.

DDE-сообщения также управляются операционной системой.

С помощью DDE независимые программы могут обмениваться сообщениями и

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

приложениям, которые находятся в режиме прослушивания) или направляться непо-

средственно заданным приложениям.

Трафик DDE-сообщений представляет собой диалог между двумя (или нескольки-

ми) приложениями, предусматривающий наличие протоколов общения и определенной

избыточности информации, благодаря которой обеспечивается высокая степень надеж-

ности передачи данных.

DDE-приложения могут одновременно поддерживать диалог с несколькими про-

граммами или несколько диалогов с одной программой. В этом смысле DDE-диалог

можно сопоставить с сеансом одновременной игры в шахматы по переписке с одним или

несколькими противниками, когда даже посредственный игрок может поддерживать

сразу несколько "диалогов".

Проведение диалога невозможно без наличия у DDE-приложения трех основных

идентификаторов [12]:

Имя приложения или сервиса. Имя DDE-приложения подразумевает широкий диапа-

зон информации, которая может предоставляться сервером. Некоторые серверы могут вы-

давать только один тип информации, в то время как другие могут предоставлять данные

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

недоразумений в отношении операций с библиотекой DDEML (DDE Management Library)

вместо термина имяприложения применяется термин имясервиса.

Тема. Каждый DDE-диалог должен иметь, по крайней мере, одну тему (topic), хотя

один и тот же диалог может "переключаться" между несколькими темами, либо же не-

сколько диалогов могут использовать несколько тем. Если провести аналогию с разго-

вором между людьми, тема эквивалентна предмету беседы. При DDE-диалоге тема

может указываться и распознаваться обеими сторонами. Имя темы обычно совпадает с

именем файла.

Элемент. Имя элемента представляет собой идентификатор внутри темы, указываю-

щий конкретный элемент данных, который передается в результате текущей операции

обмена. Если участник диалога не распознает тему, обмен данными прерывается и диа-

лог нарушается, хотя и не прекращается полностью. Имя элемента может указывать на

страницу документа, строку, изображение, ячейку таблицы или любой другой фрагмент

данных, который обычно передается от одной программы к другой.

Пусть, например, электронная таблица поддерживает два типа сервисов: spreadsheet

(таблица) и chart (диаграмма). Каждый из этих сервисов в качестве темы может использо-

 

 


 

 

вать имена определенных файлов данных электронной таблицы. Элементами сервиса

spreadsheet могут быть ячейки электронной таблицы, а элементами сервиса chart - форма-

ты представления данных, такие как pie (круговая диаграмма) или bar (гистограмма).

Количество тем и элементов ограничивается лишь словарем, который совместно

используется всеми участниками сеанса. Элементы могут представлять собой как про-

стейшие типы данных, например целые числа, так и растровые изображения, метафайлы,

массивы или структурированные записи. В роли информационного элемента может так-

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

диалога.

Возможно ограничение числа сервисов на сервере до одного. В данном случае если

имена сервиса и сервера одинаковы, то клиент, который знает одно имя, автоматически

узнает и второе. Следовательно, он может инициировать диалог, используя заданное имя

ЕХЕ-файла.

Если сервер и сервис имеют разные имена или у сервера в наличии имеется не-

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

ния диалога нужна дополнительная информация. Альтернативным вариантом является

создание специального сервиса с каким-либо легко распознаваемым именем (например,

system), который просто сообщает приложениям-клиентам имена сервисов, доступных

на этом сервере.

Кроме того, если приложение-клиент знает и имя сервера (программы), и имя сер-

виса, оно может запустить сервер, например с помощью функции CreateProcess, и вос-

становить связи из предыдущего сеанса.

DDE-диалоги состоят из транзакций трех типов: подключения, принудительных

и командных [6, 12].

В транзакциях подключения, являющихся наиболее распространенными, клиент

запрашивает элемент данных, который находится на сервере. Различают три вида под-

ключения [12].

Снеобязательнымответом. Такой вид диалога инициируется приложением-

клиентом, посылающим широковещательный запрос WM_DDE_INITIATE, в котором

указывается вызываемое приложение и тип запрашиваемых данных (как первый, так и

второй параметры могут быть пустыми, если приемлемыми считаются любые сервер и

тема). В зависимости от обстоятельств на этот запрос может откликнуться один или не-

сколько серверов, идентифицируя себя для установления диалога. Если сервер не соот-

ветствует запрашиваемому имени или не распознает тему, он просто не откликается, по-

скольку приложение-клиент ожидает поступления только подтверждающих ответов.

После получения данных диалог немедленно завершается.

Сполуобязательнымответом. Такой вид диалога подразумевает, что клиент и сервер

"знают" друг друга и сервер имеет новую информацию, которая, как он полагает, заин-

тересует клиента. Обычно клиент посылает серверу сообщение WM_DDE_ADVISE, де-

лая запрос о необходимости обновить тему (и элемент). Сервер подтверждает получение

запроса, но посылает данные только при наличии новой информации.

Собязательнымответом. Такой вид диалога отличается от предыдущего тем, что

клиент ожидает от сервера подтверждения и немедленного ответа. Если информация в

данный момент отсутствует, сервер просто ответит клиенту, что данные недоступны, и

будет ожидать следующего запроса. Сервер не будет передавать информацию до тех

пор, пока не поступит запрос от клиента.

В процессе одного и того же диалога могут чередоваться подключения всех трех

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

ределить, где заканчивается один тип подключения и начинается другой.

Принудительные транзакции используются для передачи от клиента к серверу

элемента данных, который специально не запрашивался.

 

 


 

 

Командные транзакции позволяют клиенту посылать серверу команды или после-

довательности команд, заставляющих его выполнять определенные действия.

Обменданными начинается в тот момент, когда приложение-клиент инициирует

диалог и получает ответ от сервера. Установив соединение, клиент и сервер обменива-

ются данными вплоть до того момента, пока диалог не будет прерван по инициативе од-

ной из сторон. Обмен данными осуществляется одним или сразу несколькими из пере-

численных способов [6]:

• клиент запрашивает данные, а сервер отвечает на запрос;

• клиент просит проинформировать его, произошли ли изменения определенных дан-

ных;

• клиент просит автоматически передать определенные элементы данных в случае их

обновления;

• клиент посылает команду, а сервер ее выполняет;

• клиент посылает серверу незапрашиваемый элемент данных.

Важно помнить о том, что приложение-клиент может также выступать в роли сер-

вера и наоборот. Любое приложение может одновременно быть и сервером, и клиентом.

Различия между клиентом и сервером являются весьма искусственными и не вполне оп-

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

 

8.4.2. API-функции библиотеки DDEML

 

В своей основе DDE-диалог - это довольно сложный и запутанный процесс, вклю-

чающий многочисленные ответы и подтверждения с применением разных протоколов.

Поэтому, для облегчения жизни программистов, создана специальная библиотека -

DDEML (DDE Management Library).

DDEML входит в состав Windows и содержит высокоуровневые API-функции, по-

зволяющие упростить процесс DDE-диалога. Библиотека поддерживает запись о каж-

дом диалоге с помощью структуры CONVINFO, которая содержит информацию об уча-

стниках, установивших диалог, о запрашиваемых темах и элементах, об используемых

форматах и типах данных, а также о статусе диалога, ошибках и т.д. Следует отметить,

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

все обязанности по ведению записей на DDEML. Рассмотрим основные функции данной

библиотеки.

Функция DdeInitialize предназначена для задания функции обратного вызова,

управляющей графиком DDE-сообщений. Когда приложение вызывает функцию

DdeInitialize, DDEML уведомляет об этом другие программы, отправляя сообщение

XTYP_REGISTER их функциям обратного вызова. Эти сообщения используются мно-

гими клиентами для поддержки списка доступных сервисов.

Необходимость указывать идентификатор экземпляра приложения при вызове

функции DdeInitialize представляет собой дополнительное ограничение для программи-

стов, работающих в среде Windows, поскольку этот идентификатор является локальным

для потока и не наследуется дочерними процессами. А так как идентификатор экземпля-

ра необходимо задавать в качестве параметра большинства DDEML-операций, соответ-

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

ствлен вызов функции DdeInitialize. Поток, инициализировавший DDE-сеанс, не должен

прекращаться вплоть до его завершения; в противном случае вы не сможете вызвать

функцию DdeUninitialize, осуществляющую корректное завершение сеанса.

После инициализации сервер должен зарегистрировать имена предлагаемых серви-

сов. Для этой цели служит функция DdeNameService, которая вызывается с указанием

дескриптора строки, содержащей имя сервиса, и идентификатора экземпляра данного

 

 


 

сервиса. По идентификатору экземпляра DDEML узнает о том, какая процедура обрат-

ного вызова и какой поток поддерживают данный сервис.

 

HDDEDATA DdeNameService (DWORD dwInstID, // идентификатор экземпляра


HSZ hszl,

HSZ hszRes,

UINT uFlags);


// строка с именем сервиса

// зарезервирован

// флаги


 

Значение параметра dwInstID возвращается функцией DdeInitialize. Параметр

uFlags может содержать следующие флаги:

DNS_REGISTER - Регистрация имени сервиса.

DNS_UNREGISTER - Отмена регистрации имени сервиса. Если аргумент hszl имеет

значение NULL, происходит отмена регистрации всех сервисов данного сервера.

DNS_FILTERON - Предотвращает получение сервером сообщений XTYP_CONNECT

для незарегистрированных сервисов.

DNS_FILTEROFF - Позволяет серверу получать сообщения XTYP_CONNECT при вы-

зове любой DDE-программой функции DdeConnect.

Возвращаемый функцией DdeNameService результат в действительности представ-

ляет собой логическое значение, причем он соответствует ошибке, а ненулевое значение

- успешному выполнению функции. Но в настоящее время он имеет тип HDDEDATA,

что позволяет в будущем расширить диапазон значений этого индикатора.

Если приложение поддерживает более одного сервиса, каждый из них должен ре-

гистрироваться отдельно. Использование для каждого сервиса отдельного потока так-

же имеет ряд преимуществ (в частности, в этом случае обеспечивается неизменность

дескриптора экземпляра потока на протяжении всего времени существования данного

сервиса).

"Сердцем" любого DDEML-приложения является функция DdeCallback. Windows

передает ей восемь параметров вызова. Функция DdeCallback аналогична функции



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-02 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: