Так как большинство современных компьютеров объединены в сети, то и задачи программирования передачи и получения данных по сети возникают часто. Существует множество высокоуровневых средств обмена, но иногда их бывает недостаточно, и тогда приходится использовать самые низкоуровневные средства сетевого программирования — сокеты. Однако существует целый ряд причин, по которым овладеть этой технологией непросто. Во-первых, она сложна сама по себе из-за большого количества возможностей. Во-вторых, существующие библиотеки отягощены совместимостью со старыми версиями, которые, с современной точки зрения, не всегда развивались по правильному пути. В-третьих, у программистов на Delphi возникают дополнительные трудности, связанные как с тем, что сама реализация библиотеки сокетов ориентирована на язык С, так и с тем, что стандартный модуль

WinSock

Несмотря на традиционно высокий интерес к сокетам, литературы, в которой бы эта библиотека была детально описана, очень мало. Если не считать книг, где сокеты упоминаются обзорно, автору известна только одна книга, посвященная сокетам в Windows [3]. Но она не имеет никакого отношения к Delphi и не учитывает специфику этого средства разработки. Естественно, что из-за недостатка информации у начинающих программистов часто возникают вопросы, связанные с использованием сокетов в Delphi. В данной главе мы попытаемся ответить на эти вопросы.

Изложение материала ориентировано на человека, который не только не сталкивался с сокетами раньше, но и вообще имеет смутные представления об устройстве и функционировании компьютерных сетей. Поэтому мы будем обзорно рассматривать и общетеоретические темы, которые необходимо знать, чтобы эффективно программировать сетевое взаимодействие, так что никакая предварительная подготовка в этих вопросах от читателя не требуется.

Глава разбита на две части. Первая посвящена стандартным сокетам, а вторая — сокетам Windows. Термины достаточно условны и нуждаются в дополнительном пояснении. Строго говоря, стандартными называются сокеты Беркли (Berkley sockets), разработанные в университете Беркли для системы Unix. Как это ни парадоксально звучит, но сокеты Беркли появились до появления компьютерных сетей. Изначально они предназначались для взаимодействия между процессами в системе и только позже были приспособлены для TCP/IP. Работа с сокетами Беркли сделана максимально похожей на работу с файлами в Unix. В частности, для отправки и получения данных используются те же функции, что и для файлового ввода-вывода.

Сокеты в Windows не полностью совместимы с сокетами Беркли (например, для них предусмотрены специальные функции отправки и получения данных, переопределены некоторые типы данных и т.п.). Но возможности работы с сокетами в Windows можно разделить на две части: то, что укладывается в идеологию сокетов Беркли, хотя и реализовано несколько иначе, и то, что является специфичным для Windows. Ту часть реализации сокетов Windows, которая по функциональности соответствует сокетам Беркли, мы будем называть стандартными сокетами, а сокетами Windows (Windows sockets) — специфичные для Windows расширения.

Ориентироваться мы будем только на два протокола передачи данных — TCP и UDP. Хотя библиотека сокетов поддерживает и другие протоколы, но эти два, во-первых, применяются наиболее часто, а во-вторых, именно на них во многом ориентированы стандартные сокеты. Поэтому здесь мы не будем касаться особенностей работы функций библиотеки сокетов, которые проявляются только для протоколов, отличных от TCP и UDP. Объем информации, с которой придется познакомиться, и без того большой, а с другими протоколами легче ознакомиться потом, изучив TCP и UDP.

Сначала рассмотрим классические методы работы с сокетами, которые не учитывают ни существования окон и оконных сообщений, ни возможности распараллеливания работы программы на несколько нитей. Это. впрочем, не означает, что программа, использующая эти методы, должна быть безоконной и однонитевой, оконные и многонитевые программы есть среди примеров этого раздела. Просто приспосабливать стандартные сокеты к окнам и распараллеливанию приходится вручную, а не за счет средств самой библиотеки. Тем не менее из-за своей простоты стандартные сокеты нередко оказываются более удобными, чем сокеты Windows, даже в оконных приложениях.

Первые библиотеки сокетов писались на языке С. В этом языке идентификаторы чувствительны к регистру символов, т.е., например,

SOCKET

Socket

socket

GetWindowText

Чувствительность С к регистру символов создаст некоторые проблемы при переноce библиотек, написанных на этом языке, в Delphi. Это связано с тем, что разные объекты могут иметь имена, различающиеся только регистром символов, в частности, есть тип

SOCKET

socket

Т

SOCKET

TSocket

Ранее был упомянут термин "макроопределение". Он может быть непонятен тем, кто не работал с языками С и C++, потому что в Delphi макроопределения отсутствуют. Нормальная последовательность трансляции программы в Delphi следующая: сначала компилятор создает объектный код, в котором вместо реальных адресов функций, переменных и т.п. стоят ссылки на них (на этапе компиляции эти адреса еще не известны). Затем компоновщик размещает объекты в памяти и заменяет ссылки реальными адресами. Так получается готовая к исполнению программа. В С/C++ трансляция включает в себя еще один этап: перед компиляцией текст программы модифицируется препроцессором, и компилятор получает уже несколько видоизмененный текст. Макроопределения, или просто макросы, — это директивы препроцессору, предписывающие ему, как именно нужно менять текст программы. Макрос задаст подмену: везде, где в программе встречается имя макроса, препроцессор изменяет его на тот текст, который задан при определении этого макроса. Определяются макросы с помощью директивы препроцессору

#define

В простейшем случае макросы используются для определения констант. Например, директива

#define SOMECONST 10

SOMECONST

SOMECONST

SOMECONST

Макросы позволяют в некоторых случаях существенно сократить программу и повысить ее читабельность. Тем не менее они считаются устаревшим средством. т.к. их использование может привести к существенным проблемам (обсуждение этого выходит за рамки данной книги). В современных языках от макросов отказываются. В частности, в C++ макросы поддерживаются в полном объеме, но использовать их не рекомендуется, т.к. есть более безопасные инструменты, решающие типичные для макросов задачи. В С# и Java макросы отсутствуют. Тем не менее в заголовочных файлах для системных библиотек Windows (в том числе и библиотеки сокетов) макросы широко применяются, т.к. требуется обеспечить совместимость с языком С. При портировании таких файлов в Delphi макросы без параметров заменяются константами, а макросы с параметрами — функциями (иногда один макрос приходится заменять несколькими функциями для разных типов данных).

Сокетом (от англ. socket — гнездо, розетка) называется специальный объект, создаваемый для отправки и получения данных через сеть. Отметим, что под термином "объект" в данном случае подразумевается не объект в терминах объектно-ориентированного программирования, а некоторая сущность, внутренняя структура которой скрыта от нас, и мы можем оперировать с ней только как с единым и неделимым (атомарным) объектом. Этот объект создается внутри библиотеки сокетов, а программист, работающий с данной библиотекой, получает уникальный номер (дескриптор) этого сокета. Конкретное значение этого дескриптора не несет для программиста никакой полезной информации и может быть использовано только для того, чтобы при вызове функции из библиотеки сокетов указать, с каким сокетом требуется выполнить операцию. В этом смысле тип

TSocket

Чтобы две программы могли общаться друг с другом через сеть, каждая из них должна создать сокет. Каждый сокет обладает двумя основными характеристиками: протоколом и адресом, к которым он привязан. Протокол задается при создании сокета и не может быть изменен впоследствии. Адрес сокета задаётся позже, но обязательно до того, как через сокет пойдут данные. В некоторых случаях привязка сокета к адресу может быть неявной. 

Формат адреса сокета определяется конкретным протоколом. В частности, для протоколов TCP и UDP адрес состоит из IP-адреса сетевого интерфейса и номера порта.

Каждый сокет имеет два буфера: для входящих и для исходящих данных. При отправке данных они сначала помещаются в буфер исходящих, и лишь затем отправляются в фоновом режиме. Программа в это время продолжает свою работу. При получении данных сокет помещает их в буфер для входящих, откуда они затем могут извлекаться программой.

Сеть может связывать разные аппаратные платформы, поэтому требуется согласование форматов передаваемых данных, в частности форматов целых чисел. Двухбайтные целые числа хранятся в памяти в двух последовательно расположенных байтах. При этом возможны два варианта: в первом байте хранится младший байт числа, а во втором — старший, и наоборот. Способ хранения определяется аппаратной частью платформы. Процессоры Intel используют первый вариант, т.е. первым хранится младший байт, а другие процессоры (например, Motorola) — второй вариант. То же касается и четырёхбайтных чисел: процессоры Intel хранят их, начиная с младшего байта, а некоторые другие процессоры — начиная со старшего. Сетевой формат представления таких чисел совпадает с форматом процессора Motorola, т.е. на платформах с процессором Intel необходимо переставлять байты при преобразовании чисел в сетевой формат.

Библиотека сокетов разрабатывалась для ОС Unix в которой традиционно высоко ценилась переносимость между платформами, поэтому она содержит функции, позволяющие не задумываться о порядке байтов в числах:

ntohs

ntohl

htons

htonl

htons

u_short

Сетевым протоколом называется набор соглашений, следование которым позволяет обеим сторонам одинаково интерпретировать принимаемые и отправляемые данные. Сетевой протокол можно сравнить с языком: два человека понимают друг друга тогда, когда говорят на одном языке. Причем если люди, говорящие на похожих, но немного разных языках, все же могут понимать друг друга, то компьютеры для нормального обмена данными должны поддерживать в точности одинаковый протокол.

Для установления взаимодействия между компьютерами должен быть согласован целый ряд вопросов, начиная от напряжения в проводах и заканчивая форматом пакетов. Реализуются эти соглашения на разных уровнях, поэтому логичнее иметь не один протокол, описывающий все и вся, а набор протоколов, каждый из которых охватывает только вопросы одного уровня. Организация Open Software Interconnection (OSI) предложила разделить все вопросы, требующие согласования, на семь уровней. Это разделение известно как семиуровневая модель OSI.

Семейство протоколов, реализующих различные уровни, называется стеком протоколов. Стеки протоколов не всегда точно следуют модели OSI, некоторые протоколы решают вопросы, связанные сразу с несколькими уровнями.

Первый уровень в модели OSI называется физическим. На нем согласовываются физические, электрические и оптические параметры сети: напряжение и форма импульсов, кодирующих 0 и 1, какой разъем используется и т.п.

Второй уровень носит название канального. На этом уровне решаются вопросы конфигурации сети (шина, звезда, кольцо и т.п.), приема и передачи кадров, допустимости и методов разрешения коллизий (ситуаций, когда сразу два компьютера пытаются передать данные).

Третий уровень — сетевой. Здесь определяется, как адресуются компьютеры. Большинство сетей используют широковещательный способ передачи: пакет, переданный одним компьютером, получают все остальные. Протокол сетевого уровня описывает критерии, на основании которых каждый компьютер может выбирать из сети только те пакеты, которые предназначены ему, и игнорировать все остальные. На этом же уровне определяется, как пакеты проходят через маршрутизатор.

Четвертый уровень называется транспортным. На этом уровне единый физический поток данных разбивается на независимые логические потоки. Это позволяет нескольким программам независимо друг от друга использовать сеть, не опасаясь, что их данные смешаются. Кроме того, на транспортном уровне решаются вопросы, связанные с подтверждением доставки пакета и упорядочиванием пакетов.

Пятый уровень известен как уровень сессии. Он определяет процедуру установления, завершения связи и ее восстановления после разрыва. Расписывается последовательность действий каждой стороны и пакеты, которые они должны друг другу отправить для инициализации и завершения связи. Определяются соглашения о том, как единый поток разбивается на логические пакеты.

Шестой уровень называется уровнем представлений. На этом уровне определяется то, в каком формате данные передаются по сети. Под этим подразумевается, в первую очередь, внутренняя структура пакета, а также способ представления данных разных типов. Например, для двух- и четырёхбайтных целых чисел должен быть согласован порядок байтов, для логических величин — какие значения соответствуют True, какие — False, для строк — кодировка и способ задания конца строки и т.п.

Седьмой уровень называется уровнем приложений. Соглашения этого уровня позволяют работать с ресурсами (файлами, принтерами и т.д.) удаленного компьютера как с локальными, осуществлять удаленный вызов процедур и т.п.

Чтобы получить данные через сеть, должны быть реализованы все уровни, за исключением, может быть, седьмого. Для каждого уровня должен быть определён свой протокол. В идеале механизмы взаимодействия между протоколами разных уровней должны иметь столь высокую степень абстракции, чтобы один протокол на любом из уровней можно было заменить любым другим протоколом того же уровня, не внося каких-либо изменений в выше- и нижележащие уровни.

Физический и канальный уровни полностью реализуются сетевой картой или модемом (или другим устройством, выполняющим ту же функцию) и ее драйвером. Здесь действительно достигнута настолько полная абстракция, что программист обычно не задумывается о том, какая используется сеть. Поэтому мы также не будем останавливаться на этих двух уровнях. В реальной жизни не все протоколы, особенно старые, соответствуют модели OSI. Существует такое понятие, как стек протоколов — набор протоколов разных уровней, которые совместимы друг с другом. Эти уровни не всегда точно соответствуют тем, которые предлагает модель OSI, но определенное разделение задач на уровни в них присутствует. Здесь мы сосредоточимся на стеке протоколов, который называется TCP/IP (нередко можно услышать словосочетание "протокол TCP/IP", что не совсем корректно: TCP/IP не протокол, а стек протоколов). Название этот стек получил по наименованию двух самых известных своих протоколов: TCP и IP.

Протокол сетевого уровня IP расшифровывается как Internet Protocol. Это название иногда ошибочно переводят как "протокол Интернета" или "протокол для Интернета". На самом деле, когда разрабатывался этот протокол, никакого Интернета еще и в помине не было, поэтому правильный перевод — межсетевой протокол. История появления этого протокола связана с особенностями работы сети Ethernet. Эта сеть строится по принципу шины, когда все компьютеры подключены, грубо говоря, к одному проводу. Если хотя бы два компьютера попытаются одновременно передавать данные по общей шине, возникнет неразбериха, поэтому все шинные сети строятся по принципу "один говорит — все слушают". Очевидно, что требуется какая-то защита от так называемых коллизий (ситуаций, когда два узла одновременно пытаются передавать данные).

Разные сети решают проблему коллизий по-разному. В промышленных сетях, например, обычно имеется маркер — специальный индикатор, который показывает, какому узлу разрешено сейчас передавать данные. Узел, называемый мастером, следит за тем, чтобы маркер вовремя передавался от одного узла к другому. Маркер исключает возможность возникновения коллизий. Ethernet же является одноранговой сетью, в которой нет мастера, поэтому в ней реализован другой подход: коллизии допускаются, но существует механизм их разрешения, заключающийся в том, что, во-первых, узел не начинает передачу данных, если видит, что другой узел уже что-то передает, а во-вторых, если два узла одновременно пытаются начать передачу, то оба прекращают попытку и повторяют ее через случайный промежуток времени. У кого этот промежуток окажется меньше, тот и захватит сеть (или за этот промежуток времени сеть будет захвачена кем-то еще).

При большом числе компьютеров, сидящих на одной шине, коллизии становятся слишком частыми, и производительность сети резко падает. Для борьбы с этим служат специальные устройства — маршрутизаторы специализированные узлы, подключенные одновременно к нескольким сетям. Пока остальные узлы каждой из этих сетей взаимодействуют только между собой, маршрутизатор никак себя не проявляет, и эти сети существуют независимо друг от друга. Но если компьютер из одной сети посылает пакет компьютеру другой сети, этот пакет получает маршрутизатор и переправляет его в ту сеть, в которой находится адресат, или в которой находится другой маршрутизатор, способный передать этот пакет адресату.

