Cеть передача сокетов между процессами


Содержание

Передача сокетов между процессами

Для того, чтобы передать сокет от одного процесса другому, можно воспользоваться функцией WSADuplicateSocket() из Winsock 2. Изначально в часто задаваемых вопросах (FAQ) эту проблему решали следующим способом:

Спецификация данного метода подробно описывается в секции 2.10 MSDN-а, где подробно по шагам комментируется данная функция. Так же можно почитать статью Q150523 в Microsoft Knowledge Base, в которой описываются различия наследования сокета в разных версиях Windows.

Другая забавная особенность Win32 API заключается в том, что он позволяет присваивать новому процессу (во время его создания) различные «стандартные обработчики» («standard handles») (stdin, stdout и stderr). Статья Q190351 в MSKB описывает данный момент. Обратите внимание, что данная возможность доступна только для дочерних процессов; т.е. Вы не сможете перенаправить стандартный обработчик I/O на сокет. Естевственно, что данная возможность не предоставляет нам таких преимуществ, как, например, Unix-функция dup2().

Так же в FAQ сказано, что мы не можем использовать такую возможность в Winsock 1.1. Однако Frank Schmied показал, что можно слегка обмануть стек Microsoft Winsock 1.1 в Win32, и в конечном результате добиться своей цели. Вот его комментарии:

Можно заставить Winsock 1.1 передавать сокет от одного процесса другому используя Win32 функцию DuplicateHandle(). Обработка данного вызова может быть весьма сложной. Фактически, генерация реальных дескрипторов процесса не так проста, как может показаться на первый взгляд. Windows использует два типа дескрипторов окна: псевдо-дескрипторы и реальные дескрипторы. Обычно дескрипторы в Windows — это адреса в памяти, и экземпляр дескриптора является ни чем иным как смещением указателя на код, расположенный в текущем адресном пространстве. Итак, дескриптор процесса HINSTANCE (псевдо или локальный) обычно равен 0x4000000. Передача данного дескриптора от одного процесса к другому не работает. Чтобы получить реальный дескриптор текущего процесса, можно использовать OpenProcess():

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

Данный пример отлично работает на многопроцессорном вебсервере. Данная функция передаёт сокет в новый процесс и закрывает дескриптор старого процесса. Дескриптор имеет те же свойства что и старый, но не может быть унаследован дочерним процессом. Чтобы исправить это, достаточно в DuplicateHandle() изменить FALSE на TRUE. Как мы видим, дескриптор основного процесса может быть псевдо-дескриптором, но дескриптор второго процесса обязан быть реальным.

Алгоритм таков: исходный процесс конвертирует локальный дескриптор SOCKET в реальный дескриптор при помощи OpenProcess(), затем передаёт это значение и ID процесса другому процессу. Второй процесс вызывает функцию ConvertProcessSocket(), чтобы преобразовать реальный дескриптор в локальный, который уже можно будет использовать в Winsock. Обратите внимание, что вызов DuplicateHandle() закрывает дескриптор первого процесса, а затем функция CloseHandle() закрывает реальный дескриптор, который вы передаёте второму процессу.

Недостатки: данная методика скорее всего работает только со стеком Microsoft. Однозначно не будет работать в Win16, и, возможно в WinCE. Не извесно, будет или нет работать в присутствие Layered Service Providers, исключая Windows NT 4.0 SP 4+, в которой пропатчен уровень Installable FileSystems (IFS). Возможно найдутся ещё причины, по которым данный метод может не сработать :)

Cеть передача сокетов между процессами

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

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

С уважением,
команда разработчиков eManual.ru

Передача сокетов между процессами в C++

Передача сокетов между процессами в C++

Warren Young и Frank Schmied
www.исходники.ru

Для того, чтобы передать сокет от одного процесса другому, можно воспользоваться функцией WSADuplicateSocket() из Winsock 2. Изначально в часто задаваемых вопросах (FAQ) эту проблему решали следующим способом:

Спецификация данного метода подробно описывается в секции 2.10 MSDN-а, где подробно по шагам комментируется данная функция. Так же можно почитать статью Q150523 в Microsoft Knowledge Base, в которой описываются различия наследования сокета в разных версиях Windows.

Другая забавная особенность Win32 API заключается в том, что он позволяет присваивать новому процессу (во время его создания) различные «стандартные обработчики» («standard handles») (stdin, stdout и stderr). Статья Q190351 в MSKB описывает данный момент. Обратите внимание, что данная возможность доступна только для дочерних процессов; т.е. Вы не сможете перенаправить стандартный обработчик I/O на сокет. Естевственно, что данная возможность не предоставляет нам таких преимуществ, как, например, Unix-функция dup2().

Так же в FAQ сказано, что мы не можем использовать такую возможность в Winsock 1.1. Однако Frank Schmied показал, что можно слегка обмануть стек Microsoft Winsock 1.1 в Win32, и в конечном результате добиться своей цели. Вот его комментарии:

Можно заставить Winsock 1.1 передавать сокет от одного процесса другому используя Win32 функцию DuplicateHandle(). Обработка данного вызова может быть весьма сложной. Фактически, генерация реальных дескрипторов процесса не так проста, как может показаться на первый взгляд. Windows использует два типа дескрипторов окна: псевдо-дескрипторы и реальные дескрипторы. Обычно дескрипторы в Windows — это адреса в памяти, и экземпляр дескриптора является ни чем иным как смещением указателя на код, расположенный в текущем адресном пространстве. Итак, дескриптор процесса HINSTANCE (псевдо или локальный) обычно равен 0x4000000. Передача данного дескриптора от одного процесса к другому не работает. Чтобы получить реальный дескриптор текущего процесса, можно использовать OpenProcess(): OpenProcess(PROCESS_ALL_ACCESS, FALSE, GetCurrentProcessId());

