Что такое сокет? Программирование сокетов на Java

Последнее обновление: 31.10.2015

В основе межсетевых взаимодействий по протоколам TCP и UDP лежат сокеты. В.NET сокеты представлены классом System.NET.Sockets.Socket , который предоставляет низкоуровневый интерфейс для приема и отправки сообщений по сети.

Рассмотрим основные свойства данного класса:

AddressFamily: возвращает все адреса, используемые сокетом. Данное свойство представляет одно из значений, определенных в одноименном перечислении AddressFamily . Перечисление содержит 18 различных значений, наиболее используемые:

• InterNetwork: адрес по протоколу IPv4

  InterNetworkV6: адрес по протоколу IPv6

  Ipx: адрес IPX или SPX

  NetBios: адрес NetBios

Available: возвращает объем данных, которые доступны для чтения

Connected: возвращает true, если сокет подключен к удаленному хосту

LocalEndPoint: возвращает локальную точку, по которой запущен сокет и по которой он принимает данные

ProtocolType: возвращает одно из значений перечисления ProtocolType , представляющее используемый сокетом протокол. Есть следующие возможные значения:

• IPSecAuthenticationHeader (Заголовок IPv6 AH)

  IPSecEncapsulatingSecurityPayload (Заголовок IPv6 ESP)

  IPv6DestinationOptions (Заголовок IPv6 Destination Options)

  IPv6FragmentHeader (Заголовок IPv6 Fragment)

  IPv6HopByHopOptions (Заголовок IPv6 Hop by Hop Options)

  IPv6NoNextHeader (Заголовок IPv6 No next)

  IPv6RoutingHeader (Заголовок IPv6 Routing)

  Unknown (неизвестный протокол)

  Unspecified (неуказанный протокол)

Каждое значение представляет соответствующий протокол, но наиболее используемыми являются Tcp и Udp.

RemoteEndPoint: возвращает адрес удаленного хоста, к которому подключен сокет

SocketType: возвращает тип сокета. Представляет одно из значений из перечисления SocketType :

• Dgram: сокет будет получать и отправлять дейтаграммы по протоколу Udp. Данный тип сокета работает в связке с типом протокола - Udp и значением AddressFamily.InterNetwork

  Raw: сокет имеет доступ к нижележащему протоколу транспортного уровня и может использовать для передачи сообщений такие протоколы, как ICMP и IGMP

  Rdm: сокет может взаимодействовать с удаленными хостами без установки постоянного подключения. В случае, если отправленные сокетом сообщения невозможно доставить, то сокет получит об этом уведомление

  Seqpacket: обеспечивает надежную двустороннюю передачу данных с установкой постоянного подключения

  Stream: обеспечивает надежную двустороннюю передачу данных с установкой постоянного подключения. Для связи используется протокол TCP, поэтому этот тип сокета используется в паре с типом протокола Tcp и значением AddressFamily.InterNetwork

  Unknown: адрес NetBios

Для создания объекта сокета можно использовать один из его конструкторов. Например, сокет, использующий протокол Tcp:

Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);

Или сокет, использующий протокол Udp:

Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);

Таким образом, при создании сокета мы можем указывать разные комбинации протоколов, типов сокета, значений из перечисления AddressFamily. Однако в то же время не все комбинации являются корректными. Так, для работы через протокол Tcp, нам надо обязательно указать параметры: AddressFamily.InterNetwork, SocketType.Stream и ProtocolType.Tcp. Для Udp набор параметров будет другим: AddressFamily.InterNetwork, SocketType.Dgram и ProtocolType.Udp. Для других протоколов набор значений будет отличаться. Поэтому использование сокетов может потребовать некоторого знания принципов работы отдельных протоколов. Хотя в отношении Tcp и Udp все относительно просто.

Общий принцип работы сокетов

При работе с сокетами вне зависимости от выбранных протоколов мы будем опираться на методы класса Socket:

Accept() : создает новый объект Socket для обработки входящего подключения

Bind() : связывает объект Socket с локальной конечной точкой

Close() : закрывает сокет

Connect() : устанавливает соединение с удаленным хостом

Listen() : начинает прослушивание входящих запросов

Poll() : определяет состояние сокета

Receive() : получает данные

Send() : отправляет данные

Shutdown() : блокирует на сокете прием и отправку данных

В зависимости от применяемого протокола (TCP, UDP и т.д.) общий принцип работы с сокетами будет немного различаться.

При применении протокола, который требует установление соединения, например, TCP, сервер должен вызвать метод Bind для установки точки для прослушивания входящих подключений и затем запустить прослушивание подключений с помощью метода Listen. Далее с помощью метода Accept можно получить входящие запросы на подключение в виде объекта Socket, который используется для взаимодействия с удаленным узла. У полученного объекта Socket вызываются методы Send и Receive соответственно для отправки и получения данных. Если необходимо подключиться к серверу, то вызывается метод Connect. Для обмена данными с сервером также применяются методы Send или Receive.

Если применяется протокол, для которого не требуется установление соединения, например, UDP, то после вызова метода Bind не надо вызывать метод Listen. И в этом случае для приема данных используется метод ReceiveFrom, а для отправки данных - метод SendTo.

интерфейс сетевых системных вызовов ( socket() , bind() , recvfrom() , sendto() и т. д.) в операционной системе UNIX может применяться и для других стеков протоколов (и для протоколов, лежащих ниже транспортного уровня ).

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

Второй параметр служит для задания вида интерфейса работы с сокетом – будет это потоковый сокет , сокет для работы с датаграммами или какой-либо иной. Третий параметр указывает протокол для заданного типа интерфейса. В стеке протоколов TCP/IP существует только один протокол для потоковых сокетов – TCP и только один протокол для датаграммных сокетов – UDP , поэтому для транспортных протоколов TCP/IP третий параметр игнорируется.

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

Для транспортных протоколов TCP/IP мы всегда в качестве первого параметра будем указывать предопределенную константу AF_INET (Address family – Internet ) или ее синоним PF_INET ( Protocol family – Internet ).

Второй параметр будет принимать предопределенные значения SOCK_STREAM для потоковых сокетов и SOCK_DGRAM – для датаграммных.

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

Ссылка на информацию о созданном сокете помещается в таблицу открытых файлов процесса подобно тому, как это делалось для pip ’ов и FIFO (см. семинар 5). Системный вызов возвращает пользователю файловый дескриптор , соответствующий заполненному элементу таблицы, который далее мы будем называть дескриптором сокета . Такой способ хранения информации о сокете позволяет, во-первых, процессам-детям наследовать ее от процессов-родителей, а, во-вторых, использовать для сокетов часть системных вызовов, которые уже знакомы нам по работе с pip ’ами и FIFO : close() , read() , write() .

Системный вызов для создания сокета Прототип системного вызова #include #include int socket(int domain, int type, int protocol); Описание системного вызова Системный вызов socket служит для создания виртуального коммуникационного узла в операционной системе. Данное описание не является полным описанием системного вызова, а предназначено только для использования в нашем курсе. За полной информацией обращайтесь к UNIX Manual. Параметр domain определяет семейство протоколов, в рамках которого будет осуществляться передача информации. Мы рассмотрим только два таких семейства из нескольких существующих. Для них имеются предопределенные значения параметра: PF_INET – для семейства протоколов TCP/IP ; PF_UNIX – для семейства внутренних протоколов UNIX, иначе называемого еще UNIX domain. Параметр type определяет семантику обмена информацией: будет ли осуществляться связь через сообщения (datagrams), с помощью установления виртуального соединения или еще каким-либо способом. Мы будем пользоваться только двумя способами обмена информацией с предопределенными значениями для параметра type : SOCK_STREAM – для связи с помощью установления виртуального соединения ; SOCK_DGRAM – для обмена информацией через сообщения. Параметр protocol специфицирует конкретный протокол для выбранного семейства протоколов и способа обмена информацией. Он имеет значение только в том случае, когда таких протоколов существует несколько. В нашем случае семейство протоколов и тип обмена информацией определяют протокол однозначно. Поэтому данный параметр мы будем полагать равным 0 . Возвращаемое значение В случае успешного завершения системный вызов возвращает файловый дескриптор (значение большее или равное 0 ), который будет использоваться как ссылка на созданный коммуникационный узел при всех дальнейших сетевых вызовах. При возникновении какой-либо ошибки возвращается отрицательное значение.

Адреса сокетов. Настройка адреса сокета. Системный вызов bind()

Когда сокет создан, необходимо настроить его адрес . Для этого используется системный вызов bind() . Первый параметр вызова должен содержать дескриптор сокета , для которого производится настройка адреса. Второй и третий параметры задают этот адрес .

Во втором параметре должен быть указатель на структуру struct sockaddr , содержащую удаленную и локальные части полного адреса.

Указатели типа struct sockaddr * встречаются во многих сетевых системных вызовах; они используются для передачи информации о том, к какому адресу привязан или должен быть привязан сокет . Рассмотрим этот тип данных подробнее. Структура struct sockaddr описана в файле следующим образом:

struct sockaddr { short sa_family; char sa_data; };

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

Для работы с семейством протоколов TCP/IP мы будем использовать адрес сокета следующего вида, описанного в файле :

struct sockaddr _in{ short sin_family; /* Избранное семейство протоколов – всегда AF_INET */ unsigned short sin_port; /* 16-битовый номер порта в сетевом порядке байт */ struct in_addr sin_addr; /* Адрес сетевого интерфейса */ char sin_zero; /* Это поле не используется, но должно всегда быть заполнено нулями */ };

Первый элемент структуры – sin_family задает семейство протоколов . В него мы будем заносить уже известную нам предопределенную константу AF_INET (см. предыдущий раздел).

Удаленная часть полного адреса – IP-адрес – содержится в структуре типа struct in_addr , с которой мы встречались в разделе "Функции преобразования IP-адресов inet_ntoa() , inet_aton() " .

Для указания номера порта предназначен элемент структуры sin_port , в котором номер порта должен храниться в сетевом порядке байт . Существует два варианта задания номера порта : фиксированный порт по желанию пользователя и порт , который произвольно назначает операционная система . Первый вариант требует указания в качестве номера порта положительного заранее известного числа и для протокола UDP обычно используется при настройке адресов сокетов и при передаче информации с помощью системного вызова sendto() (см. следующий раздел). Второй вариант требует указания в качестве номера порта значения 0. В этом случае операционная система сама привязывает сокет к свободному номеру порта . Этот способ обычно используется при настройке сокетов программ клиентов, когда заранее точно знать номер порта программисту необязательно.

Какой номер порта может задействовать пользователь при фиксированной настройке? Номера портов с 1 по 1023 могут назначать сокетам только процессы, работающие с привилегиями системного администратора. Как правило, эти номера закреплены за системными сетевыми службами независимо от вида используемой операционной системы, для того чтобы пользовательские клиентские программы могли запрашивать обслуживание всегда по одним и тем же локальным адресам. Существует также ряд широко применяемых сетевых программ, которые запускают процессы с полномочиями обычных пользователей (например, X-Windows). Для таких программ корпорацией Internet по присвоению имен и номеров (

Сокеты

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

Первоначально сокеты были разработаны для UNIX в Калифорнийском университете в Беркли. В UNIX обеспечивающий связь метод ввода-вывода следует алгоритму open/read/write/close. Прежде чем ресурс использовать, его нужно открыть, задав соответствующие разрешения и другие параметры. Как только ресурс открыт, из него можно считывать или в него записывать данные. После использования ресурса пользователь должен вызывать метод Close(), чтобы подать сигнал операционной системе о завершении его работы с этим ресурсом.

Когда в операционную систему UNIX были добавлены средства межпроцессного взаимодействия (Inter-Process Communication, IPC) и сетевого обмена, был заимствован привычный шаблон ввода-вывода. Все ресурсы, открытые для связи, в UNIX и Windows идентифицируются дескрипторами. Эти дескрипторы, или описатели (handles) , могут указывать на файл, память или какой-либо другой канал связи, а фактически указывают на внутреннюю структуру данных, используемую операционной системой. Сокет, будучи таким же ресурсом, тоже представляется дескриптором. Следовательно, для сокетов жизнь дескриптора можно разделить на три фазы: открыть (создать) сокет, получить из сокета или отправить сокету и в конце концов закрыть сокет.

Интерфейс IPC для взаимодействия между разными процессами построен поверх методов ввода-вывода. Они облегчают для сокетов отправку и получение данных. Каждый целевой объект задается адресом сокета, следовательно, этот адрес можно указать в клиенте, чтобы установить соединение с целью.

Типы сокетов

Существуют два основных типа сокетов - потоковые сокеты и дейтаграммные.

Потоковые сокеты (stream socket)

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

Потоковый сокет гарантирует исправление ошибок, обрабатывает доставку и сохраняет последовательность данных. На него можно положиться в доставке упорядоченных, сдублированных данных. Потоковый сокет также подходит для передачи больших объемов данных, поскольку накладные расходы, связанные с установлением отдельного соединения для каждого отправляемого сообщения, может оказаться неприемлемым для небольших объемов данных. Потоковые сокеты достигают этого уровня качества за счет использования протокола Transmission Control Protocol (TCP) . TCP обеспечивает поступление данных на другую сторону в нужной последовательности и без ошибок.

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

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

Потоки базируются на явных соединениях: сокет А запрашивает соединение с сокетом В, а сокет В либо соглашается с запросом на установление соединения, либо отвергает его.

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

Сервер электронной почты представляет пример приложения, которое должно доставлять содержание в правильном порядке, без дублирования и пропусков. Потоковый сокет рассчитывает, что TCP обеспечит доставку сообщений по их назначениям.

Дейтаграммные сокеты (datagram socket)

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

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

Использование дейтаграммных сокетов требует, чтобы передачей данных от клиента к серверу занимался User Datagram Protocol (UDP) . В этом протоколе на размер сообщений налагаются некоторые ограничения, и в отличие от потоковых сокетов, умеющих надежно отправлять сообщения серверу-адресату, дейтаграммные сокеты надежность не обеспечивают. Если данные затерялись где-то в сети, сервер не сообщит об ошибках.

Кроме двух рассмотренных типов существует также обобщенная форма сокетов, которую называют необрабатываемыми или сырыми.

Сырые сокеты (raw socket)

Главная цель использования сырых сокетов состоит в обходе механизма, с помощью которого компьютер обрабатывает TCP/IP. Это достигается обеспечением специальной реализации стека TCP/IP, замещающей механизм, предоставленный стеком TCP/IP в ядре - пакет непосредственно передается приложению и, следовательно, обрабатывается гораздо эффективнее, чем при проходе через главный стек протоколов клиента.

По определению, сырой сокет - это сокет, который принимает пакеты, обходит уровни TCP и UDP в стеке TCP/IP и отправляет их непосредственно приложению.

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

Однако нечасто может потребоваться программа, работающая с сырыми сокетами. Если вы не пишете системное программное обеспечение или программу, аналогичную анализатору пакетов, вникать в такие детали не придется. Сырые сокеты главным образом используются при разработке специализированных низкоуровневых протокольных приложений. Например, такие разнообразные утилиты TCP/IP, как trace route, ping или arp, используют сырые сокеты.

Работа с сырыми сокетами требует солидного знания базовых протоколов TCP/UDP/IP.

Порты

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

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

За определенными службами номера портов зарезервированы - это широко известные номера портов, например порт 21, использующийся в FTP. Ваше приложение может пользоваться любым номером порта, который не был зарезервирован и пока не занят. Агентство Internet Assigned Numbers Authority (IANA) ведет перечень широко известных номеров портов.

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

Например, на стороне клиента, приложение должно знать адрес цели и номер порта. Отправляя запрос на соединение, клиент пытается установить соединение с сервером:

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

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

Работа с сокетами в.NET

Поддержку сокетов в.NET обеспечивают классы в пространстве имен System.Net.Sockets - начнем с их краткого описания.

Классы для работы с сокетами

Класс	Описание
MulticastOption	Класс MulticastOption устанавливает значение IP-адреса для присоединения к IP-группе или для выхода из нее.
NetworkStream	Класс NetworkStream реализует базовый класс потока, из которого данные отправляются и в котором они получаются. Это абстракция высокого уровня, представляющая соединение с каналом связи TCP/IP.
TcpClient	Класс TcpClient строится на классе Socket, чтобы обеспечить TCP-обслуживание на более высоком уровне. TcpClient предоставляет несколько методов для отправки и получения данных через сеть.
TcpListener	Этот класс также построен на низкоуровневом классе Socket. Его основное назначение - серверные приложения. Он ожидает входящие запросы на соединения от клиентов и уведомляет приложение о любых соединениях.
UdpClient	UDP - это протокол, не организующий соединение, следовательно, для реализации UDP-обслуживания в.NET требуется другая функциональность.
SocketException	Это исключение порождается, когда в сокете возникает ошибка.
Socket	Последний класс в пространстве имен System.Net.Sockets - это сам класс Socket. Он обеспечивает базовую функциональность приложения сокета.

Класс Socket

Класс Socket играет важную роль в сетевом программировании, обеспечивая функционирование как клиента, так и сервера. Главным образом, вызовы методов этого класса выполняют необходимые проверки, связанные с безопасностью, в том числе проверяют разрешения системы безопасности, после чего они переправляются к аналогам этих методов в Windows Sockets API.

Прежде чем обращаться к примеру использования класса Socket, рассмотрим некоторые важные свойства и методы этого класса:

Свойства и методы класса Socket

Свойство или метод	Описание
AddressFamily	Дает семейство адресов сокета - значение из перечисления Socket.AddressFamily.
Available	Возвращает объем доступных для чтения данных.
Blocking	Дает или устанавливает значение, показывающее, находится ли сокет в блокирующем режиме.
Connected	Возвращает значение, информирующее, соединен ли сокет с удаленным хостом.
LocalEndPoint	Дает локальную конечную точку.
ProtocolType	Дает тип протокола сокета.
RemoteEndPoint	Дает удаленную конечную точку сокета.
SocketType	Дает тип сокета.
Accept()	Создает новый сокет для обработки входящего запроса на соединение.
Bind()	Связывает сокет с локальной конечной точкой для ожидания входящих запросов на соединение.
Close()	Заставляет сокет закрыться.
Connect()	Устанавливает соединение с удаленным хостом.
GetSocketOption()	Возвращает значение SocketOption.
IOControl()	Устанавливает для сокета низкоуровневые режимы работы. Этот метод обеспечивает низкоуровневый доступ к лежащему в основе классу Socket.
Listen()	Помещает сокет в режим прослушивания (ожидания). Этот метод предназначен только для серверных приложений.
Receive()	Получает данные от соединенного сокета.
Poll()	Определяет статус сокета.
Select()	Проверяет статус одного или нескольких сокетов.
Send()	Отправляет данные соединенному сокету.
SetSocketOption()	Устанавливает опцию сокета.
Shutdown()	Запрещает операции отправки и получения данных на сокете.

Что такое сокет?

Вы постоянно слышите разговоры о каких-то "сокетах" и, наверно, вам интересно, что же это такое. В общем, изначально сокеты - это способ общения программ друг с другом, используя файловые дескрипторы Unix.

Ок -- возможно, вы слышали от какого-нибуть Unix-хакера фразу типа "господи, всё, что есть в Unix - файлы!" Этот человек, возможно, имел в виду, что программы в Unix при абсолютно любом вводе-выводе читают или пишут в файловый дескриптор. Дескриптор файла - это простое целое число, связанное операционной системой с открытым файлов. Но (и в этом заключается ловушка) файлом может быть и сетевое подключение, и FIFO, и пайпы, и терминал, и реальный файл на диске, и просто что угодно другое. Всё в UNIX - это файл! Итак, просто поверьте, что собираясь общаться с другой программой через интернет, вам придется делать это через дескриптор файла.

"Эй, умник, а откуда мне взять этот дескриптор файла для работы в сети?" Отвечу.
Вы совершаете системный вызов socket(). Он возвращает дескриптор сокета, и вы общаетесь через него с помощью системных вызовов send() и recv() (man send, man recv).

"Но, эй!" могли бы вы воскликнуть. "Если это дескриптор файла, почему я не могу использовать простые функции read() и write(), чтобы общаться через него?". Ответ прост: "Вы можете!". Немного развернутый ответ: "Вы можете, но send() и recv() предлагают гораздо больший контроль над передачей ваших данных."

Что дальше? Как насчет этого: бывают разные виды сокетов. Есть DARPA инернет-адреса (Сокеты интернет), CCITT X.25 адреса (X.25 сокеты, которые вам не нужны), и, вероятно, многие другие в зависимости от особенностей вашей ОС. Этот документ описывает только первые, Интернет-Сокеты.

Два типа интернет-сокетов

Что? Есть два типа интернет сокетов? Да. Ну ладно, нет, я вру. Есть больше, но я не хочу вас пугать. Есть ещё raw-сокеты, очень мощная штука, вам стоит взглянуть на них.

Ну ладно. Какие два типа? Один из них - "потоковый сокет", второй - "сокет дейтаграмм", в дальнейшем они будут называться "SOCK_STREAM" и "SOCK_DGRAM" соответственно. Дейтаграммные сокеты иногда называют "сокетами без соединения" (хотя они могут и connect()`иться, если вам этого действительно захочется. См. connect() ниже.)

Потоковые сокеты обеспечивают надёжность своей двусторонней системой коммуникации. Если вы отправите в сокет два элемента в порядке "1, 2", они и "собеседнику" придут в том же порядке - "1, 2". Кроме того, обеспечивается защита от ошибок.

Что использует потоковые сокеты? Ну, вы наверно слышали о программе Telnet, да? Телнет использует потоковый сокет. Все символы, которые вы печатаете, должны прибыть на другой конец в том же порядке, верно? Кроме того, браузеры используют протокол HTTP, который в свою очередь использует потоковые сокеты для получения страниц. Если вы зайдёте телнетом на любой сайт, на порт 80 и наберёте что-то вроде "GET / HTTP/1.0" и нажмете ввод два раза, на вас свалится куча HTML ;)

Как потоковые сокеты достигают высокого уровня качества передачи данных? Они используют протокол под названием "The Transmission Control Protocol", иначе - "TCP". TCP гарантирует, что ваши данные передаются последовательно и без ошибок. Возможно, ранее вы слышали о TCP как о половине от "TCP/IP", где IP - это "Internet Protocol". IP имеет дело в первую очередь с маршрутизацей в Интернете и сам по себе не отвечает за целостность данных.

Круто. А что насчёт дейтаграммных сокетов? Почему они называются без-соединительными? В чем тут дело? Почему они ненадежны?
Ну, вот некоторые факты: если вы посылаете дейтаграмму, она может дойти. А может и не дойти. Но если уж приходит, то данные внутри пакета будут без ошибок.

Дейтаграммные сокеты также используют IP для роутинга, но не используют TCP; они используют "User Datagram Protocol", или "UDP".

Почему UDP не устанавливает соединения? Потому что вам не нужно держать открытое соединение с потоковыми сокетами. Вы просто строите пакет, формируете IP-заголовок с информацией о получателе, и посылаете пакет наружу. Устанавливать соединение нет необходимости. UDP как правило используется либо там, где стек TCP недоступен, либо там, где один-другой пропущеный пакет не приводит к концу света. Примеры приложений: TFTP (trivial file transfer protocol, младшый брат FTP), dhcpcd (DHCP клиент), сетевые игры, потоковое аудио, видео конференции и т.д.

"Подождите минутку! TFTP и DHCPcd используются для передачи бинарных данных с одного хоста на другой! Данные не могут быть потеряны, если вы хотите нормально с ними работать! Что это за темная магия?"

Нуу, мой человеческий друг, TFTP и подобные программы обычно строят свой собственный протокол поверх UDP. Например, TFTP протокол гласит, что для каждого принятого пакета получатель должен отправить обратно пакет, говорящий "я получил его!" ("ACK"-пакет). Если отправитель исходного пакета не получает ответ, скажем, в течение 5 секунд, он отправит пакет повторно, пока, наконец, не получит ACK. Подобные процедуры очень важны для реализации надёжных приложений, использующих SOCK_DGRAM.

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

Зачем вам может понадобиться использовать ненадежный базовый протокол? По двум причинам: скорость и скорость. Этот способ гораздо быстрее, выстрелил-и-забыл, чем постоянное слежение за тем, всё ли благополучно прибыло получателю. Если вы отправляете сообщение в чате, TCP великолепен, но если вы шлёте 40 позиционных обновлений персонажа в секунду, может быть, не так и важно, если один или два из них потеряются, и UDP тут будет неплохим выбором.

Теория сетей и низкие уровни

Поскольку я только что упоминал слои протоколов, пришло время поговорить о том, как на самом деле работает сеть, и показать примеры того, как построены пакеты SOCK_DGRAM. На самом деле вы можете пропустить этот раздел, но он является неплохим теоретическим подспорьем.

Эй, детишки, настало время поговорить об инкапсуляции данных! Это очень-очень важная вещь. Это настолько важно, что вам стоит выучить это наизусть.
В основном суть такова: пакет родился; пакет завёрнут ("инкапсулирован") в заголовок первым протоколом (скажем, протоколом TFTP), затем всё это (включая хидер TFTP) инкапсулируется вновь следующим протоколом (скажем, UDP), затем снова - следующим (например, IP), и наконец финальным, физическим протоколом (скажем, Ethernet).

Когда другой компьютер получает пакет, оборудование (сетевая карта) исключает Ethernet-заголовок (разворачивает пакет), ядро ОС исключает заголовки IP и UDP, программа TFTP исключает заголовок TFTP, и наконец мы получаем голые данные.

Теперь наконец можно поговорить о печально известной модели OSI - многоуровневой модели сети. Эта модель описывает систему сетевой функциональности, которая имеет много преимуществ по сравнению с другими моделями. Например, вы можете написать в своей программе как сокеты, которые шлют данные не заботясь о том, как физически передаются данные (серийный порт, эзернет, модем и т.д.), так как программы на более низких уровнях (ОС, драйверы) делают за вас всю работу, и представляют её прозрачно для программиста.

Собственно, вот все уровни полномасштабной модели:

• Прикладной


• Представительский


• Сеансовый


• Транспортный


• Сетевой


• Канальный


• Аппаратный (физический)

Физический уровень - это оборудование; ком-порт, сетевая карта, модем и т.д. Прикладной слой - дальше всех отстоит от физического. Это то место, где пользователь взаимодействует с сетью.

Для нас эта модель слишком общая и обширная. Сетевая модель, которую можем использовать мы, может выглядеть так:

• Уровень приложений (Telnet, FTP и т.д.)


• Транспортный протокол хост-хост (TCP, UDP)


• Интернет-уровень (IP и маршрутизация)


• Уровень доступа к сети (Ethernet, Wi-Fi или что угодно)

Теперь вы можете четко видеть, как эти слои соответствуют инкапсуляции исходных данных.

Видите, как много работы заключается в создании одного простого пакета? Офигеть! И все эти заголовки пакетов вы должны самостоятельно набирать в блокноте! Шучу. Всё, что вам нужно сделать в случае потоковых сокетов - это послать (send()) данные наружу. Ядро ОС построит TCP и IP хидеры, а оборудование возьмет на себя уровень доступа к сети. Ах, я люблю современные технологии.

На этом наш краткий экскурс в теорию сетей завершен. Ах да, я забыл вам сказать: всё, что я хотел вам сказать о маршрутизации: ничего! Да-да, я ничего не буду говорить об этом. О таблице маршрутизации за вас позаботятся ОС и IP-протокол. Если вам действительно интересно, почитайте документацию в интернете, её море.

ВСЕВОЛОД СТАХОВ

Программирование сокетов

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

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

int socket(int domain, int type, int protocol);

Параметр domain задаёт тип транспортного протокола, т.е. протокола доставки пакетов в сети. В настоящее время поддерживаются следующие протоколы (но учтите, что для разных типов протокола тип адресной структуры будет разный):

• PF_UNIX или PF_LOCAL – локальная коммуникация для ОС UNIX (и подобных).
• PF_INET – IPv4, IP -протокол Интернета, наиболее распространён сейчас (32-х битный адрес).
• PF_INET6 – IPv6, следующее поколение протокола IP (IPng) – 128 битный адрес.
• PF_IPX – IPX – протоколы Novell.

Поддерживаются и другие протоколы, но эти 4 являются самыми популярными.

Параметр type означает тип сокета, т.е. то, как будут передаваться данные: обычно применяется константа SOCK_STREAM, её использование означает безопасную передачу данных двунаправленным потоком с контролем ошибок. При таком способе передачи данных программисту не приходится заботиться об обработке ошибок сети, хотя это не уберегает от логических ошибок, что актуально для сетевого сервера.

Параметр protocol определяет конкретный тип протокола для данного domain, например IPPROTO_TCP или IPPROTO_UDP (параметр type должен в данном случае быть SOCK_DGRAM).

Функция socket просто создаёт конечную точку и возвращает дескриптор сокета; до того, как сокет не соединён с удалённым адресом функцией connect, данные через него пересылать нельзя! Если пакеты теряются в сети, т.е. произошло нарушение связи, то приложению, создавшему сокет, посылается сигнал Broken Pipe – SIGPIPE, поэтому целесообразно присвоить обработчик данному сигналу функцией signal. После того, как сокет соединён с другим функцией connect, по нему можно пересылать данные либо стандартными функциями read – write, либо специализированными recv – send. После окончания работы сокет надо закрыть функцией close. Для создания клиентского приложения достаточно связать локальный сокет с удалённым (серверным) функцией connect. Формат этой функции такой:

int connect(int sock_fd, const struct *sockaddr serv_addr, socketlen_t addr_len);

При ошибке функция возвращает -1, статус ошибки можно получить средствами операционной системы. При успешной работе возвращается 0. Сокет, однажды связанный, чаще всего не может быть связан снова, так, например, происходит в протоколе ip. Параметр sock_fd задаёт дескриптор сокета, структура serv_addr назначает удалённый адрес конечной точки, addr_len содержит длину serv_addr (тип socketlen_t имеет историческое происхождение, обычно он совпадает с типом int). Самый важный параметр в этой функции – адрес удалённого сокета. Он, естественно, неодинаков для разных протоколов, поэтому я опишу здесь структуру адреса только для IP (v4)-протокола. Для этого используется специализированная структура sockaddr_in (её необходимо прямо приводить к типу sockaddr при вызове connect). Поля данной структуры выглядят следующим образом:

struct sockaddr_in{

Sa_family_t sin_family; – определяет семейство адресов, всегда должно быть AF_INET

U_int16_t sin_port; – порт сокета в сетевом порядке байт

Struct in_addr sin_addr; – структура, содержащая IP-адрес

Структура, описывающая IP-адрес:

struct in_addr{

U_int32_t s_addr; – IP-адрес сокета в сетевом порядке байт

Обратите внимание на особый порядок байт во всех целых полях. Для перевода номера порта в сетевой порядок байт можно воспользоваться макросом htons (unsigned short port). Очень важно использовать именно этот тип целого – беззнаковое короткое целое.

Адреса IPv4 делятся на одиночные, широковещательные (broadcast) и групповые (multicast). Каждый одиночный адрес указывает на один интерфейс хоста, широковещательные адреса указывают на все хосты в сети, а групповые адреса соответствуют всем хостам в группе (multicast group). В структуре in_addr можно назначать любой из этих адресов. Но для сокетных клиентов в подавляющем большинстве случаев присваивают одиночный адрес. Исключением является тот случай, когда необходимо просканировать всю локальную сеть в поисках сервера, тогда можно использовать в качестве адреса широковещательный. Затем, скорее всего, сервер должен сообщить свой реальный IP-адрес и сокет для дальнейшей передачи данных должен присоединяться именно к нему. Передача данных через широковещательные адреса не есть хорошая идея, так как неизвестно, какой именно сервер обрабатывает запрос. Поэтому в настоящее время сокеты, ориентированные на соединение, могут использовать лишь одиночные адреса. Для сокетных серверов, ориентированных на прослушивание адреса, наблюдается другая ситуация: здесь разрешено использовать широковещательные адреса, чтобы сразу же ответить клиенту на запрос о местоположении сервера. Но обо всём по порядку. Как вы заметили, в структуре sockaddr_in поле IP-адреса представлено как беззнаковое длинное целое, а мы привыкли к адресам либо в формате x.x.x.x (172.16.163.89) либо в символьном формате (myhost.com). Для преобразования первого служит функция inet_addr (const char *ip_addr), а для второго – функция gethostbyname (const char *host). Рассмотрим обе из них:

u_int32_t inet_addr(const char *ip_addr)

– возвращает сразу же целое, пригодное для использования в структуре sockaddr_in по IP-адресу, переданному ей в формате x.x.x.x. При возникновении ошибки возвращается значение INADDR_NONE.

struct HOSTENT* gethostbyname(const char *host_name)

– возвращает структуру информации о хосте, исходя из его имени. В случае неудачи возвращает NULL. Поиск имени происходит вначале в файле hosts, а затем в DNS. Структура HOSTENT предоставляет информацию о требуемом хосте. Из всех её полей наиболее значительным является поле char **h_addr_list, представляющее список IP-адресов данного хоста. Обычно используется h_addr_list, представляющая первый ip адрес хоста, для этого можно также использовать выражение h_addr. После выполнения функции gethostbyname в списке h_addr_list структуры HOSTENT оказываются простые символические ip адреса, поэтому необходимо воспользоваться дополнительно функцией inet_addr для преобразования в формат sockaddr_in.

Итак, мы связали клиентский сокет с серверным функцией connect. Далее можно использовать функции передачи данных. Для этого можно использовать либо стандартные функции низкоуровневого ввода/вывода для файлов, так как сокет – это, по сути дела файловый дескриптор. К сожалению, для разных операционных систем функции низкоуровневой работы с файлами могут различаться, поэтому надо посмотреть руководство к своей операционной системе. Учтите, что передача данных по сети может закончиться сигналом SIGPIPE, и функции чтения/записи вернут ошибку. Всегда нужно помнить о проверке ошибок, кроме того, нельзя забывать о том, что передача данных по сети может быть очень медленной, а функции ввода/вывода являются синхронными, и это может вызвать существенные задержки в работе программы.

Для передачи данных между сокетами существуют специальные функции, единые для всех ОС – это функции семейства recv и send. Формат их очень похож:

int send(int sockfd, void *data, size_t len, int flags);

– отправляет буфер data.

int recv(int sockfd, void *data, size_t len, int flags);

– принимает буфер data.

Первый аргумент – дескриптор сокета, второй – указатель на данные для передачи, третий – длина буфера и четвёртый – флаги. В случае успеха возвращается число переданных байт, в случае неудачи – отрицательный код ошибки. Флаги позволяют изменить параметры передачи (например, включить асинхронный режим работы), но для большинства задач достаточно оставить поле флагов нулевым для обычного режима передачи. При отсылке или приёме данных функции блокируют выполнение программы до того, как будет отослан весь буфер. А при использовании протокола tcp/ip от удалённого сокета должен прийти ответ об успешной отправке или приёме данных, иначе пакет пересылается ещё раз. При пересылке данных учитывайте MTU сети (максимальный размер передаваемого за один раз кадра). Для разных сетей он может быть разным, например, для сети Ethernet он равен 1500.

Итак, для полноты изложения приведу самый простенький пример программы на Си, реализующей сокетного клиента:

#include /* Стандартные библиотеки сокетов для Linux */

#include /* Для ОС Windows используйте #include */

#include

int main(){

Int sockfd = -1;

/* Дескриптор сокета */

Char buf;

Char s = "Client ready ";

HOSTENT *h = NULL;

Sockaddr_in addr;

Unsigned short port = 80;

Addr.sin_family = AF_INET;

/* Создаём сокет */

If(sockfd == -1)

/* Создан ли сокет */

Return -1;

H = gethostbyname("www.myhost.com");

/* Получаем адрес хоста */

If(h == NULL)

/* А есть ли такой адрес? */

Return -1;

Addr.sin_addr.s_addr = inet_addr(h->h_addr_list);

/* Переводим ip адрес в число */

If(connect(sockfd, (sockaddr*) &addr, sizeof(addr)))

/* Пытаемся соединится с удалённым сокетом */

Return -1;

/* Соединение прошло успешно - продолжаем */

If(send(sockfd, s, sizeof(s), 0) < 0)

Return -1;

If(recv(sockfd, buf, sizeof(buf), 0) < 0)

Return -1;

Close(sockfd);

/* Закрываем сокет */

/* Для Windows применяется функция closesocket(s) */

Return 0;

Вот видите, использовать сокеты не так трудно. В серверных приложениях используются совершенно другие принципы работы с сокетами. Вначале создается сокет, затем ему присваивается локальный адрес функцией bind, при этом можно присвоить сокету широковещательный адрес. Затем начинается прослушивание адреса функцией listen, запросы на соединение помещаются в очередь. То есть функция listen выполняет инициализацию сокета для приёма сообщений. После этого нужно применить функцию accept, которая возвращает новый, уже связанный с клиентом сокет. Обычно для серверов характерно принимать много соединений через небольшие промежутки времени. Поэтому нужно постоянно проверять очередь входящих соединений функцией accept. Для организации такого поведения чаще всего прибегают к возможностям операционной системы. Для ОС Windows чаще используется многопоточный вариант работы сервера (multi-threaded), после принятия соединения происходит создание нового потока в программе, который и обрабатывает сокет. В *nix-системах чаще используется порождение дочернего процесса функцией fork. При этом накладные расходы уменьшены за счёт того, что фактически происходит копия процесса в файловой системе proc. При этом все переменные дочернего процесса совпадают с родителем. И дочерний процесс может сразу же обрабатывать входящее соединение. Родительский же процесс продолжает прослушивание. Учтите, что порты с номерами от 1 до 1024 являются привилегированными и их прослушивание не всегда возможно. Ещё один момент: нельзя, чтобы два разных сокета прослушивали один и тот же порт по одному и тому же адресу! Для начала рассмотрим форматы вышеописанных функций для создания серверного сокета:

int bind(int sockfd, const struct *sockaddr, socklen_t addr_len);

– присваивает сокету локальный адрес для обеспечения возможности принимать входящие соединения. Для адреса можно использовать константу INADDR_ANY, которая позволяет принимать входящие соединения со всех адресов в данной подсети. Формат функции аналогичен connect. В случае ошибки возвращает отрицательное значение.

int listen(int sockfd, int backlog);

– функция создаёт очередь входящих сокетов (количество подключений определяется параметром backlog, оно не должно превышать числа SOMAXCONN, которое зависит от ОС). После создания очереди можно ожидать соединения функцией accept. Сокеты обычно являются блокирующими, поэтому выполнение программы приостанавливается, пока соединение не будет принято. В случае ошибки возвращается -1.

int accept(int sockfd, struct *sockaddr, socklen_t addr_len)

– функция дожидается входящего соединения (или извлекает его из очереди соединений) и возвращает новый сокет, уже связанный с удалённым клиентом. При этом исходный сокет sockfd остается в неизменном состоянии. Структура sockaddr заполняется значениями из удалённого сокета. В случае ошибки возвращается -1.

Итак, приведу пример простого сокетного сервера, использующего функцию fork для создания дочернего процесса, обрабатывающего соединение:

int main(){

Pid_t pid;

/* Идентификатор дочернего процесса */

Int sockfd = -1;

/* Дескриптор сокета для прослушивания */

Int s = -1;

/* Дескриптор сокета для приёма */

Char buf;

/* Указатель на буфер для приёма */

Char str = "Server ready ";

/* Строка для передачи серверу */

HOSTENT *h = NULL;

/* Структура для получения ip адреса */

Sockaddr_in addr;

/* Cтруктура tcp/ip протокола */

Sockaddr_in raddr;

Unsigned short port = 80;

/* Заполняем поля структуры: */

Addr.sin_family = AF_INET;

Addr.sin_port = htons(port);

sockfd = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);

/* Создаём сокет */

If(sockfd == -1)

/* Создан ли сокет */

Return -1;

Addr.sin_addr.s_addr = INADDR_ANY;

/* Слушаем на всех адресах */

If(bind(sockfd, (sockaddr*) &addr, sizeof(addr)))

/* Присваиваем сокету локальный адрес */

Return -1;

If(listen(sockfd, 1))

/* Начинаем прослушивание */

Return -1;

S = accept(sockfd, (sockaddr *) &raddr, sizeof(raddr));

/* Принимаем соединение */

Pid = fork();

/* порождаем дочерний процесс */

If(pid == 0){

/* Это дочерний процесс */

If(recv(s, buf, sizeof(buf), 0) < 0)

/* Посылаем удалённому сокету строку s */

Return -1;

If(send(s, str, sizeof(str), 0) < 0)

/* Получаем ответ от удалённого сервера */

Return -1;

Printf("Recieved string was: %s", buf);

/* Вывод буфера на стандартный вывод */

Close(s);

/* Закрываем сокет */

Return 0;

/* Выходим из дочернего процесса */

Close(sockfd);

/* Закрываем сокет для прослушивания */

Return 0;

При создании потока (thread) для обработки сокета смотрите руководство к ОС, так как для разных систем вызов функции создания потока может существенно различаться. Но принципы обработки для потока остаются теми же. Функции обработки необходимо только передать в качестве аргумента указатель на сокет (обычно в функцию потока можно передавать данные любого типа в формате void *, что требует использования приведения типов).

Важное замечание для систем Windows. Мною было замечено, что система сокетов не работает без применения функции WSAStartup для инициализации библиотеки сокетов. Программа с сокетами в ОС Windows должна начинаться так:

WSADATA wsaData;

WSAStartup(0x0101, &wsaData);

И при выходе из программы пропишите следующее:

WSACleanup();

Так как в основном операции с сокетами являются блокирующими, приходится часто прерывать исполнение задачи ожиданием синхронизации. Поэтому часто в *nix-подобных системах избегают блокировки консоли созданием особого типа программы – демона. Демон не принадлежит виртуальным консолям и возникает, когда дочерний процесс вызывает fork, а родительский процесс завершается раньше, чем 2-й дочерний (а это всегда бывает именно таким образом). После этого 2-й дочерний процесс становится основным и не блокирует консоль. Приведу пример такого поведения программы:

pid = fork();

/* Создание первого дочернего процесса */

if (pid <0){

/* Ошибка вызова fork */

Printf("Forking Error:) ");

Exit(-1);

}else if (pid !=0){

/* Это первый родитель! */

Printf(" This is a Father 1 ");

}else{

Pid = fork();

/* Работа 1-го родителя завершается */

/* И мы вызываем ещё один дочерний процесс */

If (pid <0){

Printf("Forking error:) ");

Exit(-1);

}else if (pid !=0){

/* Это второй родитель */

Printf(" This is a father 2 ");

}else{

/* А вот это тот самый 2-й дочерний процесс*/

/* Переход в "стандартный" режим демона */

Setsid();

/* Выполняем демон в режиме superuser */

Umask(0); /* Стандартная маска файлов */

Chdir("/"); /* Переход в корневой каталог */

Daemoncode(); /* Собственно сам код демона */

/* При вызове fork демона появляется потомок-демон */

Вот и всё. Я думаю, для создания простенького сокетного сервера этого достаточно.