На канальном уровне существует адресация узлов, основанная на так называемом MAC-адресе сетевой карты (MAC — это сокращение Media Access Control). Этот адрес является уникальным номером карты, присвоенной ей производителем. Очевидно неудобство такого способа адресации, т.к. по MAC-адресу невозможно определить положение компьютера в сети, т.е. выяснить, куда направлять пакет. Кроме того, при замене сетевой карты меняется адрес компьютера, что также не всегда удобно. Поэтому на сетевом уровне определяется собственный способ адресации, не связанный с аппаратными особенностями узла. Отсюда следует, что маршрутизатор должен понимать протокол сетевого уровня, чтобы принимать решение о передаче пакета из одной сети в другую, а протокол, в свою очередь, должен учитывать наличие маршрутизаторов в сети и предоставлять им необходимую информацию. IP был одним из первых протоколов сетевого уровня, который решал такую задачу и с его помощью стала возможной передача пакетов между сетями. Поэтому он и получил название межсетевого протокола. Впрочем, название прижилось: в некоторых статьях MSDN сетевой уровень (network layer) называется межсетевым уровнем (internet layer). В протоколе IP. в частности, вводится важный параметр для каждого пакета: максимальное число маршрутизаторов, которое он может пройти, прежде чем попадет к адресату (этот параметр носит не совсем удачное название TTL — Time То Live, время жизни). Это позволяет защититься от бесконечного блуждания пакетов по сети.

Примечание

Здесь следует заметить, что сеть Ethernet ушла далеко вперёд по сравнению с моментом создания протокола IP и теперь организована сложнее, поэтому не следует думать, что в предыдущих абзацах изложены все принципы работы этой сети (это выходит за рамки данной книги). Тем не менее протокол IР по-прежнему используется, а компьютеры по-прежнему видят в сети не только свои, но и чужие пакеты. На этом основана работа так называемых снифферов — программ, позволяющих одному компьютеру читать пакеты пересылаемые между двумя другими компьютерами.

Для адресации компьютера протокол IP использует уникальное четырёхбайтное число, называемое IP-адресом. Впрочем, более распространена форма записи этого числа в виде четырех однобайтных значений. Система назначения этих адресов довольно сложна и призвана оптимизировать работу маршрутизаторов, обеспечив прохождение широковещательных пакетов только внутри определенной части сети и т.п. Мы здесь не будем подробно останавливаться на этом, потому что в правильно настроенной сети программисту не нужно знать всех этих тонкостей: достаточно помнить, что каждый узел имеет уникальный IP-адрес, для которого принята запись в виде четырех цифровых полей, разделенных точками, например, 192.168.200.217. Также следует знать, что адреса из диапазона 127.0.0.1—127.255.255.255 задают так называемый локальный узел: через эти адреса могут связываться программы, работающие на одном компьютере. Таким образом, обеспечивается прозрачность местонахождения адресата. Кроме того, один компьютер может иметь несколько IP-адресов, которые могут использоваться для одного и того же или разных сетевых интерфейсов.

Кроме IP, в стеке TCP/IP существует еще несколько протоколов — ICMP, IGMP и ARP, — решающих задачи сетевого уровня. Эти протоколы не являются полноценными и не могут заменить IP. Они служат только для решения некоторых частных задач.

Протокол ICMP (Internet Control Message Protocol — протокол межсетевых управляющих сообщений) обеспечивает диагностику связи на сетевом уровне. Многим знакома утилита ping, позволяющая проверить связь с удаленным узлом. В основе ее работы лежат специальные запросы и ответы, определяемые в рамках протокола ICMP. Кроме того, этот же протокол определяет сообщения, которые получает узел, отправивший IP-пакет, если этот пакет по каким-то причинам не доставлен.

Протокол называется надежным (reliable), если он гарантирует, что пакет будет либо доставлен, либо отправивший его узел получит уведомление о том что доставка невозможна. Кроме того, надежный протокол должен гарантировать, что пакеты доставляются в том же порядке, в каком они отправлены и дублирования сообщений не происходит. Протокол IP в чистом виде не является надежным протоколом, т.к. в нем вообще не предусмотрены средства уведомления узла о проблемах с доставкой пакета. Добавление ICMP также не делает IP надежным, т.к. ICMP-пакет является частным случаем IP-пакета, и также может не дойти до адресата, поэтому возможны ситуации, когда пакет не доставлен, а отправитель об этом не подозревает.

Протокол IGMP (Internet Group Management Protocol — протокол управления межсетевыми группами) предназначен для управления группами узлов, которые имеют один групповой IP-адрес. Отправку пакета по такому адресу можно рассматривать как нечто среднее между адресной и широковещательной рассылкой, т. к. такой пакет будет получен сразу всеми узлами, входящими в группу.

Протокол ARP (Address Resolution Protocol — протокол разрешения адресов) необходим для установления соответствия между IP- и MAC-адресами. Каждый узел имеет таблицу соответствия. Исходящий пакет содержит два адреса узла: MAC-адрес для канального уровня и IP-адрес для сетевого. Отправляя пакет, узел находит в своей таблице MAC-адрес, соответствующий IP-адресу получателя, и добавляет его к пакету. Если в таблице такой адрес не найден, отправляется широковещательное сообщение, формат которого определяется протоколом ARP. Получив такое сообщение, узел, чей IP-адрес соответствует искомому, отправляет ответ, в котором указывает свой MAC-адрес. Этот ответ также широковещательный, поэтому его получают все узлы, а не только отправивший запрос, и все узлы обновляют свои таблицы соответствия.

Строго говоря, обеспечение правильного функционирования протоколов сетевого уровня — задача администратора системы, а не программиста. В своей работе программист чаще всего сталкивается с более высокоуровневыми протоколами и не интересуется деталями реализации сетевого уровня.

Протоколами транспортного уровня в стеке TCP/IP являются протоколы TCP и UDP. Строго говоря, они решают не только задачи транспортного уровня, но и небольшую часть задач уровня сессии. Тем не менее они традиционно называются транспортными. Эти протоколы мы рассмотрим детально в следующих разделах.

Уровни сессии, представлений и приложений в стеке TCP/IP не разделены: протоколы HTTP, FTP, SMTP и т.д., входящие в этот стек, решают задачи всех трех уровней. Мы здесь не будем рассматривать эти протоколы, потому что при использовании сокетов они в общем случае не нужны: программист сам определяет формат пакетов, отправляемых с помощью TCP или UDP.

Новички нередко думают, что фраза "программа поддерживает соединение через TCP/IP" полностью описывает то, как можно связаться с программой и получить данные. На самом деле необходимо знать формат пакетов, которые эта программа может принимать и отправлять, т.е. должны быть согласованы протоколы уровня сессии и представлений. Гибкость сокетов дает программисту возможность самостоятельно определить этот формат, т.е., по сути дела, придумать и реализовать собственный протокол поверх TCP или UDP. И без описания этого протокола организовать обмен данными с программой невозможно.

Протокол UDP (User Datagram Protocol — протокол пользовательских дейтаграмм) встречается реже, чем его "одноклассник" TCP, но он проще для понимания, поэтому мы начнем изучение транспортных протоколов с него. Коротко UDP можно описать как ненадежный протокол без соединения, основанный на дейтаграммах. Теперь рассмотрим каждую из этих характеристик подробнее.

UDP не имеет никаких исполнительных средств управления пакетами по сравнению с IP. Это значит, что пакеты, отправленные с помощью UDP, могут теряться, дублироваться и менять порядок следования. В сети без маршрутизаторов ничего этого с пакетами почти никогда не происходит, и UDP может условно считаться надежным протоколом. Сети с маршрутизаторами строятся, конечно же, таким образом, чтобы подобные случаи происходили как можно реже, но полностью исключить их, тем не менее, нельзя. Происходит это из-за того, что передача данных может идти несколькими путями через разные маршрутизаторы. Например, пакет может пропасть, если короткий путь к удаленному узлу временно недоступен, а в длинном приходится пройти больше маршрутизаторов, чем это разрешено. Дублироваться пакеты могут, если они ошибочно передаются двумя путями, а порядок следования может изменяться, если пакет, посланный первым, идет по более длинному пути, чем пакет, посланный вторым.

Все сказанное отнюдь не означает, что на основе UDP нельзя построить надежный обмен данными, просто заботу об этом должно взять на себя само приложение. Каждый исходящий пакет должен содержать порядковый номер, и в ответ на него должен приходить специальный пакет — квитанция, которая уведомляет отправителя, что пакет доставлен. При отсутствии квитанции пакет высылается повторно (для этого необходимо ввести тайм-ауты на получение квитанции). Принимающая сторона по номерам пакетов восстанавливает их исходный порядок.

UDP не поддерживает соединение. Это означает, что при использовании этого протокола можно в любой момент отправить данные по любому адресу без необходимости каких-либо предварительных действий, направленных на установление связи с адресатом. Это напоминает процесс отправки обычного письма: на нем пишется адрес, и оно опускается в почтовый ящик без каких-либо предварительных действий. Такой подход обеспечивает большую гибкость, но лишает систему возможности автоматической проверки исправности канала связи.

Дейтаграммами называются пакеты, которые передаются как единое целое. Каждый пакет, отправленный с помощью UDP, составляет одну дейтаграмму. Принятые дейтаграммы складываются в буфер принимающего сокета и могут быть получены только раздельно: за одну операцию чтения из буфера программа, использующая сокет, может получить только одну дейтаграмму. Если в буфере лежит несколько дейтаграмм, потребуется несколько операций чтения, чтобы прочитать все. Кроме того, одну дейтаграмму нельзя получить из буфера по частям: она должна быть прочитана целиком за одну операцию. Чтобы данные, передаваемые разным сокетам, не перемешивались, каждый сокет должен получить уникальный в пределах узла номер от 0 до 65 535, называемый номером порта. При отправке дейтаграммы отправитель указывает IP-адрес и порт получателя, и система принимающей стороны находит сокет, привязанный к указанному порту, и помещает данные в его буфер. По сути дела, UDP является очень простой надстройкой над IP, все функции которой заключаются в том, что физический поток разделяется на несколько логических с помощью портов, и добавляется проверка целостности данных с помощью контрольной суммы (сам по себе протокол IP не гарантирует отсутствия искажений данных при передаче).

Максимальный размер одной дейтаграммы IP равен 65 535 байтам. Из них не менее 20 байтов занимает заголовок IP. Заголовок UDP имеет размер 8 байтов. Таким образом, максимальный размер одной дейтаграммы UDP составляет 65 507 байтов. 

Типичная область применения UDP — программы, для которых потеря пакетов некритична. Например, некоторые сетевые 3D-игры в локальной сети используют UDP, т.к. очень часто посылают пакеты, информирующие о действиях игрока, и потеря одного пакета не приведет к существенным проблемам: следующий пакет доставит необходимые данные. Достоинства UDP — простота установления связи, возможность обмена данными с несколькими адресами через один сокет и отсутствие необходимости возобновлять соединение после разрыва связи. В некоторых задачах также очень удобно то, что дейтаграммы не смешиваются, и получатель всегда знает, какие данные были отправлены одной дейтаграммой, а какие — разными.

Еще одно преимущество UDP — возможность отправки широковещательных дейтаграмм. Для этого нужно указать широковещательный IP-адрес (обычно 255.255.255.255, но в некоторых случаях допустимы адреса типа 192.168.100.225 для вещания в пределах сети 192.168.100.XX и т.п.), и такую дейтаграмму получат все сокеты в локальной сети, привязанные к заданному порту. Эту возможность нередко используют программы, которые заранее не знают, с какими компьютерами они должны связываться. Они посылают широковещательное сообщение и связываются со всеми узлами, которые распознали это сообщение и прислали на него соответствующий ответ. По умолчанию для широковещательных пакетов число маршрутизаторов, через которые они могут пройти (TTL), устанавливается равным нулю, поэтому такие пакеты не выходят за пределы подсети.

Протокол TCP (Transmission Control Protocol — протокол управления передачей) является надежным потоковым протоколом с соединением, т.е. полной противоположностью UDP. Единственное, что у этих протоколов общее, — это способ адресации: в TCР каждому сокету также назначается уникальный номер порта. Уникальность номера порта требуется только в пределах протокола: два сокета могут иметь одинаковые номера портов, если один из них работает через TCP, а другой через UDP.

В TCP предусмотрены так называемые хорошо известные (well-known) порты, которые зарезервированы для нужд системы и не должны использоваться программами. Стандарт TCP определяет диапазон хорошо известных портов от 0 до 255, в Windows и в некоторых других системах этот диапазон расширен до 0–1023. Часть портов UDP тоже выделена для системных нужд, но зарезервированного диапазона в UDP нет. Кроме того, некоторые системные утилиты используют порты за пределами диапазона 0–1023. Полный список системных портов для TCP и UDP содержится в MSDN, в разделе Resource Kits/Windows 2000 Server Resource Kit/TCP/IP Core Networking Appendixes/TCP and UDP Port Assignment.

Для отправки пакета с помощью TCP отправителю необходимо сначала установить соединение с получателем. После выполнения этого действия соединенные таким образом сокеты могут использоваться только для отправки сообщений друг другу. Если соединение разрывается (самой программой из-за проблем в сети), эти сокеты уже непригодны для установления нового соединения: они должны быть уничтожены, а вместо них созданы новые сокеты.

Механизм соединения, принятый в TCP, подразумевает разделение ролей соединяемых сторон: одна из них пассивно ждет, когда кто-то установит с ней соединение, и называется сервером, другая самостоятельно устанавливает соединение и называется клиентом. Действия клиента по установке связи заключаются в следующем: создать сокет, привязать его к адресу и порту вызвать функцию для установки соединения, передав ей адрес сервера. Если все эти операции выполнены успешно, то связь установлена, и можно начинать обмен данными. Действия сервера выглядят следующим образом: создать сокет, привязать его к адресу и порту, перевести в режим ожидания соединения и дождаться соединения. При соединении система создаст на стороне сервера специальный сокет, который будет связан с соединившимся клиентом, и обмениваться данными с подключившимся клиентом сервер будет через этот новый сокет. Старый сокет останется в режиме ожидания соединения. и другой клиент сможет к нему подключиться. Для каждого нового подключения будет создаваться новый сокет, обслуживающий только данное соединение, а исходный сокет будет по-прежнему ожидать соединения. Это позволяет нескольким клиентам одновременно соединяться с одним сервером, а серверу — не путаться в своих клиентах. Точное число клиентов, которые могут одновременно работать с сервером, в документации не приводится, но оно достаточно велико.

Установление такого соединения позволяет осуществлять дополнительный контроль прохождения пакетов. В рамках протокола TCP выполняется проверка доставки пакета, соблюдения очередности и отсутствия дублей. Механизмы обеспечения надежности достаточно сложны, и мы их здесь рассматривать не будем. Программисту для начала достаточно знать, что данные, переданные с помощью TCP, не теряются, не дублируются и доставляются в том порядке, в каком были отправлены. В противном случае отправитель получает сообщение об ошибке. Соединенные сокеты время от времени обмениваются между собой специальными пакетами, чтобы убедиться в наличии соединения.

Если из-за неполадок в сети произошел разрыв связи, при попытке отправить данные или прочитать их клиент получит отказ, а соединение будет разорвано. После этого клиент должен уничтожить сокет, создать новый и повторить подключение. Сервер также получает ошибку на сокете, обслуживающем данное соединение, но существенно позже (эта задержка может достигать часа). При обнаружении ошибки сервер просто уничтожает сокет и ждет нового подключения от клиента. Возможна ситуация, когда клиент уже подключился заново и для него создан новый сокет, а старый сокет еще не закрыт. Это не является существенной проблемой — на старом сокете рано или поздно будет получена ошибка, и он будет закрыт. Тем не менее сервер может учитывать такую ситуацию и уничтожать старый сокет, не дожидаясь, пока на нем будет получена ошибка, если новое соединение с тем же клиентом уже установлено. На исходный сокет, находящийся в режиме ожидания подключения, физические разрывы связи никак не влияют, после восстановления связи никаких действий с ним проводить не нужно. Если на клиентской стороне не удалось для новою сокета установить соединение с сервером с первого раза (из-за отсутствия связи или неработоспособности сервера), этот сокет не обязательно уничтожать: он может использоваться при последующих попытках установления связи неограниченное число раз, пока связь не будет установлена.

