2.1. Стандартные сокеты

Книга: О чём не пишут в книгах по Delphi

Назад: Глава 2 Использование сокетов Delphi

Дальше: 2.1.13. Определение готовности сокета

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

2.1.1 Соглашения об именах

Первые библиотеки сокетов писались на языке С. В этом языке идентификаторы чувствительны к регистру символов, т.е., например, SOCKET, Socket и socket — разные идентификаторы. Исторически сложилось, что имена встроенных в C типов данных пишутся в нижнем регистре, имена определенных в программе типов, макроопределений и констант — в верхнем, а имена функций — в смешанном (прописные буквы выделяют начала слов, например, GetWindowText). Разработчики библиотеки сокетов несколько отошли от этих правил: имена всех стандартных сокетных функций пишутся в нижнем регистре. И хотя мы и программируем на Паскале, нечувствительном к регистру символов, все же будем придерживаться этой традиции, пусть это не удобно, зато не будет расхождений с другими источниками.

Чувствительность С к регистру символов создаст некоторые проблемы при переноce библиотек, написанных на этом языке, в Delphi. Это связано с тем, что разные объекты могут иметь имена, различающиеся только регистром символов, в частности, есть тип SOCKET и функция socket. Сохранить эти имена в Delphi невозможно. Чтобы избежать этой проблемы, разработчики Delphi при переносе библиотек к имени типа добавляют букву "Т", причем независимо от того, существуют ли у этого типа одноименные функции или нет. Так, типу SOCKET из С в Delphi соответствует TSocket. Имена функций остаются без изменений.

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

В простейшем случае макросы используются для определения констант. Например, директива #define SOMECONST 10 вынуждает препроцессор заменять SOMECONST на 10. Для компилятора эта директива ничего не значит, идентификатора SOMECONST для него не существует. Он получит уже измененный препроцессором текст, в котором вместо SOMECONST будет 10. Допускается также создавать параметризованные макросы, которые изменяют текст программы по более сложным правилам.

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

2.1.2. Общие сведения о сокетах

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

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

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

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

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

Библиотека сокетов разрабатывалась для ОС Unix в которой традиционно высоко ценилась переносимость между платформами, поэтому она содержит функции, позволяющие не задумываться о порядке байтов в числах: ntohs, ntohl, htons и htonl. Первая буква в названии этих функций показывает, в каком формате дано исходное число (n — Network — сетевом формат, h — Host — формат платформы), четвертая буква — формат результата, последняя буква — разрядность (s — Short — двухбайтное число, l — Long — четырёхбайтное число). Например, функция htons принимает в качестве параметра число типа u_short (Word) в формате платформы и возвращает то же число в сетевом формате. Реализация этих функций для каждой платформы своя: где-то они переставляют байты, где-то они возвращают в точности то число, которое было им передано. Благодаря этим функциям программы становятся переносимыми. Хотя для программиста на Delphi вопросы переносимости не столь актуальны, приходится прибегать к этим функциям хотя бы потому, что байты переставлять нужно, а никакого более удобного способа для этого не существует.

2.1.3. Сетевые протоколы. Семиуровневая модель OSI

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

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

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

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

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

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

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

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

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

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

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

2.1.4. Стек TCP/IP

Физический и канальный уровни полностью реализуются сетевой картой или модемом (или другим устройством, выполняющим ту же функцию) и ее драйвером. Здесь действительно достигнута настолько полная абстракция, что программист обычно не задумывается о том, какая используется сеть. Поэтому мы также не будем останавливаться на этих двух уровнях. В реальной жизни не все протоколы, особенно старые, соответствуют модели 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. И без описания этого протокола организовать обмен данными с программой невозможно.

2.1.5. Протокол 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), устанавливается равным нулю, поэтому такие пакеты не выходят за пределы подсети.

2.1.6. Протокол TCP

Протокол 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, т.е. это может повлиять и на другие программы. Поэтому желательно не допускать таких ситуаций, когда у принимающей стороны в буфере накапливается много данных.

2.1.7. Сетевые экраны

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

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

Примечание

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

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

2.1.8. Создание сокета

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

Хотя ранее мы договорились, что будем обсуждать только стандартные сокеты, тем не менее, есть три функции, относящиеся к сокетам Windows, не познакомившись с которыми мы не сможем двигаться дальше. Это функции WSAStartup, WSACleanup и WSAGetLastError (префикс WSA означает Windows Sockets API и служит для именования большинства функций, относящихся к Windows-расширению библиотеки сокетов).

