Как подключиться к сокету через интернет

Обновлено: 30.06.2024

есть ли способ сделать чистое соединение сокета из веб-браузера, чтобы оживить веб-страницы?

вот мои случайные удары в темноте

апплеты сокеты, предоставляемые Java (требуется java установлен)
Флэш-сокеты обеспечивается с помощью флэш (нужен Flash установлено)

но о HTML5, почему они называются WebSockets, если они не являются сокетами?

является ли протокол websocket настолько простым в реализации, что он "почти"-сокеты?

Я читал о WebSockets, но они не кажутся чистыми "сокетами", потому что над ними есть протокол уровня приложения.

[является ли] протокол websocket настолько простым в реализации, что [это] "почти"-сокеты?

даже flash не может полностью сделать необработанные TCP-соединения. Flash-сокеты также добавляют безопасность CORS, но вместо внутриполосного рукопожатия соединения flash-сокетов подключаются к порту 843 на цели сервер для запроса файла политики безопасности.

есть ли способ сделать чистое соединение сокета из веб-браузера, чтобы оживить веб-страницы?

Да, вы можете использовать my websockify bridge / proxy, который позволяет браузеру с поддержкой WebSockets напрямую подключаться к TCP-сокету через websockify.

но о HTML5, почему они называются WebSockets, если они не являются сокетами?

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

Я не могу улучшить ответы Канаки на ваши второстепенные вопросы, и я знаю, что этому вопросу год. Но главный вопрос:--0--> существует проект под названием Java / JavaScript Socket Bridge это может быть то, что вы (или кто-либо попадается на этой странице из поиска Google) ищете. Преимущество этого метода перед другими заключается в том, что он не требует запуска ни клиентской, ни серверной службы. Так, например, если вы хотели реализовать IRC-клиент исключительно в JavaScript, но ваш веб-узел не дает вам достаточных прав для прокси-соединения, этот Java-апплет будет способом. Единственная проблема - убедиться, что клиент установлен и разрешен Java.

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

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

сервер также должен добавить байты заголовка, но не должен кодировать данные.

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

редирект
NAT keepalive
мультиплексирование через URI
кадрирование

Если вы просите, чтобы некоторые данные были вытеснены с сервера, он широко называется как комета или обратный Ajax.

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

Как подключиться к моему серверу на ServerSocket с другого компьютера?
Какой адрес я должен сообщить? Когда тестирую на 127.0.0.1, все функции программы выполняются.

Как передать строку через сокет?
Передаю строку через сокеты. Если запускать сервер и клиент на одном компе , передает всё нормально.

Как подключиться к веб-сокет серверу?
Доброго времени суток. Необходимо реализовать взаимодействие 1С (8.2) с веб-сокет сервером.

Так и у меня есть внутренний и есть внешний IP и он дает внешний доступ к компу.
К Инету через VPN подключаюсь. Интересно. Можно чуть подробнее?
У моего компьютера тоже был внешний IP, через который я мог получить к нему доступ, пока я не поставил дома раутер. Сейчас у меня только внутренний. И нужно делать проброс портов, ежели приспичит. Мой комп подключен к локальной сети провайдера, но для доступа в Интернет мне необходимо дополнительно устанавливать VPN-соединение с опред. настройками.
Та же проблема, есть VPS создаю слушающий сокет TCP/IP, проверял с помощью "netstat -a" сокет отображается как слушающий, но соединение не могу установить хотя локально все работает.
ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : NL_49492
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection 2:

Ethernet adapter NL_49492:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

Tunnel adapter 6TO4 Adapter:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft 6to4 Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2002:5e4b:f494::5e4b:f494(Preferred)
Default Gateway . . . . . . . . . : 2002:c058:6301::1
DNS Servers . . . . . . . . . . . : 85.17.96.69
85.17.150.123
NetBIOS over Tcpip. . . . . . . . : Disabled

