Что такое дескриптор сокета

12. Что такое дескриптор сокета?

Вы знаете, что при создании сокета сетевой адрес не указывается. Функция socket создает сокет и возвращает значение дескриптора, присвоенного системой этому сокету. Дескриптор указывает на член системной таблицы дескрипторов, соответствующий данному сокету.

Системная таблица дескрипторов управляется реализацией сокетов. Вам, как прикладному программисту, приходится общаться с этой таблицей посредством дескрипторов сокетов. На самом деле «создание сокета» — это просто процесс отведения памяти системой для размещения в ней структуры данных, описывающей данный сокет.

В операционной системе UNIX каждый процесс владеет одной таблицей дескрипторов файлов. (Вы помните, что разработчики интерфейса сокетов использовали ту же концепцию и для сетевого ввода-вывода.) Функция-socket в UNIX получает дескриптор из таблицы дескрипторов файлов. Дескриптор является указателем на внутреннюю структуру данных. Структура данных сокета в упрощенном виде показана на рис. .1.

Рис. 1

Как видно из рисунка, структура данных сокета включает элементы для хранения аргументов, с которыми была вызвана функция socket. Кроме того, в структуре размещены четыре адреса: локальный IP-адрес, удаленный IP-адрес, адреса локального и удаленного портов. Каждый раз, когда программа вызывает функцию-socket, реализация сокетов отводит машинную память для новой структуры данных, а затем размещает в ней семейство адресов, тип сокета и протокола. В таблице дескрипторов размещается указатель на эту структуру. Дескриптор, полученный вашей программой от функции socket, является индексом (порядковым номером) в таблице дескрипторов.

Интерфейс сокетов не определяет никаких способов управления дескриптором сокета. Сам UNIX обращается с дескрипторами сокетов точно так же, как с дескрипторами файлов. Другие приложения могут обращаться с дескрипторами так, как это им заблагорассудится. Другими словами, то, что происходит с данными, на которые указывает дескриптор, зависит от конкретной реализации системы, с которой вы работаете. Вам, как прикладному программисту, не обязательно знать подробности, касающиеся таблиц дескрипторов, структуры данных в них и отведения памяти. Мы рассматриваем все это, только чтобы показать, каким образом сокету присваивается сетевой адрес. Функция socket образует структуру данных сокета, не заполняя при этом поля адресов. Чтобы связать сокет с определенным сетевым адресом, необходимо вызвать другие функции, входящие в состав API, так, как это будет показано в следующих разделах.

Парадигма сокетов, или модель интерфейса сокетов, рассматривает сетевые компьютеры в качестве конечных точек сетевого соединения. Каждое сетевое соединение включает две конечные точки: локальный компьютер и удаленный компьютер. В рамках интерфейса сокетов каждая конечная точка сети представлена сокетом. Вы знаете, что большинство сетевых программ пользуются моделью клиент-сервер. Сетевые соединения в рамках этой модели также включают две конечные точки соединения. Модель клиент/сервер делает эти две точки неравноправными. Одна должна выполнять функции сервера, а другая — клиента. Конечная точка-клиент инициирует запрос к сетевым службам и представлена программой-клиентом или процессом-клиентом. Конечная точка, отвечающая на запрос, представлена программой или процессом-сервером.

Сетевой уровень IP идентифицирует сетевые компьютеры при помощи сетевого адреса. Это значит, что каждый компьютер, подключенный к Интернет, должен иметь уникальный сетевой адрес. Ранее объяснялось, как транспортный уровень использует адреса портов для обозначения определенных приложений (процессов) в сетевом компьютере. Каждый сетевой процесс, таким образом, использует номер порта сетевого компьютера в качестве собственного адреса. Наконец, вы знаете, что программы Интернет должны использовать семейство протоколов TCP/IP для передачи своих данных по сети. Таким образом, соединение между двумя сетевыми программами несет в себе следующую информацию:

— местный (локальный) порт протокола, обозначающий программу или процесс, посылающий сообщения или датаграммы;

— адрес локального компьютера, обозначающий сетевой компьютер, принимающий пакеты данных;

— удаленный порт протокола, обозначающий программу или процесс-получатель данных;

— протокол, обозначающий, каким образом программа собирается передавать данные по сети.

