Winsock (для UNIX, Windows- и -NT)

7.1 Winsock (для UNIX, Windows-95 и -NT)

Семенов Ю.А. (ГНЦ ИТЭФ)

Какие бы замечательные идеи в области телекоммуникаций, распределенных баз знаний или поисковых систем вам не пришли в голову, реализовать их на практике можно, лишь написав соответствующую программу. Основные операционные среды (Unix, Windows 95, NT или 2000) базируются в настоящее время на идеологии соединителей (socket). Эта технология была разработана в университете г. Беркли (США) для системы Unix, поэтому соединители иногда называют соединителями Беркли (berkeley sockets). Соединители реализуют механизм взаимодействия не только партнеров по телекоммуникациям, но и процессов в ЭВМ вообще (см. [15]). Вопросы сетевого программирования под MS DOS рассмотрены в [24].

Работа с соединителями содержит ряд этапов: соединитель создается, настраивается на заданный режим работы, используется для организации обмена и, наконец, ликвидируется. Технология соединителей поддерживает работу с любыми стеками протоколов, совмещенные процедуры ввода/вывода, использование большого числа сервис-провайдеров (серверов услуг), возможность группирования соединителей, что позволяет реализовать их приоритетное обслуживание, и многое другое. Набор операторов, поддерживающих интерфейс сервис провайдера, образует отдельную динамическую библиотеку.

Для общей синхронизации работы сервис-провайдеров и приложений в winsock введено понятие объектов событий. Объекты событий служат в частности для организации работы совмещенных по времени процессов информационного обмена. Здесь уместно замечание об использовании стандартных номеров портов. В много задачных, многопользовательских системах стандартные номера портов используются при инициализации процесса. Так как допускается несколько идентичных соединений (например, несколько одновременных сессий FTP) между клиентом и сервером, стандартными номерами портов здесь не обойтись. Ведь psips сервера могут соотвествовать несколько pcipc клиента.

В системах, ориентированных на соединение, пара комбинаций IP-адресов и номеров портов однозначно определяет канал связи между двумя процессами в ЭВМ. Такая комбинация называется соединителем (socket). Номера портов могут и совпадать, так как относятся к разным машинам, но IP-адреса должны быть обязательно разными. Впервые идея соединителя была использована в системе 4.3 BSD Unix для организации сетевого ввода/вывода. В Unix внешнее устройство и файл с точки зрения системного программиста эквивалентны. Сетевые процедуры несколько сложнее и не укладываются в такую простую схему. Из этой простой схемы выпадают, прежде всего, операции, при которых сервер пассивно ожидает обращения особенно для операций обмена не ориентированных на соединение. Соединитель является пограничным понятием между протоколами телекоммуникаций и операционной системой ЭВМ. Соединители играют важную роль при написании прикладных программ (API).

Соединитель отправителя = IP-адрес отправителя + номер порта отправителя

Соединитель адресата = IP-адрес адресата + номер порта адресата

Межкомпьютерные коммуникации не сводятся к знакомству с соседским депозитарием, к выполнению операций Telnet, FTP и т.д. Одной из важнейших задач является удаленный контроль за процессами в больших рассредоточенных системах, когда обмен информацией активизируется не человеком, а ЭВМ. Примерами таких задач могут служить управление современными высокотехнологичными производствами, сбор метео- или другой геофизической информации в реальном масштабе времени, эксперименты в области физики высоких энергий, где для контроля установки и сбора экспериментальных данных используются десятки (а иногда и сотни) вычислительных машин, которые обмениваются диагностической информацией и данными. Именно для решения таких задач и применяются идеи соединителей (sockets), "труб" и т.д.. Понятие соединителя в прикладных программах это не просто комбинация IP-адресов и номеров портов, это указатель на структуру данных, где хранятся параметры виртуального канала. Прежде чем воспользоваться соединителем, его нужно сформировать. Оператор формирования соединителя имеет вид:

s=socket(INT AF, INT type, INT protocol);

где все параметры целочисленные, AF (address_family) - характеризует набор протоколов, соответствующий данному соединителю (это может быть набор Internet, Unix, Appletalk и т.д.). Для Интернет AF может принимать только значение PF_INET, для Unix - PF_UNIX. Аргумент type определяет тип коммуникаций (SOCK_STREAM, SOCK_RAW, и SOCK_DGRAM). Аргумент protocol задает код конкретного протокола из указанного набора (заданного AF), который будет реализован в данном соединении. Протоколы обозначаются символьными константами с префиксом IPPROTO_ (например, IPPROTO_TCP или IPPROTO_UDP). Допускается значение protocol=0 (протокол не указан), в этом случае используется значение по умолчанию для данного вида соединений. Значения AF и type можно обычно найти в файле <sys/socket.h>. Возвращаемый параметр S представляет собой дескриптор соединителя. Параметр SOCK_STREAM говорит о том, что вы намерены создать надежный двунаправленный канал обмена, ориентированный на соединение (TCP для Интернет). Связь c другим процессом в этом случае устанавливается оператором connect. После установления соединения данные могут посылаться оператором send или получаться посредством оператора recv. Параметр SOCK_DGRAM характеризует канал, не ориентированный на соединение, с пакетами фиксированного размера (например, UDP в случае AF= PF_INET). Такой канал позволяет использовать операторы sendto и recvfrom. Параметр SOCK_RAW определяет третий режим, при котором возможно использование протоколов нижнего уровня, например ICMP. Таким образом, формирование соединителя - это создание описывающей его структуры данных.



Если операция socket завершилась успешно, s равно дескриптору соединителя, в противном случае s=INVALID_SOCKET (-1). С помощью оператора WSAGetLastError можно получить код ошибки, проясняющий причину отрицательного результата.

Дескриптор соединителя указывает на элемент таблицы дескрипторов, соответствующий данному соединителю. Оператор socket отводит место в этой таблице. Элемент такой таблицы имеет вид:

Код семейства протоколов;

Код типа сервиса;

Локальный IP-адрес;

Удаленный ipIPадрес;

Номер локального порта;

Номер удаленного порта;

IP-адрес определяет интерфейс ЭВМ, а номер порта в данном случае характеризуют сетевую процедуру.

Так как в Unix возможно формирование соединителя без IP-адресов, а для практической работы они нужны, имеется оператор bind, который позволяет присвоить определенный адрес заданному соединителю:

r=bind(s, const struct socketaddr far*name, int namelen),

где s - целочисленный код дескриптора, параметр name (идентификатор локального адреса) обычно (для Интернет) содержит три величины: IP-адрес ЭВМ, код протокольного набора, номер порта, который определяет характер приложения. Структура адресной информации имеет вид:

struct sockaddr {

u_short sa_family;

char sa_data[14];

};

Параметр namlen определяет длину второго параметра. В рамках этой идеологии легко реализовать систему клиент-сервер. IP-адрес может быть сделан равным INADDR_ANY (или =0), если ЭВМ имеет несколько интерфейсов. При номере порта равным нулю, windows socket присвоит порту уникальный номер в диапазоне 1024-5000. Приложение может выполнить операцию getsockname после bind, чтобы определить присвоенный адрес. Оператор bind выполняется до операций connect или listen. При корректном выполнении оператор bind возвращает код 0 (r=0), в противном случае SOCKET_ERROR=-1. Команда bind выдается для записи собственного номера порта. Сервер генерирует команду bind, чтобы подготовить определенный вид связи (например, FTP), и пассивно ожидает запроса connect со стороны клиента:



R=connect(s, const struct socketaddr FAR*name, int namelen),

где s - дескриптор соединителя, name - идентификатор адреса места назначения (указатель на структуру данных), а namelen - длина этого адреса. Таким образом, оператор connect сообщает ip-адрес и номер порта удаленной ЭВМ. Если адресное поле структуры name содержит нули, оператор connect вернет ошибку WSAEADDRNOTAVAIL (или SOCKET_ERROR=-1). Установка в режим ожидания осуществляется командой listen, которая организует очередь запросов:

R=listen(s, int backlog),

где backlog - задает максимальный размер очереди для приходящих запросов соединения (то есть сколько запросов может быть принято на обслуживание без потерь, обычно этот параметр равен 5). При переполнении очереди будет послано сообщение об ошибке. Следует иметь в виду, что клиент, ориентированный на соединение, также должен прослушивать порт протокола, ожидая появления дейтограмм-откликов. Ожидающий соединитель посылает каждому отправителю сообщение-отклик, подтверждающее получение запроса на соединение. Оператор listen подготавливает соединитель к обработке потока запросов, система должна быть достаточно быстродействующей. Запросы из очереди извлекаются оператором accept:

R=accept(s, struct sockaddr FAR*addr, int FAR*addrlen),

где s - дескриптор соединителя, который прослушивает соединение (тот же, что и в listen), addr - опционный указатель на структуру, которая содержит адрес, addrlen - код длины адреса. Оператор accept позволяет серверу принять запрос от клиента. Когда входная очередь сформирована, программа реализует процедуру accept и переходит в режим ожидания запросов. Программа извлекает первый элемент очереди, создает новый соединитель со свойствами, идентичными s, и при успешном выполнении возвращает дескриптор нового соединителя. При возникновении ошибки возвращается код INVALID_SOCKET. По окончании обработки запроса сервер вновь вызывает accept, который возвращает ему дескриптор соединителя очередного запроса, если таковой имеется. Если очередь пуста, accept блокирует программу до получения связи. Существуют серверы с параллельной и последовательной обработкой запросов. Параллельный обработчик запросов не ждет завершения обработки предшествующего запроса и вызывает оператор accept немедленно. В системе Unix используются обычно параллельные обработчики запросов.



Схема взаимодействия различных операторов winsock в рамках идеологии клиент/сервер для случая процедур, ориентированных на соединение, показана на рисунке 7.1. Стрелками обозначены направления посылки сетевых сообщений.

Следует иметь в виду, что программе клиента (выделена рамкой) не нужно знать номер порта, по этой причине она не обращается к процедуре bind, а для установления связи сразу вызывает оператор connect. Современные распределенные информационные системы, WWW-серверы, поисковые системы и т.д. эффективно используют механизмы формирования соединителей и многие процедуры, описанные в данном разделе. Из литературы [24] известно, что для многих видов услуг в Интернет выделены строго определенные номера портов. Доступ же к этим услугам должен быть обеспечен достаточно большому числу пользователей. С клиентской стороны при этом используются номера портов со значениями из диапазона 1024-5000. Для каждого нового клиентского запроса в ЭВМ-сервере, как правило, открывается новый процесс.



Рис. 7.1.Схема взаимодействия операторов winsock для процедур, ориентированных на соединение

Лишь при успешной реализации всех перечисленных операций может начаться обмен данными. Для пересылки данных могут использоваться команды write, read, send, recv. Команды write и read имеют форму вызова:

R=write(s, buf, len) или R=read(s, buf, len),

где s - дескриптор соединителя, buf - имя массива, подлежащего пересылке (или предназначенного для приема), len - длина этого массива. Оператор writev отличается от write тем, что данные могут не лежать в виде непрерывного массива:

R=writev(s, io_vect, vectlen) или R=readv(s, io_vect, vectlen),

где s - дескриптор соединителя, io_vect - вектор-указатель на список указателей, vectlen - длина списка указателей. Команда выполняется медленнее, чем write или read. Список указателей имеет формат (рис. 7.2):



Рис. 7.2 Формат списка указателей для функций readv и writev

Команды send(s, msg_buf, buflen, flags) и recv имеют аналогичный формат, но среди параметров обращения содержат переменную flags, которая служит для целей диагностики и управления передачей данных (например, пересылка информации с высоким приоритетом (MSG_OOB - Message Out Of Band), что используется, в частности, при передаче звуковых сообщений). При работе с операторами send или recv надо быть уверенным, что принимающая сторона знает, что ей следует делать с этими приоритетными сообщениями. Другой возможный флаг, определяемый константой MSG_PEEK, позволяет анализировать запросы из входной очереди транспортного уровня. Обычно после считывания данных из входной очереди, они уничтожаются. Когда MSG_PEEK=1, данные из входной очереди не стираются. Этот флаг используется, например, программой FTP. При успешном выполнении команды будет возвращено число переданных байтов, в противном случае -1.



Все перечисленные выше операторы рассчитаны на использование в рамках протоколов, ориентированных на установление соединения (TCP), где не требуется указание адреса места назначения. В протоколах типа UDP (не ориентированных на соединение) для передачи информации используются операторы sendto, recvfrom или sendmsg:



R=sendto

(s, msg_buf, buflen, flags, adr_struc, adr_struc_len)

или recvfrom(s, msg_buf, buflen, flags, adr_struc, adr_struc_len),

где s - дескриптор соединителя, msg_buf - указатель на буфер, где лежит сообщение, buflen - длина этого буфера (длина сообщения), adr_struc - адресная структура, содержащая исчерпывающую информацию об адресате, adr_struc_len - длина этой структуры. Оператор recvfrom принимает все данные, приходящие на его порт. Приняв дейтограмму, recvfrom записывает также адрес, откуда эта дейтограмма получена. Сервер может посылать по этому адресу дейтограмму-отклик. Вызов оператора sendmsg имеет форму:

R=sendmsg(s, msg_struc, flags) [или recvmsg(s, msg_struc, flags)],

где s - дескриптор соединителя, msg_struc - информационная структура, формат которой показан ниже на рисунке 7.3. Применение структур делает программирование пересылки сообщений более гибким. Следует учитывать, что для обменов, не ориентированных на соединение, соединитель как бы состоит лишь из одной половины (IP-адрес и номер порта). “Соединители”, созданные для обмена (UDP) однажды, далее могут жить своей жизнью. Они могут принимать пакеты от других аналогичных “соединителей” и сами посылать им дейтограммы (кавычки здесь связаны с тем, что это не реальный соединитель и никакого соединения здесь не осуществляется).



Рис. 7.3. Формат информационной структуры msg_struc

Взаимодействие операторов winsock для систем, не ориентированных на соединение, показано на рисунке 7.4. Здесь также как и в случае, ориентированном на соединение, сервер вызывает socket и bind, после чего обращается к процедуре recvfrom (вместо read или recv). Программа-клиент в данной схеме обращается к оператору bind и совсем не использует оператор connect (ведь предварительного соединения не нужно). Для передачи запросов и приема откликов здесь служат операторы sendto и recvfrom, соответственно.





Рис. 7.4. Схема взаимодействия операторов winsock для процедур, не ориентированных на соединение

