mirror of
https://github.com/yhirose/cpp-httplib.git
synced 2026-10-01 05:02:29 +07:00
yhirose
199d7ee248
read() collapsed every failure into Fail and marked the connection closed with it, so a read timeout could not be used to get control back and send on the same connection -- it killed the connection instead. The information was already there and thrown away: SocketStream::read records Error::Timeout, and read_websocket_frame flattened it into a bool. ReadResult gains Timeout, reported only when the timeout elapsed on a frame boundary with nothing consumed, which is the only case where the stream can be read again. Every multi-byte field now loops until it has its bytes, which also fixes a frame header straddling the read buffer's boundary failing the frame: Stream::read is allowed to return less than asked for, and only the payload was reading in a loop. ws::WebSocket::set_read_timeout() lets a server handler bound its own reads, and WebSocketClient::set_read_timeout() now reaches an already-open connection instead of only seeding the next connect(). The read timeout macro splits in two. A client waits forever by default -- a read timeout is the caller's tool for taking back control, not a liveness check, which is ping/pong's job -- while a server keeps the 300s that reclaims a worker from a peer gone quiet. Defining the old name still sets both. Also record a reason on the two WebSocketSSLStream::read failure paths that returned -1 without one, so get_error() cannot report a previous call's timeout, and make SocketStream's read timeout atomic now that it can be changed while a read is in flight.
81 lines
4.6 KiB
Markdown
81 lines
4.6 KiB
Markdown
---
|
|
title: "W02. ハートビートを設定する"
|
|
order: 53
|
|
status: "draft"
|
|
---
|
|
|
|
WebSocket接続は長時間つなぎっぱなしになるので、プロキシやロードバランサが「アイドルだから」と勝手に切ってしまうことがあります。これを防ぐために、定期的にPingフレームを送って接続を生かしておく仕組みがあります。cpp-httplibでは、指定した間隔で自動的にPingを送ってくれます。
|
|
|
|
## サーバー側の設定
|
|
|
|
```cpp
|
|
svr.set_websocket_ping_interval(30); // 30秒ごとにPing
|
|
|
|
svr.WebSocket("/chat", [](const auto &req, auto &ws) {
|
|
// ...
|
|
});
|
|
```
|
|
|
|
`set_websocket_ping_interval()`に秒数を渡すだけです。このサーバーが受け入れるすべてのWebSocket接続に対して、指定した間隔でPingが送られます。
|
|
|
|
`std::chrono`の期間を受け取るオーバーロードもあります。
|
|
|
|
```cpp
|
|
using namespace std::chrono_literals;
|
|
svr.set_websocket_ping_interval(30s);
|
|
```
|
|
|
|
## クライアント側の設定
|
|
|
|
クライアント側でも同じAPIがあります。
|
|
|
|
```cpp
|
|
httplib::ws::WebSocketClient cli("ws://localhost:8080/chat");
|
|
cli.set_websocket_ping_interval(30);
|
|
cli.connect();
|
|
```
|
|
|
|
`connect()`を呼ぶ前に設定しておきましょう。
|
|
|
|
## デフォルト値
|
|
|
|
デフォルトのPing間隔は、ビルド時のマクロ`CPPHTTPLIB_WEBSOCKET_PING_INTERVAL_SECOND`で決まります。通常はそのままで問題ありませんが、特別なプロキシ環境に合わせて短くしたい場合は調整してください。
|
|
|
|
## PongはどうやってpIngに応答するか
|
|
|
|
WebSocketプロトコルでは、PingフレームにはPongフレームで応答することが決まっています。cpp-httplibは受信したPingに自動でPongを返すので、アプリケーションコード側で気にする必要はありません。
|
|
|
|
## Pingの間隔をどう決めるか
|
|
|
|
| 環境 | 推奨 |
|
|
| --- | --- |
|
|
| 通常のインターネット接続 | 30〜60秒 |
|
|
| 厳しいプロキシ（AWS ALBなど） | 15〜30秒 |
|
|
| モバイル回線 | 短すぎるとバッテリーを食う、60秒以上 |
|
|
|
|
短すぎると無駄なトラフィックになり、長すぎると接続が切れます。だいたい**接続が切れる時間の半分**くらいが目安です。
|
|
|
|
> **Warning:** Ping間隔を極端に短くすると、WebSocket接続ごとにバックグラウンドでスレッドが走るので、CPU負荷が上がります。接続数が多いサーバーでは控えめな値に設定しましょう。
|
|
|
|
## 無応答のピアを検出する
|
|
|
|
Pingを送るだけでは、相手が「黙って落ちた」場合に気付けません。TCPの接続自体は生きているように見えるのに、相手のプロセスはもう応答しない、というケースです。これを検出するには、送ったPingに対してPongがN回連続で返ってこなかったら接続を切る、というオプションを有効にします。
|
|
|
|
```cpp
|
|
cli.set_websocket_max_missed_pongs(2); // 2回連続でPongが返ってこなければ切断
|
|
```
|
|
|
|
サーバー側にも同じ`set_websocket_max_missed_pongs()`があります。
|
|
|
|
たとえばPing間隔が30秒で`max_missed_pongs = 2`なら、無応答のピアは約60秒で検出され、`CloseStatus::GoingAway`（理由は`"pong timeout"`）で接続が閉じられます。
|
|
|
|
この仕組みは`read()`を呼んでPongフレームを消費したタイミングでカウンタがリセットされます。つまり通常のWebSocketクライアントのように`read()`をループで回していれば、特に意識することなく動きます。
|
|
|
|
### デフォルトは無効
|
|
|
|
`max_missed_pongs`のデフォルトは`0`で、これは「Pongが何回返ってこなくてもこの仕組みでは切断しない」という意味です。Ping自体は送られ続けますが、応答の有無はチェックされません。無応答ピアを検出したい場合は明示的に`1`以上を設定してください。
|
|
|
|
サーバ側は`0`のままでも接続が残り続けることはありません。ハンドラが`read()`を呼んでいる間は`CPPHTTPLIB_WEBSOCKET_SERVER_READ_TIMEOUT_SECOND`（デフォルト**300秒 = 5分**）が保険として働きます。一方クライアント側にはこの保険がなく、読み取りタイムアウトを設定しない限り無期限に待つので、無応答ピアを検出する手段は`max_missed_pongs`だけです。どちらの側でも「**もっと速く**検出したい」ときに使うオプションでもあります。
|
|
|
|
> 接続が閉じたときの処理は[W03. 接続クローズをハンドリングする](../w03-websocket-close)を参照してください。
|