Создание дубликата дескриптора выглядит примерно так: SOCKET ConvertProcessSocket(SOCKET oldsocket, DWORD source_p >Данный пример отлично работает на многопроцессорном вебсервере. Данная функция передаёт сокет в новый процесс и закрывает дескриптор старого процесса. Дескриптор имеет те же свойства что и старый, но не может быть унаследован дочерним процессом. Чтобы исправить это, достаточно в DuplicateHandle() изменить FALSE на TRUE. Как мы видим, дескриптор основного процесса может быть псевдо-дескриптором, но дескриптор второго процесса обязан быть реальным.

Алгоритм таков: исходный процесс конвертирует локальный дескриптор SOCKET в реальный дескриптор при помощи OpenProcess(), затем передаёт это значение и ID процесса другому процессу. Второй процесс вызывает функцию ConvertProcessSocket(), чтобы преобразовать реальный дескриптор в локальный, который уже можно будет использовать в Winsock. Обратите внимание, что вызов DuplicateHandle() закрывает дескриптор первого процесса, а затем функция CloseHandle() закрывает реальный дескриптор, который вы передаёте второму процессу.

Недостатки: данная методика скорее всего работает только со стеком Microsoft. Однозначно не будет работать в Win16, и, возможно в WinCE. Не извесно, будет или нет работать в присутствие Layered Service Providers, исключая Windows NT 4.0 SP 4+, в которой пропатчен уровень Installable FileSystems (IFS). Возможно найдутся ещё причины, по которым данный метод может не сработать :)

Cеть передача сокетов между процессами

Профиль
Группа: Участник
Сообщений: 55
Регистрация: 20.9.2005

Репутация: нет
Всего: 2

Для того, чтобы передать сокет от одного процесса другому, можно воспользоваться функцией WSADuplicateSocket() из Winsock 2. Изначально в часто задаваемых вопросах (FAQ) эту проблему решали следующим способом:

Спецификация данного метода подробно описывается в секции 2.10 MSDN-а, где подробно по шагам комментируется данная функция. Так же можно почитать статью Q150523 в Microsoft Knowledge Base, в которой описываются различия наследования сокета в разных версиях Windows.

Другая забавная особенность Win32 API заключается в том, что он позволяет присваивать новому процессу (во время его создания) различные «стандартные обработчики» («standard handles») (stdin, stdout и stderr). Статья Q190351 в MSKB описывает данный момент. Обратите внимание, что данная возможность доступна только для дочерних процессов; т.е. Вы не сможете перенаправить стандартный обработчик I/O на сокет. Естевственно, что данная возможность не предоставляет нам таких преимуществ, как, например, Unix-функция dup2().

Так же в FAQ сказано, что мы не можем использовать такую возможность в Winsock 1.1. Однако Frank Schmied показал, что можно слегка обмануть стек Microsoft Winsock 1.1 в Win32, и в конечном результате добиться своей цели. Вот его комментарии:

Можно заставить Winsock 1.1 передавать сокет от одного процесса другому используя Win32 функцию DuplicateHandle(). Обработка данного вызова может быть весьма сложной. Фактически, генерация реальных дескрипторов процесса не так проста, как может показаться на первый взгляд. Windows использует два типа дескрипторов окна: псевдо-дескрипторы и реальные дескрипторы. Обычно дескрипторы в Windows — это адреса в памяти, и экземпляр дескриптора является ни чем иным как смещением указателя на код, расположенный в текущем адресном пространстве. Итак, дескриптор процесса HINSTANCE (псевдо или локальный) обычно равен 0x4000000. Передача данного дескриптора от одного процесса к другому не работает. Чтобы получить реальный дескриптор текущего процесса, можно использовать OpenProcess():

Код
OpenProcess(PROCESS_ALL_ACCESS, FALSE, GetCurrentProcessId());

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

Код
SOCKET ConvertProcessSocket(SOCKET oldsocket, DWORD source_pid)
<
HANDLE source_handle = OpenProcess(PROCESS_ALL_ACCESS,
FALSE, source_pid);
HANDLE newhandle;
DuplicateHandle(source_handle, (HANDLE)oldsocket,
GetCurrentProcess(), &newhandle, 0, FALSE,
DUPLICATE_CLOSE_SOURCE | DUPLICATE_SAME_ACCESS);
CloseHandle(source_handle);
return (SOCKET)newhandle;
>

Данный пример отлично работает на многопроцессорном вебсервере. Данная функция передаёт сокет в новый процесс и закрывает дескриптор старого процесса. Дескриптор имеет те же свойства что и старый, но не может быть унаследован дочерним процессом. Чтобы исправить это, достаточно в DuplicateHandle() изменить FALSE на TRUE. Как мы видим, дескриптор основного процесса может быть псевдо-дескриптором, но дескриптор второго процесса обязан быть реальным.

Алгоритм таков: исходный процесс конвертирует локальный дескриптор SOCKET в реальный дескриптор при помощи OpenProcess(), затем передаёт это значение и ID процесса другому процессу. Второй процесс вызывает функцию ConvertProcessSocket(), чтобы преобразовать реальный дескриптор в локальный, который уже можно будет использовать в Winsock. Обратите внимание, что вызов DuplicateHandle() закрывает дескриптор первого процесса, а затем функция CloseHandle() закрывает реальный дескриптор, который вы передаёте второму процессу.

Недостатки: данная методика скорее всего работает только со стеком Microsoft. Однозначно не будет работать в Win16, и, возможно в WinCE. Не извесно, будет или нет работать в присутствие Layered Service Providers, исключая Windows NT 4.0 SP 4+, в которой пропатчен уровень Installable FileSystems (IFS). Возможно найдутся ещё причины, по которым данный метод может не сработать

Передача файла по сети через сокеты


