В настоящее время я борюсь с какой-то дрянной частью (настраиваемого) серверного программного обеспечения, которое не принимает свои соединения должным образом (написано на 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, если они не считываются из пользовательского пространства своевременно манера.
Также приветствуются более подробные объяснения того, что здесь происходит.
Думаю, ответ отрицательный.
Проблема была решена заменой рассматриваемого программного обеспечения, но идеи по-прежнему приветствуются.
Вы можете попробовать тюнинг TCP keepalive к гораздо более коротким значениям. По умолчанию соединение может бездействовать в течение двух часов, прежде чем сработает поддержка активности.
То, какие именно значения вы должны использовать, действительно зависит от того, что делает ваше приложение, и чего ожидают ваши пользователи или как они с ним взаимодействуют.