Помимо уже описанных операторов для работы с соединителями (sockets) имеется еще один - select, довольно часто используемый серверами. Оператор select позволяет процессу отслеживать состояние одного или нескольких соединителей. Для каждого соединителя вызывающая программа может запросить информацию о статусе read, write или error. Форма обращения имеет вид:

R=select(num_of_socks, read_socks, write_socks, error_socks, max_time),

где num_of_socks - число контролируемых соединителей (в некоторых реализациях не используется и является необязательным, по умолчанию это число не должно превышать 64). В версии Беркли read_socks, write_socks и error_socks представляют собой побитовые маски, определяющие тип соединителя. Параметр read_socks представляет собой указатель на структуру, описывающую набор соединителей, состояние которых контролируется на возможность чтения (версия winsock). Если соединитель находится в состоянии listen, он будет помечен как “готов для чтения”, при условии, что запрос на соединение уже получен. Это предполагает выполнение оператора accept без блокировки. Для других соединителей “готовность к чтению” подразумевает наличие в очереди запросов чтения. Для соединителей типа SOCK_STREAM это означает, что виртуальный соединитель, соответствующий данному соединителю закрылся, и операторы recv или recvfrom будут выполнены без блокировки. Если виртуальное соединение закрыто корректно, оператор recv вернет код 0, в противном случае (например, принудительное закрытие) будет возвращен код WSAECONNRESET. Параметр write_socks - указатель на набор соединителей, состояние которых контролируется на возможность записи. Если соединитель находится в процессе выполнения процедуры connect, “способность к записи” означает, что установление связи завершено. Для других соединителей это значит, что операции send или sendto будут выполнены без блокировки. Параметр error_socks - это указатель на набор соединителей, контролируемых на ошибки. В некоторых реализациях этот аргумент идентифицирует список соединителей, помеченных как приоритетные. Соединитель помечается как приоритетный, если опция SO_OOBINLINE=FALSE. На случай ошибки оператор select отмечает соединитель, где это произошло. select работает лишь с теми соединителями, которые были выделены с помощью масок. При успешном выполнении оператор возвращает число соединителей, готовых к операциям ввода/вывода и модифицирует коды масок в соответствии с состоянием соединителей. Прикладная программа может использовать результаты вызова оператора select, анализируя полученные коды масок. Аргумент max_time определяет максимальное время, выделенное select для завершения своей работы. Для уточнения типа ошибки, возникшей при исполнении операции select, можно воспользоваться процедурой WSAGetLastError.



Другим важным оператором является closesocket(s), который закрывает канал соединителя с одной из сторон. Все описанные выше операторы (кроме socket, bind и listen) блокируют работу программы до своего завершения. Практически любая операция, непосредственно связанная с выполнением процедур ввода/вывода, может блокировать выполнение других прикладных функций winsock.

Для обслуживания прикладных процессов (например, WWW-сервера, работа с распределенными базами данных и пр.) разработано много других сервисных программ (WINSOCK.DLL), перечень которых представлен в таблице 7.1.

Таблица 7.1. Перечень служебных операторов для работы с соединителями (Беркли)



Имя команды



Назначение

getdomainname Возвращает имя домена gethostbyname Возвращает IP-адрес для заданного сетевого имени. gethostname Возвращает имя ЭВМ (обычно имя ее домена). gethostadr Возвращает IP-адрес ЭВМ. getnetaddr Возвращает адрес сети. getnetname Возвращает имя сети. getpeername Возвращает имя партнера, подключенного к соединителю. getportbyname Возвращает имя и код протокола для указанного имени (например, ICMP, UDP или TCP) getportbynumber Возвращает имя протокола для указанного его кода getservbyname Извлекает из базы данных название протокола и номер порта для указанного имени сетевой услуги getservbyport Возвращает имя сетевой услуги для заданного номера порта getsockname Возвращает местный адрес соединителя. getsockopt Запрашивает информацию о соединителе. htonl Преобразует порядок байтов 32-разрядного кода из машинного в сетевой. htons Преобразует порядок байтов 16-разрядного кода из машинного в сетевой. inet_addr Преобразует символьную строку IP-адреса из десятично-точечного формата в 32-разрядный код с сетевым порядком байтов. inet_ntoa Преобразует IP-адрес в десятично-точечный формат. ioctlsocket Управляет параметрами соединителя, связанными с обработкой операций ввода/вывода. ntohl Преобразует порядок байтов 32-разрядного кода из сетевого в машинный.

ntohs Преобразует порядок байтов 16-разрядных кодов из сетевого в машинный. ethostname Устанавливает имя ЭВМ. setsockopt Устанавливает опции соединителя. shutdown Закрывает один из концов дуплексного канала для местной ЭВМ. socketpair Генерирует пару соединителей. Большинство перечисленных команд имеют развитую систему диагностики, кроме того, во многих реализациях Unix имеется много других полезных команд, описание которых вы можете найти в инструкциях по использованию системы Unix. Рассмотрим некоторые из них.