Tunnel adapter Teredo Tunneling Pseudo-Interface:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2001:0:9d38:90d7:2ccc:31fb:a1b4:b6b(Prefe
rred)
Link-local IPv6 Address . . . . . : fe80::2ccc:31fb:a1b4:b6b%16(Preferred)
Default Gateway . . . . . . . . . :
NetBIOS over Tcpip. . . . . . . . : Disabled

IPv4 Route Table
============================================================ ===============
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 94.75.244.158 94.75.244.148 21
94.75.244.128 255.255.255.224 On-link 94.75.244.148 276
94.75.244.148 255.255.255.255 On-link 94.75.244.148 276
94.75.244.159 255.255.255.255 On-link 94.75.244.148 276
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 94.75.244.148 276
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 94.75.244.148 276
============================================================ ===============
Persistent Routes:
Network Address Netmask Gateway Address Metric
0.0.0.0 0.0.0.0 94.75.244.158 1
============================================================ ===============

IPv6 Route Table
============================================================ ===============
Active Routes:
If Metric Network Destination Gateway
15 1041 ::/0 2002:c058:6301::1
1 306 ::1/128 On-link
16 58 2001::/32 On-link
16 306 2001:0:9d38:90d7:2ccc:31fb:a1b4:b6b/128
On-link
15 1025 2002::/16 On-link
15 281 2002:5e4b:f494::5e4b:f494/128
On-link
16 306 fe80::/64 On-link
16 306 fe80::2ccc:31fb:a1b4:b6b/128
On-link
1 306 ff00::/8 On-link
16 306 ff00::/8 On-link
============================================================ ===============
Persistent Routes:
None

Не гляните в чем проблема? Будет ли на этом VPS работать сервер (слушать сокет)?

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

Когда дело доходит до доставки данных с сервера клиенту, мы ограничены двумя основными подходами: client pull или server push . В качестве простого примера веб-приложения можно привести браузер.

Когда сайт, открытый в браузере запрашивает с сервера данные, это называется client pull . Обратная технология, когда сервер активно перенаправляет обновления на сайт, называется server push .

Существует несколько способов их реализации:

Длительный / короткий поллинг ( client pull );
WebSockets ( server push );
Server-Sent events ( server push ).

Бизнес-кейс

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

Виджеты никак не связаны друг с другом. В идеале они все должны быть подписаны на какую-либо конечную точку API и начинать получать данные от нее.

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

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

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

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

Возможные варианты реализации

Длительный поллинг

Клиент запрашивает у сервера данные. Сервер не имеет данных и ждет некоторое время перед отправкой ответа:

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

WebSockets

В качестве первого примера метода s erver push мы рассмотрим WebSockets .

Это протокол связи, обеспечивающий полнодуплексные каналы связи через одно TCP-соединение .

Приложение;
Представление;
Сессия;
Транспорт;
Сеть;
Канал передачи данных;
Физическое устройство.

В Википедии есть отличная статья о WebSockets .

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

Есть несколько проблем, связанных с WebSockets и прокси:

Балансировка нагрузки (без мультиплексирования) :

Если каждый пользователь открывает n-ное количество сокетов, реализовать корректную балансировку нагрузки очень сложно. Когда серверы перегружены, а вам нужно создавать новые экземпляры и завершать старые, действия, которые выполняются при «повторном подключении», могут вызвать длинные цепочки обновлений и новых запросов. Они будут перегружать систему.

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

Нужно заново изобретать велосипед :

Хорошими вариантами применения WebSockets являются чаты и многопользовательские игры. Их главным преимуществом является дуплексная связь, а нам это не нужно.

Промежуточные итоги

Мы получаем увеличение эксплуатационных затрат с точки зрения разработки, тестирования и масштабирования при использовании поллингов и WebSockets .

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

Но почему еще есть проблемы с мобильными устройствами?

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

Без WiFi , как для WebSockets , так и для поллинга требуется, чтобы полнодуплексная антенна работала почти постоянно. Таким образом, мы сталкиваемся с увеличением объема передаваемых данных и потребления энергии.

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

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

Уникальные функции

Реализация образца клиента

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

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

