Программирование_распределенных_систем / Использование сокетов в Delphi_2

сокет на основании первых трёх параметров так же, как это делает функция Socket. С другой стороны, если этот параметр не равен nil, то структура, на которую он указывает, содержит всю информацию, необходимую для создания сокета, поэтому первые три параметра должны быть равны константе From_Protocol_Info (-1). Параметр g зарезервирован для использования в будущем и должен быть равен нулю (тип TGroup совпадает с DWORD). Последний параметр dwFlags определяет, какие дополнительные возможности имеет создаваемый сокет. Вызов функции Socket эквивалентен вызову функции WSASocket с флагом WSA_Flag_Overlapped, который показывает, что данный сокет можно использовать для перекрытого ввода-вывода. Остальные флаги используются при многоадресной рассылке (не все из них допустимы при использовании протоколов TCP и UDP). Эти флаги мы рассмотрим в соответствующем разделе.

При использовании TCP и UDP функция WSASocket даёт следующие преимущества по сравнению с функцией Socket. Во-первых, через параметр lpProtocolInfo появляется возможность явно указать провайдера, который будет использован программой. Во-вторых, если программа не использует перекрытый ввод-вывод, можно создавать сокеты без флага WSA_Flag_Overlapped, экономя при этом некоторое незначительное количество ресурсов. Кроме того, как это будет обсуждаться ниже, с помощью WSASocket две разных программы могут использовать один и тот же сокет.

Функция WSAConnect является более мощным аналогом Connect. Её прототип выглядит следующим образом:

int WSAConnect( SOCKET s,

const struct sockaddr FAR *name, int namelen,

LPWSABUF lpCallerData,

LPWSABUF lpCalleeData,

LPQOS lpSQOS,

LPQOS lpGQOS);

function WSAConnect( S:TSocket;

var Name:TSockAddr; NameLen:Integer; lpCallerData,lpCalleeData:PWSABuf; lpSQOS,lpGQOS:PQOS);

typedef struct __WSABUF { u_long len;

char FAR *buf;} WSABUF, FAR * LPWSABUF;

type PWSABuf=^TWSABuf; TWSABuf=packed record

Len:Cardinal;

Buf:PChar end;

Функция WSAConnect устанавливает соединение со стороны клиента. Её первые три параметра совпадают с параметрами функции Connect. Параметры lpCallerData и lpCalleeData служат для передачи данных от клиента серверу и от сервера клиенту при установлении соединения. Они оба являются указателями на структуру TWSABuf, которая содержит размер буфера Len и указатель на буфер Buf. Протоколы стека TCP/IP не поддерживают передачу данных при соединении, поэтому при использовании TCP и UDP lpCallerData и lpCalleeData должны быть равны nil. Параметры lpSQOS и lpGQOS являются указателями на структуры, с помощью которых программа передаёт свои требования к качеству обслуживания, причём параметр lpGQOS связан с не поддерживаемым в настоящий момент групповым качеством и всегда должен быть равен nil. Параметр lpSQOS также должен быть равен nil, если программа не предъявляет требований к качеству обслуживания. Так как рассмотрение качества обслуживания выходит за рамки данной статьи, мы не приводим здесь определение структуры SQOS. При необходимости это определение легко найти в MSDN'е.

Между функциями Connect и WSAConnect существует небольшое различие при работе с сокетами, не поддерживающими соединение. Как вы знаете из предыдущей статьи, функция Connect может использоваться с такими сокетами для задания адреса отправки по умолчанию и автоматической фильтрации входящих пакетов. Для того, чтобы отменить такое "соединение", нужно при вызове функции Connect указать адрес InAddr_Any и нулевой порт. При использовании же WSAConnect для отмены "соединения" требуется, чтобы все без исключения поля структуры Name, включая sin_family, были нулевыми. Это сделано для того, чтобы обеспечить независимость от протокола: в этом случае для

разрыва "соединения" должно использоваться одно и то же значение Name при любом

протоколе.

Если программа не предъявляет требований к качеству обслуживания, то при использовании протоколов TCP и UDP функция WSAConnect не предоставляет никаких преимуществ по сравнению с функцией Connect.

