привет!

подключаюсь к некоторому серверу, который в данный момент не "слушает" порт, и получаю connection timed out спустя 5 минут.
расстраивает то, что нужно ждать аж пять минут.

в гугле есть решения по переводу сокета в неблокирующий режим, но для этого нужно иметь валидный дескриптор сокета. но boost::asio::ip::tcp::socket получает валидный дескриптор только после коннекта.
т.е. этот код работать не будет до тех пор, пока не подключишься:

boost::asio::ip::tcp::socket socket(io_service);
boost::asio::socket_base::non_blocking_io command(true);
socket.io_control(command);

есть еще вариант создавать дескриптор сокета при помощи int s = ::socket(...); и передавать его в констуктор, но как-то некрасиво...

есть идеи?

спасибо.

Здравствуйте, niXman, Вы писали:

X>есть идеи?

дедлайн таймер на закрытие сокета, не?

X>спасибо.

пожалуйста.

Здравствуйте, antropolog, Вы писали:

A>дедлайн таймер на закрытие сокета, не?
ну этож совсем крайний вариант...

Здравствуйте, niXman, Вы писали:

X>подключаюсь к некоторому серверу, который в данный момент не "слушает" порт, и получаю connection timed out спустя 5 минут.

Восхитительный пример для недавней темы "Поугараем над С++". То, что есть в чистом socket api уже десятилетия, до сих пор отсутствует в чудо-библиотеках с пространствами имён вида "boost::asio::ip::tcp::socket". Сразу видно, на века делали. А вдруг там будет не ip? А вдруг там будет не tcp? А у нас для этого неймспейс имеется, мы умные, мы предусмотрели!

По самому вопросу — вот создавайте сокет отдельно и передавайте его дескриптор. Заверните это в красивую ООП-обёртку.

Минусующих прошу пояснить вашу позицию.

Здравствуйте, Слава, Вы писали:

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

p.s.
и ещё топикстартер с тонкой душевной организацией и больным чсв))

Здравствуйте, antropolog, Вы писали:

A>... просто автор совсем не понимает что делает
смешной, однако)

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

Здравствуйте, niXman, Вы писали:

X>возьми дескриптор у неподключенного сокета и поработай с ним, о понимающий...

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

Здравствуйте, antropolog, Вы писали:

A>давай ты начнёшь с того, что расскажешь, зачем ты хочешь перевести сокет в неблокирующий режим.
начинать нужно с тебя.
показывай, как ты используешь мертвый сокет(т.е. -1) и какой от этого профит?

Здравствуйте, niXman, Вы писали:

X>начинать нужно с тебя.

всё понятно. гугли дальше с таким тоном.

Здравствуйте, antropolog, Вы писали:

X>>возьми дескриптор у неподключенного сокета и поработай с ним, о понимающий...
A>давай ты начнёшь с того
A>давай ты начнёшь с того
A>давай ты начнёшь с того

Я понимаю, что это злостный оффтопик, но мне кажется, что в обсуждении отчаянно не хватает фразы "православное кадило"

Таймаут по умолчанию обычно составляет примерно 72 секунды, это 5 отправок SYN с увеличивающимся интервалом ожидания ответа SYN, ASK. Откуда у топикстартера 5 минут-то взялись? Явно что-то не системное.

Здравствуйте, niXman, Вы писали:

X>подключаюсь к некоторому серверу, который в данный момент не "слушает" порт, и получаю connection timed out спустя 5 минут.
X>расстраивает то, что нужно ждать аж пять минут.

Так а подключаетесь-то вы как? Через async_connect или через connect?

Если через async_connect, то какая разница спустя какое время вы получаете ошибку?

Здравствуйте, niXman, Вы писали:

X>в гугле есть решения по переводу сокета в неблокирующий режим, но для этого нужно иметь валидный дескриптор сокета. но boost::asio::ip::tcp::socket получает валидный дескриптор только после коннекта.
X>есть идеи?

Есть: прочитать чуть дальше доку про open().

#include <boost/asio.hpp>
#include <stdio.h>
int main() {
    boost::asio::io_service io_service;
    boost::asio::ip::tcp::socket s1{io_service};
    boost::asio::ip::tcp::endpoint endpoint{};
    s1.open(endpoint.protocol());
    s1.non_blocking(true);
    printf("%d\n", (int) s1.native_handle());
}

выдаёт: 6.
strace подтверждает:

16551 18:11:05.785966 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6
16551 18:11:05.786018 epoll_ctl(4, EPOLL_CTL_ADD, 6, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP|EPOLLET, {u32=17247824, u64=17247824}}) = 0
16551 18:11:05.786066 ioctl(6, FIONBIO, [1]) = 0
16551 18:11:05.786173 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 24), ...}) = 0
16551 18:11:05.786228 write(1, "6\n", 2) = 2

Здравствуйте, so5team, Вы писали:

S>Если через async_connect, то какая разница спустя какое время вы получаете ошибку?

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

повторюсь — сама ошибка меня вполне устраивает ибо она логична. не устраивает именно время получения этой ошибки.

Здравствуйте, netch80, Вы писали:

N>Есть: прочитать чуть дальше доку про open().
да, про open() я не подумал... и вообще никогда его не использовал.
проверю в понедельник, отпишусь.

Здравствуйте, niXman, Вы писали:

S>>Если через async_connect, то какая разница спустя какое время вы получаете ошибку?

X>async_connect().

X>повторюсь — сама ошибка меня вполне устраивает ибо она логична. не устраивает именно время получения этой ошибки.

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

Здравствуйте, so5team, Вы писали:

S>Тогда не понятно, в чем ваша проблема: вы делаете async_connect, имеете возможность продолжать работу, пока операция connect выполняется асинхронно, ...

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

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

вариант с таймером — самый очевидный. но я хотел покурить в сторону системного API, етц...

Здравствуйте, niXman, Вы писали:

X>есть идеи?

бустоводы рекомендую использовать таймеры
офиц дока в том числе: http://www.boost.org/doc/libs/1_65_1/doc/html/boost_asio/example/cpp03/timeouts/async_tcp_client.cpp

Здравствуйте, niXman, Вы писали:

X>подключаюсь к некоторому серверу, который в данный момент не "слушает" порт, и получаю connection timed out спустя 5 минут.

Перед подключением проверь доступность порта. Гуглить icmp и raw sockets.

Здравствуйте, Слава, Вы писали:

С>Восхитительный пример для недавней темы "Поугараем над С++". То, что есть в чистом socket api уже десятилетия, до сих пор отсутствует в чудо-библиотеках с пространствами имён вида "boost::asio::ip::tcp::socket"

Ты внутрь то загляни.

Здравствуйте, niXman, Вы писали:

X>привет!

X>подключаюсь к некоторому серверу, который в данный момент не "слушает" порт, и получаю connection timed out спустя 5 минут.
X>расстраивает то, что нужно ждать аж пять минут.

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