Jika buffer kirim untuk satu pemain dengan koneksi lambat sudah penuh, lalu server mengirim dengan cara blocking (pemanggilan yang tidak kembali sampai buffer punya ruang), thread server ikut menunggu pemain itu.
Mengapa Buffer kirim untuk klien yang lambat penuh → Akibatnya Karena pengirimannya blocking, thread server menunggu sampai buffer punya ruang → Di layar Semua pemain yang ditangani thread itu mengalami freeze atau slow motion
Sesekali secara acak, Saat banyak pemain berkumpul
Penanggung jawab
Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game
Gunakan pengiriman non-blocking, batasi antrean kirim per klien, buang update yang sudah lama.
Di grafik
Melonjak acak sesekali · Waktu tick server, Send-Q per koneksi
Yang diperiksa
Cari koneksi yang Send-Q-nya (byte yang belum mendapat ACK atau belum terkirim) sudah sebesar buffer kirim dengan ss -tn, lalu periksa di thread dump (stack) server game saat tick melonjak apakah ada thread yang tertahan di pemanggilan send
Cocok jika
Saat ada koneksi lambat dengan Send-Q penuh, thread yang menangani koneksi itu tertahan di send, dan hanya pemain yang ditangani thread yang sama ikut berhenti
Tidak cocok jika
Thread yang berhenti menunggu di luar send (lock, pemanggilan DB): lebih mungkin “Perebutan lock” atau “Pemanggilan sinkron di thread game”
Sarana pemeriksaan
Tools infrastruktur (tanpa perlu kode game)
Sumber
send(2) — Linux manual pageLinux man-pages Jika buffer kirim tidak punya ruang, send() memblok; dalam mode non-blocking, send() langsung kembali dengan EAGAIN
send function (winsock2.h)Microsoft Winsock juga memblok send jika ruang buffer tidak ada, kecuali dalam mode non-blocking
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Nilai Recv-Q dan Send-Q di ss: pada socket listen berarti jumlah koneksi yang menunggu accept dan batas backlog; pada socket yang terhubung berarti byte yang belum dibaca aplikasi dan byte terkirim yang belum mendapat ACK