Model - Remote Procedure Call (RPC)

Back to IF3130 Sistem Paralel dan Terdistribusi

Topic

Questions/Cues

• Kenapa RPC dibuat?

• Apa itu Stub?

• Jelaskan 10 langkah alur RPC

• Apa itu Marshaling?

• Masalah pass-by-reference?

• 5 masalah representasi data?

• Solusi representasi data?

• Implicit vs Explicit Typing?

• Apa itu Binding?

• Jelaskan alur DCE Binding

• 3 semantik call RPC?

• Beda At least once vs At most once?

• Apa itu Idempotent?

• 3 varian RPC Asinkronus?

• Apa itu IDL?

• Alur kerja IDL Compiler?

Reference Points

• Slides 17-40 (11 - IF3130-11-Communication-2022.pdf)

• Kuliah Komunikasi

1. Konsep Remote Procedure Call (RPC)

Pemrograman client-server menggunakan socket (read/write) cukup rumit. RPC (1984, Birrell & Nelson) diajukan sebagai abstraksi yang membuat komunikasi jaringan terlihat seperti pemanggilan prosedur/fungsi lokal biasa.

Ide: Daripada write(socket, "add,i,j"), programmer bisa langsung menulis k = add(i, j).

2. Stub

Untuk menipu client agar mengira ia memanggil fungsi lokal, digunakan mekanisme stub.

• Client Stub: Prosedur lokal di sisi client yang memiliki interface (nama dan parameter) yang sama dengan prosedur remote. Tugasnya: melakukan marshaling parameter menjadi pesan dan mengirim pesan.

• Server Stub: Prosedur di sisi server yang menerima pesan. Tugasnya: melakukan unmarshaling pesan menjadi parameter dan memanggil prosedur implementasi yang sebenarnya.

3. Alur Dasar RPC (Slide 21)

1. Client process memanggil client stub (terlihat seperti local call).

2. Client stub membuat (build) pesan (proses marshaling parameter).

3. Client stub memanggil OS lokal untuk mengirim pesan ke server machine.

4. OS server menerima pesan dan memberikannya ke server stub.

5. Server stub membuka (unpack) pesan (proses unmarshaling).

6. Server stub memanggil prosedur implementasi add di server process.

7. Implementasi add selesai dan mengembalikan hasil ke server stub.

8. Server stub membuat pesan reply (marshaling return value).

9. OS server mengirim reply ke client, diterima OS client, diberikan ke client stub.

10. Client stub membuka reply (unmarshaling) dan mengembalikan hasil ke client process.

4. Tantangan RPC: Parameter & Data

Parameter Marshaling: Proses packing parameter ke dalam pesan.

• Pass-by-value: Mudah, cukup salin nilainya ke pesan.

• Pass-by-reference (Pointer): Tidak relevan karena client dan server tidak berbagi memori.

• Solusi: Salin item yang di-referensi ke pesan, kirim, server stub membuat pointer lokal ke data salinan itu, dan jika berubah, salin kembali ke reply.

Representasi Data: Mesin client dan server bisa berbeda dalam:

1. Byte ordering (Big-endian vs Little-endian).

2. Ukuran integer (16, 32, 64 bit).

3. Representasi floating point.

4. Character set (ASCII, EBCDIC, UTF-8).

5. Aturan alignment.

Solusi: RPC butuh standar encoding data.

• Dulu: Sun RPC menggunakan XDR (eXternal Data Representation). ISO menggunakan ASN.1.

• Sekarang: JSON, XML, Protocol Buffers (Protobuf), Apache Avro.

Typing:

• Implicit Typing (XDR): Hanya nilai yang dikirim. Tipe data disepakati sebelumnya. Cepat tapi tidak fleksibel.

• Explicit Typing (ASN.1, XML, Protobuf): Tipe data dikirim bersama nilainya. Lebih fleksibel, human-readable (jika XML/JSON), tapi overhead lebih besar.

5. Tantangan RPC: Binding

Binding adalah proses client menemukan host (mesin) dan proses (server) yang tepat untuk sebuah RPC.

Alur DCE Binding (Slide 29):

1. Server (saat start) mendaftarkan endpoint (port) ke DCE daemon (agen lokal di server machine).

2. Server mendaftarkan layanannya (nama, lokasi) ke Directory Server terpusat.

3. Client (saat ingin memanggil) bertanya ke Directory Server, “Di mana server machine untuk layanan ‘X’?”

4. Client bertanya ke DCE daemon di server machine itu, “Di endpoint (port) berapa layanan ‘X’?”

5. Client melakukan RPC ke server machine di endpoint yang didapat.

6. Tantangan RPC: Semantik Error

Local call gagal hanya jika seluruh proses gagal (semantik exactly once).

Remote call (RPC) bisa gagal dengan berbagai cara:

• 0 kali: Server crash sebelum menjalankan kode.

• 1 kali: Semua berjalan baik (ideal).

• 1 atau lebih kali: Reply dari server hilang di jaringan. Client tidak tahu, lalu timeout dan mengirim ulang request (re-eksekusi).

Implementasi RPC umumnya menyediakan 2 semantik (pilih salah satu):

• At least once: “Setidaknya sekali”. RPC akan terus di-retry sampai client dapat reply. Aman untuk fungsi idempotent.

• At most once: “Paling banyak sekali”. Server punya mekanisme (misal: cek ID request) untuk mendeteksi dan membuang request duplikat. Lebih sulit diimplementasi, tapi wajib untuk fungsi non-idempotent.

Idempotent: Fungsi yang aman dipanggil berkali-kali tanpa mengubah hasil (misal: getBalance(), setA(10)).

Non-Idempotent: Fungsi yang berbahaya jika dipanggil ulang (misal: transfer(100), addStock(10)).

7. RPC Asinkronus

RPC standar bersifat sinkronus (blocking). Ada variasi asinkronus:

1. RPC Asinkronus (b): Client blocking hanya sampai server menerima (accept) request, bukan sampai selesai proses. Client tidak dapat return value.

2. Deferred Synchronous RPC (c): Client melakukan call (b), lalu lanjut kerja. Server (setelah selesai proses) memanggil client kembali (menggunakan one-way RPC) untuk memberikan hasilnya.

8. Implementasi RPC (IDL)

IDL (Interface Definition Language) adalah bahasa formal untuk mendefinisikan interface (nama fungsi, parameter, tipe data) sebuah layanan RPC.

Alur Kerja:

1. Programmer menulis Interface.idl.

2. IDL Compiler (misal: rpcgen untuk Sun RPC) dijalankan.

3. Compiler ini men-generate 3 file kode: Client stub, Server stub, dan Header file.

4. Programmer menulis kode Client (yang memanggil stub) dan kode Server (implementasi fungsi).

5. Semua di-compile dan di-link terpisah menjadi Client binary dan Server binary.

Summary

RPC adalah abstraksi function call untuk sistem terdistribusi, yang menyembunyikan kompleksitas jaringan menggunakan client dan server stubs. Stubs ini di-generate secara otomatis dari file IDL (Interface Definition Language). Tantangan utama dalam RPC adalah marshaling (packing parameter), menangani perbedaan representasi data (via XDR, JSON, Protobuf), binding (penemuan layanan), dan semantik error (seperti at-least-once untuk fungsi idempotent vs at-most-once).

Additional Information

Pendalaman: RPC Modern (gRPC)

RPC adalah konsep lama (1984), tapi mengalami kebangkitan besar dengan gRPC (Google RPC).

• IDL: gRPC menggunakan Protocol Buffers (Protobuf) sebagai IDL-nya. Ini adalah standar dari Google untuk serialisasi data.

• Representasi Data: Protobuf men-serialisasi data menjadi format binary yang sangat ringkas dan cepat (jauh lebih cepat dari JSON/XML). Ini adalah explicit typing.

• Transport: gRPC menggunakan HTTP/2 sebagai protokol transport, yang memungkinkan fitur modern seperti streaming dua arah dan multiplexing.

gRPC sekarang sangat populer untuk komunikasi antar microservices karena performanya yang tinggi.

Eksplorasi Mandiri

• Lihat contoh file .proto (Protocol Buffers). Perhatikan bagaimana Anda mendefinisikan service (RPC) dan message (data) dalam satu file.

• Bandingkan XDR (dari Sun RPC) dengan JSON. XDR adalah implicit typing (hanya nilai), sedangkan JSON adalah explicit typing (tipe + nilai, via key).