Требование к любому клиент-серверному приложению, использующему Winsock, заключается в следующем: сервер должен сделать свой адрес доступным клиентам, чтобы они могли подключаться к серверу. Для стандартных сервисов, выполняемых в TCP/IP, с этой целью используются так называемые общеизвестные адреса. Если браузер знает имя компьютера, на котором работает Web-сервер, он может подключиться к нему, указав общеизвестный адрес Web-сервера (к IP-адресу сервера добавляется строка «:80» — номер HTTP-порта). Провайдеры пространств имен позволяют серверам регистрировать свое присутствие и другими способами. Например, провайдер пространства имен мог бы на серверной стороне регистрировать адрес сервера в Active Directory, а на клиентской — искать его в Active Directory. Провайдеры пространств имен обеспечивают эту функциональность Winsock, реализуя такие стандартные Winsock-функции разрешения имен, как getaddrinfo (заменяет gethostbyname) и getnameinfo.

ЭКСПЕРИМЕНТ: просмотр провайдеров сервисов Winsock

Утилита Windows Sockets Configuration (Sporder.exe), входящая в Platform SDK, показывает зарегистрированные в Winsock провайдеры транспортных сервисов и пространств имен и позволяет изменять порядок перечисления TSP Например, если в системе имеется два провайдера транспортных сервисов TCP/IP, то первым в списке идет TSP по умолчанию для Winsock-приложений, использующих протокол TCP/IP. Ha иллюстрации показано окно Sporder, в котором перечислены зарегистрированные TSP

Реализация Winsock представлена на рис. 13-4. Его программный интерфейс поддерживается библиотекой Ws2_32.dll (\Windows\System32\Ws2_32.dll), которая обеспечивает приложениям доступ к функциям Winsock. Для операций над именами и сообщениями Ws2_32.dll вызывает сервисы TSP и провайдеров пространств имен. Библиотека Mswsock.dll выступает в роли TSP для протоколов, поддерживаемых Microsoft в Winsock. Она взаимодействует с драйверами протоколов режима ядра с помощью вспомогательных библиотек Winsock (Winsock Helpers), специфичных для конкретного протокола. Например, Wshtcpip.dll — вспомогательная библиотека TCP/IP. B Mswsock.dll (\Windows\System32\Mswsock.dll) реализованы такие расширения Winsock, как функции TransmitEile,AcceptEx и WSARecvEx. Windows поставляется со вспомогательными библиотеками для TCP/IP, TCP/IP с IPv6, AppleTalk, IPX/SPX, ATM и IrDA (Infrared Data Association), а также с провайдерами пространств имен для DNS (TCP/IP), Active Directory и IPX/SPX.

Рис. 13-4. Реализация Winsock

Подобно API именованных каналов и почтовых ящиков Winsock интегрируется с Windows-моделью ввода-вывода и использует для представления co-кетов описатели файлов. Для этого нужна помощь со стороны драйвера файловой системы режима ядра, поэтому, реализуя функции на основе сокетов, Msafd.dll использует сервисы AFD (Ancillary Function Driver) (\Windows\System32\Drivers\Afd.sys). AFD является клиентом TDI и выполняет сетевые операции с использованием сокетов, например посылает и принимает сообщения, отправляя TDI IRP-пакеты драйверам протокола. AFD не запрограммирован на использование определенных драйверов протоколов — вместо этого Msafd.dll уведомляет AFD о протоколе, используемом для сокета, и в результате AFD может открыть объект «устройство», представляющий этот протокол.

Windows Sockets Direct (WSD) — это интерфейс, позволяющий в Winsock-приложениях без всякой модификации использовать преимущества сетей устройств хранения данных (System Area Networks, SAN). Высокопроизводительные SAN идеальны для самых разнообразных применений — от распределенных вычислений до трехуровневых архитектур электронной коммерции вроде показанной на рис. 13-5. B данной системе сети SAN соединяют Web-серверы (презентационный Web-уровень) с серверами бизнес-логики и с серверами базы данных, что обеспечивает высокоскоростную передачу данных между различными уровнями обработки информации. Поддержка WSD имеется в Windows 2003 и Windows 2000 Data Center Server, а также в Windows 2000 Advanced Server c Service Pack (SP) 2 и выше.

Высокая производительность SAN обычно достигается за счет специализированных сетевых соединений и коммутационного оборудования. K наиболее распространенным типам SAN-соединений относятся InfiniBand, Gigabit Ethernet, FiberChannel и различные фирменные (закрытые) решения. Физическая память, разделяемая двумя компьютерами, тоже может служить SAN-соединением.

Коммутационное оборудование SAN реализует немаршрутизируемый протокол, предоставляющий TCP-эквивалентные гарантии, в частности надежную доставку сообщений в правильном порядке. Эти аппаратные средства также поддерживают механизм SAN, называемый удаленным прямым доступом к памяти (Remote Direct Memory Access, RDMA); этот механизм позволяет напрямую передавать сообщения из физической памяти компьютера-источника в физическую память компьютера-получателя без промежуточной операции копирования, которая обычно выполняется на стороне, принимающей сообщения. Благодаря этому RDMA освобождает процессор и шину памяти от лишней нагрузки, связанной с операцией копирования.

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

Большинство реализаций SAN требуют модификации приложений для взаимодействия с сетевыми протоколами SAN и использования преимуществ аппаратно-реализованных протоколов и механизмов SAN вроде RDMA, но WSD позволяет любому Winsock-приложению, работающему по протоколу TCP, задействовать возможности SAN без такой модификации. Само название WSD подчеркивает, что он обеспечивает приложениям прямой доступ к оборудованию SAN, в обход стека TCP/IP. A сокращение пути передачи данных повышает производительность приложений в 2–2,5 раза.

Такое сокращение достигается за счет использования программного коммутатора, размещаемого на уровень ниже Winsock DLL, как показано на рис. 13-6. Этот коммутатор переадресует сетевые операции SAN провайдеру сервисов Winsock (Winsock service provider, WSP), который предоставляется производителем SAN. WSP служит эквивалентом NDIS-драйвера, работающим в пользовательском режиме, и может проецировать аппаратные регистры SAN на память пользовательского режима, а затем манипулировать оборудованием без участия компонентов режима ядра. Однако некоторые операции все же требуют поддержки со стороны таких компонентов, например для проецирования содержимого аппаратных регистров на память пользовательского режима; эта поддержка тоже предоставляется производителем оборудования SAN. Наконец, производитель SAN предоставляет минипорт-драйвер NDIS, выступающий в роли интерфейса между стеком TCP/IP и оборудованием SAN для приложений, которые используют сетевые средства Winsock, не поддерживаемых SAN на аппаратном уровне.