Программирование в сетях Windows. Э. Джонс, Д. Оланд
 Скачать 2.88 Mb.
|
|
LPDWORD lpHaxCollectionCount, LPDWORD lpCollectDataTimeout Параметр hNamedPipe — это описатель именованного канала, возвращен- ный функцией CreateNamedPipe или CreateFile. Параметр ipMode задает ре- жим работы именованного канала. Параметр IpMaxCollectionCount содержит максимальное число байтов, которые будут накоплены на компьютере кли- ента перед передачей на сервер. Параметр lpCollectDataTimeout определяет максимальное время в миллисекундах, которое может пройти, до того как удаленный клиент передаст информацию по сети. Функция GetNamedPipelnfo возвращает размер буферов и максимальное количество экземпляров канала: BOOL GetNamedPipeInfo( HANDLE hNamedPipe, LPDWORD lpFlags, LPDWORD IpOutBufferSize, LPDWORD IpInBufferSize, LPDWORD lpMaxInstances Параметр hNamedPipe — это описатель именованного канала, возвращен- ный функцией CreateNamedPipe или CreateFile. Параметр lpFlags указывает вид и режим работы именованного канала и определяет, является ли он сервером или клиентом. Параметры IpOutBufferSize и IpInBufferSize содержат размер исходящего и входящего внутренних буферов, ipMaxInstance — мак- симальное количество экземпляров канала. Последняя функция — PeekNamedPipe, позволяет просмотреть находящи- еся в канале данные, не удаляя их из внутреннего буфера. Например, прове- рить наличие входящих данных и избежать блокировки функции ReadFile. Кроме того, эта функция полезна, если необходимо проверить данные перед получением: приложение может скорректировать размер своего буфера в за- висимости от размера входящего сообщения. Функция PeekNamedPipe on- j ределена так: BOOL PeekNamedPipe( HANDLE hNamedPipe, LPVOID lpBuffer, DWORD nBufferSize, LPDWORD lpBytesRead, LPDWORD lpTotalBytesAvail, LPDWORD lpBytesLeftThlsHessage Параметр hNamedPipe — это описатель именованного канала, возвращен-» ный функцией CreateNamedPipe или CreateFile. Параметры lpBuffer и nBuf- ferSize определяют адрес и размер принимающего буфера. Параметр 1р- BytesRead содержит количество байтов, считанных из канала в буфер lpBuffer-, lpTotalBytesAvail — общее количество байтов, которое можно считать из ка- Г Л А В А 4 Именованные каналы 101 нала; ipBytesLeftTbisMessage — оставшееся количество байт в сообщении, если канал работает в режиме сообщений. Если сообщение не помещается в бу- фер ipBuffer, данный параметр содержит оставшееся количество байт. Если именованный канал работает в побайтовом режиме, параметр всегда содер- жит 0. Платформа и производительность В базе знаний Microsoft, к которой можно обратиться по адресу http : //sup- port.microsoft.com/support/search, описаны следующие проблемы и ограни- чения. Н Q100291 — ограничения на названия именованных каналов. Канал \\.\Pipe\Mypipes\Pipel невозможно создать при наличии канала \\.\Pipe\Mypipes. Название существующего канала нельзя использовать в качестве пути к другому каналу. И Q119218 — в и м е н о в а н н ы й канал м о ж н о записать только 64 кб данных. Если именованный канал работает в режиме сообщений, то при попытке записать данные, используя буфер большего размера, функция WriteFile вернет значение FALSE, а функция GetLastError — ошибку ERRORMOREDATA. Ш Q110148 — ф у н к ц и и WriteFile или ReadFile возвращают ошибк у ERROR_ INVALID PARAMETER, если при работе с именованным каналом используется перекрытый ввод-вывод. Возможная причина такой ошиб- ки — поля Offset и OffsetHigh структуры OVERLAPPED не равны 0. • Q180222 — функция WaitNamedPipe и ошибка с кодом 253 в Win- dows 95- Если в Windows 95 в качестве первого параметра функции Wait- NamedPipe передать неверное название канала, то функция GetLastError вернет ошибку с кодом 253, которой нет в списке возможных ошибок данной функции. Если то же самое проделать в Windows NT 4, код ошиб- ки изменится на 1б1 (ERROR_BAD PATHNAME). Обрабатывайте ошибку 253 также, как 161. • Q141709 — максимум 49 с о е д и н е н и й с о д н о й р а б о ч е й станции. Если сервер именованных каналов создает 49 каналов, клиент на удален- ном компьютере не может соединиться со следующим (50-м и далее) эк- земпляром именованного канала на этом сервере. • Q126645 — ошибка Access Denied (доступ запрещен) при откры- тии именованного канала из службы. Если служба, запущенная под учетной записью Local System, попытается открыть именованный канал на компьютере с Windows NT, будет выдана ошибка Access Denied (с ко- дом 5). Резюме ои главе мы рассмотрели технологию именованных каналов, которые Доставляют простую архитектуру клиент-сервер для надежной передачи 102 ЧАСТЬ I Устаревшие сетевые API данных. Для передачи данных по сети данный интерфейс использует пере- направитель Windows. Основное преимущество именованных каналов — они позволяют воспользоваться встроенными возможностями защиты Win- dows NT и Windows 2000. Эта глава завершает первую часть книги, в которой мы обсудили вопро- сы передачи данных средствами перенаправителя Windows. Во второй час- ти мы рассмотрим технологию Winsock, которая позволяет обмениваться данными напрямую по транспортному протоколу. Ч А С Т Ь I ИНТЕРФЕЙС ПРИКЛАДНОГО ПРОГРАММИРОВАНИЯ WINSOCK Вторая часть книги посвящена программированию средствами Winsock на платформах Win32. Winsock — это сетевой интерфейс прикладного про- граммирования, а не протокол, основной интерфейс доступа к разным ба- зовым сетевым протоколам, реализованный на всех платформах Win32. Ин- терфейс Winsock унаследовал многое от реализации Berkeley (BSD) Sockets на платформах UNIX, работающих с множеством сетевых протоколов. В сре- дах Win32 он стал абсолютно независимым от протокола, особенно с выпус- ком версии Winsock 2. В следующих трех главах описаны основные характеристики протоколов и интерфейса Winsock, включая адресацию для каждого протокола и пример простого клиента и сервера Winsock. Мы рассмотрим новые технологичес- кие возможности интерфейса Winsock 2: поставщики службы транспорта, поставщики пространства имен и качество обслуживания (Quality of Service, V°S). В описании этих технологий есть некое несоответствие: хотя они и включены в спецификацию Winsock 2 и этот интерфейс поддерживается на всех современных платформах Win32 (за исключением ОС Windows СЕ), не се указанные в документации возможности реализованы на каждой из плат- форм. Об этих ограничениях мы упомянем дополнительно. Для изучения той части книги вы должны обладать базовыми знаниями о Winsock (или етах BSD) и знать клиент-серверную терминологию Winsock. Г Л А В А Сетевые протоколы Основная цель разработки спецификации Winsock 2 — создать независимый от протокола транспортный интерфейс. К его неоспоримым преимуществам относится предоставление единого привычного интерфейса сетевого про- граммирования для различных транспортов сети. Впрочем, знать характе- ристики сетевых протоколов вам все же не помешает. В этой главе описаны различные аспекты работы с конкретными протоколами, а также некоторые основные сетевые правила. Кроме того, мы расскажем, как программно по- лучить у Winsock сведения о протоколе, опишем основные шаги создания со- кета для конкретных протоколов. Характеристики протоколов В этом разделе мы рассмотрим основные характеристики распространен- ных транспортных протоколов, а также то, как протокол функционирует в приложении. Протокол, ориентированный на передачу сообщений Протокол называют ориентированным на передачу сообщений, если для каждой команды записи он передает байты по сети в отдельном сообщении. Это также означает, что приемник получит данные в виде отдельного сооб- щения отправителя. Таким образом, приемник получит только одно сообще- ние. Например, на рис. 5-1 рабочая станция слева отправляет сообщения по 128,64 и 32 байта рабочей станции справа. Принимающая рабочая станция дает три команды чтения с 256-байтным буфером. На каждый запрос после- довательно возвращается 128, 64 и 32 байта. Первый запрос чтения не воз- вращает сразу три пакета, даже если все они уже получены. Таким образом, сохраняются границы сообщений, что часто необходимо для обмена струк- турированными данными. Например, в сетевой игре каждый участник от- правляет другим игрокам пакет данных, с информацией о своей позиции. Программа, лежащая в основе такого обмена данными, очень проста: игрок запрашивает пакет данных и получает от другого участника игры именно один пакет данных с информацией о позиции другого игрока. Протокол, не сохраняющий границы сообщений, обычно называют про- токолом, основанным на потоке. Учтите, что термин «основанный на пото- ке» (stream-based) часто употребляют некорректно, подразумевая дополни- тельные характеристики. Потоковая служба непрерывно передает данные: Г Л А В А 5 Сетевые протоколы 105 получатель считывает столько данных, сколько имеется в наличии, незави- симо от границ сообщений. Для отправителя это означает, что система мо- жет разбивать исходное сообщение на части или объединять несколько со- общений, чтобы сформировать больший пакет данных. На приемнике сете- вой стек считывает данные по мере их поступления и буферизует для целе- вого процесса. Когда процесс запрашивает данные, система возвращает мак- симально возможное количество данных, не переполняющее буфер, предо- ставленный клиентским вызовом. Платформа Win32 Сетевой стек 32 байта 64 байта 128 байт Network Stack 128 байт | t 64 байта | t 32 байта | Платформа Win32 Сеть Рис. 5-1. Службы дейтаграмм На рис. 5-2 отправитель передает пакеты данных по 128, 64 и 32 байт, однако стек локальной системы может принимать данные более крупными пакетами. В данном случае последние два пакета передаются вместе. Платформа Win32 Сетевой стек 32 байта 64 байта 128 байт Сетевой стек 224 байта Платформа Win32 Сеть Рис. 5-2. П о т о к о в ы е с л у ж б ы Решение объединить дискретные пакеты данных зависит от нескольких факторов, например, от максимального размера блока передаваемой инфор- мации или применения алгоритма Nagle. В отношении TCP/IP применение a gle заключается в том, что узел накапливает данные перед отправкой: ждет, пока накопится достаточно данных или истечет указанный тайм-аут. Парт- е Р этого узла, перед тем как отправить узлу уведомление, ожидает исходя- щие данные в течение указанного времени. Это нужно, чтобы партнеру не 1 06 ЧАСТЬ II Интерфейс прикладного программирования Winsock пришлось пересылать пакет данных «порожняком» — только с одним уве- домлением. Отправка большого количества небольших по размеру пакетов данных неэффективна, поскольку влечет существенные издержки из-за мно- гочисленных проверок на наличие ошибок и обмен подтверждениями. Со стороны получателя сетевой стек накапливает поступающие данные для кон- кретного процесса. Если получатель считывает данные, обладая 256-байт- ным буфером, то все 224 байта возвращаются сразу. Если приемник требует считать только 20 байт, система вернет только 20 байт. Псевдопоток Система с ориентированным на передачу сообщений протоколом отправ- ляет данные дискретными пакетами, которые получатель считывает и буфе- ризует в пул так, чтобы получающее приложение считывало порции данных любого размера. Такую схему обмена данными зачастую и называют псевдо- потоком. Понять работу псевдопотока можно, скомбинировав отправителя на рис. 5-1 с получателем на рис. 5-2. Отправитель должен посылать каждый пакет данных по отдельности, но получатель может принимать их как угод- но. В основном, перемещение данных псевдопотоком можно рассматривать как обычный, основанный на потоке, протокол. Обмен данными, с соединением и без него Любой протокол обычно предусматривает и ориентированные, и не ориен- тированные на соединение службы. Первые перед любым обменом данны- ми устанавливают канал связи между двумя участвующими в обмене сторо- нами. Это гарантирует существование маршрута между двумя сторонами и то, что обе стороны будут корректно обмениваться информацией. Впрочем, установление канала связи между двумя участниками влечет до- полнительные издержки. Кроме того, большинство протоколов, ориентиро- ванных на передачу сообщений, гарантируют доставку данных, что еще больше увеличивает издержки, вызванные дополнительными вычислениями для проверки правильности передачи данных. С другой стороны, протокол, не ориентированный на передачу данных, не гарантирует, что приемник фактически принимает данные. Службы, не ориентированные на соедине- ние, схожи с почтовой связью: отправитель адресует письмо определенно- му человеку и опускает его в почтовый ящик. Однако он не знает, существу- ет ли вообще получатель письма, или не помешает ли сильная буря почто- вой службе доставить послание. Надежность и порядок доставки сообщений Надежность и порядок доставки, возможно, самые важные характеристи- ки, которые следует учитывать при проектировании приложения для рабо- ты с определенным протоколом. В большинстве случаев надежность и по- рядок доставки неразрывно связаны с тем, ориентирован протокол на соеди- нение или нет. Надежность, или гарантированная доставка, подразумевает, что каждый байт данных будет доставлен от отправителя указанному полу- Г Л А В А 5 Сетевые протоколы Т07 чателю без изменений. Ненадежный протокол не гарантирует ни доставку каждого байта, ни целостность данных. Также необходимо принять во внимание порядок, в котором данные по- ступают получателю. Протокол, сохраняющий порядок данных, гарантиру- ет что приемник получит эти данные в том порядке, в котором они были отправлены. Соответственно, протокол, не сохраняющий порядок байтов, не дает такой гарантии. При установлении соединения стороны предпринимают дополнитель- ные попытки по формированию свободного канала связи между собой, дабы гарантировать целостность данных и порядок доставки. В большинстве слу- чаев протоколы, ориентированные на соединение, действительно гаранти- руют доставку. Заметьте, что сохранение порядка пакетов не гарантирует автоматичес- ки целостность данных. Конечно, основное преимущество протоколов, не ориентированных на соединение, — это скорость: они не «заботятся» об ус- тановлении виртуального соединения с приемником. Зачем замедлять пере- дачу данных проверкой на ошибки? В общем, протоколы, не ориентированные на соединение, быстрее на порядок, чем протоколы, ориентированные на соединение, — проверки дан- ных на целостность и уведомление об их успешном приеме намного услож- няют отправку даже небольших порций данных. Так что дейтаграммы удоб- ны для передачи не очень важных данных, например, для приложений, ана- логичных уже приводившимуся нами примеру с игрой: каждый игрок может использовать дейтаграммы, чтобы периодически отправлять информацию о своей позиции в игре всем другим игрокам по отдельности. Если один кли- ент пропускает пакет, то он быстро получает другой, что создает видимость непрерывной связи. Корректное завершение работы Корректное завершение работы характерно только для протоколов, ориен- тированных на соединение. При этом одна сторона инициирует завершение сеанса связи, а другая — все еще имеет возможность считывать данные, за- державшиеся в канале связи или сетевом стеке. Ориентированный на соеди- нение протокол, не поддерживающий корректного завершения работы, не- медленно завершает сеанс связи, игнорируя любые данные, которые не были считаны приемником. При использовании TCP каждая сторона соединения должна сначала вы- полнить все необходимые операции, чтобы окончательно завершить сеанс связи. Сторона — инициатор завершения сеанса, отправляет партнеру дей- таграмму с управляющим флагом FIN. Получив эту дейтаграмму, партнер от- правляет управляющий флаг АСК стороне-инициатору, чтобы подтвердить получение флага FIN, но все еще может отправлять данные. Флаг FIN озна- ает, что инициатор завершения сеанса отправлять данные больше не будет. ак только партнер завершит отправку своих данных, он также отправит Ф аг FIN, получение которого инициатор подтверждает флагом АСК. После Го с е а н с связи считается полностью завершенным. 1 08 ЧАСТЬ II Интерфейс прикладного программирования Winsock Широковещание данных Широковещание данных подразумевает их передачу с одной рабочей стан- ции всем остальным рабочим станциям ЛВС. Этой функцией обладают нео- риентированные на соединение протоколы, так как все компьютеры в ЛВС могут получать и обрабатывать широковещательные сообщения. Недостаток широковещательных сообщений — их вынужден обрабаты- вать каждый компьютер. Например, пользователь передает сообщение всем станциям ЛВС, и сетевой адаптер каждого компьютера получает сообщение и помещает его в сетевой стек. Затем стек определяет, какие сетевые прило- жения должны получить это сообщение. Обычно большинству компьютеров в сети не нужны эти данные, и они их отбрасывают. Тем не менее, каждый вынужден тратить время на обработку пакета данных, чтобы проверить, нуж- ны ли они для какого-нибудь приложения. Следствием является высокая ра- бочая нагрузка при широковещании, что может существенно замедлить ра- боту в ЛВС. В общем, маршрутизаторы не транслируют широковещательных пакетов данных. Многоадресное вещание Под многоадресным, вещанием понимается способность одного процесса передавать данные одному или более получателям. Методика присоединения процесса к многоадресному сеансу зависит от применяемого для передачи данных протокола. Например, многоадресная передача по протоколу IP является видоизме- ненной формой широковещания. Для нее необходимо, чтобы все заинтере- сованные в приеме и передаче узлы были членами особой группы. При при- соединении процесса к группе многоадресного вещания на сетевом адапте- ре добавляется фильтр. Он заставляет сетевое оборудование обрабатывать и транслировать по сетевому стеку до соответствующего процесса только дан- ные, предназначенные групповому адресу, к которому присоединился про- цесс. Многоадресная передача часто применяется в приложениях для видео- конференций. Подробнее о программировании многоадресного вещания средствами Winsock — в главе 11. Качество обслуживания Управляя качеством обслуживания (Quality of Service, QoS), приложение может зарезервировать определенную часть пропускной способности сети для моно- польного использования. Рассмотрим для примера воспроизведение видеопо- тока в реальном времени. Для его плавности и четкости видеоданные должны поступать из сети равномерно и с определенной скоростью. В недавнем про- шлом плавное воспроизведение достигалось за счет накапливания видеодан- ных в буфере. Если данные передавались неравномерно, паузы сглаживались кадрами из буфера. QoS позволяет резервировать определенную часть емкос- ти канала связи, чтобы гарантировать равномерную передачу и считывание видеоданных. Теоретически это означает, что за счет использования QoS при- ложение может не буферизовать информацию. QoS посвящена глава 12. Г Л А В А 5 Сетевые протоколы 1(09 фрагментарные сообщения фрагментарные сообщения (partial message) передают только ориентиро- ванные на сообщения протоколы. Предположим, приложению необходимо получить сообщение, а локальный компьютер принял лишь часть данных. Это обычное явление, особенно если компьютер-отправитель передает круп- ные сообщения. У локального компьютера может не хватить ресурсов, что- бы вместить сообщение целиком. На самом деле, большинство ориентиро- ванных на сообщение протоколов налагают разумные ограничения на мак- симально возможный размер дейтаграммы, чтобы такая ситуация не возни- кала часто. Большинство дейтаграммных протоколов поддерживает передачу крупных сообщений, которые требуется переправлять по физической среде несколь- кими блоками. В результате, когда пользовательское приложение попытается прочесть сообщение, фактически будет принят лишь его фрагмент. Если про- токол поддерживает фрагментарные сообщения, читатель уведомляется, что возвращаемые данные — лишь часть сообщения. Иначе базовый сетевой стек пытается сохранить фрагменты сообщения до тех пор, пока сообщение не поступит целиком. Если по какой-либо причине остатки сообщения не будут приняты, большинство ненадежных протоколов, не поддерживающих фраг- ментарные сообщения, просто отбросят неполную дейтаграмму. Маршрутизация Важно учесть, является ли протокол маршрутизируемым. Если да, то между двумя рабочими станциями можно установить канал связи (виртуальный ориентированный на соединение либо канал передачи дейтаграмм), неза- висимо от того, какая сетевая аппаратура их разделяет. Например, компью- тер А находится в отдельной от компьютера В подсети. Между ними распо- ложен маршрутизатор, соединяющий эти подсети. Маршрутизируемый про- токол «знает», что эти компьютеры расположены в разных подсетях, поэто- му направляет пакет данных маршрутизатору, который решает, как лучше пе- реслать данные компьютеру В. Поскольку немаршрутизируемый протокол не способен передавать данные между сетями, маршрутизатор удаляет лю- бые его пакеты. Маршрутизатор не пересылает пакет данных немаршрути- зируемого протокола, даже если его адресат находится в подключенной под- сети. Единственный немаршрутизируемый протокол, поддерживаемый плат- формами Win32 — NetBEUI. Другие характеристики Каждый протокол, поддерживаемый на платформах Win32, обладает специ- фичными или уникальными характеристиками: например, порядком пере- дачи байт или максимально допустимым размером пакета. Однако далеко не е эти характеристики важны для разработки Winsock-приложения. В Win- £. предусмотрен механизм перечисления каждого доступного поставщи- ротокола и опроса его характеристик (он описан разделе «Информация ° протоколе» этой главы). 110 ЧАСТЬ II Интерфейс прикладного программирования Winsock Поддерживаемые протоколы Весьма полезно, что платформы Win32 одновременно поддерживают не- сколько сетевых протоколов. Как уже упоминалось в главе 2, перенаправи- тель Windows гарантирует маршрутизацию сетевых запросов соответствую- щим протоколам и подсистемам. Впрочем, средствами Winsock вы можете написать сетевые приложения, напрямую использующие любой из этих про- токолов. В главе б рассказывается, как происходит адресация компьютеров в сети при помощи протоколов, установленных на рабочей станции. Важно, что Winsock не зависит от протокола: большинство операций схожи при ис- пользовании любого протокола. Впрочем, способы адресации рабочих стан- ций необходимо знать, чтобы определить местоположение и соединиться с сетевым партнером. Сетевые протоколы, поддерживаемые Win32 Платформы Win32 поддерживают разнообразные протоколы. Каждый про- токол обычно способен работать в нескольких режимах. Например, прото- кол IP поддерживает как ориентированные на соединение поточные службы, так и службы дейтаграмм, не ориентированные на соединение. В табл. 5-1 перечислены основные доступные протоколы и некоторые поддерживаемые ими режимы работы. Табл. 5-1. Характеристики доступных протоколов Про- Имя токол Тип сооб- щения Уста- новка соеди- нения Надеж- ность Порядок пакетов Коррект- ное завер- шение сеанса Под- держка широко- вещания Под- QoS держка многоад- ресное™ Макс. размер сообщения (байт) IP MSAFD Поток Да Да TCP MSAFD Сооб- Нет UDP щение RSVP Поток Да TCP RSVP UDP Сооб- Нет щение Нет Да Нет Да Нет Да Нет Да Нет Да Нет Нет Да Нет Да Нет Да Нет Да Нет Без огра- ничений Нет 65467 Да Без огра- ничений Да 65467 IPX/ MSAFD Сооб- Нет Нет Нет Нет SPX nwln- щение kipx [IPX] MSAFD Сооб- Да Да Да Нет nwln- щение kspx [SPX] MSAFD Сооб- Да Да Да Нет nwln- щение kspx [SPX] [псевдо- поток] Да Да Нет 576 Нет Нет Нет Нет Нет Без огра- ничений Нет Без огра- ничений Г Л А В А 5 Сетевые протоколы 1J1 Табл. Про- токол Net- BIOS Apple- Talk j on ATM 5-1. (продолжение) Имя Тип Уста- сооб- новка щения соеди- нения MSAFD Сооб- Да nwln- щение kspx [SPXII] MSAFD Сооб- Да nwln- щение kspx [SPXII] [псевдо- поток] Sequen- Сооб- Да ml Рас- щение kets (после- дователь- ность пакетов) Datag- Сооб- Нет rams щение (дейтаг- раммы) MSAFD Сооб- Да Apple- щение Talk [ADSP] MSAFD Сооб- Да Apple- щение Talk [ADSP] [псевдо- поток] MSAFD Сооб- Да Apple- щение Talk [PAP] MSAFD Поток Нет Apple- Talk [RTMP] MSAFD Поток Нет Apple- Talk [ZIP] MSAFD Поток Да ATM AAL5 Надеж- ность Да Да Да Нет Да Да Да Нет Нет Нет Порядок пакетов Да Да Да Нет Да Да Да Нет Нет Да Коррект- ное завер- шение сеанса Да Да Нет Нет Да Да Да Нет Нет Нет Под- держка широко- вещания Нет Нет Нет Да 1 [SP25] Нет Нет Нет Нет Нет Нет Под- держка многоад- ресности Нет Нет Нет Нет Нет Нет Нет Нет Нет Да OoS Нет Нет Нет Нет Нет Нет Нет Нет Нет Да Макс. размер сообщения (байт) Без oi ра- ничений Без огра- ничений 64 кб (65535) 64 кб (65535) 64 кб (65535) Без огра- ничений 4096 Без огра- ничений Без огра- ничений Без огра- ничений NetBIOS поддерживает отправку дейтаграмм как уникальным, так и групповым клиентам, общее широковещание не поддерживается »<3„ см. след. стр. 1 1 2 ЧАСТЬ II Интерфейс прикладного программирования Winsock Табл. Про- токол , 5 - 1 . Имя N a t i v e A T M (AAL5) Infra- MSAFD red So- Irda ckets [IrDA] {продолжение) Тип сооб- щения Сооб- щение По гок Уста- новка соеди- нения Да Да Надеж- ность Нет Да Порядок пакетов Да Да Коррект- ное завер- шение сеанса Нет Да Под- держка широко- вещания Нет Нет Под- держка многоад- ресное™ Да Нет QoS Да Нет Макс, размер сообщения (байт) Без огра- ничений Без огра- ничений Сетевые протоколы в Windows СЕ В отличие от других платформ Win32, Windows СЕ поддерживает только TCP/IP. Кроме того, Windows СЕ поддерживает только Winsock 1.1, поэтому большинство новых возможностей Winsock 2, описанных в этом разделе, не применимы к данной платформе. Windows СЕ поддерживает NetBIOS поверх TCP/IP при помощи перенаправителя, но не позволяет обращаться к этому протоколу ни через «родной» API-интерфейс NetBIOS, ни через Winsock. Информация о протоколе Winsock 2 позволяет узнать, какие протоколы и с какими характеристиками установлены на рабочей станции. Для каждого рабочего режима протокола существует соответствующая запись каталога в рамках системы. Например, после установки TCP/IP в каталог будут занесены две записи для IP: одна для протокола TCP (надежного, с установлением соединения), вторая — для про- токола UDP (ненадежного, без установления соединения). Узнать об установленных сетевых протоколах можно с помощью функ- ции WSAEnumProtocols: int WSAEnumProtocols ( LPINT lpiProtocols, LPWSAPROTOCOL_INFO lpProtocolBuffer, LPDWORD lpdwBufferLength Она заменила функцию EnumProtocols из Winsock 1.1, применяемую в Windows СЕ. Единственное отличие: WSAEnumProtocols возвращает массив структур WSAPROTOCOLJNFO, a EnumProtocols — массив структур PROTO- COL INFO, содержащий меньше полей, чем структура WSAPROTOCOLJNFO (хотя информация та же). Структура WSAPROTOCOLJNFO определена так: typedef struct _WSAPROTOCOL_INFOW { DWORD dwServiceFlagsi; DWORD dwServiceFlags2; DWORD dwServiceFlags3; DWORD dwServiceFlags4; < ш, Г Л А В А 5 Сетевые протоколы 113 DWORD GUID DWORD WSAPROTOCOLCHAIN int int int int int int int int int DWORD DWORD WCHAR } WSAPROTOCOL_INFOW, dwProviderFlags; Providerld; dwCatalogEntryld; ProtocolChain; iVersion; iAddressFamily; iMaxSockAddr; iMinSockAddr; iSocketType; iProtocol; iProtocolMaxOffset; INetworkByteOrder; ISecurityScheme; dwMessageSize; dwProviderReserved; szProtocol[WSAPROTOCOL_LEN + 1]; FAR * LPWSAPR0TOCOL_INFOW; Инициализация Winsock Перед вызовом любой функции Winsock необходимо загрузить правиль- ную версию библиотеки Winsock. Функция инициализации Winsock — WSAStartup: int WSAStartup(WORD wVersionRequested, LPWSADATA lpWSAData); Первый параметр — версия библиотеки Winsock, которую необхо- димо загрузить. На современных платформах Win32 используется вер- сия 2.2. Единственное исключение — Windows СЕ, поддерживающая только Winsock 1.1. Для загрузки версии Winsock 2.2 укажите значение 0x0202, либо макрос MAKEWORD(2, 2). Верхний байт определяет до- полнительный номер версии, нижний — основной. Второй параметр — структура WSADATA, возвращаемая по заверше- нии вызова. Она содержит информацию о версии Winsock, загружен- ной функцией WSAStartup: typedef struct WSAData { WORD WORD char char unsigned unsigned char FAR short short * wVersion; wHighVersion; szDescription[WSADESCRIPTION_LEN szSystemStatus[WSASYS_STATUS_LEN iMaxSockets; iMaxUdpDg; lpVendorlnfo; > WSADATA, FAR * LPWSADATA; + 1] + 1] Единственная полезная информация, возвращаемая в структуре WSADATA — поля wVersion и wHighVersion. Поля, относящиеся к макси- мальному количеству сокетов и максимальному размеру UDP, следует получать из записи каталога для конкретного протокола. Ранее мы см. след. стр. 114 ЧАСТЬ II Интерфейс прикладного программирования Winsock говорили об этом, когда приводили описание WSAEnumProtocols и воз- вращаемых этой функцией структур. Индивидуальные поля структуры WSADATA таковы: Ш wVersion — версия Winsock, которую предполагает использовать ВЫЗОВ; • wHighVersion — высшая версия Winsock, поддерживаемая загру- женной библиотекой (как правило, то же значение, что и wVersion) Ш szDescription — текстовое описание загруженной библиотеки; Ш szSystemStattis — текстовая строка с соответствующей информа- цией о состоянии или конфигурации; • iMaxSockets — максимальное количество сокетов (пропустите это поле для Winsock 2 и более поздних версий); Ж iMaxUdpDg — максимальный размер дейтаграммы UDP; • ipVendorlnfo — информация об изготовителе (пропустите это поле для Winsock 2 и более поздних версий). По завершении работы с библиотекой Winsock вызовите функцию WSACleanup для выгрузки библиотеки и освобождения ресурсов: int WSACleanup (void); Для каждого вызова WSAStartup необходимо согласованно вызы- вать WSACleanup, так как каждый стартовый вызов увеличивает зна- чение эталонного счетчика ссылок на загруженные Winsock DLL. Что- бы уменьшить значение счетчика, требуется равное количество вы- зовов WSACleanup. Обратите внимание: Winsock 2 полностью совместим со всеми вы- зовами функций Winsock 1.1. Поэтому приложение, написанное для Winsock 1.1, будет работать и с библиотекой Winsock 2- функции Win- sock 1.1 сопоставляются их эквивалентам в Winsock 2. Проще всего задать WSAEnumProtocols с ipProtocolBujfer, равным NULL, и IpdwBufferLength — равным 0. При вызове с WSAENOBUFS произойдет ошиб- ка, однако IpdwBufferLength будет содержать размер буфера, достаточный для возвращения всей информации о протоколах. Вызвав функцию с правиль- ным размером буфера, вы получите несколько структур WSAPROTOCOLJNFO. Просмотрите структуры в цикле и найдите запись протокола с необходимы- ми атрибутами Программа Enum.c на прилагаемом компакт-диске перечис- ляет все установленные протоколы и распечатывает их характеристики. Особенно часто в структуре WSAPROTOCOLJNFO используется поле dw- ServiceFlagsl — битовая маска разных атрибутов протокола. В следующем списке перечислены битовые флаги и действия, которые инициируются, если данный флаг задан. • ХР1 CONNECTIONLESS — протокол передает данные без установления соединения; если флаг не задан — с установлением соединения. * ХР1 GUARANTEED DELIVERY— протокол гарантирует доставку данных получателю. Г Л А В А 5 Сетевые протоколы 115 ж XPl GUARANTEED_ORDER — протокол гарантирует доставку данных в порядке их отправки без дублирования, хотя саму доставку не гаранти- рует. щ XPl MESSAGEORIENTED — протокол обрабатывает границы сообще- ний. ш xpjPSEUDOSTREAM — протокол передает сообщения, но границы сообщений игнорируются приемником. Ш XPl GRACEFULjCLOSE — протокол поддерживает двухфазное заверше- ние сеанса (каждая сторона уведомляется о намерении другой завершить сеанс связи). Если этот флаг не задан, сеанс разрывается без предупреж- дения. щ XPl EXPEDITED DATA — протокол поддерживает обмен срочными (out- of-band) данными т XP1_CONNECT_DATA — протокол поддерживает передачу данных с зап- росом соединения. • XP1DISCONNECTDATA — протокол поддерживает передачу данных с запросом разъединения. Ш ХР 1 SUPPORTBROADCAST — протокол поддерживает механизм широ- ковещания. • XPl SUPPORT MULTIPOINT — протокол поддерживает механизм мно- гоадресной передачи данных. Ш XPl MULTIPOINTCONTROLPLANE — плоскость управления (control plane) маршрутизируется, если флаг не задан — этого не происходит. • ХР 1 _MULTIPOINT_DATA_PLANE — плоскость данных маршрутизирует- ся, если флаг не задан — этого не происходит. Ш XPlQoS SUPPORTED — протокол поддерживает запросы QoS. * ХР 1 _UNI_SEND — протокол однонаправленный и обеспечивает лишь отправку данных. * XP1UNIRECV — протокол однонаправленный и обеспечивает лишь прием данных. * XP1_IFS_HANDLES — дескрипторы сокета, возвращенные поставщиком, являются описателями файловой системы IFS и могут быть использова- ны в таких API-функциях, как ReadFile и WriteFile. Ш XPl PARTIAL MESSAGE — флаг MSG_PARTIAL поддерживается функция- ми WSASend и WSASendTo. Для проверки наличия определенного свойства выберите соответствую- щий флаг и логически сложите его с полем dwServiceFlags 1. Если результат сложения ненулевой, протокол обладает указанным свойством, иначе — нет. ьольшинство из приведенных в списке флагов подробно описаны в сле- дующих главах. Поэтому сейчас рассмотрим другие, не менее важные поля: iProtocol, iSocketType и iAddressFamily. 116 ЧАСТЬ II Интерфейс прикладного программирования Winsock Поле iProtocol определяет, к какому протоколу относится данная запись Поле iSocketType важно, если протокол способен работать в разных режимах, например, с установлением поточного или дейтаграммного соединения И наконец, поле lAddressFamily позволяет выяснить корректную структуру ад- ресации, применяемую данным протоколом Эти три поля очень важны при создании сокета для конкретного протокола Сокеты Windows Рассмотрим, как доступные протоколы используют средства Winsock Как вы уже, вероятно, знаете, этот интерфейс основан на понятии сокета Сокет — это описатель поставщика транспорта В Win32 сокет отличается от описа- теля файла, а потому представлен отдельным типом — SOCKET Сокет созда- ется одной из двух функций SOCKET WSASocket ( int af, int type, int protocol, LPWSAPROTOCOL_INFO lpProtOCOlInfo, GROUP g, DWORD dwFlags SOCKET socket ( int af, int type, int protocol Первый параметр — af, определяет семейство адресов протокола Напри- мер, если вы хотите создать UDP- или ТСР-сокет, подставьте константу AF_ INET, чтобы сослаться на протокол IP Второй параметр — type, это тип соке- та для данного протокола Он может принимать одно из следующих значений SOCKSTREAM, SOCK_DGRAM, SOCKJEQPACKET, SOCK_RAWn SOCKRDM Третий параметр — protocol, указывает конкретный транспорт, если для данного се- мейства адресов и типа сокета существует несколько записей В табл 5-2 пе- речислены значения, используемые в полях семейства адресов, типа сокета и протокола для данного сетевого транспорта Табл. 5-2. Параметры сокетов Протокол Семейство Тип сокета адресов Протокол Internet AFINET Protocol (IP) IPX/SPX AF NS TCP UDP Простые сокеты MSAFD nwln- kipx [IPX] SOCKSTREAM SOCKDGRAM SOCKRAW SOCK DGRAM IPPROTOJP 1PPROTOJJDP IPPROTO_RAW 1PPROTOJCMP NSPROTO IPX Табл. 5-2. Протокол NetBIOS AppleTalk ATM Infrared Sockets (продолжение) Семейство адресов AFJPX AFJVETBIOS AF APPLE- TALK AF_ATM AFJRDA Тип сокета MSAFD nwln- kspx [SPX] MSAFD nwln- kspx [SPX] [псевдопоток] MSAFD nwln- kspx [SPXII] MSAFD nwlnk- spx [SPXII] [псевдопоток] Последова- тельные пакеты Дейтаграммы MSAFD Apple- Talk [ADSP] MSAFD Apple- Talk [ADSP] [псевдопоток] MSAFD Apple- Talk [PAP] MSAFD Apple- Talk [RTMP] MSAFD Apple- Talk [ZIP] MSAFD ATM AAL5 Native ATM (AAL5) MSAFD Irda [IrDA] |