// Сразу выделяем память под строку
SetLength(Connection.Msg, Connection.MsgSize);
end;
end
elsе if Res = 0 then
begin
AddMessageToLog('Клиент ' + Connection.ClientAddr +
' закрыл соединение');
RemoveConnection;
Exit;
end
else
// Ошибку WSAEWOULDBLOCK игнорируем, т.к. она говорит
// только о том, что входной буфер сокета пуст, но в целом
// все в порядке - такое вполне возможно при ложных
// срабатываниях сообщения
if WSAGetLastError <> WSAEWOULDBLOCK then
begin
AddMessageToLog('Ошибка при получении данных от клиента ' +
Connection.ClientAddr + ': ' + GetErrorString);
RemoveConnection;
Exit;
end;
end
else if Connection.Phase = tpReceiveString then
begin
// Следующий этап - чтение строки. Он практически не отличается
// по реализации от этапа чтения длины строки, за исключением
// того, что теперь буфером, куда помещаются полученные от
// клиента данные, служит не Connection.MsgSize,
// a Connection.Msg.
Res :=
recv(Connection.ClientSocket, Connection.Msg(Connection.Offset + 1),
Connection.BytesLeft, 0);
if Res > 0 then
begin
Inc(Connection.Offset, Res);
Dec(Connection.BytesLeft, Res);
// Если количество оставшихся байтов равно нулю, можно
// переходить к следующему этапу.
if Connection.BytesLeft = 0 then
begin
AddMessageToLog('От клиента ' + Connection.ClientAddr +
' получена строка: ' + Connection.Msg);
// Преобразуем строку. В отличие от предыдущих примеров,
// здесь мы явно добавляем к строке #0. Это связано с тем,
// что при отправке, которая тоже может быть выполнена не
// за один раз, мы указываем индекс того символа строки,
// начиная с которого нужно отправлять данные. И (хотя
// теоретически вероятность этого очень мала) может
// возникнуть ситуация, когда за один раз будут отправлены
// все символы строки, кроме завершающего #0, и тогда при
// следующей отправке начинать придется с него. Если мы
// будем использовать тот #0, который добавляется к концу
// строки автоматически, то в этом случае индекс выйдет за
// пределы диапазона. Поэтому мы вручную добавляем ещё один
// #0 к строке, чтобы он стал законной ее частью.
Connection.Msg :=
AnsiUpperCase(StringReplace(Connection.Msg, #0, '#0', [rfReplaceAll])) +
'(AsyncSelect server)'#0;
// Следующий этап - отправка строки клиенту
Connection.Phase := tpSendString;
// Отправлено на этом этапе 0 байт
Connection.Offset := 0;
// Осталось отправить Length(Connection.Msg) байтов.
// Единицу к длине строки, в отличие от предыдущих
// примеров, не добавляем, т.к. там эта единица нужна была
// для того, чтобы учесть добавляемый к строке
// автоматически символ #0. Здесь мы еще один #0 добавили
// к строке явно, поэтому он уже учтен в функции Length.
Connection.BytesLeft := Length(Connection.Msg);
// Ставим в очередь сообщение с событием FW_WRITE.
// Его получение заставит сервер отправить данные
PostMessage(Handle, WM_SOCKETMESSAGE, Msg.Socket, FD_WRITE);
end;
end
else if Res = 0 then
begin
AddMessageToLog('Клиент ' + Connection.ClientAddr +
' закрыл соединение');
RemoveConnection;
Exit;
end
elsе
// Как обычно, "ошибку" WSAEWOULDBLOCK просто игнорируем
if WSAGetLastError <> WSAEWOULDBLOCK then
begin
AddMessageToLog('Ошибка при получении данных от клиента ', +
Connection.ClientAddr + ': ' + GetErrorString);
RemoveConnection;
Exit;
end;
end
else if Connection.Phase = tpSendString then
// Если сервер находится на этапе отправки данных,
// а событие FD_READ все же произошло, отмечаем это
Connection.SendRead := True;
end;
FD_WRITE: begin
if Connection.Phase = tpSendString then
begin
// При наступлении события FD_WRITE проверяем, находится ли
// сервер на этапе отправки данных, и если да, отправляем их
Res :=
send(Connection.ClientSocket, Connection.Msg[Connection.Offset + 1],
Connection.BytesLeft, 0);
if Res > 0 then
begin
Inc(Connection.Offset, Res);
Dec(Connection.BytesLeft, Res);
// Если Connections. BytesLeft = 0, значит, строка отправлена
// полностью.
if Connection.BytesLeft = 0 then
begin
AddMessageToLog('Клиенту ' + Connection.ClientAddr +
' отправлена строка: ' + Connection.Msg);
// Очищаем строку, просто чтобы сэкономить память
Connection.Msg := '';
// Следующий этап - снова получение длины строки от клиента
Connection.Phase := tpReceiveLength;
// Получено - 0 байт
Connection.Offset := 0;
// Осталось прочитать столько, сколько занимает целое число
Connection.BytesLeft := SizeOf(Integer);
// Если были промежуточные события FD_READ, вызываем их
// снова искусственно
it Connection.SendRead then
begin
PostMessage(Handle, WM_SOCKETMESSAGE, Msg.Socket, FD_READ);
Connection.SendRead := False;
end;
end;
end
else if WSAGetLastError <> WSAEWOULDBLOCK then
begin
AddMessageToLog('Ошибка при отправке данных клиенту ' +
Connection.ClientAddr + ': ' + GetErrorString);
RemoveConnection;
Exit;
end;
end;
end;
FD_CLOSE: begin
// Клиент вызвал функцию shutdown. Закрываем соединение.
AddMessageToLog('Клиент ' + Connection.ClientAddr +
' закрыл соединение');
shutdown(Connection.ClientSocket, SD_BOTH);
RemoveConnection;
end
else
begin
AddMessageToLog('Неверное событие при обмене с клиентом ' +
Connection.ClientAddr);
RemoveConnection;
end;
end;
end;
В этом примере можно найти много общего с кодом из листинга 2.32 — получение и отправка данных в зависимости от этапа выполняется практически одинаково, различаются только условия, при которых эти участки кода выполняются. Обратите внимание, что теперь проверка того, какой этап чтения выполняется, сделана взаимоисключающей, т.е. при обработке одного сообщения не может быть прочитана и длина строки, и сама строка. Это сделано, чтобы убрать ложные срабатывания. Рассмотрим два возможных варианта. Первый вариант — когда во входном буфере сокета оказывается сразу длина и строка (или ее часть). После того как будет прочитана длина, сообщение WM_SOCKETMESSAGE с параметром FD_READ вновь будет помещено в очередь, поскольку функция recv помещает это сообщение в очередь, если после ее вызова во входном буфере сокета остались данные. Если мы немедленно перейдем ко второму этапу, то прочитаем из буфера сокета все оставшиеся там данные, но сообщение в очереди все равно останется, что даст нам ложное срабатывание, когда петля сообщений извлечет и диспетчеризует это сообщение. Таким образом, выполнение сразу двух этапов при обработке одного сообщения не даст выигрыша в производительности, т.к. все равно придется извлекать и обрабатывать два сообщения.
Второй вариант — когда на момент обработки события FD_READ во входном буфере находится только длина строки. В этом случае функция recv не будет помещать в очередь второе сообщение WM_SOCKETMESSAGE, т.к. данных в буфере после ее выполнения не останется, но и попытка выполнить этап чтения строки окажется бесполезной работой, т.к. строка еще не получена. В любом случае этап чтения строки будет выполнен только при обработке следующего сообщения WM_SOCKETMESSAGE, когда от клиента будут получены новые данные.
Получается, что при обоих вариантах попытка выполнить за один раз сразу два этапа не дает никаких преимуществ в быстродействии, но зато повышает вероятность ложных срабатываний события FD_READ в то время, когда сервер находится на этапе отправки данных клиенту. А ложные срабатывания на этом этапе вредны тем, что сервер принимает их за поступление данных, которое нужно запомнить, чтобы обработать после того, как ответ будет отправлен клиенту. В принципе, эти ложные срабатывания в итоге не приводят ни к чему плохому, кроме незначительного увеличения нагрузки на процессор, но раз от них нет пользы, и мы можем избавиться от них совсем небольшой ценой, лучше это сделать.
