Buku Putih Lag Game › Desain sinkronisasi

Protokol dengan banyak round trip berurutan (chatty) Chatty protocol / sequential round trips

ID penyebab sy-chatty · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Buka kartu interaktif dengan gambar dan simulasi →

Jika satu aksi butuh beberapa kali pulang-pergi ke server secara berurutan, ping dikalikan sebanyak jumlah itu.

Mengapa Buka toko → minta daftar → cek harga → beli → perbarui inventory, masing-masing diminta terpisah → Akibatnya Permintaan berikutnya baru dikirim setelah jawaban permintaan sebelumnya diterima → Di layar Dengan ping 150 ms, satu kali beli butuh hampir 1 detik. Loading terasa sangat lama

Gejala

Input lag, Tidak bisa masuk / loading tanpa henti

Faktor

Latensi

Siapa yang mengalami

Fitur tertentu saja, Hanya saya

Kapan

Saat melakukan aksi tertentu, Tepat setelah login atau maintenance

Penanggung jawab

Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)

Tugas Tim Pengembang Game

Server: ubah protokol agar beberapa tahap digabung dalam satu permintaan dan respons (misalnya, sertakan inventory yang sudah diperbarui di respons pembelian). Klien: ambil data yang dibutuhkan lebih dulu, buat UI yang tidak menunggu hasil.

Kisaran angka

Waktu yang dibutuhkan ≈ jumlah round trip × (ping + pemrosesan server + waktu tunggu tick). Untuk 5 kali dengan ping 150 ms, sekitar 0,85–1 detik.

Di grafik

Selalu tinggi sejak awal · Waktu selesai per fitur, jumlah round trip per aksi

Yang diperiksa

Dari packet capture di sisi server (Wireshark), hitung berapa kali permintaan dan respons bergantian dan berapa jeda di antaranya selama akun uji melakukan satu aksi, seperti membeli di toko atau login. Jika ada log permintaan server, kelompokkan berdasarkan ID sesi lalu periksa jumlah permintaan serta waktu tiba dan waktu respons setiap permintaan

Cocok jika

Dalam satu aksi, permintaan bolak-balik beberapa kali secara berurutan sambil menunggu respons sebelumnya, waktu selesai kira-kira jumlah round trip × RTT, dan makin tinggi ping wilayah pemain, makin lambat fitur yang sama secara proporsional

Tidak cocok jika

Round trip hanya satu atau dua kali tetapi satu respons lama: penyebabnya di pemrosesan server atau DB. Semua pemain sama lambatnya tanpa peduli ping: periksa beban server

Sarana pemeriksaan

Tools infrastruktur (tanpa perlu kode game)

Sumber

1. Chatty I/O antipattern Microsoft Azure
   Banyak permintaan I/O kecil membuat latensi kumulatif sangat menurunkan responsivitas. Disarankan menggabungkan permintaan menjadi lebih besar dan lebih sedikit

Lihat juga

Lapisan yang sama: Desain sinkronisasi

• Feedback baru tampil setelah server merespons (model request-response)
• Tidak ada input buffering untuk skill
• Timing window pendek yang termakan ping
• Hit registration tanpa lag compensation
• Lag compensation berlebihan
• Otoritas klien
• Lockstep menunggu pemain paling lambat
• Prediksi rollback netcode meleset
• Event diputar begitu tiba tanpa timestamp
• Menunggu tick dua kali
• Validasi server yang terlalu ketat
• Arsitektur host (pembuat room)
• Server menolak setelah feedback sisi klien
• Perhitungan jalur tidak sama pada sinkronisasi perintah
• Laju pengiriman snapshot rendah

Penyebab di lapisan lain dengan gejala yang sama (Input lag)

• Beban rendering kerumunan besar L1 Proses game di klien
• Bottleneck pemrosesan paket di main thread L1 Proses game di klien
• V-Sync dan antrean render L1 Proses game di klien
• Mode hemat daya dan thermal throttling L2 OS dan perangkat klien
• Pemakaian bandwidth oleh aplikasi lain di perangkat yang sama L2 OS dan perangkat klien
• Latensi layar, perangkat input, dan frame generation L2 OS dan perangkat klien
• Channel Wi-Fi padat L3 Jaringan rumah
• Bufferbloat (antrean router) L3 Jaringan rumah

Lihat kartu interaktif dengan gambar dan simulasi