А. Григорьев - О чём не пишут в книгах по Delphi

Сокет, созданный при вызове функции 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также генерируется.