5

Лекция №22

Лекция №22

Сокеты

Итак, сегодня мы с Вами будем говорить о механизме сокетов. Этот механизм впервые был разработан в версии ОС BSD. В дальнейшем этот механизм получил распространение в других версиях ОС. Но следует отметить, что его реализации в различных клонах UNIX конечно отличаются от того, что было предложено в BSD UNIX. Замечу, что этот механизм поддерживается системой и в нашем машинном зале.

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

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

• AF_UNIX

• AF_INET

Реально кроме средств взаимодействия коммуникационный домен определяет адресацию, которая будет применяться в рамках взаимодействия. Мы пришли к той же «широкой» проблеме, которая возникала и в механизме сигналов, и в средствах, предоставляемых IPC, - проблеме адресации. При работе с сигналами в качестве адресов использовались идентификаторы процессов, в случае IPC – уникальные ключи. При работе с сокетами конкретный метод адресации определяется коммуникационным доменом. Эта проблема действительно «широкая», например, если мы говорим о двух процессах в сети, то появляется необходимость т. н. сетевой адресации.

Когда мы говорим о сокетах, с этим понятием ассоциируется несколько свойств, в том числе домен и тип сокета. Тип сокета кроме всего прочего определяет дисциплину организации взаимосвязи. Существует несколько типов сокетов: от низкоуровневых до достаточно высокоуровневых. Мы будем говорить о сокетах двух типов:

• соединение с использованием виртуального канала;

• сокеты датаграмм.

Соединение с использованием виртуального канала – соединение, которое представляется последовательным потоком байтов, и гарантирует доставку данных от отправителя к адресату. Датаграммные сокеты – это попросту говоря пакеты, которые в общем случае не обладают «гарантированной» доставкой и порядок прихода которых может быть произвольным. Это напоминает ситуацию, когда отправлены несколько писем одному адресату. Письма могут придти не все и кроме того не в том порядке, в котором их посылали. Я в свое время был в Китае. В декабре месяце отправил домой поздравление с Новым Годом. В силу определенных обстоятельств я очень скоро покинул страну и оказался дома. А поздравление пришло … в мае месяце …

Здесь также существует некоторая аналогия с протоколами TCP и UDP, рассмотренными нами на прошлой лекции, т. е. дейтаграммы – это некий аналог UDP, а виртуальный канал напоминает TCP.

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

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

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

#include <sys/types.h>

#include <sys/socket.h>

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

int socket (int domain, int type, int protocol);

domain – константа, определяющая коммуникационный домен, который будет использоваться для взаимодействия, в частности значение AF_UNIX определяет домен локального межпроцессного взаимодействия внутри одной UNIX-системы, а значение AF_INET соответствует домену взаимодействия удаленных систем с использованием TCP/IP.

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

protocol – код протокола, который будет использоваться для взаимодействия. Значение IPPROTO_TCP используют, если тип сокета – виртуальный канал, IPPROTO_UDP – если речь идет о датаграммном сокете. Если protocol=0, то система сама подберет подходящий протокол.

Функция возвращает дескриптор сокета - некоторое положительное число в случае успешной работы и «-1» в случае возникновения проблем (в errno – причина).

Функция связывания

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

int bind(int sockfd, struct sockaddr * myaddr, int sizeaddr);

sockfd – дескриптор сокета, который вернула функция socket.

sizeaddr – размер той структуры в байтах, на которую указывает второй аргумент (myaddr). Использование этого аргумента обусловлено тем, что реально в зависимости от домена форматы структур могут быть разными. Чтобы не быть голословным я приведу формат структуры sockaddr для UNIX-домена, которая содержится в файле sys/un.h:

struct sockaddr_un

{

short sun_family; // Код домена, в частности AF_UNIX

char sun_path[108]; // имя файла, с которым будет связан адрес

}

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