Программа ioctlsocket(s, long cmd, u_long FAR*argp) служит для получения параметров соединителя (выполнение не зависит от типа протокола и коммуникационной субсистемы). Аргумент cmd представляет собой код команды, которая будет выполнена для соединителя s, argp - указатель на параметр команды. Возможно применение команд: FIONBIO - разрешает/запрещает режим блокировки соединителя s (команда WSAAsyncSelect ставит соединитель в режим запрета блокировок автоматически). FIONREAD - определяет объем данных, которые могут быть автоматически считаны через соединитель s. SIOCATMARK - задает режим чтения приоритетной информации (для соединителей типа SOCK_STREAM.

Программа setsockopt(s, int level, int optname, const char far*optval, int optlen) устанавливает текущие значения опций для соединителя s. Аргумент level описывает уровень, на котором определена данная опция (например, SOL_SOCKET или IPPROTO_TCP). optname - имя опции, значение которой устанавливается, optval - указатель на буфер, где лежит значение опции, optlen - размер этого буфера. Для опции SO_LINGER - это размер структуры, для остальных - длина целого. При корректном исполнении setsockopt возвращает нуль, в противном случае SOCKET_ERROR. Программа setsockopt поддерживает следующие опции (BSD поддерживает и некоторые другие опции; колонка тип соответствует значению optval, таблица 7.2):

Таблица 7.2. Опции соединителей для оператора setsockopt.

Опция	Тип	Назначение
SO_BROADCAST	булев	Позволяет передачу широковещательных сообщений
SO_DEBUG	булев	Осуществляет запись отладочных данных.
SO_DONTLINGER	булев	Разрешает закрытие без ожидания при наличии не отосланной информации. Эта опция эквивалентна SO_LINGER с l_onoff=0.
SO_DONTROUTE	булев	Запрет маршрутизации - отправка непосредственно интерфейсу.
SO_KEEPALIVE	булев	Посылка сообщения keepalive (“еще жив”)
SO_LINGER	структура	Задержка закрытия в случае наличия не отосланной информации.
SO_OOBINLINE	булев	Принимает информацию, приходящуюю по независимым каналам, в общем потоке данных
SO_RCVBUF	целый	Определяет размер входного буфера
SO_REUSEADDR	булев	Позволяет соединителю использовать адрес, который уже задействован
SO_SNDBUF	целый	Определяет размер выходного буфера
TCP_NODELAY	булев	Запрещает использование алгоритма Нагля (TCP).

<


/p> Программа getsockopt(s, int level, int optname, char far*optval, int FAR* optlen) позволяет получить значение опции для любого типа соединителей. Значения параметров обращения аналогичны setsockopt. Ниже представлена таблица (7.3) поддерживаемых опций.

В среде Windows существуют аналоги (асинхронные) многих из приведенных выше операторов. Имена этих операторов имеют префикс WSA (Windows Socket Asynchronous). Асинхронными они названы по той причине, что их выполнение сопряжено с определенным диалогом и ни начало, ни завершение не ограничено какими-либо временными рамками. Список таких операторов представлен в таблицах 7.4 и 7.5 (версия windows socket 2.2).

Таблица 7.3. Опции соединителей для оператора getsockopt

Опция	Тип	Назначение
SO_ACCEPTCONN	булев	Соединитель в режиме listen
SO_BROADCAST	булев	Разрешена передача широковещательных сообщений
SO_DEBUG	булев	Отладочный режим разрешен
SO_DONTLINGER	булев	Если равен TRUE, SO_LINGER-опция запрещена
SO_DONTROUTE	булев	Запрет маршрутизации.
SO_ERROR	целое	Выдает статус ошибок
SO_KEEPALIVE	булев	Сообщение keepalive (“еще жив”) послано
SO_LINGER	структура	Возвращает текущие значения опции SO_LINGER
SO_OOBINLINE	булев	Принимает информацию, приходящуюю по независимым каналам, в общем потоке данных
SO_RCVBUF	целый	Сообщает размер входного буфера
SO_REUSEADDR	булев	Соединителю разрешено использовать адрес, который уже задействован
SO_SNDBUF	целый	Сообщает размер выходного буфера
SO_TYPE	целый	Тип соединителя (например, SOCK_STREAM)
TCP_NODELAY	булев	Использование алгоритма Нагля запрещено (tcp).

Таблица 7.4. Основные операторы winsock

Имя оператора	Назначение
WSAAsyncGetHostByAddr	Аналог оператора gethostbyaddr
WSAAsyncGetHostByAddr	Аналог оператора gethostbyaddr
WSAAsyncGetHostByName	Аналог оператора gethostbyname
WSAAsyncGetProtoByName	Аналог оператора getprotobyname
WSAAsyncGetProtoByNumber	Аналог оператора getprotobynumber
WSAAsyncGetServByName	Аналог оператора getservbyname
WSAAsyncGetServByPort	Аналог оператора getservbyport
WSAAsyncSelect	Функциональный аналог оператора select
WSACancelAsyncRequest	Прерывает выполнение операторов типа WSAAsyncget*by*
WSACancelBlockingCall	Прерывает выполнение блокирующего оператора приложения (API)
WSACleanup	Сообщает Windows sockets о завершении работы программы с DLL
WSAGetLastError	Выдает сообщение о последней ошибке
WSAIsBlocking	Определяет, является ли Winsock DLL блокирующей
WSASetBlockingHook	Устанавливает перехват блокирующего вызова
WSASet LastError	Фиксирует тип ошибки для последующего вызова WSALastError
WSAStartup	Инициализирует следующий уровень Winsock
WSAUNhookBlockingHook	Восстанавливает прежнюю блокировку.

<


/p> Из этого списка можно выделить две программы WSAStartup и WSACleanup, первая вызывается в начале любой процедуры, вторая - ее завершает. wsastartup может вызываться за время сессии несколько раз, она позволяет указать версию winsock или получить информацию об ее конкретной реализации. При вызове WSAStartup осуществляется диалог с динамической библиотекой WINSOCK.DLL и настройка параметров системы. При аварийном завершении программы нужно корректно окончить работу с WINSOCK.DLL. Следует при этом помнить, что WSACleanup воздействует на все потоки завершаемого процесса (например, в случае Windows 95 или NS). Определенные проблемы может вызвать перенос программ из Unix в Windows, так как там вместо read и write используются операторы recv и send, вместо ioctl - ioctlsocket, а вместо close - closesocket. Некоторые операторы вообще непереносимы: readv, writv, recvmsg и sendmsg и части программы, где они содержатся, необходимо переписать. При обнаружении ошибки Unix присваивает переменной errno соответствующее значение. В winsock для этой цели используется символьная константа SOCKET_ERROR (равная -1), а для уточнения типа ошибки следует вызвать WSAGetLastError. В системах Windows 95 или NT этот оператор обращается к программе Win32 GetLastError, которая возвращает значение ошибки для сессии, вызвавшей эту ошибку.

Таблица 7.5. Асинхронные операторы

WSAAccept *	Расширенная версия accept, которая позволяет условное подключение и формирование групп соединителей.
WSACloseEvent	Уничтожает объект события.
WSAConnect *	Расширенная версия connect, которая позволяет обмениваться данными о соединении и QoS-информацией.
WSACreateEvent	Создает объект события.
WSADuplicateSocket	Создает новый дескриптор соединителя для случая использования его несколькими процессами.
WSAEnumNetworkEvents	Выявляет сетевые события.
WSAEnumProtocols	Выдает информацию о каждом доступном протоколе.
WSAEventSelect	Связывает сетевое событие с объектом события.
WSAGetOverlappedResult	Сообщает состояние выполнения совместной операции обмена.
WSAGetQOSByName	Выдает параметры qos для заданного имени сетевой услуги.
WSAHtonl	Расширенная версия htonl
WSAHtons	Расширенная версия htons
WSAIoctl *	Версия ioctlsocket, пригодная для совмещения процедур ввода/вывода
WSAJoinLeaf *	Подключает периферийный узел к многоточечной сессии.
WSANtohl	Расширенная версия ntohl
WSANtohs	Расширенная версия ntohs
WSARecv *	Расширенная версия recv, которая позволяет совмещать по времени операции ввода/вывода, использовать многобуферную схему при работе с векторами указателей и получать флаги в качестве входных и выходных параметров.
WSARecvDisconnect	Завершает работу соединителя и выдает информацию о завершении, если соединитель был ориентирован на работу в связанном состоянии.
WSARecvFrom *	Расширенная версия recvfrom, которая позволяет совмещать по времени операции ввода/вывода, использовать многобуферную схему при работе с векторами указателей и получать флаги в качестве входных и выходных параметров
WSAResetEvent	Обнуляет объект события.
WSASend *	Расширенная версия send, которая позволяет совмещать по времени операции ввода/вывода, использовать многобуферную схему при работе с векторами указателей.
WSASendDisconnect	Инициализирует процедуру закрытия соединения и опционно посылает сообщение disconnect.
WSASendTo *	Расширенная версия sendto, которая позволяет совмещать по времени операции ввода/вывода, использовать многобуферную схему при работе с векторами указателей.
WSASetEvent	Устанавливает объект события.
WSASocket	Расширенная версия socket, которая использует структуру WSAPROTOCOL_INFO в качестве входной информации и позволяет создать соединители, работающие одновременно. Позволяет также формировать группы соединителей.
WSAWaitForMultipleEvents	Присылается, если любой или все специфицированные объекты находятся в сигнальном состоянии или когда истекает время таймаута.

<


/p> * Программа может вызвать блокировку при работе с блокирующим соединителем.

При написании программ на персональной ЭВМ, например, на С++ или ассемблере существует возможность выбора модели памяти: small, medium, compact, large или huge. Эти модели отличаются друг от друга числом сегментов (по 64 Кбайт) памяти, выделяемой для программы и данных. Модель small предполагает, что все указатели имеют тип near, если явно не указано обратное (не записан модификатор FAR). Модель large считает по умолчанию все указатели дальними, если явно не присутствует модификатор near. В модели huge длина блока данных может превышать размер одного сегмента. С особенностями этих моделей рекомендуется ознакомиться по описаниям конкретных трансляторов. Используя те или иные модели при создании сетевых программ, нужно учитывать проблемы, которые могут возникнуть при переносе вашей программы из одной операционной среды в другую. ОС Unix, Windows NT и Windows 97 не поддерживают каких-либо моделей памяти и их система адресации скорее совместима с моделью large. Но при переносе программы из одной среды в другую об этой проблеме лучше не забывать и перед началом отладки полезно изучить особенности адресации.

При программировании под Windows 3.1 нужно учитывать то, что для доступа к процессору (ЦПУ) необходимо, чтобы программа, захватившая его раньше, прекратила свою работу и освободила ЦПУ. Этого не требуется в среде Unix, Windows 95 или Windows NT. Различие этих операционных сред особенно заметно при выполнении блокирующих процедур, рассмотренных выше, например операции сетевого ввода/вывода. Блокирующие процедуры являются потенциальным источником “повисания” программ, например, оператор recv может вечно ждать отклика, в то время как удаленный сервер будет ждать сообщения от программы, выполняющей recv. По этой причине создание не блокирующих соединителей представляется привлекательным. Такие соединители формируются путем вызова стандартного оператора socket с последующим обращением к процедуре, изменяющей режим работы соединителя (по умолчанию создается блокирующий соединитель). После этого при вызове блокирующего оператора, например, recv при условии, что соединитель не имеет запрашиваемых данных, система возвратит флаг ошибки. Таким образом, при работе с неблокирующим соединителем, операционная система проверяет возможность немедленного выполнения процедуры, и возвращает сигнал ошибки, если это не возможно. Все операторы winsock являются асинхронными и неблокирующими. Асинхронные операции при невозможности выполнить требуемую операцию не выдают сообщения об ошибке, за тем, чтобы процедура была выполнена так как нужно, в этом случае следит операционная система. По завершении асинхронной операции ОС Windows посылает сообщение тому окну, из которого эта операция была вызвана. Но и операторы, работающие с неблокирующими соединителями Беркли, также являются неблокирующими. В то же время все операции ввода и вывода в Unix являются синхронными.



Хотя оператор WSAAsyncSelect считается аналогом select, между ними имеется существенное отличие. WSAAsyncSelect - единственный оператор, использующий дескриптор соединителя в качестве параметра. Если select контролирует состояние нескольких соединителей, для того чтобы достичь того же результата с помощью wsaasyncselect надо реализовать столько вызовов, сколько соединителей мы хотим мониторировать. Форма обращения к WSAAsyncSelect имеет вид:



WSAAsyncSelect

(SOCKETs, HWND hWnd, unsigned int wMsg, long lEvent),

где s - дескриптор соединителя, состояние которого мы хотим контролировать, аргумент, hWnd - дескриптор окна-получателя сообщения; wMsg - определяет тип посылаемого сообщения (эти два параметра являются стандартными для всех функций Windows); lEvent - битовая маска, определяющая тип событий, которые нас интересуют. Возможные значения параметра lEvent приведены в таблице 7.6.



Таблица

7.6. Возможные значения параметра lEvent оператора WSAAsyncSelect

Значение	Назначение
FD_READ	Готовность к чтению
FD_WRITE	Готовность к записи
FD_OOB	Поступление Out_Of_Band данных
SD_ACCEPT	Контроль установки входного соединения
FD_CONNECT	Контроль реализованных соединений
FD_CLOSE	Контроль закрытия соединения

При необходимости контроля комбинации вышеперечисленных состояний эти маски могут объединяться по ИЛИ. Как только состояние соединителя станет соответствовать выбранной маске, Windows пошлет прикладной программе соответствующее сообщение. Это сообщение содержит дескриптор окна, откуда осуществлен вызов процедуры WSAAsyncSelect, идентификатор сообщения, а также 16-битовый и 32- битовый параметры этого сообщения. Первый из них представляет собой дескриптор соединителя, где это событие произошло. Младшие 16 бит второго параметра являются кодом события, а старшие предназначены для записи кода ошибок, если они произошли.

Как уже было отмечено, обращение к WSAAsyncSelect переводит соединитель в неблокирующее состояние. При необходимости реализовать, например, процедуру recv, следует обратиться с начала к WSAAsyncSelect, запросив Windows информировать вас о готовности чтения (lEvent=FD_READ). После этого обработчик сообщений windows при получении соответствующего сигнала предоставит возможность прикладной программе перейти к выполнению операции recv. Так как соединитель уже получил данные, блокировки не произойдет и программа их немедленно получит.



Особое внимание блокирующим операциям должно быть уделено в Windows 3.1, поскольку блокировка остановит не только выполнение задачи, вызвавшей эту операцию, но и все другие приложения (ЭВМ станет неуправляемой на время блокировки). Здесь блокирующие процедуры должны быть запрещены, вместо этого при необходимости вызова такой процедуры windows реализует цикл по проверке состояния соединителя (очереди сообщений). Остальные приложения могут при этом продолжить свою работу, а при получении благоприятного сообщения Windows разрешает выполнение блокирующей процедуры, так как она уже не может вызвать блокировки. Осложнения могли бы возникнуть, если обработчик сообщений Windows получит сигнал, который приведет к вызову другой блокирующей процедуры. Сегодня в Windows действует правило, запрещающее такие вызовы из прикладных программ как блокирующие, так и неблокирующие. То есть, на время выполнения блокирующей процедуры все обращения к сетевому интерфейсу запрещены.

Имеется несколько операторов Winsock, предназначенных для работы с блокирующими процедурами (смотри таблицу 7.7):

Таблица 7.7.

WSACancelBlockingCall	прерывание блокирующей процедуры (без аргументов);
WSAIsBlocking	определение блокирующей операции (без аргументов);
WSASetBlockingHook	перехват блокирующего вызова, организация цикла ожидания;
WSAUNhookBlockingHook	восстановление прежней блокировки.

При необходимости прервать блокирующую операцию можно вызвать процедуру WSACancelBlockingCall, прикладная программа получит при этом сообщение об ошибке (WSAEINTR). Оператор WSAIsBlocking возвращает значение TRUE, если в данный момент реализуется блокирующая операция. Последние два оператора из четырех названных служат для построения пользовательских обработчиков сообщений.

Аппарат соединителей предполагает возникновение и исчезновение вычислительных и управляющих процессов. Новый процесс может наследовать "старые" соединители. В этом случае может возникнуть необходимость выяснить, адрес партнера, с которым взаимодействует данный соединитель. Эту задачу можно решить с помощью команды getpeername(s, destaddr, addrlen), где destaddr - указатель на структуру типа (рис. 7.5):





Рис. 7.5. Указатель на структуру типа для команды getpeername



AF

- идентифицирует семейство протоколов (для TCP/IP=2), для которого порожден данный соединитель, вся структура занимает 16 октетов. addrlen - указатель на переменную, куда будет записана длина адреса. Соединитель может быть выключен командой close(s), где s идентификатор соединителя, который надлежит закрыть. Если пользователь не хочет более посылать или получать данные, он может выдать команду shutdown(s, how), где параметр how может принимать значения: 0 - блокируется прием данных; 1 - блокируется передача данных; 3 - блокируются любые обмены.

Каждое соединение должно иметь свой неповторимый код ISN (Initial Sequence Number). Этот код посылается клиентом серверу с помощью сегмента SYN. Для реализации режима соединения прикладная программа на одном конце канала устанавливается в режим пассивного доступа ("passive open"), а операционная система на другом конце ставится в режим активного доступа ("active open"). Протокол TCP предполагает реализацию 11 состояний (ESTABLISHED, CLOSED, LISTEN, SYN_SENT, SYN_RCVD и т.д.), переход между которыми строго регламентирован (смотри раздел 4.4.3).

При написании диагностических и управляющих программ под Windows 95 или NT можно использовать простые соединители (Sock_Raw) или библиотеку ICMP.DLL (эта динамическая библиотека не является частью Win32 API). Библиотека ICMP.DLL содержит в частности процедуру ICMPSendEcho, которая посылает запросы эхо по указанному адресу и возвращает отклик в пределах указанного временного интервала. В качестве аргументов запрос ICMPSendEcho использует ICMP-дескриптор, который получается в результате запроса IcmpCreateFile.

HANDLE WINAPI IcmpCreateFile(VOID);

/* Оператор создает ICMP-дескриптор; при ошибке возвращает INVALID_HANDLE_VALUE */

BOOL WINAPI IcmpCloseHandle(HANDLE IcmpHandle);

/* Оператор ликвидирует ICMP-дескриптор; при возникновении ошибки возвращает значение FALSE */

Обращение к процедуре посылки ICMP запроса эхо имеет формат:



DWORD WINAPI IcmpSendEcho(

HANDLE IcmpHandle,

/* дескриптор, полученный в результате запроса IcmpCreateFile */ u_long DestAddress,

/* IP адрес точки зондирования */

LPVOID RequestData,

/* указатель на буфер, где лежат данные, подлежащие посылке */ WORD RequestSize,

/* длина этого буфера */

LPIPINFO RequestOptns,

/* указатель на структуру ICMP-опций */

LPVOID ReplyBuffer,

/* указатель на буфер для приема пакета-отклика */ DWORD ReplySize,

/* размер буфера для пакета-отклика */

DWORD Timeout

/* время ожидания отклика в миллисекундах */

); struct icmp_echo_reply {

/* Структура ICMP-отклика */

u_long Address;

/* адрес отправителя */

u_long Status;

/* код IP-статуса */

u_long RTTime;

/* RTT в миллисекундах */

u_short DataSize;

/* длина пакета-отклика */

u_short Reserved;

/* зарезервировано на будущее */

void FAR *Data;

/* буфер отклика */

struct ip_option_information Options;

/* опции отклика */

}; ICMPECHO, *PICMPECHO, FAR *LPICMPECHO; struct ip_option_information {

/* Структура опций протокола ICMP */

u_char TTL;

/* Time To Live (используется процедурой traceroute) */

u_char Tos;

/* Type Of Service (тип сервиса; обычно 0) */

u_char Flags;

/* Флаги IP-заголовка (обычно 0) */

u_char OptionsSize;

/* Размер буфера опций (обычно 0, max=40) */

u_char FAR *OptionsData;

/* Буфер опций */

} IPINFO, *PIPINFO, FAR *LPIPINFO;

Приложение может использовать WSAEnumProtocols для определения того, какой транспортный протокол (стек протоколов) поддерживается, и попутно можно получить дополнительную информацию, которая содержится в структуре WSAPROTOCOL_INFO.

В то время как в WinSock 1.1 имеется только одно семейство адресов AF_INET, включающее в себя ограниченное число известных типов соединителей и идентификаторов протоколов, в WinSock 2 это ограничение снято. Информация по WinSock 2 доступна по адресу:

www.stardust.com/winsock/ws_specs.htm

В настоящее время WinSock допускает совмещение по времени нескольких операций ввода/вывода. Такого рода операции возможны только для соединителей, созданных оператором WSASocket с флагом WSA_FLAG_OVERLAPPED=1 (Win32).



Запросы получения и отправки информации возвращают отклик немедленно. Если получен нуль, это означает, что операция ввода/вывода завершилась успешно, если же получен флаг SOCKET_ERROR с кодом ошибки WSA_IO_PENDING, указывает на успешное начало операции, последующие сообщения позволят судить о дальнейшем выполнении операции.

Допуская возможность нескольких операций ввода/вывода одновременно, нужно обеспечить соответствие между этими процессами и сообщениями об их завершении. В Winsock эта проблема решена с помощью введения объектов события (event objects), по аналогии с Win32. Эти объекты создаются, уничтожаются, устанавливаются в определенное состояние и т.д. Приложение может использовать оператор WSACreateEvent для создания дескриптора (указателя) объекта события, который передается в качестве обязательного параметра для совмещаемых во времени процедур посылки и получения данных (WSASend, WSASendTo, WSARecv, WSARecvFrom). Каждому оператору создания объекта WSACreateEvent должен соответствовать оператор WSACloseEvent, ликвидирующий его. Объекты события используются также оператором WSAEventSelect для того, чтобы связать FD_XXX сетевое события с объектами события.

В 32-разрядной среде операторы для работы с объектами события WSACreateEvent, WSACloseEvent, WSAResetEvent, WSASetEvent, WSAGetOverlappedResult и WSAWaitForMultipleEvents строго соответствуют операторам Win32.

Приложение может установить режим ожидания с блокировкой для одного или нескольких объектов события, используя оператор WSAWaitForMultipleEvents. Для этих целей можно применить и WaitForMultipleObjects. Если при ожидании предпочтительнее отсутствие блокировки, можно воспользоваться оператором WSAGetOverlappedResult, чтобы проконтролировать завершение заданного процесса.

Операторы запуска совмещаемых по времени процессов ввода/вывода WSASend, WSASendTo, WSARecv, WSARecvFrom используют в качестве опционного указателя lpCompletionRoutine, который позволяет по завершении процесса обмена передать управление определенной приложением программе.



В версии WinSock 2 введено понятие группы соединителей, которое позволяет приложению сообщить сервис провайдеру, что данный набор соединителей имеет определенные идентичные свойства (атрибуты). К числу этих свойств относятся относительные приоритеты отдельных соединителей в пределах группы, а также спецификация качества услуг (QOS).

Приложения, реализующие мультимедийные потоки данных, нуждаются в организации специфических взаимоотношений между наборами соединителей. Как минимум это может включать подсказку сервис провайдеру о приоритетности потоков информации. Например, при проведении видеоконференций звуковое сопровождение должно иметь более высокий приоритет, чем видеоинформация. Кроме того, существуют сервис провайдеры, которые могут обеспечить запрашиваемое качество обслуживание (код QOS).



WSASocket

и WSAAccept представляют собой два новых оператора, используемых для создания соединителей и групп, а также для включения соединителя в определенную группу. Идентификатор группы соединителя можно узнать с помощью оператора getsockopt с опцией SO_GROUP_ID. Установка и проверка относительного приоритета соединителей в группе осуществляется соответственно операторами getsockopt и setsockopt с опцией SO_GROUP_PRIORITY. Опции соединителей приведены в таблице 7.8.

Таблица 7.8. Опции соединителей

Опция	Тип	Назначение	Значение по умолчанию
SO_GROUP_ID	GROUP	Идентификатор группы, к которой принадлежит соединитель.	NULL
SO_GROUP_PRIORITY	int	Относительный приоритет соединителей, принадлежащих к группе.	0
SO_MAX_MSG_SIZE	int	Максимальный размер сообщения для соединителей, ориентированных на сообщения. Не имеет смысла для соединителей типа stream.	Зависит от реализации
SO_PROTOCOL_INFO	struct WSAPROTOCOL_INFO	Описание протокольной информации.	Зависит от протокола
PVD_CONFIG	char FAR *	Информационная структура, содержащая данные о сервис провайдере.	Зависит от реализации

Сводная таблица кодов операций для процедуры ioctl приведена ниже (таблица 7.9). Оператор WSAIoctl поддерживает также все операции, специфицированные для процедуры iocltsocket.



Таблица 7.9. Коды операций

Код операции	Input Type	Output Type	Значение
SIO_ASSOCIATE_HANDLE	зависит от API	не использ.	Связывает соединитель с заданным дескриптором интерфейса-партнера.
SIO_ENABLE_CIRCULAR_QUEUEING	не использ.	не использ.	Разрешает организацию кольцевой очереди.
SIO_FIND_ROUTE	struct sockaddr	не использ.	Запрос маршрута до заданного адреса.
SIO_FLUSH	не использ.	не использ.	Аннулирует текущее содержимое очереди на отправку.
SIO_GET_BROADCAST_ADDRESS	не использ.	struct sockaddr	Определяет протокольно-зависимый широковещательный адрес для использования в sendto/WSASendTo
SIO_GET_QOS	не использ.	QOS	Определяет текущую спецификацию соединителя.
SIO_GET_GROUP_QOS	не использ.	QOS	Определяет спецификацию группы, к которой принадлежит соединитель
SIO_MULTIPOINT_LOOKBACK	BOOL	не использ.	Определяет, будут ли данные, посланные в ходе многоточечной сессии, получены соединителем локальной ЭВМ.
SIO_MULTICAST_SCOPE	int	не использ.	Определяет режим, в котором будут осуществляться мультикастинг-обмены.
SIO_SET_QOS	QOS	не использ.	Устанавливает новую спецификацию для соединителя.
SIO_SET_GROUP_QOS	QOS	не использ.	Устанавливает новую спецификацию группы, к которой принадлежит соединитель.
SIO_TRANSLATE_HANDLE	int	зависит от API	Возвращает дескриптор для соединителя s, который соответствует контексту интерфейса-партнера.

Оператор WSAAccept устанавливает условное соединение и имеет следующую структуру параметров.



WSAAccept (

IN	SOCKET	s ,
OUT	struct sockaddr FAR	addr,
IN OUT	LPINT	addrlen ,
IN	LPCONDITIONPROC	lpfnCondition,
IN	DWORD	dwCallbackData

);

s	дескриптор соединителя, который находится в режиме listen.
addr	опционный указатель на буфер (структуру), где должен храниться адрес подключаемого объекта, формат адреса определяется типом протокола, заданным при создании соединителя.
addrlen	Опционный указатель на целую переменную, которая определяет длину аргумента addr.
lpfnCondition	Адрес опционной условной процедуры, которая на основе полученной информации, создает группу или подключает соединитель к уже существующей группе.
dwCallbackData	Параметр, возвращаемый приложению. Этот параметр не интерпретируется WinSock.

<


/p>

IN

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

Программа извлекает очередную заявку на соединение из очереди соединителя s и проверяет с помощью специфицированной программы выполнение условий соединения. Если условия выполнены, возвращается флаг CF_ACCEPT, программа создает новый соединитель и осуществляет подключение его к группе в соответствии с параметром g, выработанным программой проверки условий. Вновь созданный соединитель имеет те же параметры, что и s, включая те, что задаются операторами контроля WSAAsyncSelect или WSAEventSelect. Если программа проверки условия вернула флаг CF_REJECT, запрос на соединение аннулируется. При невозможности принять решение немедленно, программа проверки условия должна вернуть флаг CF_DEFER, при этом никаких действий не предпринимается. Когда приложение будет готово обслужить запрос на соединение, оно снова запустит процедуру WSAAccept и пришлет либо CF_ACCEPT, либо CF_REJECT в качестве результата проверки условий.

Для соединителей, которые остаются в блокирующем режиме, когда в очереди нет запросов на соединение, WSAAccept блокирует вызывающую программу до появления заявки на соединение. Для соединителей неблокирующего типа, когда очередь пуста, оператор WSAAccept вернет флаг ошибки.

При завершении процедуры в addrlen будет записана реальная длина адреса в байтах. Если addr и (или) addrlen равны нулю, это означает, что нет никакой информации об адресе удаленного адресата. В противном случае эти параметры несут в себе реальную информацию не зависимо от результатов проверки условий. Прототип программы проверки условий имеет формат:



int CALLBACK

ConditionFunc(

IN	LPWSABUF	lpCallerId ,
IN	LPWSABUF	lpCallerData ,
IN OUT	LPQOS	lpSQOS ,
IN OUT	LPQOS	lpGQOS,
IN	LPWSABUF	lpCalleeId ,
OUT	LPWSABUF	lpCalleeData ,
OUT	GROUP FAR *	g
IN	DWORD	dwCallbackData

);

ConditionFunc

представляет собой указатель имени программы, которая служит для проверки условий. В 16-битной версии Windows, эта программа выполняется в рамках той же сессии, что и WSAAccept, поэтому вызов каких-либо иных WinSock операторов кроме WSAIsBlocking и WSACancelBlockingCall не возможен. Программа проверки условий должна находиться в DLL или прикладном модуле. Для определения адреса программы проверки условий следует пользоваться оператором MakeProcInstance.



Переменные lpCallerId и lpCallerData являются параметрами, которые содержат адрес партнера и любую пользовательскую информацию, которая была прислана вместе с запросом на соединение.

lpSQOS

представляет собой указатель на текущую спецификацию QOS соединителя s (по одной для каждого из концов виртуального канала), за которой следуют дополнительные параметры, заданные провайдером. Нулевое значение lpSQOS указывает на то, что вызывающая сторона не задала значения QOS.

lpGQOS

- указатель на спецификацию QOS группы соединителей, созданной запрашивающей стороной (для каждого из направлений обмена), за которой следуют дополнительные параметры, заданные провайдером.

lpCalleeId

представляет собой локальный адрес вызывающей стороны.

lpCalleeData

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

lpCalleeData

первоначально содержит размер буфера, предназначенного для сервис провайдера. Положение буфера определяется указателем lpCalleeData->buf. Программа проверки условий должна скопировать lpCalleeData->len байт в lpCalleeData->buf, а затем провести актуализацию lpCalleeData->len, с тем чтобы сообщить действительное число переданных байтов.

В таблице 7.10 представлен перечень кодов-сообщений об ошибках вместе с их эквивалентами для Berkley-соединителей.

Таблица 7.10. Краткое описание сообщений об ошибках

WinSock-код	Berkeley-эквивалент	Код ошибки	Значение
WSAEINTR	EINTR	10004	Как в стандартном C
WSAEBADF	EBADF	10009	Как в стандартном C
WSAEACCES	EACCES	10013	Как в стандартном C
WSAEFAULT	EFAULT	10014	Как в стандартном C
WSAEINVAL	EINVAL	10022	Как в стандартном C
WSAEMFILE	EMFILE	10024	Как в стандартном C
WSAEWOULDBLOCK	EWOULDBLOCK	10035	Как в BSD
WSAEINPROGRESS	EINPROGRESS	10036	Эта ошибка возникает, если какая-либо процедура WinSock вызвана во время исполнения блокирующей операции.
WSAEALREADY	EALREADY	10037	Как в BSD
WSAENOTSOCK	ENOTSOCK	10038	Как в BSD
WSAEDESTADDRREQ	EDESTADDRREQ	10039	Как в BSD
WSAEMSGSIZE	EMSGSIZE	10040	Как в BSD
WSAEPROTOTYPE	EPROTOTYPE	10041	Как в BSD
WSAENOPROTOOPT	ENOPROTOOPT	10042	Как в BSD
WSAEPROTONOSUPPORT	EPROTONOSUPPORT	10043	Как в BSD
WSAESOCKTNOSUPPORT	ESOCKTNOSUPPORT	10044	Как в BSD
WSAEOPNOTSUPP	EOPNOTSUPP	10045	Как в BSD
WSAEPFNOSUPPORT	EPFNOSUPPORT	10046	Как в BSD
WSAEAFNOSUPPORT	EAFNOSUPPORT	10047	Как в BSD
WSAEADDRINUSE	EADDRINUSE	10048	Как в BSD
WSAEADDRNOTAVAIL	EADDRNOTAVAIL	10049	Как в BSD
WSAENETDOWN	ENETDOWN	10050	Как в BSD. Ошибка возникает в любое время, когда приложение WinSock обнаруживает ошибку на нижележащем уровне.
WSAENETUNREACH	ENETUNREACH	10051	Как в BSD
WSAENETRESET	ENETRESET	10052	Как в BSD
WSAECONNABORTED	ECONNABORTED	10053	Как в BSD
WSAECONNRESET	ECONNRESET	10054	Как в BSD
WSAENOBUFS	ENOBUFS	10055	Как в BSD
WSAEISCONN	EISCONN	10056	Как в BSD
WSAENOTCONN	ENOTCONN	10057	Как в BSD
WSAESHUTDOWN	ESHUTDOWN	10058	Как в BSD
WSAETOOMANYREFS	ETOOMANYREFS	10059	Как в BSD
WSAETIMEDOUT	ETIMEDOUT	10060	Как в BSD
WSAECONNREFUSED	ECONNREFUSED	10061	Как в BSD
WSAELOOP	ELOOP	10062	Как в BSD
WSAENAMETOOLONG	ENAMETOOLONG	10063	Как в BSD
WSAEHOSTDOWN	EHOSTDOWN	10064	Как в BSD
WSAEHOSTUNREACH	EHOSTUNREACH	10065	Как в BSD
WSASYSNOTREADY		10091	Выдается WSAStartup, указывает, что сетевая субсистема использоваться не может.
WSAVERNOTSUPPORTED		10092	Выдается WSAStartup, указывая на то, что WinSock DLL не может поддерживать это приложение.
WSANOTINITIALISED		10093	Выдается любой процедурой кроме WSAStartup, указывая на то, что успешное исполнение WSAStartup не было осуществлено.
WSAEDISCON		10094	Выдается recv, WSARecv, чтобы отметить начало разрыва связи удаленным партнером
WSA_OPERATION_ABORTED		TBD	Совмещенные по времени процедуры прерваны из-за закрытия соединения, или выполнения команды SIO_FLUSH в WSAIoctl
WSAHOST_NOT_FOUND	HOST_NOT_FOUND	11001	Как в BSD
WSATRY_AGAIN	TRY_AGAIN	11002	Как в BSD
WSANO_RECOVERY	NO_RECOVERY	11003	Как в BSD
WSANO_DATA	NO_DATA	11004	Как в BSD

<


/p>

Современные версии WinSock обеспечивают протокольно- независимый доступ ко всем ресурсам сети, включая такие стандартные приложения, как DNS, SAP, X.500 и т.д.

Позволяют реализовать несколько сессий ввода/вывода одновременно.

Поддерживают любые стандартные уровни сервиса (QOS - Quality of service). Осуществляют объединение соединителей по группам в соответствии с их параметрами.

Допускается многопротокольная широковещательная или мультикастинг-адресация.

Предусматривается совместное использование соединителей несколькими процессами, условное создание соединителей и объединение их в группы.

Введено понятие WOSA-интерфейса (Windows Open Service Architecture), который обеспечивает связь между прикладной программой и сетевыми процедурами ОС. Этот интерфейс заметно упрощает программирование при работе с пакетами.

Каждая процедура, распознаваемая WOSA, имеет в свою очередь несколько интерфейсов, ориентированных на конкретных сервис-провайдеров. Применение этих средств реализуется через DLL.

WinSock, следуя модели WOSA, обеспечивает прикладной интерфейс для сетевого программирования (API - Application Programming Interface), который организует доступ к транспортным услугам и серверу имен сервис-провайдера (SPI - Service Provider Interfaces). SPI ориентирован на использование в рамках 32-битовой модели Microsoft Windows, включая Windows NT и Windows 95.

Транспортные сервис-провайдеры (например, TCP/IP или IPX/SPX) и именные серверы (DNS) в WinSock представляют собой динамические библиотеки (DLL) с одной точкой входа для процедур инициализации WSPStartup или NSPStartup (обратите внимание на то, что здесь под сервис-провайдером подразумевается система, способная предоставить определенный вид услуг). Все остальные процедуры сервис-провайдера сделаны доступными для WinSock DLL через диспетчерскую таблицу. Динамическая библиотека сервис-провайдера загружаются в память WinSock DLL только по мере необходимости и выгружаются, когда они более не нужны. Динамическая библиотека сервис-провайдера имеет обычно расширение .WSP или .NSP. Процедуры WinSock SPI имеют префиксы:



WSP

WinSock Service Provider

для транспортных услуг сервис-провайдера;

WPU

WinSock Provider Upcall

для входа в WinSock DLL сервис-провайдера;

WSC

WinSock Configuration

для входа в WinSock DLL инсталляционных приложений;

NSP

Name Space Provider

для работы с сервером имен.

Сервис- провайдеры WinSock при работе со строками используют UNICODE. WinSock DLL выполняют необходимые преобразования при работе с приложениями, использующими ANSI или UNICODE.

Конкретный сервис-провайдер может поддерживать один или более протоколов. Так TCP/IP-провайдер должен как минимум поддерживать TCP- и UDP-протоколы, в то время как IPX/SPX-провайдер - IPX, SPX и SPX II. Каждый поддерживаемый протокол описывается в структуре WSAPROTOCOL_INFO, а набор таких структур представляет собой каталог используемых протоколов (более детальную информацию по данной тематике можно найти по адресу: www.stardust.com/winsock/ws_specs.htm).

Одной из главных задач WinSock DLL является выполнение функции регулировщика информационных потоков между приложениями и сервис-провайдерами. Каждый сервис-провайдер взаимодействует только с WinSock DLL. WinSock DLL заботится об объединении потоков событий от разных сервис-провайдеров и направлении их приложению. Эта библиотека берет на себя функции арбитража и синхронизации. Взаимоотношения между сервис-провайдерами (даже если они поддерживают разные протоколы) улаживаются также WinSock DLL.

Работа WinSock DLL базируется на параметрах соединителей, которые задаются при формировании (socket и WSASocket), именно эта информация определяет, какой из сервис провайдеров будет задействован. Для выбора сервис провайдера используется процедура WSPSocket. В случае процедуры socket, WinSock DLL находит запись в структуре WSAPROTOCOL_INFO, которая соответствует входным параметрам (идентификатор стека протоколов, тип соединителя, протокол).

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



Транспортный SPI WinSock аналогичен WinSock API с точки зрения базовых процедур с соединителями. Так процедурам connect и WSAConnect ставится в соответствие WSPConnect; accept и WSAAccept - WSPAccept, а socket и WSASocket - WSPSocket.

Так как WinSock DLL не поставляется теперь разработчиками стека протоколов, расширение функциональных возможностей представляет определенную проблему. Для преодоления этих трудностей новейшие версии WinSock используют процедуру WSAIoctl, чтобы помочь сервис-провайдерам на практике реализовать какие-либо функциональные новшества.

Для введения расширенных возможностей приложение должно запросить указатель на точку входа в соответствующую программу. Это делается с помощью процедуры WSAIoctl, используя команду SIO_GET_EXTENSION_FUNCTION_POINTER. При этом входной буфер процедуры WSAIoctl содержит идентификатор запрашиваемой функции, в выходной буфер будет занесен указатель на нужную программу.

Идентификаторы, присвоенные новым функциям, должны быть уникальными глобальными идентификаторами (GUID - Global Unique IDentifiers), которые присваиваются им поставщиками сервис-провайдеров.

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

В WinSock DLL содержится процедура WSCInstallProvider для инсталляции программ поставщиков и процедура выгрузки этих программ WSCDeinstallProvider.

Структура WSAPROTOCOL_INFO поставляется для каждого протокола и указывает на то, является ли этот протокол базовым, слоевым или стеком. Величина поля ProtocolChain.ChainLen интерпретируется как:

0	протокол слоя
1	базовый протокол (или стек, если стек состоит из одного протокола)
>1	стек протоколов.

Инсталляция стека протоколов возможна лишь после загрузки всех составных частей (слоевых и базовых протоколов). Структура WSAPROTOCOL_INFO для стека протоколов использует поле ProtocolChain для описания длины стека и идентификации каждой из составных частей. Отдельные протоколы, входящие в стек последовательно перечислены в массиве ProtocolChain.ChainEntries, нулевой элемент списка соответствует первому протоколу слоя.



SDK ( System Development Kit) для WinSock включает в себя инструментальную WinSock и отладочную DLL.

При разработке протокольно-независимых приложений для систем клиент-сервер нужно зарегистрировать имя сервера в банке имен, только это может сделать его доступным извне. Программа-клиент может функционировать лишь при условии, если она способна найти необходимую ей процедуру в поле имен и получить доступ к соответствующему транспортному протоколу и адресной информации. Для тех кто работает с протоколами TCP/IP это может в начале вызвать определенные трудности, которые компенсируются возможностями создания программ, пригодных для широкого класса самых разнообразных протоколов (например, Novell). Под работой с полем имен здесь подразумевается возможность установления соответствия между протоколом и адресным атрибутом сетевой услуги, которой присвоено какое-то имя. Примерами таких полей имен могут служить уже используемые системы DNS (Domain Name System), NDS (Netware Directory Services), X.500 и др. Поля имен могут быть динамическими, статическими и постоянными.

Динамические поля имен служат для краткосрочной регистрации сетевой услуги. Часто они базируются на широковещательной системе определения доступности той или иной услуги. Примерами таких систем являются SAP в среде Netware и NBP в среде Appletalk.

Статические поля имен формируются при первоначальном создании сервера имен и в дальнейшем могут изменяться лишь администратором сети. Традиционная система DNS относится именно к этой разновидности. Программа может воспользоваться таким банком имен, но не может произвести туда запись.

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

Некоторые поля имен организованы иерархически, X.500 и NDS, например, позволяют неограниченное число уровней вложения. Программные интерфейсы, предназначенные для посылки запросов в именные базы данных, сильно варьируются в зависимости от разновидности используемого поля имен. Сервер имен представляет собой резидентную программу, которая обеспечивает интерфейс между WinSock SPI и некоторой существующей базой данных имен.



Используемые услуги в WinSock группируются в классы услуг и в пределах класса имя услуги должно быть уникально. Примерами классов услуг могут служить FTP и SQL. Каждому классу присваивается имя и идентификатор (ID). Имя класса может не быть уникальным, но идентификатор обязан быть неповторимым. В качестве идентификаторов классов услуг в Winsock используются GUID (Globally Unique Identifiers). Для генерации GUID имеется специальная программа (UUIDGEN.EXE), которой может воспользоваться разработчик новых классов услуг.

DNS в Internet не имеет развитой системы для записи информации о классах услуг. Для TCP/IP-класса услуг GUID присвоен раз и навсегда.

WinSock DLL может маршрутизовать прикладные операции в пространстве имен и переадресовывать их соответствующим серверам имен.

Процедуры установки классов услуг, регистрации и обслуживания запросов осуществляются непосредственно через интерфейс API - SPI. Процедура WSAGetServiceClassNameByServiceClassId не имеет аналога среди операторов SPI, так как эта процедура WinSock DLL осуществляет обращение к NSPGetServiceClassInfo.

Переключение сервера имен из активного состояния в пассивное и обратно осуществляется с помощью процедуры WSCEnableNSProvider. В активном состоянии могут находиться несколько серверов имен одновременно. Инициализация сервис провайдеров выполняется с помощью процедуры WSPStartup (см. аналогично WSAStartup). Каждой процедуре WSPStartup должна соответствовать процедура WSPCleanup.

Процедура WSPSocket имеет параметр flags, который позволяет контролировать атрибуты соединителя. Флаг WSA_FLAG_OVERLAPPED указывает на то, что данный соединитель будет использоваться в режиме совмещения процессов ввода/вывода.

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

Соединитель, созданный для работы в блокирующем режиме, может быть преобразован в неблокирующий с помощью процедур WSPAsyncSelect, WSPEventSelect или WSPIoctl. Перевод соединителя в блокирующий режим производится посредством процедур WSPIoctl, если WSPAsyncSelect неактивен, или WSPEventSelect, если активен.



Процедура WSPCloseSocket ликвидирует дескриптор соединителя и все процессы, использующие этот соединитель, будут прерваны.

Понятие блокировки для среды Windows было фундаментальным. В WinSock 1.1, блокирующие процедуры WinSock были проблемой, так как они парализовали взаимодействие приложения и надстройки Windows, а применение псевдо-блокирующей техники не всегда давало удовлетворительный эффект. В ОС типа Windows 95 или Windows NT блокирующие процедуры уже не могут вызвать каких-либо проблем, более того, они уже представляются привлекательными. Интерфейс WinSock 2 API уже не поддерживает более псевдоблокировку, но для обеспечения совместимости с WinSock 1.1 он эмулирует этот механизм.

В среде Win16, где настоящее блокирование не поддерживается ОС, блокирующие процедуры, которые не могут быть закончены немедленно, обслуживаются с использованием псевдоблокировки. Сервис-провайдер инициализирует процедуру, после чего входит в цикл, внутри которого осуществляет доставку любых сообщений Windows и проверяет завершение процедуры. Если процедура завершилась, или если вызван оператор WSPCancelBlockingCall, происходит выход из цикла, а блокирующая процедура завершается с соответствующим результатом.

Эта схема вполне приемлема для простых приложений. Но она неприемлема для приложений, где должны реализоваться сложные схемы доставки сообщений, например, для модели MDI (Multiple Document Interface). Для таких приложений псевдоблокировка должна быть реализована в самом приложении. Сервис-провайдер в этом случае должен вызывать именно этот цикл. Для этого он должен получить указатель на него, обратившись к WPUQueryBlockingCallback.

Сервис-провайдер WinSock не может исходить из предположения, что псевдоблокировка, используемая приложением, обеспечит обработку сообщений. Если приложение не приспособлено для решения таких задач, оно откликнется флагом FALSE. Если сервис-провайдер требует обработки сообщений для своих внутренних нужд, он может вызвать процедуру PeekMessage до передачи управления циклу псевдоблокировки в приложении.



Сервис- провайдер WinSock использует псевдоблокировку лишь при выполнении определенных условий:

Программа определена как блокирующая,

Соответствующий соединитель работает в блокирующем режиме,

Запрос не может быть выполнен немедленно.

Если условия не выполнены, уход в цикл псевдоблокировки осуществлен не будет.

Если во время цикла псевдоблокировки получено сообщение Windows, существует опасность того, что будет предпринята попытка вызова еще одной процедуры WinSock. Из-за трудностей управления этим процессом WinSock 1.1 запрещает такие вызовы. Любая попытка осуществить вложенный вызов процедур WinSock вызовет ошибку WSAEINPROGRESS. Для WinSock 1.1 это ограничение справедливо как для блокирующих, так и для неблокирующих процедур. Имеется два исключения из этого правила. Это процедура, которая позволяет приложению проверить, находится ли система в цикле псевдоблокировки (WSAIsBlocking), и процедура ухода из этого цикла (WSPCancelBlockingCall).

WinSock 2 DLL имеет средства для формирования объектов событий, как для приложения, так и для сервис-провайдера, хотя на практике объекты событий создаются в основном приложениями. Для формирования объектов событий в WinSock имеется оператор WPUCreateEvent. Дескриптор объекта события имеет смысл лишь в контексте программы, его сформировавшей. В среде Win32 работа с объектами событий выполняется самой операционной системой.

Объекты событий в WinSock представляют собой простые конструкции, которые могут создаваться и уничтожаться, они могут устанавливаться и сбрасываться. Клиент создает объект события и передает его дескриптор в качестве параметра таким процедурам как WSPSend и WSPEventSelect. Когда оговоренные условия выполнены, сервис-провайдер использует дескриптор для того, чтобы установить объект события с помощью оператора WPUSetEvent. При этом клиент WinSock SPI может находиться в состоянии блокировки-ожидания или в режиме запроса, ожидая, когда объект события будет установлен. Клиент может сбросить объект события в нуль, снова его установить и использовать снова.



Субъект (приложение или сервис-провайдер), создавший объект события, ответственен и за его ликвидацию. Сервис-провайдер может это сделать с помощью WPUCloseEvent.

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

FD_CONNECT	Канал до удаленной ЭВМ или для мультикастинг-сессии сформирован
FD_ACCEPT	Удаленная ЭВМ выставила запрос на соединение;
FD_READ	Получены данные и их можно считать;
FD_WRITE	В буферах сервис-провайдера появилось свободное место и можно послать очередную порцию информации;
FD_OOB	Для чтения доступна высокоприоритетная информация;
FD_CLOSE	Удаленная ЭВМ закрывает канал;
FD_QOS	Произошло изменение оговоренного значения QOS (качества услуг);
FD_GROOUP_QOS	Произошло изменение оговоренного значения QOS для данной группы соединителей.

Стандартный BSD-интерфейс соединителей имеет только одно средство получить информацию о сетевых событиях - оператор select. Этот метод не может дать информацию о событиях FD_QOS и FD_GROUP_QOS.

В Windows Sockets 1.1 используется асинхронный механизм получения информации о сетевых событиях. Для регистрации интересующих событий можно использовать процедуру WSPAsyncSelect. Когда нужное сетевое событие произойдет, соответствующему окну будет послано сообщение, заданное клиентом. Сервис-провайдер использует для тех же целей процедуру WPUPostMessage. В среде Win32 этот метод получения данных о событиях нельзя считать эффективным.



WSPEventSelect

ведет себя практически также как WSPAsyncSelect за исключением того, что вместо посылки сообщения Windows при сетевом событии типа FD_XXX, устанавливается соответствующий объект события.

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

Сервис-провайдеры (ISDN или ATM) могут использовать групповые значения QOS при формировании виртуального канала и повышения эффективности своей работы. Пакеты для соединителей в пределах группы мультиплексируются обычным образом.



Операторы WSPSocket и WSPAccept предназначены для формирования соединителей и подключения новых соединителей, к той или иной группе. Однажды включенный в группу соединитель остается в ней до своего закрытия. Группа прекращает свое существование, лишь когда последний соединитель группы будет закрыт. Идентификатор группы соединителей может быть получен с помощью оператора WSPGetSockOpt с опцией SO_GROUP_ID. Узнать об относительном приоритете соединителя в группе можно, воспользовавшись процедурой WSPGet/SetSockOpt с опцией SO_GROUP_PRIORITY.

Групповое значение QOS можно задать при выполнении WSPConnect, или WSPIoctl с SIO_SET_GROUP_QOS, если специфицированный соединитель является “учредителем” группы. Оператор WSPIoctl с SIO_GET_GROUP_QOS может использоваться для получения группового значения QOS заданного соединителя.

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

1. Создание новых групп и присвоение им уникальных идентификаторов.



2. Возможность включения соединителя в одну из существующих групп.



3. Учет провайдером значения QOS порождающего соединителя при формировании списка параметров нового соединителя, включаемого в группу.

Существуют группы двух видов. Одни включают в себя соединители, ориентированные на соединение, они могут быть подключены только к определенному адресу ЭВМ, остальные группы относятся к другому виду. Провайдер не может включить в группу соединитель, который не удовлетворяет этому условию. Провайдер не может также выполнить соединение, если адресат не соответствует адресу места назначения группы соединителей. Групповой адрес места назначения определяется, когда выполняется процедура connect для первого из соединителей группы.

Единственный индивидуальный параметр соединителя в группе - его внутренний уровень приоритета. Провайдер должен уметь считывать значение приоритета, но он может полностью игнорировать этот параметр. В настоящее время не существует каких-либо механизмов для сопоставления приоритетов соединителей, принадлежащих к разным группам, или соединителей вне групп. Поддержка провайдеров групп не означает непременную поддержку различного качества услуг (QOS, см. RFC-1363).



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

Характер информационного обмена описывается спецификацией потока (flow specs), для каждого соединителя используется две такие спецификации, по одной для каждого из направлений обмена. Запрос на соединение реализуется через процедуры WSPConnect или WSPIoctl с кодом команды SIO_SET_QOS/SIO_SET_GROUP_QOS. Спецификация потока параметрически задает уровень сервиса (QOS) и определяет механизм адаптации приложения к сетевым условиям.

В WinSock 2 спецификация потока содержит следующие характеристики QOS:

Описание источника информационного потока, которое характеризует способ, используемый приложением, для введения потока данных в сеть. Эта спецификация выполняется в терминах модели пакетов символов (token bucket) и включает частоту символов, их размер, частоту пакетов символов и их размер, а также максимальное значение информационного потока.

Задержка (latency) - приемлемые верхние пределы задержки и ее вариации.

Гарантированный уровень обслуживания. Предполагается, что провайдер, который не способен обеспечить требуемый уровень сервиса (QOS), не сможет быть подключен.

Цена (параметр зарезервирован на будущее).

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

Для протоколов, ориентированных на соединение более удобно для приложения оговаривать QOS при формировании соединения. Это делается путем запроса WSPConnect, направленного сервис-провайдеру. Если QOS было задано с помощью WSPIoctl, его значение может быть переписано при выполнении процедуры WSPConnect.

Бессвязные соединители могут также использовать WSPConnect с целью установления определенного уровня QOS для канала связи с партнером



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

Но после того как информация о состоянии сети получена, условия могут измениться, партнеры могут согласовать другой уровень QOS, так что приложение должно быть готово ко всему. Для информирования клиента о возможных изменениях условий в Winsock используется механизм сетевых событий (FD_QOS и FD_GROUP_QOS). Сервис-провайдер должен генерировать события типа FD_QOS/FD_GROUP_QOS, если уровень сервиса изменился значительно. Клиент должен использовать WSPIoctl с кодами команд SIO_GET_QOS и/или SIO_GET_GROUP_QOS, чтобы получить соответствующую спецификацию потока и выяснить, изменился ли уровень сервиса (QOS). Структура QOS должна актуализоваться вне зависимости от типа события FD_QOS/FD_GROUP_QOS. Если новый уровень сервиса неприемлем, клиент может попытаться приспособиться к новым условиям или закрыть соединение. При повторной попытке согласовать уровень QOS успешный выход из процедуры WSPIoctl указывает, что новое значение QOS приемлемо. Структура QOS в WinSock 2 описана в файле Winsock2.h и представлена ниже.

typedef enum

{

BestEffortService,

ControlledLoadService,

PredictiveService,

GuaranteedService

} GUARANTEE;

typedef struct _flowspec

{ int32

TokenRate;

/* В байтах/сек */

int32

TokenBucketSize;

/* В байтах */

int32

PeakBandwidth;

/* В байтах/сек */

int32

Latency;

/* В микросекундах */

int32

DelayVariation;

/* В микросекундах */

GUARANTEE LevelOfGuarantee; int32

CostOfCall;

/* Зарезервировано для будущего использования, должно быть = 0 */

int32

NetworkAvailability

/* только для чтения:

1, если есть доступ,

0, если нет */

} FLOWSPEC, FAR * LPFLOWSPEC;

typedef struct _QualityOfService

{ FLOWSPEC

SendingFlowspec;

/* Спецификация потока для данных */



/* Посылка */

FLOWSPEC

ReceivingFlowspec;

/* Спецификация потока для данных */

/* Прием */

WSABUF

ProviderSpecific;

/* Дополнительный провайдер */

/* Специфические параметры */

} QOS, FAR * LPQOS;



Определения:

LevelOfGuarantee	Согласуемый уровень сервиса. Определены четыре уровня: гарантированный, предсказуемый, контролируемая загрузка и лучшее, что возможно. Предсказуемый уровень сервиса может дать наилучший результат при использовании определенного ресурса сети, в то время как гарантированный уровень соответствует необходимому уровню услуг конкретного приложения. Провайдеры могут предоставлять один, оба или ни одного их этих двух видов услуг.
GuaranteedService	Провайдер, поддерживающий гарантированный уровень сервиса, использует алгоритм очередей, в котором поток изолируется от влияния других потоков, и гарантирует, на сколько возможно, пропускную способность. Если отправитель шлет данные с большей скоростью, сеть может задержать или даже ликвидировать “лишнюю” часть потока. Если поток находится в пределах допустимого, то гарантируется и задержка отклика. Этот вид сервиса предусмотрен для приложений реального времени.
PredictiveService	Провайдер, поддерживающий предсказуемый уровень сервиса, гарантирует пропускную способность, по крайней мере равную TokenRate, на время соединения. Если отправитель шлет данные с большей скоростью, сеть может задержать или даже ликвидировать “лишнюю” часть потока. Значение задержки не гарантируется. Этот вид сервиса предназначен для приложений, способных адаптироваться к вариациям качества услуг, например, передача видео изображения.
ControlledLoadService	Этот уровень сервиса предполагает, что система сетевых устройств, которыми пользуется приложение, обеспечит условия работы, близкие к тем, которые достижимы при незагруженных каналах, для используемой транспортной среды. Приложения, использующие этот уровень сервиса, могут ожидать что: 1. Большая часть передаваемых пакетов будет успешно доставлена (процент потерь определяется частотой ошибок транспортной среды). 2. Задержка доставки не будет заметно превышать минимальное время распространения сигнала в используемой транспортной среде.
BestEffortService	Провайдеры, поддерживающие уровень сервиса “лучшее что возможно”, рассматривают спецификацию потока, как руководство к действию. И пытаются сделать все возможное, чтобы поддержать запрашиваемый уровень сервиса (без каких-либо твердых гарантий).
TokenRate/TokenBucketSize	Модель “блоков символов” (Token bucket model) используется для задания верхнего предела скорости обмена. Величина value -1 в этом случае означает, что не существует никаких ограничений на скорость обмена. Значение TokenRate (частота символов) выражается в байтах в сек, а TokenBucketSize в байтах. Блок имеет определенный объем (TokenBucketSize), который заполняется с определенной скоростью (TokenRate). Если в блоке достаточно места, приложение может посылать данные, что приводит к уменьшению свободного места. Если же свободного места нет, приложение должно прервать обмен и ждать. Если приложение в течение определенного времени слало данные со скоростью меньше чем TokenRate, оно может затем на некоторое время превысить эту скорость.
PeakBandwidth	Значение этого поля (выражается в байтах в сек) ограничивает максимальную скорость пересылки пакетов приложением. Промежуточные системы могут использовать эту величину для оптимизации использования имеющихся ресурсов.
Latency	Характеризует максимально приемлемую задержку между посылкой бита отправителем и его получением адресатом (в миллисекундах).
DelayVariation	Значение этого поля в миллисекундах характеризует разницу между максимальной и минимальной задержкой доставки пакетов. Этот параметр используется приложением для расчета объема входного буфера.
CostOfCall	Зарезервировано на будущее и должно равняться нулю.
NetworkAvailability	Это поле, доступное провайдерам только в режиме чтения, используется для сообщения приложению о доступности транспортной среды (например, знакомая многим ситуация потери спутника антенной).

<


/p> Приложения, которые не склонны иметь дело с QOS-структурой непосредственно, могут воспользоваться именами известных видов сервиса и получить нужные данные с помощью запроса WSPGetQOSByName.

Прежде чем использовать соединитель, надо связать его с локальным адресом. Это выполняется с помощью процедуры WSPBind, или WSPConnect.

Сервер сначала создает соединитель, связывает его с известным локальным адресом (что позволяет клиенту найти его) и переводит соединитель в режим ожидания посредством WSPListen, готовя его к приему запросов на соединение. Одновременно система подготавливает структуру для формирования очереди запросов. Сервис-провайдер заносит поступающие запросы в очередь, где они ожидают обработки. Запросы могут быть удалены клиентом из очереди по таймауту.

Если использован соединитель блокирующего типа, сервер может немедленно вызвать процедуру WSPAccept, которая вызовет блокировку на время ожидания запроса на соединение. В качестве альтернативы сервер может использовать один из механизмов обработки сетевых событий, описанный ранее. В зависимости от выбранного механизма провайдер или пошлет сообщение Windows или даст знать о приходе запроса на соединение через объект события.

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

Когда сервер запускает процедуру WSPAccept, сервис-провайдер инициализирует программу проверки условий, поставляемую приложением. В качестве параметров обращения используется информация, полученная вместе с запросом на соединение (берется из очереди запросов). Эта информация включат в себя адрес подключаемой ЭВМ, данные о пользователе и характеристику QOS, если таковая имеется. На основе полученной информации сервер определяет, принять данный запрос или нет.



Если сервер принял запрос, он должен сформировать новый соединитель с теми же атрибутами что и соединитель ожидавший прихода запроса. Исходный соединитель остается в режиме ожидания последующих запросов.

Для получения локального адреса сопряженными соединителями используется запрос WSPGetSockName. Это особенно полезно, когда послан запрос WSPConnect без предварительного вызова процедуры WSPBind.

Как было сказано ранее, процедура WSPAccept позволяет воспользоваться поставляемой клиентом программой проверки условий, которая осуществляет условную обработку запросов на соединения, ожидающие обслуживания. Принятие решения осуществляется на основе информации, поступающей вместе с запросом (идентификатор источника запроса, QOS и т.д.). Если программа проверки условий возвращает флаг CF_ACCEPT, формируется новый соединитель с теми же свойствами, что и исходный. Если программа проверки вернет флаг CF_REJECT, запрос на соединение будет отвергнут. При возвращении флага CF_DEFER принятие решения откладывается, а запрос на соединение остается в очереди. Клиент должен будет осуществить вызов WSPAccept еще раз.

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

Разрыв соединения может быть выполнен несколькими способами. Для инициализации прерывания связи можно, например, применить процедуру WSPShutdown (с параметром how равным SD_SEND или SD_BOTH), и WSPSendDisconnect. Процедура WSPCloseSocket может быть применена и для аварийного прерывания соединения.

Сервис провайдер сообщает о разрыве соединения по инициативе удаленного партнера с помощью сетевого события FD_CLOSE. При реализации процедуры разрыва соединения возможен обмен определенной информацией, если это предусмотрено используемым протоколом.



Инициатор разрыва связи может вызвать WSPSendDisconnect, чтобы сообщить, что данных больше посылаться не будет и можно ликвидировать соединение. При этом может быть послана некоторая служебная информация, предусмотренная протоколом обмена. Для чтения этой информации партнер может воспользоваться оператором WSPRecvDisconnect. По завершении этого обмена обе стороны вызывают процедуры WSPCloseSocket.

Следует различать процедуры прерывания (shutdown) связи и ее разрыва (close). Прерывание связи сопряжено с определенным диалогом между партнерами, после чего связь “замораживается”, но дескриптор связи сохраняется. Существует два типа прерывания связи: аварийное (аппаратное) и нормальное. При нормальном прерывании любые данные, которые стояли в очереди, пересылаются до завершения процесса прерывания. При аварийном же прерывании непосланная информация теряется.

В Windows Sockets, как процедура WSPShutdown, так и WSPSendDisconnect могут использоваться для инициализации прерывания связи. В то время как запрос WSPCloseSocket служит для ликвидации дескрипторов соединителей и освобождения связанных с ними ресурсов.

Путем установки определенных значений для опций соединителей SO_LINGER и SO_DONTLINGER можно получит следующие варианты реализации процедуры WSPCloseSocket.

Процедура аварийного прерывания соединения, которая возвращается из WSPCloseSocket немедленно.

Нормальное прерывание соединения (graceful shutdown); задержка исполнения до завершения исполнения процедуры или до истечения заданного времени. Если таймаут наступает до завершения процедуры прерывания соединения, запускается процесс аварийного разрыва соединения.

Нормальное прерывание соединения с немедленным возвратом и завершением процедуры прерывания в фоновом режиме. Этот алгоритм реализуется по умолчанию. Приложение при этом не знает, когда и как завершается процесс прерывания соединения.

Для соединителей, соответствующих протоколам неориентированных на соединение, работа, выполняемая оператором WSPConnect, связана главным образом с установлением адреса места назначения по умолчанию, что позволит в дальнейшем использовать соединитель в операциях обмена, ориентированных на соединение (WSPSend and WSPRecv). Любые дейтограммы, полученные от отправителя с адресом, отличным от специфицированного, будут проигнорированы.



Место назначения по умолчанию может быть изменено с помощью повторного вызова WSPConnect. Любая дейтограмма из входной очереди будет отброшена, если новый адрес отличается от адреса, заданного в предыдущем WSPConnect.

Если новый адрес равен нулю, соединитель будет отсоединен, так как удаленный адрес не определен, в результате операторы WSPSend и WSPRecv возвратят флаг ошибки WSAENOTCONN, в то же время WSPSendTo и WSPRecvFrom могут использоваться по-прежнему. Существует три базовых способа выполнения операций ввода/вывода:

Блокирующий ввод/вывод,

Неблокирующий ввод/вывод с асинхронными сетевыми событиями,

Совмещенный ввод/вывод.

Первый вариант является режимом по умолчанию, неблокирующий вариант может использоваться на любом соединителе, который поставлен в соответствующий режим. Третья разновидность обмена реализуется только на соединителях, которые при формировании были объявлены совмещенными. Процедуры посылки WSPSend и WSPSendTo и приема WSPRecv и WSPRecvFrom реализуют все три указанных режима обмена. Сервис-провайдеры определяют метод обмена на основе режима работы соединителя, атрибутов и входных параметров.

Простейшим режимом обмена в WinSock 2 является блокирующий ввод/вывод. Этот режим устанавливается по умолчанию. Любая операция ввода/вывода на блокирующем соединителе вернет управление системе только по завершении процедуры. Таким образом, в ходе любой сессии может выполняться только одна операция ввода/вывода. Это простой режим, но отнюдь не самый эффективный.

Если соединитель находится в неблокирующем состоянии, любая операция обмена должна либо завершаться немедленно, либо возвращать флаг ошибки WSAEWOULDBLOCK, указывая, что операция не может быть завершена корректно. Необходим механизм для определения, когда следует попытаться выполнить операцию еще раз. Для решения этой проблемы определен список сетевых событий, наступление которых может контролироваться с помощью процедур WSPSelect, WSPAsyncSelect или WSPEventSelect.

В WinSock 2 впервые разрешено совмещение нескольких процедур ввода/вывода и потребована поддержка этого режима всеми сервис-провайдерами. Этот режим возможен только для соединителей, сформированных с помощью WSPSocket с флагом WSA_FLAG_OVERLAPPED.



Для приема данных клиент может воспользоваться процедурами WSPRecv или WSPRecvFrom, чтобы указать буферы, куда будут записываться данные. Если один или более буферов подготовлены приложением до начала обмена, информация будет заноситься непосредственно в буферы пользователя и многоступенчатое копирование будет исключено. Если буферов заранее приложением не подготовлено, информация заносится сервис-провайдером во внутренний буфер и система ждет запроса, чтобы перенести данные в буфер приложения. Исключением из этого правила является случай, когда приложение использует WSPSetSockOpt для установления нулевого размера входного буфера. В этом варианте данные принимаются лишь при наличии указателей на буфер приложения. При посылке информации клиенты для выдачи указателей на буфер данных используют WSPSend или WSPSendTo.

В совмещенном режиме процедуры посылки и получения данных завершаются немедленно. Полученный по возврату нуль, указывает на то, что процедура завершилась успешно. То есть, сформирован соответствующий объект события или программа завершения установлена в очередь с помощью WPUQueueApc. Возврат флага SOCKET_ERROR, сопряженного с кодом ошибки WSA_IO_PENDING, указывает, что совмещенная операция успешно начата и будет позднее сообщено, когда выходной буфер будет свободен или входной буфер будет заполнен. Любые другие коды ошибок говорят о сбое.

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

Сервис-провайдеры имеют два способа сообщать о завершении совмещенных по времени операций: установка объекта события, заданного программой-клиентом, или запуск заданной клиентом программы завершения. В обоих случаях каждой из совмещенных операций ставится в соответствие структура WSAOVERLAPPED. Память для размещения этой структуры выделяется клиентом и используется им для указания того, какой из объектов следует установить при завершении процесса обмена. Структура WSAOVERLAPPED может использоваться сервис-провайдером для хранения дескриптора соответствующей совмещенной процедуры. Для извлечения нужной информации из указанной структуры можно воспользоваться оператором WSPGetOverlappedResult.



Если параметр lpCompletionRoutine совмещенной операции не равен нулю, то сервис-провайдер может вызвать программу завершения, специфицированную клиентом. WinSock DLL предлагает асинхронную процедуру вызова (APC) программ завершения обмена.

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



WPUQueueApc

берет в качестве входных параметров указатель на структуру WSATHREADID, указатель на процедуру APC и 32-разрядный контекстный код. Сервис-провайдеры всегда получают указатель на соответствующую структуру WSATHREADID через параметр lpThreadId. Провайдер должен запомнить структуру WSATHREADID и выдать указатель на ее копию в качестве параметра оператора WPUQueueApc.

Так как механизм APC работает только с одним 32-разрядным контекстным кодом, процедура APC не может быть сама программой завершения, заданной клиентом. Сервис-провайдер должен выдать указатель на свою собственную процедуру APC, которая, используя контекстный код, обеспечивает доступ к необходимой информации для совмещенной операции обмена и вызывает заданную клиентом программу завершения.

Сервис-провайдер должен позволить клиентам WinSock 2 вызов процедур чтения или записи во время выполнения процедуры завершения обмена и гарантировать, что для данного соединителя не будет допущено вложение операций завершения.

Структура WSAOVERLAPPED создает коммуникационную среду между запуском совмещенной операции обмена и последующим ее завершением. Структура WSAOVERLAPPED совместима со структурой OVERLAPPED для Win32:

typedef struct _WSAOVERLAPPED { DWORD

Internal;

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

DWORD

InternalHigh;

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

DWORD

Offset;

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

DWORD

OffsetHigh;

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

WSAEVENT

hEvent;

} WSAOVERLAPPED, LPWSAOVERLAPPED; Internal и InternalHigh

Резервное поле, которое используется объектом, вовлеченным в совмещенные операции ввода/вывода. Для IFS-провайдеров это поле используется базовой операционной системой (IFS - Installable File System - инсталлируемая файловая система).



Offset и OffsetHigh

Поле зарезервировано для сервис-провайдеров.

hEvent

Если совмещенные операции ввода/вывода запущены в отсутствии программ завершения (lpCompletionRoutine равно NULL), тогда это поле должно содержать дескриптор (указатель) объекта WSAEVENT. В противном случае (lpCompletionRoutine не равно NULL) клиент может использовать это поле как сочтет нужным.

Приоритетные данные могут доставляться пользователю независимо от обычной информации. Для коммуникационных протоколов, где предусмотрена пометка данных как срочные (например, TCP, позволяющий доставку срочной информации в общем потоке данных) система извлекает приоритетную информацию из общего потока и запоминает отдельно.

Пользователь может определить, имеется ли приоритетная непрочитанная информация, используя процедуру WSPIoctl(SIOCATMARK). Для протоколов, где положение приоритетной информации в общем потоке имеет смысл, сервис-провайдер обеспечивает указатели, определяющие это положение. Для таких протоколов допускается обработка приоритетных данных в общем информационном потоке. Это достигается путем установки опции соединителя SO_OOBINLINE (OOB - Out-Of-Band). Для других протоколов, где блоки приоритетных данных независимы от общего информационного потока, попытка установить опцию SO_OOBINLINE вызовет ошибку. Приложение может использовать команду SIOCATMARK WSPIoctl для определения наличия непрочитанных блоков приоритетной информации. При запрещении SO_OOBINLINE (disabled - значение по умолчанию):

Сервис-провайдер WinSock сообщает клиенту о FD_OOB событиях, если клиент зарегистрирован для этого с помощью процедуры WSPAsyncSelect, точно таким же образом FD_READ используется для сообщения о присутствии обычных данных. Таким образом, FD_OOB посылается, когда поступает приоритетная информация, а также когда данные прочитаны с использованием флага MSG_OOB, в условиях присутствия приоритетных данных, подлежащих чтению. Сообщение FD_READ для приоритетных данных не посылается.

Сервис-провайдер WinSock возвращает соответствующий набор exceptfds при выполнении процедуры WSPSelect, если приоритетные данные присутствуют в очереди соединителя.



Клиент может вызвать WSPRecv с MSG_OOB для чтения блока приоритетных данных.

Клиент может вызвать процедуру WSPRecv без MSG_OOB для чтения потока обычной информации. Блок приоритетных данных не может появиться в потоке обычных данных. Если приоритетные данные остаются после запроса WSPRecv, сервис-провайдер дает сообщение клиенту с помощью флага FD_OOB или через exceptfds при использовании запроса B>WSPSelect.

Для протоколов, где приоритетные данные находятся в потоке обычных данных, одного запроса WSPRecv недостаточно. Один вызов WSPRecv вернет обычные данные до маркера, и потребуется второй запрос WSPRecv для чтения данных после маркера.

При разрешении SO_OOBINLINE (enabled):

Сообщение FD_OOB не посылается для приоритетных данных, а процедуры WSPSelect и WSPAsyncSelect рассматривают эти данные как обычные, о типе информации можно судить по readfds соединителя или по сообщению FD_READ, соответственно.

Клиент не может осуществлять вызов WSPRecv с флагом MSG_OOB для чтения блока приоритетных данных - в противном случае будет получен код ошибки WSAEINVAL.

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

Программа WSPAsyncSelect прекрасно приспособлена для выявления приоритетных данных, когда SO_OOBINLINE находится в состоянии выключено.

Использование соединителя несколькими процессами одновременно организовано следующим образом. Базовый процесс для получения специальной структуры WSAPROTOCOL_INFO вызывает WSPDuplicateSocket. Эта процедура для передачи структуры другому процессу использует межпроцессный механизм коммуникаций (IPC). Последний процесс использует структуру WSAPROTOCOL_INFO при обращении к WSPSocket. Дескриптор соединителя, полученный в результате этой операции, будет дополнительным дескриптором исходного соединителя, который с этого момента может использоваться двумя процессами.



Такой механизм разработан для того, чтобы удовлетворить как требованиям однопроцессной версии Windows 3.1, так и многопроцессным вариантам Windows 95 и NT. Следует иметь в виду, что совместное использование соединителей несколькими процессами возможно и без использования WSPDuplicateSocket, так как дескриптор соединителя доступен для всех процессов.

Когда формируется дескриптор нового соединителя IFS-провайдер должен вызвать WPUModifyIFSHandle, а не-IFS-провайдер должен вызвать WPUCreateSocketHandle (IFS - Installable File System).

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

Контроль состояния используемых совместно соединителей осуществляется посредством WSPAsyncSelect и WSPEventSelect. Вызов одного из указанных запросов с одним из дескрипторов соединителя в качестве параметра, аннулирует любую предшествующую регистрацию событий для указанного соединителя, вне зависимости от того, какой из дескрипторов использован для новой регистрации. Таким образом, нельзя для процесса A иметь FD_READ-события, а для процесса B получать FD_WRITE-события.

Процесс может вызвать WSPCloseSocket для дублирующего соединителя и старый дескриптор будет ликвидирован, в то время как сам соединитель, ему соответствующий, останется открытым вплоть до выполнения процедуры WSPCloseSocket.

Два или более дескрипторов могут соответствовать одному и тому же соединителю и использоваться независимо для операций ввода/вывода. Однако, интерфейс WinSock не осуществляет какого-либо контроля за доступом, задача координации совместного использования соединителя является объектом ответственности самих процессов.

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

В настоящее время многоточечные приложения (напр., IP-мультикастинг, ST-II, T.120, ATM UNI, и т.д.) значительно различаются по способу подключения узла к многоточечной сессии. Для декларации различных многоточечных атрибутов протокола в WinSock 2 используется структура WSAPROTOCOL_INFO. Просматривая эти атрибуты, программист может узнать, какие соглашения должны быть реализованы.



В плоскости управления существует два типа различных сессий: rooted и non-rooted (корневые и некорневые). В случае корневого управления существует участник, называемый c_root, который отличается от всех остальных членов многоточечной сессии, которые называются c_leaf (периферийные члены группы). Участник сессии c_root должен оставаться в списке участников на протяжении всей многоточечной сессии, так как без его участия сессия будет прервана. c_root обычно инициирует многоточечную сессию путем установления связей с участниками типа c_leaf. c_root может вводить членов в группу, но c_leaf может подключиться к c_root позднее.

Для некорневой плоскости управления, все участники многоточечной сессии являются периферийными узлами и не существует какого-то выделенного узла. Каждый c_leaf должен подключиться к многоточечной сессии, которая либо существует всегда (как в случае IP-мультикастинг адреса), или создана за счет какого-то внешнего механизма. При другом подходе c_root по-прежнему существует, но принадлежит сети в целом (не является одним из участников сессии). Так как корневой узел существует, некорневая управляющая плоскость может рассматриваться как неявно корневая. Примерами такого рода неявно корневых схем являются система IP-мультикастинга многоточечные блоки управления (Multipoint Control Unit - MCU) в H.320-видеоконференциях и т.д.

В плоскости данных существует два стиля передачи информации: rooted и non-rooted (корневой и некорневой). В корневой плоскости данных существует выделенный участник, называемый d_root. Обмен данными происходит исключительно между d_root и остальными участниками многоточечной сессии, которые называются d_leaf. Трафик может быть однонаправленным или двунаправленным. Данные, посланные d_root, будут доставлены всем d_leaf, в то время как данные, отправленные d_leafs попадут только в d_root. В случае корневой плоскости данных не существует потока данных между периферийными узлами группы (d_leaf).

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



В структуре WSAPROTOCOL_INFO имеется три поля атрибутов для выделения различных схем, используемых в плоскостях управления и данных:

XP1_SUPPORT_MULTIPOINT = 1 указывает на то, что этот протокол поддерживает многоточечные коммуникации, а последующие два поля имеют смысл.

XP1_MULTIPOINT_CONTROL_PLANE определяет, является ли плоскость управления корневой ( = 1) или не корневой ( = 0).

XP1_MULTIPOINT_DATA_PLANE указывает, является ли плоскость данных корневой ( = 1) или некорневой ( = 0).

В определенные моменты соединители, включенные в многоточечную сессию, могут по своему поведению отличаться от соединителей типа точка-точка. Так соединитель вида d_leaf в корневой плоскости данных может только посылать информацию участнику d_root. Это вызывает необходимость для клиента быть способным заявить об этом на стадии формирования соединителя. Делается это с помощью четырех многоточечных атрибутных флагов, которым присваивается определенное значение через параметр dwFlags в WSPSocket:

SA_FLAG_MULTIPOINT_C_ROOT служит для создания соединителя, работающего как c_root. Это разрешено, если в WSAPROTOCOL_INFO указано, что имеет место контекст корневой плоскости управления.

WSA_FLAG_MULTIPOINT_C_LEAF предназначен для генерации соединителя, работающего как c_leaf. Это возможно, если XP1_SUPPORT_MULTIPOINT присутствует в соответствующей записи WSAPROTOCOL_INFO.

WSA_FLAG_MULTIPOINT_D_ROOT предполагает формирование соединителя, работающего как d_root. Это позволено, если в WSAPROTOCOL_INFO указано, что имеет место контекст корневой плоскости данных.

WSA_FLAG_MULTIPOINT_D_LEAF служит для создания соединителя, работающего как d_leaf. Это допускается, если XP1_SUPPORT_MULTIPOINT присутствует в соответствующей записи WSAPROTOCOL_INFO.

Когда создается многоточечный соединитель, один из двух флагов плоскости управления и один из двух флагов плоскости данных должны быть заданы в параметре dwFlags WSPSocket. Таким образом, при создании многоточечного соединителя могут быть реализованы четыре возможности: c_root/d_root, c_root/d_leaf, c_leaf/d_root, или c_leaf /d_leaf.



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

При использовании мультикастинга обычно необходимо специфицировать способ реализации сессии. Среди параметров сессии важную роль играет число вовлеченных сетевых сегментов. Для регулирования этого числа используется команда SIO_MULTICAST_SCOPE WSPIoctl. Нулевое значение числа сетевых сегментов означает, что мультикастинг пакеты не покинут пределы ЭВМ и могут попадать только во внутренние соединители. Значение единица (число по умолчанию) указывает, что мультикастинг-пакеты не могут выйти за пределы маршрутизатора локальной сети. Большие величины позволят распространение сообщений, проходящих соответствующее число маршрутизаторов. Этот код идентичен параметру времени жизни (TTL) в IP-мультикастинге.

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

В схемах для корневой плоскости периферийные узлы добавляются в многоточечную группу одним из двух способов. В первом методе, корень использует WSPJoinLeaf для инициализации соединения с периферийным узлом и приглашает его быть участником сессии. Со стороны периферийного узла приложение должно создать c_leaf-соединитель и использовать WSPListen для установки его в режим ожидания (listen). Периферийный узел получит сообщение FD_ACCEPT, которое означает приглашение присоединиться к многоточечной сессии, и может объявить о своем желании подключиться путем вызова WSPAccept. Корневое приложения получит сообщение FD_CONNECT, когда операция подключения к группе завершена.

Во втором методе роли меняются. Корневой клиент создает соединитель c_root и переходит в режим ожидания (listen). Периферийный узел, желающий присоединиться к сессии, создает соединитель c_leaf и запускает WSPJoinLeaf, чтобы инициализировать соединение и доступ. Корневой клиент получает FD_ACCEPT, когда приходит запрос доступа, и принимает периферийный узел в группу посредством запроса WSPAccept. Периферийный узел получает FD_CONNECT, когда он принят в группу. Для случая IP-мультикастинга это эквивалентно опции соединителя IP_ADD_MEMBERSHIP. Читателей, знакомых с использованием несвязного UDP-протокола в IP-мультикастинге, может смутить семантика, ориентированная на соединение, присутствующая здесь. В частности указание на то, что используется запрос WSPJoinLeaf для соединителя UDP и ожидание сообщения FD_CONNECT могут вызвать недоразумение. Существуют уже, однако, прецеденты использования такой семантики для протоколов, не ориентированных на соединение. Разрешено и иногда полезно, например, использовать процедуру WSPConnect для UDP-соединителей. Общим результатом применения семантики, ориентированной на соединение для несвязных соединителей, является ограничение на то, как эти соединители могут использоваться. UDP-соединитель, используемый в WSPJoinLeaf, будет иметь определенные ограничения, а ожидание сообщения FD_CONNECT (которое в этом случае указывает на посылку соответствующего IGMP-сообщения) является одним из таких ограничений. Существует три случая, когда клиент может использовать WSPJoinLeaf:

При работе в качестве многоточечного сервера (root), приглашая новый периферийный узел принять участие в сессии.

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

При работе в качестве периферийного узла, запрашивая подключение к некорневой многоточечной сессии (например, IP-мультикастинг).

Как было упомянуто ранее, WSPJoinLeaf используется для присоединения периферийного узла к многоточечной сессии. WSPJoinLeaf имеет те же параметры и семантику, что и WSPConnect за исключением того, что он возвращает дескриптор соединителя (как и WSPAccept), и имеет дополнительный параметр dwFlags. Параметр dwFlags показывает, будет ли соединитель работать только в режиме чтения, только в режиме записи или в обоих режимах. Только многоточечный соединитель может использоваться в качестве входного параметра s этой процедуры. Если многоточечный соединитель находится в неблокирующем состоянии, полученный дескриптор соединителя нельзя будет использовать до тех пор, пока не будет получено FD_CONNECT. Корневое приложение в многоточечной сессии может вызвать WSPJoinLeaf один или более раз для того, чтобы добавить новые узлы к текущей многоточечной сессии.

Параметры дескриптора соединителя, присланного WSPJoinLeaf, варьируются в зависимости от того, является ли дескриптор c_root или c_leaf. Для c_root соединителя, параметр name означает имя определенного периферийного узла, который должен быть добавлен, а возвращенный дескриптор соединителя является c_leaf и соответствует вновь добавленному периферийному узлу. Некоторые многоточечные приложения могут позволять этому соединителю “постороннее” общение с корневым сервером.

При вызове WSPJoinLeaf для соединителя c_leaf, параметр name содержит адрес корневого приложения (для схемы корневого управления) или существующей многоточечной сессии (некорневая схема управления), и возвращенный дескриптор соединителя является тождественным по отношению ко входному дескриптору соединителя. В корневой схеме управления, корневой клиент должен поставить свой c_root соединитель в режим ожидания с помощью WSPListen. При запросе периферийного узла о присоединении к группе присылается стандартное сообщение FD_ACCEPT. Корневой клиент использует для подключения нового периферийного узла обычную процедуру WSPAccept. Запрос WSPAccept присылает дескриптор соединителя c_leaf, точно также как и WSPJoinLeaf.



Многоточечный корневой клиент является ответственным за прерывание сессии. Такое приложение может использовать WSPShutdown или WSPClosesocket для соединителя c_root, чтобы прислать всем членам группы соединителей c_leaf сообщение FD_CLOSE.

Рассмотрим семантическое отличие многоточечных и обычных соединителей. В плоскости управления имеется существенное семантическое отличие между соединителями c_root и обычными соединителями точка-точка:

1. Cоединитель c_root может использоваться в процедуре WSPJoinLeaf для подключения новых периферийных узлов;



2. Постановка соединителя c_root socket в режим ожидания (путем вызова WSPListen) не препятствует тому, чтобы соединитель c_root использовался оператором WSPJoinLeaf для добавления в список участников нового периферийного узла или для посылки или получения информации;



3. Закрытие соединителя c_root вызовет отправку всем сопряженным соединителям c_leaf сообщения FD_CLOSE.

Не существует какого-либо семантического различия между соединителем c_leaf и традиционным соединителем в плоскости управления, за исключением того, что соединитель c_leaf может использоваться процедурой WSPJoinLeaf, а использование соединителя c_leaf в WSPListen указывает на то, что должны восприниматься только запросы многоточечного соединения.

В плоскости данных семантическое отличие между соединителями d_root и традиционными соединителями заключается в следующем:

1. Данные, посланные на соединитель d_root, будут доставлены всем членам группы узлов, участвующих в многоточечном обмене;



2. Данные, полученные соединителем d_root, могут поступить от любого участника многоточечного обмена.

Соединитель d_leaf в корневой плоскости данных не имеет каких-либо семантических отличий от традиционных соединителей, однако, в некорневой плоскости данных информация, посланная на соединитель d_leaf, поступит ко всем периферийным узлам группы. Данные могут передаваться любым участником многоточечной сессии. Информация о том, находится ли соединитель d_leaf в корневой или некорневой плоскости данных, хранится в структуре соединителя WSAPROTOCOL_INFO.



Сводные данные по опциям Winsock 2 вместе с их значениями по умолчанию приведены в таблице 7.11 (см. также описания WSPGetSockOpt и WSPSetSockOpt). Сервис-провайдеры Windows должны распознавать все эти опции.

Таблица 7.11. Опции Winsock 2.

Опция	Тип	Назначение	Значение по умолчанию
SO_ACCEPTCONN	BOOL	Соединитель в режиме WSPListen.	FALSE, если WSPListen не была выполнена
SO_BROADCAST	BOOL	Соединитель сконфигурирован для передачи широковещательных сообщений.	FALSE
SO_DEBUG	BOOL	Разрешен отладочный режим.	FALSE
SO_DONTLINGER	BOOL	Если истинно, опция SO_LINGER запрещена.	TRUE
SO_DONTROUTE	BOOL	Маршрутизация запрещена.	FALSE
SO_ERROR	int	Возвращает статус ошибки и осуществляет сброс.	0
SO_GROUP_ID	GROUP	Идентификатор группы, к которой принадлежит соединитель.	NULL
SO_GROUP_ PRIORITY	int	Относительный приоритет для соединителей членов группы.	0
SO_KEEPALIVE	BOOL	Послано сообщение “еще жив”.	FALSE
SO_LINGER	struct linger	Возвращается текущее значение опции LINGER.	l_onoff = 0
SO_MAX_MSG_SIZE	int	Максимальный размер сообщения для соединителей, ориентированных на обмен сообщениями. Не имеет смысла для соединителей, ориентированных на потоки данных.	Зависит от реализации
SO_OOBINLINE	BOOL	Приоритетная информация получена в потоке обычных данных.	FALSE
SO_PROTOCOL_INFO	struct WSAPROTOCOL_INFO	Описание протокола для заданного соединителя.	Зависит от протокола
SO_RCVBUF	int	Размер буфера для приема.	Зависит от реализации
SO_REUSEADDR	BOOL	Адрес, к которому подключен соединитель, может быть использован другими.	FALSE
SO_SNDBUF	int	Размер буфера для отправки	Зависит от реализации
SO_TYPE	int	Тип соединителя (т.е. SOCK_STREAM).	Как было при создании socket
PVD_CONFIG	char FAR *	Структурный объект, содержащий информацию о конфигурации сервис-провайдера.	Зависит от реализации
TCP_NODELAY	BOOL	Запрещает алгоритм Нагля.	Зависит от реализации

<


/p> В таблице 7.12 приведен список ioctl-кодов команд для соединителей.



Таблица 7.12. ioctl-

коды команд для соединителей (Winsock 2)

Код операции	Тип входа	Тип выхода	Значение
FIONBIO	unsigned long	Не использ.	Разрешает или запрещает неблокирующий режим соединителя.
FIONREAD	Не используется	unsigned long	Определяет объем информации, который может быть считан с соединителя автоматически.
SIOCATMARK	Не использ.	BOOL	Определяет, будут ли считаны все приоритетные данные.
SIO_ASSOCIATE_HANDLE	Зависит от API	Не использ.	Связывает соединитель с заданным дескриптором интерфейса-партнера.
SIO_ENABLE_CIRCULAR_QUEUEING	Не использ.	Не использ.	Разрешает организацию циклической очереди.
SIO_FIND_ROUTE	struct sockaddr	Не использ.	Запрашивает маршрут до указанного адреса.
SIO_FLUSH	Не использ.	Не использ.	Аннулирует содержимое выходной очереди.
SIO_GET_BROADCAST_ADDRESS	Не использ.	struct sockaddr	Возвращает протокольно-зависимый адрес, предназначенный для использования с WSPSendTo
SIO_GET_QOS	Не использ.	QOS	Возвращает текущую спецификацию QOS для соединителя.
SIO_GET_GROUP_QOS	Не использ.	QOS	Возвращает текущую спецификацию QOS для группы, к которой принадлежит соединитель.
SIO_MULTIPOINT_LOOKBACK	BOOL	Не использ.	Определяет, будут ли данные, посланные в ходе многоточечной сессии, получены соединителем на локальной ЭВМ.
SIO_MULTICAST_SCOPE	int	Не использ.	Определяет режим мультикастинг-обмена.
SIO_SET_QOS	QOS	Не использ.	Устанавливает новую спецификацию качества сервиса для соединителя.
SIO_SET_GROUP_QOS	QOS	Не использ.	Устанавливает новую спецификацию для группы, к которой принадлежит соединитель.
SIO_TRANSLATE_HANDLE	int	Зависит от API	Возвращает соответствующий дескриптор соединителя s, который верен для контекста интерфейса.

В таблице 7.13 представлены основные характеристики базовых SPI (Service Provider Interfaces) процедур передачи данных для Winsock 2.





Таблица 7.13.

Базовые SPI процедуры передачи данных Winsock 2

WSPAccept	Входное соединение подтверждается и создается соединитель. Исходный соединитель возвращается в режим ожидания (listening). Эта процедура позволяет условное создание соединителей и их включение в группу.
WSPAsyncSelect	Выполняет WSPSelect в асинхронном режиме.
WSPBind	Присваивает локальное имя безымянному соединителю.
WSPCancelBlockingCall	Аннулирует блокирующую процедуру WinSock.
WSPCloseSocket	Удаляет соединитель из справочной таблицы.
WSPConnect	Инициализирует соединение для специфицированного соединителя. Эта процедура позволяет обмениваться данными о соединении и QOS.
WSPDuplicateSocket	Возвращает структуру WSAPROTOCOL_INFO, которая может быть использована для формирования нового дескриптора соединителя, используемого несколькими процессами.
WSPEnumNetworkEvents	Выявляет факт появления сетевых событий.
WSPEventSelect	Связывает сетевые события с объектами события.
WSPGetOverlappedResult	Сообщает состояние завершения процесса при совмещении операций ввода/вывода.
WSPGetPeerName	Возвращает имя партнера, подключенного к заданному соединителю.
WSPGetSockName	Возвращает локальный адрес, к которому подключен заданный соединитель.
WSPGetSockOpt	Возвращает опцию заданного соединителя.
WSPGetQOSByName	Сообщает параметры QOS на основе названия известной сетевой услуги.
WSPIoctl	Обеспечивает управление соединителем.
WSPJoinLeaf	Подключает периферийный узел к многоточечному обмену.
WSPListen	Организует процесс ожидания (Listen) на заданном соединителе.
WSPRecv	Получает данные от подключенного или неподключенного соединителя. Эта процедура реализует прием рассеянных данных или массивов для соединителей, работающих в режиме совмещения операций ввода/вывода, и использует flags в качестве параметра IN OUT.
WSPRecvDisconnect	Завершает операции приема для соединителя и возвращает информацию об отключении для соединителей, ориентированных на соединение.
WSPRecvFrom	Принимает данные от подключенного или неподключенного соединителя. Эта процедура позволяет работать с рассеянными данными в совмещенном режиме ввода/вывода, и использует flags в качестве параметра IN OUT.
WSPSelect	Выполняет синхронное мультиплексирование.
WSPSend	Посылает данные подключенному соединителю. Эта процедура позволяет работать с рассеянными данными при совмещении операций ввода/вывода.
WSPSendDisconnect	Запускает процесс отключения соединителя и опционно посылает уведомление об отсоединении.
WSPSendTo	Посылает данные в подключенному или неподключенному соединителю. Эта процедура позволяет работать с рассеянными данными при совмещенных операциях ввода/вывода.
WSPSetSockOpt	Запоминает опции, соответствующие определенному соединителю.
WSPShutdown	Прерывает частично дуплексное соединение.
WSPSocket	Процедура формирования соединителя, которая использует в качестве входной структуру WSAPROTOCOL_INFO и позволяет использовать созданный соединитель для совмещенных операций. Позволяет создавать группы соединителей.
WSPStartup	Инициализирует сервис-провайдера WinSock.
WPUCloseEvent	Ликвидирует дескриптор объекта события
WPUCloseSocketHandle	Ликвидирует дескриптор соединителя, сформированный WinSock DLL
WPUCreateEvent	Формирует новый объект события
WPUCreateSocketHandle	Создает новый дескриптор соединителя для не-IFS провайдеров
WPUGetProviderPath	Присылает путь к DLL для специфицированного провайдера
WPUModifyIFSHandle	Присылает модифицированный дескриптор IFS из WinSock DLL
WPUPostMessage	Выполняет стандартную процедуру PostMessage так, чтобы обеспечить обратную совместимость
WPUQueryBlockingCallback	Присылает указатель на вход в цикл псевдоблокировки
WPUQuerySocketHandleContext	Присылает значение контекста соединителя (только для провайдеров, не поддерживающих IFS)
WPUQueueApc	Ставит пользователя в очередь APC для указанной сессии
WPUSetEvent	Устанавливает объект события
WSCDeinstallProvider	Отмена регистрации сервис-провайдера
WSCEnumProtocols	Получение информации о доступных транспортных протоколах
WSCInstallProvider	Регистрация нового сервис-провайдера

Содержание раздела

---

---

---

Главная сайта

---