Розетки Беркли

Сокеты Беркли — это интерфейс прикладного программирования (API) для интернет-сокетов и сокетов домена Unix , используемый для межпроцессного взаимодействия (IPC). Обычно он реализуется как библиотека подключаемых модулей. Он возник в операционной системе Unix 4.2BSD , выпущенной в 1983 году.

Сокет — это абстрактное представление ( дескриптор ) локальной конечной точки сетевого пути связи. API сокетов Беркли представляет его как файловый дескриптор ( дескриптор файла ) в философии Unix , который обеспечивает общий интерфейс для ввода и вывода потоков данных.

Сокеты Беркли с небольшими изменениями превратились из фактического стандарта в компонент спецификации POSIX . Термин сокеты POSIX по сути является синонимом сокетов Беркли , но они также известны как сокеты BSD , что означает первую реализацию в дистрибутиве программного обеспечения Беркли .

История и реализации

Сокеты Беркли возникли в 4.2BSD Unix операционной системе , выпущенной в 1983 году, в качестве программного интерфейса. Однако только в 1989 году Калифорнийский университет в Беркли смог выпустить версии операционной системы и сетевой библиотеки, свободные от лицензионных ограничений Unix, принадлежащей корпорации AT&T .

Все современные операционные системы реализуют версию интерфейса сокетов Беркли. Он стал стандартным интерфейсом для приложений, работающих в Интернете . Даже реализация Winsock для MS Windows, созданная независимыми разработчиками, точно соответствует стандарту.

API сокетов BSD написан на языке программирования C. Большинство других языков программирования предоставляют аналогичные интерфейсы, обычно написанные в виде библиотеки-оболочки на основе C API.

Сокеты BSD и POSIX.

По мере того, как API сокетов Беркли развивался и в конечном итоге привел к появлению API сокетов POSIX, некоторые функции были признаны устаревшими или удалены и заменены другими. POSIX API также предназначен для повторного входа и поддерживает IPv6.

Действие	БСД	ПОСИКС
Преобразование текстового адреса в упакованный адрес	inet_aton	inet_pton
Преобразование упакованного адреса в текстовый адрес	inet_war	inet_ntop
Прямой поиск имени хоста/службы	gethostbyname, gethostbyaddr, getservbyname, getservbyport	getaddrinfo
Обратный поиск имени хоста/службы	gethostbyaddr, getservbyport	получить информацию о имени

Альтернативы

API STREAMS (TLI) на основе интерфейса транспортного уровня предлагает альтернативу API сокетов. Многие системы, предоставляющие API TLI, также предоставляют API сокетов Беркли.

Не-Unix-системы часто предоставляют API сокетов Беркли с уровнем трансляции в собственный сетевой API. План 9 и Генод используйте API файловой системы с управляющими файлами, а не с файловыми дескрипторами.

Заголовочные файлы

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

Файл	Описание
sys/socket.h	Основные функции сокетов и структуры данных.
нетинет/ин.ч	Семейства адресов AF_INET и AF_INET6 и соответствующие им семейства протоколов PF_INET и PF_INET6. К ним относятся стандартные IP-адреса и номера портов TCP и UDP.
sys/un.h	Семейство адресов PF_UNIX и PF_LOCAL. Используется для локальной связи между программами, работающими на одном компьютере.
arpa/inet.h	Функции для управления числовыми IP-адресами.
netdb.h	Функции для перевода имен протоколов и имен хостов в числовые адреса. Ищет локальные данные, а также службы имен.

Функции API сокетов

Блок-схема транзакции клиент-сервер с использованием сокетов с протоколом управления передачей (TCP).

API сокетов Беркли обычно предоставляет следующие функции:

• Socket() создает новый сокет определенного типа, идентифицируемый целым числом, и выделяет ему системные ресурсы.
• Метод связывания() обычно используется на стороне сервера и связывает сокет со структурой адреса сокета, т.е. с указанным локальным IP-адресом и номером порта.
• Listen() используется на стороне сервера и переводит связанный TCP-сокет в состояние прослушивания.
• Connect() используется на стороне клиента и назначает сокету свободный номер локального порта. В случае TCP-сокета вызывается попытка установить новое TCP-соединение.
• Accept() используется на стороне сервера. Он принимает полученную входящую попытку создать новое TCP-соединение от удаленного клиента и создает новый сокет, связанный с парой адресов сокетов этого соединения.
• send() , Recv() , sendto() и Recvfrom() используются для отправки и получения данных. стандартные функции write() и read() . Также можно использовать
• close() заставляет систему освободить ресурсы, выделенные для сокета. В случае TCP соединение разрывается.
• gethostbyname() и gethostbyaddr() используются для разрешения имен и адресов хостов. Только IPv4.
• getaddrinfo() и freeaddrinfo() используются для разрешения имен и адресов хостов. IPv4, IPv6.
• select() используется для приостановки, ожидания, пока один или несколько сокетов из предоставленного списка будут готовы к чтению, готовы к записи или содержат ошибки.
• poll() используется для проверки состояния сокета в наборе сокетов. Набор можно протестировать, чтобы увидеть, можно ли в какой-либо сокет выполнить запись или чтение или произошла ли ошибка.
• getockopt() используется для получения текущего значения определенной опции сокета для указанного сокета.
• setockopt() используется для установки определенного параметра сокета для указанного сокета.

