mirror of
https://github.com/yhirose/cpp-httplib.git
synced 2026-10-15 10:39:37 +00:00
yhirose
bef278e0d2
Samples that did not compile or run as shown: - res.user_data.get<T>() inside a generic lambda needs the `template` keyword; use explicit parameter types (tour 09, cookbook s15). - listen() on a Unix domain socket fails with port 0 (tour 09, s22). - "*.dev.local" is not a NO_PROXY pattern (c16). - ssl_backend_error() holds a verify result, not an ERR_get_error() value, after a verification failure; decode each with the matching OpenSSL function (c18). - The content provider's `length` is everything that remains, so the sample read the whole file in one call (s05). Statements corrected: - Client keep-alive is off by default; c14 is rewritten around set_keep_alive(true). - Mounted files are looked up before GET handlers (tour 04, s04). - Params keep insertion order, and to_string(Error::Connection) reads "Could not establish connection" (tour 02). - A chunked provider ends with sink.done(), and post_routing_handler runs before the response is sent (tour 09). - Timeouts surface as Error::Read; Error::Timeout comes from the stream API (c17). The max timeout cuts off the wait for the response only (c13). The progress callback needs Content-Length (c11). - Encoding selection follows q-values, then Brotli, gzip, Zstd (s08), and the client compresses with the first of those it was built with (c15). - stop() cuts a provider-driven response short (s19); a rejected content_reader already gets 400 or 413 (s07); user_data values must be copyable (s12); Client accepts a client certificate too (t04); on_message() is the fallback for every unhandled event and 204/403/404 end reconnection (e04); the pong timeout takes two to three intervals and ends a waiting read() (w02). In the LLM app tutorial, an uncaught exception does not crash the server, so say what it does instead. Drop the server and client timeout settings whose stated purpose, covering inference and download time, they do not serve: those timeouts bound a single socket wait. Update the llama.cpp server layout in chapter 7.
81 lines
3.6 KiB
Markdown
81 lines
3.6 KiB
Markdown
---
|
||
title: "W02. Set a WebSocket Heartbeat"
|
||
order: 53
|
||
status: "draft"
|
||
---
|
||
|
||
WebSocket connections stay open for a long time, and proxies or load balancers will sometimes drop them for being "idle." To prevent that, you periodically send Ping frames to keep the connection alive. cpp-httplib can do this for you automatically.
|
||
|
||
## Server side
|
||
|
||
```cpp
|
||
svr.set_websocket_ping_interval(30); // ping every 30 seconds
|
||
|
||
svr.WebSocket("/chat", [](const auto &req, auto &ws) {
|
||
// ...
|
||
});
|
||
```
|
||
|
||
Just pass the interval in seconds. Every WebSocket connection this server accepts will be pinged on that interval.
|
||
|
||
There's a `std::chrono` overload too.
|
||
|
||
```cpp
|
||
using namespace std::chrono_literals;
|
||
svr.set_websocket_ping_interval(30s);
|
||
```
|
||
|
||
## Client side
|
||
|
||
The client has the same API.
|
||
|
||
```cpp
|
||
httplib::ws::WebSocketClient cli("ws://localhost:8080/chat");
|
||
cli.set_websocket_ping_interval(30);
|
||
cli.connect();
|
||
```
|
||
|
||
Call it before `connect()`.
|
||
|
||
## The default
|
||
|
||
The default interval is set by the build-time macro `CPPHTTPLIB_WEBSOCKET_PING_INTERVAL_SECOND`. Usually you won't need to change it, but adjust downward if you're dealing with an aggressive proxy.
|
||
|
||
## What about Pong?
|
||
|
||
The WebSocket protocol requires that Ping frames are answered with Pong frames. cpp-httplib responds to Pings automatically — you don't need to think about it in application code.
|
||
|
||
## Picking an interval
|
||
|
||
| Environment | Suggested |
|
||
| --- | --- |
|
||
| Normal internet | 30–60s |
|
||
| Strict proxies (e.g. AWS ALB) | 15–30s |
|
||
| Mobile networks | 60s+ (too short drains battery) |
|
||
|
||
Too short wastes bandwidth; too long and connections get dropped. As a rule of thumb, target about **half the idle timeout** of whatever's between you and the client.
|
||
|
||
> **Warning:** A very short ping interval spawns background work per connection and increases CPU usage. For servers with many connections, keep the interval modest.
|
||
|
||
## Detecting an unresponsive peer
|
||
|
||
Sending pings alone doesn't tell you anything if the peer just silently dies — the TCP socket might still look open while the process on the other end is long gone. To catch that, enable the max-missed-pongs check: if N consecutive pings go unanswered, the connection is closed.
|
||
|
||
```cpp
|
||
cli.set_websocket_max_missed_pongs(2); // close after 2 consecutive unacked pings
|
||
```
|
||
|
||
The server side has the same `set_websocket_max_missed_pongs()`.
|
||
|
||
With a 30-second ping interval and `max_missed_pongs = 2`, a dead peer is detected 60 to 90 seconds after it stops answering, and the connection is closed with `CloseStatus::GoingAway` and the reason `"pong timeout"`. A `read()` waiting on the peer at that moment returns `Fail`.
|
||
|
||
The counter is reset whenever `read()` consumes an incoming Pong frame, so this only works if your code is actively calling `read()` in a loop — which is what a normal WebSocket client does anyway.
|
||
|
||
### Why the default is 0
|
||
|
||
`max_missed_pongs` defaults to `0`, which means "never close the connection because of missing pongs." Pings are still sent on the heartbeat interval, but their responses aren't checked. If you want unresponsive-peer detection, set it explicitly to `1` or higher.
|
||
|
||
On the server side, even with `0`, a dead connection won't linger forever: while a handler is inside `read()`, `CPPHTTPLIB_WEBSOCKET_SERVER_READ_TIMEOUT_SECOND` (default **300 seconds = 5 minutes**) acts as a backstop. A client has no backstop of its own — it waits forever unless you set a read timeout — so there `max_missed_pongs` is what notices an unresponsive peer at all. On either side, it is also how you notice one **faster** than that 5-minute fallback.
|
||
|
||
> For handling a closed connection, see [W03. Handle connection close](../w03-websocket-close).
|