NusaMart: Layanan Chat CS & Heartbeat

Jawaban Kuis Studi Kasus Pertemuan 04 - Sistem Terdistribusi (Socket Programming TCP/UDP)

Node.js Native Pure TCP Socket Length-Prefix Framing Non-Blocking Event Loop
Soal 1: Pemilihan Protokol TCP vs UDP (Chat CS & Heartbeat) 20 Poin

Pertanyaan: Pilih TCP atau UDP untuk chat dan heartbeat, lalu jelaskan alasannya.

1. Layanan Chat Customer Service: Pilihan = TCP (Transmission Control Protocol)

Alasan Teknis:

  • Persyaratan Wajib (Slide 18): Dinyatakan secara eksplisit bahwa "Pesan chat tidak boleh hilang atau tertukar urutannya".
  • Keandalan (Reliable Delivery): TCP menggunakan nomor urut (Sequence Numbers), tanda terima (ACK), dan mekanisme retransmisi otomatis jika terjadi packet loss. Bila menggunakan UDP, pesan chat dapat hilang tanpa notifikasi.
  • Urutan Pesan Terjamin (In-Order Delivery): Dalam komunikasi penanganan keluhan pelanggan (CS), konteks kalimat sangat kritis. TCP memastikan data dirakit kembali di sisi penerima sesuai urutan pengiriman awal.
  • Connection-Oriented & Stateful: Hubungan agen dan pelanggan memerlukan sesi komunikasi dua arah yang persisten (3-way handshake).

2. Mekanisme Heartbeat Antar-Instance: Pilihan = UDP (User Datagram Protocol)

Alasan Teknis:

  • Frekuensi Periodik (Slide 18): Setiap instance mengirim status tiap 5 detik. Status bersifat idempotent dan transient. Jika paket status pada detik ke-5 hilang, paket pada detik ke-10 akan segera menggantikannya dengan status terkini. Data lama yang hilang tidak relevan untuk diretransmisi.
  • Overhead Header Minimal: Header UDP hanya 8 byte (dibandingkan TCP minimal 20 byte). Tidak ada overhead 3-way handshake (SYN, SYN-ACK, ACK) maupun connection termination (FIN/ACK).
  • Skalabilitas Server Pemantau: Menghindari server pemantau kehabisan file descriptors / state table untuk ribuan instance mikroservis (User, Product, Order, Payment, Notification).
Ringkasan Matriks Perbandingan:
KarakteristikChat CS (TCP)Heartbeat Monitoring (UDP)
Sifat KoneksiConnection-oriented (Handshake 3-way)Connectionless (Kirim langsung datagram)
Garansi PengirimanPasti sampai (ACK + Retransmisi)Best-effort (Bisa hilang tanpa retransmisi)
Garansi UrutanTerjamin urut (Sequence Number)Tidak ada jaminan urutan
Header Overhead20 – 60 Byte8 Byte
Toleransi Kehilangan0% (Tidak boleh hilang sama sekali)Tinggi (Tertutup oleh heartbeat periode berikutnya)
Soal 2: Implementasi Server Chat Multi-Klien dengan Framing Length-Prefix 35 Poin

Pertanyaan: Implementasikan server chat multi-klien dengan framing length-prefix dan uji dengan minimal tiga klien.

Mengapa Membutuhkan Framing pada TCP?

TCP adalah protokol aliran byte berkelanjutan (byte-stream) tanpa konsep batas pesan (no message boundaries). Satu kali pemanggilan send() bisa tiba terpecah ke beberapa recv() (fragmentasi), atau beberapa send() digabung menjadi satu paket oleh algoritma Nagle (coalescence / sticky packets).

Struktur Frame yang Diimplementasikan:
+------------------------------------+---------------------------------------+
|  Panjang Pesan / Length (4 Byte)    |   Payload Data JSON / Teks (N Byte)   |
|  Unsigned 32-bit Integer Big-Endian |   {"type":"chat", "content":"Halo"}   |
+------------------------------------+---------------------------------------+

Format header !I (Network Byte Order / Big-Endian) 4-byte memungkinkan payload hingga 4 GB per frame secara presisi.

Kode Inti Server (Node.js Buffer Accumulator & Parser):

// Akumulasi chunk TCP yang masuk
clientInfo.buffer = Buffer.concat([clientInfo.buffer, chunk]);

// Parsing loop selama buffer memiliki minimal 4 byte header
while (clientInfo.buffer.length >= 4) {
  const expectedLength = clientInfo.buffer.readUInt32BE(0);
  const totalFrameSize = 4 + expectedLength;

  if (clientInfo.buffer.length >= totalFrameSize) {
    const payload = clientInfo.buffer.subarray(4, totalFrameSize);
    clientInfo.buffer = clientInfo.buffer.subarray(totalFrameSize);
    
    // Pesan utuh berhasil diekstrak!
    const message = JSON.parse(payload.toString('utf8'));
    broadcast(message);
  } else {
    // Menunggu chunk lanjutan dari TCP stream
    break;
  }
}

Silakan beralih ke tab "💻 Simulasi Multi-Klien Live" untuk melihat pengujian langsung 3 klien dengan packet coalescence & fragmentation!

Soal 3: Pemilihan Model Konkurensi untuk 2.200 Koneksi Bersamaan 20 Poin

Pertanyaan: Pilih model konkurensi server untuk 2.200 koneksi bersamaan (200 agen + 2.000 pelanggan) dan jelaskan alasannya.

Model Terpilih: Event Loop (Asynchronous Non-Blocking I/O)

Contoh teknologi: Node.js (libuv / epoll / IOCP), Nginx, Go Runtime, atau Netty.

Alasan Teknis & Analisis Perbandingan:

Model Konkurensi Kesesuaian untuk 2.200 Klien Analisis Beban Memori & Kinerja
1. Iteratif (Single Synchronous) ❌ Sangat Tidak Layak Hanya dapat melayani 1 klien hingga koneksi ditutup. Klien lain (2.199 klien) akan hang/mengantre, mustahil untuk chat real-time.
2. Thread per Koneksi ⚠️ Boros & Berat Membuat 2.200 thread OS. Setiap thread membutuhkan stack memori minimal 1 MB – 8 MB. Total alokasi RAM untuk stack thread saja = 2,2 GB s.d. 17,6 GB! Terjadi overhead context switching CPU yang sangat tinggi.
3. Thread Pool ⚠️ Berisiko Starvation Jika pool diisi 100-200 worker thread, dan 2.200 klien mempertahankan koneksi TCP persisten, maka sisa 2.000 koneksi akan tertahan di queue (thread exhaustion).
4. Event Loop (Asynchronous) ✅ Paling Efisien (Terbaik) Menggunakan I/O Multiplexing (epoll/kqueue/IOCP) pada 1 thread utama. Konsumsi memori per koneksi hanya sebesar struktur soket & buffer (~10-20 KB per koneksi). Untuk 2.200 koneksi hanya butuh RAM ~25 - 45 MB! Zero thread context-switching overhead.
Perhitungan Kebutuhan Memori (Memory Footprint Comparison):
• Thread per Connection: 2.200 thread × 1 MB = 2.200 MB (2,2 GB) hanya untuk alokasi stack thread kosong.
• Event Loop (Node.js): 2.200 koneksi × 15 KB ≈ 33 MB RAM. Sangat ringan, hemat biaya server, dan tahan banting.
Soal 4: Perhitungan Throughput Maksimum & Kebutuhan Window Scaling 25 Poin

Pertanyaan: Hitung throughput maksimum sinkronisasi arsip chat ke Singapura dan window yang diperlukan untuk 50 Mbps.

Parameter Jaringan NusaMart (Slide 12 & 18):
• RTT (Round Trip Time) Jakarta–Singapura = 40 ms = 0,04 detik
• Window Penerima Default (RWIN) = 64 KB = 65.536 byte
• Target Kecepatan Arsip = 50 Mbps

Bagian A: Menghitung Throughput Maksimum Saat Ini (Window = 64 KB)

Rumus Throughput Maksimum TCP:

Throughput Maksimum =
Window Size (bit) RTT (detik)
=
Window (Byte) × 8 RTT (detik)

Langkah-langkah Perhitungan:

  1. Konversi Window ke satuan bit:
    Window = 65.536 byte × 8 bit/byte = 524.288 bit
  2. Bagi dengan latensi RTT (0,04 detik):
    Throughput =
    524.288 bit 0,04 detik
    = 13.107.200 bps
  3. Konversi ke Megabits per second (Mbps):
    13.107.200 bps ÷ 1.000.000 = 13,11 Mbps (atau ≈ 13,1 Mbps)

Kesimpulan Bagian A: Meskipun pipa bandwidth fisik jaringan 1 Gbps, throughput sinkronisasi mentok di 13,11 Mbps karena batasan buffer penerima 64 KB dan latensi 40 ms.

Bagian B: Menghitung Kebutuhan Window untuk Mencapai 50 Mbps

Rumus Bandwidth-Delay Product (BDP):

BDP (bit) = Target Throughput × RTT = 50.000.000 bps × 0,04 s = 2.000.000 bit

Menghitung ukuran buffer Window dalam satuan Byte:

Window Diperlukan =
BDP (bit) 8 bit/byte
=
2.000.000 8
= 250.000 Byte

Konversi ke Kilobyte (KB):

  • Basis Biner (1 KB = 1024 Byte): 250.000 ÷ 1024 = 244,14 KB
  • Basis Desimal (1 KB = 1000 Byte): 250.000 ÷ 1000 = 250 KB

Solusi Teknis & Standar RFC 7323 (TCP Window Scaling):

Field Window Size pada header standar TCP hanya berukuran 16-bit, sehingga kapasitas buffer maksimum tanpa scaling dibatasi pada:

216 − 1 = 65.535 Byte (≈ 64 KB)

Karena kebutuhan buffer sinkronisasi adalah 250.000 Byte (> 65.535 Byte), maka server di Jakarta dan Singapura wajib mengaktifkan opsi TCP Window Scaling (RFC 7323).

Dengan Window Scaling, nilai window riil adalah:

Window Efektif = Window Header × 2w
  • Jika w = 1: 65.536 × 21 = 131.072 Byte (belum mencukupi)
  • Jika w = 2: 65.536 × 22 = 262.144 Byte (≥ 250.000 Byte → Mencukupi)

Kesimpulan: Diperlukan faktor skala pergeseran bit minimal w = 2.

Simulasi Multi-Klien Live & Packet Inspector Soal 2 Demo

Uji coba interaktif pengiriman pesan antara 3 klien (Agen CS Siti, Pelanggan Budi, Pelanggan Dewi). Perhatikan bagaimana header 4-byte Big-Endian selalu membatasi payload secara akurat meskipun terjadi fragmentasi atau penggabungan paket (coalescence).

Tampilan Ruang Chat (Multi-Client Room)

[SERVER] Server TCP Berjalan di port 5000. Siap menerima koneksi.

Raw TCP Frame Inspector (Wire-Level)

Belum ada packet transmission. Klik tombol aksi di atas untuk memulai pengiriman.
Kalkulator Interaktif Throughput & BDP TCP Soal 4 Tool

Ubah parameter latensi (RTT), Window buffer, atau target bandwidth untuk melihat pengaruh langsung pada performa transmisi socket.

Hasil Analisis Real-Time:

Throughput Maksimum Saat Ini:
13,11 Mbps
Kebutuhan Buffer Window untuk Target:
250.000 Byte (244,14 KB)
Rekomendasi Window Scaling:
Wajib Aktifkan RFC 7323 (Scale Factor w ≥ 2)
Struktur File Proyek & Panduan Menjalankan Dokumentasi

Semua program dibangun murni menggunakan modul bawaan Node.js (net, dgram, http) sehingga ringan, berkecepatan tinggi, dan tanpa perlu menjalankan `npm install`.

Nama FileFungsi & Deskripsi
server.jsTCP Multi-Client Chat Server dengan Framing 4-byte Length-Prefix Big-Endian
client.jsTCP Chat Client CLI interaktif (dapat dijalankan di beberapa terminal)
test_clients.jsAutomated test runner 3 klien simultan + uji packet coalescence & fragmentation
heartbeat.jsUDP Heartbeat Monitor Server & Client simulator untuk 5 mikroservis
web_server.jsWeb server HTTP ringan untuk membuka dashboard ini di browser
LAPORAN_KUIS_STUDI_KASUS.mdDokumen laporan lengkap siap kumpul dalam format Markdown terstruktur

Cara Menjalankan via Terminal:

# 1. Menjalankan pengujian otomatis multi-klien + framing TCP:
node test_clients.js

# 2. Menjalankan uji UDP Heartbeat:
node heartbeat.js

# 3. Menjalankan Server Chat interaktif:
node server.js

# 4. Membuka terminal lain untuk klien:
node client.js Agen_Siti
node client.js Pelanggan_Budi
node client.js Pelanggan_Dewi