Протокол TCP называется потоковым потому, что он собирает входящие пакеты в один поток. В частности, если в буфере сокета лежат 30 байтов, принятые по сети, не существует возможности определить, были ли эти 30 байтов отправлены одним пакетом, 30 пакетами по 1 байт, или еще как-либо. Гарантируется только то. что порядок байтов в буфере совпадает с тем порядком, в котором они были отправлены. Принимающая сторона также не ограничена в том, как она будет читать информацию из буфера: все сразу или по частям. Это существенно отличает TCP от UDP, в котором дейтаграммы не объединяются и не разбиваются на части.

Склеивание пакетов осуществляется не только принимающей, но и отправляющей стороной. Библиотека сокетов может придержать в выходном буфере то, что кладет программа, и потом отправить одним пакетом данные, которые программа складывала в буфер постепенно. И наоборот, данные большого объема могут быть отправлены по частям, поэтому возможна ситуация, когда принимающая сторона находит в своем буфере только часть сообщения, посланного своим визави. Это значит, что оставшаяся часть сообщения придет позже. Будут ли пакеты сливаться или разбиваться на части, зависит от пропускной способности и текущей загрузке сети, определяется это алгоритмом, который называется алгоритмом Нагла.

TCP применяется там, где программа не хочет заботиться о проверке целостности данных. За отсутствие этой проверки приходится растачиваться более сложной процедурой установления и восстановления связи. Если при использовании UDP сообщение не будет отправлено из-за проблем в сети или на удаленной стороне, никаких действий перед отправкой следующего сообщения выполнять не нужно и можно использовать тот же сокет. В случае же TCP, как уже было сказано, необходимо сначала уничтожать старый сокет, затем создать новый и подключить его к серверу, и только потом можно будет снова отправлять сообщения. Другим недостатком TCP по сравнению с UDP является то, что через один TCP-сокет все пакеты отправляются только по одному адресу, в то время как через UDP-сокет разные пакеты могут быть отправлены по разным адресам. И наконец, TCP не позволяет рассылать широковещательные сообщения. Но, несмотря на эти неудобства, TCP применяется существенно чаще UDP, потому что автоматическая проверка целостности данных и гарантия их доставки является очень важным преимуществом. Кроме того, TCP гарантирует более высокую безопасность в Интернете (это связано с тем, что обеспечить безопасность при передаче данных легче при наличии соединения, а не в ситуации, когда пакеты могут передаваться от кого угодно кому угодно).

То, что TCP склеивает данные в один поток, не всегда удобно. Во многих случаях пакеты, приходящие по сети, обрабатываются отдельно, поэтому читать их из буфера желательно тоже по одному. Это просто сделать, если все пакеты имеют одинаковую длину. Но при различной длине пакетов принимающая сторона заранее не знает, сколько байтов нужно прочитать из буфера, чтобы получить ровно один пакет и ни байта больше. Чтобы обойти эту ситуацию, в пакете можно предусмотреть обязательный заголовок фиксированной длины, одно из полей которого хранит длину пакета. В этом случае принимающая сторона может читать пакет по частям: сначала заголовок известной длины, а потом тело пакета, размер которого стал известен благодаря заголовку. Другой способ разделения пакетов — вставка между ними заранее оговоренной последовательности байтов, которая не может появиться внутри пакета.

Но самое неудобное то, что пакеты не только склеиваются, но и разбиваются на части. Принимающая сторона может получить пакет меньшего размера, чем отправленный, если этот пакет был послан по частям, и на момент его чтения принимающей стороной еще не все части были получены. Тогда приходится повторять операцию чтения данных, пока не будет получено все, что нужно.

В отличие от UDP, в TCP данные, которые программа отправляет одной командой, могут разбиваться на части и отправляться несколькими IP-пакетами. Поэтому ограничение на длину данных, отправляемых за один раз, в TCP отсутствует (точнее, определяется доступными ресурсами системы). Количество данных, получаемое отправителем за одну операцию чтения, ограничено размером низкоуровневого буфера сокета и может быть разным в различных реализациях. Следует иметь в виду, что при переполнении буфера принимающей стороны протокол TCP предусматривает передачу отправляющей стороне сигнала, по которому она приостанавливает отправку, причём этот сигнал прерывает всю передачу данных между этими двумя компьютерами с помощью TCP, т.е. это может повлиять и на другие программы. Поэтому желательно не допускать таких ситуаций, когда у принимающей стороны в буфере накапливается много данных.

Сеть не только позволяет пересылать полезные данные, но и может служить путем проникновения вредоносных программ, несанкционированного доступа к данным и т.п. С этим, естественно, борются, и один из способов борьбы — сетевые экраны (они же брандмауэры, иди firewalls). Мы здесь не будем детально знакомиться с ними, но затронем эту тему, потому что сетевые экраны могут повлиять на работоспособность наших примеров. Сетевые экраны бывают аппаратными и программными. Их общий принцип действия заключается в проверке пакетов, идущих по сети, и блокировании тех из них, которые не удовлетворяют заданным критериям. Критерии могут быть различными и зависят от настройки конкретного сетевого экрана. Все пакеты делятся на входящие и исходящие. Для входящих UDP-сообщений обычно оставляют открытыми некоторые порты, а все сообщения, присланные на другие порты, отсекаются. Для исходящих сообщений тоже может быть задан набор портов, но обычно сетевые экраны осуществляют проверку по-другому: у них есть список приложений, которым разрешено отправлять исходящие UDP-сообщения, а пакеты, отправляемые другими приложениями, сетевой экран не пропускает.

Для протокола TCP настройки обычно задаются на уровне соединения, а не отдельного пакета. Составляется список портов, открытых для внешнего подключения. Если сервер использует порт не из этого набора, клиент не сможет к нему подключиться. Для исходящих подключений тоже составляется список программ, которым разрешено это к делать, и, если клиент, отсутствующий в "белом" списке сетевого экрана, пытается подключиться к удаленному серверу, сетевой экран не допускает этого.

Примечание

Здесь описаны наиболее типичные способы локальной фильтрации пакетов сетевым экраном. В каждом конкретном случае могут применяться другие правила.

При тестировании своих примеров или примеров из этой книги вы можете столкнуться с тем, что программы по непонятным причинам не могут обмениваться данными по сети, и это может объясняться работой сетевых экранов. Проконсультируйтесь у администратора сети насчет настроек сетевых экранов в вашей сети и согласуйте с ним возможность работы с теми или иными портами и запуска ваших приложений. 

До сих пор мы обсуждали только теоретические аспекты работы с сокетами. Далее будут рассматриваться конкретные функции, позволяющие осуществлять те или иные операции с сокетами. Эти функции экспортируются системной библиотекой wsock32.dll (а также библиотекой ws2_32.dll; взаимоотношение этих библиотек будет обсуждаться во втором разделе данной главы), для их использования в Delphi в раздел uses нужно добавить стандартный модуль

WinSock

Хотя ранее мы договорились, что будем обсуждать только стандартные сокеты, тем не менее, есть три функции, относящиеся к сокетам Windows, не познакомившись с которыми мы не сможем двигаться дальше. Это функции

WSAStartup

WSACleanup

WSAGetLastError

Функция

WSAStartup

function WSAStartup(wVersionRequired: Word; var WSData: TWSAData): Integer;

Параметр

wVersionRequired

WinSock

Параметр

WSData

Нулевое значение, возвращаемое функцией, говорит об успешном завершении, в противном случае возвращается код ошибки. Обычно функция, завершившаяся с ошибкой, возвращает значение

SOCKET_ERROR

Функция

WSACleanup

WSAStartup

CoInitialize

WSACleanup

WSAStartup

Большинство функций библиотеки сокетов возвращают значение, позволяющее судить только об успешном или неуспешном завершении операции, но не дающее информации о том, какая именно ошибка произошла (если она произошла). Для получения сведений об ошибке служит функция

WSAGetLastError

WSAGetLastError

Забегая чуть вперед, отметим, что библиотека сокетов содержит стандартную функцию

getsockopt

WSAGetLastError

getsockopt

Для создания сокета предусмотрена стандартная функция

socket

function socket(af, struct, protocol: Integer): TSocket;

Параметр

аf

AF_INET

Параметр

struct

SOCK_STREAM

SOCK_DGRAM

Параметр

protocol

IPPROTO_IP

IPPROTO_RDP

IPPROTO_TCP

IPPROTO_UDP

Тип

TSocket

TSocket

socket

INVALID_SOCKET

WSAGetLastError

Сокет, созданный с помощью функции

socket

bind

function bind(s: TSocket; var addr: TSockAddr; namelen: Integer): Integer;

Первый параметр этой функции — дескриптор сокета. который привязывается к адресу. Здесь, как и в остальных подобных случаях, требуется передать значение, которое вернула функция

socket

Функция

bind

WinSock

bind

int bind(SOCKET s, const struct sockaddr FAR* name, int namelen);

Видно, что второй параметр — это указатель на структуру

sockaddr

bind

TSockAddr

bind

Примечание

На самом деле существует способ передать в функцию

bind

с таким прототипом параметр

addr

любого типа, совместимого с этой функцией. Если

A

— некая переменная типа, отличающегося от

TSockAddr

, то передать в качестве параметра-переменной ее можно так:

PSockAddr(@А)^

. Однако подобные низкоуровневые операции программу не украшают.

В стандартной библиотеке сокетов (т.е. в заголовочных файлах для этой библиотеки) полагается, что адрес кодируется структурой

sockaddr

PF_INET

AF_INET

AF_XXX

PF_XXX

sockaddr

char

char

Char

ShortInt

bind

Ранее уже упоминалось, что неструктурированное представление адреса в виде массива из 14 байтов бывает неудобно, и поэтому для каждого семейства протоколов предусмотрена своя структура, учитывающая особенности адреса. В частности, для протоколов стека TCP/IP используется структура

sockaddr_in

Можно было бы предположить, что типы

TSockAddr

TSockAddrIn

sockaddr

sockaddr_in

SunB = packed record

 s_b1, s_b2, s_b3, s_b4: u_char;

end;

SunW = packed record

 s_w1, s_w2: u_short;

end;

in_addr = record

 case Integer of

 0: (S_un_b: SunB);

 1: (S_un_w: SunW);

 2: (S_addr: u_long);

end;

TInAddr = in_addr;

sockaddr_in = record

 case Integer of

 0: (

  sin_family: u_short;

  sin_port: u_short;

  sin_addr: TInAddr;

  sin_zero: array[0..7] of Char);

 1: (

  sa_family: u_short;

  sa_data: array[0..13] of Char);

end;

TSockAddrIn = sockaddr_in;

TSockAddr = sockaddr_in;

Таким образом, типы

TSockAddr

TSockAddrIn

sockaddr_in

sockaddr_in

sockaddr_in

WinSock

sockaddr_in

WinSock

sockaddr_in

sockaddr

Примечание

Из названия типов можно сделать вывод, что тип

u_short

— это

Word

, а

u_long

—

Cardinal

. На самом деле

u_short

— это действительно

Word

, а вот

u_long

— это

LongInt

. Сложно сказать почему выбран знаковый тип там, где предполагается беззнаковый. Видимо, это осталось в наследство от старых версий Delphi, которые не поддерживали тип

Cardinal

в полном объеме. Кстати, тип

u_char

— это

Char

, а не

Byte

.

Перейдем, наконец, к более практически важному вопросу: какими значениями следует заполнять переменную типа

TSockAddr

bind

sockaddr_in

sin

Поле

sin_zero

sin_family

sin_port

htons

IP-адрес для привязки сокета задается полем

sin_addr

TInAddr

Пусть у нас есть переменная

Addr

TSockAddr

sin_addr

Addr.sin_addr.S_un_b.s_b1 := 192;

Addr.sin_addr.S_un_b.s_b2 := 168;

Addr.sin_addr.S_un_b.s_b3 := 200;

Addr.sin_addr.S_un_b.s_b4 := 217;

Существует альтернатива такому присвоению четырех полей по отдельности — функция

inet_addr

inet_addr

Addr.sin_addr.S_addr := inet_addr('192.168.200.217');

Функция

inet_addr

inet_addr

Примечание

Если строка, переданная функции

inet_addr

, не распознается как допустимый адрес, то функция возвращает значение

INADDR_NONE

. До пятой версии Delphi включительно эта константа имеет значение

$FFFFFFFF

, начиная с шестой версии — значение -1. Поле

S_addr

имеет тип

u_long

, который, как отмечалось, соответствует типу

LongInt

, т.е. является знаковым. Сравнение знакового числа с беззнаковым обрабатывается компилятором особым образом (подробнее об этом написано в разд. 3.1.4), поэтому, если просто сравнить

S_addr

и

INADDR_NONE

в старых версиях Delphi, получится неправильный результат. Перед сравнением константу

INADDR_NONE

следует привести к типу

u_long

, тогда операция выполнится правильно. В шестой и более поздних версиях Delphi приведение не обязательно, но оно не мешает, поэтому в целях совместимости со старыми версиями его тоже лучше выполнять.

В библиотеке сокетов предусмотрена константа

INADDR_ANY

sin_addr.S_addr

INADDR_ANY

Итак, резюмируем все сказанное. Пусть у нас есть сокет S, который нужно привязать, например, к адресу

192.168.200.217

Addr.sin_family := PF_INET;

Addr.sin_addr.S_addr := inet_addr('192.168.200.217');

Addr.sin_port := htons(3320);

FillChar(Addr.sin_zero, SizeOf(Addr.sin_zero), 0);

if bind(S, Addr, SizeOf(Addr)) = SOCKET_ERROR  then

begin

 // какая-то ошибка, анализируем с помощью WSAGetLastError

end;

FillChar

sin_zero

ZeroMemory

memset

Теперь рассмотрим другой случай: пусть выбор адреса и порта можно оставить на усмотрение системы. Тогда код будет выглядеть так, как показано в листинге 2.4.

Addr.sin_family := PF_INET;

Addr.sin_addr.S_addr := INADDR_ANY;

Addr.sin_port := 0;

FillChar(Addr.sin_zero, SizeOf(Addr.sin_zero), 0);

if bind(S, Addr, SizeOf(Addr)) = SOCKET_ERROR then

begin

 // какая-то ошибка, анализируем с помощью WSAGetLastError

end;

В случае TCP сервер сам не является инициатором подключения, но может работать с любым подключившимся клиентом, какой бы у него ни был адрес.

