Операционная система UNIX - Андрей Робачевский

Поскольку домен и семейство протоколов определяют адресное пространство взаимодействия (допустимые адреса и их формат), то в названиях доменов присутствует префикс AF (от address family — семейство адресов). Допустимыми также являются названия с префиксом PF (protocol family) PF_UNIX, PF_INET и т.д.

Заметим, что домен может не поддерживать определенные типы сокетов. Для сравнения в табл. 3.7 приведены два основных коммуникационных домена — внутренний домен UNIX, предназначенный для взаимодействия процессов одной операционной системы, и домен TCP/IP, используемый в сетевых распределенных приложениях.

Таблица 3.7. Поддержка различных типов сокетов в доменах

Домен: AF_UNIX AF_INET Тип сокета SOCK_STREAM Да Да SOCK_DGRAM Да Да SOCK_SEQPACKET Нет Нет SOCK_RAW Нет Да

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

Сокет Протокол SOCK_STREAM IPPROTO_TCP (TCP) SOCK_DGRAM IPPROTO_UDP (UDP) SOCK_RAW IPPROTO_ICMP (ICMP) SOCK_RAW IPPROTO_RAW (IP)

Указанные протоколы принадлежат семейству сетевых протоколов TCP/IP и будут подробно рассмотрены в главе 6.

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

1. Коммуникационным протоколом

2. Локальным адресом

3. Локальным процессом

4. Удаленным адресом

5. Удаленным процессом

Как правило, адрес определяет операционную систему (или хост сети), а процесс — конкретное приложение, получающее или передающее данные. Однако конкретные значения и формат этих параметров определяются коммуникационным доменом.

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

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

Рис. 3.21. Взаимодействие между процессами при создании виртуального канала (с предварительным установлением соединения)

Рис. 3.22. Взаимодействие между процессами, основанное на датаграммах (без предварительного установления соединения)

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

#include <sys/types.h>

#include <sys/socket.h>

int bind(int sockfd, struct sockaddr *localaddr, int addrlen);

Здесь sockfd является дескриптором сокета, полученным при его создании; аргумент localaddr определяет локальный адрес, с которым необходимо связать сокет; параметр addrlen определяет размер адреса. Заметим, что речь идет о связывании с локальным адресом, в общем случае определяющим два параметра коммуникационного канала (коммуникационный узел): локальный адрес и локальный процесс.

Как уже обсуждалось, адрес сокета зависит от коммуникационного домена, в рамках которого он определен. В общем случае адрес определяется следующим образом (в файле <sys/socket.h>):

struct sockaddr {

 u_short sa_family;

 char sa_data[14];

}

Поле sa_family определяет коммуникационный домен (семейство протоколов), a sa_data — содержит собственно адрес, формат которого определен для каждого домена.

Например, для внутреннего домена UNIX адрес выглядит следующим образом (определен в <sys/un.h>):

struct sockaddr_un {

 short sun_family; /* ==AF_UNIX */

 char sun_path[108];

};

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

В отличие от локального межпроцессного взаимодействия, для сетевого обмена данными необходимо указание как локального процесса, так и хоста, на котором выполняется данный процесс. Для домена Internet (семейство протоколов TCP/IP) используется следующий формат адреса (определен в файле <netinet/in.h>):

struct sockaddr_in {

 short sin_ family; /* ==AF_INET */

 u_short sin_port;

 struct in_addr sin_addr;

 char sin_zero[0];

}

Адреса этого домена (IP-адреса) будут рассмотрены подробнее в главе 6. Пока лишь заметим, что адрес хоста представляет собой 32-разрядное целое число sin_addr, а процесс (приложение) адресуется 16-разрядным номером порта sin_port.

На рис. 3.23 показаны рассмотренные форматы адресов сокетов.

Рис. 3.23. Адреса сокетов

Итак, связывание необходимо для присвоения сокету локального адреса и, таким образом, для определения коммуникационного узла. Можно выделить три случая использования для этого функции bind(2):

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

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

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

Назначение адреса для клиента также можно выполнить с помощью системного вызова connect(2), устанавливающего связь с сервером и автоматически связывающего сокет клиента с локальным коммуникационным узлом. Вызов connect(2) имеет вид:

#include <sys/types.h>

#include <sys/socket.h>

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

Характер этого вызова предполагает создание виртуального канала и, таким образом, используется для предварительного установления связи между коммуникационными узлами. В этом случае клиенту нет необходимости явно связывать сокет с помощью системного вызова bind(2). Локальный узел коммуникационного канала указывается дескриптором сокета sockfd, для которого система автоматически выбирает приемлемые значения локального адреса и процесса. Удаленный узел определяется аргументом servaddr, который указывает на адрес сервера, a addrlen задает его длину.