Приветствую.
Возник вопрос, как мне сбросить соединения еще не прошедшие accept?

Есть пул потоков которые обрабатывают поступившие соединения.
Если все потоки заняты хочется закрыть соединение, чтобы клиент обратился к следующему по списку серверу.
Сейчас приходится получать дескриптор после accept и закрывать его close.
Есть ли более правильные решения? Платформа Linux и MacOS X.

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

D>Приветствую.
D>Возник вопрос, как мне сбросить соединения еще не прошедшие accept?

D>Есть пул потоков которые обрабатывают поступившие соединения.
D>Если все потоки заняты хочется закрыть соединение, чтобы клиент обратился к следующему по списку серверу.
D>Сейчас приходится получать дескриптор после accept и закрывать его close.
D>Есть ли более правильные решения? Платформа Linux и MacOS X.

Старые звери вроде sendmail закрывают в этом случае слушающий сокет.
Но если проблема кратковременная, надо просто не делать accept(), а подождать освобождения треда. Потому что в этом случае клиенту лучше подождать, чем нарываться на немедленный отказ.
При более длительном (для каждой цели длительность считается по-своему) — закрывать таки слушающий сокет.

В SysV интерфейсе (TLI/XTI) есть вызов закрыть без принятия, но в BSD sockets (склонированном и в Linux) такого нет.

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

D>>Приветствую.
D>>Возник вопрос, как мне сбросить соединения еще не прошедшие accept?

N>Старые звери вроде sendmail закрывают в этом случае слушающий сокет.
N>Но если проблема кратковременная, надо просто не делать accept(), а подождать освобождения треда. Потому что в этом случае клиенту лучше подождать, чем нарываться на немедленный отказ.
N>При более длительном (для каждой цели длительность считается по-своему) — закрывать таки слушающий сокет.

N>В SysV интерфейсе (TLI/XTI) есть вызов закрыть без принятия, но в BSD sockets (склонированном и в Linux) такого нет.
Спасибо.
Про закрытие слушающего сокета я знаю, но что-то меня в этом смущает, есть ли какие подводные камни?

В теории, можно послать RST в ответ на соединение, но как бы это сделать?

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

D>Спасибо.
D>Про закрытие слушающего сокета я знаю, но что-то меня в этом смущает, есть ли какие подводные камни?

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

D>В теории, можно послать RST в ответ на соединение, но как бы это сделать?

Через iptables. Дайте приложению через sudo ${script} такие права.

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

D>Приветствую.
D>Возник вопрос, как мне сбросить соединения еще не прошедшие accept?

D>Есть пул потоков которые обрабатывают поступившие соединения.
D>Если все потоки заняты хочется закрыть соединение, чтобы клиент обратился к следующему по списку серверу.
D>Сейчас приходится получать дескриптор после accept и закрывать его close.
D>Есть ли более правильные решения? Платформа Linux и MacOS X.
а если установить длину очереди в listen?

Здравствуйте, Nikolay_Ch, Вы писали:
D>>Есть пул потоков которые обрабатывают поступившие соединения.
D>>Если все потоки заняты хочется закрыть соединение, чтобы клиент обратился к следующему по списку серверу.
D>>Сейчас приходится получать дескриптор после accept и закрывать его close.
D>>Есть ли более правильные решения? Платформа Linux и MacOS X.
N_C>а если установить длину очереди в listen?
Для некоторых запросов, увеличивается время ответа, хотя они могли бы быть дропнуты и обработаны следующим сервером.

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

D>Возник вопрос, как мне сбросить соединения еще не прошедшие accept?
Не получай дескриптор, не вызывай accept() и всё.

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

I>Не получай дескриптор, не вызывай accept() и всё.
Таймаут соединения достаточно большой. Клиент все это время будет ждать, хотя мог-бы присоединиться к соседнему серверу... А именно этого, насколько я понимаю, хотел избежать автор вопроса...