Функция WSAStartup предназначена для инициализации библиотеки сокетов. Эту функцию необходимо вызвать до вызова любой другой функции из этой библиотеки. Ее прототип имеет вид:

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

Параметр wVersionRequired задает требуемую версию библиотеки сокетов. Младший байт задает основную версию, старший — дополнительную. Допустимы версии 1.0 ($0001), 1.1 ($0101), 2.0 ($0002) и 2.2 ($0202). Пока мы работаем со стандартными сокетами, принципиальной разницы между этими версиями нет, но версии 2.0 и выше пока лучше не использовать, т.к. модуль WinSock не рассчитан на их поддержку. Вопросы взаимоотношения библиотек и версий будут рассматриваться во втором разделе этой главы, а пока ограничимся версией 1.1.

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

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

Функция WSACleanup завершает работу с библиотекой сокетов. Эта функция не имеет параметров и возвращает ноль в случае успешного завершения или код ошибки в противном случае. Функцию WSAStartup достаточно вызвать один раз, даже в многонитевом приложении, в этом ее отличие от таких функций, как, например, CoInitialize, которая должна быть вызвана в каждой нити, использующей COM. Функцию можно вызывать повторно — в этом случае ее вызов не дает никакого эффекта, но для завершения работы с библиотекой сокетов функция WSACleanup должна быть вызвана столько же раз, сколько была вызвана WSAStartup.

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

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

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

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

Параметр аf задаёт семейство адресов (address family). Этот параметр определяет, какой способ адресации (т.е. по сути дела, какой стек протоколов) будет использоваться для данного сокета. Для TCP/IP этот параметр должен быть равен AF_INET, для других стеков также есть соответствующие константы, которые можно посмотреть в файле WinSock.pas.

Параметр struct указывает тип сокета и может принимать одно из двух значений: SOCK_STREAM (для потоковых протоколов) и SOCK_DGRAM (для дейтаграммных протоколов).

Параметр protocol позволяет указать, какой именно протокол будет использоваться сокетом. Этот параметр можно оставить равным нулю — тогда будет выбран протокол по умолчанию, отвечающий условиям, заданным первыми двумя параметрами. Для стека TCP/IP потоковый протокол по умолчанию — TCP, дейтаграммный — UDP. В некоторых примерах можно увидеть значение третьего параметра равно IPPROTO_IP. Значение этой константы равно 0, и ее использование только повышает читабельность кода, но приводит к тому же результату: будет выбран протокол по умолчанию. Если требуется протокол, отличный от протокола по умолчанию (например, в некоторых реализациях стека TCP/IP существует протокол RDP — Reliable Datagram Protocol, надежный дейтаграммный протокол), следует указать здесь соответствующую константу (для RDP это будет IPPROTO_RDP). Можно также явно задать TCP или UDP с помощью констант IPPROTO_TCP и IPPROTO_UDP соответственно.

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

Сокет, созданный с помощью функции socket, не привязан ни к какому адресу. Привязка осуществляется с помощью функции bind, имеющей следующий прототип:

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

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

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

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

Видно, что второй параметр — это указатель на структуру sockaddr. Однако C/C++ позволяет при вызове функции в качестве параметра передать указатель на любую другую структуру, если будет выполнено явное приведение типов. Для каждого семейства адресов предусмотрена своя структура, и в качестве фактического параметра передастся указатель на эту структурy. Если бы авторы модуля WinSock описали второй параметр как параметр-значение типа указатель, можно было бы поступать точно так же. Однако они описали этот параметр как параметр-переменную. В результате на двоичном уровне ничего не изменилось: и там, и там в стек помещается указатель. Однако компилятор при вызове функции bind не допустит использования никакой другой структуры, кроме TSockAddr, а эта структура не универсальна и удобна, по сути дела, только при использовании стека TCP/IP. В других случаях наилучшим решением будет самостоятельно импортировать функцию bind из wsock32.dll с нужным прототипом. При этом придется импортировать и некоторые другие функции, работающие с адресами. Впрочем мы здесь ограничиваемся только протоколами TCP и UDP, поэтому больше останавливаться на этом вопросе не будем.

Примечание

На самом деле существует способ передать в функцию bind с таким прототипом параметр addr любого типа, совместимого с этой функцией. Если A — некая переменная типа, отличающегося от TSockAddr, то передать в качестве параметра-переменной ее можно так: PSockAddr(@А)^. Однако подобные низкоуровневые операции программу не украшают.

