Um die Anzahl der Sonden oder die Sondenintervalle zu ändern, schreiben Sie Werte in das /proc-Dateisystem wie
echo 600 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 60 > /proc/sys/net/ipv4/tcp_keepalive_intvl
echo 20 > /proc/sys/net/ipv4/tcp_keepalive_probes
Beachten Sie, dass diese Werte global für alle Keepalive-aktivierten Sockets auf dem System gelten. Sie können diese Einstellungen auch auf Socket-Basis überschreiben, wenn Sie die Setsockopt festlegen, siehe Abschnitt 4.2 des Dokuments, das Sie verlinkt haben.
Sie können den Status des Sockets aus dem Userspace nicht mit Keepalive "überprüfen". Stattdessen ist der Kernel einfach aggressiver, wenn es darum geht, das entfernte Ende zu zwingen, Pakete zu bestätigen, und festzustellen, ob der Socket schlecht geworden ist. Wenn Sie versuchen, in den Socket zu schreiben, erhalten Sie ein SIGPIPE, wenn Keepalive festgestellt hat, dass das Remote-Ende ausgefallen ist.
Sie erhalten das gleiche Ergebnis, wenn Sie SO_KEEPALIVE aktivieren, als wenn Sie SO_KEEPALIVE nicht aktivieren - normalerweise finden Sie den Socket bereit und erhalten eine Fehlermeldung, wenn Sie daraus lesen.
Sie können das Keepalive-Timeout unter Linux pro Socket festlegen (dies kann eine Linux-spezifische Funktion sein). Ich würde dies empfehlen, anstatt die systemweite Einstellung zu ändern. Weitere Informationen finden Sie in der Manpage für TCP.
Wenn Ihr Client ein Webbrowser ist, ist es sehr wahrscheinlich, dass er den Socket sowieso ziemlich schnell schließt - die meisten von ihnen halten Keepalive-Verbindungen (HTTP 1.1) nur für eine relativ kurze Zeit offen (30 Sekunden, 1 Minute usw.). Natürlich, wenn der Client-Rechner verschwunden oder das Netzwerk ausgefallen ist (was SO_KEEPALIVE wirklich nützlich zum Erkennen ist), dann wird es nicht in der Lage sein, den Socket aktiv zu schließen.
Wie bereits besprochen, macht SO_KEEPALIVE den Kernel aggressiver bei der kontinuierlichen Überprüfung der Verbindung, selbst wenn Sie nichts tun, tut dies aber nicht die Art und Weise, wie Ihnen die Informationen bereitgestellt werden, ändern oder verbessern. Sie werden es herausfinden, wenn Sie versuchen, tatsächlich etwas zu tun (zum Beispiel "schreiben"), und Sie werden es sofort herausfinden, da der Kernel jetzt nur den Status eines zuvor gesetzten Flags meldet, anstatt ein paar warten zu müssen Sekunden (oder in einigen Fällen viel länger), bis die Netzwerkaktivität fehlschlägt. Die exakt gleiche Codelogik, die Sie für die Behandlung der Bedingung „andere Seite ging unerwartet weg“ hatte, wird weiterhin verwendet; Was sich ändert, ist das Timing (nicht die Methode).
Praktisch jedes "praktische" Sockets-Programm bietet auf irgendeine Weise nicht - Blockieren des Zugriffs auf die Sockets während der Datenphase (vielleicht mit select()/poll(), oder vielleicht mit fcntl()/O_NONBLOCK/EINPROGRESS&EWOULDBLOCK, oder wenn Ihr Kernel es unterstützt, vielleicht mit MSG_DONTWAIT). Unter der Annahme, dass dies aus anderen Gründen bereits geschehen ist, ist es trivial (manchmal ohne Code erforderlich), zusätzlich sofort über einen Verbindungsabbruch zu erfahren. Aber wenn die Datenphase nicht bereits irgendwie einen nicht blockierenden Zugriff auf die Sockets bieten, werden Sie erst beim nächsten Versuch, etwas zu tun, von dem Verbindungsabbruch erfahren.
(Eine TCP-Socket-Verbindung ohne irgendein nicht blockierendes Verhalten während der Datenphase ist notorisch fragil, denn wenn das falsche Paket auf ein Netzwerkproblem stößt, kann das Programm sehr leicht auf unbestimmte Zeit "hängen", und es gibt nicht viel Sie dagegen tun können.)