Как можно передать файл с расширением .ехе размером, допустим, 30мб через сокет? Какие функции использовать? Какой алгоритм?

Столкнулся с такой вот проблемой: не могу отправить файл кусками, то есть буфер у меня 1024, а файл, допустим, 17*1024. Не получается считывать по очереди 1024 байта с файла. ReadFile & fread читают полностью файл, не обращая внимание на размер записываемого буфера. Пробовал так же игратся с позицией в потоке и fgets? но так же ничего не вышло. Кто знает каким способом можно высылать частями файл?

Уже разобрался , всем спасибо за помощь) Конечний код передачи файла:

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

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

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

Таблица 3.6. Типы сокетов в системе BSD UNIX

Название Тип
SOCK_DGRAM Сокет датаграмм
SOCK_STREAM Сокет потока
SOCK_SEQPACKET Сокет пакетов
SOCK_RAW Сокет низкого уровня

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

Для создания сокета используется системный вызов socket(2)[44], имеющий следующий вид:

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

Здесь аргумент domain определяет коммуникационный домен, type — тип сокета, a protocol — используемый протокол (может быть не указан, т.е. приравнен 0). В случае успеха системный вызов возвращает положительное целое число, аналогичное файловому дескриптору, которое служит для адресации данного сокета в последующих вызовах.

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

AF_UNIX Домен локального межпроцессного взаимодействия в пределах единой операционной системы UNIX. Внутренние протоколы.
AF_INET Домен взаимодействия процессов удаленных систем. Протоколы Internet (TCP/IP).
AF_NS Домен взаимодействия процессов удаленных систем. Протоколы Xerox NS.

Поскольку домен и семейство протоколов определяют адресное пространство взаимодействия (допустимые адреса и их формат), то в названиях доменов присутствует префикс AF (от address family — семейство адресов). Допустимыми также являются названия с префиксом PF (protocol family) PF_UNIX , PF_INET и т.д.

Илон Маск рекомендует:  Asp обзор программного администрирования

Заметим, что домен может не поддерживать определенные типы сокетов. Для сравнения в табл. 3.7 приведены два основных коммуникационных домена — внутренний домен UNIX, предназначенный для взаимодействия процессов одной операционной системы, и домен TCP/IP, используемый в сетевых распределенных приложениях.

Таблица 3.7. Поддержка различных типов сокетов в доменах

Домен: AF_UNIX AF_INET
Тип сокета
SOCK_STREAM Да Да
SOCK_DGRAM Да Да
SOCK_SEQPACKET Нет Нет
SOCK_RAW Нет Да

Также допустимы не все комбинации типа сокета и используемого коммуникационного протокола (если таковой явно указан в запросе). Так для домена AF_ INET возможны следующие комбинации:

Сокет Протокол
SOCK_STREAM IPPROTO_TCP (TCP)
SOCK_DGRAM IPPROTO_UDP (UDP)
SOCK_RAW IPPROTO_ICMP (ICMP)
SOCK_RAW IPPROTO_RAW (IP)

Указанные протоколы принадлежат семейству сетевых протоколов TCP/IP и будут подробно рассмотрены в главе 6.

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

1. Коммуникационным протоколом

2. Локальным адресом

3. Локальным процессом

4. Удаленным адресом

5. Удаленным процессом

Как правило, адрес определяет операционную систему (или хост сети), а процесс — конкретное приложение, получающее или передающее данные. Однако конкретные значения и формат этих параметров определяются коммуникационным доменом.

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

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

Рис. 3.21. Взаимодействие между процессами при создании виртуального канала (с предварительным установлением соединения)

Рис. 3.22. Взаимодействие между процессами, основанное на датаграммах (без предварительного установления соединения)

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

int bind(int sockfd, struct sockaddr *localaddr, int addrlen);

Здесь sockfd является дескриптором сокета, полученным при его создании; аргумент localaddr определяет локальный адрес, с которым необходимо связать сокет; параметр addrlen определяет размер адреса. Заметим, что речь идет о связывании с локальным адресом, в общем случае определяющим два параметра коммуникационного канала (коммуникационный узел): локальный адрес и локальный процесс.

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

Поле sa_family определяет коммуникационный домен (семейство протоколов), a sa_data — содержит собственно адрес, формат которого определен для каждого домена.

Например, для внутреннего домена UNIX адрес выглядит следующим образом (определен в ):

short sun_family; /* ==AF_UNIX */


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

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

short sin_ family; /* ==AF_INET */

struct in_addr sin_addr;

Адреса этого домена (IP-адреса) будут рассмотрены подробнее в главе 6. Пока лишь заметим, что адрес хоста представляет собой 32-разрядное целое число sin_addr , а процесс (приложение) адресуется 16-разрядным номером порта sin_port .

На рис. 3.23 показаны рассмотренные форматы адресов сокетов.

Рис. 3.23. Адреса сокетов

Итак, связывание необходимо для присвоения сокету локального адреса и, таким образом, для определения коммуникационного узла. Можно выделить три случая использования для этого функции bind(2):

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

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

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

Назначение адреса для клиента также можно выполнить с помощью системного вызова connect(2), устанавливающего связь с сервером и автоматически связывающего сокет клиента с локальным коммуникационным узлом. Вызов connect(2) имеет вид:

int connect(int sockfd, struct sockaddr *servaddr, int addrlen);

Характер этого вызова предполагает создание виртуального канала и, таким образом, используется для предварительного установления связи между коммуникационными узлами. В этом случае клиенту нет необходимости явно связывать сокет с помощью системного вызова bind(2). Локальный узел коммуникационного канала указывается дескриптором сокета sockfd , для которого система автоматически выбирает приемлемые значения локального адреса и процесса. Удаленный узел определяется аргументом servaddr , который указывает на адрес сервера, a addrlen задает его длину.

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

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