В стандартной библиотеке сокетов (т.е. в заголовочных файлах для этой библиотеки) полагается, что адрес кодируется структурой sockaddr длиной 16 байтов, причем первые два байта этой структуры кодируют семейство протоколов, а смысл остальных зависит от этого семейства. В частности, для стека TCP/IP семейство протоколов задается константой PF_INET. (Ранее мы уже встречались с термином "семейство адресов" и константой AF_INET. В ранних версиях библиотеки сокетов семейства протоколов и семейства адресов были разными понятиями, но затем эти понятия слились в одно, и константы AF_XXX и PF_XXX стали взаимозаменяемыми). Остальные 14 байтов структуры sockaddr занимает массив типа char (напомним, что тип char в C/C++ соответствует одновременно двум типам Delphi: Char и ShortInt). В принципе, в стандартной библиотеке сокетов предполагается, что структура, задающая адрес, всегда имеет длину 16 байтов, но на всякий случай предусмотрен третий параметр функции bind, который хранит длину структуры. В сокетах Windows длина структуры может быть любой (это зависит от протокола), так что этот параметр, в принципе, может пригодиться.

Ранее уже упоминалось, что неструктурированное представление адреса в виде массива из 14 байтов бывает неудобно, и поэтому для каждого семейства протоколов предусмотрена своя структура, учитывающая особенности адреса. В частности, для протоколов стека TCP/IP используется структура sockaddr_in, размер которой также составляет 16 байтов. Из них задействовано только восемь: два для кодирования семейства протоколов, четыре для IP-адреса и два — для порта. Оставшиеся 8 байтов должны содержать нули.

Можно было бы предположить, что типы TSockAddr и TSockAddrIn, описанные в модуле WinSock, соответствуют структурам sockaddr и sockaddr_in, однако это не так. На самом деле эти типы описаны следующим образом (листинг 2.1).

Листинг 2.1. Типы TSockAddr и TSockAddrIn

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 является вариантной записью, и в случае 0 соответствует типу sockaddr_in из стандартной библиотеки сокетов, а в случае 1 — sockaddr из этой же библиотеки. Вот такая несколько запутанная ситуация, хотя на практике все выглядит не так страшно.

Примечание

Из названия типов можно сделать вывод, что тип u_short — это Word, а u_long — Cardinal. На самом деле u_short — это действительно Word, а вот u_long — это LongInt. Сложно сказать почему выбран знаковый тип там, где предполагается беззнаковый. Видимо, это осталось в наследство от старых версий Delphi, которые не поддерживали тип Cardinal в полном объеме. Кстати, тип u_char — это Char, а не Byte.

Перейдем, наконец, к более практически важному вопросу: какими значениями следует заполнять переменную типа TSockAddr, чтобы при передаче ее в функцию bind сокет был привязан к нужному адресу. Так как мы ограничиваемся рассмотрением протоколов TCP и UDP, нас не интересует та часть вариантной записи sockaddr_in, которая соответствует случаю 1, т.е. мы будем рассматривать только те поля этой структуры, которые имеют префикс sin.

Поле sin_zero, очевидно, должно содержать массив нулей. Это то самое поле, которое не несет никакой смысловой нагрузки и служит только для увеличения размера структуры до стандартных 16 байтов. Поле sin_family, должно иметь значение PF_INET. В поле sin_port записывается номер порта, к которому привязывается сокет. Номер порта должен быть записан в сетевом формате, т.е. здесь необходимо прибегать к функции htons, чтобы из привычной нам записи номера порта получить число в требуемом формате. Номер порта можно оставить нулевым, тогда система выберет для сокета свободный порт с номером от 1024 до 5000.

IP-адрес для привязки сокета задается полем sin_addr, которое имеет тип TInAddr. Этот тип сам является вариантной записью, которая отражает три способа задания IP-адреса: в виде 32-битного числа, в виде двух 16-битных чисел или в виде четырех 8-битных чисел. На практике чаще всего встречается формат в виде четырех 8-битных чисел, реже — в виде 32-битного числа. Задание адресов в виде двух 16-битных чисел или двух 8-битных и одного 16-битного числа относится к очень редко встречающейся экзотике.

Пусть у нас есть переменная Addr типа TSockAddr, и нам требуется ее поле sin_addr записать адрес 192.168.200.217. Это можно сделать так, как показано в листинге 2.2.