Структура данных сокета, как видно на рис. 1, соответствующая дескриптору сокета, содержит информацию об этих же пяти пунктах. Таким образом, сокет является реализацией абстрактной модели конечной точки сетевого соединения. Структура данных сокета содержит все элементы, необходимые конечной точке сетевого соединения. Структура данных сокета значительно упрощает процесс сетевого соединения. Когда одна программа желает установить связь с другой, программа-передатчик просто отдает свою информацию сокету, а интерфейс сокетов в свою очередь передает ее дальше стеку сетевых протоколов TCP/IP. Перед этим программа должна создать сокет, вызвав системную функцию-сокет, а затем сконфигурировать его, пользуясь функциями, также входящими в интерфейс сокетов. В следующих разделах будет показано, каким образом сокет конфигурируется.

Сокеты¶

Сокеты (англ. socket — разъём) — название программного интерфейса для обеспечения обмена данными между процессами. Процессы при таком обмене могут исполняться как на одной ЭВМ, так и на различных ЭВМ, связанных между собой сетью. Сокет — абстрактный объект, представляющий конечную точку соединения.

Принципы сокетов¶

Каждый процесс может создать слушающий сокет (серверный сокет) и привязать его к какому-нибудь порту операционной системы (в UNIX непривилегированные процессы не могут использовать порты меньше 1024). Слушающий процесс обычно находится в цикле ожидания, то есть просыпается при появлении нового соединения. При этом сохраняется возможность проверить наличие соединений на данный момент, установить тайм-аут для операции и т.д.

Каждый сокет имеет свой адрес. ОС семейства UNIX могут поддерживать много типов адресов, но обязательными являются INET-адрес и UNIX-адрес. Если привязать сокет к UNIX-адресу, то будет создан специальный файл (файл сокета) по заданному пути, через который смогут сообщаться любые локальные процессы путём чтения/записи из него (см. Доменный сокет Unix). Сокеты типа INET доступны из сети и требуют выделения номера порта.

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

Основные функции¶

socket()¶

Создаёт конечную точку соединения и возвращает файловый дескриптор. Принимает три аргумента:

domain указывающий семейство протоколов создаваемого сокета

• AF_INET для сетевого протокола IPv4
• AF_INET6 для IPv6
• AF_UNIX для локальных сокетов (используя файл)

type

• SOCK_STREAM (надёжная потокоориентированная служба (сервис) или потоковый сокет)
• SOCK_DGRAM (служба датаграмм или датаграммный сокет)
• SOCK_RAW (Сырой сокет — сырой протокол поверх сетевого уровня).

protocol

Протоколы обозначаются символьными константами с префиксом IPPROTO_* (например, IPPROTO_TCP или IPPROTO_UDP). Допускается значение protocol=0 (протокол не указан), в этом случае используется значение по умолчанию для данного вида соединений.

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

Пример на Python

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

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

Возвращает 0 при успехе и −1 при возникновении ошибки.

Пример на Python

Автоматическое получение имени хоста.

listen()¶

Подготавливает привязываемый сокет к принятию входящих соединений. Данная функция применима только к типам сокетов SOCK_STREAM и SOCK_SEQPACKET. Принимает два аргумента:

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

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

Пример на Python

accept()¶

Используется для принятия запроса на установление соединения от удаленного хоста. Принимает следующие аргументы:

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

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

Пример на Python

connect()¶

Устанавливает соединение с сервером.

Некоторые типы сокетов работают без установления соединения, это в основном касается UDP-сокетов. Для них соединение приобретает особое значение: цель по умолчанию для посылки и получения данных присваивается переданному адресу, позволяя использовать такие функции как send() и recv() на сокетах без установления соединения.

Загруженный сервер может отвергнуть попытку соединения, поэтому в некоторых видах программ необходимо предусмотреть повторные попытки соединения.

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

Пример на Python

Передача данных¶

Для передачи данных можно пользоваться стандартными функциями чтения/записи файлов read и write, но есть специальные функции для передачи данных через сокеты:

• send
• recv
• sendto
• recvfrom
• sendmsg
• recvmsg

Нужно обратить внимание, что при использовании протокола TCP (сокеты типа SOCK_STREAM) есть вероятность получить меньше данных, чем было передано, так как ещё не все данные были переданы, поэтому нужно либо дождаться, когда функция recv возвратит 0 байт, либо выставить флаг MSG_WAITALL для функции recv, что заставит её дождаться окончания передачи. Для остальных типов сокетов флаг MSG_WAITALL ничего не меняет (например, в UDP весь пакет = целое сообщение).

Socket and file descriptors

I’m learning about network programming in Unix and currently trying to understand the concept of socket and file descriptors. From what I have understood a file descriptor is simply a position in an array of pointers (File descriptor table?) and these pointers point to a file somewhere in memory.

Do socket descriptors share this array with file descriptors, but the pointer instead refers to a socket. Or is there something else that’s only used for sockets?

Is this array unique to every application/process?

3 Answers 3

Yes, sockets are also indices into the same table as files. At least for UNIX systems (like Linux and OSX), Windows is different, which is why you can’t use e.g. read and write to receive and send data.

Each process has its own «file» descriptor table.

Socket is nothing but a file in UNIX operating system. Even everything is treated as a file in UNIX Operating system. Whenever we create a socket an entry is made in the file descriptor table which contains standard i/o and standard errors and other details. The file descriptor acts as a pointer to the File Table which contains information about what action is to be taken i.e read, write, etc, and it contains pointers to the inode table of that particular file and as you might know inode contains all the necessary deatils of a file.

Сокеты Беркли

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

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

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

API Интерфейса транспортного уровня (TLI), основанный на STREAMS, представляет собой альтернативу сокетному API. Тем не менее, API сокетов Беркли значительно преобладает в популярности и количестве реализаций.

Содержание

Интерфейс сокета Беркли

Интерфейс сокета Беркли — API, позволяющий реализацию взаимодействия между компьютерами или между процессами на одном компьютере. Данная технология может работать со множеством различных устройств ввода/вывода и драйверов, несмотря на то, что их поддержка зависит от реализации операционной системы. Подобная реализация интерфейса лежит в основе TCP/IP, благодаря чему считается одной из фундаментальных технологий, на которых основывается Интернет. Технология сокетов впервые была разработана в Калифорнийском университете Беркли для применения на Юникс-системах. Все современные операционные системы имеют ту или иную реализацию интерфейса сокетов Беркли, так как это стало стандартным интерфейсом для подключения к сети Интернет.

Программисты могут получать доступ к интерфейсу сокетов на трёх различных уровнях, наиболее мощным и фундаментальным из которых является уровень сырых сокетов. Довольно небольшое число приложений нуждается в ограничении контроля над исходящими соединениями, реализуемыми ими, поэтому поддержка сырых сокетов задумывалась быть доступной только на компьютерах, применяемых для разработки на основе технологий, связанных с Интернет. Впоследствии, в большинстве операционных систем была реализована их поддержка, включая Windows XP.

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

Программная библиотека сокетов Беркли включает в себя множество связанных заголовочных файлов. В их числе:

<sys/socket.h> Базовые функции сокетов BSD и структуры данных. <netinet/in.h> Семейства адресов/протоколов PF_INET и PF_INET6. Широко используются в сети Интернет, включают в себя IP-адреса, а также номера портов TCP и UDP. <sys/un.h> Семейство адресов PF_UNIX/PF_LOCAL. Используется для локального взаимодействия между программами, запущенными на одном компьютере. В компьютерных сетях не применяется. <arpa/inet.h> Функции для работы с числовыми IP-адресами. <netdb.h> Функции для преобразования протокольных имен и имен хостов в числовые адреса. Используется локальные данные аналогично DNS.

Структуры

• sockaddr  — обобщённая структура адреса, к которой, в зависимости от используемого семейства протоколов, приводится соответствующая структура, например:

• sockaddr_in
• sockaddr_in6
• in_addr
• in6_addr

Функции

socket()

socket() создаёт конечную точку соединения и возвращает дескриптор. socket() принимает три аргумента:

• domain , указывающий семейство протоколов создаваемого сокета. Например:
  • PF_INET для сетевого протокола IPv4 или
  • PF_INET6 для IPv6.
  • PF_UNIX для локальных сокетов (используя файл).
  • SOCK_STREAM (надёжная потокоориентированная служба (сервис) или потоковый сокет)
  • SOCK_DGRAM (служба датаграмм или датаграммный сокет)
  • SOCK_SEQPACKET (надёжная служба последовательных пакетов) или
  • SOCK_RAW (Сырой сокет — сырой протокол поверх сетевого уровня).

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

  Прототип

  gethostbyname() и gethostbyaddr()

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

  • name , определяющий имя хоста. Например: www.wikipedia.org
  • addr , определяющий указатель на struct in_addr , содержащую адрес хоста.
  • len , определяющий длину в байтах addr .
  • type , определяющий тип области адресов хоста. Например: PF_INET

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

  Прототипы

  connect()

  connect() Возвращает целое число, представляющее код ошибки: 0 означает успешное выполнение, а −1 свидетельствует об ошибке.

  Некоторые типы сокетов работают без установления соединения, это в основном касается UDP-сокетов. Для них соединение приобретает особое значение: цель по умолчанию для посылки и получения данных присваивается переданному адресу, позволяя использовать такие функции как send() и recv() на сокетах без установления соединения.

  Загруженный сервер может отвергнуть попытку соединения, поэтому в некоторых видах программ необходимо предусмотреть повторные попытки соединения.

  Прототип

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

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

  Возвращает 0 при успехе и −1 при возникновении ошибки.

  Прототип

  listen()

  listen() подготавливает привязываемый сокет к принятию входящих соединений. Данная функция применима только к типам сокетов SOCK_STREAM и SOCK_SEQPACKET . Принимает два аргумента:

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

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

  Прототип

  accept()

  accept() используется для принятия запроса на установление соединения от удаленного хоста. Принимает следующие аргументы:

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

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

  Прототип

  Дополнительные параметры для сокетов

  После создания сокета можно задавать для него дополнительные параметры. Вот некоторые из них:

  • TCP_NODELAY отключает алгоритм Нэгла (англ.  Nagle’s_algorithm)
  • SO_KEEPALIVE включает периодические проверки на наличие ‘признаков жизни’, если это поддерживается ОС.

  Блокирующие и неблокирующие сокеты

  Сокеты Беркли могут работать в одном из двух режимов: блокирующем или неблокирующем. Блокирующий сокет не возвращает контроль пока не отошлет (или пока не получит) все данные, указанные для операции. Это верно лишь для Linux-систем. В других системах, например во FreeBSD, вполне естественно для блокирующего сокета посылать не все данные. Приложение должно проверять возвращаемое значение для отслеживания того, сколько байт было послано/получено и, соответственно, перепосылать необработанную на данный момент информацию [1]. Это может привести к проблемам, если сокет продолжает «слушать»: программа может повиснуть из-за того, что сокет ждет данных, которые могут никогда не прибыть.

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

  Передача данных

  Для передачи данных можно пользоваться стандартными функциями чтения/записи файлов read и write , но есть специальные функции для передачи данных через сокеты:

  • send
  • recv
  • sendto
  • recvfrom
  • sendmsg
  • recvmsg

  Нужно обратить внимание, что при использовании протокола TCP (сокеты типа SOCK_STREAM ) есть вероятность получить меньше данных, чем было передано, так как ещё не все данные были переданы, поэтому нужно либо дождаться, когда функция recv возвратит 0 байт, либо выставить флаг MSG_WAITALL для функции recv , что заставит её дождаться окончания передачи. Для остальных типов сокетов флаг MSG_WAITALL ничего не меняет (например, в UDP весь пакет = целое сообщение). Смотри также главу «Блокирующие и неблокирующие сокеты».

  Высвобождение ресурсов

  Система не освобождает ресурсы, выделенные при вызове socket() , пока не произойдет вызова close() . Это особенно важно в случае, если вызов connect() прошёл неудачно и может быть повторен. Каждый вызов socket() должен иметь соответствующий вызов close() во всех возможных путях исполнения. Необходимо добавлять заголовочный файл <unistd.h> для поддержки функции закрытия.

  Результатом выполнения системного вызова close() является только обращение к интерфейсу для закрытия сокета, а не закрытие самого сокета. Это является командой для ядра закрыть сокет. Иногда, на серверной стороне сокет может перейти в режим ожидания TIME_WAIT до 4 минут.[2]

  Пример клиента и сервера, использующих TCP

  TCP реализует концепцию соединения. Процесс создаёт TCP-сокет вызовом функции socket() с параметрами PF INET или PF_INET6 , а также SOCK_STREAM (Потоковый сокет) и IPPROTO_TCP .

  Сервер

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

  • Создание TCP-сокетов вызовом функции socket() .
  • Привязывание сокета к прослушиваемому порту вызовом функции bind() . Перед вызовом bind() программист должен объявить структуру sockaddr_in , очистить её (при помощи memset() ), затем sin_family ( PF_INET или PF_INET6 ) и заполнить поля sin_port (прослушиваемый порт, указать в виде последовательности байтов). Преобразование short int в порядок байтов может быть выполнено при помощи вызова функции htons() (сокращение от «от хоста в сеть»).
  • Подготовка сокета к прослушиванию на предмет соединений (создание прослушиваемого сокета) при помощи вызова listen() .
  • Принятие входящих соединений через вызов accept() . Это блокирует сокет до получения входящего соединения, после чего возвращает дескриптор сокета для принятого соединения. Первоначальный дескриптор остаётся прослушиваемым дескриптором, а accept() может быть вызван вновь для этого сокета в любое время (пока он закрыт).
  • Соединение с удаленным хостом, которое может быть создано при помощи send() и recv() или write() и read() .
  • Итоговое закрытие каждого открытого сокета, который больше не нужен, происходит при помощи close() . Необходимо отметить, что если были любые вызовы fork() , то каждый процесс должен закрыть известные ему сокеты (ядро отслеживает количество процессов, имеющих открытый дескриптор), а кроме того, два процесса не должны использовать один и тот же сокет в одно время.

  Клиент

  Создание TCP-клиента происходит следующим образом:

  • Создание TCP-сокета вызовом socket() .
  • Соединение с сервером при помощи connect() , передача структуры sockaddr_in с sin_family с указанными PF_INET или PF_INET6 , sin_port для указания порта прослушивания (в байтовом порядке), и sin_addr для указания IPv4 или IPv6 адреса прослушиваемого сервера (также в байтовом порядке).
  • Взаимодействие с сервером при помощи send() и recv() или write() и read() .
  • Завершение соединения и сброс информации при вызове close() . Аналогично, если были какие-либо вызовы fork() , каждый процесс должен закрыть ( close() ) сокет.

  Пример клиента и сервера, использующие UDP

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

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

  Сервер

  Код может создавать UDP-сервер на порту 7654 следующим образом:

  bind() связывает сокет с парой адрес/порт.

  Такой бесконечный цикл получает все UDP-датаграммы, приходящие на порт 7654, при помощи recvfrom(). Функция использует параметры:

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

  Клиент

  Простейшая демонстрация отправки UDP-пакета, содержащего «Привет!» на адрес 127.0.0.1 порт 7654 выглядит примерно так:

  См. также

  Ссылки

  Определение стандарта «де юре» интерфейса сокетов, содержащееся в стандарте POSIX, более известное как:

  • IEEE Std. 1003.1-2001 Standard for Information Technology — Portable Operating System Interface (POSIX).
  • Open Group Technical Standard: Base Specifications, Issue 6, December 2001.
  • ISO/IEC 9945:2002  — информация об этих стандартах, а также о текущей работе над ними.
  • RFC3493 и RFC3542 — описание IPv6-расширения базового API сокетов.
  • API
  • Межпроцессное взаимодействие

  Wikimedia Foundation . 2010 .

  Полезное

  Смотреть что такое «Сокеты Беркли» в других словарях:

  Сокет (программный интерфейс) — У этого термина существуют и другие значения, см. Сокет. Сокеты (англ. socket углубление, гнездо, разъём) название программного интерфейса для обеспечения обмена данными между процессами. Процессы при таком обмене могут исполняться как на… … Википедия

  Программирование сетевых задач — В области компьютеризации понятие программирования сетевых задач или иначе называемого сетевого программирования (англ. network programming), довольно сильно схожего с понятиями программирование сокетов и клиент серверное программирование,… … Википедия

  Unix domain socket — (Доменный сокет Unix) или IPC сокет (сокет межпроцессного взаимодействия) конечная точка обмена данными, схожая с Интернет сокетом, но не использующая сетевой протокол для взаимодействия (обмена данными). Он используется в операционных системах,… … Википедия

  Сырой сокет — интерфейс программирования приложений (API), разновидность сокетов Беркли, позволяющий собирать TCP/IP пакеты, контролируя каждый бит заголовка и отправляя в сеть нестандартные пакеты. Пример Создание сокета. Код на языке Си . int i32SocketFD … Википедия

  UNIX — Генеалогическое древо UNIX систем UNIX (читается юникс) семейство переносимых, многозадачных и многопользовательских … Википедия

  UX — Генеалогическое древо UNIX систем UNIX (читается юникс) группа переносимых, многозадачных и многопользовательских операционных систем. Первая система UNIX была разработана в 1969 г. в подразделении Bell Labs компании AT T. С тех пор было создано … Википедия

  Unix — Генеалогическое древо UNIX систем UNIX (читается юникс) группа переносимых, многозадачных и многопользовательских операционных систем. Первая система UNIX была разработана в 1969 г. в подразделении Bell Labs компании AT T. С тех пор было создано … Википедия

  ЮНИКС — Генеалогическое древо UNIX систем UNIX (читается юникс) группа переносимых, многозадачных и многопользовательских операционных систем. Первая система UNIX была разработана в 1969 г. в подразделении Bell Labs компании AT T. С тех пор было создано … Википедия

  Юникс — Генеалогическое древо UNIX систем UNIX (читается юникс) группа переносимых, многозадачных и многопользовательских операционных систем. Первая система UNIX была разработана в 1969 г. в подразделении Bell Labs компании AT T. С тех пор было создано … Википедия

  Интерфейс транспортного уровня — В области проектирования компьютерных сетей Интерфейс транспортного уровня (от англ. Transport Layer Interface) (TLI) был сетевым API, поддерживаемым AT T UNIX System V Release 3 (SVR3) и Release 4 (SVR4). TLI был двойником (но в System V)… … Википедия