розетка

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

• домен , который указывает семейство протоколов создаваемого сокета. Например:
  • AF_INET для сетевого протокола IPv4 (только IPv4)
  • AF_INET6 для IPv6 (и в некоторых случаях обратно совместим с IPv4)
  • AF_UNIX для локального сокета (с использованием специального узла файловой системы)
• тип , один из:
  • SOCK_STREAM (надежный потоко-ориентированный сервис или потоковые сокеты )
  • SOCK_DGRAM (служба дейтаграмм или сокеты дейтаграмм )
  • SOCK_SEQPACKET (надежная служба упорядоченных пакетов)
  • SOCK_RAW (необработанные протоколы на сетевом уровне)
• протокол, определяющий фактический используемый транспортный протокол. Наиболее распространенными являются IPPROTO_TCP , IPPROTO_SCTP , IPPROTO_UDP , IPPROTO_DCCP . Эти протоколы указаны в файле netinet/in.h . Значение 0 может использоваться для выбора протокола по умолчанию из выбранного домена и типа.

Функция возвращает -1, если произошла ошибка. В противном случае он возвращает целое число, представляющее вновь назначенный дескриптор.

связывать

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

• sockfd — дескриптор, представляющий сокет
• my_addr — указатель на структуру sockaddr, представляющую адрес для привязки.
• addrlen — поле типа socklen_t, определяющее размер структуры sockaddr .

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

слушать

После того, как сокет связан с адресом, метод Listen() подготавливает его для входящих соединений. Однако это необходимо только для потоково-ориентированных (ориентированных на соединение) режимов данных, т.е. для типов сокетов ( SOCK_STREAM , SOCK_SEQPACKET ). Listen() требует два аргумента:

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

Как только соединение принято, оно выводится из очереди. В случае успеха возвращается 0. В случае возникновения ошибки возвращается -1.

принимать

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

• sockfd — дескриптор прослушивающего сокета, соединение с которым поставлено в очередь.
• cliaddr — указатель на структуру sockaddr для получения информации об адресе клиента.
• addrlen — указатель на местоположение socklen_t , который определяет размер структуры адреса клиента, передаваемой в метод Accept(). Когда метод Accept() возвращает значение, это местоположение содержит размер (в байтах) структуры.

Accept() возвращает новый дескриптор сокета для принятого соединения или значение -1 в случае возникновения ошибки. Вся дальнейшая связь с удаленным хостом теперь происходит через этот новый сокет.

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

соединять

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

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

Connect() возвращает целое число, представляющее код ошибки: 0 представляет успех, а –1 представляет ошибку. Исторически сложилось так, что в системах, основанных на BSD, состояние дескриптора сокета не определено, если вызов подключения завершается неудачей (как указано в Единой спецификации Unix), поэтому переносимые приложения должны немедленно закрыть дескриптор сокета и получить новый дескриптор с помощью Socket(), в случае сбоя вызова метода Connect().

gethostbyname и gethostbyaddr

Функции gethostbyname() и gethostbyaddr() используются для разрешения имен и адресов хостов в системе доменных имен или других механизмах разрешения локальных хостов (например, поиск в /etc/hosts). Они возвращают указатель на объект типа struct hostent , который описывает хост интернет-протокола . Функции используют следующие аргументы:

• name указывает имя хоста.
• addr указывает указатель на структуру in_addr, содержащую адрес хоста.
• len определяет длину addr в байтах .
• type указывает тип семейства адресов (например, AF_INET) адреса хоста.

Функции возвращают NULL-указатель в случае ошибки, и в этом случае внешнее целое число h_errno можно проверить, чтобы определить, является ли это временным сбоем или недействительным или неизвестным хостом. допустимая структура hostent * В противном случае возвращается .

