Skip to content
  • 0 Votes
    1 Posts
    0 Views
    marcelschmall@infosec.exchangeM
    🫀 SO_KEEPALIVE — How your server detects dead connections before the client knowsA client connects to your server. Then their laptop lid closes. WiFi drops. Router reboots.The TCP connection is dead — but your server has no idea. It just sits there. Holding a socket. Waiting forever. This is called a half-open connection — one of TCP’s most silent failure modes. The fix — one line: setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &flag, sizeof(flag));The kernel now sends small probe packets on idle connections. No response after a few tries? Connection gets cleaned up automatically.️ Three knobs you control:→ tcp_keepalive_time — idle time before first probe (default: 2h )→ tcp_keepalive_intvl — time between probes (default: 75s)→ tcp_keepalive_probes — failures before giving up (default: 9)The defaults are hilariously conservative. For a real server you want minutes, not hours. Without it you risk:→ File descriptor leaks→ Thread pool exhaustion→ Memory piling up for connections that died hours ago Who needs it most:→ WebSockets & long-lived connections→ Servers behind NAT — routers silently drop idle mappings→ Any server where clients disappear without sending FIN Your server shouldn’t mourn connections that are already gone.#Linux #Networking #SystemsProgramming #ServerDevelopment
  • 0 Votes
    1 Posts
    0 Views
    marcelschmall@infosec.exchangeM
    spdlog — Logging for C++ that actually gets out of your wayWhen you’re writing a Linux server in C++ close to the hardware, the last thing you want is a logging library that slows you down — at build time, at runtime, or when reading the code.That’s exactly where spdlog shines. Header-only — zero build ceremonyDrop the headers into your project, #include "spdlog/spdlog.h" and you’re done. No linking against extra libraries, no CMake gymnastics, no ABI headaches. For embedded systems or minimal server builds this alone is worth a lot.And because spdlog supports C++11 and up, it runs happily on older GCC toolchains — exactly the kind you find in Linux BSP environments and long-lived server codebases. Logging should be fast AND readablespdlog uses the {fmt} library under the hood, which means your log messages are formatted at compile time where possible. Instead of stringing together cout-style streams, you write:spdlog::info("Connection from {} on port {}", client_ip, port);Clean, readable, and significantly faster than printf or std::cout at runtime.🪣 The Sink System — one logger, many destinationsThe real power comes from sinks. A sink is simply a destination for log output — and you can attach as many as you want to a single logger.→ stdout_sink for live debugging in the terminal→ rotating_file_sink to write to disk with automatic file rotation→ syslog_sink to feed directly into the Linux system journalIn a hardware-near server this means you can log to syslog for production monitoring AND to a rotating file for post-mortem debugging — with a single log call in your code. No duplication, no extra logic. Log levels keep noise under controlspdlog supports the classic hierarchy — trace, debug, info, warn, error, critical. You set the minimum level per sink, so your rotating file might catch everything from debug upwards while syslog only sees warn and above. Perfect for production servers where log volume matters. For C++ server development on Linux, spdlog hits a rare sweet spot: trivial to integrate, fast enough for hot paths, and flexible enough for real production setups.#Cpp #Linux #SystemsProgramming #ServerDevelopment