* При перепечатке материалов ссылка на www.SeoLiga.ru обязательна!
Асинхронный режим, основанный на сообщениях
19 марта 2009
Все операции с сокетами, которые мы рассматривали раньше, являлись синхронными. Программа, использующая такие сокеты, должна сама время от времени проверять тем или иным способом, пришли ли данные, установлена ли связь и т.п. Асинхронные сокеты позволяют программе получать уведомления о событиях, происходящих с сокетом: поступлении данных, освобождении места в буфере, закрытии и т.п. Такой способ работы лучше подходит для событийно-ориентированных программ, типичных для Windows. Поддержка асинхронных сокетов впервые появилась в WinSock 1 и была основана на сообщениях, которые обрабатывались оконными процедурами. В WinSock 2 этот асинхронный режим остался без изменений. Программист указывает, какое сообщение какому окну должно приходить при возникновении события на интересующем его сокете. Асинхронный режим с уведомлением через сообщения устанавливается функцией WSAAsyncSelect, имеющей следующий прототип:
function WSAAsyncSelect(S:TSocket;HWindow:HWND; wMsg:u_int;lEvent:LongInt):Integer;
Параметр S определяет сокет, для которого устанавливается асинхронный режим работы. Параметр HWindow - дескриптор окна, которому будут приходить сообщения, параметр wMsg - сообщение, а параметр lEvent задаёт события, которые вызывают отправку сообщения. Для этого параметра определены константы, комбинация которых задаёт интересующие программу события. Мы не будем рассматривать здесь все возможные события, остановимся только на самых главных. Они показаны в таблице. Событие Комментарий FD_Read Сокет готов к чтению FD_Write Сокет готов к записи FD_Accept В очереди сокета есть подключения (применимо только для сокетов, находящихся в режиме ожидания подключения) 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 содержит произошедшее событие (одну из констант FD_XXX), а старшее слово - код ошибки, если она произошла. Для выделения кода события и кода ошибки из lParam в библиотеке WinSock предусмотрены макросы WSAGETSELECTEVENT и WSAGETSELECTERROR соответственно. В модуле WinSock они заменены функциями WSAGetSelectEvent и WSAGetSelectError. Одно сообщение может информировать только об одном событии на сокете. Если произошло несколько событий, в очередь окна будет добавлено несколько сообщений. Сокет, созданный при вызове функции Accept, наследует режим того сокета, который принял соединения. Таким образом, если сокет, находящийся в режиме ожидания подключения, является асинхронным, то и сокет, порождённый функцией Accept, будет асинхронным, и тот же набор его событий будет связан с тем же сообщением, что и у исходного сокета. Рассмотрим подробнее каждое из вышеперечисленных событий. Событие FD_Read возникает, когда во входной буфер сокета поступают данные (если на момент вызова WSAAsyncSelect, разрешающего такие события, в буфере сокета уже есть данные, то событие также возникает). Как только соответствующее сообщение помещается в очередь окна, дальнейшая генерация таких сообщений для этого сокета блокируется, т.е. получение новых данных не будет приводить к появлению новых сообщений (при этом сообщения, связанные с другими событиями этого сокета или с событием FD_Read других сокетов, будут по-прежнему помещаться при необходимости в очередь окна). Генерация сообщений снова разрешается после того, как будет вызвана функция для чтения данных из буфера сокета (это может быть функция Recv, RecvFrom, WSARecv или WSARecvFrom; мы в дальнейшем будем говорить только о функции Recv, потому что остальные ведут себя в этом отношении полностью аналогично). Если после вызова Recv в буфере асинхронного сокета остались данные, в очередь окна снова помещается это же сообщение. Благодаря этому программа может обрабатывать большие массивы по частям. Действительно, пусть в буфер сокета приходят данные, которые программа хочет забирать оттуда по частям. Приход этих данных вызывает событие FD_Read, сообщение о котором помещается в очередь. Когда программа начинает обрабатывать это сообщение, она вызывает Recv и читает часть данных из буфера. Так как данные в буфере ещё есть, снова генерируется сообщение о событии FD_Read, которое ставится в конец очереди. Через некоторое время программа снова начинает обрабатывать это сообщение. Если и в этот раз данные будут прочитаны не полностью, в очередь снова будет добавлено такое же сообщение. И так будет продолжаться до тех пор, пока не будут прочитаны все полученные данные. Описанная схема, в принципе, достаточно удобна, но следует учитывать, что в некоторых случаях она может давать ложные срабатывания, т.е. при обработке сообщения о событии FD_Read функция Recv завершится с ошибкой WSAEWouldBlock, показывающей, что входной буфер сокета пуст. Если программа читает данные из буфера не только при обработке FD_Read, может возникнуть следующая ситуация: в буфер сокета поступают данные. Сообщение о событии FD_Read помещается в очередь. Программа в это время обрабатывает какое-то другое сообщение, при обработке которого также читаются данные. В результате все данные извлекаются из буфера, и он остаётся пустым. Когда очередь доходит до обработки FD_Read, читать из буфера уже нечего. Другой вариант ложного срабатывания возможен, если программа при обработке FD_Read читает данные из буфера по частям, вызывая Recv несколько раз. Каждый вызов Recv, за исключением последнего, приводит к тому, что в очередь ставится новое сообщение о событии FD_Read. Чтобы избежать появления пустых сообщений в подобных случаях, MSDN рекомендует перед началом чтения отключить для данного сокета реакцию на поступление данных, вызвав для него WSAAsyncSelect без FD_Read, а перед последним вызовом Recv - снова включить. И, наконец, следует помнить, что сообщение о событии FD_Read можно получить и после того, как с помощью WSAAsyncSelect сокет будет переведён в синхронный режим. Это может случиться в том случае, когда на момент вызова WSAAsyncSelect в очереди ещё остались необработанные сообщения о событиях на данном сокете. Впрочем, это касается не только FD_Read, а вообще любого события. Событие FD_Write информирует программу о том, что в выходном буфере сокета есть место для данных. Вообще говоря, оно там есть практически всегда, если только программа не отправляет постоянно большие объёмы данных. Следовательно, механизм генерации этого сообщения должен быть таким, чтобы не забивать очередь программы постоянными сообщениями о том, что в буфере есть место, а посылать эти сообщения только тогда, когда программа действительно нуждается в такой информации. При использовании TCP первый раз сообщение, уведомляющее о событии FD_Write, присылается сразу после успешного завершения операции подключения к серверу с помощью Connect, если речь идёт о клиенте, или сразу после создания сокета функцией Accept или её аналогом в случае сервера. При использовании UDP это событие возникает после привязки сокета к адресу явным или неявным вызовом функции Bind. Если на момент вызова WSAAsyncSelect описанные действия уже выполнены, событие FD_Write также генерируется. В следующий раз событие может возникнуть только в том случае, если функция Send (или SendTo) не смогла положить данные в буфер из-за нехватки места в нём (в этом случае функция вернёт значение, меньшее, чем размер переданных данных, или завершится с ошибкой WSAEWouldBlock). Как только в выходном буфере сокета снова появится свободное место, возникнет событие FD_Write, показывающая, что программа может продолжить отправку данных. Если же программа отправляет данные не очень большими порциями и относительно редко, не переполняя буфер, то второй раз событие FD_Write не возникнет никогда. Событие FD_Accept во многом похоже на FD_Read, за исключением того, что событие возникает не при получении данных, а при подключении клиента. После постановки сообщения о событии FD_Accept в очередь новые сообщения о FD_Accept для данного сокета в очередь не ставятся, пока не будет вызвана функция Accept или WSAAccept. При вызове одной из этих функций сообщение о событии вновь помещается в очередь окна, если в очереди подключений после вызова функции остаются подключения. Событие FD_Connect возникает при установлении соединения для сокетов, поддерживающих соединение. Для клиентских сокетов оно возникает после завершения процедуры установления связи, начатой с помощью функции Connect, для серверных - после создания нового сокета с помощью функции Accept (событие возникает именно на новом сокете, а не на том, который находится в режиме ожидания подключения). В MSDN'е написано, что оно должно возникать также и после выполнения Connect для сокетов, не поддерживающих соединение, однако мне не удалось получить это событие при использовании протокола UDP. Событие FD_Connect также возникает, если при попытке установить соединение произошла ошибка (например, оказался недоступен указанный сетевой адрес). Поэтому при получении этого события необходимо анализировать старшее слово параметра lParam, чтобы понять, удалось ли установить соединение. Событие FD_Close возникает только для сокетов, поддерживающих соединение, при разрыве этого соединения нормальным образом или в результате ошибки связи. Если удалённая сторона для завершения соединения использует функцию Shutdown, то FD_Close возникает после вызова этой функции с параметром SD_Send. При этом соединение закрыто ещё не полностью, удалённая сторона ещё может получать данные, поэтому при обработке FD_Close можно попытаться отправить те данные, которые в этом нуждаются. При этом нет гарантии, что вызов функции отправки не завершится неудачей, т.к. удалённая сторона может и не использовать функцию Shutdown, а закрывать сокет сразу. Рекомендуемая последовательность действий при завершении связи такова. Сначала клиент завершает отправку данных через сокет, вызывая функцию Shutdown с параметром SD_Send. Сервер при этом получает событие FD_Close. Сервер отсылает данные клиенту (при этом клиент получает одно или несколько событий FD_Read), а затем также завершает отправку данных с помощью Shutdown с параметром SD_Send. Клиент при этом получает событие FD_Close, в ответ на которое закрывает сокет с помощью CloseSocket. Сервер, в свою очередь, сразу после вызова Shutdown также вызывает CloseSocket. Ниже приведён пример кода сервера, использующего асинхронные сокеты. Сервер работает в режиме запрос-ответ, т.е. посылает какие-то данные клиенту только в ответ на его запросы. Константа WM_SocketEvent, определённая в коде для сообщений, связанных с сокетом, может, в принципе, иметь и другие значения. unit Unit1;
procedure TForm1.FormCreate(Sender: TObject); var Data:TWSAData; Addr:TSockAddr; begin WSAStartup($101,Data); // Обычная последовательность действий по созданию сокета, // привязке его к адресу и установлению на прослушивание ServSock:=Socket(AF_Inet,Sock_Stream,0); Addr.sin_family:=AF_Inet; Addr.sin_addr.S_addr:=InAddr_Any; Addr.sin_port:=HToNS(3320); FillChar(Addr.sin_zero,SizeOf(Addr.sin_zero),0); Bind(ServSock,Addr,SizeOf(Addr)); Listen(ServSock,SOMaxConn); // Перевод сокета в асинхронный режим. Кроме события FD_Accept // указаны также события FD_Read и FD_Close, которые никогда не // возникают на сокете, установленном в режим прослушивания. // Это сделано потому, что сокеты, созданные с помощью функции // Accept, наследуют асинхронный режим, установленный для // слушающего сокета. Таким образом, не придётся вызывать // функцию WSAAsyncSelect для этих сокетов - для них сразу // будет назначен обработчик событий FD_Read и FD_Close. WSAAsyncSelect(ServSock,Handle, WM_SocketEvent,FD_Read or FD_Accept or FD_Close) end;
procedure TForm1.FormDestroy(Sender: TObject); begin CloseSocket(ServSock); WSACleanup end;
procedure TForm1.WMSocketEvent(var Msg:TMessage); var Sock:TSocket; SockError:Integer; begin Sock:=TSocket(Msg.WParam); SockError:=WSAGetSelectError(Msg.lParam); if SockError<>0 then begin // Здесь должен быть анализ ошибки CloseSocket(Sock); Exit end; case WSAGetSelectEvent(Msg.lParam) of FD_Read: begin // Пришёл запрос от клиента. Необходимо прочитать данные, // сформировать ответ и отправить его. end; FD_Accept: begin // Просто вызываем функцию Accept. Её результат нигде не // сохраняется, потому что вновь созданный сокет автоматически // начинает работать в асинхронном режиме, и его дескриптор при // необходимости будет передан через Msg.wParam при возникновении // события Accept(Sock,nil,nil) end; FD_Close: begin // Получив от клиента сигнал завершения, сервер, в принципе, // может попытаться отправить ему данные. После этого сервер // также должен соединение со своей стороны Shutdown(Sock,SD_Send); CloseSocket(Sock) end end end;
end.
Преимущество такого сервера по сравнению с сервером, основанным на функции Select (пример кода такого сервера приведён в предыдущей статье), заключается в том, что при отсутствии событий на сокетах он не находится в приостановленном режиме и может выполнять какие-то другие действия (например, реагировать на действия пользователя). Кроме того, этот сервер не имеет ограничений по количеству подключаемых клиентов, связанных с размером типа TFDSet. Впрочем, последнее не является существенным преимуществом, так как при таком количестве клиентов сервер обычно использует другие, более производительные способы взаимодействия с клиентами.