Для сервера принципиально, какой порт он будет использовать — если порт не определен заранее, клиент не будет знать, куда подключаться. Поэтому номер порта является важным признаком для сервера. (Иногда, впрочем встречаются серверы, порт которых заранее неизвестен, но в таких случаях всегда существует другой канал передачи данных, позволяющий клиенту до подключения узнать, какой порт задействован в данный момент сервером. С другой стороны, клиенту обычно непринципиально, какой порт будет у его сокета, поэтому чаще всего серверу назначается фиксированный порт, а клиент оставляет выбор системе.

Протокол UDP не поддерживает соединение, но при его применении часто одно приложение тоже можно условно назвать сервером, а другое — клиентом. Сервер создает сокет и ждет, когда кто-нибудь что-нибудь пришлет и высылает что-то в ответ, а клиент сам отправляет что-то куда-то. Поэтому, как и в случае TCP, сервер должен использовать фиксированный порт, а клиент может выбирать любой свободный.

Если у компьютера только один IP-адрес, то выбор адреса для сокета и клиент, и сервер могут доверить системе. Если компьютер имеет несколько интерфейсов к одной сети, каждый со своим IP-адресом, то выбор конкретного адреса в большинстве случаев также непринципиален и может быть оставлен на усмотрение системы. Проблемы возникают, когда у компьютера несколько сетевых интерфейсов, каждый из которых включен в свою сеть. В этом случае выбор того или иного IP-адреса для сокета привязывает его к одной из сетей, и только к одной. Поэтому нужно принять меры для того, чтобы сокет оказался привязан к той сети, в которой находится его адресат.

Ранее мы уже говорили, что в системах с несколькими сетевыми картами привязка сокета к адресу в том случае, когда его выбор доверен системе, может осуществляться не во время выполнения функции

bind

INADDR_ANY

После успешного завершения функций

socket

bind

bind

Когда сокет больше не нужен, следует освободить связанные с ним ресурсы. Это выполняется в два этапа: сначала сокет "выключается", а потом закрывается.

Для выключения сокета предусмотрена функция

shutdown

function shutdown(s: TSocket; how: Integer): Integer;

Параметр

s

how

SD_RECEIVE

SD_SEND

SD_BOTH

SOCKET_ERROR

SD_RECEIVE

При указании значения

SD_SEND

shutdown

shutdown

Параметр

SD_BOTH

Примечание

Модуль

WinSock

до пятой версии Delphi включительно содержит ошибку: в нем не определены константы

SD_XXX

. Чтобы использовать их в своей программе, нужно объявить их так, как показано в листинге 2.5.

const

 SD_RECEIVE = 0;

 SD_SEND = 1;

 SD_BOTH = 2;

Для освобождения ресурсов, связанных с сокетом, служит функция

closesocket

SOCKET_ERROR

По умолчанию функция

closesocket

closesocket

Функция

shutdown

closesocket

shutdown

MSDN рекомендует следующий порядок закрытия TCP-сокета. Во-первых, сервер не должен закрывать свой сокет по собственной инициативе, он может это делать только после того, как был закрыт связанный с ним клиентский сокет. Клиент начинает закрытие сокета с вызова

shutdown

SD_SEND

shutdown

SD_SEND

closesocket

closesocket

shutdown

SD_SEND

SD_BOTH

closesocket

closesocket

shutdown

Мы наконец-то добрались до изучения того, ради чего сокеты и создавались: как передавать и получать с их помощью данные. По традиции начнем рассмотрение с более простого протокола UDP. Функции, которые рассматриваются в этом разделе, могут работать и с другими протоколами, и от этого их поведение может меняться. Мы здесь описываем только их поведение при использовании UDP.

Для передачи данных удалённому сокету предусмотрена функция

sendto

function sendto(s: TSocket; var Buf; len, flags: Integer; var addrto: TSockAddr; tolen: Integer): Integer;

Первый параметр данной функции задаёт сокет, который служит для передачи данных. Здесь нужно указать значение, полученное ранее от функции

socket

Buf

len

flags

flags

sendto

addrto

addrto

INADDR_ANY

tolen

SizeOf(TSockAddr)

sendto

sendto

sendto

Функцию

sendto

bind

INADDR_ANY

Если выходной буфер сокета имеет ненулевой размер,

sendto

sendto

sendto

sendto

Если размер выходного буфера сокета равен нулю, функция

sendto

sendto

В случае успешного завершения функция

sendto

len

sendto

len

sendto

SOCKET_ERROR

Для получения данных, присланных сокету, предназначена функция

recvfrom

function recvfrom(s: TSocket; var Buf; len, flags: Integer; var from: TSockAddr; var fromlen: Integer): Integer;

Параметр

s

Buf

flags

from

fromlen

SizeOf(TSockAddr)

SizeOf(TSockAddr)

В оригинале параметры

from

fromlen

WinSock

PSockAddr(nil)^

PInteger(nil)^

Функция

reсvfrom

recvfrom

Значение, возвращаемое функцией

recvfrom

sendto

len

SOCKET_ERROR

Если размер буфера, определяемого параметром

Buf

recvfrom

WSAGetLastError

WSAEMSGSSIZE

recvfrom

Другой способ избежать подобной проблемы — использовать флаг

MSG_PEEK

recvfrom

Buf

recvfrom

MSG_PEEK

recvfrom

MSG_PEEK

recvfrom

bind

sendto

Протокол UDP не поддерживает соединения в том смысле, в котором их поддерживает TCP, но библиотека сокетов позволяет частично имитировать такие соединения, Для этого служит функция

connect

function connect(s: TSocket; var name: TSockAddr; namelen: Integer): Integer;

Параметр

s

addr

sendto

namelen

SizeOf(TSockAddr)

SOCKET_ERROR

connect

connect

connect

connect

Программа может вызывать 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

recvfrom

sendto

recv

send

Возможные последовательности действий программы для протокола UDP показаны на рис. 2.1.

Попробуем применить свои знания на практике и напишем простейший чат на основе протокола UDP. Пример этой программы находится на прилагаемом к книге компакт-диске и называется UDPChat, окно приложения показано на рис. 2.2.

Прежде чем писать программу, необходимо определиться с форматом передаваемых данных (т.е. договориться о протоколе уровня представлений). Так как мы пишем простейший пример, то и протокол у нас будет простейшим: дейтаграмма содержит текстовое сообщение, введенное пользователем, без завершающего нуля (он не нужен, т.к. размер строки определяется размером дейтаграммы) и без дополнительной служебной информации.

Для начала нам потребуется научиться сообщать пользователю об ошибках. Номер ошибки мало что дает даже опытному пользователю, поэтому сообщения должны быть дружественными, с внятным объяснением того, какая именно ошибка произошла. К счастью, мы избавлены от необходимости вручную писать текстовое сообщение для каждой из возможных ошибок, т.к. в системе уже есть функция

FormatMessage

FormatMessage

GetErrorString

WSAGetLastError

Рис. 2.2. Главное окно UDP-чата

// функция 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

Нить, читающая данные, создается обычным образом — порождением наследника от класса

TThread

FSocket

unit ReceiveThread;

{

 В этом модуле реализуется дополнительная нить UDP-чата, отвечающая за прием сообщений.

}

interface

uses

 SysUtils, Classes, WinSock;

type

 TReceiveThread = class(TThread)

 private

  // Сообщение, которое нужно добавить в лог,

  // хранится в отдельном поле, т.к. метод, вызывающийся через

  // Synchronize, не может иметь параметров.

  FMessage: string;

  // Сокет, получающий сообщения

  FSocket: TSocket;

  // Вспомогательный метод для вызова через Synchronize

  procedure DoLogMessage;

 protected

  procedure Execute; override;

  // Вывод сообщения в лог главной формы

  procedure LogMessage(const Msg: string);

 public

  constructor Create(ServerSocket: TSocket);

 end;

implementation

uses ChatMainUnit;

{TReceiveThread}

// Сокет, получающий сообщения, создается в главной нити,

// а сюда передаётся через параметр конструктора

constructor TReceiveThread.Create(ServerSocket: TSocket);

begin

 FSocket := ServerSocket;

 inherited Create(False);

end;

procedure TReceiveThread.Execute;

var

 // Буфер для получения сообщения.

 // Размер равен максимальному размеру UDP-дейтаграммы

 Buffer: array[0..65506] of Byte;

 // Адрес, с которого пришло сообщение

 RecvAddr: TSockAddr;

 RecvLen, AddrLen: Integer;

 Msg: string;

begin

 // Начинаем бесконечный цикл, на каждой итерации которого

 // читается одна дейтаграмма

 repeat

  AddrLen := SizeOf(RecvAddr);

  // Получаем дейтаграмму

  RecvLen :=

   recvfrom(FSocket, Buffer, SizeOf(Buffer), 0, RecvAddr, AddrLen);

  // Так как UDP не поддерживает соединение, ошибку при вызове recvfrom

  // мы можем получить, только если случилось что-то совсем

  // экстраординарное. В этом случае завершаем работу нити.

  if RecvLen < 0 then

  begin

   LogMessage('Ошибка при получении сообщения: ' + GetErrorString);

   // Перевод элементов управления главной формы

   // в состояние "Сервер не работает"

   Synchronizе(ChatForm.OnStopServer);

   Break;

  end;

  // Устанавливаем нужный размер строки

  SetLength(Msg, RecvLen);

  // и копируем в нее дейтаграмму из буфера

  if RecvLen > 0 then Move(Buffer, Msg[1], RecvLen);

  LogMessage('Сообщение с адреса ' + inet_ntoa(RecvAddr.sin_addr) + ':' +

   IntToStr(ntohs(RecvAddr.sin_port)) + ':' + Msg);

 until False;

 closesocket(FSocket);

end;

procedure TReceiveThread.LogMessage(const Msg: string);

begin

 FMessage := Msg;

 Synchronize(DoLogMessage);

end;

procedure TReceiveThread.DoLogMessage;

begin

 ChatForm.AddMessageToLog(FMessage);

end;

end.

Отправлять данные можно и из основной нити, поскольку функция

sendto

OnCreate

FSendSocket

procedure TChatForm.FormCreate(Sender: TObject);

var

 // Без этой переменной не удастся инициализировать библиотеку сокетов

 WSAData: TWSAData;

 // Адрес, к которому привязывается сокет для отправки сообщений

 Addr: TSockAddr;

 AddrLen: Integer;

begin

 // инициализация библиотеки сокетов

 if WSAStartup($101, WSAData) <> 0 then

 begin

  MessageDlg('Ошибка при инициализации библиотеки WinSock',

   mtError, [mbOK], 0);

  Application.Terminate;

 end;

 // Перевод элементов управления в состояние "Сервер не работает"

 OnStopServer;

 // Создание сокета

 FSendSocket := socket(AF_INET, SOCK_DGPAM, IPROTO_UDP);

 if FSendSocket = INVALID_SOCKET then

 begin

  MessageDlg('Ошибка при создании отправляющего сокета:'#13#10 +

   GetErrorString, mtError, [mbOK], 0);

  Exit;

 end;

 // Формирование адреса, к которому будет привязан сокет

 // для отправки сообщений

 FillChar(Addr.sin_zero, SizeOf(Addr.sin_zero), 0);

 Addr.sin_family := AF_INET;

 // Пусть система сама выбирает для него IP-адрес и порт

 Addr.sin_addr.S_addr := INADDR_ANY;

 Addr.sin_port := 0;

 // Привязка сокета к адресу

 if bind(FSendSocket, Addr, SizeOf(Addr)) = SOCKET_ERROR then

 begin

  MessageDlg('Ошибка при привязке отправляющего сокета к адресу:'#13#10 +

   GetErrorString, mtError, [mbOK], 0);

  Exit;

 end;

 // Узнаем, какой адрес система назначила сокету

 // Это нужно для вывода информации для пользователя

 AddrLen := SizeOf(Addr);

 if getsockname(FSendSocket, Addr, AddrLen) = SOCKET_ERROR then

 begin

  MessageDlg('Ошибка при получении адреса отправляющего сокета:'#13#10 +

   GetErrorString, mtError, [mbOK], 0);

  Exit;

 end;

 // Не забываем, что номер порта возвращается в сетевом формате,

 // и его нужно преобразовать к обычному функцией htons.

 LabelSendPort.Caption := 'Порт отправки: ' + IntToStr(ntohs(Addr.sin_port));

end;

Сокет для получения сообщений создается при нажатии кнопки Запустить и привязывается к тому порту, который указал пользователь. В случае его успешного создания запускается нить, которой передается этот сокет, и все дальнейшие операции с ним выполняет эта нить. Нить вместе с этим сокетом мы будем условно называть сервером. Код обработчика нажатия кнопки Запустить показан в листинге 2.9.

// Реакция на кнопку "Запустить"

procedure TChatForm.BtnStartServerClick(Sender: TObject);

var

 // Сокет для приема сообщений

 ServerSocket: TSocket;

 // Адрес, к которому привязывается сокет для приема сообщений

 ServerAddr: TSockAddr;

begin

 // Формирование адреса сокета для приема сообщений

 FillChar(ServerAddr.sin_zero, SizeOf(ServerAddr.sin_zero), 0);

 ServerAddr.sin_family := AF_INET;

 // IP-адрес может выбрать система, а порт назначаем тот,

 // который задан пользователем

 ServerAddr.sin_addr.S_addr := INADDR_ANY;

 try

  // He забываем преобразовать номер порта к сетевому формату

  // с помощью функции htons

  ServerAddr.sin_port := htons(StrToInt(EditServerPort.Text));

  if ServerAddr.sin_port = 0 then

  begin

   MessageDlg('Номер порта должен находиться в диапазоне 1-65535',

    mtError, [mbOK], 0);

   Exit;

  end;

  // Создание сокета для получения сообщений

  ServerSocket := socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

  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;

  // Создание нити, которая будет получать сообщения.

  // Сокет передается ей, и дальше она отвечает за него.

  TReceiveThread.Create(ServerSocket);

  // Перевод элементов управления в состояние "Сервер работает"

  LabelServerPort.Enabled := False;

  EditServerPort.Enabled := False;

  BtnStartServer.Enabled := False;

  LabelServerState.Caption:= 'Сервер работает';

 except

  on EConvertError do

   // Это исключение может возникнуть только в одном месте -

   // при вызове StrToInt(ЕditServerPort.Text)

   MessageDlg('"' + EditServerPort.Text +

    '" не является целым числом', mtError, [mbOK], 0);

  on ERangeError do

   // Это исключение может возникнуть только в одном месте -

   // при присваивании значения номеру порта

   MessageDlg('Номер порта должен находиться в диапазоне 1-65535",

    mtError, [mbOK], 0);

 end;

end;

Для отправки сообщения пользователь должен нажать кнопку Отправить. При этом формируется адрес на основании введённых пользователем данных и вызывается функция

sendto

// Реакция на кнопку "Отправить"

procedure TChatFormBtnSendClick(Sender: TObject);

var

 // Адрес назначения SendAddr: TSockAddr;

 // Сообщение для отправки

 Msg: string;

 // Результат отправки

 SendRes: Integer;

begin

 // Формируем адрес назначения на основе того,

 // что пользователь ввел в соответствующие поля

 FillChar(SendAddr.sin_zero, SizeOf(SendAddr.sin_zero), 0);

 SendAddr.sin_family := AF_INET;

 SendAddr.sin_addr.S_addr := inet_addr(PChar(EditSendAddr.Text));

 // Для совместимости со старыми версиями Delphi приводим

 // константу INADDR_NONE к типу u_long

 if SendAddr.sin_addr.S_addr = u_long(INADDR_NONE) then

 begin

  MessageDlg('"' +EditSendAddr.Text + '"не является IP-адресом',

   mtError, [mbOK], 0);

  Exit;

 end;

 try

  SendAddr.sin_port := htons(StrToInt(EditSendPort.Text));

  // Получаем сообщение, которое ввел пользователь.

  // Дополнительная переменная понадобилась потому,

  // что нам потребуется ее передавать в качестве var-параметра,

  // а делать это со свойством EditMessage.Техt нельзя.

  Msg := EditMessage.Text;

  if Length(Msg) = 0 then

   // Отправляем дейтаграмму нулевой длины -

   // протокол UDP разрешает такое

   SendRes := sendto(FSendSocket, Msg, 0, 0, SendAddr, SizeOf(SendAddr))

  else

   // Отправляем сообщение, содержащее строку

   SendRes := sendto(FSendSocket, Msg[1], Length(Msg), 0, SendAddr, SizeOf(SendAddr));

  if SendRes < 0 then

   MessageDlg('Ошибка при отправке сообщения:'#13#10 + GetErrorString,

    mtError, [mbOK], 0)

  else

   AddMessageToLog('Для ' + EditSendAddr.Text + ':' + EditSendPort.Text +

    ' отправлено сообщение: ' + Msg);

 except

  on EConvertError do

   // Это исключение может возникнуть только в одном месте -

   // при вызове IntToStr(EditSendPort.Text)

   MessageDlg('"' + EditSendPort.Text + не является целым числом',

    mtError, [mbOK], 0);

  on ERangeError do

   // Это исключение может возникнуть только в одном месте -

   // при присваивании значения номеру порта

   MessageDlg('Номер порта должен находиться в диапазоне 1-65535',

    mtError, [mbOK], 0);

 end;

end;

Заметим, что в нашем сервере есть один очень неудобный момент. Предположим, получено сообщение, и программа высветила следующую надпись: "Сообщение с адреса 192.168.200.211:2231. Привет!". Порт, который указан в этом сообщении — это порт того сокета, который используется на удаленной стороне для отправки сообщений. Для их получения там предназначен другой сокет и другой порт, поэтому цифра 2231 не несет никакой информации о том, на какой порт нужно отправлять ответ. В нашем примитивном чате соответствие между номерами портов для отправки и для получения сообщений пользователю приходится держать в голове. По сути дела, более-менее нормальная работа такого чата возможна только тогда, когда все пользователи используют один и тот же порт для сокета, принимающего сообщения (или когда компьютеры стоят рядом, и пользователи могут сообщить друг другу номера своих портов).

Не будем слишком строги к нашему первому примеру — его ценность в том, что он учит основам использования сокетов и протокола UDP. Проблему можно было бы решить, передавая в дейтаграмме не только сообщения, но и номер порта для ответа и реализовав в программе таблицу соответствия портов для отправки и приема сообщений известных адресатов. Однако это уже не относится к работе с сокетами, и потому мы не стали загромождать этим пример. Чуть позже мы научимся делать так, что функция

recvfrom

Здесь возникает вопрос: нельзя ли с помощью

sendto

recvfrom

В заключение отметим, что наш чат допускает одновременное общение любого количества человек с любого числа адресов, но сообщения всегда передаются от одного человека к другому. Широковещательных и групповых сообщений у нас нет. Отметим также, что отправлять сообщения можно и не запуская "сервер".

Примечание

Для того чтобы протестировать работу чата, не обязательно иметь два компьютера, соединенных в сеть. Два или более экземпляра чата можно запустить и на одном компьютере, главное, чтобы у них у всех были разные порты для принимающего сокета. В качестве IP-адреса для отправки сообщений можно задавать адрес локального компьютера вида 127.0.0.N. Это же верно и для всех остальных примеров работы с сокетами.

При программировании TCP и UDP применяются одни и те же функции, но их поведение при этом различно. Для передачи данных с помощью TCP необходимо сначала установить соединение, и после этого возможен обмен данными только с тем адресом, с которым это соединение установлено. Функция

sendto

send

recv

recvfrom

В TCP существует разделение ролей взаимодействующих сторон на клиент и сервер. Мы начнем изучение передачи данных в TCP с изучения действий клиента.

Для начала взаимодействия клиент должен соединиться с сервером с помощью функции

connect

connect

connect

bind

В отличие от UDP, сокет в TCP нельзя отсоединить или соединить с другим адресом, если он уже соединен. Для нового соединения необходим новый сокет.

Мы уже говорили, что TCP является надежным протоколом, т.е. в том случае, если пакет не доставлен, отправляющая сторона уведомляется об этом.

Тем не менее успешное завершение

send

Если выходной буфер сокета равен нулю, данные сразу копируются в сеть, но успешное завершение функции и в этом случае не гарантирует успешную доставку. Использовать нулевой выходной буфер для TCP-сокетов не рекомендуется, т.к. это снижает производительность при последовательной отправке данных небольшими порциями. При буферизации эти порции накапливаются в буфере, а потом отправляются одним большим пакетом, требующим одного подтверждения от клиента. Если же буферизация не осуществляется, то будет отправлено несколько мелких пакетов, каждый со своим заголовком и своим подтверждением от клиента, что приведет к снижению производительности.

Функция

recv

Buf

len

recv

recv

recv

SOCKET_ERROR

Теперь рассмотрим, какие действия при использовании TCP должен выполнить сервер. Как мы уже говорили, сервер должен перевести сокет в режим ожидания соединения. Это делается с помощью функции

listen

function listen(s: TSocket; backlog: Integer): Integer;

Параметр s задает сокет, который переводится в режим ожидания подключения. Этот сокет должен быть привязан к адресу, т.е. функция

bind

backlog

SOMAXCONN

SOCKET_ERROR

Когда клиент вызывает функцию

connect

accept

function accept(s: TSocket; addr: PSockAddr; addrlen: PInteger) : TSocket;

Параметр

s

addr

addrlen

addr

SizeOf(TSockAddr)

В случае ошибки функция

accept

INVALID_SOCKET

recv

send

closesocket

Исходный сокет, определяемый параметром

s

accept

Для получения целостной картины кратко повторим все сказанное. Для установления соединения сервер должен, во-первых, создать сокет с помощью функции

socket

bind

listen

accept

bind

connect

var

 S, AcceptedSock: TSocket;

 Addr: TSockAddr;

 Data: TWSAData;

 Len: Integer;

begin

 WSAStartup($101, Data);

 S := socket(AF_INET, SOCK_SТREAМ, 0);

 Addr.sin_family := FF_INET;

 Addr.sin_port := htons(3030);

 Addr.sin_addr.S_addr := INADDR_ANY;

 FillChar(Addr.sin_zero, SizeOf(Addr.sin_zero), 0);

 bind(S, Addr, SizeOf(TSockAddr));

 listen(S, SOMAXCONN);

 Len := SizeOf(TSockAddr);

 AcceptedSock := accept(S, @Addr, @Len);

 {

  Теперь Addr содержит адрес клиента, с которым установлено соединение, а AcceptedSock - дескриптор, обслуживающий это соединение. Допустимы следующие действия:

  send(AcceptedSock, ...) - отправить данные клиенту

  recv(AcceptedSock, ...) - получить данные от клиента

  accept(...) - установить соединение с новым клиентом

 }

Здесь сокет сервера привязывается к порту с номером 3030. В общем случае разработчик сервера сам должен выбрать порт из диапазона 1024–65 535.

var

 S: TSocket;

 Addr: TSockAddr;

 Data: TWSAData;

begin

 WSAStartup($101, Data);

 S := socket(AF_INET, SOCK_STREAM, 0);

 Addr.sin_family := AF_INET;

 Addr.sin_port := htons(3030);

 Addr.sin_addr.S_addr := inet_addr(...);

 FillChar(Addr.sin_zero, SizeOf(Addr.sin_zero), 0);

 connect(S, Addr, SizeOf(TSockAddr));

 {

  Теперь соединение установлено. Допустимы следующие действия:

  send(S, ...) - отправить данные серверу

  recv(S, ...) — получить данные от сервера

 }

В приведенном коде для краткости опущены проверки результатов функций с целью обнаружения ошибок. При написании серьезных программ этим пренебрегать нельзя. Блок-схема действии клиента и сервера приведена на рис. 2.3.

Если на момент вызова функции

accept

accept

accept

acсept

accept

recv

send

send

recv

Рис. 2.3. Последовательность действий клиента и сервера при использовании TCP

То, что функция

recv

ReadFromSocket

recv

ReadFromSocket

// Функция читает Cnt байтов в буфер Buffer из сокета S

// Учитывается, что может потребоваться несколько операций чтения,

// прежде чем будет прочитано нужное число байтов.

// Возвращает:

// 1 — в случае успешного чтения

// 0 - в случае корректного закрытия соединения удаленной стороной

// -1 — в случае ошибки чтения

function ReadFromSocket(S: TSocket; var Buffer; Cnt: Integer): Integer;

var

 Res, Total: Integer;

begin

 // Total содержит количество принятых байтов

 Total := 0;

 // Читаем байты в цикле до тех пор, пока не будет прочитано Cnt байтов

 repeat

  // На каждой итерации цикла нам нужно прочитать

  // не более чем Cnt - Total байтов, т.е. не более

  // чем нужное количество минус то, что уже прочитано

  // на предыдущих итерациях. Очередную порцию данных

  // помещаем в буфер со смещением Total.

  Res := recv(S, (PChar(@Buffer) + Total)^, Cnt - Total, 0);

  if Res = 0 then

  begin

   // Соединение закрыто удаленной стороной

   Result := 0;

   Exit;

  end;

  if Res < 0 then

  begin

   // Произошла ошибка при чтении

   Result := -1;

   Exit;

  end;

  Inc(Total, Res);

 until Total >= Cnt;

 Result:= 1;

end;

Эта функция будет использоваться в дальнейшем в нескольких наших примерах.

Теперь у нас достаточно знаний, чтобы написать TCP-клиент и TCP-сервер. Как и в случае с UDP, сначала нужно договориться о том, какими данными и в каком формате будут обмениваться наши программы. С протоколом, описанным здесь, нам предстоит работать на протяжении всей главы. По мере изучения новых возможностей библиотеки сокетов мы будем реализовывать новые варианты серверов и клиентов, но почти все они будут поддерживать один и тот же протокол, поэтому любой клиент сможет работать с любым сервером.

Наши сервер и клиент будут обмениваться строковыми сообщениями: клиент пошлет строку, сервер отправит ответ. Мы уже не можем, как в случае UDP, просто отправить строку, потому что при использовании TCP несколько строк могут быть отправлены одним пакетом, или наоборот, одна строка разбита на несколько пакетов. Соответственно, наш протокол должен позволять определить, где заканчивается одна строка и начинается другая.

Ранее мы уже упоминали три основных способа определения границ логического пакета в TCP: все пакеты могут иметь одинаковую длину, пакет может предваряться фиксированным заголовком, содержащим длину, между пакетами может вставляться заранее оговоренная последовательность байт. Первый способ самый легкий в реализации, но он накладывает существенные ограничения на передаваемые данные. В частности, нам он не подходит, потому что мы будем передавать строки произвольной длины. Второй и третий способы приемлемы для передачи строк, и чтобы проиллюстрировать как можно больше различных вариантов в наших примерах, мы будем использовать их оба. При передаче данных от клиента серверу, мы будем перед строгой передавать четырёхбайтное значение — длину строки, а при передаче данных от сервера клиенту длину строки мы передавать не будем, но к каждой строке будет добавляться символ

#0

#0

Все серверы, которые мы напишем, будут возвращать клиенту присланную строку, но слегка преобразованную. Во-первых, все символы

#0

#0

Практическое знакомство с TCP мы начнем с написания простейшего сервера. На компакт-диске этот сервер находится в папке

SimplestServer

Наш простейший сервер будет использовать только одну нить. Как мы помним, сервер должен вызывать две функции, которые блокируют работу нити: accept и recv. Очевидно, что задействовать их обе сразу в одной нити не получится, именно поэтому наш сервер сможет работать только с одним клиентом одновременно. И чтобы не блокировать пользовательский интерфейс, наш сервер будет консольным приложением. В командной строке ему передается номер порта, к которому привязывается слушающий сокет.

Первое, что должен сделать сервер, — это создать сокет. привязать его к требуемому адресу и перевести в режим прослушивания. Этот код мало чем отличается от приведенного ранее примера создания сокета для UDP (см. листинг 2.8). Вся разница только в том, что вместо сокета типа

SOCK_DGRAM

SOCK_STREAM

listen

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

// Начало цикла подключения и общения с клиентом

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

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

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).

procedure TSimpleClientForm.BtnDisconnectClick(Sender: TObject);

begin

 shutdown(FSocket, SD_BOTH);

 closesocket(FSocket);

 OnDisconnect;

end;

Откомпилируем наши примеры и посмотрим, что получилось. Пока у нас один клиент работает с одним сервером, все вполне предсказуемо: клиент передает сообщения, сервер на них отвечает. Попытаемся подключиться вторым клиентом, не отключая первый, и посмотрим, что будет. Само подключение с точки зрения клиента проходит нормально, хотя сервер находится в своем внутреннем цикле и не вызывает

accept

recv

accept

Простейший сервер и эксперименты с ним, конечно, очень познавательны, но на практике хотелось бы иметь такой сервер, который может работать одновременно с несколькими клиентами. Чтобы добиться этого, сделаем так же, как при написании UDP-чата: вынесем в отдельные нити работу с блокирующими функциями (пример

MultithreadedServer

TListenThread

// Реакция на кнопку Запустить

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

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

Код нити типа

TClientThread

// Сокет для взаимодействия с клиентом создается в главной нити,

// а сюда передается через параметр конструктора. Для формирования

// заголовка сюда же передается адрес подключившегося клиента

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

Этот сервер уже можно использовать как образец для подражания. Нужно только помнить, что он тратит на каждого клиента относительно много ресурсов, и поэтому не подходит там, где могут подключаться сотни и более клиентов одновременно. Кроме того, этот сервер очень уязвим по отношению к DoS-атакам, поэтому подобный сервер целесообразен там. где число клиентов относительно невелико, а вероятность DoS-атак низка.

Примечание

DoS-атака (Denied of Service) — способ помешать функционированию сервера, заключающийся в загрузке его бесполезной работой. В простейшем случае — это просто одновременное подключение большого числа клиентов. У нас даже простое подключение большого числа клиентов приводит к большому расходу системных ресурсов, поэтому DoS-атакой можно добиться неработоспособности не только самого сервера, но и системы в целом. Полностью защититься от DoS-атаки невозможно, но можно снизить урон, наносимый ею. Об этом мы поговорим далее.

Так как многие функции библиотеки сокетов блокируют вызвавшую их нить, если соответствующая операция не может быть выполнена немедленно, часто бывает полезно заранее знать, готов ли сокет к немедленному (без блокирования) выполнению той или иной операции. Основным средством определения этого в библиотеке сокетов служит функция

select

function select(nfds: Integer; readfds, writefds, exceptfds: PFDSet; timeout: PTimeVal): LongInt;

Первый параметр этой функции оставлен только для совместимости со старыми версиями библиотеки сокетов: в существующих версиях он игнорируется. Три следующих параметра содержат указатели на множества сокетов (эти множества описываются типом

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 максимальное количество сокетов, которое может содержать в себе множество

TFDSet

FD_SETSIZE

FD_SETSIZE

TFDSet

FDSet

_SETSIZE

TFDSet

TFDSet

select

FD_XXX

Примечание

На первый взгляд может показаться, что Delphi в данном случае хуже, чем C/C++. Но достаточно хотя бы раз столкнуться с ошибкой, вызванной взаимным влиянием макроопределений в модулях C/C++, чтобы понять, что уж лучше написать несколько лишних строк кода, лишь бы никогда больше не иметь таких проблем.

Последний параметр функции

select

TTimeVal

TTimeVal = record

 tv_sec: LongInt;

 tv_usec: LongInt;

end;

Эта структура служит для задания времени ожидания. Поле

tv_sec

tv_usec

tv_sec

tv_usec

timeout

select

nil

Мы потратили достаточно много времени, выясняя структуру параметров функции

select

Функция

select

readfds

recv

recvfrom

recv

recvfrom

SOCKET_ERROR

readfds

listen

accept

Для сокетов, входящих в множество

writefds

select

send

sendto

send

sendto

Следует отметить, что большинство протоколов обмена устроено таким образом, что при их реализации проблема переполнения выходного буфера практически никогда не возникает. Чаще всего клиент и сервер обмениваются небольшими пакетами, причем сервер посылает клиенту только ответы на его запросы, а клиент не посылает новый запрос до тех пор. пока не получит ответ на предыдущий. В этом случае гарантируется, что пакеты будут уходить о выходного буфера быстрее (или, по крайней мере, не медленнее), чем программа будет их туда помещать. Поэтому заботиться о том, чтобы в выходном буфере было место, приходится достаточно редко.

И наконец, последнее множество

exceptfds

Функция

select

readfds

writefds

exceptfds

nil

В листинге 2.23 приведен пример кода TCP-сервера, взаимодействующего с несколькими клиентами в рамках одной нити и работающего по простой схеме "запрос-ответ".

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

При создании множества оно сначала очищается, а потом в него в цикле добавляются сокеты. Для любителей кратких решений есть существенно более быстрый способ формирования множества, при котором не потребуются ни циклы, ни

FD_ZERO

FD_SET

Move((PChar(Sockets) - 4)^, FDSet, Length(Sockets) * SizeOf(TSocket) + SizeOf(Integer));

Почему такая конструкция будет работать, предлагаем разобраться самостоятельно, изучив по справке Delphi, как хранятся в памяти динамические массивы, а по MSDN — структуру типа

FDSET

Второй шаг — это собственно выполнение ожидания готовности сокетов с помощью функции

select

readfds

nil

Третий шаг выполняется только после функции

select

accept

На первый взгляд может показаться странным, почему для перебора элементов массива выбран цикл

while

for

for

for

while

Напомним, что функция

select

FD_ISSET

FDSet

recv

SOCKET_ERROR

closesocket

И наконец, на четвертом шаге мы проверяем состояние готовности исходного сокета, который хранится в нулевом элементе массива. Так как этот сокет находится в режиме ожидания соединения, для него состояние готовности означает, что в очереди соединений появились клиенты, и необходимо вызвать функцию

accept

Хотя приведенный пример вполне работоспособен, следует отметить, что это только один из возможных вариантов организации сервера. Так что лучше не относиться к нему как к догме, потому что именно в вашем случае может оказаться предпочтительнее какой-либо другой вариант. Ценность этого примера заключается в том, что он иллюстрирует работу функции

select

Рассмотрим два практических примера использования функции

select

Сначала модифицируем UDP-чат (см. разд. 2.1.10) таким образом, чтобы он использовал один сокет и для отправки, и для получения сообщений (пример SelectChat на компакт-диске). Вторая нить нам теперь не понадобится, всё будет делать главная форма. Процедуры создания сокета и отправки сообщений изменений не претерпели, главное дополнение — это то, что на форме появился таймер, в обработчике события

OnTimer

select

Примечание

Несмотря на эти изменения, новая версия UDP-чата может обмениваться сообщениями со старой, т.к. протокол обмена остался неизменным.

// Реакция на таймер. С периодичностью, заданной таймером,

// проверяем, не пришли ли сообщения, и если пришли,

// получаем их.

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

Перейдем к следующему примеру использования

select

select

select

Примечание

Разумеется, ни один сервер не может работать с неограниченным числом клиентов. Здесь и далее под словом "неограниченный" подразумевается то, что количество клиентов сервера ограничивается только ресурсами системы, а не самой реализацией сервера.

Инициализация сокета и установка его в режим прослушивания в новом сервере ничем не отличается от простейшего, изменения начинаются только с цикла. Теперь цикл только один (вложенные циклы в нем есть, но они выполняют чисто техническую роль). Начинается цикл с того, что с помощью функции

select

accept

TConnection

// запись TConnection хранит информацию о подключившемся клиенте.

// поле ClientAddr содержит строковое представление адреса клиента.

// Поле ClientSocket содержит сокет, созданный функцией accept

// для взаимодействия с данным клиентом.

// Поле Deleted - служебное. Если оно равно False, значит,

// соединение с данным клиентом по каким-то причинам потеряно,

// и сервер должен освободить ресурсы, выделенные для этого клиента.

PConnection = ^Connection;

TConnection = record

 ClientAddr: string;

 ClientSocket: TSocket;

 Deleted: Boolean;

end;

Поле

ClientAddr

ClientSocket

Deleted

FConnections

TList

Deleted

После проверки новых подключений начинается проверка получения сообщений от тех клиентов, которые уже подключены. Для этого перебираются сокеты из списка подключений и для каждого вызывается

select

TFDSet

FD_SETSIZE

FD_SETSIZE

select

Для тех сокетов, которые готовы к чтению, вызывается процедура

ProcessSocketMessage

Примечание

Эта ситуация отличается от использования

select

для UDP-сокетов. С ними такой проблемы не возникает, т.к. дейтаграмма никогда не приходит по частям, и если функция

select

показала готовность сокета. значит, уже получено все сообщение целиком.

Завершается основной цикл сервера удалением всех ресурсов, связанных с закрытыми соединениями. После небольшой паузы, сделанной для того, чтобы сервер не нагружал процессор непрерывно, управление передается на начало цикла (листинг 2.26).

// Тайм-аут для функции 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

// Функция 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

Ранее мы столкнулись с функциями, которые могут надолго приостановить работу вызвавшей их нити, если действие не может быть выполнено немедленно. Это функции

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

recv

recv

ioctlsocket

FIONREAD

При задании аргумента

FIONBIO

arg

s

var

 S: TSocket;

 Arg: u_long;

begin

 ...

 Arg := 1;

 ioctlsocket(S, FIONBIO, Arg);

Пока программа использует только стандартные сокеты (а не сокеты Windows), сокет может быть переведен в неблокирующий или обратно в блокирующий режим в любой момент. Неблокирующим может быть сделан любой сокет (серверный или клиентский) независимо от протокола.

Функция

ioctlsocket

Итак, по умолчанию сокет работает в блокирующем режиме. С особенностями работы функций

accept

connect

recv

send

□ 

accept

□ 

connect

connect

□ 

recv

□ 

send

Если условия, при которых эти функции выполняются без блокирования, выполнены, то их поведение в блокирующем и неблокирующем режимах идентично. Если же выполнение операции без блокирования невозможно, функции возвращают результат, указывающий на ошибку . Чтобы понять, произошла ли ошибка из-за необходимости блокирования или из-за чего-либо еще. программа должна вызвать функцию

WSAGetLastError

WSAEWOULDBLOCK

WSAEWOULDBLOCK

Следует отметить, что при нулевом выходном буфере сокета (т.е. когда функция

send

send

send

Для функций

accept

recv

send

WSAEWOULDBLOCK

connect

select

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

Функция

send

send

len

send

send

WSAGetLastError

WSAEWOULDBLOCK

Сразу отметим, что, хотя спецификация допускает частичное копирование функцией

send

send

WSAEWOULDBLOCK

В этом разделе мы создадим сервер, основанный на неблокирующих сокетах. Это будет наш первый сервер, не использующий функцию

ReadFromSocket

NonBlockingServer

WSAEWOULDBLOCK

Запуск сервера (листинг 2.30) мало чем отличается от запуска многонитевого сервера (см. листинг 2.19). Практически вся разница заключается в том, что вместо запуска "слушающей" нити сокет переводится в неблокирующий режим и включается таймер.

// Реакция на кнопку "Запустить" - запуск сервера

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

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. 

// Обработка сообщения от таймера

// В ходе обработки проверяется наличие вновь подключившихся клиентов

// а также осуществляется обмен данными с клиентами

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

// Обработка клиента. 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

Каждый сокет обладает рядом параметров (опций), которые влияют на его работу. Существуют параметры уровня сокета, которые относятся к сокету как к объекту безотносительно используемого протокола и его уровня. Впрочем, некоторые параметры уровня сокета применимы не ко всем протоколам. Здесь мы не будем рассматривать все параметры сокета, а ограничимся лишь изложением методов доступа к ним и познакомимся с некоторыми самыми интересными параметрами.

Для получения текущего значения параметров сокета предусмотрена функция

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

optlen

getsockopt

optval

optlen

setsockopt

optval

optlen

Чаще всего параметры сокета имеют целый или логический тип. В обоих случаях параметр

optval

Integer

True

False

SOL_SOCKET

SO_RCVBUF

SO_SNDBUF

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

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.

Мы рассмотрели основные принципы работы со стандартными сокетами. Хотя многое осталось за кадром, того, что здесь было написано, достаточно, чтобы начать создавать разнообразные приложения с использованием сокетов. Для самостоятельного изучения рекомендуется сделать следующее:

□ Для каждой из упоминавшихся здесь функций выяснить, какие ошибки может возвращать

WSAGetLastError

□ посмотреть, какие еще параметры (опции) есть у сокета;

□ самостоятельно разобраться с не упомянутыми здесь функциями

getsockname

gethostbyaddr

getaddrbyhost

Из приведенных примеров видно, что стандартные сокеты достаточно интегрируются с пользовательским интерфейсом, однако приложение, использующее их, вынуждено самостоятельно опрашивать сокеты с определённой периодичностью (например, по таймеру). Это не совпадает с принятой в Windows схемой событийного управления программой, основанной на принципе "пусть мне скажут, когда что-то произойдет, и я отреагирую". Именно поэтому стандартные сокеты были расширены и появились сокеты Windows, с которыми мы познакомимся далее.

В предыдущих разделах мы рассмотрели те методы работы с сокетами, которые восходят еще к сокетам Беркли. Разработчики библиотеки сокетов для Windows добавили в нее также поддержку новых методов, упрощающих работу с сокетами для приложений, имеющих традиционную для Windows событийно-ориентированную модель. В Windows можно использовать асинхронные сокеты и перекрытый ввод-вывод. Далее мы рассмотрим эти расширения, а также ряд новых функций, пришедших на смену "морально устаревшим" функциям из стандартных сокетов.

Материал здесь, как и ранее, не претендует на полноту, а предназначен лишь для знакомства с наиболее часто употребляемыми возможностями библиотеки сокетов. По-прежнему рассматриваются только протоколы TCP и UDP. Не будут затронуты такие вопросы, как поддержка качества обслуживания, пространства имен, простые сокеты (

RAW_SOCK

При рассмотрении функции WSAStartup уже упоминалось, что существуют разные версии библиотеки сокетов, которые заметно различаются по функциональности. К сожалению, полный перечень существующих на сегодняшний день версий Windows Sockets и их особенностей в документации в явном виде не приводится, но, изучая разрозненную информацию, можно сделать некоторые выводы, которые приведены в табл. 2.1. В дальнейшем, если не оговорено иное, под WinSock 1 мы будем подразумевать версию 1.1, под WinSock 2 — версию 2.2.

Таблица 2.1. Версии Windows Sockets

WinSock 1 в 16-разрядных версиях Windows реализуется библиотекой WinSock.dll, в 32-разрядных — WSock32.dll. WinSock 2 реализуется библиотекой WS2_32.dll, и. кроме того, часть функций вынесена в отдельную библиотеку MSWSock.dll. При этом для сохранения совместимости WS2_32.dll содержит даже те устаревшие функции, которые формально исключены из спецификации WinSock 2. В тех системах, в которых установлена библиотека WinSock 2, WSock32.dll не реализует самостоятельно практически ни одной функции, а просто импортирует их из WS2_32.dll и MSWSock.dll. WSock32.dll требуется только для обратной совместимости, в новых программах необходимости в этой библиотек нет.

Как это ни удивительно, но в Delphi даже 2007-й версии (не говоря уже о более ранних) отсутствует поддержка WinSock 2. Стандартный модуль WinSock импортирует функции только из WSock32.dll, поэтому программисту доступны только функции WinSock 1. Разумеется, импортировать функции WinSock 2 самостоятельно не составит труда. Более того, в Интернете можно найти уже готовые модули, импортирующие их (например, на сайте Алекса Коншина http://home.carthlink.net/~akonshin/delphi_ru.htm). Тем не менее, чтобы избежать разночтений, мы не будем использовать какой-либо готовый модуль для импорта и примем следующее соглашение: если прототип функции приведен только на Паскале, значит, эта функция есть в модуле

WinSock

WinSock

stdcall

Примечание

С Delphi поставляется библиотека Indy (Internet Direct), в состав которой входит модуль

IdWinSock2

, импортирующий почти все функции WinSock 2 из системных библиотек. Импорт в нем динамический, над каждой функцией сделана обертка, которая при первом вызове проверяет, была ли уже загружена функция из библиотеки, и при необходимости загружает ее. Чтобы реализовать это, имена всех функций изменены, а вызов идет через процедурные переменные, имена которых совпадают с оригинальными именами соответствующих функций.

WinSock 2 предлагает разработчику Service Provider Interface (SPI), с помощью которого можно добавлять в систему поддержку своих протоколов. Устаревшими объявлены функции, имеющие привязку к конкретным протоколам (например, уже знакомая нам функция

inet_addr

В этом разделе мы познакомимся с теми устаревшими функциями, которые не стоит применять в 32-разрядных программах. Рассмотрим мы их, разумеется, очень обзорно, только для того, чтобы после прочтения книги вас не смущали упоминания этих функций и связанных с ними ошибок, которые иногда встречаются в MSDN.

В 16-разрядных версиях Windows реализована так называемая корпоративная многозадачность: каждая программа время от времени должна добровольно возвращать управление операционной системе, чтобы та могла передать управление другой программе. Если какая-то программа при этом поведет себя некорректно и не вернет управление системе, то все остальные приложения не смогут продолжать работу. Другой недостаток такой модели — в ней невозможно распараллеливание работы в рамках одного процесса, т.е. создание нитей.

При такой модели многозадачности использование блокирующих сокетов может привести к остановке всей системы, если не будут приняты дополнительные меры. В Windows проблема решается следующим образом: библиотека сокетов во время ожидания периодически вызывает заранее указанную функцию. В 16-разрядных версиях Windows эта функция по умолчанию извлекает сообщение из системной очереди и передает его соответствующему приложению. Таким образом, остальные приложения не прекращают работу во время блокирующего вызова.

В очереди могут находиться сообщения и для того приложения, которое выполняет блокирующий вызов. В этом случае будет снова вызвана оконная процедура, инициировавшая блокирующую операцию. Это напоминает рекурсию, при которой процедура вызывает сама себя: в памяти компьютера будут одновременно две активации этой процедуры. Упрощенно это выглядит так: оконная процедура вызывает блокирующую функцию (например, accept), а та, в свою очередь, снова вызывает ту же самую оконную процедуру. При этом вторая активация не может выполнять никаких операций с сокетами: они будут завершены с ошибкой

WSAEINPROGRESS

WSAIsBlocking

True

Вторая активация процедуры может прервать блокирующий вызов с помощью функции

WSACancelBlockingСаll

WSAECANCELLED

Программа может устанавливать свою процедуру, которая будет вызываться во время выполнения блокирующей операции. Для этого предусмотрены функции

WSASetBlockingHook

WSAUnhookBlockingHook

Данная модель неудобна, поэтому разработчики WinSock 1 рекомендуют модель асинхронных сокетов, более приспособленную к особенностям Windows.

В 32-разрядных версиях WinSock такая модель работы поддерживается в полном объеме, за исключением того, что по умолчанию при блокирующем вызове не вызывается никакая функция. Поэтому если не вызове не вызывается никакая функция. Поэтому если не использовать

WSASetBlockingHook

WSAEINPROGRESS

Все перечисленные функции формально исключены из спецификации WinSock 2, хотя фактически они присутствуют в библиотеке WS2_32.dll и при необходимости могут быть задействованы (это, правда, осложняется тем, что в новых версиях MSDN отсутствует их описание). Тем не менее причин ориентироваться на эту неудобную модель в 32-разрядных версиях Windows, видимо, нет. Описание этих функций мы здесь привели только для того, чтобы упоминания об ошибках

WSAEINPROGRESS

WSAECANCELLED

Ранее мы уже видели, что передача данных через сокет осуществляется одними и теми же функциями независимо от протокола. Но при этом программа должна учитывать, является ли протокол потоковым, дейтаграммным или иным. Кроме того, информация о протоколе требуется для создания сокета и для распределения ролей между клиентом и сервером при установлении соединения. Чтобы работать с любым протоколом, программа должна иметь возможность получить всю эту информацию и выполнить на основе ее те или иные действия. Могут также понадобиться такие сведения, как максимальное число сокетов, поддерживаемых провайдером протокола, допустимый диапазон адресов, максимальный размер сообщений для дейтаграммных протоколов и т.д. Для хранения полного описания протокола и его провайдера в WinSock 2 предусмотрена структура

WSAPROTOCOL_INFO

// ***** Описание на C++ *****

typedef struct _WSAPROTOCOLCHAIN {

 int ChainLen;

 DWORD ChainEntries[MAX_PROTOCOL_CHAIN];

} WSAPROTOCOLCHAIN, *LPWSAPROTOCOLCHAIN;

typedef struct _WSAPROTOCOL_INFO {

 DWORD dwServiceFlags1;

 DWORD dwServiceFlags2;

 DWORD dwServiceFlags3;

 DWORD dwServiceFlgs4;

 DWORD dwProviderFlags;

 GUID ProviderId;

 DWORD dwCatalogEntryId;

 WSAPROTOCOLCHAIN ProtocolChain;

 int iVersion;

 int iAddressFamily;

 int iMaxSockAddr;

 int iMinSockAddr;

 int iSocketType;

 int iProtocol;

 int iProtocolMaxOffset;

 int iNetworkByteOrder;

 int iSecurityScheme;

 DWORD dwMessageSize;

 DWORD dwProviderReserved;

 TCHAR szProtocol[WSAPROTOCOL_LEN - 1];

} WSAPROTOCOL_INFO, *LPWSAPROTOCOL_INFO;

// ***** Описание на Delphi *****

TWSAProtocolChain = packed record

 ChainLen: Integer;

 ChainEntries: array[0..MAX_PROTOCOL_CHAIN - 1] of DWORD;

end;

//Структура на C++ содержит тип TCHAR, который, как мы

// говорили в главе 1, может означать как Char,

// так и WideChar, т.е. структура должна иметь

// два варианта описания: TWSAProtocolInfoA для

// однобайтной кодировки и TWSAProtocolInfo для

// двухбайтной. Соответственно, все функции

// использующие эту структуру, реализованы

// в системных библиотеках в двух вариантах.

// Здесь мы приводим только ANSI-вариант.

PWSAProtocolInfo = ^TWSAProtocolInfo;

TWSAProtocolInfo = packed record

 dwServiceFlags1: DWORD;

 dwServiceFlags2: DWORD;

 dwServicsFlags3: DWORD;

 dwServiceFlags4: DWORD;

 dwProviderFlags: DWORD;

 ProviderId: GUID;

 dwCatalogEntryId: DWORD;

 ProtocolChain: TWSAProtocolChain;

 iVersion: Integer;

 iAddressFamily: Integer;

 iMaxSockAddr: Integer;

 iMinSockAddr: Integer;

 iSocketType: Integer;

 iProtocol: Integer;

 iProtocolMaxOffset: Integer;

 iNetworkByteOrder: Integer;

 iSecurityScheme: Integer;

 dwMessageSize: DWORD;

 dwProviderReserved: DWORD;

 szProtocol: array [0..WSAPROTOCOL_LEN] of Char;

end;

Расшифровка полей типа

TWSAProtocolInfo

Сама функция

WSAEnumProtocols

// ***** описание на C++ *****

int WSAEnumProtocols(LPINT lpiProtocols, LPWSAPROTOCOL_INFO lpProtocolBuffer, LPDWORD lpdwBufferLength);

// ***** Описание на Delphi *****

function WSAEnumProtocols(lpiProtocols: PInteger; lpProtocolBuffer: PWSAProtocolInfo; var BufferLength: DWORD): Integer;

Примечание

В старых версиях MSDN в описании этой функции есть небольшая опечатка: тип параметра

lpdwBufferLength

назван

LLPDWORD

вместо

LPDWORD

.

Библиотека WS2_32.dll придерживается тех же правил насчет ANSI- и Unicode-вариантов функций, что и другие системные библиотеки (см. разд. 1.1.12), поэтому в ней нет функции с именем

WSAEnumProtocols

, а есть

WSAEnumProtocolsA

и

WSAEnumProtocolsW

. Эти функции работают с разными вариантами структуры

WSAPROTOCOL_INFO

, которые различаются типом элементов в последнем массиве —

CHAR

или

WCHAR

.

Параметр

lpiProtocols

nil

lpProtocolBuffer

TWSAProtocolInfo

BufferLength

lpProtocolBuffer

Если параметр

lpiProtocols

В системе может быть установлено несколько провайдеров для одного протокола. В этом случае информация о каждом провайдере будет помещена в отдельный элемент массива. Из-за этого число задействованных элементов в массиве

lpProtocolBuffer

lpiProtocols

К сожалению, полную информацию о том, каким протоколам какие номера соответствуют, в документации найти не удалось. Можно только сказать, что для получения информации о протоколе TCP в массив

lpiProtocols

IPPROTO_TCP

IPPROTO_UDP

Возвращаемое функцией значение равно числу протоколов, информация о которых помещена в массив, если функция выполнена успешно, и

SOCKET_ERROR

WSAGetLastError

lpProtocolBuffer

WSAENOBUFS

WinSock 1 содержит аналогичную по возможности функцию

EnumProtocols

PROTOCOL_INFO

WSAPROTOCOL_INFO

EnumProtocols

PROTOCOL_INFO

EnumProtocols

WSAEnumProtocols

В этом разделе мы рассмотрим некоторые новые функции, появившиеся в WinSock 2. Большинство из них позволяет выполнять действия, уже знакомые нам из предыдущих разделов, но предоставляет большие возможности, чем стандартные сокетные функции.

Для создания сокета предназначена функция

WSASocket

// ***** Описание на C++ *****

SOCKET WSASocket(int af, int SockType, int protocol, LPWSAPROTOCOL_INFO lpProtocolInfo, GROUP g, DWORD dwFlags);

// ***** Описание на Delphi *****

function WSASocket(AF, SockType, Protocol: Integer; lpProtocolInfo: PWSAProtocolInfo; g: TGroup; dwFlags: DWORD): TSocket;

Первые три параметра совпадают с тремя параметрами функции

socket

lpProtocolInfo

TWSAProtocolInfo

nil

socket

nil

FROM_PROTOCOL_INFO

g

TGroup 

DWORD

dwFlags

socket

WSASocket

WSA_FLAG_OVERLAPPED

В случае TCP и UDP функция

WSASocket

socket

lpProtocolInfo

WSA_FLAG_OVERLAPPED

WSASocket

Функция

WSAConnect

connect

// ***** Описание на C++ *****

int WSAConnect(SOCKET s, const struct sockaddr FAR* name, int name len, LPWSABUF lpCallerData, LPWSABUF lpCalleeData, LPQOS lpSQOS, LPQOS lpGQOS);

typedef struct __WSABUF {

 u_long len;

 char FAR *buf;

} WSABUF, FAR* LPWSABUF;

// ***** Описание на Delphi ******

function WSAConnect(S: TSocket; var Name: TSockAddr; NameLen: Integer; lpCollerData, lpCalleeData: PWSABuf; lpSQOS, lpGQOS: PQOS): Integer;

PWSABuf = ^TWSABuf;

TWSABuf = packed record

 Len: Cardinal;

 Buf: PChar;

end;

Функция

WSAConnect

lpCallerData

lpCalleeData

TWSABuf

TWSABuf

Len

Buf

lpCallerData 

lpCalleeData

nil

lpSQOS

lpGQOS

lpGQOS

nil

lpSQOS

nil

SQOS

Между функциями

connect

WSAConnect

connect

connect

INADDR_ANY

WSAConnect

Name

sin_family

Name

Если программа не предъявляет требований к качеству обслуживания, то для протоколов TCP и UDP функция

WSAConnect

connect

Функция

accept

WSAAccept

// ***** Описание на C++ *****

SOCKET WSAAccept(SOCKET S, struct sockaddr FAR* addr, LPINT addrlen, LPCONDITIONPROC lpfnCondition, dwCallbackData);

// ***** описание на Delphi *****

function WSAAccept( S: TSocket; Addr: PSockAddr; AddrLen: PInteger; lpfnCondition: TConditionProc; dwCallbackData: DWORD): TSocket;

По сравнению с уже известной нам функцией

accept

WSAAccept

lpfnCondition

dwCallbackData

lpfnCondition

WSAAccept

dwCallbackData

WSAAccept

TConditionProc

// ***** Описание на C++ *****

typedef (int*)(LPWSABUF lpCallerId, LPWSABUF lpCallerData, LPQOS lpSQOS, LPQOS lpGQOS, LPWSABUF lpCalleeId, LPWSABUF lpCalleeData, GROUP FAR* g, DWORD dwCallbackData) LPCONDITIONPROC;

// ***** Описание на Delphi *****

TConditionProc = function(lpCallerId, lpCallerData: PWSABuf; lpSQOS, lpGQOS: PQOS; lpCalleeID, lpCalleeData: PWSABuf; g: PGroup; dwCallbackData: DWORD): Integer; stdcall;

Параметр

lpCallerId

lpCallerId^.Len

SizeOf(TSockAddr)

lpCallerId^.Buf

TSockAddr

lpCallerData

lpSQOS

lpGQOS

lpGQOS

nil

lpSQOS

nil

Параметр

lpCalleeId

lpCallerId

INADDR_ANY

lpCalleeId

lpCalleeData

Параметр

g

WSAAccept

Примечание

Если вы пользуетесь старой версией MSDN, то можете не обнаружить там описания параметра

g

— оно там отсутствует. Видимо, просто по ошибке.

И наконец, через параметр

dwCallbackData

dwCallbackData

WSAAccept

Функция должна вернуть

CF_ACCEPT

CF_REJECT

CF_DEFER

CF_REJECT

WSAAccept

WSAECONNREFUSED

CF_DEFER

WSATRY_AGAIN

WSAAccept

Ранее уже обсуждалось, что функция

connect

accept

WSAAccept

accept

WSAAccept

lpCondition

SO_CONDITIONAL_ACCEPT

var

 Cond: BOOL;

begin

 Cond := True;

 setsockopt(S, SOL_SOCKET, SO_CONDITIONAL_ACCEPT, PChar(@Cond), SizeOf(Cond));

Этот режим снижает нагрузку на сеть и повышает устойчивость сервера против DoS-атак, заключающихся в многократном подключении-отключении посторонних клиентов, поэтому в серьезных серверах рекомендуется использовать эту возможность.

Из сказанного следует, что при использовании протокола TCP функция

WSAAccept

Некоторые протоколы поддерживают передачу информации не только при установлении связи, но и при её завершении. Для таких протоколов в WinSock2 предусмотрены функции

WSASendDisconnect

WSARecvDisconnect

shutdown

Далее мы рассмотрим несколько новых функций, унифицирующих работу с различными протоколами.

Функция

inet_addr

WSAStringToAddress

// ***** Описание на C++ *****

INT WSAStringToAddress(LPTSTR AddressString, INT AddressFamily, LPWSAPROTOCOL_INFO lpProtocolInfo, LPSOCKADDR lpAddress, LPINT lpAddressLength);

// ***** Описание на Delphi *****

function WSAStringToAddress(AddresString: PChar; AddressFamily: Integer; lpProtocolInfo: PWSAProtocolInfo; var Address: TSockAddr; var AddressLength: Integer): Integer;

Данная функция преобразует строку, задающую адрес сокета, в адрес, хранящийся в структуре

TSockAddr

AddressString

AddressFamily

lpProtocolInfo

lpProtocolInfo

nil

Address

AddressLength

Address

Функция возвращает 0 в случае успешного выполнения и

SOCKET_ERROR

Допустимый формат строки определяется протоколом (некоторые протоколы вообще не поддерживают текстовую запись адреса, и для них функция

WSAStringToAddress

AF_INET

Port

Таким образом, чтобы в структуре

TSockAddr

var

 Addr: TSockAddr;

 AddrLen: Integer;

begin

 AddrLen := SizeOf(Addr);

 WSAStringToAddress('192.168.100.217:5000', AF_INET, nil, Addr, AddrLen);

Существует также функция

WSAAddressToString

WSAStringToAddrеss

// ***** Описание на C++ *****

INT WSAAddressToString(LPSOCKADDR lpsaAddress, DWORD dwAddressLength, LWSAPROTOCOL_INFO lpProtocolInfo, LPTSTR lpszAddressString, LPDWORD lpdwAddressStringLength);

// ***** Описание на Delphi *****

function WSAAddressToString(var Address: TSockAddr; dwAddressLength: DWORD; lpProtocolInfo: PWSAProtocolInfo; lpszAddressString: PChar; var AddressStringLength: DWORD): Integer;

Как нетрудно догадаться по названию функции, она преобразует адрес, заданный структурой

TSockAddr

Address

dwAddressLength

Address

lpProtocolInfo

TWSAProtocolInfo

lpszAddressString

AddressStringLength

lpszAddressString

Функция возвращает ноль в случае успеха и

SOCKET_ERROR

htons

ntohs

htonl

ntohl

WSAHtons

WSANtohs

WSAHtonl

WSANtohl

WSANtohl

WSANtohl

// ***** Описание на C++ *****

int WSANtohl(SOCKET s, u_long netlong, u_long FAR *lphostlong);

// ***** Описание на Delphi *****

function WSANtohl(S: TSocket; NetLong: Cardinal; var HostLong: Cardinal): Integer;

Параметр 

S

NetLong

HostLong

Функция возвращает ноль в случае успешного выполнения операции и

SOCKET_ERROR

Если программа работает только с протоколами стека TCP/IP, старые варианты функций удобнее новых, потому что возвращают непосредственно результат преобразования, который можно использовать в выражениях. При работе с новыми функциями для получения результата следует заводить отдельную переменную, поэтому эти функции целесообразны тогда, когда программа должна единым образом работать с разными протоколами. Последняя функция, которую мы здесь рассмотрим, не имеет прямых аналогов среди старых функций. Называется она

WSADuplicateSocket

WSADuplicateSocket

// ***** Описание на C++ *****

int WSADuplicateSocket(SOCKET s, DWORD dwProcessId, LPWSAPROTOCOL_INFO lpProtocolInfo);

// ***** Описание на Delphi *****

function WSADuplicateSocket(S: TSocket; dwProcessID: DWORD; var ProtocolInfo: TWSAProtocolInfo): Integer;

Параметр 

S

dwProcessID

ProtocolInfo

WSASocket

Функция

WSADuplicateSocket

SOCKET_ERROR

WSADuplicateSocket

closesocket

Отметим, что функция

WSADuplicateSocket

Все операции с сокетами, которые мы рассматривали раньше, являлись синхронными. Программа, использующая такие сокеты, должна сама время от времени проверять тем или иным способом, пришли ли данные, установлена ли связь и т.п. Асинхронные сокеты позволяют программе получать уведомления о событиях, происходящих с сокетом: поступлении данных, освобождении места в буфере, закрытии и т.п. Такой способ работы лучше подходит для событийно-ориентированных программ, типичных для Windows. Поддержка асинхронных сокетов впервые появилась в WinSock 1 и была основана на сообщениях, которые обрабатывались оконными процедурами. В WinSock 2 этот асинхронный режим остался без изменений. Программист указывает, какое сообщение какому окну должно приходить при возникновении события на интересующем его сокете.

Асинхронный режим с уведомлением через сообщения устанавливается функцией

WSAAsyncSelect

function WSAAsyncSelect(S: TSocket; HWindow: HWND; wMsg: u_int; lEvent: LongInt): Integer;

Параметр

S

HWindow

wMsg

lEvent

Таблица 2.2. Асинхронные события сокета

Каждый последующий вызов

WSAAsyncSelect

WSAAsyncSelect(S, Form1.Handle, WM_USER, FD_WRITE);

// Второй вызов отменит результаты первого

WSAAsyncSelect(S, Form1.Handle, WM_USER, FD_READ);

// Теперь окно не будет получать уведомления о возможности записи

WSAAsyncSelect

WSADuplicateSocket

WSAAsyncSelect

WSAAsyncSelect

Для того, чтобы получать сообщения при готовности сокета как к чтению, так и к записи, нужно выполнить следующий код.

WSAAsyncSelect(S, Form1.Handle, WM_USER, FD_READ or FD_WRITE);

При необходимости с помощью

or

Из сказанного следует, что нельзя связать с разными событиями одного и того же сокета разные сообщения (или отправлять сообщения разным окнам), т.к. при одном вызове

WSAAsyncSelect

WSAAsyncSelect

WSAAsyncSelect

Сообщение, которое связывается с асинхронным сокетом, может быть любым. Обычно его номер выбирают от

WM_USER

При получении сообщения его параметр

wParam

lParam

FD_XXX

lParam

WSAGETSELECTEVENT

WSAGETSELECTERROR

WSAGetSelectEvent

WSAGetSelectError

Сокет, созданный при вызове функции

accept

accept

Рассмотрим подробнее каждое из перечисленных событий.

Событие

FD_READ

WSAAsyncSelect

FD_READ

recv

recvfrom

WSARecv

WSARecvFrom

recv

Если после вызова

recv

FD_READ

recv

FD_READ

Описанная схема, в принципе, достаточно удобна, но следует учитывать, что в некоторых случаях она может давать ложные срабатывания, т.е. при обработке сообщения о событии

FD_READ

recv

WSAEWOULDBLOCK

FD_READ

FD_READ

FD_READ

Другой вариант ложного срабатывания возможен, если программа при обработке

FD_READ

recv

FD_READ

WSAAsyncSelect

FD_READ

И наконец, следует помнить, что сообщение о событии 

FD_READ

WSAAsyncSelect

WSAAsyncSelect

FD_READ

Событие

FD_WRITE

При использовании TCP первый раз сообщение, уведомляющее о событии

FD_WRITE

connect

accept

bind

WSAAsyncSelect

FD_WRITE

В следующий раз событие может возникнуть только в том случае, если функция

send

sendto

WSAEWOULBBLOCK

FD_WRITE

FD_WRITE

Событие

FD_ACCEPT

FD_READ

FD_ACCEPT

FD_ACCEPT

accept

WSAAccept

Событие

FD_CONNECT

connect

accept

connect

FD_CONNECT

lParam

Событие

FD_CLOSE

shutdown

FD_CLOSE

SD_SEND

FD_CLOSE

shutdown

Рекомендуемая последовательность действий при завершении связи такова. Сначала клиент завершает отправку данных через сокет, вызывая функцию

shutdown

SD_SEND

FD_CLOSE

FD_READ

shutdown

SD_SEND

FD_CLOSE

closesocket

shutdown

closesocket

WM_SOCKETEVENT

unit Unit1;

interface

uses

 Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, WinSock;

const

 WM_SOCKETEVENT = WM_USER + 1;

type

 TForm1 = class(TForm)

  procedure FormCreate(Sender: TObject);

  procedure FormDestroy(Sender: TObjеct);

 private

  ServSock: TSocket;

  procedure WMSocketEvent(var Msg: TMessage); message WM_SOCKETEVENT;

 end;

var

 Form1: TForm1;

implementation

{$R *.DFM}

procedure TForm1.FormCreate(Sender: TObject);

var

 Data: TWSAData;

 Addr: TSockAddr;

begin

 WSAStartup($101, Data);

 // Обычная последовательность действий по созданию сокета,

 // привязке его к адресу и установлению на прослушивание

 ServSock := socket(AF_INET, SOCK_STREAM, 0);

 Addr.sin_family := AF_INET;

 Addr.sin_addr.S_addr := INADDR_ANY;

 Addr.sin_port := htons(3320);

 FillChar(Addr.sin_zero, SizeOf(Addr.sin_zero), 0);

 bind(ServSock, Addr, SizeOf(Addr));

 listen(ServSock, SOMAXCONN);

 // Перевод сокета в асинхронный режим. Кроме события FD_ACCEPT

 // указаны также события FD_READ и FD_CLOSE, которые никогда не

 // возникают на сокете, установленном в режим прослушивания.

 // Это сделано потому, что сокеты, созданные с помощью функции

 // accept, наследуют асинхронный режим, установленный для

 // слушающего сокета. Таким образом, не придется вызывать

 // функцию WSAAsyncSelect для этих сокетов - для них сразу

 // будет назначен обработчик событий FD_READ и FD_CLOSE.

 WSAAsyncSelect(ServSock, Handle, WM_SOCKETEVENT, FD_READ or FD_ACCEPT or FD_CLOSE);

end;

procedure TForm1.FormDestroy(Sender: TObject);

begin

 closesocket(ServSock);

 WSACleanup;

end;

procedure TForm1.WMSocketEvent(var Msg: TMessage);

var

 Sock: TSocket;

 SockError: Integer;

begin

 Sock := TSocket(Msg.WParam);

 SockError := WSAGetSelectError(Msg.lParam);

 if SockError <> 0 then

 begin

  // Здесь должен быть анализ ошибки

  closesocket(Sock);

  Exit;

 end;

 case WSAGetSelectEvent(Msg.lParam) of

 FD_READ: begin

  // Пришел запрос от клиента. Необходимо прочитать данные,

  // сформировать ответ и отправить его.

 end;

 FD_АССЕРТ: begin

  // Просто вызываем функция accept. Ее результат нигде не

  // сохраняется, потому что вновь созданный сокет автоматически

  // начинает работать в асинхронном режиме, и его дескриптор

  // при необходимости будет передан через Msg.wParam при

  // возникновение события

  accept(Sock, nil, nil);

 end;

 FD_CLOSE:

 begin

  // Получив от клиента сигнал завершения, сервер, в принципе,

  // может попытаться отправить ему данные. После этого сервер

  // также должен закрыть соединение со своей стороны

  shutdown(Sock, SD_SEND);

  closesocket(Sock);

 end;

 end;

end;

end.

Преимущество такого сервера по сравнению с сервером, основанным на функции

select

TFDSet

В этом разделе мы напишем сервер, использующий асинхронные сокеты и их сообщения (пример AsyncSelectServer на компакт-диске). Этот сервер будет во многом похож на сервер на основе неблокирующих сокетов (см. разд. 2.1.16), только он не станет проверять по таймеру наличие данных в буфере и возможность отправки данных, а будет выполнять это тогда, когда поступят соответствующие сообщения.

Такая схема работы требует более осторожного подхода. По сигналу от таймера мы сами проверяем, на каком этапе в данный момент находится обмен данными с клиентом. Если, например, идет этап отправки данных, то проверять входной буфер сокета не нужно, можно оставить это до тех пор, пока не наступит этап чтения данных. При использовании сообщений приходится учитывать, что сообщение о поступлении данных в буфер сокета может прийти в любой момент, в том числе и тогда, когда обмен с клиентом находится на этапе отправки строки. По протоколу сервер не должен читать сообщение в этот момент, необходимо сначала закончить отправку, поэтому приходится данное уведомление игнорировать. Но второго уведомления система не пришлет, соответственно, после окончания отправки данных сервер должен сам вспомнить, что было уведомление, и перейти к операции чтения.

Примечание

Вообще говоря, ситуация, когда сервер не отправит данные за один раз, и их отправка растянется на несколько итераций петли сообщений, настолько редка, что при разработке сервера, к которому не предъявляются повышенные требования по надежности, ее можно было бы вообще не учитывать. Соответственно, возможность получения сервером нового уведомления о поступлении данных до того, как на старое сообщение будет дан ответ, возможна только тогда, когда клиент не соблюдает принятый протокол и посылает несколько сообщений подряд, не дожидаясь ответа. Наш пример призван продемонстрировать наиболее надежный к подобным действиям клиента сервер, поэтому мы его напишем "по всем правилам".

Как обычно, работа сервера начинается с инициализации слушающего сокета, выполняющейся при нажатии кнопки Запустить (листинг 2.50).

procedure TServerForm.BtnStartServerClick(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 := 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('Ошибка при привязке сокета к адресу:'#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;

  // Связь слушающего сокета с событием FD_ACCEPT

  if WSAAsyncSelect(FServerSocket, Handle,

WM_ACCEPTMESSAGE, FD_ACCEPT) = SOCKET_ERROR then

  begin

   MessageDlg('Ошибка при установке асинхронного режима ' +

    'cлушающего сокета:'#13#10 + GetErrorString, mtError, [mbOK], 0);

   closesocket(FServerSocket);

   Exit;

  end;

  // Перевод элементов управления в состояние "Сервер работает"

  LabelPortNumber.Enabled := False;

  EditPortNumber.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;

Этот код мало чем отличается от того, что мы уже видели (сравните, например, с листингами 2.19 и 2.30). Единственное существенное отличие здесь — вызов функции

WSAAsyncSelect

FD_ACCEPT

WM_ACCEPTMESSAGE

Сообщение

WM_ACCEPTMESSAGE

WM_SOCKETMESSAGE

TWMSocketMessage

TMessage

const

 WM_ACCEPTMESSAGE = WM_USER + 1;

 WM_SOCKETMESSAGE = WM_USER + 2;

type

 TWMSocketMessage = packed record

  Msg: Cardinal;

  Socket: TSocket;

  SockEvent: Word;

  SockError: Word;

 end;

Прежде чем реализовывать реакцию на эти сообщения, нужно позаботиться об обработке ошибок. Функция

GetErrorString

WSAGetLastError

SockError

GetErrorString

// функция GetErrorString возвращает сообщение об ошибке,

// сформированное системой на основе значения, которое

// передано в качестве параметра. Если это значение

// равно нулю (по умолчанию), функция сама определяет

// код ошибки, используя функцию WSAGetLastError.

// Для получения сообщения используется системная функция

// FormatMessage.

function GetErrorString(Error: Integer = 0): string;

var

 Buffer: array[0..2047] of Char;

begin

 if Error = 0 then Error := WSAGetLastError;

 FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, nil, Error, $400,

  @Buffer, SizeOf(Buffer), nil);

 Result := Buffer;

end;

Сам обработчик сообщения

WM_ACCEPTMESSAGE

procedure TServerForm.WMAcceptMessage(var Msg: TWMSocketMessage);

var

 NewConnection: PConnection;

 // Сокет, который создаётся для вновь подключившегося клиента

 ClientSocket: TSocket;

 // Адрес подключившегося клиента

 ClientAddr: TSockAddr;

 // Длина адреса

 AddrLen: Integer;

begin

 // Страхуемся от "тупой" ошибки

 if Msg.Socket <> FServerSocket then

  raise ESocketError.Create(

  'Внутренняя ошибка сервера - неверный серверный сокeт');

 // Обрабатываем ошибку на сокете, если она есть.

 if Msg.SockError <> 0 then

 begin

  MessageDlg('Ошибка при подключении клиента:'#13#10 +

   GetErrorString(Msg.SockError) +

   #13#10'Сервер будет остановлен', mtError, [mbOK], 0);

  ClearConnections;

  closesocket(FServerSocket);

  OnStopServer;

  Exit;

 end;

 // Страхуемся от еще одной "тупой" ошибки

 if Msg.SockEvent <> FD_ACCEPT then

  raise ESocketError.Create(

   'Внутренняя ошибка сервера — неверное событие на сокете');

 AddrLen := SizeOf(TSockAddr);

 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

  // связываем сообщение с новым сокетом

  if WSAAsyncSelect(ClientSocket, Handle, WM_SOCKETMESSAGE,

   FD_READ or FD_WRITE or FD_CLOSE) = SOCKET_ERROR then

  begin

   MessageDlg('Ошибка при установке асинхронного режима ' +

    'подключившегося сокета:'#13#10 +

    GetErrorString, mtError, [mbOK], 0);

   closesocket(ClientSocket);

   Exit;

  end;

  // Создаем запись для нового подключения и заполняем ее

  New(NewConnection);

  NewConnection.ClientSocket := ClientSocket;

  NewConnection.ClientAddr := 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);

  NewConnection.SendRead := False;

  // Добавляем запись нового соединения в список

  FConnections.Add(NewConnection);

  AddMessageToLog('Зафиксировано подключение с адреса ' +

   NewConnection.ClientAddr);

 end;

end;

Для каждого подключившегося клиента создается запись типа

TConnection

FConnections

TConnection

SendRead

True

FD_READ

Каждый сокет, созданный функцией

accept

WM_SOCKETMESSAGE

// Метод GetConnectionBySocket находит в списке FConnections

// запись, соответствующую данному сокету

function TServerForm.GetConnectionBySocket(S: TSocket): PConnection;

var

 I: Integer;

begin

 for I := 0 to FConnections.Count - 1 do

  if PConnection(FConnections[I]).ClientSocket = S then

  begin

   Result := FConnections[I];

   Exit;

  end;

 Result := nil;

end;

procedure TServerForm.WMSocketMessage(var Msg: TWMSocketMessage);

var

 Connection: PConnection;

 Res: Integer;

 // Вспомогательная процедура, освобождающая ресурсы, связанные

 // с клиентом и удаляющая запись подключения из списка

 procedure RemoveConnection;

 begin

  closesocket(Connection.ClientSocket);

  FConnections.Remove(Connection);

  Dispose(Connection);

 end;

begin

 // Ищем соединение по сокету

 Connection := GetConnectionBySocket(Msg.Socket);

 if Connection = nil then

 begin

  AddMessageToLog(

   'Внутренняя ошибка сервера — не найдено соединение для сокета');

  Exit;

 end;

 // Проверяем, были ли ошибки при взаимодействии

 if Msg.SockError <> 0 then

 begin

  AddMessageToLog('Ошибка при взаимодействии с клиентом ' +

   Connection.ClientAddr + ': ' + GetErrorString(Msg.SockError));

  RemoveConnection;

  Exit;

 end;

 // Анализируем, какое событие произошло

 case Msg.SockEvent of

 FD_READ: begin

  // Проверяем, на каком этапе находится взаимодействие с клиентом.

  if Connection.Phase = tpReceiveLength then

  begin

   // Этап получения от клиента длины строки. При выполнении этого

   // этапа сервер получает от клиента длину строки и размещает ее

   // в поле Connection.MsgSize. Здесь приходится учитывать, что

   // теоретически даже такая маленькая (4 байта) посылка может

   // быть разбита на несколько пакетов, поэтому за один раз этот

   // этап не будет завершен, и второй раз его придется

   // продолжать, загружая оставшиеся байты. Connection.Offset -

   // количество уже прочитанных на данном этапе байтов -

   // одновременно является смещением, начиная с которого

   // заполняется буфер.

   Res := recv(Connection.ClientSocket,

    (PChar((PConnection.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

   elsе if Res = 0 then

   begin

    AddMessageToLog('Клиент ' + Connection.ClientAddr +

     ' закрыл соединение');

    RemoveConnection;

    Exit;

   end

   else

    // Ошибку WSAEWOULDBLOCK игнорируем, т.к. она говорит

    // только о том, что входной буфер сокета пуст, но в целом

    // все в порядке - такое вполне возможно при ложных

    // срабатываниях сообщения

    if WSAGetLastError <> WSAEWOULDBLOCK then

    begin

     AddMessageToLog('Ошибка при получении данных от клиента ' +

      Connection.ClientAddr + ': ' + GetErrorString);

     RemoveConnection;

     Exit;

    end;

  end

  else if Connection.Phase = tpReceiveString then

  begin