Для создания сокета используется системный вызов socket(2) [44] Поскольку сокеты являются неотъемлемой частью BSD UNIX, в системах этой ветви функции, связанные с этими объектами, в частности socket(2) и рассмотренные ниже, представляют собой системные вызовы. В UNIX ветви System V интерфейс сокетов сохранен для совместимости, но имеет совершенно отличную от принятой в BSD архитектуру (основанную на подсистеме STREAMS). Поэтому все его функции являются библиотечными и описываются, соответственно в разделе 3 электронного справочника. Однако, оставляя пальму первенства в этом вопросе за BSD UNIX, в этом разделе будем считать эти функции системными вызовами и связывать с ними раздел 2 справочника man(1M) .
, имеющий следующий вид:
#include
#include
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.
Читать дальше