Листинг 2.14. Создание сокета в программе SimplestServer
var
// Порт, который будет "слушать" сервер
Port: Word;
// "Слушающей" сокет
MainSocket: TSocket;
// Сокет, создающийся для обслуживания клиента
ClientSocket: TSocket;
// Адрес "слушающего" сокета
MainSockAddr: TSockAddr;
// Адрес подключившегося клиента
ClientSockAddr: TSockAddr;
// Размер адреса подключившегося клиента
ClientSockAddrLen: Integer;
//Без этой переменной не удастся инициализировать библиотеку сокетов
WSAData: TWSAData;
StrLen: Integer;
Str: string;
begin
try
if ParamCount = 0 then
// Если в командной строке порт не задан, назначаем его
Port := 12345;
else
// В противном случае анализируем командную строку и назначаем порт
try
Port := StrToInt(ParamStr(1));
if Port = 0 then
raise ESocketException.Create(
'Номер порта должен находиться в диапазоне 1-65535');
except
on EConvertError do
raise ESocketException.Create(
'Параметр "' + ParamStr(1) + '" не является целым числом');
on ERangeError do
raise ESocketException.Create(
'Номер порта должен находиться в диапазоне 1-65535');
end;
// инициализация библиотеки сокетов
if WSAStartup($101, WSAData) <> 0 then
raise ESocketException.Create(
'Ошибка при инициализации библиотеки WinSock');
// Создание сокета, который затем будет "слушать" порт
MainSocket := socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if MainSocket = INVALID_SOCKET then
raise ESocketException.Create(
'Невозможно создать слушающий сокет: ' + GetErrorString');
// Формирование адреса для "слушающего" сокета
FillChar(MainSockAddr.sin_zero, SizeOf (MainSockAddr.sin_zero, 0);
MainSockAddr.sin_family := AF_INET;
// Выбор IP-адреса доверяем системе
MainSockAddr.sin_addr.S_addr := INADDR_ANY;
// Порт назначаем, не забывая перевести его номер в сетевой формат
MainSockAddr.sin_port := htons(Port);
// Привязка сокета к адресу
if bind(MainSocket, MainSockAddr, SizeOf(MainSockAddr)) = SOCKET_ERROR then
raise ESocketException.Create(
'Невозможно привязать слушающий сокет к адресу: ' +
GetErrorString);
// Установка сокета в режим прослушивания
if listen(MainSocket, SOMAXCONN) = SOCKET_ERROR then
raise ESocketException.Create(
'Невозможно установить сокет в режим прослушивания: ' +
GetErrorString);
WriteLn(OemString('Сервер успешно начал прослушивание порта '), Port);
...
// Основная часть сервера приведена в листинге 2.15
...
except
on Е: ESocketException do
WriteLn(OemString(E.Message));
on E: Exception do
WriteLn(OemString('Неожиданное исключение ' + E.ClassName +
' с сообщением ' + E.Message));
end;
end.
Основная часть кода сервера — это два цикла, один из которых вложен в другой (листинг 2.15). Перед внешним циклом сервер создает сокет и переводит его в режим прослушивания, и внешний цикл начинается с вызова функции accept. Завершение accept указывает на подключение клиента. После этого начинается внутренний цикл, который состоит из получения сообщений от клиента, преобразования строки и отправки ответа. Внутренний цикл завершается, когда соединение разрывается либо самим клиентом, либо из-за ошибки в сети. После этого управление вновь передается на начало внешнего цикла, т.е. на accept, и сервер может принять подключение другого клиента (или повторное подключение того же клиента).
Листинг 2.15. Основная часть сервера SimplestServer
// Начало цикла подключения и общения с клиентом
repeat
ClientSockAddrLen := SizeOf(ClientSockAddr);
// Принимаем подключившегося клиента. Для общения с ним создается новый
// сокет, дескриптор которого помещается в ClientSocket.
ClientSocket :=
accept(MainSocket, @ClientSockAddr, @ClientSockAddrLen);
if ClientSocket = INVALID_SOCKET then
raise ESocketException.Create(
'Ошибка при ожидании подключения клиента: ' + GetErrorString);
// При выводе сообщения не забываем,
// что номер порта имеет сетевой формат
WriteLn(OemString(' Зафиксировано подключение с адреса '),
Ord(ClientSockAddr.sin_addr.S_un_b.s_b1), '.',
Ord(ClientSockAddr.sin_addr.S_un_b.s_b2), '.',
Ord(ClientSockAddr.sin_addr.S_un_b.s_b3), '.',
Ord(ClientSockAddr.sin_addr.S_un_b.s_b4), ':',
ntohs(ClientSockAddr.sin_port));
// Цикл общения с клиентом. Продолжается до тех пор,
// пока клиент не закроет соединение или пока
// не возникнет ошибка
repeat
// Читаем длину присланной клиентом строки и помещаем ее в StrLen
case ReadFromSocket(ClientSocket, StrLen, SizeOf(StrLen)) of
0: begin
WriteLn(OemString('Клиент закрыл соединение');
Break;
end;
-1: begin
WriteLn(OemString('Ошибка при получении данных от клиента: ',
GetErrorString));
Break;
end;
end;
// Протокол не допускает строк нулевой длины
if StrLen <= 0 then
begin
WriteLn(OemString('Неверная длина строки от клиента: '), StrLen);
Break;
end;
// Установка длины строки в соответствии с полученным значением
SetLength(Str, StrLen);
// Чтение строки нужной длины
case ReadFromSocket(ClientSocket, Str[1], StrLen) of
0: begin
WriteLn(OemString('Клиент закрыл соединение'));
Break;
end;
-1: begin
WriteLn(OemString( 'Ошибка при получении данных от клиента: ' +
GetErrorString));
Break;
end;
end;
WriteLn(OemString('Получена строка: ' + Str));
// Преобразование строки
Str :=
AnsiUpperCase(StringReplace(Str, #0, '#0', [rfReplaceAll])) +
' (Simplest server)';
// Отправка строки. Отправляется на один байт больше, чем
// длина строки, чтобы завершающий символ #0 тоже попал в пакет
if send(ClientSocket, Str[1], Length(Str) + 1, 0) < 0 then
begin
WriteLn(OemString('Ошибка при отправке данных клиенту: ' +
GetErrorString));
Break;
end;
WriteLn(OemString('Клиенту отправлен ответ: ' + Str));
// Завершение цикла обмена с клиентом
until False;
// Сокет для связи с клиентом больше не нужен
closesocket(ClientSocket);
until False;
Теперь перейдем к написанию клиента. Пример этого клиента находится на компакт-диске в папке SimpleClient, главное окно показано на рис. 2.4. Клиент должен вызывать только одну функцию, которая реально может блокировать вызвавшую ее нить, — функцию recv. Но по нашему протоколу сервер не посылает клиенту ничего по собственной инициативе, он только отвечает на сообщения клиента. Следовательно, клиент не должен быть всегда готов принять сообщение, он его принимает только после отправки своего. В простых случаях, когда сообщение имеет небольшой размер, а формирование ответа на сервере не требует длительной работы, мы можем считать, что попытка получения ответа от сервера сразу же после отправки ему сообщения в подавляющем большинстве случаев не будет блокировать работу клиента, а оставшееся незначительное количество случаев считаем форс-мажором и допускаем, что в такой ситуации блокирование будет допустимо. На практика заметить это блокирование можно будет только тогда, когда сервер не будет должным образом отвечать на сообщения или связь с ним будет потеряна. Для простого клиента с невысокими требованиями к надежности такое упрощение вполне допустимо и вполне может быть использовано на практике. А в дальнейшем мы познакомимся со средствами библиотеки сокетов, позволяющими писать программы, в которых работа с сокетами никогда не приводит к блокировке.
Рис. 2.4. Главное окно программы SimpleClient
Таким образом, наш клиент будет очень простым: по кнопке Соединиться он будет соединяться с сервером, по кнопке Отправить — отправлять серверу сообщение и дожидаться ответа. Третья кнопка, Отсоединиться, служит для корректного завершения работы с сервером. Рассмотрим эти действия подробнее.
При соединении с сервером клиент должен создать сокет и вызвать функцию connect. Здесь мы не можем создать сокет один раз и потом пользоваться им на протяжении всего времени работы клиента, т.к. после закрытия соединения (неважно, корректного или из-за ошибки) сокет больше нельзя использовать. Поэтому при установлении соединения каждый раз приходится создавать новый сокет. Обработчик нажатия кнопки Соединиться приведен в листинге 2.16.
Листинг 2.16. Обработчик нажатия кнопки Соединиться
procedure TSimpleClientForm.BtnConnectClick(Sender: TObject);
var
// Адрес сервера
ServerAddr: TSockAddr;
begin
// Формируем адрес сервера, к которому нужно подключиться
FillChar(ServerAddr.sin_zero, SizeOf(ServerAddr.sin_zero), 0);
ServerAddr.sin_family := AF_INET;
ServerAddr.sin_addr.S_addr := inet_addr(PChar(EditIPAddress.Text));
// Для совместимости со старыми версиями Delphi приводим
// константу INADDR_ANY к типу u_long
if ServerAddr.sin_addr.S_addr := u_long(INADDR_NONE)then
begin
MessageDlg('Синтаксическая ошибка в IР-адресе', mtError, [mbOK], 0);
Exit;
end;
try
ServerAddr.sin_port := htons(StrToInt(EditPort.Text));
// Создание сокета
FSocket := socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if FSocket = INVALID_SOCKET then
begin
MessageDlg('Ошибка при создании сокета: '#13#10 +
GetErrorString, mtError, [mbOK], 0);
Exit;
end;
// Подключение к серверу
if connect(FSocket, ServerAddr, SizeOf(ServerAddr)) < 0 then
begin
MessageDlg('Ошибка при установлении подключения: '#13#10 +
GetErrorString, mtError, [mbOK], 0);
// Так как сокет был успешно создан,
// в случае ошибки его нужно удалить
closesocket(FSocket);
FSocket := 0;
Exit;
end;
// Включаем режим "Соединение установлено"
OnConnect;
except
on EConvertError do
// Это исключение может возникнуть только в одном месте -
// при вызове StrToInt(EditPort.Text)
MessageDlg('"' + EditPort.Text + '"не является целым числом',
mtError, [mbOK], 0);
on ERangeError do
// Это исключение может возникнуть только в одном месте -
// при присваивании значения номеру порта
MessageDlg('Номер порта должен находиться в диапазоне 1-65535',
mtError, [mbOK], 0);
end;
end;
Теперь посмотрим, как клиент реагирует на нажатие кнопки Отправить (листинг 2.17). Сама по себе отправка — вещь очень простая: нужно сформировать адрес получателя и вызвать функцию send. Несколько сложнее выполняется чтение данных, потому что, согласно нашему протоколу, клиент не знает, сколько байтов он должен прочитать, и читает до тех пор, пока не встретит символ #0.
Листинг 2.17. Обработчик нажатия кнопки Отправить
procedure TSimpleClientForm.BtnSendClick(Sender: TObject);
const
// Данные из буфера сокета мы будем читать порциями.
// константа BufStep определяет размер порции
BufStep = 10;
var
Str: string
StrLen, BufStart, Portion: Integer;
Buf: array of Char;
begin
Str := EditStringToSend.Text;
StrLen := Length(Str);
if StrLen = 0 then
begin
MessageDlg('Протокол не допускает отправки пустых строк',
mtError, [mbOK], 0);
Exit;
end;
// отправляем серверу длину строки
if send(FSocket, StrLen, SizeOf(StrLen), 0) < 0 then
begin
MessageDlg('Ошибка при отправке данных серверу '#13#10 +
GetErrorString, mtError, [mbOK], 0);
OnDisconnect;
Exit;
end;
// Отправляем серверу строку
if send(FSocket, Str[1], StrLen, 0) < 0 then
begin
MessageDlg('Ошибка при отправке данных серверу: '#13#10 +
GetErrorString, mtError, [mbOK], 0);
OnDisconnect;
Exit;
end;
BufStart := 0;
// Цикл получения ответа от сервера
// завершается, когда получаем посылку, оканчивающуюся на #0
repeat
SetLength(Buf, Length(Buf) + BufStep);
// Читаем очередную порцию ответа от сервера
Portion := recv(FSocket, Buf(BufStart), BufStep, 0);
if Portion <= 0 then
begin
MessageDlg('Ошибка при получении ответа от сервера: '#13#10 +
GetErrorString, mtError, [mbOK], 0);
OnDisconnect;
Exit;
end;
// Если порция кончается на #0, ответ прочитан полностью, выходим из
// цикла. Здесь мы использовали особенность нашего протокола, который
// запрещает серверу присылать несколько строк подряд, следующая
// строка будет выслана сервером только после нового запроса от
// клиента. Если бы протокол допускал отправку сервером нескольких
// ответов подряд, при чтении очередной порции данных могло бы
// оказаться, что начало порции принадлежит одной строке, конец -
// следующей, а признак конца строки нужно искать где-то в середине
if Buf[BufStart + Portion - 1] = #0 then
begin
EditReply.Text := PChar(@Buf[0]);
Break;
end;
Inc(BufStart, BufStep);
until False;
end;
Реакция на кнопку Отсоединиться совсем простая: нужно разорвать соединение и закрыть сокет (листинг 2.18).
Листинг 2.18. Реакция на нажатие кнопки Отсоединиться
procedure TSimpleClientForm.BtnDisconnectClick(Sender: TObject);
begin
shutdown(FSocket, SD_BOTH);
closesocket(FSocket);
OnDisconnect;
end;
Откомпилируем наши примеры и посмотрим, что получилось. Пока у нас один клиент работает с одним сервером, все вполне предсказуемо: клиент передает сообщения, сервер на них отвечает. Попытаемся подключиться вторым клиентом, не отключая первый, и посмотрим, что будет. Само подключение с точки зрения клиента проходит нормально, хотя сервер находится в своем внутреннем цикле и не вызывает accept, для второго клиента. Впрочем, как мы знаем, для успешного выполнения функции connect на стороне клиента достаточно, чтобы сокет сервера находился в режиме прослушивания. Теперь попытаемся отправить что-то серверу со второго клиента. Сама отправка проходит успешно, но при попытке получить ответ клиент "зависает", т.к. функция recv блокирует нить до прихода данных, а данные не приходят, потому что сервер не обрабатывает сообщения от этого клиента. Отсоединим первый клиент от сервера, чтобы сервер вернулся к выполнению функции accept. Мы видим, что сервер немедленно обнаружил подключение второго клиента, а также то, что клиент прислал ему сообщение. Соответственно, сервер отвечает на это сообщение, и второй клиент "отвисает" — теперь с ним можно нормально работать.
Простейший сервер и эксперименты с ним, конечно, очень познавательны, но на практике хотелось бы иметь такой сервер, который может работать одновременно с несколькими клиентами. Чтобы добиться этого, сделаем так же, как при написании UDP-чата: вынесем в отдельные нити работу с блокирующими функциями (пример MultithreadedServer на компакт-диске). Нам понадобится одна нить для выполнения функции accept и по одной нити на работу с каждым подключившимся клиентом. Инициализация выполняется при нажатии кнопки Запустить (листинг 2.19). После инициализации библиотеки сокетов, создания сокета и перевода его в режим прослушивания она создает нить типа TListenThread, передает ей дескриптор сокета и больше с сокетами не работает — дальнейшая роль главной нити заключается только в обработке сообщений. Благодаря этому сервер может иметь нормальный пользовательский интерфейс.
Листинг 2.19. Инициализация многонитевого сервера
// Реакция на кнопку Запустить
procedure TServerForm.BtnStartServerClick(Sender: TObject);
var
// Сокет, который будет "слушать"
ServerSocket: TSocket;
// Адрес, к которому привязывается слушающий сокет
ServerAddr: TSockAddr;
begin
// Формирyем адрес для привязки.
FillChar(ServerAddr.sin_zero, SizeOf(ServerAddr.sin_zero), 0);
ServerAddr.sin_family := AF_INET;
ServerAddr.sin_addr.S_addr := ADDR_ANY;
try
ServerAddr.sin_port := htons(StrToInt(EditPortNumber.Text));
if ServerAddr.sin_port = 0 then
begin
MessageDlg('Номер порта должен находиться в диапазоне 1-65535',
mtError, [mbOK], 0);
Exit;
end;
// Создание сокета
ServerSocket := socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if ServerSocket = INVALID_SOCKET then
begin
MessageDlg('Ошибка при создании сокета: '#13#10 + GetErrorString,
mtError, [mbOK], 0);
Exit;
end;
// Привязка сокета к адресу
if bind(ServerSocket, ServerAddr, SizeOf(ServerAddr)) = SOCKET_ERROR then
begin
MessageDlg('Ошибка при привязке сокета к адресу: '#13#10 +
GetErrorString, mtError, [mbOK], 0);
closesocket(ServerSocket);
Exit;
end;
// Перевод сокета в режим прослушивания
if listen(ServerSocket, SOMAXCONN) = SOCKET_ERROR then
begin
MessageDlg('Ошибка при переводе сокета в режим просушивания:'#13#10 +
GetErrorString, mtError, [mbOK], 0);
closesocket(ServerSocket);
Exit;
end;
// Запуск нити, обслуживающей слушающий сокет
TListenThread.Create(ServerSocket);
// Перевод элементов управления в состояние "Сервер работает"
LabelPortNumber.Enabled := False;
EditРоrtNumber.Enabled := False;
BtnStartServer.Enabled := False;
LabelServerState.Caption := 'Сервер работает';
except
on EConvertError do
// Это исключение может возникнуть только в одном месте
// при вызове StrToInt(EditPortNumber.Text)
MessageDlg('"' + EditPortNumber.Text + '"не является целым числом',
mtError, [mbOK], 0);
on ERangeError do
// это исключение может возникнуть только в одном месте -
// при присваивании значения номеру порта
MessageDlg('Номер порта должен находиться в диапазоне 1-65535',
mtError, [mbOK], 0);
end;
end;
Слушающая" нить TListenThread состоит из бесконечного ожидания подключения клиента. Каждый раз при подключении клиента библиотека сокетов создаёт новый сокет, и для работы с ним создается новая нить типа TClientThread (листинг 2.20).
Листинг 2.20. Код "слушающей" нити
procedure TListenThread.Execute;
// Сокет, созданный для общения с подключившимся клиентом
ClientSocket: TSocket;
// Адрес подключившегося клиента
ClientAddr: TSockAddr;
ClientAddrLen: Integer;
begin
// Начинаем бесконечный цикл
repeat
ClientAddrLen := SizeOf(ClientAddr);
// Ожидаем подключения клиента
ClientSocket := accept(FServerSocket, @ClientAddr, @ClientAddrLen);
if ClientSocket = INVALID_SOCKET then
begin
// Ошибка в функции accept возникает только тогда, когда
// происходит нечто экстраординарное. Продолжать работу
// в этом случае бессмысленно.
LogMessage('Ошибка при подключении клиента: ' + GetErrorString);
Break;
end;
// Создаем новую нить для обслуживания подключившегося клиента
// и передаём ей сокет, созданный для взаимодействия с ним.
TClientThread.Create(ClientSocket, ClientAddr);
until False;
closesocket(FServerSocket);
LogMessage('Сервер завершил работу');
Synchronize(ServerForm.OnStopServer);
end;
Метод LogMessage, существующий у "слушающей" нити, эквивалентен тому, который приведен в листинге 2.7.
Код нити типа TClientThread, которая отвечает за взаимодействие с одним клиентом, приведен в листинге 2.21.
Листинг 2.21. Код нити, реализующей взаимодействие с клиентом
// Сокет для взаимодействия с клиентом создается в главной нити,
// а сюда передается через параметр конструктора. Для формирования
// заголовка сюда же передается адрес подключившегося клиента
constructor TClientThread.Create(ClientSocket: TSocket; const ClientAddr:TSockAddr);
begin
FSocket := ClientSocket;
// Заголовок содержит адрес и номер порта клиента.
// Этот заголовок будет добавляться ко всем сообщениям в лог
// от данного клиента.
FHeader :=
'Сообщение от клиента ' + inet_ntoa(ClientAddr.sin_addr) + ':' +
IntToStr(ntohs(ClientAddr.sin_port)) + ': ';
inherited Create(False);
end;
procedure TClientThread.Execute; var Str: string; StrLen: Integer;
begin
LogMessage('Соединение установлено');
// Начинаем цикл, из которого выходим только при закрытии
// соединения клиентом или из-за ошибки в сети.
repeat
// Читаем длину присланной клиентом строки и помещаем ее в StrLen
case ReadFromSocket(FSocket, StrLen, SizeOf(StrLen)) of
0: begin
LogMessage('Клиент закрыл соединение');
Break;
end;
-1: begin
LogMessage('Ошибка при получении данных от клиента: ' +
GetErrorString);
Break;
end;
end;
// Протокол не допускает строк нулевой длины
if StrLen <= 0 then
begin
LogMessage('Неверная длина строки от клиента: ' +
IntToStr(StrLen));
Break;
end;
// Установка длины строки в соответствии с полученным значением
SetLength(Str, StrLen);
// Чтение строки нужной длины
case ReadFromSocket(FSocket, Str[1], StrLen) of
0: begin
LogMessage('Клиент закрыл соединение');
Break;
end;
-1: begin
LogMessage('Ошибка при получении данных от клиента: ' +
GetErrorString);
Break;
end;
end;
LogMessage('Получена строка: ' + Str);
// Преобразование строки
Str :=
AnsiUpperCase(StringReplace(Str, #0, '#0', [rfReplaceAll]),
' (Multithreaded server)';
// Отправка строки. Отправляется на один байт больше, чем
// длина строки, чтобы завершающий символ #0 тоже попал в пакет
if send(FSocket, Str[1], Length(Str) + 1, 0) < 0 then
begin
LogMessage('Ошибка при отправке данных клиенту: ' +
GetErrorString);
Break;
end;
LogMessage('Клиенту отправлен ответ: ' + Str);
until False;
closesocket(FSocket);
end;
procedure TClientThread.LogMessage(const Msg: string);
begin
FMessage := FHeader + Msg;
Synchronize(DoLogMessage);
end;
Метод LogMessage здесь несколько видоизменен по сравнению с предыдущими примерами: к каждому сообщению он добавляет адрес клиента, чтобы пользователь мог видеть, с каким именно из одновременно подключившихся клиентов связано сообщение. Что же касается кода Execute, то видно, что он практически не отличается от кода внутреннего цикла простейшего сервера (см. листинг 2.15). Это неудивительно — сообщение здесь читается и обрабатывается единым образом. Вся разница только в том, что теперь у нас одновременно могут работать несколько таких нитей, обеспечивая одновременную работу сервера с несколькими клиентами.
Этот сервер уже можно использовать как образец для подражания. Нужно только помнить, что он тратит на каждого клиента относительно много ресурсов, и поэтому не подходит там, где могут подключаться сотни и более клиентов одновременно. Кроме того, этот сервер очень уязвим по отношению к DoS-атакам, поэтому подобный сервер целесообразен там. где число клиентов относительно невелико, а вероятность DoS-атак низка.
Примечание
DoS-атака (Denied of Service) — способ помешать функционированию сервера, заключающийся в загрузке его бесполезной работой. В простейшем случае — это просто одновременное подключение большого числа клиентов. У нас даже простое подключение большого числа клиентов приводит к большому расходу системных ресурсов, поэтому DoS-атакой можно добиться неработоспособности не только самого сервера, но и системы в целом. Полностью защититься от DoS-атаки невозможно, но можно снизить урон, наносимый ею. Об этом мы поговорим далее.
2.1.13. Определение готовности сокета
Так как многие функции библиотеки сокетов блокируют вызвавшую их нить, если соответствующая операция не может быть выполнена немедленно, часто бывает полезно заранее знать, готов ли сокет к немедленному (без блокирования) выполнению той или иной операции. Основным средством определения этого в библиотеке сокетов служит функция select:
function select(nfds: Integer; readfds, writefds, exceptfds: PFDSet; timeout: PTimeVal): LongInt;
Первый параметр этой функции оставлен только для совместимости со старыми версиями библиотеки сокетов: в существующих версиях он игнорируется. Три следующих параметра содержат указатели на множества сокетов (эти множества описываются типом TFDSet), состояние которых должно проверяться. В данном случае понятие множества не имеет ничего общего с типом множество в Delphi. В оригинальной версии библиотеки сокетов, написанной на C, определены макросы, позволяющие очищать такие множества, добавлять и удалять сокеты и определять, входит ли тот или иной сокет в множество. В модуле WinSock эти макросы заменены одноименными процедурами и функциями (листинг 2.22).
Листинг 2.22. Функции для работы с типом TFDSet
// Удаляет сокет Socket из множества FDSet.
procedure FD_CLR(Socket: TSocket; var FDSet: TFDSet);
// Определяет, входит ли сокет Socket в множество FDSet.
function FD_ISSET(Socket: TSocket; var FDSet: TFDSet): Boolean;
// Добавляет сокет Socket в множество FDSet.
procedure FD_SET(Socket: TSocket; var FDSet: TFDSet);
// Инициализирует множество FDSet.
procedure FD_ZERO(var FDSet: TFDSet);
При создании переменной типа TFDSet в той области памяти, которую она занимает, могут находиться произвольные данные, являющиеся, по сути дела, "мусором". Из-за этого мусора функции FD_CLR, FD_ISSET, и FD_SET не смогут работать корректно. Процедура FD_ZERO очищает мусор, создавая пустое множество. Вызов остальных функций FD_XXX до вызова FD_ZERO приведёт к непредсказуемым результатам.
Мы намеренно не приводим здесь описание внутренней структуры типа TFDSet. С помощью функций FD_XXX можно выполнить все необходимые операции с множеством, не зная этой структуры. Отметим, что в Windows и в Unix внутреннее устройство этого типа существенно различается, но благодаря использованию этих функций код остается переносимым.
В Windows максимальное количество сокетов, которое может содержать в себе множество TFDSet, определяется значением константы FD_SETSIZE. По умолчанию ее значение равно 64. В C/C++ отсутствует раздельная компиляция модулей в том смысле, в котором она существует в Delphi, поэтому модуль в этих языках может поменять значение константы FD_SETSIZE перед включением заголовочного файла библиотеки сокетов, и это изменение приведёт к изменению внутренней структуры типа TFDSet (точнее, типа FDSet — в C/C++ он называется так). К счастью, в Delphi модули надежно защищены от подобного влияния друг на друга, поэтому как бы мы ни переопределяли константу FD_SETSIZE в своем модуле, на модуле WinSock это никак не отразится. В Delphi приходится прибегать к другому способу изменения количества сокетов в множестве: для этого следует определить свой тип, эквивалентный по структуре TFDSet, но резервирующий иное количество памяти для хранения сокетов (структуру TFDSet можно узнать из исходного кода модуля WinSock). В функцию select можно передавать указатели на структуры нового типа, необходимо только приведение типов указателей. А вот существующие функции FD_XXX, к сожалению, не смогут работать с новой структурой, потому что компилятор требует строгого соответствия типов для параметров-переменных. Но, опять же, при необходимости очень легко создать аналоги этих функций для своей структуры.
Примечание
На первый взгляд может показаться, что Delphi в данном случае хуже, чем C/C++. Но достаточно хотя бы раз столкнуться с ошибкой, вызванной взаимным влиянием макроопределений в модулях C/C++, чтобы понять, что уж лучше написать несколько лишних строк кода, лишь бы никогда больше не иметь таких проблем.
Последний параметр функции select содержит указатель на структуру TTimeVal, которая описывается следующим образом:
TTimeVal = record
tv_sec: LongInt;
tv_usec: LongInt;
end;
Эта структура служит для задания времени ожидания. Поле tv_sec содержит число полных секунд в этом интервале, поле tv_usec — число микросекунд. Так, чтобы задать интервал ожидания, равный 1,5 с, нужно присвоить полю tv_sec значение 1, а полю tv_usec — значение 500 000. Параметр timeout функции select должен содержать указатель на заполненную подобным образом структуру, определяющую, сколько времени функция будет ожидать, пока хотя бы один из сокетов не будет готов к требуемой операции. Если этот указатель равен nil, ожидание будет бесконечным.
Мы потратили достаточно много времени, выясняя структуру параметров функции select. Теперь, наконец-то, можно перейти к описанию того, зачем она нужна и какой смысл несет каждый из ее параметров.
Функция select позволяет дождаться, когда хотя бы один из сокетов, переданный в одном из множеств, будет готов к выполнению той или иной операции. Какой именно операции, определяется тем, в какое из трех множеств входит сокет. Для сокетов, входящих в множество readfds, готовность означает, что функции recv или recvfrom будут выполнены без блокирования. В случае UDP это означает, что во входном буфере сокета есть данные, которые можно прочитать. При использовании TCP функции recv и recvfrom могут быть выполнены без задержки еще в двух случаях: когда партнер закрыл соединение (в этом случае функции вернут 0), а также когда соединение некорректно разорвано (в этом случае функции вернут SOCKET_ERROR). Кроме того, если сокет, включенный в множество readfds, находится в состоянии ожидания соединения (в которое он переведен с помощью функции listen), то для него состояние готовности означает, что очередь соединений не пуста и функция accept будет выполнена без задержек.
Для сокетов, входящих в множество writefds, готовность означает, что сокет соединен, а в его выходном буфере есть свободное место. (До сих пор мы обсуждали только блокирующие сокеты, для которых успешное завершение функции connect автоматически означает, что сокет соединен. Далее мы познакомимся с неблокирующими сокетами, для которых нужно вызвать функцию select, чтобы понять, установлено ли соединение.) Наличие свободного места в буфере не гарантирует того, что функции send или sendto не будут блокировать вызвавшую их нить, т.к. программа может попытаться передать больший объем информации, чем размер свободного места в буфере на момент вызова функции. В этом случае функции send и sendto вернут управление вызвавшей их нити только после того, как часть данных будет отправлена, и в буфере сокета освободится достаточно места.
Следует отметить, что большинство протоколов обмена устроено таким образом, что при их реализации проблема переполнения выходного буфера практически никогда не возникает. Чаще всего клиент и сервер обмениваются небольшими пакетами, причем сервер посылает клиенту только ответы на его запросы, а клиент не посылает новый запрос до тех пор. пока не получит ответ на предыдущий. В этом случае гарантируется, что пакеты будут уходить о выходного буфера быстрее (или, по крайней мере, не медленнее), чем программа будет их туда помещать. Поэтому заботиться о том, чтобы в выходном буфере было место, приходится достаточно редко.
И наконец, последнее множество exceptfds. Для сокетов, входящих в это множество, состояние готовности означает либо неудачу попытки соединения для неблокирующего сокета, либо получение высокоприоритетных данных (out-of-band data). В этой книге мы не будем детально рассматривать отправку и получение высокоприоритетных данных. Те, кому это понадобится, легко разберутся с этим вопросом по MSDN.
Функция select возвращает общее количество сокетов, находящихся в состоянии готовности. Если функция завершила работу по тайм-ауту, возвращается 0. Множества readfds, writefds и exceptfds модифицируются функцией: в них остаются только те сокеты, которые находятся в состоянии готовности. При вызове функции любые два из этих трех указателей могут быть равны nil, если программу не интересует готовность сокетов по соответствующим критериям. Один и тот же сокет может входить в несколько множеств.
В листинге 2.23 приведен пример кода TCP-сервера, взаимодействующего с несколькими клиентами в рамках одной нити и работающего по простой схеме "запрос-ответ".
Листинг 2.23. Пример сервера, использующего select
var
Sockets: array of TSocket;
Addr: TSockAddr;
Data: TWSAData;
Len, I, J: Integer;
FDSet: TFDSet;
begin
WSAStartup($101, Data);
SetLength(Sockets, 1);
Sockets[0] := socket(AF_INET, SOCK_STREAM, 0);
Addr.sin_family := AF_INET;
Addr.sin_port := htons(5514);
Addr.sin_addr.S_addr := INADDR_ANY;
FillChar(Addr.sin_zero, SizeOf(Addr.sin_zero), 0);
bind(Sockets[0], Addr, SizeOf(TSockAddr));
listen(Sockets[0], SCMAXCONN);
while True do
begin
// 1. Формирование множества сокетов
FD_ZERO(FDSet);
for I := 0 to High(Sockets) do FDSET(Sockets[1], FDSet);
// 2. Проверка готовности сокетов
select(0, @FDSet, nil, nil, nil);
// 3. Чтение запросов клиентов тех сокетов, которые готовы к этому
I := 1;
while I <= High(Sockets) do
begin
if FD_ISSET(Sockets[I], FDSet) then if recv(Sockets[I], ...) <= 0 then
begin
// Связь разорвана, нужно закрыть сокет
// и удалить его из массива
closesocket(Sockets[I]);
for J := I to High(Sockets) - 1 do Sockets[J] := Sockets[J + 1];
Dec(I);
SetLength(Sockets, Length(Sockets) -1);
end
else
begin
// Получены данные от клиента, нужно ответить
send(Sockets[I], ...);
end;
Inc(I);
end;
// 4. Проверка подключения нового клиента
if FD_ISSET(Sockets[0], FDSet) then
begin
// Подключился новый клиент
SetLength(Sockets, Length(Sockets) + 1);
Len := SizeOf(TSockAddr);
Sockets[High(Sockets)] := accept(Sockets[0], @Addr, @Len)
end;
end;
end;
Как и в предыдущих примерах, код для краткости не содержит проверок успешности завершения функций. Еще раз напоминаем, что в реальном коде такие проверки необходимы.
Теперь разберем программу по шагам. Создание сокета, привязка к адресу и перевод в режим ожидания подключений вам уже знакомы, поэтому мы на них останавливаться не будем. Отметим только, что вместо переменной типа TSocket мы формируем динамический массив этого типа, длина которого сначала устанавливается равной одному элементу, и этот единственный элемент и содержит дескриптор созданного сокета. В дальнейшем мы будем добавлять в этот массив сокеты, создающиеся в результате выполнения функции accept. После перевода сокета в режим ожидания подключения начинается бесконечный цикл, состоящий из четырех шагов.
На первом шаге цикла создаётся множество сокетов, в которое добавляются все сокеты, содержащиеся в массиве. В этом месте в примере пропущена важная проверка того, что сокетов в массиве не больше 64-х. Если их будет больше, то попытки добавить лишние сокеты в множество будут проигнорированы функцией FD_SET и, соответственно, эти сокеты выпадут из дальнейшего рассмотрения, т.е. даже если клиент что-то пришлет, сервер этого не увидит. Решить проблему можно тремя способами. Самый простой — это отказывать в подключении лишним клиентам. Для этого сразу после вызова accept нужно вызывать для нового сокета closesocket. Второй способ — это увеличение количества сокетов в множестве, как это было описано ранее. В этом случае все равно остается та же проблема, хотя если сделать число сокетов в множестве достаточно большим, она практически исчезает. И наконец, можно разделить сокеты на несколько порций, для каждой из которых вызывать select отдельно. Это потребует усложнения примера, потому что сейчас в функции select мы используем бесконечное ожидание. При разбиении сокетов на порции это может привести к тому, что из-за отсутствия готовых сокетов в первой порции программа не сможет перейти к проверке второй порции, в которой готовые сокеты, может быть, есть. Пример разделения сокетов на порции будет рассмотрен в следующем разделе.
При создании множества оно сначала очищается, а потом в него в цикле добавляются сокеты. Для любителей кратких решений есть существенно более быстрый способ формирования множества, при котором не потребуются ни циклы, ни FD_ZERO, ни FD_SET:
Move((PChar(Sockets) - 4)^, FDSet, Length(Sockets) * SizeOf(TSocket) + SizeOf(Integer));
Почему такая конструкция будет работать, предлагаем разобраться самостоятельно, изучив по справке Delphi, как хранятся в памяти динамические массивы, а по MSDN — структуру типа FDSET. Тем же, кто по каким-то причинам не захочет разбираться, настоятельно рекомендуем никогда и ни при каких обстоятельствах не использовать такую конструкцию, потому что в неумелых руках она превращается в мину замедленного действия, из-за которой ошибки могут появиться в самых неожиданных местах программы.
Второй шаг — это собственно выполнение ожидания готовности сокетов с помощью функции select. Готовность к записи и к чтению высокоприоритетной информации нас в данном случае не интересует, поэтому мы ограничиваемся заданием множества readfds. В нашем простом примере не должно выполняться никаких действий, если ни один сокет не готов, поэтому последний параметр тоже равен nil, что означает ожидание, не ограниченное тайм-аутом.
Третий шаг выполняется только после функции select, т.е. тогда, когда хотя бы один из сокетов находится в состоянии готовности. На этом шаге мы проверяем сокеты, созданные для взаимодействия с клиентами на предыдущих итерациях цикла с помощью функции accept. Эти сокеты располагаются в массиве сокетов, начиная с элемента с индексом 1. Программа в цикле просматривает все сокеты и, если они находятся в состоянии готовности, выполняет операцию чтения.
На первый взгляд может показаться странным, почему для перебора элементов массива выбран цикл while, а не for. Но в дальнейшем мы увидим, что размер массива во время выполнения цикла может изменяться. Особенность же цикла for заключается в том, что его границы вычисляются один раз и запоминаются в отдельных ячейках памяти, и дальнейшее изменение значений выражений, задающих эти границы, не изменяет эти границы. В нашем примере это приведет к тому, что в случае уменьшения массива цикл for не остановится на реальной уменьшившейся длине, а продолжит выполнение по уже не существующим элементам, что приведет к трудно предсказуемым последствиям. Поэтому в данном случае предпочтительнее цикл while, в котором условие продолжения цикла заново вычисляется при каждой его итерации.
Напомним, что функция select модифицирует переданные ей множества таким образом, что в них остаются лишь сокеты, находящиеся в состоянии готовности. Поэтому чтобы проверить, готов ли конкретный сокет, достаточно с помощью функции FD_ISSET проверить, входит ли он в множество FDSet. Если входит, то вызываем для него функцию recv. Если эта функция возвращает положительное значение, значит, данные в буфере есть, программа их читает и отвечает. Если функция возвращает 0 или -1 (SOCKET_ERROR) значит, соединение закрыто или разорвано, и данный сокет больше не может быть использован. Поэтому мы должны освободить связанные с ним ресурсы (closesocket) и убрать его из массива сокетов (как раз на этом шаге размер массива уменьшается). При удалении оставшиеся сокеты смещаются на одну позицию влево, поэтому переменную цикла необходимо уменьшить на единицу, иначе следующий сокет будет пропущен.
И наконец, на четвертом шаге мы проверяем состояние готовности исходного сокета, который хранится в нулевом элементе массива. Так как этот сокет находится в режиме ожидания соединения, для него состояние готовности означает, что в очереди соединений появились клиенты, и необходимо вызвать функцию accept, чтобы создать сокеты для взаимодействия с этими клиентами.
Хотя приведенный пример вполне работоспособен, следует отметить, что это только один из возможных вариантов организации сервера. Так что лучше не относиться к нему как к догме, потому что именно в вашем случае может оказаться предпочтительнее какой-либо другой вариант. Ценность этого примера заключается в том, что он иллюстрирует работу функции select, а не в том, что он дает готовое решение на все случаи жизни.
2.1.14. Примеры использования функции select
Рассмотрим два практических примера использования функции select для получения информации о готовности сокета. Оба примера станут развитием рассмотренных ранее.
Сначала модифицируем UDP-чат (см. разд. 2.1.10) таким образом, чтобы он использовал один сокет и для отправки, и для получения сообщений (пример SelectChat на компакт-диске). Вторая нить нам теперь не понадобится, всё будет делать главная форма. Процедуры создания сокета и отправки сообщений изменений не претерпели, главное дополнение — это то, что на форме появился таймер, в обработчике события OnTimer которого мы будем проверять с помощью select, пришло ли сообщение для сокета (листинг 2.24). С помощью таких простейших модификаций мы получили чат, который работает без распараллеливания и использует всего один сокет. Работать с таким чатом стало намного проще, потому что теперь ответ нужно посылать на тот же порт, с которого пришло сообщение, а не запоминать, какой порт для отправки какому из экземпляров чата соответствует.
Примечание
Несмотря на эти изменения, новая версия UDP-чата может обмениваться сообщениями со старой, т.к. протокол обмена остался неизменным.
Листинг 2.24. Проверка готовности сокетов при обработке сообщения от таймера
// Реакция на таймер. С периодичностью, заданной таймером,
// проверяем, не пришли ли сообщения, и если пришли,
// получаем их.
procedure TChatForm.TimerChatTimer(Sender: TObject);
var
// Множество сокетов для функции select.
// Будет содержать только один сокет FSocket.
SocketSet: TFDSet;
// Тайм-аут для функции select
Timeout: TTimeVal;
// Буфер для получения сообщения.
// Размер равен максимальному размеру UDP-дейтаграммы
Buffer: array[0..65506] of Byte;
Msg: string;
// Адрес, с которого пришло сообщение
RecvAddr: TSockAddr;
RecvLen, AddrLen: Integer;
begin
// Инициализируем множество сокетов,
// т.е. очищаем его от случайного мусора
FD_ZERO(SocketSet);
// Добавляем в это множество сокет FSocket
FD_SET(FSocket, SocketSet);
// Устанавливаем тайм-аут равным нулю, чтобы
// функция select ничего не ждала, а возвращала
// готовность сокетов на момент вызова.
Timeout.tv_sec := 0;
Timeout.tv_usec := 0;
// Проверяем готовность сокета для чтения
if select(0, @SocketSet, nil, nil, @Timout) = SOCKET_ERROR then
begin
AddMessageToLog('Ошибка при проверке готовности сокета: ' + GetErrorString);
Exit;
end;
// Проверяем, оставила ли функция select сокет в множестве.
//Если оставила, значит, во входном буфере сокета есть данные.
if FD_ISSET(FSocket, SocketSet) then
begin
AddrLen := SizeOf(RecvAddr); // Получаем дейтаграмму
RecvLen :=
recvfrom(FSocket, Buffer, SizeOf(Buffer), 0, RecvAddr, AddrLen);
// Так как UDP не поддерживает соединение, ошибку при вызове recvfrom
// мы можем получить, только если случилось что-то совсем
// экстраординарное.
if RecvLen < 0 then
begin
AddMessageToLog('Ошибка при получении сообщения: ' +
GetErrorString);
Exit;
end;
// Устанавливаем нужный размер строки
SetLength(Msg, RecvLen);
// и копируем в неё дейтаграммы из буфера
if RecvLen > 0 then Move(Buffer, Msg[1], RecvLen);
AddMessageToLog('Сообщение с адреса ' + inet_ntoa(RecvAddr.sin_port) +
':' + IntToStr(ntohs(RecvAddr.sin_port)) + ': ' + Msg);
end;
end;
Обратите внимание, что в обработчике события от таймера читается только одно сообщение, хотя за время, прошедшее с предыдущего вызова этого обработчика, в принципе, могло прийти несколько сообщений. Если запустить два экземпляра чата на одном компьютере, и с одного из них послать несколько сообщений подряд другому (добиться этого можно, несколько раз быстро нажав на кнопку Отправить), то адресат получит сообщения последовательно, с полусекундной задержкой между ними. Было бы достаточно просто организовать в обработчике сообщения таймера цикл до тех пор, пока функция select не покажет, что сокет не готов к чтению, и извлечь за один раз сразу все сообщения, которые накопились в буфере сокета. Этого не сделано, чтобы уменьшить уязвимость чата по отношению к действиям потенциального злоумышленника. Имеется в виду та разновидность DoS-атаки, когда злоумышленник посылает большой поток сообщений, чтобы парализовать работу чата. Работа в этом случае, конечно же, будет парализована независимо от того, будет ли в обработчике события таймера извлекаться одно сообщение или все сразу — все равно чат будет замусорен бессмысленными сообщениями. Но в первом случае между показом сообщений будут интервалы, и пользователь хотя бы сможет корректно закрыть программу. Во втором же случае, если злоумышленник посылает сообщения достаточно быстро, цикл может оказаться бесконечным, обработка других оконных сообщений прекратится, и пользователь вынужден будет снять задачу средствами системы. Таким образом, извлечение только одного сообщения за один раз снижает ущерб от атаки. (Разумеется, вряд ли кто-то всерьез захочет атаковать наш учебный пример, но эту возможность следует учитывать при разработке более серьезных приложений.)
Перейдем к следующему примеру использования select — TCP-серверу, который может работать одновременно с неограниченным числом клиентов (пример находится на компакт-диске в папке SelectServer). Этот сервер будет усовершенствованной версией нашего простейшего сервера (см. разд. 2.1.12) и тоже будет консольным приложением (функция select, как мы видели на примере UDP-чата, позволяет создавать приложения с графическим интерфейсом пользователя, так что реализация сервера в качестве консольного приложения — это не необходимость, а свободный выбор для иллюстрации различных способов применения функции select).
Примечание
Разумеется, ни один сервер не может работать с неограниченным числом клиентов. Здесь и далее под словом "неограниченный" подразумевается то, что количество клиентов сервера ограничивается только ресурсами системы, а не самой реализацией сервера.
Инициализация сокета и установка его в режим прослушивания в новом сервере ничем не отличается от простейшего, изменения начинаются только с цикла. Теперь цикл только один (вложенные циклы в нем есть, но они выполняют чисто техническую роль). Начинается цикл с того, что с помощью функции select определяется готовность к чтению слушающего сокета. Если слушающий сокет готов к чтению, то в данном случае это означает, что есть клиенты, которые уже подключились к серверу, но еще не были обработаны функцией accept. Если такие клиенты есть, то сервер принимает подключение, причем только одно за одну итерацию цикла. Для каждого подключившегося клиента сервер создает экземпляр записи TConnection, которая описана в листинге 2.25.
Листинг 2.25. Описание типа TConnection
// запись TConnection хранит информацию о подключившемся клиенте.
// поле ClientAddr содержит строковое представление адреса клиента.
// Поле ClientSocket содержит сокет, созданный функцией accept
// для взаимодействия с данным клиентом.
// Поле Deleted - служебное. Если оно равно False, значит,
// соединение с данным клиентом по каким-то причинам потеряно,
// и сервер должен освободить ресурсы, выделенные для этого клиента.
PConnection = ^Connection;
TConnection = record
ClientAddr: string;
ClientSocket: TSocket;
Deleted: Boolean;
end;
Поле ClientAddr хранит строковое представление адреса клиента в виде "X.X.X.X:Port" — это поле используется только при выводе сообщений, связанных с данным клиентом. Поле ClientSocket содержит сокет, созданный для связи с данным клиентом. Поле Deleted необходимо для того, чтобы упростить удаление записей для тех клиентов, соединение с которыми уже потеряно. Список соединений хранится в глобальной переменной FConnections типа TList. Потеря соединения обнаруживается при попытке чтения или отправки данных через сокет. Если в одном цикле делать и попытки чтения, и удаление ненужных записей, этот цикл усложняется, и в нем легко сделать ошибку в индексах. Чтобы избежать этого, в "читающем" цикле те записи, для которых потеряно соединение, просто помечаются как удаленные с помощью свойства Deleted. Затем другой цикл удаляет все записи, помеченные для удаления.
После проверки новых подключений начинается проверка получения сообщений от тех клиентов, которые уже подключены. Для этого перебираются сокеты из списка подключений и для каждого вызывается select. Чтобы повысить производительность, сокеты проверяются не по одному, а группами. Как уже было сказано, множество типа TFDSet может содержать не более FD_SETSIZE сокетов, а в нашем списке их может оказаться больше. Приходится разбивать сокеты на группы размером по FD_SETSIZE и для каждой группы вызывать select отдельно.
Для тех сокетов, которые готовы к чтению, вызывается процедура ProcessSocketMessage. Ее код практически полностью совпадает с кодом одной итерации внутреннего цикла примера SimplestServer (см. листинг 2.15), т.е. процедура сначала читает размер строки, затем — саму строку, после этого формирует ответ и отправляет его клиенту. Реализуя эту функцию таким образом, мы пошли на некоторый риск блокировки, потому что функция select информирует только о том, что во входном буфере сокета есть хоть что-то, но вовсе не гарантирует, что там лежит уже все сообщение целиком. Наша же функция реализована таким образом, что она завершается либо после прочтения сообщения целиком, либо после обнаружения ошибки. Тем не менее в простых случаях можно пойти на такой риск, потому что, во-первых, короткие сообщения редко разбиваются на части, а во-вторых, если даже такое произойдет, оставшаяся часть сообщения, скорее всего, догонит первую достаточно быстро, и блокировка долгой не будет, так что риск при нормальной работе сети и клиента не очень велик.
Примечание
Эта ситуация отличается от использования select для UDP-сокетов. С ними такой проблемы не возникает, т.к. дейтаграмма никогда не приходит по частям, и если функция select показала готовность сокета. значит, уже получено все сообщение целиком.
Завершается основной цикл сервера удалением всех ресурсов, связанных с закрытыми соединениями. После небольшой паузы, сделанной для того, чтобы сервер не нагружал процессор непрерывно, управление передается на начало цикла (листинг 2.26).
Листинг 2.26. Основная часть сервера SelectServer
// Тайм-аут для функции select, хотя и передается через указатель,
// является для нее входным параметром, который не изменяется.
// Так как у нас везде будет использоваться один и тот же нулевой
// тайм-аут, можем один раз задать значение переменной Timeout
// и в дальнейшем всегда им пользоваться.
Timeout.tv_sec := 0;
Timeout.tv_usec := 0;
// Начало цикла подключения и общения с клиентами
repeat
// Сначала проверяем, готов ли слушающий сокет.
// Если он готов, это означает, что есть подключившийся,
// но не обработанный функцией accept клиент
FD_ZERO(SockSet);
FD_SET(MainSocket, SockSet);
if select(0, @SockSet, nil, nil, @Timeout) = SOCKET_ERROR then
raise ESocketException.Create('Ошибка при проверке готовности слушающего сокета: ' +
GetErrorString);
// Если функция select оставила MainSocket в множестве, значит,
// зафиксировано подключение клиента, и функция accept не приведет
// к блокированию нити.
if FD_ISSET(MainSocket, SockSet) then
begin
ClientSockAddrLen := SizeOf(ClientSockAddr);
// Принимаем подключившегося клиента. Для общения с ним создается
// новый сокет, дескриптор которого помещается в ClientSocket.
ClientSocket :=
accept(MainSocket, @ClientSockAddr, @ClientSockAddrLen);
if ClientSocket = INVALID_SOCKET then raise
ESocketException.Create(
'Ошибка при ожидании подключения клиента: ' + GetErrorString);
// Создаем в динамической памяти новый экземпляр TConnection
// и заполняем его данными, соответствующими подключившемуся клиенту
New(NewConnection);
NewConnection.ClientSocket := ClientSocket;
NewConnection.ClientAddr :=
Format('%u.%u.%u.%u:%u',
Ord(ClientSockAddr.sin_addr.S_un_b.s_bl),
Ord(ClientSockAddr.sin_addr.S_un_b.s_b2),
Ord(ClientSockAddr.sin_addr.S_un_b.s_b3),
Ord(ClientSockAddr.sin_addr.S_un_b.s_b4),
ntohs(ClientSockAddr.sin_port));
NewConnection.Deleted := False;
// Добавляем соединение в список
Connections.Add(NewConnection);
WriteLn(OemString('Зафиксировано подключение с адреса ' +
NewConnection.ClientAddr));
end;
// Теперь проверяем готовность всех сокетов подключившихся клиентов.
// Так как множество SockSet не может содержать более чем FT_SETSIZE
// элементов, а размер списка Connections мы нигде не ограничиваем,
// приходится разбивать Connections на "куски" размером не более
// FD_SETSIZE и обрабатывать этот список по частям.
// Поэтому у нас появляется два цикла - внешний, который повторяется
// столько раз, сколько у нас будет кусков, и внутренний, который
// повторяется столько раз, сколько элементов в одном куске.
for J := 0 to Ceil(Connections.Count, FD_SETSIZE) - 1 do
begin
FD_ZERO(SockSet);
for I := FD_SETSIZE * J to Min(FD_SETSIZE * (J + 1) - 1, Connections.Count - 1) do
FD_SET(PConnection(Connections[I])^.ClientSocket, SockSet);
if select(0, @SockSet, nil, nil, @Timeout) = SOCKET_ERROR then
raise ESocketException.Create(
'Ошибка при проверке готовности сокетов: ' + GetErrorString);
// Проверяем, какие сокеты функция select оставила в множестве,
// и вызываем для них ProcessSocketMessage. В этом есть некоторый
// риск, т.к. для того, чтобы select оставила сокет в множестве,
// достаточно, чтобы он получил хотя бы один байт от клиента,
// а не все сообщение. Поэтому может возникнуть такая ситуация,
// когда сервер получил только часть сообщения, но уже пытается
// прочитать сообщение целиком. Это приведет к блокированию нити,
// но вероятность блокирования на долгое время мы оцениваем как
// крайне низкую, т.к. оставшаяся часть сообщения, скорее всего,
// придет достаточно быстро, и поэтому идем на такой риск.
for I := FD_SETSIZE * J to Min(FD_SETSIZE * (J + 1) - 1, Connections.Count - 1) do
if FD_ISSET(PConnection(Connections[I])^.ClientSocket, SockSet) then
ProcessSocketMessage(PConnection(Connections[I])^);
end;
// Проверяем поле Deleted у всех соединений. Те, у которых
// оно равно True, закрываем: закрываем сокет, освобождаем память,
// удаляем указатель из списка. Цикл идет с конца списка к началу,
// потому что в ходе работы цикла верхняя граница списка
// может меняться, и цикл for снизу вверх мог бы привести
// к появлению индексов вне диапазона.
for I := Connections.Count - 1 downto 0 do
if PConnection(Connections[I])^.Deleted then
begin
closesocket(PConnection(Connections[I])^.ClientSocket);
Dispose(PConnection(Connections[I]));
Connections.Delete(I);
end;
Sleep(100);
until False;
Функции Ceil и Min, которые встречаются здесь, можно было бы заменить одноимёнными функциями из модуля Math. Но этот модуль входит не во все варианты поставки Delphi, и чтобы пример можно было откомпилировать в любом варианте поставки Delphi, мы описали их здесь самостоятельно (листинг 2.27).
Листинг 2.27. Функции Ceil и Min
// Функция Ceil возвращает наименьшее целое число X, удовлетворяющее
// неравенству X >= А / В
function Ceil(A, B: Integer): Integer;
begin
Result := A div B;
if A mod В <> 0 then Inc(Result);
end;
// Функция Min возвращает меньшее из двух чисел
function Min(А, В: Integer): Integer;
begin
if A < В then Result := A
else Result := B;
end;
Получившийся сервер более устойчив к DoS-атакам, чем написанный ранее многонитевой сервер. Так как он обходится одной нитью, планировщик задач не перегружается при большом числе подключившихся клиентов. DoS-атака заставляет расходовать только ресурсы библиотеки сокетов и процессорное время, причем вредный эффект последнего легко уменьшить, установив процессу сервера низкий приоритет.
Однако сервер имеет другую уязвимость, связанную с возможным отступлением от протокола обмена клиентом (случайным или злонамеренным). Если клиент, например, пришлет всего один байт и на этом остановится, не разрывая связь с сервером, то при попытке получить сообщение от такого клиента сервер окажется заблокированным, т.к. будет ожидать как минимум четырех байтов (длина строки). Это полностью парализует работу сервера, потому что его единственная нить окажется заблокированной, и обрабатывать сообщения от других клиентов он не сможет.
Примечание
Многонитевой сервер в этом отношении надежнее: некорректное сообщение клиента заблокирует только ту нить, которая взаимодействует с этим клиентом, никак не влияя на остальные нити, работающие с другими клиентами.
Сделать сервер более устойчивым к некорректным действиям клиента можно, если каждый раз читать ровно столько байтов, сколько пришло. Это усложнит сервер, т.к. придется между "сеансами связи с клиентом" помнить сколько байтов было прочитано в прошлый раз. Однако это поможет полностью избежать блокировок при операциях чтения, что существенно повысит надежность сервера. В этом разделе мы не будем рассматривать соответствующий пример, а реализуем эту возможность в следующем сервере, использующем неблокирующие сокеты. В сервере на основе select это делается совершенно аналогично.
2.1.15. Неблокирующий режим
Ранее мы столкнулись с функциями, которые могут надолго приостановить работу вызвавшей их нити, если действие не может быть выполнено немедленно. Это функции accept, recv, recvfrom, send, sendto и connect (в дальнейшем в этом разделе мы не будем упоминать функции recvfrom и sendto, потому что они в смысле блокирования эквивалентны функциям recv и send соответственно, и все, что будет здесь сказано о recv и send, применимо к recvfrom и sendto). Такое поведение не всегда удобно вызывающей программе, поэтому в библиотеке сокетов предусмотрен особый режим работы сокетов — неблокирующий. Этот режим может быть установлен или отменен дм каждого сокета индивидуально с помощью функции ioctlsocket, имеющей следующий прототип:
function ioctlsocket(s: TSocket; cmd: DWORD; var arg: u_long): Integer;
Данная функция предназначена для выполнения нескольких логически мало связанных между собой действий. Возможно, у разработчиков первых версий библиотеки сокетов были причины экономить на количестве функций, потому что мы и дальше увидим, что иногда непохожие операции выполняются одной функцией. Но вернемся к ioctlsocket. Ее параметр cmd определяет действие, которое выполняет функция, а также смысл параметра arg. Допустимы три значения параметра cmd: SIOCATMARK, FIONREAD и FIONBIO. При задании SIOCATMARK параметр arg рассматривается как выходной: в нем возвращается ноль, если во входном буфере сокета имеются высокоприоритетные данные, и ненулевое значение, если таких данных нет (как уже было оговорено, мы в этой книге не будем касаться передачи высокоприоритетных данных).
При cmd, равном FIONREAD, в параметре arg возвращается размер данных, находящихся во входном буфере сокета, в байтах. При использовании TCP это число равно максимальному количеству информации, которое можно получить на данный момент за один вызов recv. Для UDP это значение равно суммарному размеру всех находящихся в буфере дейтаграмм (напомним, что прочитать несколько дейтаграмм за один вызов recv нельзя). Функция ioctlsocket с параметром FIONREAD может использоваться для проверки наличия данных с целью избежать вызова recv тогда, когда это может привести к блокированию, или для организации вызова recv в цикле до тех пор, пока из буфера не будет извлечена вся информация.
При задании аргумента FIONBIO параметр arg рассматривается как входной. Если его значение равно нулю, сокет будет переведен в блокирующий режим, если не равно нулю — в неблокирующий. Таким образом, чтобы перевести который сокет s в неблокирующий режим, нужно выполнить следующие действия (листинг 2.28).
Листинг 2.28. Перевод сокета в неблокирующий режим
var
S: TSocket;
Arg: u_long;
begin
...
Arg := 1;
ioctlsocket(S, FIONBIO, Arg);
Пока программа использует только стандартные сокеты (а не сокеты Windows), сокет может быть переведен в неблокирующий или обратно в блокирующий режим в любой момент. Неблокирующим может быть сделан любой сокет (серверный или клиентский) независимо от протокола.
Функция ioctlsocket возвращает нулевое значение в случае успеха и ненулевое — при ошибке. В примере, как всегда, проверка результата для краткости опущена.
Итак, по умолчанию сокет работает в блокирующем режиме. С особенностями работы функций accept, connect, recv и send в этом режиме мы уже познакомились. Теперь рассмотрим то, как они ведут себя в неблокирующем режиме. Для этого сначала вспомним, когда эти функции блокируют вызвавшую их нить.
□ accept — блокирует нить, если на момент ее вызова очередь подключений пуста.
□ connect — в случае TCP блокирует сокет практически всегда, потому что требуется время на установление связи с удаленным сокетом. Без блокирования вызов connect выполняется только в том случае, если какая-либо ошибка не дает возможности приступить к операции установления связи. Также без блокирования функция connect выполняется при использовании UDP, потому что в данном случае она только устанавливает фильтр для адресов.
□ recv — блокирует нить, если на момент вызова входной буфер сокета пуст.
□ send — блокирует нить, если в выходном буфере сокета недостаточно места, чтобы скопировать туда переданную информацию.
Если условия, при которых эти функции выполняются без блокирования, выполнены, то их поведение в блокирующем и неблокирующем режимах идентично. Если же выполнение операции без блокирования невозможно, функции возвращают результат, указывающий на ошибку . Чтобы понять, произошла ли ошибка из-за необходимости блокирования или из-за чего-либо еще. программа должна вызвать функцию WSAGetLastError. Если она вернет WSAEWOULDBLOCK, значит, никакой ошибки не было, но выполнение операции без блокирования невозможно. Закрывать сокет и создавать новый после WSAEWOULDBLOCK, разумеется, не нужно, т.к. ошибки не было, и связь (в случае TCP) осталась неразорванной.
Следует отметить, что при нулевом выходном буфере сокета (т.е. когда функция send передаст данные напрямую в сеть) и большом объеме информации функция send может выполняться достаточно долго, т.к. эти данные отправляются по частям, и на каждую часть в рамках протокола TCP получаются подтверждения. Но эта задержка не считается блокированием, и в данном случае send будет одинаково вести себя с блокирующими и неблокирующими сокетами, т.е. вернет управление программе лишь после того, как все данные окажутся в сети.
Для функций accept, recv и send WSAEWOULDBLOCK означает, что операцию следует повторить через некоторое время, и, может быть, в следующий раз она не потребует блокирования и будет выполнена. Функция connect в этом случае начинает фоновую работу по установлению соединения. О завершении этой работы можно судить по готовности сокета, которая проверяется с помощью функции select. Листинг 2.29 иллюстрирует это.
Листинг 2.29. Установление связи при использовании неблокирующего сокета
var
S: TSocket;
Block: u_long;
SetW, SetE: TFDSet;
begin
S :=socket(AF_INET, SOCK_STREAM, 0);
...
Block := 1;
ioctlsocket(S, FIONBIO, Block);
connect(S, ...);
if WSAGetLastError <> WSAEWOULDBLOCK then
begin
// Произошла ошибка
raise ...
end;
FD_ZERO(SetW);
FD_SET(S, SetW);
FD_ZERO(SetE);
FD_SET(S, SetE);
select(0, nil, @SetW, @SetE, nil);
if FD_ISSET(S, SetW) then
// Connect выполнен успешно
else if FD_ISSET(S, SetE) then
// Соединиться не удалось
else
// Произошла еще какая-то ошибка
Напомним, что сокет, входящий в множество SetW, будет считаться готовым, если он соединен, а в его выходном буфере есть место. Сокет, входящий в множество SetE, будет считаться готовым, если попытка соединения не удалась. До тех пор, пока попытка соединения не завершилась (успехом или неудачей), ни одно из этих условий готовности не будет выполнено. Таким образом, в данном случае select завершит работу только после того, как будет выполнена попытка соединения, и о результатах этой попытки можно будет судить по тому, в какое из множеств входит сокет.
Из приведенного примера не видно, какие преимущества дает неблокирующий сокет по сравнению с блокирующим. Казалось бы, проще вызвать connect в блокирующем режиме, дождаться результата и лишь потом переводить сокет в неблокирующий режим. Во многих случаях это действительно может оказаться удобнее. Преимущества соединения в неблокирующем режиме связаны с тем, что между вызовами connect и select программа может выполнить какую-либо полезную работу, а в случае блокирующего сокета программа будет вынуждена сначала дождаться завершения работы функции connect и лишь потом сделать что-то еще.
Функция send для неблокирующего сокета также имеет некоторые специфические черты поведения. Они проявляются, когда свободное место в выходном буфере есть, но его недостаточно для хранения данных, которые программа пытается отправить с помощью этой функции. В этом случае функция send, согласно документации, может скопировать в выходной буфер такой объем данных, для которого хватает места. При этом она вернет значение, равное этому объему (оно будет меньше, чем значение параметра len, заданного программой). Оставшиеся данные программа должна отправить позже, вызвав еще раз функцию send. Такое поведение функции send возможно только при использовании TCP. В случае UDP дейтаграмма никогда не разделяется на части, и если в выходном буфере не хватает места для всей дейтаграммы, то функция send возвращает ошибку, a WSAGetLastError — WSAEWOULDBLOCK.
Сразу отметим, что, хотя спецификация допускает частичное копирование функцией send данных в буфер сокета, на практике такое поведение наблюдать пока не удалось: все эксперименты показали, что функция send всегда либо копирует данные целиком, расширяя при необходимости буфер, либо дает ошибку WSAEWOULDBLOCK. Далее этот вопрос будет обсуждаться подробнее. Тем не менее при написании программ следует учитывать возможность частичного копирования, т.к. оно может появиться в тех условиях или в тех реализациях библиотеки сокетов, которые в наших экспериментах не были проверены.
2.1.16. Сервер на неблокирующих сокетах
В этом разделе мы создадим сервер, основанный на неблокирующих сокетах. Это будет наш первый сервер, не использующий функцию ReadFromSocket (см. листинг 2.13). Этот сервер (пример NonBlockingServer на компакт-диске) состоит из одной нити, которая никогда не будет блокироваться сокетными операциями, т.к. все сокеты используют неблокирующий режим. На форме находится таймер, по сигналам которого сервер выполняет попытки чтения данных с сокетов всех подключившихся клиентов. Если данных нет, функция recv немедленно завершается с ошибкой WSAEWOULDBLOCK, и сервер переходит к попытке чтения из следующего сокета.
Запуск сервера (листинг 2.30) мало чем отличается от запуска многонитевого сервера (см. листинг 2.19). Практически вся разница заключается в том, что вместо запуска "слушающей" нити сокет переводится в неблокирующий режим и включается таймер.
Листинг 2.30. Инициализация сервера на неблокирующих сокетах
// Реакция на кнопку "Запустить" - запуск сервера
procedure TServerForm.BtnStartServerClick(Sender: TObject);
var
// Адрес, к которому привязывается слушающий сокет
ServerAddr: TSockAddr;
NonBlockingArg: u_long;
begin
// Формируем адрес для привязки.
FillChar(ServerAddr.sin_zero, SizeOf(ServerAddr.sin_zero), 0);
ServerAddr.sin_family := AF_INET;
ServerAddr.sin_addr.S_addr := INADDR_ANY;
try
ServerAddr.sin_port := htons(StrToInt(EditPortNumber.Text));
if ServerAddr.sin_port = 0 then
begin
MessageDlg('Номер порта должен находиться в диапазоне 1-65535',
mtError, [mbOK], 0);
Exit;
end;
// Создание сокета
FServerSocket := socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if FServerSocket = INVALID_SOCKET then
begin
MessageDlg('Ошибка при создании сокета: '#13#10 + GetErrorString,
mtError, [mbOK], 0);
Exit;
end;
// Привязка сокета к адресу
if bind(FServerSocket, ServerAddr, SizeOf(ServerAddr)) = SOCKET_ERROR then
begin
MessageDlg('Ошибка при привязке сокета к адреcу: '#13#10 +
GetErrorString, mtError, [mbOK], 0);
closesocket(FServerSocket);
Exit;
end;
// Перевод сокета в режим прослушивания
if listen(FServerSocket, SOMAXCONN) = SOCKET_ERROR then
begin
MessageDlg('Ошибка при переводе сокета в режим прослушивания:'#13#10 +
GetErrorString, mtError, [mbOK], 0);
closesocket(FServerSocket);
Exit;
end;
// Перевод сокета в неблокирующий режим
NonBlockingArg := 1;
if ioctlsocket(FServerSocket, FIONBIO, NonBlockingArg) = SOCKET_ERROR then
begin
MessageDlg('Ошибка при переводе сокета в неблокирующий режим:'#13#10 +
GetErrorString, mtError, [mbOK], 0);
closesocket(FServerSocket);
Exit;
end;
// Перевод элементов управления в состояние "Сервер работает"
LabelPortNumber.Enabled := False;
EditРоrtNumber.Enabled := False;
BtnStartServer.Enabled := False;
TimerRead.Interval := TimerInterval;
LabelServerState.Caption := 'Сервер работает';
except
on EConvertError do
// Это исключение может возникнуть только в одном месте -
// при вызове StrToInt(EditPortNumber.Text)
MessageDlg('"' + EditPortNumber.Text +
'" не является целым числом', mtError, [mbOK], 0);
on ERangeError do
// Это исключение может возникнуть только в одном месте -
// при присваивании значения номеру порта
MessageDlg('Номер порта должен находиться в диапазоне 1-65535',
mtError, [mbOK], 0);
end;
end;
Так как протокол TCP допускает разбиение посылки на произвольное число пакетов, возможна ситуация, когда на момент срабатывания таймера в буфере сокета будет только часть того, что отправил клиент. Так как мы договорились не блокировать нить, то ждать, пока придет остальное, мы не будем. Вместо этого будем запоминать то, что пришло, а при следующем срабатывании таймера, если пришло еще что-то. добавлять это к предыдущим данным, и так до тех пор, пока не придет все, что мы ожидаем получить от клиента. Так как посылка может разорваться в любом месте, наш код должен быть к этому готов.
Взаимодействие сервера с клиентом состоит из трех этапов. На первом этапе сервер получает от клиента четырёхбайтное значение — длину строки. На втором этапе сервер получает от клиента саму строку, размер которой уже известен из величины, полученной на первом этапе. На третьем этапе сервер отправляет ответ клиенту, состоящий из строки, завершающейся нулем. Чтобы при очередном "тике" таймера сервер мог продолжить общение с клиентом, прерванное в произвольном месте, необходимо запоминать, на каком этапе было прервано взаимодействие в предыдущий раз, сколько байтов на данном этапе уже прочитано или отправлено и сколько еще осталось прочитать или отправить. Для хранения этих данных мы будем использовать типы TTransportPhase и TConnection (листинг 2.31).
Листинг 2.31. Типы TTransportPhase и TConnection
type
// Этап взаимодействия с клиентом:
// tpReceiveLength - сервер ожидает от клиента длину строки
// tpReceiveString - сервер ожидает от клиента строку
// tpSendString - сервер посылает клиенту строку
TTransportPhase = (tpReceiveLength, tpReceiveString, tpSendString);
// Информация о соединении с клиентом:
// СlientSocket - сокет, созданный для взаимодействия с клиентом
// ClientAddr - строковое представление адреса клиента
// MsgSize - длина строки, получаемая от клиента
// Msg - строка, получаемая от клиента или отправляемая ему,
// Phase - этап взаимодействия с данным клиентом
// Offset - количество байтов, уже полученных от клиента
// или отправленных ему на данном этапе
// BytesLeft - сколько байтов осталось получить от клиента
// или отправить ему на данном этапе
PConnection = ^TConnection;
TConnection = record
ClientSocket: TSocket;
ClientAddr: string;
MsgSize: Integer;
Msg: string;
Phase: TTransportPhase;
Offset: Integer;
BytesLeft: Integer;
end;
Для каждого подключившегося клиента создается отдельный экземпляр записи TConnection, в котором хранится информация как о самом подключении, так и о том, на каком этапе находится взаимодействие с данным клиентом.
Проверка подключения клиентов и взаимодействие с подключившимися ранее реализуется, как уже было сказано, при обработке события таймера. Код обработчика приведен в листинге 2.32.
Листинг 2.32. Обработчик события таймера
// Обработка сообщения от таймера
// В ходе обработки проверяется наличие вновь подключившихся клиентов
// а также осуществляется обмен данными с клиентами
procedure TServerForm.TimerReadTimer(Sender: TObject);
var
// Сокет, который создается для вновь подключившегося клиента
ClientSocket: TSocket;
// Адрес подключившегося клиента
ClientAddr: TSockAddr;
// Длина адреса
AddrLen: Integer;
// Вспомогательная переменная для создания нового подключения
NewConnection: PConnection;
I: Integer;
begin
AddrLen := SizeOf(TSockAddr);
// Проверяем наличие подключении. Так как сокет неблокирующий,
// accept не будет блокировать нить даже в случае отсутствия
// подключений.
ClientSocket := accept(FServerSocket, @ClientAddr, @AddrLen);
if ClientSocket = INVALID_SOCKET then
begin
// Если произошедшая ошибка - WSAEWOULDBLOCK, это просто означает,
// что на данный момент подключений нет, а вообще все в порядке,
// поэтому ошибку WSAEWOULDBLOCK мы просто игнорируем. Прочие же
// ошибки могут произойти только в случае серьезных проблем,
// которые требуют остановки сервера.
if WSAGetLastError <> WSAEWOULDBLOCK then
begin
MessageDlg('Ошибка при подключении клиента:'#13#10 +
GetErrorString + #13#10'Сервер будет остановлен', mtError, [mbOK], 0);
ClearConnections;
closesocket(FServerSocket);
OnStopServer;
end;
end
else
begin
// Создаем запись для нового подключения и заполняем ее
New(NewConnection);
NewConnection.ClientSocket := ClientSocket;
NewConnection.СlientAddr :=
Format('%u.%u.%u.%u:%u', [
Ord(ClientAddr.sin_addr.S_un_b.s_b1),
Ord(ClientAddr.sin_addr.S_un_b.s_b2),
Ord(ClientAddr.sin_addr.S_un_b.s_b3),
Ord(ClientAddr.sin_addr.S_un_b.s_b4),
ntohs(ClientAddr.sin_port)]);
NewConnection.Phase := tpReceiveLength;
NewConnection.Offset := 0;
NewConnection.BytesLeft := SizeOf(Integer);
// Добавляем запись нового соединения в список
FConnections.Add(NewConnection);
AddMessageToLog('Зафиксировано подключение с адреса ' +
NewConnection.ClientAddr);
end;
// Обрабатываем все существующие подключения.
// Цикл идет от конца списка к началу потому, что в ходе
// обработки соединение может быть удалено из списка.
for I := FConnections.Count - 1 downto 0 do processConnection(I);
end;
Обратите внимание, что сокет, созданный функцией accept, нигде не переводится в неблокирующий режим. Это связано с тем, что такой сокет наследует свойства слушающего сокета, поэтому он в данном случае сразу создается неблокирующим.
Собственно взаимодействие сервера с клиентом вынесено в метод ProcessConnection (листинг 2.33). который осуществляет чтение данных от клиента и отправку данных в соответствии с этапом, на котором остановилось взаимодействие. При реализации этого метода необходимо просто аккуратно следить за тем, куда и сколько данных нужно передать.
Листинг 2.33. Метод ProcessConnection
// Обработка клиента. Index задает индекс записи в списке
procedure TServerForm.ProcessConnection(Index: Integer);
var
// Вспомогательная переменная, чтобы не приводить каждый раз
// FConnections[Index] к PConnection
Connection: PConnection;
// Результат вызова recv и send
Res: Integer;
// Вспомогательная процедура, освобождающая ресурсы, связанные
// с клиентом и удаляющая запись подключения из списка
procedure RemoveConnection;
begin
closesocket(Connection.ClientSocket);
Dispose(Connection);
FConnections.Delete(Index);
end;
begin
Connection := PConnection(PConnections[Index]);
// Проверяем, на каком этапе находится взаимодействие с клиентом.
// Используется оператор if, а не case, потому, что в случае case
// выполняется только одна альтернатива, а в нашем случае в ходе
// выполнения этапа он может завершиться, и взаимодействие
// перейдет к следующему этапу. Использование if позволяет выполнить
// все три этапа, если это возможно, а не один из них.
if Connection.Phase = tpReceiveLength then
begin
// Этап получения от клиента длины строки. При выполнении этого
// этапа сервер получает от клиента длину строки и размещает ее
// в поле Connection.MsgSize. Здесь приходится учитывать, что
// теоретически даже такая маленькая (4 байта) посылка может
// быть разбита на несколько пакетов, поэтому за один раз этот
// этап не будет завершен, и второй раз его придется продолжать,
// загружая оставшиеся байты. Connection.Offset — количество
// уже прочитанных на данном этапе байтов - одновременно является
// смещением, начиная с которого заполняется буфер.
Res := recv(Connection.ClientSocket, (PChar(@Connection.MsgSize) +
Connection.Offset)^, Connection.BytesLeft, 0);
if Res > 0 then
begin
// Если Res > 0, это означает, что получено Res байтов.
// Соответственно, увеличиваем на Res количество прочитанных
// на данном этапе байтов и на такую же величину уменьшаем
// количество оставшихся.
Inc(Connection.Offset, Res);
Dec(Connection.BytesLeft, Res);
// Если количество оставшихся байтов равно нулю, можно переходить
// к следующему этапу.
if Connection.BytesLeft = 0 then
begin
// Проверяем корректность принятой длины строки
if Connection.MsgSize <= 0 then
begin
AddMessageToLog('Неверная длина строки от клиента ' +
Connection.ClientAddr + ': ' + IntToStr(Connection.MsgSize));
RemoveConnection;
Exit;
end;
// Следующий этап - это чтение самой строки
Connection.Phase := tpReceiveString;
// Пока на этом этапе не прочитано ни одного байта
Connection.Offset := 0;
// Осталось прочитать Connection.MsgSize байтов
Connection.BytesLeft := Connection.MsgSize;
// Сразу выделяем память под строку
SetLength(Connection.Msg, Connection.MsgSize);
end;
end
else 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;
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])) + ' (Non-blocking server)'#0;
// Следующий этап - отправка строки клиенту
Connection.Phase := tpSendString;
// Отправлено на этом этапе 0 байт
Connection.Offset := 0;
// Осталось отправить Length(Connection.Msg) байт.
// Единицу к длине строки, в отличие от предыдущих примеров,
// не добавляем, т.к. там эта единица нужна была для того,
// чтобы учесть добавляемый к строке автоматически символ #0.
// Здесь мы еще один #0 добавили к строке явно, поэтому
// он уже учтен в функции Length.
Connection.BytesLeft := Length(Connection.Msg);
end;
end
else 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;
if Connection.Phase = tpSendString then
begin
// Следующий этап — отправка строки. Код примерно такой же,
// как и в предыдущем этапе, но вместо recv используется send.
// Кроме того, отсутствует проверка на Res = 0, т.к. при
// использовании TCP send никогда не возвращает 0.
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);
// Если Connection.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);
end;
end
else
if WSAGetLastError <> WSAEWOULDBLOCK then
begin
AddMessageToLog('Ошибка при отправке данных клиенту ' +
Connection.ClientAddr + ': ' + GetErrorString);
RemoveConnection;
Exit;
end;
end;
end;
В итоге мы получили сервер, достаточно устойчивый как к подключению множества клиентов, так и к нарушению протокола со стороны клиента. Для самостоятельной работы рекомендуем подумать о том, как можно сделать UDP-чат на неблокирующих сокетах. На самом деле он мало чем будет отличаться от рассмотренного чата на основе select. Просто при использовании select проверка возможности неблокирующего чтения из сокета проверяется предварительным вызовом этой функции, а в случае неблокирующих сокетов сначала вызывается recvfrom, а потом проверяется, было что-то прочитано, или же операция не может быть выполнена потому, что блокировки запрещены. Во всем остальном использование select и неблокирующих сокетов очень похоже, причем не только в данном случае, но и вообще.
2.1.17. Параметры сокета
Каждый сокет обладает рядом параметров (опций), которые влияют на его работу. Существуют параметры уровня сокета, которые относятся к сокету как к объекту безотносительно используемого протокола и его уровня. Впрочем, некоторые параметры уровня сокета применимы не ко всем протоколам. Здесь мы не будем рассматривать все параметры сокета, а ограничимся лишь изложением методов доступа к ним и познакомимся с некоторыми самыми интересными параметрами.
Для получения текущего значения параметров сокета предусмотрена функция getsockopt, для изменения — setsockopt. Прототипы этих функций выглядят следующим образом:
function getsockopt(s: TSocket; level, optname: Integer; optval: PChar; var optlen: Integer): Integer;
function setsockopt(s: TSocket; level, optname: Integer; optval: PChar; optlen: Integer): Integer;
Параметры у функций почти одинаковы. Первый задает сокет, параметры которого следует узнать или изменить. Второй указывает, параметр какого уровня следует узнать или изменить. Третий задает сам параметр сокета. Параметр optval содержит указатель на буфер, в котором хранится значение параметра, a optlen — размер этого буфера (разные параметры имеют различные типы и поэтому размер буфера может быть разным). Функция getsockopt сохраняет значение параметра в буфере, заданном указателем optval. Длина буфера передается через параметр optlen, и через него же возвращается размер, реально понадобившийся для хранения параметра. У функции setsockopt параметр optval содержит указатель на буфер, хранящий новое значение параметра сокета, a optlen — размер этого буфера.
Чаще всего параметры сокета имеют целый или логический тип. В обоих случаях параметр optval должен содержать указатель на значение типа Integer. Для логического типа любое ненулевое значение интерпретируется True, нулевое — как False. Два достаточно важных параметра сокета — размеры входного и выходного буфера. Это параметры уровня сокета (SOL_SOCKET), их номера задаются константами SO_RCVBUF и SO_SNDBUF. Например, чтобы получить размер входного буфера сокета, нужно выполнить код листинга 2.34.
Листинг 2.34. Получение размера входного буфера сокета
var
Val, Len: Integer;
S: TSocket;
begin
...
Len := SizeOf(Integer);
getsockopt(S, SOL_SOCKET, SO_RCBUF, @Val, Len);
После выполнения этого кода размер буфера будет содержаться в переменной Val.
Немного поэкспериментировав, можно обнаружить, что размер входного и выходного буфера равен 8192 байтам как для TCP, так и для UDP. Тем не менее это не мешает отправлять и получать дейтаграммы большего размера (для UDP), а также накапливать в буфере больший объем информации (для TCP). При получении данных это достигается за счет использования более низкоуровневых буферов, чем буфер самого сокета. Можно даже установить входной буфер сокета равным нулю — тогда все поступившие данные будут храниться в низкоуровневых буферах. Однако делать так не рекомендуется, т.к. при этом снижается производительность.
Как уже говорилось, если буфер для исходящих имеет нулевой размер, то функции send и sendto независимо от режима работы сокета отправляют данные непосредственно в сеть. Если же размер этого буфера не равен нулю, при необходимости он может увеличиваться.
В MSDN описаны следующие правила роста буфера:
1. Если объем данных в буфере меньше, чем это задано параметром SO_SNDBUF, то новые данные копируются в буфер полностью. Буфер при необходимости увеличивается.
2. Если объем данных в буфере достиг или превысил SO_SNDBUF, но в буфере находятся данные, переданные в результате только одного вызова send, последующий вызов приводит к увеличению буфера до размера, необходимого, чтобы принять эти данные целиком.
3. Если объем данных в буфере достиг или превысил SO_SENDBUF, и эти данные оказались в буфере в результате нескольких вызовов send, то буфер не расширяется. Блокирующий сокет при этом ждет, когда за счет отправки данных в буфере появится место, неблокирующий завершает операцию с ошибкой WSAEWOULDBLOCK.
Следует отметить, что увеличение размера буфера носит временный характер.
Заметим также, что в ходе наших экспериментов второе правило воспроизвести не удалось. Если предел, заданный параметром SO_SNDBUF, был достигнут, не удавалось поместить новые данные в буфер независимо от того, были ли имеющиеся данные положены туда одним вызовом send или несколькими. Впрочем, это могут быть детали реализации, которые различны в разных версиях системы.
Ранее мы упоминали, что UDP допускает широковещательную рассылку (рассылку по адресу 255.255.255.255 и т.п.). Но по умолчанию такая рассылка запрещена. Чтобы разрешить широковещательную рассылку, нужно установить в True параметр SO_BROADCAST, относящийся к уровню сокета (SOL_SOCKET). Таким образом, вызов функции setsockopt для разрешения широковещательной рассылки будет выглядеть так, как показано в листинге 2.35.
Листинг 2.35. Включение возможности широковещательной рассылки
var
EnBroad: Integer;
begin
EnBroad := 1;
setsockopt(S, SOL_SOCKET, SO_BROADCAST, PChar(@EnBroad), SizeOf(Integer));
Для запрета широковещательной рассылки через сокет используется тот же код, за исключением того, что переменной EnBroad следует присвоить ноль.
Последний параметр сокета, который мы рассмотрим, называется SO_LINGER. Он управляет поведением функции closesocket. Напомним, что по умолчанию эта функция не блокирует вызвавшую ее нить, а закрывает сокет в фоновом режиме. Параметр SO_LINGER имеет тип TLinger, представляющий собой следующую структуру:
TLinger = record
l_onoff: u_short;
l_linger: u_short;
end;
Поле l_onoff этой структуры показывает, будет ли использоваться фоновый режим закрытия сокета. Нулевое значение показывает, что закрытие выполняется в фоновом режиме, как это установлено по умолчанию (в этом случае поле l_linger игнорируется). Ненулевое значение показывает, что функция closesocket не вернет управление вызвавшей ее нити, пока сокет не будет закрыт. В этом случае возможны два варианта: мягкое и грубое закрытие. Мягкое закрытие предусматривает, что перед закрытием сокета все данные, находящиеся в его выходном буфере, будут переданы партнеру. При грубом закрытии данные партнеру не передаются. Поле l_linger задает время (в секундах), которое дается на передачу данных партнеру. Если за отведенное время данные, находящиеся в выходном буфере сокета, не были отправлены, сокет будет закрыт грубо. Если поле l_linger будет равно нулю (при ненулевом l_onoff), сокет всегда будет закрываться грубо. Неблокирующие сокеты рекомендуется закрывать с нулевым временем ожидания или в фоновом режиме, При мягком закрытии неблокирующего сокета не в фоновом режиме, если остались непереданные данные, вызов closesocket завершится с ошибкой WSAEWOULDBLOCK, и сокет не будет закрыт. Придется вызывать функцию closesocket несколько раз до тех пор. пока она не завершится успешно.
Остальные параметры сокета детально описаны в MSDN.
2.1.18. Итоги первого раздела
Мы рассмотрели основные принципы работы со стандартными сокетами. Хотя многое осталось за кадром, того, что здесь было написано, достаточно, чтобы начать создавать разнообразные приложения с использованием сокетов. Для самостоятельного изучения рекомендуется сделать следующее:
□ Для каждой из упоминавшихся здесь функций выяснить, какие ошибки может возвращать WSAGetLastError в случае неуспешного завершения и что каждая из этих ошибок означает.
□ посмотреть, какие еще параметры (опции) есть у сокета;
□ самостоятельно разобраться с не упомянутыми здесь функциями getsockname, gethostbyaddr и getaddrbyhost.
Из приведенных примеров видно, что стандартные сокеты достаточно интегрируются с пользовательским интерфейсом, однако приложение, использующее их, вынуждено самостоятельно опрашивать сокеты с определённой периодичностью (например, по таймеру). Это не совпадает с принятой в Windows схемой событийного управления программой, основанной на принципе "пусть мне скажут, когда что-то произойдет, и я отреагирую". Именно поэтому стандартные сокеты были расширены и появились сокеты Windows, с которыми мы познакомимся далее.
Назад: 2.1. Стандартные сокеты
Дальше: 2.2. Сокеты Windows