Листинг 2.2. Прямое присваивание IP-адреса

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. Эта функция в качестве входного параметра принимает строку, в которой записан IP-адрес, и возвращает этот IP-адрес в формате 32-битного числа. С использованием функции inet_addr приведенный в листинге 2.2 код можно переписать так:

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

Функция inet_addr выполняет простой парсинг строки и не проверяет, существует ли такой адрес на самом деле. Поля адреса можно задавать в десятичном, восьмеричном и шестнадцатеричном форматах. Восьмеричное поле должно начинаться с нуля, шестнадцатеричное — с "0x". Приведенный адрес можно записать в виде "0300.0250.0310.0331" (восьмеричный) или "0xC0.0xA8.0xC8.0xD9" (шестнадцатеричный). Допускается также смешанный формат записи, в котором разные поля заданы в разных системах исчисления. Функция inet_addr поддерживает также менее распространенные форматы записи IP-адреса в виде трех полей. Подробнее об этом можно прочитать в MSDN.

Примечание

Если строка, переданная функции 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. Если IP-адрес компьютеру не назначен, то при использовании этой константы сокет будет привязан к локальному адресу 127.0.0.1. Если компьютеру назначен один IP-адрес, сокет будет привязан к этому адресу. Если компьютеру назначено несколько IP-адресов, то будет выбран один из них, причем сама привязка при этом отложится до установления соединения (в случае TCP) или до первой отправки данных через сокет (в случае UDP). Выбор конкретного адреса при этом зависит от того, какой адрес имеет удалённая сторона.

Итак, резюмируем все сказанное. Пусть у нас есть сокет S, который нужно привязать, например, к адресу 192.168.200.217 и порту 3320. Для этого следует выполнить код листинга 2.3.

Листинг 2.3. Привязка сокета к конкретному адресу

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. Для этой же цели пригодна функция Windows API ZeroMemory. В примерах на С/C++ обычно используется функция memset.

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

Листинг 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, а позже, когда системе станет понятно, зачем используется этот сокет. Например, когда TCP-клиент осуществляет подключение к серверу, система по адресу этого сервера определяет, через какую карту должен идти обмен, и выбирает соответствующий адрес. То же самое происходит с UDP-клиентом: когда он отправляет первую дейтаграмму, система по адресу получателя определяет, к какой карте следует привязать сокет. Поэтому клиент и в данном случае может оставить выбор адреса на усмотрение системы. С серверами все несколько сложнее. Система привязывает сокет UDP-сервера к адресу, он ожидает получения пакета. В этот момент система не имеет никакой информации о том, с какими узлами будет вестись обмен через данный сокет, и может выбрать не тот адрес, который нужен. Поэтому сокеты UDP-серверов, работающих в подобных системах, должны явно привязываться к требуемому адресу. Сокеты TCP-серверов, находящиеся в режиме ожидания и имеющие адрес INADDR_ANY, допускают подключение к ним по любому сетевому интерфейсу, который имеется в системе. Сокет, который создается таким сервером при подключении клиента, будет автоматически привязан к IP-адресу того сетевого интерфейса, через который осуществляется взаимодействие с подключившимся клиентом. Таким образом, сокеты, созданные для взаимодействия с разными клиентами, могут оказаться привязанными к разным адресам.

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

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

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

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

Параметр s определяет сокет, который необходимо выключить, параметр how может принимать значения SD_RECEIVE, SD_SEND или SD_BOTH. Функция возвращает ноль при успешном выполнении и SOCKET_ERROR — в случае ошибки. Вызов функции с параметром SD_RECEIVE запрещает чтение данных из входного буфера сокета. Однако на у ровне протокола вызов этой функции игнорируется: дейтаграммы UDP и пакеты TCP, посланные данному сокету, продолжают помещаться в буфер, хотя программа уже не может их оттуда забрать.

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

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

Примечание

Модуль WinSock до пятой версии Delphi включительно содержит ошибку: в нем не определены константы SD_XXX. Чтобы использовать их в своей программе, нужно объявить их так, как показано в листинге 2.5.

Листинг 2.5. Объявление констант SD_XXX для Delphi 5 и более ранних версий

const

SD_RECEIVE = 0;

SD_SEND = 1;

SD_BOTH = 2;

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

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