Реализация клиента для WebSockets выглядит похоже. Сложность с сокетами заключается в ИТ-инфраструктуре и реализации сервера.

EventSource

Каждый объект EventSource содержит следующие компоненты :

URL : устанавливается во время сборки.
Запрос : изначально имеет значение null.
Время повторного соединения : значение в миллисекундах (определяемое пользователем значение).
Идентификатор последнего события : сначала пустая строка.
Состояние готовности : состояние соединения.

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

Обработка разрывов соединения

Реализация образца сервера

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

Определяем функцию, которая будет обрабатывать ответ:

Если значение этого поля не содержит U + 0000 NULL , устанавливаем для буфера последнего идентификатора события значение поля. Иначе игнорируем поле.

Добавляем значение поля в буфер, затем добавляем в буфер один символ U + 000A LINE FEED (LF) .

Устанавливаем для буфера тип события и значение поля. Это приводит к тому, что для event.type задается пользовательское имя события.

Если значение поля состоит только из цифр ASCII , тогда интерпретируем значение поля как целое число в десятичной системе исчисления. А также устанавливаем для времени повторного соединения потока событий это целое число. В противном случае игнорируем поле.

Все остальное будет проигнорировано. Мы не можем вводить собственные поля.

Пример с добавленным event :

В клиенте это обрабатывается с помощью addEventListener следующим образом:

Это значительно упрощает то, что мы можем сделать с нашими данными.

Специальные требования к серверу

В нашем случае лучше всего использовать сервер на основе цикла событий. Например, NodeJS , Kestrel или Twisted . Идея состоит в том, что при использовании потокового решения будет один поток на соединение. То есть, 1000 соединений = 1000 потоков. В решении на основе цикла событий у нас будет один поток для 1000 соединений.

Мы получили все, чтобы приложение работало эффективно. Но столкнулись с некоторыми проблемами:

Некоторые из доступных полифиллов:

Бесплатное подключение и другие функции

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

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

Подобный подход может снизить объем передаваемых данных и привести к значительной экономии энергии.

Помимо реализации существующего API и формата передаваемых данных ext/event-stream также могут поддерживаться форматы фреймворка событий, определенные другими спецификациями.

Заключение

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

Вот как выглядит окончательная рабочая установка:

Обзор окончательной архитектуры. Все конечные точки API обслуживаются NGINX, поэтому клиенты получают мультиплексированный ответ.

NGINX дает нам следующее :

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

Основные преимущества этого подхода:

Здесь вы можете найти демо-версию кода простой реализации клиента и сервера.

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

Пожалуйста, опубликуйте ваши комментарии по текущей теме статьи. За комментарии, дизлайки, отклики, подписки, лайки низкий вам поклон!

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

Простой пример

Чтобы открыть веб-сокет-соединение, нам нужно создать объект new WebSocket , указав в url-адресе специальный протокол ws :

Протокол wss:// не только использует шифрование, но и обладает повышенной надёжностью.

Это потому, что данные ws:// не зашифрованы, видны для любого посредника. Старые прокси-серверы не знают о WebSocket, они могут увидеть «странные» заголовки и закрыть соединение.

Как только объект WebSocket создан, мы должны слушать его события. Их всего 4:

Для демонстрации есть небольшой пример сервера server.js, написанного на Node.js, для запуска примера выше. Он отвечает «Привет с сервера, Джон», после ожидает 5 секунд и закрывает соединение.

Так вы увидите события open → message → close .

В общем-то, всё, мы уже можем общаться по протоколу WebSocket. Просто, не так ли?

Теперь давайте поговорим более подробно.

Открытие веб-сокета

Когда new WebSocket(url) создан, он тут же сам начинает устанавливать соединение.

Вот пример заголовков для запроса, который делает new WebSocket("wss://javascript.info/chat") .

Здесь Sec-WebSocket-Accept – это Sec-WebSocket-Key , перекодированный с помощью специального алгоритма. Браузер использует его, чтобы убедиться, что ответ соответствует запросу.

