受信バッファのあふれ Socket receive buffer overflow

原因ID co-rcvbuf · 主担当 ゲーム開発チーム・クライアント開発

ゲームの処理が忙しく、ソケット（OSが提供するネットワーク送受信のインターフェース）からパケットを取り出すのが遅れると、OSのバッファがあふれます。

なぜフレームが遅れ、ゲームがソケットを読むのが遅くなる → すると OSの受信バッファがいっぱいになり、UDPは破棄され、TCPは受信ウィンドウを縮めて送信側を止めさせる → 画面では ワープ（UDP）または早送り（TCP）

症状: ワープ, 早送り
要因: パケットロス, ストール
誰に起きるか: 自分だけ
いつ: 人が集中したとき
担当: 主担当 ゲーム開発チーム・クライアント開発
ゲーム開発チームの対応: 受信専用スレッド、バッファサイズの調整（SO_RCVBUF）。
数値の目安: デフォルトの受信バッファは、OS・設定によって数十〜数百KB。人が多い場所の更新は、1秒に数百KBになることもあります。
グラフでは: 人数・負荷に連動して上昇 · UDP受信バッファでの破棄数、フレームタイム
確認箇所: Windowsのパフォーマンスモニターで、Microsoft Winsock BSP\Dropped Datagrams（ソケットの受信バッファ不足で破棄されたUDPの数）とUDPv4\Datagrams Received Errorsをフレームタイムとあわせて記録し、ゲーム側では受信パケットの連番の抜けを数える
該当する場合: 人が多い場所や長いフレームの直後にDropped Datagramsが増え、同じ瞬間にゲームの連番に抜けが出る。同じ時刻に回線側のパケットロスはない
該当しない場合: Dropped Datagramsは変わらないのに連番だけ抜けるなら、経路上のパケットロス
確認手段: ユーザー側の環境で確認

出典

socket(7) — Linux manual page Linux man-pages
SO_RCVBUFはソケットの受信バッファの最大サイズ。デフォルト値はrmem_default、最大値はrmem_maxで決まる（AndroidもLinuxカーネル）
SOL_SOCKET Socket Options (Winsock2.h) Microsoft
WindowsのSO_RCVBUF：ソケットごとに受信用に確保するバッファ領域
RFC 9293: Transmission Control Protocol (TCP) IETF
TCPのウィンドウフィールドは、受信側がさらに受け取れるバイト数。0なら送信側はゼロウィンドウプローブだけを送って待つ
Low Latency Workloads Management and Operations Microsoft
Microsoft Winsock BSPカウンターセットのDropped Datagrams・Dropped Datagrams/sec：アプリの処理速度よりUDPが速く届いたり、受信ソケットのバッファが足りなかったりして破棄された数
Network-Related Performance Counters Microsoft
UDPv4・UDPv6：Datagrams Received Errors、Microsoft Winsock BSP：Dropped Datagramsカウンター