Chcete-li upravit počet testů nebo intervaly testů, zapište hodnoty do souborového systému /proc jako
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
Všimněte si, že tyto hodnoty jsou globální pro všechny sokety v systému s povoleným udržováním stavu. Tato nastavení můžete také přepsat na základě soketu, když nastavíte setsockopt, viz část 4.2 dokumentu, který jste propojili.
Nemůžete "zkontrolovat" stav soketu z uživatelského prostoru pomocí keepalive. Místo toho je jádro prostě agresivnější, když nutí vzdálený konec potvrzovat pakety a určuje, zda se soket pokazil. Když se pokusíte zapisovat do soketu, dostanete SIGPIPE, pokud Keepalive zjistí, že vzdálený konec je mimo provoz.
Pokud povolíte SO_KEEPALIVE, získáte stejný výsledek, jako když nepovolíte SO_KEEPALIVE – obvykle najdete soket připravený a při čtení z něj se zobrazí chyba.
Timeout keepalive můžete nastavit na základě jednotlivých soketů pod Linuxem (toto může být specifická funkce pro Linux). Doporučil bych to spíše než měnit nastavení celého systému. Více informací naleznete na manuálové stránce tcp.
A konečně, pokud je vaším klientem webový prohlížeč, je docela pravděpodobné, že stejně rychle uzavře socket – většina z nich udrží udržovací (HTTP 1.1) připojení otevřená pouze po relativně krátkou dobu (30 s, 1 min atd.). Samozřejmě, pokud klientský počítač zmizel nebo došlo k výpadku sítě (což je to, co je SO_KEEPALIVE opravdu užitečné pro detekci), pak nebude schopen aktivně zavřít soket.
Jak již bylo řečeno, SO_KEEPALIVE činí jádro agresivnějším, pokud jde o neustálé ověřování připojení, i když nic neděláte, ale nedělá změnit nebo zlepšit způsob, jakým jsou vám informace poskytovány. Zjistíte to, když se pokusíte něco skutečně udělat (například „zapsat“), a zjistíte to hned, protože jádro nyní pouze hlásí stav dříve nastaveného příznaku, místo aby muselo pár čekat sekund (v některých případech mnohem déle), než síťová aktivita selže. Stále bude použita přesně stejná logika kódu, jakou jste měli pro zpracování podmínky „druhá strana nečekaně odešla“; co se mění, je načasování (ne metoda).
Prakticky každý "praktický" program pro sockety nějakým způsobem poskytuje ne -blokování přístupu k soketům během datové fáze (možná pomocí select()/poll(), nebo možná pomocí fcntl()/O_NONBLOCK/EINPROGRESS&EWOULDBLOCK, nebo pokud to vaše jádro podporuje, možná pomocí MSG_DONTWAIT). Za předpokladu, že se to již děje z jiných důvodů, je triviální (někdy nevyžaduje vůbec žádný kód) navíc okamžitě zjistit přerušení připojení. Pokud však datová fáze ne už nějak zajistit neblokovací přístup k zásuvkám, o vypadávání spojení se dozvíte až při příštím pokusu něco udělat.
(Připojení soketu TCP bez určitého druhu neblokujícího chování během datové fáze je notoricky křehké, jako kdyby nesprávný paket narazil na problém se sítí, je pro program velmi snadné „zavěsit“ na dobu neurčitou, a není toho mnoho. může to udělat.)