Эти функции не являются строго компонентами API сокетов BSD, но часто используются вместе с функциями API для поиска хоста. Эти функции теперь считаются устаревшими интерфейсами для запроса системы доменных имен. Определены новые функции, полностью независимые от протокола (поддержка IPv6). Эти новые функции — getaddrinfo() и getnameinfo() — основаны на новой addrinfo . структуре данных

Эта пара функций появилась одновременно с API-интерфейсом сокетов BSD в версии 4.2BSD (1983 г.). в том же году впервые был создан DNS. Ранние версии не запрашивали DNS и выполняли только поиск в /etc/hosts. В версии 4.3BSD (1984 г.) DNS был добавлен в грубом виде. Текущая реализация, использующая переключатель службы имен , является производной от Solaris и более поздней версии NetBSD 1.4 (1999). Первоначально определенный для NIS+ , NSS делает DNS лишь одним из многих вариантов поиска с помощью этих функций, и его использование можно отключить даже сегодня.

Протокольные и адресные семьи

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

Ниже приводится выборка семейств протоколов (перед которыми указан стандартный символический идентификатор), определенных в современной реализации Linux или BSD :

Идентификатор	Функция или использование
PF_APPLETALK	AppleTalk
PF_ATMPVC	с асинхронным режимом передачи Постоянные виртуальные каналы
PF_ATMSVC	Виртуальные каналы с асинхронной передачей и коммутацией
PF_AX25	Любительская радиостанция AX.25
PF_CAN	Сеть контроллеров
PF_BLUETOOTH	Bluetooth- разъемы
PF_BRIDGE	Многопротокольный мост
PF_DECnet	Зарезервировано для DECnet проекта
PF_ECONET	Желудь Эконет
PF_INET	Интернет-протокол версии 4
PF_INET6	Интернет-протокол версии 6
PF_IPX	Novell Межсетевой обмен пакетами
PF_IRDA	ИК- разъемы
PF_KEY	API управления ключами PF_KEY
PF_LOCAL, PF_UNIX, PF_FILE	Локально для хоста (каналы и файловый домен)
PF_NETROM	Любительское радио NET/ROM (относится к AX.25)
PF_NETBEUI	Зарезервировано для проекта 802.2LLC.
PF_SECURITY	Обратный вызов безопасности псевдо AF
PF_NETLINK, PF_ROUTE	API маршрутизации
PF_PACKET	Сокеты захвата пакетов
PF_PPPOX	PPP через X -сокеты
PF_SNA	Linux Проект сетевой архитектуры Systems (SNA)
PF_WANPIPE	Сокеты Sangoma Wanpipe API

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

Первоначальная концепция дизайна интерфейса сокетов различала типы протоколов (семейства) и конкретные типы адресов, которые каждый из них может использовать. Предполагалось, что семейство протоколов может иметь несколько типов адресов. Типы адресов определялись дополнительными символьными константами с использованием префикса АФ вместо ПФ . Идентификаторы AF предназначены для всех структур данных, которые конкретно связаны с типом адреса, а не с семейством протоколов. Однако эта концепция разделения протокола и типа адреса не нашла поддержки в реализации, и AF -константы определялись соответствующим идентификатором протокола, оставляя различие между Утка ​ Константы коэффициента мощности как технический аргумент, не имеющий практического значения. Действительно, существует большая путаница в правильном использовании обеих форм.

Спецификация POSIX.1—2008 не определяет никаких ПФ - константы, но только AF Константы

Необработанные розетки

Необработанные сокеты предоставляют простой интерфейс, который обходит обработку стека TCP/IP хоста. Они позволяют реализовать сетевые протоколы в пользовательском пространстве и помогают в отладке стека протоколов. Необработанные сокеты используются некоторыми службами, такими как ICMP , которые работают на уровне Интернета модели TCP/IP.

Блокирующий и неблокирующий режим

Сокеты Беркли могут работать в одном из двух режимов: блокирующем или неблокирующем.

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

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

Сокет обычно устанавливается в блокирующий или неблокирующий режим с помощью функций fcntl и ioctl .

Оконечные розетки

Операционная система не освобождает ресурсы, выделенные для сокета, пока сокет не будет закрыт. Это особенно важно, если вызов подключения завершается неудачно и будет повторен.

Когда приложение закрывает сокет, уничтожается только интерфейс сокета. Ядро несет ответственность за внутреннее уничтожение сокета. Иногда сокет может войти в Состояние TIME_WAIT на стороне сервера до 4 минут.

В системах SVR4 использование close() может сбросить данные. Использование shutdown() или SO_LINGER может потребоваться в этих системах, чтобы гарантировать доставку всех данных.

Пример клиент-сервера с использованием TCP

Протокол управления передачей (TCP) — это протокол , ориентированный на соединение , который обеспечивает различные функции исправления ошибок и производительности для передачи потоков байтов. Процесс создает сокет TCP, вызывая socket() функция с параметрами семейства протоколов ( PF INET , PF_INET6 ), режим сокета для потоковых сокетов ( SOCK_STREAM ) и идентификатор протокола IP для TCP ( IPPROTO_TCP ).

Сервер

Установка TCP-сервера включает в себя следующие основные шаги:

• Создание TCP-сокета с помощью вызова функцииocket().
• Привязка сокета к порту прослушивания ( bind() ) после установки номера порта.
• Подготовка сокета для прослушивания соединений (создание сокета прослушивания) с помощью вызова Listen() .
• Прием входящих соединений ( accept() ). Это блокирует процесс до тех пор, пока не будет получено входящее соединение, и возвращает дескриптор сокета для принятого соединения. Начальный дескриптор остается дескриптором прослушивания, и метод Accept() может быть вызван снова в любое время с помощью этого сокета, пока он не будет закрыт.
• Общение с удаленным хостом осуществляется с помощью функций API send() и Recv() , а также с помощью функций общего назначения write() и read() .
• Закрытие каждого сокета, открытого после использования, с помощью функции close()

Следующая программа создает TCP-сервер, прослушивающий порт номер 1100:

  #include <sys/types.h>
  #include <sys/socket.h>
  #include <netinet/in.h>
  #include <arpa/inet.h>
  #include <stdio.h>
  #include <stdlib.h>
  #include <string.h>
  #include <unistd.h>
  
  int main(void)
  {
    struct sockaddr_in sa;
    int SocketFD = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
    if (SocketFD == -1) {
      perror("cannot create socket");
      exit(EXIT_FAILURE);
    }
  
    memset(&sa, 0, sizeof sa);
  
    sa.sin_family = AF_INET;
    sa.sin_port = htons(1100);
    sa.sin_addr.s_addr = htonl(INADDR_ANY);
  
    if (bind(SocketFD,(struct sockaddr *)&sa, sizeof sa) == -1) {
      perror("bind failed");
      close(SocketFD);
      exit(EXIT_FAILURE);
    }
  
    if (listen(SocketFD, 10) == -1) {
      perror("listen failed");
      close(SocketFD);
      exit(EXIT_FAILURE);
    }
  
    for (;;) {
      int ConnectFD = accept(SocketFD, NULL, NULL);
  
      if (ConnectFD == -1) {
        perror("accept failed");
        close(SocketFD);
        exit(EXIT_FAILURE);
      }
  
      /* perform read write operations ... 
      read(ConnectFD, buff, size)
      */
  
      if (shutdown(ConnectFD, SHUT_RDWR) == -1) {
        perror("shutdown failed");
        close(ConnectFD);
        close(SocketFD);
        exit(EXIT_FAILURE);
      }
      close(ConnectFD);
    }

    close(SocketFD);
    return EXIT_SUCCESS;  
}

Клиент

Программирование клиентского приложения TCP включает в себя следующие шаги:

• Создание TCP-сокета.
• Подключение к серверу ( connect() ) путем передачи sockaddr_in структура с sin_family установлен на AF_INET , sin_port установите порт, который прослушивает конечная точка (в сетевом порядке байтов), и sin_addr установлен на IP-адрес прослушивающего сервера (также в сетевом порядке байтов).
• Общение с удаленным хостом осуществляется с помощью функций API send() и Recv() , а также с помощью функций общего назначения write() и read() .
• Закрытие каждого сокета, который был открыт после использования, с помощью функции close().

  #include <sys/types.h>
  #include <sys/socket.h>
  #include <netinet/in.h>
  #include <arpa/inet.h>
  #include <stdio.h>
  #include <stdlib.h>
  #include <string.h>
  #include <unistd.h>
  
  int main(void)
  {
    struct sockaddr_in sa;
    int res;
    int SocketFD;

    SocketFD = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
    if (SocketFD == -1) {
      perror("cannot create socket");
      exit(EXIT_FAILURE);
    }
  
    memset(&sa, 0, sizeof sa);
  
    sa.sin_family = AF_INET;
    sa.sin_port = htons(1100);
    res = inet_pton(AF_INET, "192.168.1.3", &sa.sin_addr);

    if (connect(SocketFD, (struct sockaddr *)&sa, sizeof sa) == -1) {
      perror("connect failed");
      close(SocketFD);
      exit(EXIT_FAILURE);
    }
  
    /* perform read write operations ... */
  
    close(SocketFD);
    return EXIT_SUCCESS;
  }

