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

Следующий вызов:

ACE_HANDLE handles[2];
ACE_Pipe pipe;
if (pipe.open(handles)==-1)
    T_OS_ELOG(ACE_OS::last_error());

Иногда это приводит к ошибке, и ACE_OS::last_error возвращает следующую строку:

Error code: 10060. Error details: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

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

Это не проблема, связанная с брандмауэром (брандмауэра нет, и пока ничего не выходит наружу), и я почти уверен, что это не потому, что у меня закончились порты или что-то в этом роде, потому что в этом случае я получаю "Only one usage of each socket address (protocol/network address/port) is normally permitted".

Итак, что может вызвать эту ошибку?

(кстати, я запускаю Windows)


pipe ace
person Ronen Ness    schedule 04.06.2018    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Я не знаю, в чем основная причина ошибки, но в Windows ACE_Pipe реализован с использованием петлевого TCP-сокета. Вот как появляется концепция удаленного однорангового узла/стороны. Я рекомендую пройтись по нему с помощью отладчика и посмотреть, какой из вызовов не работает.

person Steve Huston    schedule 05.06.2018

arrow_upward
0
arrow_downward

Отвечая самому себе для будущих искателей: как упомянул Стив Хьюстон, ACE_Pipe реализован с использованием сокета обратной связи TCP в Windows.

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

Необязательным решением может быть использование сокетов быстрого доступа (https://blogs.technet.microsoft.com/wincat/2012/12/05/fast-tcp-loopback-performance-and-low-latency-with-windows-server-2012-tcp-loopback-fast-path/) или полностью отказаться от сокетов и вместо этого использовать анонимные каналы (https://docs.microsoft.com/en-us/windows/desktop/ipc/anonymous-pipes).

К сожалению, оба варианта не поддерживаются ACE, поэтому вместо использования ACE_Pipe потребуется реализовать собственный IPC. Также он не кроссплатформенный.

person Ronen Ness    schedule 02.07.2018