Функция shutdown нужна в первую очередь для того, чтобы заранее сообщить партнеру по связи о намерении завершить связь, причем это имеет смысл только для протоколов, поддерживающих соединение. В случае UDP функцию shutdown вызывать практически бессмысленно, можно сразу вызывать closesocket. При использовании TCP удаленная сторона получает сигнал о выключении партнера, но стандартная библиотека сокетов не позволяет программе обнаружить его получение (такие функции есть в сокетах Windows, о чем мы будем говорить далее). Но этот сигнал может быть важен для внутрисистемных функций, реализующих сокеты. Windows-версия библиотеки сокетов относится к отсутствию данного сигнала достаточно либерально, поэтому вызов shutdown в том случае, когда и клиент, и сервер работают под управлением Windows, не обязателен. Но реализации TCP в других системах не всегда столь же снисходительно относятся к подобной небрежности. Результатом может стать долгое (до двух часов) "подвешенное" состояние сокета в той системе, когда с ним и работать уже нельзя, и информации об ошибке программа не получает. Поэтому в случае TCP лучше не пренебрегать вызовом shutdown, чтобы сокет на другой стороне не имел проблем.

MSDN рекомендует следующий порядок закрытия TCP-сокета. Во-первых, сервер не должен закрывать свой сокет по собственной инициативе, он может это делать только после того, как был закрыт связанный с ним клиентский сокет. Клиент начинает закрытие сокета с вызова shutdown с параметром SD_SEND. Сервер после этого сначала получает все данные, которые оставались в буфере сокета клиента, а затем получает от клиента сигнал о завершении передачи. Тем не менее сокет клиента продолжает работать на прием, поэтому сервер при необходимости может на этом этапе послать клиенту какие-либо данные, если это необходимо. Затем сервер вызывает shutdown с параметром SD_SEND, и сразу после этого — closesocket. Клиент продолжает читать данные из входящего буфера сокета до тех пор, пока не будет получен сигнал о завершении передачи сервером. После этого клиент также вызывает closesocket. Такая последовательность гарантирует, что данные не будут потеряны, но, как мы уже обсуждали ранее, она не может быть реализована в рамках стандартных сокетов из-за невозможности получить сигнал о завершении передачи, посланный удаленной стороной. Поэтому на практике следует реализовывать упрощенный способ завершения связи: клиент вызывает shutdown с параметром SD_SEND или SD_BOTH и сразу после этого — closesocket. Сервер при попытке выполнить операцию с сокетом получает ошибку, после которой также вызывает closesocket. Вызов shutdown на стороне сервера при этом не нужен, т.к. в этот момент соединение уже потеряно, и высылать данные из буфера вместе с сигналом завершения уже некуда.

2.1.9. Передача данных при использовании UDP

Мы наконец-то добрались до изучения того, ради чего сокеты и создавались: как передавать и получать с их помощью данные. По традиции начнем рассмотрение с более простого протокола 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 задает адрес (состоящий из IP-адреса и порта) удаленного сокета, который должен получить эти данные. Значение параметра addrto должно формироваться по тем же правилам, что значение аналогичного параметра функции bind, за исключением того, что IP-адрес и порт должны быть заданы явно (т.е. не допускаются значения INADDR_ANY и нулевой номера порта). Параметр tolen задает длину буфера, отведенного для адреса, и должен быть равен SizeOf(TSockAddr). Один вызов функции sendto приводит к отправке одной дейтаграммы. Данные, переданные в sendto, никогда не разбиваются на несколько дейтаграмм, и данные, переданные последовательными вызовами sendto, никогда не объединяются в одну дейтаграмму.

Функцию sendto можно использовать с сокетами, не привязанными к адресу. В этом случае внутри библиотеки сокетов будет неявно вызвана функция bind для привязки сокета к адресу INADDR_ANY и нулевому порту (т.е. адрес и порт будут выбраны системой).

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

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

В случае успешного завершения функция sendto возвращает количество байтов, скопированных в буфер (или переданных напрямую в сеть, если буфера нет). Для протокола UDP это значение может быть равно только значению параметра len, хотя для некоторых других протоколов (например, TCP) возможны ситуации, когда в буфер сокета копируется только часть данных, переданных программой, и тогда sendto возвращает значение в диапазоне от 1 до len. Если при выполнении sendto возникает ошибка, она возвращает значение SOCKET_ERROR (эта константа имеет отрицательное значение).

Для получения данных, присланных сокету, предназначена функция recvfrom, имеющая следующий прототип:

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

Параметр s задает сокет, из входного буфера которого будут извлекаться данные, Buf — буфер, в который эти данные будут копироваться, а len — размер этого буфера. Параметр flags задает дополнительные опции и в большинстве случаев должен быть равен нулю. Параметр from выходной: в него помещается адрес, с которого была послана дейтаграмма. Параметр fromlen задает размер в байтах буфера для адреса отправителя. При вызове функции значение переменной, подставляемой в качестве фактического параметра, должно быть равно SizeOf(TSockAddr). Функция меняет это значение на ту длину, которая реально потребовалась для хранения адреса отправителя (в случае UDP это значение также будет равно SizeOf(TSockAddr).

В оригинале параметры from и fromlen передаются как указатели, и программа может использовать вместо них нулевые указатели, если ее не интересует адрес отправителя. Разработчики модуля WinSock заменили указатели параметрами-переменными, что в большинстве случаев удобнее. Но для передачи нулевых указателей приходится в качестве фактических параметров подставлять неуклюжие конструкции PSockAddr(nil)^ и PInteger(nil)^.

Функция reсvfrom всегда читает только одну дейтаграмму, даже если размер переданного ей буфера достаточен для чтения нескольких дейтаграмм. Если на момент вызова recvfrom дейтаграммы во входном буфере сокета отсутствуют, функция будет ждать, пока они там появятся, и до этого момента не вернет управление вызвавшей её программе. Если в буфере находится несколько дейтаграмм, то они читаются в порядке очередности поступления в буфер. Напомним, что дейтаграммы могут поступать в буфер не в том порядке, в котором они были отправлены. Кроме того, в очень редких случаях буфер может содержать несколько копий одной дейтаграммы, каждую из которых нужно извлекать отдельно.

Значение, возвращаемое функцией recvfrom, равно длине прочитанной дейтаграммы. Это значение может быть равно нулю, т.к. UDP позволяет отправлять дейтаграммы нулевой длины (для этого при вызове sendto нужно задать параметр len равным нулю). Если обнаружена какая-то ошибка, возвращается значение SOCKET_ERROR.

Если размер буфера, определяемого параметром Buf, меньше, чем первая находящаяся во входном буфере сокета дейтаграмма, то копируется только часть дейтаграммы, помещающаяся в буфере, a recvfrom завершается с ошибкой (WSAGetLastError при этом вернет ошибку WSAEMSGSSIZE). Оставшаяся часть дейтаграммы при этом безвозвратно теряется, при следующем вызове recvfrom будет прочитана следующая дейтаграмма. Этой проблемы легко избежать, т.к. длина дейтаграммы в UDP не может превышать 65 507 байтов. Достаточно подготовить буфер соответствующей длины, и и в него гарантированно поместится любая дейтаграмма.

Другой способ избежать подобной проблемы — использовать флаг MSG_PEEK. В этом случае дейтаграмма не удаляется из входного буфера сокета, а значение, возвращаемое функцией recvfrom, равно длине дейтаграммы. При этом в буфер, заданный параметром Buf, копируется та часть дейтаграммы, которая в нем помещается. Программа может действовать следующим образом: вызвать recvfrom с флагом MSG_PEEK, выделить память, требуемую для хранения дейтаграммы, вызвать recvfrom без флага MSG_PEEK, чтобы прочитать дейтаграмму целиком и удалить ее из входного буфера сокета. Этот метод сложнее, а 65 507 байтов — не очень большая по нынешним меркам память, поэтому легче все-таки заранее приготовить буфер фиксированной длины. Функция recvfrom непригодна для тех сокетов, которые еще не привязаны к адресу, поэтому перед вызовом этой функции должна быть вызвана либо функция bind, либо функция, которая осуществляет неявную привязку сокета к адресу (например, sendto).

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

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

Параметр s задает сокет, который должен быть "соединен" с удаленным адресом. Адрес задается параметром name аналогично тому, как он задаётся в параметре addr функции sendto. Параметр namelen содержит длину структуры, описывающей адрес, и должен быть равен SizeOf(TSockAddr). Функция возвращает ноль при успешном завершении и SOCKET_ERROR — в случае ошибки. Вызов функции connect в случае UDP устанавливает фильтр для входящих дейтаграмм. Дейтаграммы, адрес отправителя которых не совпадает с адресом, заданным в функции connect, игнорируются: новые дейтаграммы не помещаются во входной буфер сокета, а те, которые находились там на момент вызова connect, удаляются из него. Функция connect не проверяет, существует ли адрес, с которым сокет "соединяется", и может успешно завершиться, даже если узла с таким IP-адресом нет.

Программа может вызывать connect неограниченное число раз с разными адресами. Если параметр name задает IP-адрес INADDR_ANY и нулевой порт, то сокет "отсоединяется", т.е. все фильтры для него снимаются, и он ведет себя так же, как сокет, для которого не была вызвана функция connect. Для сокетов, не привязанных к адресу, connect неявно вызывает bind.

После вызова connect для отправки данных можно использовать функцию send со следующим прототипом:

function send(s: TSocket; var Buf; len, flags: Integer): Integer;

От функции sendto она отличается отсутствием параметров addrto и tolen. При использовании send дейтаграмма отправляется по адресу, заданному при вызове connect. В остальном эти функции ведут себя одинаково, функция sendto при работе с "соединенным" сокетом ведет себя так же, как с несоединенным, т.е. отправляет дейтаграмму по адресу, определяемому параметром addrlen, а не по адресу, заданному при вызове connect.

Получение данных через "соединенные" сокеты может также осуществляться с помощью функции reсv, имеющей следующий прототип:

function recv(s: TSocket; var Buf; len, flags: Integer): Integer;

От своего аналога recvfrom она отличается только отсутствием параметров from и fromlen, через которые передается адрес отправителя дейтаграммы.

Рис. 2.1. Последовательность действий программы при обмене данными с помощью UDP

Строго говоря, функцию recv можно использовать и для несоединенных сокетов, но при этом программе остается неизвестным адрес отправителя. В случае же "соединенных" сокетов адрес отправителя заранее известен — это адрес, заданный в функции connect, а дейтаграммы всех других отправителей будут отбрасываться. Функция recvfrom также пригодна для "соединенных" сокетов, но адрес отправителя, который она возвращает, в данном случае может быть только тот, который определен в функции connect.

Таким образом, функция connect в случае протокола UDP позволяет, во-первых, выполнить фильтрацию входящих дейтаграмм по адресу средствами самой библиотеки сокетов, а во-вторых, использовать более лаконичные альтернативы recvfrom и sendto — recv и send.

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

2.1.10. Пример программы: простейший чат на UDP

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

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

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

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

Листинг 2.6. Функция GetErrorString, возвращающая описание ошибки

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

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

// вернула функция WSAGetLastError. Для получения сообщения

// используется системная функция FormatMessage.

function GetErrorString: string;

var

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

begin

FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, nil, WSAGetLastError, $400,

@Buffer, SizeOf(Buffer), nil);

Result := Buffer;

end;

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

Нить, читающая данные, создается обычным образом — порождением наследника от класса TThread. Мы не будем возлагать на эту нить задачу создания сокета, — пусть он создается в главной нити, а затем его дескриптор передаётся в дополнительную, которая сохраняет его в своем внутреннем поле FSocket. Код нити, читающей сообщения, показан в листинге 2.7.

Листинг 2.7. Код "читающей" нити

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. Пользователю не принципиально, какой порт займет этот сокет, поэтому мы доверяем его выбор системе (листинг 2.8).

Листинг 2.8. Инициализация программы UDPChat

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.

Листинг 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;

Для отправки сообщения пользователь должен нажать кнопку Отправить. При этом формируется адрес на основании введённых пользователем данных и вызывается функция sendto (листинг 2.10). Пользователь должен каким-то образом узнать, какой порт назначения выбран у адресата. Его IP-адрес тоже, разумеется, необходимо знать.

Листинг 2.10. Обработчик нажатия кнопки Отправить

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

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;

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

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

Здесь возникает вопрос: нельзя ли с помощью sendto передавать данные через тот же сокет, который в другой нити используется в функции recvfrom? Документация по этому поводу упорно молчит. Если в нашем чате оставить только один сокет и задействовать его в обеих нитях, то всё вроде как работает. Однако это тот случай, когда эксперимент не может служить доказательством, потому что у ошибок, связанных с неправильной синхронизацией нитей, есть очень неприятная особенность: программа может миллион раз отработать правильно, а на миллион первый дать сбой. Поэтому сколько бы раз такой эксперимент ни завершился удачно, полной гарантии он все же не даёт, так что приходится действовать осторожно и не использовать один сокет в разных нитях.

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

Примечание

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

2.1.11. Передача данных при использовании TCP

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

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

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

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

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

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

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