Пример клиент-сервера с использованием UDP

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

Адресное пространство UDP, пространство номеров портов UDP (в терминологии ISO, TSAP ), полностью не пересекается с пространством портов TCP.

Сервер

Приложение может настроить UDP-сервер на порту 7654 следующим образом. Программы содержат бесконечный цикл, который получает датаграммы UDP с помощью функции Recvfrom() .

#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <unistd.h> /* for close() for socket */ 
#include <stdlib.h>

int main(void)
{
  int sock;
  struct sockaddr_in sa; 
  char buffer[1024];
  ssize_t recsize;
  socklen_t fromlen;

  memset(&sa, 0, sizeof sa);
  sa.sin_family = AF_INET;
  sa.sin_addr.s_addr = htonl(INADDR_ANY);
  sa.sin_port = htons(7654);
  fromlen = sizeof sa;

  sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
  if (bind(sock, (struct sockaddr *)&sa, sizeof sa) == -1) {
    perror("error bind failed");
    close(sock);
    exit(EXIT_FAILURE);
  }

  for (;;) {
    recsize = recvfrom(sock, (void*)buffer, sizeof buffer, 0, (struct sockaddr*)&sa, &fromlen);
    if (recsize < 0) {
      fprintf(stderr, "%s\n", strerror(errno));
      exit(EXIT_FAILURE);
    }
    printf("recsize: %d\n ", (int)recsize);
    sleep(1);
    printf("datagram: %.*s\n", (int)recsize, buffer);
  }
}

Клиент

Ниже представлена ​​клиентская программа для отправки UDP-пакета, содержащего строку «Hello World!» по адресу 127.0.0.1 по номеру порта 7654.

#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <unistd.h>
#include <arpa/inet.h>

int main(void)
{
  int sock;
  struct sockaddr_in sa;
  int bytes_sent;
  char buffer[200];
 
  strcpy(buffer, "hello world!");
 
  /* create an Internet, datagram, socket using UDP */
  sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
  if (sock == -1) {
      /* if socket failed to initialize, exit */
      printf("Error Creating Socket");
      exit(EXIT_FAILURE);
  }
 
  /* Zero out socket address */
  memset(&sa, 0, sizeof sa);
  
  /* The address is IPv4 */
  sa.sin_family = AF_INET;
 
   /* IPv4 addresses is a uint32_t, convert a string representation of the octets to the appropriate value */
  sa.sin_addr.s_addr = inet_addr("127.0.0.1");
  
  /* sockets are unsigned shorts, htons(x) ensures x is in network byte order, set the port to 7654 */
  sa.sin_port = htons(7654);
 
  bytes_sent = sendto(sock, buffer, strlen(buffer), 0,(struct sockaddr*)&sa, sizeof sa);
  if (bytes_sent < 0) {
    printf("Error sending packet: %s\n", strerror(errno));
    exit(EXIT_FAILURE);
  }
 
  close(sock); /* close the socket */
  return 0;
}

В этом коде buffer — это указатель на данные, которые необходимо отправить, а buffer_length указывает размер данных.

Ссылки

Стандартное де-юре определение интерфейса Sockets содержится в стандарте POSIX, известном как:

• Стандарт IEEE . 1003.1-2001 Стандарт информационных технологий — интерфейс портативной операционной системы (POSIX).
• Технический стандарт Открытой группы: базовые спецификации, выпуск 6, декабрь 2001 г.
• ИСО/МЭК 9945:2002.

Информацию об этом стандарте и текущей работе над ним можно получить на сайте Остина .

Расширения IPv6 для API базового сокета документированы в RFC 3493 и RFC 3542.

• Стивенс, В. Ричард; Раго, Стивен А. (24 мая 2013 г.). Расширенное программирование в среде UNIX (Третье изд.). Аддисон-Уэсли Профессионал . ISBN  978-0321637734 . Проверено 27 февраля 2015 г.

Внешние ссылки

• Дополнительные документы для UNIX-программиста (PSD: 20-1)
• Руководство Биджа по сетевому программированию - 2007 г.
• Портирование программ Berkeley Socket на Winsock — документация Microsoft.
• Программирование сокетов UNIX на языке C. Часто задаваемые вопросы , 1 996 г.
• Сетевое программирование Linux — Linux Journal , 1998 г.