Для создания сокета процесс должен указать тип сокета и коммуникационный домен, в рамках которого будет использоваться сокет. Поскольку коммуникационный домен может поддерживать использование нескольких протоколов, процесс может также указать конкретный коммуникационный протокол для взаимодействия. Если таковой не указан, система выберет наиболее подходящий из списка протоколов, доступных для данного коммуникационного домена. Если же в рамках указанного домена создание сокета данного типа невозможно, т.е. отсутствует соответствующий коммуникационный протокол, запрос процесса завершится неудачно.
Для создания сокета используется системный вызов socket(2)[44], имеющий следующий вид:
#include <sys/types.h>
#include <sys/socket.h>
int socket(int domain, int type, int protocol);
Здесь аргумент domain определяет коммуникационный домен, type — тип сокета, a protocol — используемый протокол (может быть не указан, т.е. приравнен 0). В случае успеха системный вызов возвращает положительное целое число, аналогичное файловому дескриптору, которое служит для адресации данного сокета в последующих вызовах.
По существу коммуникационный домен определяет семейство протоколов (protocol family), допустимых в рамках данного домена. Возможные значения аргумента domain включают:
AF_UNIX |
Домен локального межпроцессного взаимодействия в пределах единой операционной системы UNIX. Внутренние протоколы. |
AF_INET |
Домен взаимодействия процессов удаленных систем. Протоколы Internet (TCP/IP). |
AF_NS |
Домен взаимодействия процессов удаленных систем. Протоколы Xerox NS. |
Поскольку домен и семейство протоколов определяют адресное пространство взаимодействия (допустимые адреса и их формат), то в названиях доменов присутствует префикс 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 определяет размер адреса. Заметим, что речь идет о связывании с локальным адресом, в общем случае определяющим два параметра коммуникационного канала (коммуникационный узел): локальный адрес и локальный процесс.
44
Поскольку сокеты являются неотъемлемой частью BSD UNIX, в системах этой ветви функции, связанные с этими объектами, в частности