1с ошибка загрузки сетевой инфраструктуры обычно разрешается только одно использование адреса сокета
У меня есть служба WCF и веб-приложение. Веб-приложение непрерывно обращается к этой службе WCF, также как и опрос. В нашей производственной среде я получаю эту ошибку очень редко. Поскольку это внутреннее действие, о котором пользователи не знали, когда возникает эта ошибка.
У меня проблемы с воспроизведением этого поведения в нашей среде dev / qa. Я убедился, что клиентское соединение закрыто в блоке try..catch..finally. Все еще не понимаю, что вызывает эту проблему . кто-нибудь знает об этом?
Примечание . Я просмотрел это SO question, но, похоже, не отвечает на мою проблему, поэтому это не повторяющиеся вопросы.
Это потому, что веб-служба использует порт 80, который используется IIS? Какой порт использует ваш сервис в производстве? Какой порт настроен на IIS в производственной среде?
Для обоих приложений одинаковое значение 80. Служба WCF настроена как виртуальный каталог внутри корня, в котором размещен сайт. Итак, вы говорите, что иногда может возникать конфликт между запросом веб-страницы и запросом на обслуживание с веб-страницы, пытающейся использовать один и тот же порт?
2 ответа
Вы перегружаете стек TCP / IP. Windows (и я думаю, что на самом деле все стеки сокетов) имеют ограничение на количество сокетов, которые могут быть открыты в быстрой последовательности из-за того, как сокеты закрываются при нормальной работе. Всякий раз, когда сокет закрыт, он переходит в состояние TIME_WAIT на определенное время (240 секунд IIRC). Каждый раз, когда вы опрашиваете, сокет расходуется за пределы динамического диапазона по умолчанию (я думаю, что это около 5000 динамических портов чуть выше 1024), и каждый раз, когда этот опрос заканчивается, этот конкретный сокет переходит в TIME_WAIT. Если вы опрашиваете достаточно часто, вы в конечном итоге израсходуете все доступные порты, что приведет к ошибке TCP 10048.
Есть два решения, которые вы можете использовать, чтобы обойти эту проблему. Вы можете либо увеличить динамический диапазон портов, либо уменьшить период TIME_WAIT. Первый вариант, вероятно, более безопасен, но если вы потребляете очень большой объем сокетов (что не похоже на ваш сценарий), уменьшение TIME_WAIT - лучший вариант (или оба вместе).
Изменение динамического диапазона портов
- Откройте regedit.
- Откройте ключ HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters
- Отредактируйте (или создайте как DWORD) значение MaxUserPort.
- Установите более высокое значение. (т.е. 65534)
Изменение задержки TIME_WAIT
- Откройте regedit.
- Откройте ключ HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters
- Отредактируйте (или создайте как DWORD) файл TcpTimedWaitDelay.
- Установите меньшее число. Значение в секундах. (т.е. 60 для задержки в 1 минуту)
Одно из вышеперечисленных решений должно решить вашу проблему. Если он не исчезнет после изменения диапазона портов, я бы попробовал увеличить период вашего опроса, чтобы он происходил реже . это даст вам больше возможностей для работы с задержкой времени ожидания. Я бы изменил задержку времени ожидания в крайнем случае.
Полагаю, некоторые коллеги уже оказывались в ситуации, когда отладка внезапно пропадала, и различные "шаманские" методики (переустановка платформы, чистка локального кэша и прочее) результата не давали. Опишу свой опыт по выявлению и устранению причины.
Преамбула
Данная статья содержит основные моменты из моей публикации. Рассчитываю, что эта информация поможет оказавшимся в подобной ситуации решить проблему. Или хотя бы послужит примером диагностики в конкретной ситуации.
Начальное состояние
Периодические отваливается отладка. Основные подозреваемые - брандмауэр и антивирус выключены.
Анализ
Текущий порт отлачика tcp://srv1c:1562.
netstat -naot 1 | find "1562" при запуске сеанса отладки показывает наличие состояний SYN_SENT.
Настроен полный технологический журнал, поскольку заранее неизвестны события, содержащие необходимую информацию. Для сбора данных по клиентским сеансам моего пользователя файл настроек расположен в %UserProfile%\AppData\Local\1C\1cv8\conf
Значимые события технологического журнала клиента, собранного с момента запуска сеанса отладки до момента прекращения появления состояний SYN_SENT:
При соединение по TCP/IP открывается сокет и выбирается динамический порт. По умолчанию, диапазон динамических портов от 1024 по 5000. Увеличиваем до максимума.
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value: MaxUserPort
Data Type: REG_DWORD
Range: 5000 to 65534
Default value: 5000
Recommended value: 65534
Когда соединение TCP закрывается, то сокет сразу не освобождается, а переходит в статус TIME_WAIT и ресурсы освободятся только через определённое время. По умолчанию, только через 4 минуты. Снизим это время до минимума - 30 секунд.
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value: TcpTimedWaitDelay
Data Type: REG_DWORD
Range: 30 to 300
Default value: 240
Recommended value: 30
Отключение автотюнинга tcp протокола:
netsh int tcp set global autotuninglevel=disabled
Результат
Мониторинг сервера в течении нескольких дней показал, что после проведенных изменений даже при большом количестве сессий 1С отладка перестала отваливаться.
Специальные предложения
Я так понимаю, что это рекомендации к клиент-серверной версии, а что делать при такой же беде с файловой базой?
Однажды, пропала отладка для всех имеющихся баз на локальном пк, чистка кэша, отключение антивируса, брендмауэра не помогла. Впоследствии отладка сама включилась через несколько дней, из значимых событий на пк в эти дни было только обновление Skype.
Единственное, что смущает - попадание в зарезервированный диапазон динамических (эфемерных ) портов 49152 - 65535.
Может лучше сначала Range: 5000 to 49000 ?
(8) я нашел следующие разъяснения насчет диапазонов портов:
1. Номер порта выделяется для каждой сетевой службы, чтоб они работали независимо;
2. Порт назначается временно и только на время соединения. После завершения сеанса соединения порт снова становится свободен для использования, хотя в большинстве реализаций просто происходит увеличение на единицу номера последнего использованного порта вплоть до исчерпания всего диапазона эфемерных портов.
3. Номер порта - это абстракция, относящаяся к транспортному уровню (TCP & UDP), более низкие уровни (IP, ICMP, IGMP) - не имеют такой абстракции;
4. "Размещаются" порты в стеке TCP/IP, т.е. в реализованной в составе ОС части, т.е. программисту это не важно;
5. Порты для UDP & TCP - совершенно разные пространства, т.е. 21 порт UDP и 21 порт TCP - это 2 совершенно разные сущности.
6. Наконец, порты TCP/UDP подразделяются на "хорошо известные порты" (номера 0 - 1023), "динамические" (из диапазона 1024 - 49151), и "эфемерные" (49152 - 65535). Хорошо известные порты приписаны стандартным службам: telnet, ftp etc. и использоваться не должны (для других целей). Динамические порты - должны регистрироваться в международном комитете для использования новыми службами широкого применения. Эфемерные порты - это порты "оставленные" разработчикам для использования в своих частных задачах (где попало. ). Никаких гарантий об неконфликтности эфемерных портов в условиях эксплуатации, естественно, не даётся.
В этом контексте использование "эфемерного" диапазона не должно привести к каким то проблемам.
Можно более подробно разобрать, что вас смущает. Полагаю, полезно будет для всех.
Странно, у меня по умолчанию такие параметры установлены (только в шестнадцатиричной системе исчисления). Win 7 x64.
Может, стоит уточнить для каких ОС этот рецепт предназначен.
(10) по умолчанию этих параметров в соответствующих разделах реестра нет. В вашем случае, когда добавляли эти параметры, перед вводом значений не переключили предварительно систему исчисления в десятичную. При создании в форме ввода значения параметра по умолчанию установлена шестнадцатиричная, что объясняет ваши значения.
Применил параметры реестра, всё равно отладка не работает. Отлаживаю вебсервис (на клиенте и сервере отладка работает). На локальном компьютере iis и конфигуратор, на сервере сервер 1с и sql. Фаерволы, антивирусы отключены. В публикации прописал адрес отладки (в разных вариациях пробовал) из настроек отладки. Автоматическое подключение вебсервисов стоит. В тех журнале на клиенте такое (см скрин). Делал netsh winsock reset - не помогло. Есть какие-то мысли?
P.S. Отладка вчера работала, а сегодня отвалилась. Перезагружал и сервер и свою машину по нескольку раз, ничего не помогает.
(13) Да, я делал так, как было в инструкции, но это всё равно не помогло. В итоге, после n-ной попытки переопубликации вебсервиса и перезапуска его, отладка удивительным образом заработала. Шайтан.
Текущий порт отлачика tcp://srv1c:1562.
Как поменять текущий порт отладчика ?
(15) как минимум он устанавливается автоматически отладчиком. Иначе только менять диапазон в настройках "Конфигуратор" - "Отладка" - "Подключение". В открывшейся форме "Параметры отладки" кнопка снизу слева "Настройка" - регулировка диапазона используемых для отладки портов. Но какой порт платформа займет в каждом отдельном случае - ее усмотрение, будет занимать по порядку не занятые.
Сколько же я мучался.. и на всех последних платформах.
Решение принял другое - переход на отладку по http протоколу. Ничего не "отваливается".
Жаль, что раньше эту статью не увидел.
Сервер 1С находится на одном сервере, пользователи подключаются с другого сервера по тонкому клиенту.
Столкнулись с проблемой: после какого-то кол-ва пользователей зашедших в базу, новых перестает пускать - просто падает платформа. Началось внезапно, ничего не меняли, ни конфигурацию, ни платформу, ни сервер. На текущей платформе проработали больше месяца нормально. Через технологический журнал на клиенте выцепил ошибку, с которой падает платформа "Обычно разрешается одно использование адреса сокета (протокол/сетевой адрес/порт)". Ошибку это возвращает платформе винда, везде пишут, что проблема в том, что не хватает динамических портов, которые можно расширить через реестр, но это не помогло.
Через netstat -ano на сервере удаленных рабочих столов, откуда подключаются пользователи видно, что заняты все порты с 1560 по 1591 тонким клиентом. Но многие клиенты сидят на рандомных портах типа 45434. Заметили, что новые пользователи не могут зайти в базу, когда все порты 1560-1591 заняты. Если убить любого тонкого клиента, который занимает порт в этом диапазоне и порт освобождается, то новый пользователь может зайти в базу.
Так же, когда все эти порты заняты, не получается запустить отладку из конфигуратора, ругается на "Для выполнения отладки необходимо включить поддержку сетевого протокола TCP/IP" - что тоже описано в инете как проблема занятых портов.
Не понятно, зачем тонкому клиенту на сервере удаленных рабочих столов занимать эти порты, ведь используются они сервером 1С для рабочих процессов. И почему когда свободных портов нет на РДП сервере, клиент не может подключиться к серверу 1С. Но часть клиентов спокойно висят на рандомных портах типа 45434. Такое ощущение, что при коннекте, клиент все таки занимает какой-то из портов в этом диапазоне, а после этого его перекидывает на любой свободный до 65535, но эти порты из диапазона 1560-1591 не успевают освободиться.
Объясните, по какому принципу клиент занимает порты и можно ли это как-то где-то настроить? То, что происходит в описанной ситуации это какой-то сбой либо некорректная настройка и достаточно в настройках службы 1С указать бОльший пул портов? Но никогда не слышал, чтобы в базах, где работает большое кол-во пользователей, увеличивали диапазон портов для рабочих процессов на сервере 1С.
В первый раз появилось на платформе 8.3.14.1854, после этого откатились на 8.3.12.1685, на которой были несколько месяцев, ситуация не изменилась.
вам хватит на 1 локальный порт 1561 всех подключить
сбрасывайте настройки в дефолт, переустанавливайте платформу.
(2) Так какие настройки? На РДП сервере стоит только тонкий клиент, какие и где там настройки можно сбросить?
6. Необходимо настроить сетевой стек для обеспечения возможности обработки большого числа подключений
Настройки, которые необходимо выполнить (в дополнение к настройке 5.2. Настроить рабочий сервер в соответствии с инструкцией):
Устанавливаем диапазон исходящих портов (1025; 65535)
Выполнить: netsh int ipv4 set dynamic port tcp start=1025 num=64510
Выполнить: netsh int ipv4 set dynamic port udp start=1025 num=64510
(4) Все эти настройки сделаны, это все как раз гуглится по ошибке "Обычно разрешается одно использование адреса сокета (протокол/сетевой адрес/порт)". Но легче не стало вообще. Да и 80 пользователей не так много.
Проблема в том, что тонкий клиент почему-то занимает 1560-1591 порты на рдп сервере (не на 1С сервере) и из-за этого не могут подключаться новые клиенты. Так как если через netstat выбрать клиента, который занял 1560 порт, завершить его, то другой пользователь сможет зайти.
Тема сетевого программирования является для разработчиков одной из важнейших в современном цифровом мире. Правда, надо признать, что большая часть сетевого программирования сосредоточена в области написания скриптов исполнения для web-серверов на языках PHP, Python и им подобных. Как следствие - по тематике взаимодействия клиент-сервер при работе с web-серверами написаны терабайты текстов в Интернете. Однако когда я решил посмотреть, что же имеется в Интернете по вопросу программирования сетевых приложений с использованием голых сокетов, то обнаружил интересную вещь: да, такие примеры конечно же есть, но подавляющее большинство написано под *nix-системы с использованием стандартных библиотек (что понятно – в области сетевого программирования Microsoft играет роль сильно отстающего и менее надежного «собрата» *nix-ов). Другими словами все эти примеры просто не будут работать под Windows. При определенных танцах с бубнами код сетевого приложения под Linux можно запустить и под Windows, однако это еще более запутает начинающего программиста, на которого и нацелены большинство статей в Интернете с примерами использования сокетов.
вообще не заработает, т.к. полю Service.sin_addr.s_addr невозможно присвоить значение целого типа, которое возвращает функция inet_addr (возвращает unsigned long). То есть это ни много, ни мало - ошибка! Можно себе представить, сколько пытливых бойцов полегло на этом месте кода.
Сразу оговорюсь, что статья рассчитана на начинающих программистов, которые только входят в сетевое программирование под Windows. Необходимые навыки – базовое знание С++, а также теоретическая подготовка по теме сетевых сокетов и стека технологии TCP/IP.
Теория сокетов за 30 секунд для "dummies"
Начну всё-таки немного с теории в стиле «for dummies». В любой современной операционной системе, все процессы инкапсулируются, т.е. скрываются друг от друга, и не имеют доступа к ресурсам друг друга. Однако существуют специальные разрешенные способы взаимодействия процессов между собой. Все эти способы взаимодействия процессов можно разделить на 3 группы: (1) сигнальные, (2) канальные и (3) разделяемая память.
Когда мы говорим про работу сетевого приложения, то всегда подразумеваем взаимодействие процессов: процесс 1 (клиент) пытается что-то послать или получить от Процесса 2 (сервер). Наиболее простым и понятным способом организации сетевого взаимодействия процессов является построение канала между этими процессами. Именно таким путём и пошли разработчики первых сетевых протоколов. Получившийся способ взаимодействия сетевых процессов в итоге оказался многоуровневым: основной программный уровень - стек сетевой технологии TCP/IP, который позволяет организовать эффективную доставку пакетов информации между различными машинами в сети, а уже на прикладном уровне тот самый «сокет» позволяет разобраться какой пакет какому процессу доставить на конкретной машине.
Иными словами «сокет» - это «розетка» конкретного процесса, в которую надо подключиться, чтобы этому процессу передать какую-либо информацию. Договорились, что эта «розетка» в Сети описывается двумя параметрами – IP-адресом (для нахождения машины в сети) и Портом подключения (для нахождения процесса-адресата на конкретной машине).
Для того, чтобы сокеты заработали под Windows, необходимо при написании программы пройти следующие Этапы:
Инициализация сокетных интерфейсов Win32API.
Инициализация сокета, т.е. создание специальной структуры данных и её инициализация вызовом функции.
«Привязка» созданного сокета к конкретной паре IP-адрес/Порт – с этого момента данный сокет (его имя) будет ассоциироваться с конкретным процессом, который «висит» по указанному адресу и порту.
Для серверной части приложения: запуск процедуры «прослушки» подключений на привязанный сокет.
Для клиентской части приложения: запуск процедуры подключения к серверному сокету (должны знать его IP-адрес/Порт).
Акцепт / Подтверждение подключения (обычно на стороне сервера).
Обмен данными между процессами через установленное сокетное соединение.
Закрытие сокетного соединения.
Итак, попытаемся реализовать последовательность Этапов, указанных выше, для организации простейшего чата между клиентом и сервером. Запускаем Visual Studio, выбираем создание консольного проекта на С++ и поехали.
Этап 0: Подключение всех необходимых библиотек Win32API для работы с сокетами
Сокеты не являются «стандартными» инструментами разработки, поэтому для их активизации необходимо подключить ряд библиотек через заголовочные файлы, а именно:
WinSock2.h – заголовочный файл, содержащий актуальные реализации функций для работы с сокетами.
WS2tcpip.h – заголовочный файл, который содержит различные программные интерфейсы, связанные с работой протокола TCP/IP (переводы различных данных в формат, понимаемый протоколом и т.д.).
Ну и в конце Этапа 0 подключаем стандартные заголовочные файлы iostream и stdio.h
Итого по завершению Этапа 0 в Серверной и Клиентской частях приложения имеем:
Обратите внимание: имя системной библиотеки ws2_32.lib именно такое, как это указано выше. В Сети есть различные варианты написания имени данной библиотеки, что, возможно, связано иным написанием в более ранних версиях ОС Windows. Если вы используете Windows 10, то данная библиотека называется именно ws2_32.lib и находится в стандартной папке ОС: C:/Windows/System32 (проверьте наличие библиотеки у себя, заменив расширение с “lib” на “dll”).
Этап 1: Инициализация сокетных интерфейсов Win32API
Прежде чем непосредственно создать объект сокет, необходимо «запустить» программные интерфейсы для работы с ними. Под Windows это делается в два шага следующим образом:
Нужно определить с какой версией сокетов мы работаем (какую версию понимает наша ОС) и
Запустить программный интерфейс сокетов в Win32API. Ну либо расстроить пользователя тем, что ему не удастся поработать с сокетами до обновления системных библиотек
Первый шаг делается с помощью создания структуры типа WSADATA , в которую автоматически в момент создания загружаются данные о версии сокетов, используемых ОС, а также иная связанная системная информация: WSADATA wsData;
Второй шаг – непосредственный вызов функции запуска сокетов с помощью WSAStartup() . Упрощённый прототип данной функции выглядит так:
Первый аргумент функции – указание диапазона версий реализации сокетов, которые мы хотим использовать и которые должны быть типа WORD . Этот тип данных является внутренним типом Win32API и представляет собой двухбайтовое слово (аналог в С++: unsigned short ). Функция WSAStartup() просит вас передать ей именно WORD , а она уже разложит значение переменной внутри по следующему алгоритму: функция считает, что в старшем байте слова указана минимальная версия реализации сокетов, которую хочет использовать пользователь, а в младшем – максимальная. По состоянию на дату написания этой статьи (октябрь 2021 г.) актуальная версия реализации сокетов в Windows – 2. Соответственно, желательно передать и в старшем, и в младшем байте число 2. Для того, чтобы создать такую переменную типа WORD и передать в её старший и младший байты число 2, можно воспользоваться Win32API функцией MAKEWORD(2,2) .
Второй аргумент функции – просто указатель на структуру WSADATA , которую мы создали ранее и в которую подгрузилась информация о текущей версии реализации сокетов на данной машине.
WSAStartup() в случае успеха возвращает 0, а в случае каких-то проблем возвращает код ошибки, который можно расшифровать последующим вызовом функции WSAGetLastError() .
Важное замечание: поскольку сетевые каналы связи и протоколы в теории считаются ненадежными (это отдельный большой разговор), то критически важно для сетевого приложения анализировать все возможные ошибки, которые возникают в процессе вызовов сокетных функций. По этой причине каждый вызов таких функций мы будем анализировать на ошибки и в случае их обнаружения завершать сетевые сеансы и закрывать открытые сокеты. Используем для этого переменную erStat типа int .
Также важно после работы приложения обязательно закрыть использовавшиеся сокеты с помощью функции closesocket(SOCKET ) и деинициализировать сокеты Win32API через вызов метода WSACleanup() .
Итого код Этапа 1 следующий:
Да, кода мало, а описания много. Так обычно и бывает, когда хочешь глубоко в чем-то разобраться. Так что на лабе будешь в первых рядах.
Этап 2: Создание сокета и его инициализация
Сокет в С++ – это структура данных (не класс) типа SOCKET. Её инициализация проводится через вызов функции socket() , которая привязывает созданный сокет к заданной параметрами транспортной инфраструктуре сети. Выглядит прототип данной функции следующим образом:
Семейство адресов: сокеты могут работать с большим семейством адресов. Наиболее частое семейство – IPv4. Указывается как AF_INET .
Тип сокета: обычно задается тип транспортного протокола TCP ( SOCK_STREAM ) или UDP ( SOCK_DGRAM ). Но бывают и так называемые "сырые" сокеты, функционал которых сам программист определяет в процессе использования. Тип обозначается SOCK_RAW
Тип протокола: необязательный параметр, если тип сокета указан как TCP или UDP – можно передать значение 0. Тут более детально останавливаться не будем, т.к. в 95% случаев используются типы сокетов TCP/UDP.
При необходимости подробно почитать про функцию socket() можно здесь.
Код Этапа 2 будет выглядеть так:
Этап 3: Привязка сокета к паре IP-адрес/Порт
Сокет уже существует, но еще неполноценный, т.к. ему не назначен внешний адрес, по которому его будут находить транспортные протоколы по заданию подключающихся процессов, а также не назначен порт, по которому эти подключающиеся процессы будут идентифицировать процесс-получатель.
Такое назначение делается с помощью функции bind() , имеющей следующий прототип:
Функция bind() возвращает 0 , если удалось успешно привязать сокет к адресу и порту, и код ошибки в ином случае, который можно расшифровать вызовом WSAGetLastError() - см. итоговый код Этапа 3 далее.
Тут надо немножно притормозить и разобраться в том, что за такая структура типа sockaddr передается вторым аргументом в функцию bind() . Она очень важна, но достаточно запутанная.
Итак, если посмотреть в её внутренности, то выглядят они очень просто: в ней всего два поля – (1) первое поле хранит семейство адресов, с которыми мы уже встречались выше при инициализации сокета, а (2) второе поле хранит некие упакованные последовательно и упорядоченные данные в размере 14-ти байт. Бессмысленно разбираться детально как именно эти данные упакованы, достаточно лишь понимать, что в этих 14-ти байтах указан и адрес, и порт, а также дополнительная служебная информация для других системных функций Win32API .
Но как же явно указать адрес и порт для привязки сокета? Для этого нужно воспользоваться другой структурой, родственной sockaddr , которая легко приводится к этому типу - структурой типа sockaddr_in .
В ней уже более понятные пользователю поля, а именно:
Семейство адресов - опять оно ( sin_family )
Вложенная структура типа in_addr , в которой будет храниться сам сетевой адрес ( sin_addr )
Технический массив на 8 байт ( sin_zero[8] )
При приведении типа sockaddr_in к нужному нам типу sockaddr для использования в функции bind() поля Порт (2 байта), Сетевой адрес (4 байта) и Технический массив (8 байт) как раз в сумме дают нам 14 байт, помещающихся в 14 байт, находящихся во втором поле структуры sockaddr . Первые поля у указанных типов совпадают – это семейство адресов сокетов (указываем AF_INET ). Из этого видно, что структуры данных типа sockaddr и sockaddr_in тождественны, содержат одну и ту же информацию, но в разной форме для разных целей.
Соответственно, ввод данных для структуры типа sockaddr_in выглядит следующим образом:
Создание структуры типа sockaddr_in : sockaddr_in servInfo;
Заполнение полей созданной структуры servInfo
servInfo.sin_port = htons(); порт всегда указывается через вызов функции htons() , которая переупаковывает привычное цифровое значение порта типа unsigned short в побайтовый порядок понятный для протокола TCP/IP (протоколом установлен порядок указания портов от старшего к младшему байту или «big-endian»).
Далее нам надо указать сетевой адрес для сокета. Тип этого поля – структура типа in_addr , которая по своей сути представляет просто особый «удобный» системным функциям вид обычного строчного IPv4 адреса. Таким образом, чтобы указать этому полю обычный IPv4 адрес, его нужно сначала преобразовать в особый числовой вид и поместить в структуру типа in_addr .
Благо существует функция, которая переводит обычную строку типа char[] , содержащую IPv4 адрес в привычном виде с точками-разделителями в структуру типа in_addr – функция inet_pton() . Прототип функции следующий:
В случае ошибки функция возвращает значение меньше 0.
Соответственно, если мы хотим привязать сокет к локальному серверу, то наш код по преобразованию IPv4 адреса будет выглядеть так:
erStat = inet_pton(AF_INET, “127.0.0.1”, &ip_to_num);
Результат перевода IP-адреса содержится в структуре ip_to_num. И далее мы передаем уже в нашу переменную типа sockaddr_in значение преобразованного адреса:
Вся нужная информация для привязки сокета теперь у нас есть, и она хранится в структуре servInfo . Можно смело вызывать функцию bind() , не забыв при этом привести servInfo из типа sockaddr_in в требуемый функции sockaddr* . Тогда итоговый код Этапа 3 (слава богу закончили) выглядит так:
Этап 4 (для сервера): «Прослушивание» привязанного порта для идентификации подключений
Серверная часть готова к прослушке подключающихся «Клиентов». Для того, чтобы реализовать данный этап, нужно вызвать функцию listen() , прототип которой:
Второй аргумент: максимально возможное число подключений устанавливается через передачу параметр SOMAXCONN (рекомендуется). Если нужно установить ограничения на количество подключений – нужно указать SOMAXCONN_HINT(N) , где N – кол-во подключений. Если будет подключаться больше пользователей, то они будут сброшены.
После вызова данной функции исполнение программы приостанавливается до тех пор, пока не будет соединения с Клиентом, либо пока не будет возвращена ошибка прослушивания порта. Код Этапа 4 для Сервера:
Этап 4 (для Клиента). Организация подключения к серверу
Код для Клиента до текущего этапа выглядит даже проще: необходимо исполнение Этапов 0, 1 и 2. Привязка сокета к конкретному процессу ( bind() ) не требуется, т.к. сокет будет привязан к серверному Адресу и Порту через вызов функции connect() (по сути аналог bind() для Клиента). Собственно, после создания и инициализации сокета на клиентской стороне, нужно вызвать указанную функцию connect() . Её прототип:
Функция возвращает 0 в случае успешного подключения и код ошибки в ином случае.
Процедура по добавлению данных в структуру sockaddr аналогична тому, как это делалось на Этапе 3 для Сервера при вызове функции bind() . Принципиально важный момент – в эту структуру для клиента должна заноситься информация о сервере, т.е. IPv4-адрес сервера и номер «слушающего» порта на сервере.
Этап 5 (только для Сервера). Подтверждение подключения
После начала прослушивания (вызов функции listen() ) следующей функцией должна идти функция accept() , которую будет искать программа после того, как установится соединение с Клиентом. Прототип функции accept() :
Если подключение подтверждено, то вся информация по текущему соединению передаётся на новый сокет, который будет отвечать со стороны Сервера за конкретное соединение с конкретным Клиентом. Перед вызовом accept() нам надо создать пустую структуру типа sockaddr_in , куда запишутся данные подключившегося Клиента после вызова accept() . Пример кода:
Всё, соединение между Клиентом и Сервером установлено! Самое время попробовать передать информацию от Клиента к Серверу и обратно. Как мы в начале и договорились, мы будет реализовывать простейший чат между ними.
Этап 6: Передача данных между Клиентом и Сервером
Принимать информацию на любой стороне можно с помощью функции recv() , которая при своём вызове блокирует исполнение кода программы до того момента, пока она не получит информацию от другой стороны, либо пока не произойдет ошибка в передаче или соединении.
Отправлять информацию с любой стороны можно с помощью функции send() . При вызове данной функции обычно никакого ожидания и блокировки не происходит, а переданные в неё данные сразу же отправляются другой стороне.
Рассмотрим прототипы функций recv() и send() :
Флаги в большинстве случаев игнорируются – передается значение 0.
Функции возвращают количество переданных/полученных по факту байт.
Как видно из прототипов, по своей структуре и параметрам эти функции совершенно одинаковые. Что важно знать:
и та, и другая функции не гарантируют целостности отправленной/полученной информации. Это значит, что при реализации прикладных задач по взаимодействию Клиента и Сервера с их использованием требуется принимать дополнительные меры для контроля того, что все посланные байты действительно посланы и, что еще более важно, получены в том же объеме на другой стороне
предельно внимательно надо относиться к параметру "размер буфера". Он должен в точности равняться реальному количеству передаваемых байт. Если он будет отличаться, то есть риск потери части информации или «замусориванию» отправляемой порции данных, что ведет к автоматической поломке данных в процессе отправки/приёма. И совсем замечательно будет, если размер буфера по итогу работы функции равен возвращаемому значению функции – размеру принятых/отправленных байт.
В качестве буфера рекомендую использовать не классические массивы в С-стиле, а стандартный класс С++ типа char, т.к. он показал себя как более надежный и гибкий механизм при передаче данных, в особенности при передаче текстовых строк, где важен терминальный символ и «чистота» передаваемого массива.
Сама по себе упаковка и отправка данных делается элементарным использованием функций чтения всей строки до нажатия кнопки Ввода - fgets() с последующим вызовом функции send() , а на другой стороне - приёмом информации через recv() и выводом буфера на экран через cout
Процесс непрерывного перехода от send() к recv() и обратно реализуется через бесконечный цикл, из которого совершается выход по вводу особой комбинации клавиш. Пример блока кода для Серверной части:
Пришло время показать итоговый рабочий код для Сервера и Клиента. Чтобы не загромождать и так большой текст дополнительным кодом, даю ссылки на код на GitHub:
Несколько важных финальных замечаний:
В итоговом коде я не использую проверку на точное получение отосланной информации, т.к. при единичной (не циклической) отсылке небольшого пакета информации накладные расходы на проверку его получения и отправку ответа будут выше, чем выгоды от такой проверки. Иными словами – такие пакеты теряются редко, а проверять их целостность и факт доставки очень долго.
В последующих статьях я покажу реализацию полноценного чата между двумя сторонами (поможет разобраться в понятии «нити процесса»), а также покажу полноценную реализацию прикладного протокола по копированию файлов с Сервера на Клиент.
Попытался написать в Delphi простенький чат с использованием ServerSocket и ClientSocket в их свойства Port вписал значение 1111 и при компиляции Delphi и само приложение начали выдавать ошибку:
Project Project1.exe raised exception class ESocketError with message 'Windows socket error: Обычно разрешается одно использование адреса сокета (протокол/сетевой адрес/порт) (10048), on API 'bind''. Use Step or Run to continue.
Exception ESocketError in module Project1.exe at 00056B22.
Windows socket error: Обычно разрешается одно использование адреса сокета (протокол/сетевой адрес/порт) (10048), on API 'bind'.
Проблему решил, просто в компоненте ClientSocket в свойстве Active не поменял значение False на True, эти ошибки не выдоёт, но зато стала выдавать другие ошибки:
Project Project1.exe raised exception class ESocketError with message 'No address specified'.
А само приложение:
Exception ESocketError in module Project1.exe at 00056EDE.
No address specified.
Проблему решил, просто в компоненте ClientSocket в свойстве Active не поменял значение False на True, эти ошибки не выдоёт, но зато стала выдавать другие ошибки:
Project Project1.exe raised exception class ESocketError with message 'No address specified'.
А само приложение:
Exception ESocketError in module Project1.exe at 00056EDE.
No address specified.
Скорее всего это значит, на этом порту уже кто-то сидит и слушает. Сдается мне, что у тебя каждый экземпляр твоего чата открывает сервер сокет, а это немножко неправильно.
Проблему решил, просто в компоненте ClientSocket в свойстве Active не поменял значение False на True, эти ошибки не выдоёт, но зато стала выдавать другие ошибки:
Project Project1.exe raised exception class ESocketError with message 'No address specified'.
А само приложение:
Exception ESocketError in module Project1.exe at 00056EDE.
No address specified.
Спрашивали тут уже, используй:
Читайте также: