materi

Pertemuan 2: Komunikasi Antar Proses (IPC), Remote Procedure Call (RPC), dan Peran Middleware

Komunikasi Antar Proses (IPC), Remote Procedure Call (RPC), dan Peran Middleware

Analisis teknis protokol komunikasi antar proses (Inter-Process Communication / IPC) pada lingkungan jaringan, arsitektur internal Remote Procedure Call (RPC), tahapan serialisasi dan marshalling data, penanganan semantik kegagalan panggilan remote, serta evolusi middleware modern menuju kerangka kerja gRPC.

1. Dari Socket API Tingkat Rendah Menuju Abstraksi RPC

Pada tingkat jaringan dasar, komunikasi antar komputer dilakukan menggunakan antarmuka Socket API (TCP atau UDP). Namun, pemrograman berbasis socket murni mewajibkan pengembang mengelola pembukaan koneksi (handshake), fragmentasi byte stream, konversi endianness, serta buffer data secara manual. Untuk mempermudah rekayasa perangkat lunak terdistribusi, Birrell dan Nelson (1984) memperkenalkan konsep Remote Procedure Call (RPC):

  • Paradigma RPC memungkinkan suatu program komputer memanggil fungsi atau prosedur yang berlokasi di mesin remote seolah-olah fungsi tersebut dieksekusi di ruang alamat memori lokal program itu sendiri.
  • Abstraksi ini menyembunyikan seluruh kerumitan soket jaringan di balik antarmuka pemanggilan fungsi biasa.

2. Anatomi dan Siklus Hidup Eksekusi RPC

Arsitektur RPC bekerja dengan melibatkan dua komponen perantara transparan yang disebut Stub:

  1. Client Stub: Komponen di sisi pemanggil yang bertindak sebagai representasi lokal dari prosedur remote.
  2. Server Stub (Skeleton): Komponen di sisi penyedia layanan yang menerima permintaan jaringan dan memanggil fungsi aktual di server.
sequenceDiagram
    autonumber
    actor Client as Client App
    participant CS as Client Stub
    participant OS_C as OS / Transport (Client)
    participant OS_S as OS / Transport (Server)
    participant SS as Server Stub
    participant Server as Server App

    Client->>CS: Panggil Fungsi Lokal (args)
    CS->>CS: Marshalling (Serialisasi Argumen ke Byte Stream)
    CS->>OS_C: Kirim Paket Pesan
    OS_C->>OS_S: Transmisi Jaringan (TCP/IP)
    OS_S->>SS: Teruskan Paket ke Stub Server
    SS->>SS: Unmarshalling (Ekstraksi Argumen Asli)
    SS->>Server: Eksekusi Prosedur Lokal Aktual
    Server->>SS: Kembalikan Nilai Hasil Komputasi
    SS->>SS: Marshalling (Serialisasi Hasil ke Byte Stream)
    SS->>OS_S: Kirim Paket Balasan
    OS_S->>OS_C: Transmisi Balik Melalui Jaringan
    OS_C->>CS: Terima Paket Balasan
    CS->>CS: Unmarshalling (Ekstraksi Hasil)
    CS->>Client: Kembalikan Nilai Akhir ke Pemanggil

Tahapan eksekusi secara runtut:

  1. Aplikasi client memanggil prosedur pada Client Stub dengan parameter input normal.
  2. Client Stub melakukan Marshalling (mengubah parameter dan struktur data kompleks menjadi format biner terstandarisasi yang siap dikirimkan melalui jaringan).
  3. Lapisan transport sistem operasi mengirimkan paket pesan melalui protokol jaringan (TCP/IP).
  4. Sistem operasi server menerima paket dan meneruskannya ke Server Stub.
  5. Server Stub melakukan Unmarshalling (membongkar representasi biner kembali menjadi parameter data asli di memori server).
  6. Server Stub memanggil fungsi lokal aktual pada aplikasi server dan menerima nilai hasil eksekusi.
  7. Hasil kembalian dipaketkan kembali oleh Server Stub dan dikirim balik melalui jaringan menuju client.
  8. Client Stub menerima paket balasan, melakukan unmarshalling, dan meneruskan hasil akhir ke aplikasi pemanggil.

3. Semantik Penanganan Kegagalan (Fault Semantics)

Panggilan fungsi lokal hampir tidak pernah gagal kecuali terjadi kesalahan logika atau kehabisan memori. Sebaliknya, panggilan remote rentan mengalami kegagalan transmisi jaringan di tengah proses. Oleh karena itu, sistem RPC menerapkan spesifikasi semantik kegagalan:

  • At-least-once Semantics: Sistem terus mengulang pengiriman pesan panggilan sampai memperoleh konfirmasi balasan (acknowledgement). Semantik ini hanya aman digunakan pada operasi yang bersifat idempoten (operasi yang jika dieksekusi berulang kali memberikan dampak status sistem yang persis sama, misal kueri pembacaan data GET).
  • At-most-once Semantics: Server mencatat identitas unik setiap panggilan transaksi. Jika pesan duplikat diterima akibat timeout jaringan, server tidak mengeksekusi ulang prosedur, melainkan langsung mengembalikan hasil perhitungan sebelumnya. Semantik ini wajib diterapkan pada transaksi non-idempoten (seperti pemotongan saldo rekening bank).
  • Exactly-once Semantics: Menjamin prosedur dieksekusi tepat satu kali tanpa duplikasi maupun kehilangan, yang memerlukan koordinasi protokol konsensus terdistribusi tingkat tinggi (seperti Paxos atau Raft).

4. Evolusi Middleware Modern: gRPC dan Message Queues

Perkembangan teknologi komputasi cloud dan arsitektur microservices membawa evolusi besar dari Java RMI dan CORBA menuju standar modern:

  • gRPC (Google Remote Procedure Call):
    • Menggunakan Protocol Buffers (Protobuf) sebagai format serialisasi biner berkecepatan tinggi yang jauh lebih ringkas dan cepat dibandingkan format teks JSON atau XML.
    • Memanfaatkan protokol transport HTTP/2 yang mendukung multiplexing simultan dalam satu koneksi TCP tunggal, bidirectional streaming, serta kompresi header.
    • Bersifat independen terhadap bahasa (language-agnostic), memungkinkan microservice berbasis Go berkomunikasi mulus dengan microservice berbasis Python atau Java.
  • Asynchronous Message Broker: Untuk sistem yang tidak memerlukan respon instan secara sinkron (decoupled async communication), arsitektur modern memanfaatkan middleware antrean pesan seperti Apache Kafka atau RabbitMQ.