Untuk mengubah jumlah probe atau interval probe, Anda menulis nilai ke sistem file /proc seperti
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
Perhatikan bahwa nilai ini bersifat global untuk semua soket yang mendukung keepalive pada sistem, Anda juga dapat mengganti pengaturan ini berdasarkan soket saat menyetel setockopt, lihat bagian 4.2 dari dokumen yang Anda tautkan.
Anda tidak dapat "memeriksa" status soket dari ruang pengguna dengan keepalive. Sebaliknya, kernel hanya lebih agresif dalam memaksa ujung jarak jauh untuk mengakui paket, dan menentukan apakah soket rusak. Saat Anda mencoba menulis ke soket, Anda akan mendapatkan SIGPIPE jika keepalive telah menentukan ujung jarak jauh sedang down.
Anda akan mendapatkan hasil yang sama jika Anda mengaktifkan SO_KEEPALIVE, sama seperti jika Anda tidak mengaktifkan SO_KEEPALIVE - biasanya Anda akan menemukan soket sudah siap dan mendapatkan kesalahan saat membacanya.
Anda dapat menyetel batas waktu keepalive berdasarkan per-soket di Linux (ini mungkin fitur khusus Linux). Saya akan merekomendasikan ini daripada mengubah pengaturan seluruh sistem. Lihat halaman manual untuk tcp untuk info lebih lanjut.
Akhirnya, jika klien Anda adalah browser web, kemungkinan besar itu akan menutup soket dengan cukup cepat - kebanyakan dari mereka hanya akan menahan koneksi keepalive (HTTP 1.1) terbuka untuk waktu yang relatif singkat (30 detik, 1 menit dll). Tentu saja jika mesin klien menghilang atau jaringan mati (yang sangat berguna untuk dideteksi oleh SO_KEEPALIVE), maka mesin tidak akan dapat menutup soket secara aktif.
Seperti yang sudah dibahas, SO_KEEPALIVE membuat kernel lebih agresif untuk terus memverifikasi koneksi bahkan saat Anda tidak melakukan apa-apa, tetapi tidak mengubah atau meningkatkan cara penyampaian informasi kepada Anda. Anda akan mengetahuinya ketika Anda mencoba untuk benar-benar melakukan sesuatu (misalnya "menulis"), dan Anda akan segera mengetahuinya karena kernel sekarang hanya melaporkan status dari flag yang ditetapkan sebelumnya, daripada harus menunggu beberapa saat. detik (atau lebih lama dalam beberapa kasus) agar aktivitas jaringan gagal. Logika kode yang sama persis dengan yang Anda miliki untuk menangani kondisi "sisi lain pergi secara tak terduga" akan tetap digunakan; yang berubah adalah waktunya (bukan metodenya).
Hampir setiap program soket "praktis" dalam beberapa cara menyediakan non -memblokir akses ke soket selama fase data (mungkin dengan select()/poll(), atau mungkin dengan fcntl()/O_NONBLOCK/EINPROGRESS&EWOULDBLOCK, atau jika kernel Anda mendukungnya mungkin dengan MSG_DONTWAIT). Dengan asumsi ini sudah dilakukan karena alasan lain, itu sepele (terkadang tidak memerlukan kode sama sekali) untuk mengetahui lebih lanjut tentang koneksi yang terputus. Tetapi jika fase data tidak entah bagaimana sudah menyediakan akses non-pemblokiran ke soket, Anda tidak akan mengetahui tentang koneksi yang terputus sampai Anda mencoba melakukan sesuatu lagi.
(Koneksi soket TCP tanpa semacam perilaku non-pemblokiran selama fase data terkenal rapuh, seolah-olah paket yang salah mengalami masalah jaringan, sangat mudah bagi program untuk kemudian "hang" tanpa batas waktu, dan tidak banyak yang Anda dapat melakukannya.)