Функция Accept из стандартной библиотеки сокетов позволяет серверу извлечь из очереди соединений информацию о подключившемся клиенте и создать сокет для его обслуживания. Эти действия выполняются безусловно, для любых подключившихся клиентов. Если сервер допускает подключение не любых клиентов, а только тех, которые отвечают некоторым условиям (для протокола TCP эти условия могут заключаться в том, какие IP-адреса и какие порты допустимо использовать клиентам), сразу после установления соединения его приходится разрывать, если клиент не удовлетворяет этим условиям. Для упрощения этой операции в WinSock 2 предусмотрена функция WSAAccept, имеющая следующий прототип:

SOCKET WSAAccept(

SOCKET s,

struct sockaddr FAR *addr, LPINT addrlen,

LPCONDITIONPROC lpfnCondition, DWORD dwCallbackData);

function WSAAccept( S:TSocket; Addr:PSockAddr; AddrLen:PInteger;

lpfnCondition:TConditionProc;

dwCallbackData:DWORD):TSocket;

По сравнению с уже известной нам функцией Accept функция WSAAccept имеет два новых параметра: lpfnCondition и dwCallbackData. lpfnCondition является указателем на функцию обратного вызова. Эта функция объявляется и реализуется программой. WSAAccept вызывает её внутри себя и в зависимости от её результата принимает или отклоняет соединение. Параметр dwCallbackData не имеет смысла для самой функции WSAAccept и передаётся без изменений в функцию обратного вызова. Тип TConditionProc должен быть объявлен следующим образом:

typedef (int*)(

LPWSABUF lpCallerId, LPWSABUF lpCallerData, LPQOS lpSQOS,

LPQOS lpGQOS, LPWSABUF lpCalleeId,

LPWSABUF lpCalleeData, GROUP FAR *g,

DWORD dwCallbackData) LPCONDITIONPROC;

type TConditionProc=function( lpCallerId,lpCallerData:PWSABuf; lpSQOS,lpGQOS:PQOS; lpCalleeID,lpCalleeData:PWSABuf; g:PGroup; dwCallbackData:DWORD):Integer;stdcall;

Параметр lpCallerId указывает на буфер, в котором хранится адрес подключившегося клиента. В случае использования стека TCP/IP lpCallerId^.Len будет равен

SizeOf(TSockAddr), а lpCallerId^.Buf будет указывать на структуру TSockAddr, содержащую адрес клиента. Параметр lpCallerData определяет буфер, в котором хранятся данные, переданные клиентом при соединении. Как уже отмечалось выше, протоколы стека TCP/IP не поддерживают передачу данных при соединении, поэтому для них этот параметр будет равен nil.

Параметры lpSQOS и lpGQOS задают требуемое клиентом качество обслуживания для сокета и для группы соответственно. Т.к. группы сокетов в текущей реализации WinSock не поддерживаются, параметр lpGQOS будет равен nil. Параметр lpSQOS тоже будет равен nil, если клиент не задал качество обслуживания при соединении.

Параметр lpCalleeId содержит адрес интерфейса, принявшего соединение (поля структуры при этом используются так же, как у параметра lpCallerId). В предыдущей статье обсуждалось, что сокет, привязанный к адресу InAddr_Any, прослушивает все сетевые интерфейсы, имеющиеся на компьютере, но каждое подключение, созданное с его помощью, использует конкретный интерфейс. Параметр lpCalleeId содержит адрес,

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

Описание параметра g в MSDN'е отсутствует (видимо, по ошибке). Но так как имеющаяся версия WinSock не поддерживает группы сокетов, его значение всё равно должно игнорироваться функцией обратного вызова.

И, наконец, через параметр dwCallbackData в функцию обратного вызова передаётся

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

Функция должна вернуть CF_Accept (0), если соединение принимается, CF_Reject (1), если оно отклоняется, и CF_Defer (2), если решение о разрешении или запрете соединения откладывается. Если функция обратного вызова вернула CF_Reject, WSAAccept

завершается с ошибкой WSAEConnRefused, если CF_Defer - с ошибкой WSATry_Again (в

последнем случае соединение остаётся в очереди, и информация о нём вновь будет передана в функцию обратного вызова при следующем вызове WSAAccept). Обе эти ошибки не являются фатальными, сокет остаётся в режиме ожидания соединения и может принимать подключения от новых клиентов.

В предыдущей статье обсуждалось, что функция Connect на стороне клиента считается успешно завершённой тогда, когда соединение встало в очередь, а не тогда, когда оно реально принято сервером через функцию Accept. По умолчанию для клиента, соединение с которым сервер отклонил, нет разницы, использовал ли сервер функцию WSAAccept и сразу отклонил соединение, или установил его с помощью Accept, а потом разорвал. В обоих случаях клиент сначала получит информацию об успешном соединении с сервером, а потом это соединение будет разорвано. Но при использовании WSAAccept можно установить такой режим работы, когда сначала выполняется функция, заданная параметром lpCondition, и лишь потом клиенту отправляется разрешение или запрет на подключение. Включается этот режим установкой параметра слушающего сокета SO_Conditional_Accept следующим образом:

var Cond:BOOL; begin

Cond:=True; SetSockOpt(S,SOL_Socket,SO_Conditional_Accept,PChar(@Cond),SizeOf(Cond));

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

Из вышесказанного следует, что при использовании протокола TCP функция WSAAccept по сравнению с Accept даёт два принципиальных преимущества - позволяет управлять качеством обслуживания и запрещать подключение нежелательных клиентов.

Некоторые протоколы поддерживают передачу информации не только при установлении связи, но и при её завершении. Для таких протоколов в WinSock2 предусмотрены функции

WSASendDisconnect и WSARecvDisconnect. Так как протокол TCP не поддерживает передачу данных при закрытии соединения, для него эти функции не дают никаких преимуществ по сравнению с использованием функции Shutdown, поэтому мы не будем их здесь рассматривать.

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

Функция Inet_Addr, как это уже упоминалось выше, жёстко связана с протоколом IP и не имеет смысла при использовании других протоколов. WinSock 2 предлагает использовать вместо неё функцию WSAStringToAddress, имеющую следующий прототип:

INT WSAStringToAddress(

LPTSTR AddressString,

INT AddressFamily,

LPWSAPROTOCOL_INFO lpProtocolInfo,

LPSOCKADDR lpAddress,

LPINT lpAddressLength);

function WSAStringToAddress( AddresString:PChar; AddressFamily:Integer; lpProtocolInfo:PWSAProtocolInfo;

var Address:TSockAddr;

var AddressLength:Integer):Integer;

Данная функция преобразует строку, задающую адрес сокета, в адрес, хранящийся в структуре TSockAddr. Параметр AddressString указывает на строку, хранящую адрес, параметр AddressFamily - на семейство адресов, для которого осуществляется трансляция. Если есть необходимость указать конкретного провайдера для протокола, в функцию может быть передан параметр lpProtocolInfo, в котором указан идентификатор провайдера. Если же программу устраивает провайдер по умолчанию, параметр lpProtocolInfo должен быть равен nil. Адрес возвращается через параметр Address. Параметр AddressLength при вызове функции должен содержать размер буфера, переданного через Address, а на выходе содержит реально использованное число байт в буфере.

Функция возвращает 0 в случае успешного выполнения и Socket_Error в случае ошибки.

Допустимый формат строки определяется протоколом (некоторые протоколы вообще не поддерживают текстовую запись адреса, и для них функция WSAStringToAddress неприменима). Для семейства AF_Inet, к которому относятся TCP и UDP, адрес может задаваться в виде "IP1.IP2.IP3.IP4:Port" или "IP1.IP2.IP3.IP4", где IPn - n-ая компонента IP-

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

Таким образом, чтобы в структуре TSockAddr оказался, например, адрес 192.168.100.217 и порт с номером 5000, необходимо выполнить следующий код:

var Addr:TSockAddr; AddrLen:Integer;

begin

AddrLen:=SizeOf(Addr); WSAStringToAddress('192.168.100.217:5000',AF_Inet,nil,Addr,AddrLen);

Существует также функция WSAAddressToString, обратная к WSAStringToAddress. Её прототип выглядит следующим образом:

INT WSAAddressToString(

LPSOCKADDR lpsaAddress,

DWORD dwAddressLength,

LPWSAPROTOCOL_INFO lpProtocolInfo,

LPTSTR lpszAddressString,

LPDWORD lpdwAddressStringLength);

function WSAAddressToString( var Address:TSockAddr; dwAddressLength:DWORD;

lpProtocolInfo:PWSAProtocolInfo;

lpszAddressString:PChar;

var AddressStringLength:DWORD):Integer;

Как нетрудно догадаться по названию функции, она преобразует адрес, заданный структурой TSockAddr, в строку. Адрес задаётся параметром Address, параметр dwAddressLength определяет длину буфера Address. Необязательный параметр lpProtocolInfo содержит указатель на структуру TWSAProtocolInfo, с помощью которой можно определить, какой именно провайдер должен выполнить преобразование. Параметр lpszAddressString содержит указатель на буфер, заранее выделенный программой, в который будет помещена строка. Параметр AddressStringLength на входе должен содержать размер буфера, заданного параметром lpszAddressString, а на выходе содержит длину получившейся строки.

Функция возвращает ноль в случае успеха и Socket_Error в случае ошибки.

В предыдущей статье мы обсуждали различные форматы представления целых чисел, а также то, что формат, предусмотренный сетевым протоколом, может не совпадать с форматом, используемым узлом. Для преобразования из сетевого формата в формат узла используются функции HToNS, NToHS, HToNL и NToHL. Эти функции привязаны к

протоколам стека TCP/IP - другие протоколы могут использовать другой формат представления чисел. WinSock 2 предлагает аналоги этих функций WSAHToNS, WSANToHS, WSAHToNL и WSANToHL, которые учитывают особенности конкретного протокола. Мы здесь рассмотрим только функцию WSANToHL, преобразующую 32-битное целое из сетевого формата в формат узла. Остальные три функции работают аналогично. Прототип функции WSANToHL выглядит так:

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

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

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

Асинхронный режим с уведомлением через сообщения устанавливается функцией WSAAsyncSelect, имеющей следующий прототип:

function WSAAsyncSelect(S:TSocket;HWindow:HWND; wMsg:u_int;lEvent:LongInt):Integer;

Параметр S определяет сокет, для которого устанавливается асинхронный режим работы. Параметр HWindow - дескриптор окна, которому будут приходить сообщения, параметр wMsg - сообщение, а параметр lEvent задаёт события, которые вызывают отправку сообщения. Для этого параметра определены константы, комбинация которых задаёт интересующие программу события. Мы не будем рассматривать здесь все возможные события, остановимся только на самых главных. Они показаны в таблице.

FD_Connect Соединение установлено (применимо только для сокетов, для которых вызвана функция Connect или аналогичная ей)

FD_Close Соединение закрыто

Каждый последующий вызов WSAAsyncSelect для одного и того же сокета отменяет предыдущий вызов. Таким образом, в результате выполнения следующего кода форма будет получать только сообщения, показывающие готовность сокета к чтению, а готовность к записи не приведёт к отправке сообщения:

WSAAsyncSelect(S,Form1.Handle,WM_User,FD_Write);

// Второй вызов отменит результаты первого

WSAAsyncSelect(S,Form1.Handle,WM_User,FD_Read);

WSAAsyncSelect связывает с сообщением именно сокет, а не его дескриптор. Это означает, что если две программы используют один сокет (копия дескриптора которого была создана с помощью функции WSADuplicateSocket), и первая программа вызывает WSAAsyncSelect со своим дескриптором, а затем вторая - со своим, то вызов

WSAAsyncSelect, сделанный во второй программе, отменит вызов, сделанный в первой.

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

WSAAsyncSelect(S,Form1.Handle,WM_User,FD_Read or FD_Write);

При необходимости с помощью or можно комбинировать и большее число констант.

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

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

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

При получении сообщения его параметр wParam содержит дескриптор сокета, на котором произошло событие. Младшее слово lParam содержит произошедшее событие