IF Notes

Semantik Eksekusi, Async RPC, dan Implementasi Praktis

5 min read

Back to IF3130 Sistem Paralel dan Terdistribusi

Topic: Semantik Eksekusi, Async RPC & Implementasi Sun RPC

Questions/Cues

  • Partial Failure

  • Semantik RPC (Maybe, At-least, At-most)

  • Idempotent vs Non-Idempotent

  • Async RPC (One-way)

  • Deferred Sync RPC

  • IDL (.x file)

  • Output rpcgen

  • Static Result (Server)

  • clnt_create & Binding

Reference Points

  • Slides: Page 23-40

  • Fokus: Error Handling & Coding

1. Tantangan Utama: Kegagalan Parsial (Partial Failure)

Berbeda dengan Local Procedure Call yang bersifat “berhasil semua” atau “gagal total” (aplikasi crash), RPC menghadapi ketidakpastian jaringan.

  • Skenario Kegagalan:

    1. Klien tidak bisa menemukan server.

    2. Request hilang di jalan (Server tidak pernah terima).

    3. Server crash saat memproses.

    4. Reply (balasan) hilang di jalan (Server sukses, tapi Klien tidak tahu).

  • Dampak: Klien tidak bisa membedakan antara server yang lambat, mati, atau masalah jaringan.

2. Semantik Eksekusi (Jaminan RPC)

Sistem RPC diklasifikasikan berdasarkan seberapa keras Klien mencoba mengirim ulang request saat terjadi kegagalan.

A. Semantik “Maybe” (0 atau 1 kali)

  • Prinsip: Klien mengirim request sekali. Jika time-out/error, klien menyerah.

  • Hasil: Server mungkin menjalankannya (1) atau tidak sama sekali (0).

  • Kelemahan: Tidak ada jaminan sukses. Jarang dipakai untuk sistem kritis.

B. Semantik “At-Least-Once” (1 kali atau lebih)

  • Prinsip: Klien terus melakukan retry (kirim ulang) sampai mendapat konfirmasi (Reply).

  • Masalah: Jika reply yang hilang (bukan request), Server akan menerima request yang sama dua kali. Server akan memproses ulang.

  • Syarat: Operasi harus IDEMPOTENT.

C. Semantik “At-Most-Once” (0 atau 1 kali) - Paling Aman

  • Prinsip: Server mendeteksi duplikasi. Jika request yang sama datang lagi (karena klien retry), server tidak memproses ulang, tapi mengirimkan hasil lama yang tersimpan (cache).

  • Keuntungan: Menjamin operasi tidak pernah dijalankan lebih dari sekali. Aman untuk operasi Non-Idempotent.

3. Konsep Idempotency

Definisi: Operasi yang jika dilakukan berulang kali, hasil akhirnya tetap sama dengan jika dilakukan satu kali.

  • Operasi Idempotent (Aman diulang):

    • x = 5; (Assignment nilai absolut)

    • read_file(); (Membaca data)

    • check_balance(); (Cek saldo)

  • Operasi Non-Idempotent (Bahaya diulang):

    • x = x + 5; (Increment relative)

    • transfer_money(); (Transaksi finansial)

    • append_to_file(); (Menambah data di akhir)

4. Variasi Komunikasi: Asynchronous RPC

Model RPC standar memblokir Klien (Blocking). Klien tidak bisa kerja lain saat menunggu Server.

A. Asynchronous RPC (One-way)

  • Alur: Klien kirim request → Server segera kirim ACK (Tanda terima) → Klien lanjut kerja.

  • Beda: Klien TIDAK menunggu hasil pemrosesan server. Klien hanya tahu pesan “sampai”.

  • Diagram: Lihat Slide 27.

B. Deferred Synchronous RPC (Two-way Async)

  • Alur:

    1. Klien kirim → Server ACK → Klien kerja lain.

    2. Server memproses request yang berat/lama.

    3. Setelah selesai, Klien mengambil hasil (Result).

  • Mekanisme Ambil Hasil:

    • Polling: Klien bertanya berkala (“Sudah selesai?”).

    • Callback: Server memanggil prosedur di Klien untuk memberi hasil.

5. Implementasi Praktis: Sun RPC (ONC RPC)

Sun RPC menggunakan pendekatan berbasis IDL (Interface Definition Language).

A. File .x (IDL)

Mendefinisikan kontrak komunikasi (struct, program ID, version).

struct intpair { int a; int b; };
program MATH_PROG {
    version MATH_VERS {
        int ADD(intpair) = 1;
    } = 1;
} = 0x23451111;

B. Tool rpcgen

Kompilasi: rpcgen -a -C math.x. Menghasilkan:

  • math.h: Header file.

  • math_svc.c: Server Stub (Main loop, register socket).

  • math_clnt.c: Client Stub (Wrapper function).

  • math_xdr.c: Marshaling data.

C. Kode Server (Rule: Static Result)

int * add_1_svc(intpair *argp, struct svc_req *rqstp) {
    static int result;  // WAJIB STATIC!
    result = argp->a + argp->b;
    return &result;     // Return pointer ke static
}

Alasan: Stub server butuh data tetap ada di memori setelah fungsi return untuk proses pengiriman. Variabel lokal (stack) akan hilang.

D. Kode Client (Rule: Binding)

// 1. Binding (Tanya Portmapper)
clnt = clnt_create("localhost", MATH_PROG, MATH_VERS, "udp");
// 2. Panggil Remote Function
result = add_1(&args, clnt);

clnt_create menghubungi Portmapper di host tujuan untuk mendapatkan port dinamis server.

Summary

RPC menghadapi tantangan Partial Failure yang memerlukan pemilihan semantik eksekusi: At-Most-Once (paling aman untuk transaksi non-idempotent) atau At-Least-Once (untuk operasi idempotent). Asynchronous RPC digunakan untuk menghindari blocking pada klien. Implementasi Sun RPC bergantung pada IDL (.x) dan rpcgen untuk membuat stub, serta mengharuskan penggunaan variabel static pada server dan fungsi clnt_create pada klien untuk menangani binding dinamis.

Graph View

Backlinks