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

var cbTransfer:DWORD; fWait:BOOL;

var Flags:DWORD):BOOL;

Параметры S и lpOverlapped функции WSAGetOverlappedResult определяют сокет и операцию перекрытого ввода-вывода, информацию о которой требуется получить. Их значения должны совпадать со значениями соответствующих параметров, переданных функции WSARecv. Через параметр cbTransfer возвращается количество полученных байт, а через параметр Flags возвращаются флаги (напомню, что при использовании TCP и UDP флаги не модифицируются, и выходное значение параметра Flags будет равно входному значению параметра Flags функции WSARecv).

Допускается вызов функции WSAGetOverlappedResult до того, как операция перекрытого ввода-вывода будет завершена. В этом случае поведение функции зависит от параметра fWait. Если он равен True, функция переводит нить в состояние ожидания до тех пор, пока операция не будет завершена. Если он равен False, функция завершается немедленно с ошибкой WSA_IO_Incomplete (996).

Функция WSAGetOverlappedResult возвращает True, если операция перекрытого вводавывода успешно завершена, и False, если произошли какие-то ошибки. Ошибка может возникнуть в одном из трёх случаев:

1.Операция перекрытого ввода-вывода ещё не завершена, а параметр fWait равен

False.

2.Операция перекрытого ввода-вывода завершилась с ошибкой (например, из-за разрыва связи).

3.Параметры, переданные функции WSAGetOverlappedResult, имеют некорректные значения.

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

В принципе, программа может вообще не использовать события для отслеживания завершения операции ввода-вывода, а вызывать вместо этого время от времени функцию WSAGetOverlappedResul в удобные для себя моменты. При этом при вызове функции WSARecv можно указать нулевое значение события hEvent. Но следует иметь ввиду, что при вызове функции WSAGetOverlappedResult с параметром fWait, равным True, указанное событие используется для ожидания завершения операции, и если событие не задано, возникнет ошибка. Таким образом, если событие не используется, функция WSAGetOverlappedResult не может вызываться в режиме ожидания.

Отдельно рассмотрим ситуацию, когда на момент вызова функции WSARecv с ненулевым параметром lpOverlapped во входном буфере сокета есть данные. В этом случае функция отработает так же, как и в неперекрытом режиме, т.е. изменит значения параметров NumberOfBytesRecvd и Flags и вернёт ноль, свидетельствующий об успешном выполнении функции. Но при этом событие будет взведено, а в структуру lpOverlapped будет внесена вся необходимая информация. Благодаря этому последующие вызовы функций

WSAWaitForMultipleEvents и WSAGetOverlappedResult будут выполняться корректно, т.е.

таким образом, как если бы функция WSARecvзавершилась с ошибкой WSA_IO_Pending, и сразу после этого в буфер сокета поступили данные. Это позволяет использовать один и тот же код для обработки результатов операций перекрытого ввода-вывода независимо от того, были ли в буфере сокета данные на момент начала операции или нет.

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

ВMSDN'е мне не удалось найти информацию о том, что будет, если вызвать для сокета WSARecv повторно, до того как будет завершена предыдущая операция перекрытого чтения. Мои эксперименты показали, что в этом случае операции перекрытого чтения встают в очередь, т.е. первый полученный сокетом пакет приводит к завершению операции, начатой первой, второй пакет - операции, начатой второй, и т.д. Но я не знаю, документировано ли такое поведение операций перекрытого ввода-вывода где-либо, и поэтому рекомендую не предполагать, что они всегда будут выполняться таким образом.

Вкачестве примера использования перекрытого ввода-вывода рассмотрим ситуацию, когда программа начинает операцию чтения данных из сокета, время от времени проверяя статус операции. События в этом примере не используются, проверка осуществляется с помощью функции WSAGetOverlappedResult.

