А. Григорьев - О чём не пишут в книгах по Delphi
Функция reсvfrom всегда читает только одну дейтаграмму, даже если размер переданного ей буфера достаточен для чтения нескольких дейтаграмм. Если на момент вызова recvfrom дейтаграммы во входном буфере сокета отсутствуют, функция будет ждать, пока они там появятся, и до этого момента не вернет управление вызвавшей её программе. Если в буфере находится несколько дейтаграмм, то они читаются в порядке очередности поступления в буфер. Напомним, что дейтаграммы могут поступать в буфер не в том порядке, в котором они были отправлены. Кроме того, в очень редких случаях буфер может содержать несколько копий одной дейтаграммы, каждую из которых нужно извлекать отдельно.
Значение, возвращаемое функцией recvfrom, равно длине прочитанной дейтаграммы. Это значение может быть равно нулю, т.к. UDP позволяет отправлять дейтаграммы нулевой длины (для этого при вызове sendto нужно задать параметр len равным нулю). Если обнаружена какая-то ошибка, возвращается значение SOCKET_ERROR.
Если размер буфера, определяемого параметром Buf, меньше, чем первая находящаяся во входном буфере сокета дейтаграмма, то копируется только часть дейтаграммы, помещающаяся в буфере, a recvfrom завершается с ошибкой (WSAGetLastError при этом вернет ошибку WSAEMSGSSIZE). Оставшаяся часть дейтаграммы при этом безвозвратно теряется, при следующем вызове recvfrom будет прочитана следующая дейтаграмма. Этой проблемы легко избежать, т.к. длина дейтаграммы в UDP не может превышать 65 507 байтов. Достаточно подготовить буфер соответствующей длины, и и в него гарантированно поместится любая дейтаграмма.
Другой способ избежать подобной проблемы — использовать флаг MSG_PEEK. В этом случае дейтаграмма не удаляется из входного буфера сокета, а значение, возвращаемое функцией recvfrom, равно длине дейтаграммы. При этом в буфер, заданный параметром Buf, копируется та часть дейтаграммы, которая в нем помещается. Программа может действовать следующим образом: вызвать recvfrom с флагом MSG_PEEK, выделить память, требуемую для хранения дейтаграммы, вызвать recvfrom без флага MSG_PEEK, чтобы прочитать дейтаграмму целиком и удалить ее из входного буфера сокета. Этот метод сложнее, а 65 507 байтов — не очень большая по нынешним меркам память, поэтому легче все-таки заранее приготовить буфер фиксированной длины. Функция recvfrom непригодна для тех сокетов, которые еще не привязаны к адресу, поэтому перед вызовом этой функции должна быть вызвана либо функция bind, либо функция, которая осуществляет неявную привязку сокета к адресу (например, sendto).
Протокол UDP не поддерживает соединения в том смысле, в котором их поддерживает TCP, но библиотека сокетов позволяет частично имитировать такие соединения, Для этого служит функция connect, имеющая следующий прототип:
function connect(s: TSocket; var name: TSockAddr; namelen: Integer): Integer;
Параметр s задает сокет, который должен быть "соединен" с удаленным адресом. Адрес задается параметром name аналогично тому, как он задаётся в параметре addr функции sendto. Параметр namelen содержит длину структуры, описывающей адрес, и должен быть равен SizeOf(TSockAddr). Функция возвращает ноль при успешном завершении и SOCKET_ERROR — в случае ошибки. Вызов функции connect в случае UDP устанавливает фильтр для входящих дейтаграмм. Дейтаграммы, адрес отправителя которых не совпадает с адресом, заданным в функции connect, игнорируются: новые дейтаграммы не помещаются во входной буфер сокета, а те, которые находились там на момент вызова connect, удаляются из него. Функция connect не проверяет, существует ли адрес, с которым сокет "соединяется", и может успешно завершиться, даже если узла с таким IP-адресом нет.
Программа может вызывать connect неограниченное число раз с разными адресами. Если параметр name задает IP-адрес INADDR_ANY и нулевой порт, то сокет "отсоединяется", т.е. все фильтры для него снимаются, и он ведет себя так же, как сокет, для которого не была вызвана функция connect. Для сокетов, не привязанных к адресу, connect неявно вызывает bind.
После вызова connect для отправки данных можно использовать функцию send со следующим прототипом:
function send(s: TSocket; var Buf; len, flags: Integer): Integer;
От функции sendto она отличается отсутствием параметров addrto и tolen. При использовании send дейтаграмма отправляется по адресу, заданному при вызове connect. В остальном эти функции ведут себя одинаково, функция sendto при работе с "соединенным" сокетом ведет себя так же, как с несоединенным, т.е. отправляет дейтаграмму по адресу, определяемому параметром addrlen, а не по адресу, заданному при вызове connect.
Получение данных через "соединенные" сокеты может также осуществляться с помощью функции reсv, имеющей следующий прототип:
function recv(s: TSocket; var Buf; len, flags: Integer): Integer;
От своего аналога recvfrom она отличается только отсутствием параметров from и fromlen, через которые передается адрес отправителя дейтаграммы.
Рис. 2.1. Последовательность действий программы при обмене данными с помощью UDP
Строго говоря, функцию recv можно использовать и для несоединенных сокетов, но при этом программе остается неизвестным адрес отправителя. В случае же "соединенных" сокетов адрес отправителя заранее известен — это адрес, заданный в функции connect, а дейтаграммы всех других отправителей будут отбрасываться. Функция recvfrom также пригодна для "соединенных" сокетов, но адрес отправителя, который она возвращает, в данном случае может быть только тот, который определен в функции connect.
Таким образом, функция connect в случае протокола UDP позволяет, во-первых, выполнить фильтрацию входящих дейтаграмм по адресу средствами самой библиотеки сокетов, а во-вторых, использовать более лаконичные альтернативы recvfrom и sendto — recv и send.
Возможные последовательности действий программы для протокола UDP показаны на рис. 2.1.
2.1.10. Пример программы: простейший чат на UDP
Попробуем применить свои знания на практике и напишем простейший чат на основе протокола UDP. Пример этой программы находится на прилагаемом к книге компакт-диске и называется UDPChat, окно приложения показано на рис. 2.2.
Прежде чем писать программу, необходимо определиться с форматом передаваемых данных (т.е. договориться о протоколе уровня представлений). Так как мы пишем простейший пример, то и протокол у нас будет простейшим: дейтаграмма содержит текстовое сообщение, введенное пользователем, без завершающего нуля (он не нужен, т.к. размер строки определяется размером дейтаграммы) и без дополнительной служебной информации.
Для начала нам потребуется научиться сообщать пользователю об ошибках. Номер ошибки мало что дает даже опытному пользователю, поэтому сообщения должны быть дружественными, с внятным объяснением того, какая именно ошибка произошла. К счастью, мы избавлены от необходимости вручную писать текстовое сообщение для каждой из возможных ошибок, т.к. в системе уже есть функция FormatMessage, которая возвращает текстовое сообщение по коду ошибки (эта функция работает со всеми ошибками, а не только с ошибками сокетов). На основе FormatMessage мы создадим функцию GetErrorString (листинг 2.6), которая возвращает сообщение, соответствующее коду ошибки, возвращаемому функцией WSAGetLastError. Эта функция будет встречаться во всех наших примерах.
Рис. 2.2. Главное окно UDP-чата
Листинг 2.6. Функция GetErrorString, возвращающая описание ошибки
// функция GetErrorString возвращает сообщение об ошибке,
// сформированное системой из основе значения, которое
// вернула функция WSAGetLastError. Для получения сообщения
// используется системная функция FormatMessage.
function GetErrorString: string;
var
Buffer: array [0..2047] of Char;
begin
FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, nil, WSAGetLastError, $400,
@Buffer, SizeOf(Buffer), nil);
Result := Buffer;
end;
Нам понадобится и принимать, и передавать данные. Как мы помним, функция recvfrom не возвращает управление вызвавшей ее нити до тех пор, пока не будут получены данные. Таким образом, если мы будем вызывать recvfrom в главной нити, то при отсутствии входящих дейтаграмм программа просто повиснет, т.к. не сможет обрабатывать оконные сообщения. Поэтому все действия по приему сообщений мы должны вынести в отдельную нить. Задача этой нити очень проста: она в бесконечном цикле вызывает recvfrom и все полученные дейтаграммы передает в главное окно для отображения на экране.