Системный вызов listen(2) информирует систему, что сервер готов принимать запросы. Он имеет следующий вид:

int listen(int sockfd, int backlog);

Здесь параметр sockfd определяет сокет, который будет использоваться для получения запросов. Предполагается, что сокет был предварительно связан с известным адресом. Параметр backlog указывает максимальное число запросов на установление связи, которые могут ожидать обработки сервером.[45]

Фактическую обработку запроса клиента на установление связи производит системный вызов

int accept(int sockfd, struct sockaddr *clntaddr,

Вызов accept(2) извлекает первый запрос из очереди и создает новый сокет, характеристики которого не отличаются от сокета sockfd , и таким образом завершает создание виртуального канала со стороны сервера. Одновременно accept(2) возвращает параметры удаленного коммуникационного узла — адрес клиента clntaddr и его размер addrlen . Новый сокет используется для обслуживания созданного виртуального канала, а полученный адрес клиента исключает анонимность последнего. Дальнейший типичный сценарий взаимодействия имеет вид:

sockfd = socket(. ); Создать сокет

bind(sockfd, . ); Связать его с известным локальным адресом

listen(sockfd, . ); Организовать очередь запросов

newsockfd = accept(sockfd, . ); Получить запрос

close(sockfd); Дочерний процесс

close(newsockfd); Родительский процесс

В этом сценарии, в то время как дочерний процесс обеспечивает фактический обмен данными с клиентом, родительский процесс продолжает «прослушивать» поступающие запросы, порождая для каждого из них отдельный процесс-обработчик. Очередь позволяет буферизовать запросы на время, пока сервер завершает вызов accept(2) и затем создает дочерний процесс. Заметим, что новый сокет newsockfd , полученный в результате вызова accept(2), адресует полностью определенный коммуникационный канал: протокол и полные адреса обоих узлов — клиента и сервера. Напротив, для сокета sockfd определена только локальная часть канала. Это позволяет серверу продолжать использовать sockfd для «прослушивания» последующих запросов.

Наконец, если для сокетов потока при приеме и передаче данных могут быть использованы стандартные вызовы read(2) и write(2), то сокеты дата- грамм должны пользоваться специальными системными вызовами (эти вызовы также доступны для сокетов других типов):

int send(int s, const char *msg, int len, int flags);

int sendto(int s, const char *msg, int len, int flags,

const struct sockaddr* toaddr, int tolen);

int recv(int s, char *buf, int len, int flags);

int recvfrom(int s, char *buf, int len, int flags,

struct sockaddr* fromaddr, int* fromlen);

Функции send(2) и sendto(2) используются для передачи данных удаленному узлу, а функции recv(2) и recvfrom(2) — для их приема. Основным различием между ними является то, что функции send(2) и recv(2) могут быть использованы только для «подсоединенного» сокета, т.е. после вызова connect(2).

Все эти вызовы используют в качестве первого аргумента дескриптор сокета, через который производится обмен данными. Аргумент msg содержит сообщение длиной len , которое должно быть передано по адресу toaddr , длина которого составляет tolen байтов. Для функции send(2) используется адрес получателя, установленный предшествовавшим вызовом connect(2). Аргумент buf представляет собой буфер, в который копируются полученные данные.

Параметр flags может принимать следующие значения:


Сетевое программирование для разработчиков игр. Часть 2: прием и передача пакетов данных

Прием и передача пакетов данных

Введение

Привет, меня зовут Гленн Фидлер и я приветствую вас в своей второй статье из цикла “Сетевое программирование для разработчиков игр”.

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

А сейчас я собираюсь рассказать вам, как на практике использовать UDP для отправки и приема пакетов.

BSD сокеты

В большинстве современных ОС имеется какая-нибудь реализация сокетов, основанная на BSD сокетах (сокетах Беркли).

Сокеты BSD оперируют простыми функциями, такими, как “socket”, “bind”, “sendto” и “recvfrom”. Конечно, вы можете обращаться к этим функциями напрямую, но в таком случае ваш код будет зависим от платформы, так как их реализации в разных ОС могут немного отличаться.

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

Особенности разных ОС

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

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

В UNIX системах функции работы с сокетами входят в стандартные системные библиотеки, поэтому никакие сторонние библиотеки нам в этом случае не нужны. Однако в Windows для этих целей нам нужно подключить библиотеку winsock.

Вот небольшая хитрость, как можно это сделать без изменения проекта или makefile’а:

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

Инициализация сокетов

В большинстве unix-like операционных систем (включая macosx) не требуется никаких особых действий для инициализации функционала работы с сокетами, но в Windows нужно сначала сделать пару па — нужно вызвать функцию “WSAStartup” перед использованием любых функций работы с сокетами, а после окончания работы — вызвать “WSACleanup”.

Давайте добавим две новые функции:

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

Создаем сокет

Теперь мы можем создать UDP сокет. Это делается так:

Далее мы должны привязать сокет к определенному номеру порта (к примеру, 30000). У каждого сокета должен быть свой уникальный порт, так как, когда приходит новый пакет, номер порта определяет, какому сокету его передать. Не используйте номера портов меньшие, чем 1024 — они зарезервированы системой.

Если вам все равно, какой номер порта использовать для сокета, вы можете просто передать в функцию “0”, и тогда система сама выделит вам какой-нибудь незанятый порт.

Теперь наш сокет готов для передачи и приема пакетов данных.

Но что это за таинственная функция “htons” вызывается в коде? Это просто небольшая вспомогательная функция, которая переводит порядок следования байтов в 16-битном целом числе — из текущего (little- или big-endian) в big-endian, который используется при сетевом взаимодействии. Ее нужно вызывать каждый раз, когда вы используете целые числа при работе с сокетами напрямую.

Вы встретите функцию “htons” и ее 32-битного двойника — “htonl” в этой статье еще несколько раз, так что будьте внимательны.

Перевод сокета в неблокирующий режим

По умолчанию сокеты находится в так называемом “блокирующем режиме”. Это означает, что если вы попытаетесь прочитать из него данные с помощью “recvfrom”, функция не вернет значение, пока не сокет не получит пакет с данными, которые можно прочитать. Такое поведение нам совсем не подходит. Игры — это приложения, работающие в реальном времени, со скоростью от 30 до 60 кадров в секунду, и игра не может просто остановиться и ждать, пока не придет пакет с данными!

Решить эту проблему можно переведя сокет в “неблокирующий режим” после его создания. В этом режиме функция “recvfrom”, если отсутствуют данные для чтения из сокета, сразу возвращает определенное значение, показывающее, что нужно будет вызвать ее еще раз, когда в сокете появятся данные.

Перевести сокет в неблокирующий режим можно следующим образом:

Как вы можете видеть, в Windows нет функции “fcntl”, поэтому вместе нее мы используем “ioctlsocket”.

Илон Маск рекомендует:  Создание окна
Отправка пакетов

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

Переслать пакет на определенный адрес можно следующим образом:

Обратите внимание — возвращаемое функцией “sendto” значение показывает только, был ли пакет успешно отправлен с локального компьютера. Но оно не показывает, был ли пакет принят адресатом! В UDP нет средств для определения, дошел ли пакет по назначению или нет.

В коде, приведенном выше, мы передаем структуру “sockaddr_in” в качестве адреса назначения. Как нам получить эту структуру?

Допустим, мы хотим отправить пакет по адресу 207.45.186.98:30000.

Запишем адрес в следующей форме:


И нужно сделать еще пару преобразований, чтобы привести его к форме, которую понимает “sendto”:

Как видно, сначала мы объединяем числа a, b, c, d (которые лежат в диапазоне [0, 255]) в одно целое число, в котором каждый байт — это одно из исходных чисел. Затем мы инициализируем структуру “sockaddr_in” нашими адресом назначения и портом, при этом не забыв конвертировать порядок байтов с помощью функций “htonl” и “htons”.

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

Прием пакетов

После того, как мы привязали UDP сокет к порту, все UDP пакеты, приходящие на IP адрес и порт нашего сокета, будут ставиться в очередь. Поэтому для приема пакетов мы просто в цикле вызываем “recvfrom”, пока он не выдаст ошибку, означающую, что пакетов для чтения в очерели не осталось.

Так как протокол UDP не поддерживает соединения, пакеты могут приходить с множества различных компьютеров сети. Каждый раз, когда мы принимаем пакет, функция “recvfrom” выдает нам IP адрес и порт отправителя, и поэтому мы знаем, кто отправил этот пакет.

Код приема пакетов в цикле:

Пакеты, размер которых больше, чем размер буфера приема, будут просто втихую удалены из очереди. Так что, если вы используете буфер размером 256 байтов, как в примере выше, и кто-то присылает вам пакет в 300 байт, он будет отброшен. Вы не получите просто первые 256 байтов из пакета.

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

Закрытие сокета

На большинстве unix-like систем, сокеты представляют собой файловые дескрипторы, поэтому для того, чтобы закрыть сокеты после использования, можно использовать стандартную функцию “close”. Однако, Windows, как всегда, выделяется, и в ней нам нужно использовать “closesocket”.

Так держать, Windows!

Класс сокета

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

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

Поэтому мы сделаем класс-обертку “Socket” для всех этих операций. Также мы создадим класс “Address”, чтобы было проще работать с IP адресами. Он позволит не проводить все манипуляции с “sockaddr_in” каждый раз, когда мы захотим отправить или принять пакет.

Итак, наш класс Socket:

И класс Address:

Использовать их для приема и передачи нужно следующим образом:

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

Заключение

Теперь у нас есть независимый от платформы инструмент для отправки и према UDP пакетов.

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

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

> Node 30000
> Node 30001
> Node 30002
И т.д…

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

Я разрабатывал эту программу на MacOSX, но она должна компилироваться на любой unix-like ОС и на Windows, однако если вам для этого потребуется делать какие-либо доработки, сообщите мне.

Cеть передача сокетов между процессами

Авторы: Warren Young и Frank Schmied

Для того, чтобы передать сокет от одного процесса другому, можно воспользоваться функцией WSADuplicateSocket() из Winsock 2. Изначально в часто задаваемых вопросах (FAQ) эту проблему решали следующим способом:

Спецификация данного метода подробно описывается в секции 2.10 MSDN-а, где подробно по шагам комментируется данная функция. Так же можно почитать статью Q150523 в Microsoft Knowledge Base, в которой описываются различия наследования сокета в разных версиях Windows.

Другая забавная особенность Win32 API заключается в том, что он позволяет присваивать новому процессу (во время его создания) различные «стандартные обработчики» («standard handles») (stdin, stdout и stderr). Статья Q190351 в MSKB описывает данный момент. Обратите внимание, что данная возможность доступна только для дочерних процессов; т.е. Вы не сможете перенаправить стандартный обработчик I/O на сокет. Естевственно, что данная возможность не предоставляет нам таких преимуществ, как, например, Unix-функция dup2().

Так же в FAQ сказано, что мы не можем использовать такую возможность в Winsock 1.1. Однако Frank Schmied показал, что можно слегка обмануть стек Microsoft Winsock 1.1 в Win32, и в конечном результате добиться своей цели. Вот его комментарии:

Можно заставить Winsock 1.1 передавать сокет от одного процесса другому используя Win32 функцию DuplicateHandle(). Обработка данного вызова может быть весьма сложной. Фактически, генерация реальных дескрипторов процесса не так проста, как может показаться на первый взгляд. Windows использует два типа дескрипторов окна: псевдо-дескрипторы и реальные дескрипторы. Обычно дескрипторы в Windows — это адреса в памяти, и экземпляр дескриптора является ни чем иным как смещением указателя на код, расположенный в текущем адресном пространстве. Итак, дескриптор процесса HINSTANCE (псевдо или локальный) обычно равен 0x4000000. Передача данного дескриптора от одного процесса к другому не работает. Чтобы получить реальный дескриптор текущего процесса, можно использовать OpenProcess():

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

Данный пример отлично работает на многопроцессорном вебсервере. Данная функция передаёт сокет в новый процесс и закрывает дескриптор старого процесса. Дескриптор имеет те же свойства что и старый, но не может быть унаследован дочерним процессом. Чтобы исправить это, достаточно в DuplicateHandle() изменить FALSE на TRUE. Как мы видим, дескриптор основного процесса может быть псевдо-дескриптором, но дескриптор второго процесса обязан быть реальным.

Алгоритм таков: исходный процесс конвертирует локальный дескриптор SOCKET в реальный дескриптор при помощи OpenProcess(), затем передаёт это значение и ID процесса другому процессу. Второй процесс вызывает функцию ConvertProcessSocket(), чтобы преобразовать реальный дескриптор в локальный, который уже можно будет использовать в Winsock. Обратите внимание, что вызов DuplicateHandle() закрывает дескриптор первого процесса, а затем функция CloseHandle() закрывает реальный дескриптор, который вы передаёте второму процессу.

Недостатки: данная методика скорее всего работает только со стеком Microsoft. Однозначно не будет работать в Win16, и, возможно в WinCE. Не извесно, будет или нет работать в присутствие Layered Service Providers, исключая Windows NT 4.0 SP 4+, в которой пропатчен уровень Installable FileSystems (IFS). Возможно найдутся ещё причины, по которым данный метод может не сработать

Передача сокета между процессами в Linux


Как передать права собственности на сокет между процессами под Linux? У Windows есть функция Socket.DuplicateAndClose , но есть ли способ сделать это в Linux?

Если это имеет значение, я хотел бы передать право собственности из родительского процесса на дочерний процесс, и дочерний процесс не будет запущен в то время, когда я получу сокет, поэтому я открыт для интересных решений с участием fork и семейства функций exec .

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

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

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

Однако, чтобы фактически передать вновь созданный сокет в существующий процесс, вам необходимо использовать вспомогательные данные для упаковки вашего сокета и sendmsg и recvmsg , чтобы выполнить передачу данных. На странице руководства cmsg приведен пример создания сообщения для передачи.

TCP и UDP сокеты в CODESYS V3

CPM723-01: Рекомендации к применению

Сопроводительные документы

Сокеты и стек протоколов TCP/IP

Рис. 1. Пример протоколов стека TCP/IP в соответствии с моделью OSI

В распределенных системах управления обмен данными является одним из ключевых моментов работы системы. Контроллер CPM723-01 позволяет отправлять и получать данные по промышленному протоколу Modbus TCP на базе протокола TCP/IP с использованием двух портов Ethernet и по протоколу Modbus RTU/ACSII на базе последовательных сетей RS-485/ RS-232 с помощью коммуникационных модулей NIM741/NIM742. Кроме того, система исполнения контроллера CPM723-01 поддерживает механизм сетевого обмена данными между контроллерами, принадлежащими одной подсети, средствами специального протокола прикладного уровня CODESYS V3.

Иногда возникает необходимость использовать протоколы низкого уровня, которые позволяют обмениваться большим количеством сообщений с помощью стека TCP/IP. Также, на базе них можно создавать протоколы более высокого уровня модели OSI (рис. 1).

Взаимодействие между устройствами в рамках стека TCP/IP осуществляется с помощью связки IP адреса и порта.

Для заданияIP адресав настоящее время чаще всего используется протокол IPv4. Для него IP-адрес записывается в виде 32-битной формы, представляемой в символьной форме mmm.nnn.ppp.qqq: адрес, разбитый на четыре поля, разделённых точками, по одному байту в поле, например, 192.168.102.101. Номер порта задается в диапазоне от 0 до 65535.

Пара адрес и порт образует сокет (с английского socket – «гнездо»). Сокет – является программным интерфейсом, который обеспечивает обмен данными между устройствами на низком уровне (рис. 2).

Рис. 2. Общение с помощью сокетов.

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

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

TCP сокеты

TCP сокеты используют TCP-соединения, в которых на транспортном уровне (рис. 1) обеспечивается надёжная доставка данных. TCP протокол отвечает за установление и поддержание соединения, сегментацию, доставку и буферизацию данных, упорядочивание и избавление от дублированных TCP-сегментов данных, контроль ошибок и скорости передачи. Схема работы простого TCP сокета представлена на рисунке 3.

Для удобства в качестве функций, указанных на диаграмме, используются функции, из системной библиотеки SysSocket 3.х.x.x, которая позволяет создавать сокеты на устройствах, поддерживающих платформу CODESYS V3 в том числе на контроллере CPM723-01 модульной линейки Fastwel I/O.

Cерверный TCP сокет

Рассмотрим работу серверного сокета (рис. 3). Будем считать, что существует отдельная программа, исполняемая в контроллере, которая организует обмен данными с помощью сокетов.

Рис. 3. Работа простого TCP сокета

Инициализация сокета

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

Далее сокет сервера привязывается к определенному IP-адресу и порту с помощью функции SysSockBind() . Для привязки к определенному IP-адресу функция SysSockBind() ссылается на структуру SOCKADDRESS , в которой хранятся заданный адрес сокета для привязки.

После успешной привязки к адресу функция SysSockListen() включает прослушивание входящих соединений (ожидание подключений клиентов к серверу). Функцией SysSockListen() также определяется максимальное количество подключений к серверу. Например, если максимальное количество подключений равно 3, и если 3 клиента уже подключились к серверу, то 4-тому будет отказано в подключении.

Обмен данными

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

Серверный сокет принимает сообщения с помощью функции SysSockRecv() :

Затем отправляет данные с помощью функции SysSockSend() :

Илон Маск рекомендует:  Rookee и оптимизация поведенческих факторов - новое в SEO

Обработка новых подключений

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

  • 1. Программа может закрыть клиентское соединение. В таком случае, в следующих циклах программы сервер будет ожидать подключения с новым клиентом. Такой режим работы не является эффективным, так как контроллеру придется во время каждого цикла закрывать клиентское соединение и подключать нового (или того же самого что и в предыдущем цикле) клиента.
  • 2. Программа может не закрывать клиентский сокет, а сохранить установленное соединение. В таком случае, один раз установив соединение, клиент будет постоянно отправлять и получать данные от сервера. Такой режим работы более эффективный, но может возникнуть ситуация, когда все клиентские соединения будут заняты, и новый клиент не сможет подключиться к серверу. Решить данную ситуацию можно различными способами. Один из вариантов – следить за последним временем активности клиентских сокетов, и отключать самое старое соединение в случае, если в очереди обнаружился новый клиент (рис. 4).
Рис. 4. Обработка подключения нового клиента

Закрытие соединения


В рабочем режиме работы серверный сокет всегда остается открытым. Закрытие серверного сокета может происходить при внешнем событии, или при возникновении критических ошибок. Ошибки при создании и работе сокетов отображаются в системном идентификаторе result, который имеет тип структуры RTS_IEC_RESULT. Обозначение кодов ошибок описано в системной библиотеке CmpErrors Interfaces в глобальных константах Errors (рис. 5).
Для закрытии сокетного соединения используется фукнция SysSockClose() :

Рис. 5. Расшифровка кодов ошибок работы сокетов

Клиентский TCP сокет

Схема работы клиентского сокета отображена на рисунке 3 справа.

Инициализация клиента

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

Зная IP-адрес и порт сервера, клиент с помощью SysSockConnect() подключается к серверному сокету:

Обмен данными

Обмен данными между клиентом и с помощью функций SysSockSend() и SysSockRecv() :

Закрытие соединения

После обмена данными сокет может быть закрыт с помощью с помощью SysSockClose() :

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

Особенности сокетов TCP

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

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

UDP сокеты

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

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

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

Серверный UDP сокет

На рисунке 6 показана схема работы простого UDP сокета.

Инициализация сервера

Также, как в случае TCP сокетов, системный идентификатор UDP сокета создается с помощью функции SysSockCreate() :

После создания сокет сервера привязывается к определенному IP-адресу и порту с помощью функции SysSockBind() . В отличие от TCP, UDP сокет не включает прослушивание входящих соединений, а сразу подготавливается к получению данных по сети:

Обмен данными

Для получения данных по UDP сокетам используется функция SysSockRecvFrom() (в отличие от SysSockRecv() для TCP сокетов). Ее главная особенность в том, что она не просто принимает данные от клиента, но и записывает адрес и порт клиента в специальную структуру для хранения адреса SOCKADDRESS , чтобы в дальнейшем сервер знал, куда отправлять ответное сообщение:

Рис. 6. Схема работы простого UDP сокета.

Ответное сообщение отправляется с помощью SysSockSendTo() , которая аналогична SysSockSend() для TCP протокола, но в качестве аргумента принимает ссылку на адрес структуры SOCKADDRESS , где хранится записанный ранее адрес клиента:

Закрытие соединения

После отправки данных, сокет сервера снова переходит к функции SysSockRecvFrom() и остается незакрытым.

Но в случае необходимости серверный сокет можно закрыть аналогично TCP сокету:

Клиентский UDP сокет

Клиент UDP работает аналогично клиентскому сокету TCP за исключением использования функций SysSockSendTo() и SysSockRecvFrom() для отправки и получения сообщений.

Инициализация клиента

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

Обмен данными

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

bytesRecv:=SysSockRecvFrom(hClientSocket, ADR(recvMessage), 256, 0, ADR(clientAddress), SIZEOF(clientAddress), ADR(result));
// hClientSocket — системный идентификатор сокета сервера;
// bytesRead, bytesRecv – количество полученных и отправленных байт;
// В случае ошибки возвращается 0;
// ADR(clientAddress) – указатель на структуру SOCKADDRESS, в которую запишется адрес клиента;
// ADR(result) – указатель на идентификатор результата

Закрытие соединения


После обмена данными сокет может быть закрыт с помощью с помощью SysSockClose() :

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

Дополнительные настройки сокетов

На рисунке 3 и 6 показана работа простых серверного и клиентского сокетов. Но на деле, такая простая схема имеет некоторые ограничения и недостатки.

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

По умолчанию, некоторые функции библиотеки SysSocket являются блокирующими. Это значит, что вызов функции не возвращает управление коду, до тех пор, пока он не выполнится. Блокирующими функциями являются SysSockAccept() , SysSockSend() , SysSockRecv() , SysSockSendTo() , SysSockRecvFrom() и так далее.

Например, сервер включает прослушивание входящих соединений с помощью неблокирующей функции SysSockListen() , сразу после которой идет вызов SysSockAccept() . И до тех пор, пока в очереди установленных соединений не появится хотя бы одно подключение, программа не будет исполняться дальше. Такой режим работы также называется синхронным.

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

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

Также, дополнительные настройки работы сокета можно сделать с помощью функции SysSockSetOptions() . Например, включить возможность повторного использования порта:

Подключение несколько клиентов

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

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

Если хотя бы один сокет клиента готов, например, к отправке данных, SysSockSelect() сообщит об этом программе и соединение с данным клиентом будет установлено. Схема работы серверного сокета с использованием SysSockSelect() показана на рисунке 5.

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

Рис. 7. Схема работы сокетов с использованием функции SysSockSelect()

Программа сокетов для CPM723

В проектах TCP_UDP_Sockets.project и 2xPLCs_Sockets.project, входящих в комплект поставки программного обеспечения Fastwel I/O, реализованы программы TCP сокетов и UDP сокетов на языках ST и CFC стандарта МЭК 61131-3.

Структура проекта TCP_UDP_Sockets.project указана на рисунке 8. В данном проекте реализовано два проекта для UDP и TCP сокетов, для работы в рамках одного контроллера CPM723-01. В первом проекте CPM723_LOCAL_CFC работа сокетов реализована с помощью функциональных блоков, вызываемых в программах (язык CFC). Во втором проекте CPM723_LOCAL_ST работа сокетов реализована в программах (язык ST).

Рис. 8. Структура проекта TCP_UDP_Sockets.project

В проекте 2xPLCs_Sockets.project реализован пример для двух контроллеров CPM723-01, обменивающихся данными по протоколу TCP. На первом контроллере ClientsTCP реализованы TCP сокеты клиентов, на втором контроллере ServerTCP – TCP сокет сервера. Структура проекта указана на рисунке 9.

Рис. 8. Структура проекта TCP_UDP_Sockets.project

Заключение

Сокеты отвечают за обмен данными между различными устройствами и процессами. На базе обмена данными по сокетам можно создавать протоколы стека TCP/IP более высокого уровня.

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

Cеть передача сокетов между процессами

Профиль
Группа: Участник
Сообщений: 55
Регистрация: 20.9.2005

Репутация: нет
Всего: 2

Для того, чтобы передать сокет от одного процесса другому, можно воспользоваться функцией WSADuplicateSocket() из Winsock 2. Изначально в часто задаваемых вопросах (FAQ) эту проблему решали следующим способом:

Спецификация данного метода подробно описывается в секции 2.10 MSDN-а, где подробно по шагам комментируется данная функция. Так же можно почитать статью Q150523 в Microsoft Knowledge Base, в которой описываются различия наследования сокета в разных версиях Windows.

Другая забавная особенность Win32 API заключается в том, что он позволяет присваивать новому процессу (во время его создания) различные «стандартные обработчики» («standard handles») (stdin, stdout и stderr). Статья Q190351 в MSKB описывает данный момент. Обратите внимание, что данная возможность доступна только для дочерних процессов; т.е. Вы не сможете перенаправить стандартный обработчик I/O на сокет. Естевственно, что данная возможность не предоставляет нам таких преимуществ, как, например, Unix-функция dup2().

Так же в FAQ сказано, что мы не можем использовать такую возможность в Winsock 1.1. Однако Frank Schmied показал, что можно слегка обмануть стек Microsoft Winsock 1.1 в Win32, и в конечном результате добиться своей цели. Вот его комментарии:

Можно заставить Winsock 1.1 передавать сокет от одного процесса другому используя Win32 функцию DuplicateHandle(). Обработка данного вызова может быть весьма сложной. Фактически, генерация реальных дескрипторов процесса не так проста, как может показаться на первый взгляд. Windows использует два типа дескрипторов окна: псевдо-дескрипторы и реальные дескрипторы. Обычно дескрипторы в Windows — это адреса в памяти, и экземпляр дескриптора является ни чем иным как смещением указателя на код, расположенный в текущем адресном пространстве. Итак, дескриптор процесса HINSTANCE (псевдо или локальный) обычно равен 0x4000000. Передача данного дескриптора от одного процесса к другому не работает. Чтобы получить реальный дескриптор текущего процесса, можно использовать OpenProcess():

Код
OpenProcess(PROCESS_ALL_ACCESS, FALSE, GetCurrentProcessId());

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

Код
SOCKET ConvertProcessSocket(SOCKET oldsocket, DWORD source_pid)
<
HANDLE source_handle = OpenProcess(PROCESS_ALL_ACCESS,
FALSE, source_pid);
HANDLE newhandle;
DuplicateHandle(source_handle, (HANDLE)oldsocket,
GetCurrentProcess(), &newhandle, 0, FALSE,
DUPLICATE_CLOSE_SOURCE | DUPLICATE_SAME_ACCESS);
CloseHandle(source_handle);
return (SOCKET)newhandle;
>

Данный пример отлично работает на многопроцессорном вебсервере. Данная функция передаёт сокет в новый процесс и закрывает дескриптор старого процесса. Дескриптор имеет те же свойства что и старый, но не может быть унаследован дочерним процессом. Чтобы исправить это, достаточно в DuplicateHandle() изменить FALSE на TRUE. Как мы видим, дескриптор основного процесса может быть псевдо-дескриптором, но дескриптор второго процесса обязан быть реальным.

Алгоритм таков: исходный процесс конвертирует локальный дескриптор SOCKET в реальный дескриптор при помощи OpenProcess(), затем передаёт это значение и ID процесса другому процессу. Второй процесс вызывает функцию ConvertProcessSocket(), чтобы преобразовать реальный дескриптор в локальный, который уже можно будет использовать в Winsock. Обратите внимание, что вызов DuplicateHandle() закрывает дескриптор первого процесса, а затем функция CloseHandle() закрывает реальный дескриптор, который вы передаёте второму процессу.

Недостатки: данная методика скорее всего работает только со стеком Microsoft. Однозначно не будет работать в Win16, и, возможно в WinCE. Не извесно, будет или нет работать в присутствие Layered Service Providers, исключая Windows NT 4.0 SP 4+, в которой пропатчен уровень Installable FileSystems (IFS). Возможно найдутся ещё причины, по которым данный метод может не сработать

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL