ゲームラグ白書 › 同期設計
逐次往復の多いプロトコル（chatty） Chatty protocol / sequential round trips
原因ID sy-chatty · 主担当 ゲーム開発チーム・サーバー開発 · 副担当 ゲーム開発チーム・クライアント開発
図と実験のあるメインページでこのカードを開く →
1回の操作でサーバーとの往復が順番に何回も必要になると、Pingがその回数分だけ積み重なります。
なぜ ショップを開く → 一覧を要求 → 価格を確認 → 購入 → インベントリ更新を、それぞれ別々にリクエスト → すると 前のリクエストの応答を受け取ってから次のリクエストを送る → 画面では Ping 150msで1回の購入に1秒近くかかる。ロードがやけに長い
- 症状
- 入力遅延, 接続不可・無限ロード
- 要因
- 遅延
- 誰に起きるか
- 特定の機能だけ, 自分だけ
- いつ
- 特定の操作をしたとき, 接続直後・メンテ明け
- 担当
- 主担当 ゲーム開発チーム・サーバー開発 · 副担当 ゲーム開発チーム・クライアント開発
- ゲーム開発チームの対応
- サーバー：複数の段階を1回のリクエスト・レスポンスにまとめるようプロトコルを変更（例：購入の応答に更新後のインベントリを含める）。クライアント：必要なデータを先に受け取っておく、結果を待たないUI。
- 数値の目安
- かかる時間 ≈ 往復回数 ×（Ping + サーバー処理 + ティック待ち）。5回ならPing 150msで約0.85〜1秒。
- グラフでは
- 最初から常に高い · 機能ごとの完了時間、1回の操作あたりの往復回数
- 確認箇所
- サーバー側のパケットキャプチャ（Wireshark）で、試験アカウントでショップでの購入・ログインなどの操作を1回行う間に、リクエストとレスポンスが何回交互にやり取りされるかとその間隔を数える。サーバーのリクエストログがあれば、セッションIDでまとめてリクエスト数と、リクエストごとの到着・応答時刻を確認
- 該当する場合
- 1つの操作でリクエストが前の応答を待ってから順番に何回もやり取りされ、完了時間がおおよそ往復回数 × RTTで、Pingが高い地域のユーザーほど同じ機能が比例して遅い
- 該当しない場合
- 往復は1〜2回なのに1つの応答に時間がかかるなら、サーバー処理・DB側の原因。Pingに関係なく全ユーザーが同じように遅いなら、サーバー負荷を確認
- 確認手段
- インフラのツールで確認（ゲームコード不要）
出典
- Chatty I/O antipattern Microsoft Azure
小さなI/Oリクエストが多いと、累積した遅延で応答性が大きく落ちる。リクエストをより大きく、少なくまとめるよう推奨
あわせて読みたい原因
同じ層：同期設計
同じ症状（入力遅延）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る