Функция recv копирует пришедшие данные из входного буфера сокета в буфер, заданный параметром Buf, но не более len байтов. Скопированные данные удаляются из буфера сокета. При этом все полученные данные сливаются в один поток, поэтому получатель может самостоятельно выбирать, какой объем данных считывать за один раз. Если за один раз была скопирована только часть пришедшего пакета, оставшаяся часть не пропадает, а будет скопирована при следующем вызове recv. Функция recv возвращает число байтов, скопированных в буфер. Если на момент ее вызова входной буфер сокета пуст, она ждет, когда там что-то появится, затем копирует полученные данные и лишь после этого возвращает управление вызвавшей ее программе. Если recv возвращает 0, это значит, что удаленный сокет корректно завершил соединение. Если соединение завершено некорректно (например, из-за обрыва кабеля или сбоя удаленного компьютера), функция завершается с ошибкой (т.е. возвращает SOCKET_ERROR).

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

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

Параметр s задает сокет, который переводится в режим ожидания подключения. Этот сокет должен быть привязан к адресу, т.е. функция bind должна быть вызвана для него явно. Для сокета, находящегося в режиме ожидания, создается очередь подключений. Размер этой очереди определяется параметром backlog, если он равен SOMAXCONN, очередь будет иметь максимально возможный размер. В MSDN отмечается, что узнать максимально допустимый размер очереди стандартными средствами нельзя. Функция возвращает ноль при успешном завершении и SOCKET_ERROR — в случае ошибки.

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

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

Параметр s задает сокет, который находится в режиме ожидания соединения и из очереди которого извлекается информация о соединении. Выходной параметр addr позволяет получить адрес клиента, установившего соединение. Здесь должен быть передан указатель на буфер, в который этот адрес будет помещен. Параметр addrlen содержит указатель на переменную, в которой хранится длина этого буфера: до вызова функции эта переменная должна содержать фактическую длину буфера, задаваемого параметром addr, после вызова — количество байтов буфера, реально понадобившихся для хранения адреса клиента. Очевидно, что в случае TCP и входное, и выходное значение этой переменной должно быть равно SizeOf(TSockAddr). Эти параметры передаются как указатели, а не как параметры-переменные, что было бы более естественно для Delphi, потому что библиотека сокетов допускает для этих указателей нулевые значения, если сервер не интересует адрес клиента. В данном случае разработчики модуля WinSock сохранили полную функциональность, предоставляемую библиотекой.

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

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

Для получения целостной картины кратко повторим все сказанное. Для установления соединения сервер должен, во-первых, создать сокет с помощью функции socket, а во-вторых, привязать его к адресу с помощью функции bind. Далее сокет должен быть переведен в режим ожидания с помощью listen, а потом с помощью функции accept создается новый сокет, обслуживающий соединение, установленное клиентом. После этого сервер может обмениваться данными с клиентом. Клиент же должен создать сокет, при необходимости привязки к конкретному порту вызвать bind, и затем вызвать connect для установления соединения. После успешного завершения этой функции клиент может обмениваться данными с сервером. Это иллюстрируют листинги 2.11 и 2.12.

Листинг 2.11. Код сервера

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.

Листинг 2.12. Код клиента

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 успешно завершилась и в распоряжении программы оказались два сокета: находящийся в режиме ожидания новых подключений и созданный для обслуживания уже существующего подключения. Если вызвать accept, то программа не сможет продолжить работу до тех пор, пока не подключится еще один клиент, а это может произойти через очень длительный промежуток времени или вообще никогда не случится. Из-за этого программа не сможет обрабатывать вызовы уже подключившегося клиента. С другой стороны, если функцию acсept не вызывать, сервер не сможет обнаружить подключение новых клиентов. Средства для решения этой проблемы есть как у стандартных сокетов, так и у сокетов Windows, и далее мы их рассмотрим. Но существует довольно популярный способ ее решения средствами не библиотеки сокетов, а операционной системы. Он заключается в использовании отдельной нити для обслуживания каждого из клиентов. Каждый раз, когда клиент подключается, функция accept передает управление программе, возвращая новый сокет. Здесь сервер может породить новую нить, которая предназначена исключительно для обмена данными с новым клиентом. Старая нить после этого снова вызывает accept для старого сокета, а новая — функции recv и send для нового сокета. Такой метод решает заодно и проблемы, связанные с тем, что функции send и recv также могут блокировать работу программы и помешать обмену данными с другими клиентами. В данном случае будет блокирована только одна нить, обменивающаяся данными с одним из клиентов, а остальные нити продолжат свою работу. Далее мы рассмотрим пример сервера, работающего по такой схеме.

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

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

Листинг 2.13. Функция 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;

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

2.1.12. Примеры передачи данных с помощью TCP

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

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

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

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

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

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

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

Назад: Глава 2 Использование сокетов Delphi

Дальше: 2.1.13. Определение готовности сокета