Операционная система UNIX
вернуться

Робачевский Андрей Михайлович
Шрифт:

Таблица 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 {