Расширения и подпротоколы

Могут быть дополнительные заголовки Sec-WebSocket-Extensions и Sec-WebSocket-Protocol , описывающие расширения и подпротоколы.

Sec-WebSocket-Extensions: deflate-frame означает, что браузер поддерживает сжатие данных. Расширение – это что-то, связанное с передачей данных, расширяющее сам протокол WebSocket. Заголовок Sec-WebSocket-Extensions отправляется браузером автоматически со списком всевозможных расширений, которые он поддерживает.

Этот необязательный заголовок ставим мы сами, передавая массив подпротоколов вторым параметром new WebSocket , вот так:

Сервер должен ответить перечнем протоколов и расширений, которые он может использовать.

Здесь сервер отвечает, что поддерживает расширение – deflate-frame и может использовать только протокол SOAP из всего списка запрошенных подпротоколов.

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

Поток данных в WebSocket состоит из «фреймов», фрагментов данных, которые могут быть отправлены любой стороной, и которые могут быть следующих видов:

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

В браузере мы напрямую работаем только с текстовыми и бинарными фреймами.

Метод WebSocket .send() может отправлять и текстовые и бинарные данные.

Вызов socket.send(body) принимает body в виде строки или любом бинарном формате включая Blob , ArrayBuffer и другие. Дополнительных настроек не требуется, просто отправляем в любом формате.

При получении данных, текст всегда поступает в виде строки. А для бинарных данных мы можем выбрать один из двух форматов: Blob или ArrayBuffer .

Это задаётся свойством socket.binaryType , по умолчанию оно равно "blob" , так что бинарные данные поступают в виде Blob -объектов.

Blob – это высокоуровневый бинарный объект, он напрямую интегрируется с <a> , <img> и другими тегами, так что это вполне удобное значение по умолчанию. Но для обработки данных, если требуется доступ к отдельным байтам, мы можем изменить его на "arraybuffer" :

Ограничение скорости

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

Мы можем вызывать socket.send(data) снова и снова. Но данные будут буферизованы (сохранены) в памяти и отправлены лишь с той скоростью, которую позволяет сеть.

Свойство socket.bufferedAmount хранит количество байт буферизованных данных на текущий момент, ожидающих отправки по сети.

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

Закрытие подключения

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

Метод для этого:

code – специальный WebSocket-код закрытия (не обязателен).
reason – строка с описанием причины закрытия (не обязательна).

Затем противоположная сторона в обработчике события close получит и код code и причину reason , например:

code – это не любое число, а специальный код закрытия WebSocket.

Наиболее распространённые значения:

1000 – по умолчанию, нормальное закрытие,
1006 – невозможно установить такой код вручную, указывает, что соединение было потеряно (нет фрейма закрытия).

Есть и другие коды:

Полный список находится в RFC6455, §7.4.1.

Состояние соединения

Чтобы получить состояние соединения, существует дополнительное свойство socket.readyState со значениями:

0 – «CONNECTING»: соединение ещё не установлено,
1 – «OPEN»: обмен данными,
2 – «CLOSING»: соединение закрывается,
3 – «CLOSED»: соединение закрыто.

Пример чата

От JavaScript мы хотим 3 вещи:

Серверный код выходит за рамки этой главы. Здесь мы будем использовать Node.js, но вы не обязаны это делать. Другие платформы также поддерживают средства для работы с WebSocket.

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

Вот рабочий пример:

Вы также можете скачать его (верхняя правая кнопка в ифрейме) и запустить локально. Только не забудьте установить Node.js и выполнить команду npm install ws до запуска.

Итого

WebSocket – это современный способ иметь постоянное соединение между браузером и сервером.

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

socket.send(data) ,
socket.close([code], [reason]) .

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

Сокеты (англ. 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() принимает три аргумента:

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

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

Пример на Python

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

listen()¶

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

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

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

Пример на Python

accept()¶

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

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

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

Пример на Python

connect()¶

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

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

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

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

Пример на Python

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

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

Читайте также: