☰

Есть ли в Linux настраиваемый тайм-аут сокета между ядром и пространством пользователя?

tag-icon • tag-icon linux socket
Есть ли в Linux настраиваемый тайм-аут сокета между ядром и пространством пользователя?

В настоящее время я борюсь с каким-то паршивым (кастомным) серверным ПО, которое не принимает соединения должным образом (написано на Java программистом PHP, который никогда раньше не прикасался к сокетам, не говоря уже о потоках). Я предполагаю, что поток умирает до того, как сокет будет должным образом принят в клиентском потоке. Я не могу быть уверен, и на самом деле это не имеет большого значения, поскольку ПО в настоящее время переписано; старая версия должна работать, пока новая версия не выйдет в сеть, максимально надежно, но без затрат времени и денег на отладку старой кодовой базы.

Ошибка проявляется в следующем выводе netstat; некоторые соединения никогда не переносятся из ядра в пространство использования (это то, как я это понимаю, лучшие интерпретации приветствуются):

Proto Recv-Q Send-Q Local Address         Foreign Address         State       PID/Program name
tcp6     228      0 192.0.2.105:1988      46.23.248.10:7925       ESTABLISHED -               
tcp6       0      0 192.0.2.105:1988      221.130.33.37:9826      ESTABLISHED 14741/java      
tcp6       0      0 192.0.2.105:1988      46.23.248.2:5867        ESTABLISHED 14741/java      
tcp6    2677      0 192.0.2.105:1988      221.130.33.37:15688     ESTABLISHED -               
tcp6    3375      0 192.0.2.105:1988      221.130.33.36:3045      ESTABLISHED -               
tcp6   14742      0 192.0.2.105:1988      46.23.248.17:4679       ESTABLISHED -               
tcp6     774      0 192.0.2.105:1988      212.9.19.73:36064       ESTABLISHED -               
tcp6      92      0 192.0.2.105:1988      46.23.248.19:7164       ESTABLISHED -               
tcp6       0      0 192.0.2.105:1988      46.23.248.21:6322       ESTABLISHED 14741/java      
tcp6       0      0 192.0.2.105:1988      221.130.39.216:13937    ESTABLISHED 14741/java      
tcp6    3051      0 192.0.2.105:1988      211.139.145.104:31239   ESTABLISHED -               
tcp6     246      0 192.0.2.105:1988      46.23.248.10:5458       ESTABLISHED -               
tcp6     618      0 192.0.2.105:1988      212.9.19.73:20209       ESTABLISHED -               
tcp6    1041      0 192.0.2.105:1988      46.23.248.18:7424       ESTABLISHED -               
tcp6       0      0 192.0.2.105:1988      46.23.248.10:5065       ESTABLISHED 14741/java

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

Итак, если предположить, что моя интерпретация этой проблемы верна, то мне стало интересно, есть ли параметр ядра, который я могу настроить и который заставит ядро ​​сбрасывать/закрывать TCP-соединения с помощью RST, если они не считываются пространством пользователя своевременно.

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

решение1

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

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

решение2

Думаю, ответ — нет.

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

Связанный контент