Ответы пользователя по тегу Сокеты
  • Почему send позволяет отправлять little-endian данные?

    Понятие big endian и little endian есть у многобайтных типов фиксированной длины (обычно целочисленных) в адресном пространстве. В сети нет адресации данных, поэтому нет понятия big endian и little endian, есть понятие прямого и обратного сетевого порядка байт.
    Функции send/recv оперируют не с многобайтными целыми числами, а с буфером памяти произвольной длины и ничего не знают о том, какие именно данные в этих буферах находятся и о представлении хранящихся в них целочисленных данных, если таковые там есть. Поэтому данные по сети будут отправлены в том порядке, в котором они находятся в адресном пространстве в отправляемом буфере.

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

    P.S. а вообще у вас там лишний бекслеш перед H в текстовой константе.
    Ответ написан
  • Что произойдет, если я подключусь к синхронному запросу в базе данных в асинхронном сокет-сервере Workerman?

    Если у вас в worker'е случается синхронный запрос, то воркер подвисает до окончания этого запроса. Фактический результат зависит от разных параметров: того, сколько имеется воркеров, как запросы распределяются по воркерам, какая нагрузка на сервис. Если такое происходит на достаточно большом проценте запросов и сервис достаточно нагружен, то в какой-то момент начнут висеть все воркеры. По мере увеличения нагрузки это будет выглядеть так: сначала (пока количество воркеров больше количества одновременных запросов) может вообще не проявляться, потом появится большой разброс во времени обработки клиентских запросов, а затем все умрет.
    Ответ написан
  • Сколько сокетов соединений может быть на одном порту и на все системе?

    Для входящего соединения создается новый сокет, поэтому лимит определяется в основном тем, сколько активных сокетов может быть в системе. Для каждого сокета требуется файловый дискриптор и некоторое количество системных буферов. Плюс, для обработки сетевых событий требуются процессорные мощности. При этом упереться можно в разные лимиты - самое первое, это ulimit'ы (по умолчанию в Linux пользовать может создать 1024 файловых дискриптора), они легко повышаются. В какой-то момент вы упретесь в лимиты ядра, и вам придется пересобирать ядро с кастомными параметрами. В конце концов, вы упретесь в физические лимиты машины (например в лимит на физическую память, которая требуется для системных буферов), если не упретесь раньше в лимиты по производительности. Поэтому "сколько" вопрос более риторический, смотря что вы хотите сделать. Если поставить рекорд - то можно собрать систему которая будет держать миллионы соединений. Реальная система на реальных запросах скорей всего раньше упрется в нехватку других ресурсов.
    Ответ написан
  • Зачем устанавливается размер сокета SO_SNDBUF в исходниках traceroute?

    По всей видимости, это нужно, чтобы следующий пакет мог быть поставлен в очередь только тогда, когда ушел предыдущий, чтобы более точно вычислять задержки/таймауты.
    Ответ написан
  • Что читать про интеграцию REST, SOAP, JSON, RMI и т.д для аналитика, который в этом ничего не понимает?

    Вам не хватает фундаментальных знаний, в данном случае вам сильно помогло бы представление о модели ISO/OSI + основные представления о классах и объектах.

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

    1. Сетевое соединение - способ установить соединение между двумя приложениями (например клиентским и серверным). Сокет является представлением такого соединения на уровне операционной системы и приложения (т.е. этим пняием оперирует разработчик пишущий сетевое приложение).
    2. Прикладной протокол - описывает взаимодейтвие клиента и сервера, чаще всего через установленное сетевое соединение (т.е. с програмной точки зрения через сокет). Например, HTTP или SMTP. Т.е. прикладные протоколы находятся над сокетами.

    сокеты и сетевые протоколы относятся к модели ISO/OSI

    3. Форматы обмена данных. Есть несколько универсальных форматов позволяющих описывать практически любые данные. К ним относятся, например, XML и JSON. JSON является альтернативой XML (он несколько проще и компактней). По JSON и XML есть соответствующие стандарты.
    Данные в этих форматах могут храниться или пердаваться поверх прикладных протоколов (например поверх HTTP).

    4. Модели данных (классы). Модель данных описывает определенный класс данных. Например, заказ. Она определяет какие свойства есть у заказа (дата, сумма, товар, покупатель, продавец, дата доставки и т.д.). Модели данных бумают универсальные и бывают разработанные под конкретное приложение. Существуют различные стандарты описывающие модели данных и связи между ними - XML schema, JSON-LD. Универсальные модели данных можно найти на schema.og. Разработчики приложения могут создать свою модель данных. Модели данных могут быть описаны как для XML так и для JSON.

    5. API (программные компоненты) использующие модели данных. В частности SOAP и REST API. При этом SOAP является стандартом на подобные API и используется обычно для универсальных интегрируемых между собой компонент, SOAP использует XML. REST API это достаточно условный термин, который может быть применен практически к любому API который принимает или отдает структурированные данные (как поверх XML так и поверх JSON). SOAP ближе к объектной модели данных, REST API ближе к классическому API и используется для простых клиент-серверных приложений.
    WSDL просто один из элементов SOAP.
    Т.е. SOAP работает поверх XML schema поверх XML поверх HTTP (например) поверх соединения через сокет.

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

    последние три уровня не относятся к модели ISO/OSI, это уже из область прикладной разработки / дизайна.

    Вопрос про HD-фильм это вопрос из области можно ли переслать слона по почте. Через сокет можно передавать любые данные, в XML/JSON тоже можно упаковать любые данные, по прикладному протоколу тоже можно пердать любые данные и т.д. Более того, есть DLNA который фактически является REST API поверх XML и поддерживается любым современным телевизиром именно для передачи фильмов, в т.ч. HD. Т.е. создать конкретную реализацию приложений которая будет поддерживать HD фильмы можно, но ожидать что любая реализация SOAP/REST API поволит передавать HD фильмы нельзя, они делаются под определенные задачи.
    На практике как правило есть конкретная реализация и ограничения, например на размер POST запроса или размер письма (SOAP может использовать SMTP, не только HTTP).
    Ответ написан
  • Как между собой общаются разные программы?

    Вы можете попробовать начать с этой статьи.
    Она не вполне точна, но дает общее представление.
    Ответ написан
  • Как передавать данные на сервер без статического IP?

    Можно реализовать с помощью функции connect back в 3proxy
    (один прокси ставится на домашний компьютер, один на VPS, со стороны VPS пробрасывается порт на домашний компьютер)
    https://3proxy.ru/howtor.asp#CONNBACK
    работает это похоже на вашу текущую схему.
    Но если нет каких-то серьезных причин, то правильнее сделать VPN, как вам уже посоветовали.
    Ответ написан
  • Много соединений socket. Что лучше использовать asyncio или потоки?

    При использовании одного потока с асинхронной обработкой будет задействовано только одно ядро процессора. При использвании потока на каждый запрос большие дополнительные расходы на создание потоков. Отсюда:
    1. Если каждый запрос требует серьезной обработки и грузит процессор - используйте потоки.
    2. Если запросы частые, но обработки не требует - используйте асинхронность.
    3. Если у вас действительно высокие нагрузки и нужно максимально эффективно использовать ресурсы - используйте приложение с несколькими заранее запущенными потоками (worker'ами) и в каждом из них используйте асинхронность, распределяйте запросы равномерно между воркерами. Количество воркеров должно быть не меньше, чем количество ядер.

    P.S. при исользовании любого подхода кроме один запрос - один поток, асинхронность должна быть не только на сокетах, все операции (например работа с файлами) должна быть асинхронными, чтобы не приводить к блокировке потока.
    Ответ написан
  • RFC 1928, как реализовать socks chain?

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

    Если вы запускаете сканирование под Windows, то соединения на порты 25, 80 и т.д. обычно перехватываются антивирусом или службами типа alg (application layer gateway). На mail.ru порт 25 закрыт. То что вы смогли на него подключиться просто означает что у вас какое-то приложение перехватило коннект.

    Здесь неправильно примерно все. Из того что сразу в глаза бросается:
    1. server_data перед использованием надо занулить
    2. FD_SET по умолчанию поддерживает только 64 сокета (на Windows, в *nix так же ограниченное количество). Соответственно вы сканируете только первые 64 порта
    3. connect() не даст вам ошибки подключения, т.к. вы перевели сокет в асинхронный режим, соответственно в большинстве случаев у вас будет waiting time exceeded, хотя на самом деле ошибка будет другая.
    4. там такое ощущение что кусок кода вырезан, т.к проверка сокетов попала в тот же цикл где идут коннекты.
    Ответ написан
  • TCP: правда ли, что send/write нельзя вызывать из разных потоков, иначе перепутается содержимое буферов?

    Перепутаться содержимое именно в send()/write() не должно, т.к. вывод не буферизирован, функция выполняется за один системный вызов. Но send()/write() в любом случае могут отправить не полный буфер данных, обязательно надо контролировать возвращаемое значение. И доотправлять неотправленное. Поскольку одну команду может быть придется отправлять за несколько операций send()/write() - содержимое в разных потоках может перемешаться. Правда на практике такое (отправка неполного буфера) в Windows мне не встречалось (а вот в POSIX системах это достаточно обычное явление). Но пологаться на это, разумеется, не стоит и лучше, как уже говорилось, использовать критические секции или мутексы для синхронизации отправки данных.
    Ответ написан
  • Почему функция send может вернуть количество переданных байтов, меньшее указанного в её аргументе?

    Так может быть по определению. Т.е. функция send() может отправить не все данные, и это является нормальной ситуацией. В Windows это редкая ситуация, может быть если вызван, например WSPCancelBlockingCall(). В POSIX системах это достаточно частая ситуация, которая может возникнуть при недостаточном количестве буферов или при получении сигнала, например.
    send() возвращает количество отправленных байт, проверяйте его и доотправляйте то, что не было отправлено.
    Ответ написан
  • Как работать с сокетами в несколько потоков?

    Существует 3 основных подхода.
    1. То, что вы имеете ввиду - после accept() создавать отдельный поток на каждого лиента и обрабатывать пришедший коннект в нем.
    2. Использовать один поток, переводить сокеты в неблокирующий режим и использовать select() или poll() / epol() / ... для обнаружения данных поступивших в сокет и их обработки
    3. Использовать модель с несколькими worker'ами. Запускать несколько потоков-worker'ов работающих так же как в п.2, распределять входящие коннекты между ними. Обычно так пишут серверы для достаточно большой нагрузки.
    Достаточно подробный ответ есть здесь: https://www.opennet.ru/base/faq/prog_faq.txt.html, см. "как писать сервера".
    Ответ написан
  • Как закрыть сокет (TCP) полностью?

    Устанавливайте setsockopt() опцию SO_LINGER с нулевым или маленьким таймаутом перед закрытием сокета.
    Ответ написан
  • Как протестировать кол-во открытых сокетов на сервере?

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

    поставьте легко проверяемое ограничение, например 2, и проверьте nmap'ом, что два nmap'а запустить и установтиь соединение дают, а в третьем соединение не проходит.
    Разные порты=разные сокеты. Утверждение верно?

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

    Все зависит от того, что у вас за сервис, насколько он сам по себе выдерживает параллельные запросы, в каком формате он отдает данные, какая нагрузка планируется и где прогнозируется "узкое место". Если сам по себе сервис быстрый и выплевывает небольшие порции данных в своем формате и планируются большие нагрузки, то узким местом вероятно станет веб-сервер. Тогда оптимально написать свой асинхронный прокси-демон, который будет конвертировать HTTP-запрос в запрос к сервисам, а данные, возвращаемые сервисами в JSON или XML, из PHP ничего напрямую не дергать, а подгружать JSON или XML непосредственно со страницы AJAX'ом и парсить их в браузере.
    Если сервис медленный, запросы тяжелые или он ограничен количеством одновременных запросов, то особого смысла оптимизировать нет, используйте семафоры и делайте запросы непосредственно из PHP.
    Ответ написан
  • python и сокеты: как работать с внеполосными данными?

    Давно не работал с OOB, но теоретически описанное Вами поведение должно наблюдаться только при установленной опции SO_OOBINLINE, с ней OOB-данные попадают в общий поток.
    Ответ написан
  • Лучшая методика для реализации HTTP(S) прокси сервера?

    Под Windows вариант один клиент — один тред является оптимальным, если не требуется очень большого числа одновременных подключений (скажем, порядка 10000). Если требуется что-то очень высоконагруженное, то используется вариант один тред — n клиентов на асинхронных неблокирующих сокетах с наращиванием числа тредов по необходимости.

    Но опять же могу предложить написать плагин под 3proxy, если его функционала недостаточно.
    Ответ написан