Функция SleepEx является частью стандартного API системы и импортируется модулем Windows. Она переводит нить в состояние ожидания. Параметр dwMilliseconds задаёт время ожидания в миллисекундах (или значение Infinite для бесконечного ожидания). Параметр bAlertable указывает, допустимо ли прерывание состояния ожидания для выполнения процедуры завершения. Если bAlertable равен False, функция SleepEx ведёт себя так же, как функция Sleep, т.е. просто приостанавливает работу нити на заданное время. Если bAlertable равен True, нить может быть выедена системой из состояния ожидания раньше, чем истечёт заданное время, если возникнет необходимость выполнить процедуру завершения. О причине завершения ожидания программа может судить по результату, возвращаемому функцией SleepEx: ноль в случае завершения по таймауту и Wait_IO_Completion в случае завершения из-за выполнения процедуры завершения (в последнем случае сначала выполняется процедура завершения, а потом только происходит возврат из функции SleepEx). Если завершилось несколько операций перекрытого вводавывода, в результате выполнения SleepEx будут вызваны процедуры завершения для всех этих операций.

Существует также возможность ожидать выполнения процедуры завершения одновременно с ожиданием взведения событий с помощью функции WSAWaitForMultuipleEvents. Напомню, что у этой функции также есть параметр fAlertable. Если задать его равным True, то при необходимости выполнения процедуры завершения функция WSAWaitForMultipleEvents, подобно функции SleepEx, выполняет эту процедуру и возвращает Wait_IO_Completion.

Если программа выполняет одновременно несколько операций перекрытого вводавывода, встаёт вопрос, как при вызове процедуры завершения определить, какая из них завершилась. Для каждой такой операции должен быть создан уникальный экземпляр структуры TWSAOverlapped. Процедура завершения получает указатель на тот экземпляр, который использовался для начала завершившейся операции. Можно сравнить указатель с теми, которые использовались для запуска операций перекрытого ввода-вывода, и определить, какая из них завершилась. Это не всегда бывает удобно из-за необходимости где-то хранить список указателей, использовавшихся для операций перекрытого вводавывода. Существуют ещё два варианта решения этой проблемы. Первый вариант заключается в создании своей процедуры завершения для каждой из выполняющихся параллельно операций. Этот вариант приводит к получению громоздкого кода и может быть неудобен, если число одновременно выполняющихся операций заранее неизвестно. Его следует использовать только при одновременном выполнении разнородных опреаций, требующих разных алгоритмов при обработке их завершения. Другой вариант предлагается в MSDN'e. Так как при использовании процедур завершения значение поля hEvent структуры TWSAOverlapped игнорируется системой, программа может записать туда любое 32-битное значение и с его помощью определить, какая из операций завершена. В строго типизированном языке, каким является Паскаль, подобное смешение типа дескриптора и целого выглядит весьма непривлекательно, но, к сожалению, это лучшее из того, что нам предлагают разработчики WinSock API.

При использовании процедур завершения допустимо использование функции WSAGetOverlappedResult для определения статуса операции, но её параметр fWait обязательно должен быть равен False, потому что события, необходимые для выполнения ожидания, не взводятся, и попытка дождаться окончания операции может привести к блокировке работы нити.

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

var S:TSocket;

Overlapped:TWSAOverlapped;

BufPtr:TWSABuf; RecvBuf:array[1..100] of Char; Cnt,Flags:Cardinal; Connected:Boolean;

procedure GetData(Err,Cnt:DWORD;OvPtr:PWSAOverlapped;Flags:DWORD);stdcall; begin

if Err<>0 then begin

// Произошла ошибка. Соединение надо устанавливать заново

CloseSocket(S);

Connected:=False end

else

разбирали в предыдущей статье. В остальном WSARecvFrom ведёт себя так же, как WSARecv, поэтому мы не будем останавливаться на ней.

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

int WSASend( SOCKET s,

LPWSABUF lpBuffers, DWORD dwBufferCount,

LPDWORD lpNumberOfBytesSent, DWORD dwFlags, LPWSAOVERLAPPED lpOverlapped,

LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine);

function WSASend( S:TSocket; lpBuffers:PWSABuf;

dwBufferCount:DWORD;

var NumberOfBytesRecvd:DWORD; Flags:DWORD; lpOverlapped:PWSAOverlapped;

lpCompletionRoutine:TWSAOverlappedCompletionRoutine):Integer;

int WSASend( SOCKET s,

LPWSABUF lpBuffers, DWORD dwBufferCount,

LPDWORD lpNumberOfBytesSent, DWORD dwFlags,

const struct sockaddr FAR *lpTo, int iToLen,

LPWSAOVERLAPPED lpOverlapped, LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine);

function WSASendTo( S:TSocket; lpBuffers:PWSABuf; dwBufferCount:DWORD;

var NumberOfBytesRecvd:DWORD; Flags:DWORD;

var AddrTo:TSockAddr; ToLen:Integer; lpOverlapped:PWSAOverlapped;

lpCompletionRoutine:TWSAOverlappedCompletionRoutine):Integer;

Если вы разобрались с функциями WSARecv, Send и SendTo, то смысл параметров функций WSASend и WSASendTo должен быть вам очевиден, поэтому подробно разбирать мы их не будем. Но отметим, что флаги передаются по значению, и функции не могут изменять их.

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

[ К содержанию ]

Многоадресная рассылка

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

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

загружает центральный процессор, но её возможности ограничены. В частности, у

некоторых старых карт отсутствует аппаратная поддержка IGMP, поэтому они не могут получать пакеты, отправленные на групповой адрес, без переключения в режим программной выборки. Более современные сетевые карты способны запоминать несколько (обычно 16 или 32) групповых адресов, и, пока количество групповых адресов не превышает этот предел, могут осуществлять аппаратную выборку пакетов с учётом групповых адресов.

Windows 95 и NT 4 используют сетевые карты в режиме программной выборки пакетов. Windows 98 и 2000 по умолчанию используют сетевые карты в режиме аппаратной выборки пакетов. При этом Windows 2000 может переключать карту в режим программной выборки, если число групповых адресов, с которых компьютер должен принимать пакеты, превышает её аппаратные возможности. Windows 98 такой возможностью не обладает, поэтому программа, выполняемая в этой среде, может столкнуться с ситуацией, когда сокет не сможет присоединиться к групповому адресу из-за нехватки аппаратных ресурсов сетевой карты (программа при этом получит ошибку WSAENoBufs).

WinSock предоставляет достаточно широкие возможности по управлению многоадресной рассылкой, но для их использования необходимо, чтобы выбранный сетевой протокол поддерживал все эти возможности. Поддержка многоадресной рассылки протоколом IP достаточно скудна по сравнению, например, с протоколами, применяющимися в сетях ATM. Здесь мы будем рассматривать только те возможности WinSock по поддержке многоадресной рассылки, которые могут быть использованы с протоколом IP.

Протокол IP не поддерживает многоадресную рассылку при использовании TCP, поэтому всё, что будет сказано ниже, относится только к протоколу UDP. Отметим также, что при использовании многоадресной рассылки через границы подсетей роутеры должны поддерживать передачу многоадресных пакетов.

Глава "Многоадресная рассылка" в рекомендованной выше книге Джонса и Оланда, к

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

Многоадресная рассылка в IP является одноранговой и в плоскости управления, и в плоскости данных (в книге Джонса и Оланда вместо "одноранговая" используется слово "немаршрутизируемая" - видимо, переводчик просто перепутал слова nonrooted и nonrouted). Это значит, что все сокеты, участвующие в ней, равноправны. Каждый сокет без каких-либо ограничений может подключиться к многоадресной группе и получать все сообщения, отправленные на групповой адрес. При этом послать сообщение на групповой адрес может любой сокет, в т.ч. и не входящий в группу. Для групповых адресов протокол IP использует диапазон от 224.0.0.0 до 239.255.255.255. Часть из этих адресов зарезервирована для стандартных служб, поэтому своим группам лучше назначать адреса, начиная с 225.0.0.0. Кроме того, весь диапазон от 224.0.0.0 до 224.0.0.255 зарезервирован для групповых сообщений, управляющих роутерами, поэтому сообщения, отправленные на эти адреса, никогда не передаются в соседние подсети.

Есть два варианта осуществления многоадресной рассылки с использованием IP средствами WinSock. Первый вариант связан с использованием WinSock 1 и жёстко привязан к протоколу IP. Второй вариант подразумевает использование WinSock 2 и осуществляется универсальными, не привязанными к конкретному протоколу средствами.

Если рассылка будет осуществляться средствами WinSock 1, то сокет, участвующий в ней, создаётся обычным образом - с помощью функции WSASocket со стандартным набором флагов или с помощью функции Socket с обычными параметрами, задаваемыми при создании UDP-сокета. Если же используется WinSock 2, то сокет должен быть создан с указанием его роли в плоскостях управления и данных. Так как многоадресная рассылка в IP является одноранговой, все сокеты, участвующие в ней, могут быть только "листьями", поэтому сокет для рассылки должен создаваться функцией WSASocket с указанием флагов

WSA_Flag_Multipoint_C_Leaf (4) и WSA_Flag_Multipoint_D_Leaf (16). В книге Джонса и Оланда на странице 313 написано, что для рассылки средствами WinSock 2 можно создавать сокет функцией Socket - это неверно. Впрочем, на странице 328 всё-таки написано, что указанные флаги использовать обязательно.

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

Затем выполняется собственно добавление сокета в группу. В WinSock 1 для этого надо использовать функцию SetSockOpt с параметром IP_Add_Membership, указав в качестве уровня IPProto_IP. При этом через параметр OptVal передаётся указатель на структуру

ip_mreq, описанную следующим образом:

struct ip_mreq {

struct in_addr imr_multiaddr; struct in_addr imr_interface;

}

type TIPMreq=packed record

IMR_MultiAddr:TSockAddr; IMR_Interface:TSockAddr

end;

Поле IMR_MultiAddr задаёт групповой адрес, к которому присоединяется сокет. У этой структуры должны быть заполнены поля sin_family (значением AF_Inet) и sin_addr. Номер порта здесь указывать не надо, значение этого поля игнорируется. Поле IMR_Interface определяет адрес сетевого интерфейса, через который будет вестись приём многоадресной рассылки. Если программу устраивает интерфейс, выбираемый системой по умолчанию, значение поля IMR_Interface.sin_addr должно быть InAddr_Any (на компьютерах с одним сетевым интерфейсом обычно используется именно это значение). Но если у компьютера несколько сетевых интерфейсов, которые связывают его с разными сетями, интерфейс для получения групповых пакетов, выбираемый системой по умолчанию, может быть связан не с той сетью, из которой они реально ожидаются. В этом случае программа может явно указать IP-адрес того интерфейса, через который данный сокет должен принимать

групповые пакеты. Как и в поле IMR_MultiAddr, в поле IMR_Interface используются только поля sin_family и sin_addr, а остальные поля игнорируются.

Для прекращения членства сокета в группе используется та же функция SetSockOpt, но с параметром IP_Drop_Membership. Через параметр OptVal при этом также передаётся структура ip_mreq, значимые поля которой должны быть заполнены так же, как они были заполнены при добавлении данного сокета в данную группу.

Несмотря на то, что структура ip_mreq относится к WinSock 1, в модуле WinSock её описание отсутствует. Константы IP_Add_Membership и IP_Drop_Membership в этом модуле объявлены, но использовать их следует с осторожностью, потому что они должны иметь разные значения в WinSock 1 и WinSock 2. В WinSock 1 они должны иметь значения 5 и 6 соответственно, а в WinSock 2 - 12 и 13. Из-за этого нужно внимательно следить, чтобы использовались значения, соответствующие той библиотеке, из которой импортируется функция SetSockOpt: 5 и 6 при использовании WSock32.dll и 12 и 13 при использовании

WS2_32.dll.

В WinSock 2 для присоединения сокета к группе объявлена функция WSAJoinLeaf, имеющая следующий прототип:

SOCKET WSAJoinLeaf( SOCKET s,

const struct sockaddr FAR *name, int namelen,

LPWSABUF lpCallerData, LPWSABUF lpCalleeData, LPQOS lpSQOS,

LPQOS lpGQOS, DWORD dwFlags);

function WSAJoinLeaf( S:TSocket;

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

Параметры lpCallerData и lpCalleeData задают буферы, в которые помещаются данные, передаваемые и получаемые при присоединении к группе. Протокол IP не поддерживает передачу таких данных, поэтому при его использовании эти параметры должны быть равны nil. Параметры lpSQOS и lpGQOS относятся к качеству обслуживания, которое мы здесь не рассматриваем, поэтому их мы тоже полагаем равными nil.

Параметр S определяет сокет, который присоединяется к группе, параметр Name - адрес группы, NameLen - размер буфера с адресом. Параметр dfFlags определяет, будет ли сокет использоваться для отправки данных (JL_Sender_Only, 1), для получения данных

(JL_Receiver_Only, 2) или и для отправки, и для получения (JL_Both, 4).

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

В этом разделе мы рассмотрим некоторые функции, относящиеся в WinSock к дополнительным. В WinSock 1 эти функции вместе со всеми остальными экспортируются библиотекой WSock32.dll, а в WinSock 2 они вынесены в отдельную библиотеку MSWSock.dll (в эту же библиотеку вынесены некоторые устаревшие функции типа

EnumProtocols).

Начнём мы знакомство с этими функциями с функции WSARecvEx (которая, кстати, является расширенной версией функции Recv, а отнюдь не WSARecv, как это можно заключить из её названия), имеющей следующий прототип

function WSARecvEx(S:TSocket;var Buf;Len:Integer;var Flags:Integer):Integer;

Видно, что эта функция отличается от обычной функции Recv только тем, что флаги передаются через параметр-переменную вместо значения. В функции WSARecvEx этот параметр является не только входным, но и выходным; функция может модифицировать его. Ранее мы познакомились с функцией WSARecv, которая также может модифицировать переданные ей флаги, но условия, при которых эти две функции модифицируют флаги, различаются.

При использовании TCP (а также любого другого потокового протокола) флаги не изменяются функцией, и результат работы WSARecvEx эквивалентен результату работы

Recv.

В предыдущей статье мы обсуждали, что дейтаграмма UDP должна быть прочитана из буфера сокета целиком. Если в буфере, переданном функции Recv или RecvFrom недостаточно места для получения дейтаграммы, эти функции завершаются с ошибкой. При этом в буфер помещается та часть дейтаграммы, которая может в нём поместиться, а оставшаяся часть дейтаграммы теряется. Функция WSARecvEx отличается от Recv только тем, что в случае, когда размер буфера меньше размера дейтаграммы, она завершается без ошибки (возвращая при этом размер прочитанной части дейтаграммы, т.е. размер буфера) и добавляет флаг Msg_Partial к параметру Flags. Остаток дейтаграммы при этом также теряется. Таким образом, WSARecvEx даёт альтернативный способ проверки того, что дейтаграмма не поместилась в буфер, и в некоторых случаях этот способ может оказаться удобным.

Если при вызове функции WSARecvEx флаг Msg_Partial установлен программой, но дейтаграмма поместилась в буфер целиком, функция сбрасывает этот флаг.

В описании функции WSARecvEx в MSDN'е можно прочитать, что если дейтаграмма прочитана частично, то следующий вызов функции позволит прочитать оставшуюся часть дейтаграммы. Это не относится к протоколу UDP и имеет место быть только при использовании протоколов типа SPX, в которых одна дейтаграмма может разбиваться на несколько сетевых пакетов, и поэтому возможна такая ситуация, когда в буфере сокета окажется только часть дейтаграммы. В UDP, напомню, дейтаграмма всегда посылается одним IP-пакетом и помещается в буфер сразу целиком.

WSARecvEx не позволяет программе определить, с какого адреса прислана дейтаграмма, а аналога функции RecvFrom с такими же возможностями в WinSock нет.

Мы уже упоминали о том, что в WinSock 1 существует перекрытый ввод-вывод, но только для систем линии NT. Также в WinSock 1 определена функция AcceptEx, которая является более мощным эквивалентом функции Accept, и позволяет принимать входящие соединения в режиме перекрытого ввода-вывода. В WinSock 1 эта функция не поддерживается в Windows 95, в WinSock 2 она доступна во всех системах. Её прототип выглядит следующим образом:

function AcceptEx( sListenSocket,sAcceptSocket:TSocket; lpOutputBuffer:Pointer;

ReceiveDataLength,LocalAddressLength,RemoteAddressLength:DWORD; var lpdwBytesReceived:DWORD;

lpOverlapped:POverlapped):BOOL;

Функция AcceptEx позволяет принять новое подключение со стороны клиента и сразу же получить от него первую порцию данных. Функция работает только в режиме перекрытого ввода-вывода.

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

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