Если мы используем домен INET, то формат структуры адреса берется из файла sys/netinet/in.h. Соответственно в этой структуре первое поле – тип домена (в данном случае AF_INET), второе поле – номер порта и IP-адрес хоста, на котором работает текущий процесс. Работа с портами дает возможность создания нескольких сокетов на одной машине с общим IP-адресом. Функция bind используется в различных ситуациях, но следует подчеркнуть, что она обязана использоваться в том процессе, к адресу которого происходит обращение. В данном случае механизм сокетов ложится на т. н. технологию клиент-сервер, суть которой состоит в том, что есть некая сущность, которая предоставляет услуги – назовем ее сервер и есть сущность клиент, которая запрашивает услуги. Все как в магазине: Вы – клиент, а сервер - … это милая девушка которая стоит у прилавка, которая может Вас обслужить – продать помидоры, может не обслужить, может обслужить так, что в этот магазин Вы больше не пойдете … Ну а если серьезно, то технология клиент-сервер широко используется в базах данных и позволяет по запросам осуществлять выборку нужной информации. Т. е. клиент делает запрос – сервер обрабатывает запрос и делает выборку и выдает результат клиенту.

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

Функция bind возвращает «0» в случае успеха и «-1» в случае ошибки.

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

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

int connect (int sockfd, struct sockaddr *servaddr, int addrlen);

sockfd – дескриптор сокета.

servaddr – указатель на структуру, содержащую адрес сокета-сервера.

addrlen – длина структуры, содержащей адрес.

Соединение осуществляется от имени клиента, т. е. в рамках сервера происходит регистрация того факта, что имеется клиент – сокет, который будет работать с сервером. Обращаю Ваше внимание, что установка соединения имеет смысл для домена INET.

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

Рассмотрим серверные функции:

1. int listen (int sockfd, int backlog);

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

sockfd – дескриптор сокета.

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

1. int accept (int sockfd, struct sockaddr *clntaddr, int *addrlen);

Это функция подтверждения соединения. Ее параметры:

sockfd – дескриптор сокета.

clntaddr – указатель на структуру, в которой указан адрес клиента.

addrlen – указатель на целочисленную переменную, содержащую длину адреса (фактически, длину структуры sockaddr).

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

1. read/write – полностью аналогичны работе с файлами, но только вместо файлового дескриптора будет дескриптор сокета. Например, write в сервере может работать с тем дескриптором сокета, который вернула функция accept, а в клиенте – с дескриптором, который вернула функция connect.

2. send/recv и sendto/recvfrom – реально эти функции Вы посмотрите сами в доступной литературе. В общем то, эти функции аналогичны read/write.

Функции закрытия сокета

Две функции:

1. close – полная аналогия с работой с файлами, но аргумент – дескриптор сокета.

2. int shutdown (int sd, int mode);

sd – дескриптор сокета.

mode – некий модификатор, который определяет вариации закрытия сокета:

• на получение информации;

• на передачу информации;

• совсем.

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

О
бщая схема функционирования взаимодействия при создании виртуального канала (с предварительным установлением соединения) приведена на рисунке:

Все очень прозрачно: формирование сокета, именование, декларирование готовности к работе. Замечу, что блоков accept – close может быть произвольное количество, лимитированное лишь ресурсами системных таблиц. Кроме того, подчеркну, что блоки accept – close могут произвольным образом пересекаться, т. е. сначала может, например, идти 20 раз обращение к accept, а в конце 20 раз close. Еще одна оговорка – связывание имени с помощью bind() может не быть в клиенте: продавщице не обязательно знать, как зовут покупателя. Это, пожалуй, все о схеме взаимодействия с предварительной установкой соединения.

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

Здесь в общем то все тоже достаточно прозрачно и понятно: открываем сокет, связываем с ним именование и работаем по именам. Замечу, что в обоих примерах ничто не мешало нам вместо close использовать shutdown.

Вот, пожалуй, все, что я Вам хотел сказать о сокетах. Мы говорили, конечно, совсем поверхностно, совсем «на пальцах». Я бы хотел, чтобы Вы осознали, что такое сокет, потому, что это достаточно общий, интересный и полезный механизм взаимодействия в рамках сети (или одной ЭВМ). Это была последняя лекция. Спасибо за внимание!

(Раздаются бурные незатухающие аплодисменты.)

Copyright Gerasimov Sergej, group 205