2,2 PANGGILAN REMOTE PROSEDUR Sistem terdistribusi banyak didasarkan pada exchenge pesan eksplisit antara proses.

Namun, prosedur mengirim dan menerima tidak menyembunyikan komunikasi, yang penting untuk mencapai akses Transparansi dalam sistem terdistribusi. Masalah ini telah lama dikenal, namun sedikit yang dilakukan sampai kertas oleh Birrell dan nelson (1984) memperkenalkan cara yang sama sekali berbeda dari penanganan komunikasi. Meskipun gagasan ini refresingly sederhana implikasi sering halus. Dalam bagian ini kita akan membahas konsep, pelaksanaannya, kekuatan, dan kelemahan. Singkatnya, apa yang Birrell dan nelson disarankan yang memungkinkan program untuk memanggil prosedur yang terletak pada mesin lain. Ketika sebuah proses pada mesin A memanggil prosedur pada mesin B, proses menyerukan A ditunda, dan exacution dari prosedur yang disebut berlangsung Informasi B. dapat diangkut dari pemanggil ke callee dalam parameter dan bisa kembali dalam hasil prosedur. Tidak ada pesan lewat sama sekali dapat dilihat oleh programmer. Metode ini tahu sebagai panggilan prosedur remote, atau sering hanya RPC. Whike ide dasar terdengar sederhana dan elegan, halus masalah yang ada. Untuk mulai dengan, karena prosedur panggilan dan disebut berjalan pada mesin yang berbeda, mereka mengeksekusi dalam ruang alamat yang berbeda, yang menyebabkan komplikasi. Parameter dan hasil juga harus dilalui, yang bisa rumit, terutama jika achines tidak identik. Akhirnya, kedua mesin dapat ditangani, dan RPC adalah teknik yang digunakan secara luas yang mendasari sistem terdistribusi banyak.

2.2.1 DASAR OPERASI RPC Pertama-tama kita mulai dengan membahas panggilan prosedur konvensional, dan kemudian menjelaskan bagaimana panggilan itu sendiri dapat dibagi bagian client dan server yang masing-masing dijalankan pada mesin yang berbeda. KONVENSIONAL PROSEDUR PANGGILAN Untuk undersatand bagaimana RPC bekerja, penting untuk memahami bagaimana panggilan prosedur konvensional bekerja. Pertimbangkan panggilan dalam seperti Count = read (fd, buf, nbytes); Dimana fd merupakan integer yang menunjukkan file, buf adalah array dari karakter di mana data dibaca, dan nbytes adalah bilangan bulat lainnya mengatakan berapa banyak byte untuk membaca. Jika panggilan tersebut dibuat dari program utama, stack akan seperti yang ditunjukkan pada gambar. 2-6 sebelum panggilan tersebut. Untuk membuat panggilan, si penelepon mendorong parameter ke Stach dalam rangka,, ast pertama satu, seperti yang ditunjukkan pada gambar. Setelah membaca telah selesai berjalan, menempatkan nilai kembali dalam register, menghilangkan alamat pengirim, dan transfer kontrol kembali ke pemanggil. Penelepon kemudian menghapus parameter dari stack, kembali ke keadaan semula. Beberapa hal yang perlu diperhatikan. Untuk satu parameter C dapat panggilan dengan nilai atau panggilan dengan referensi. Sebuah nilai parameter, seperti fd atau nbytes, hanya copyed ke stack seperti yang ditunjukkan pada gambar. Untuk prosedur callad, parameter nilai hanya sebuah variabel lokal diinisialisasi. Prosedur yang disebut dapat memodifikasi tetapi perubahan tersebut tidak mempengaruhi nilai asli di sisi menelepon. Sebuah parameter acuan dalam C adalah pointer ke variabel daripada nilai variabel. Dalam panggilan untuk membaca, parameter kedua adalah array parameter acuan bacause selalu dikirimkan dengan referensi dalam C. Apa yang

sebenarnya didorong ke stack adalah alamat dari array karakter. Jika prosedur yang disebut menggunakan parameter ini untuk menyimpan sesuatu ke dalam array caracter, itu tidak mengubah array dalam prosedur menelepon. Perbedaan antara panggilan dengan nilai dan panggilan dengan referensi yang cukup penting bagi RPC, seperti yang akan kita lihat. Salah satu parameter mekanisme lewat lainnya juga ada, meskipun tidak digunakan dalam C. Hal ini disebut panggilan dengan copy / restore. Ini consitent memiliki variabel disalin ke tumpukan oleh pemanggil, sebagai incall dengan nilai, dan kemudian disalin kembali setelah panggilan, Timpa nilai asli pemanggil. Dalam kondisi yang paling, ini mencapai efek yang sama persis dengan panggilan dengan refernce, namun dalam beberapa situasi, seperti parameter yang sama hadir beberapa kali dalam daftar parameter, semantich berbeda. Panggilan oleh copy / restore machanism tidak digunakan dalam banyak bahasa. Keputusan yang parameter mekanisme lewat untuk menggunakan biasanya dibuat oleh para desainer bahasa dan adalah properti tetap bahasa. Kadangkadang itu tergantung pada jenis data yang berlalu. Dalam C, misalnya, bilangan bulat dan jenis skalar lainnya selalu dilewatkan dengan nilai, sedangkan array selalu dikirimkan dengan referensi, seperti yang telah kita lihat. Beberapa ADA compiler copy penggunaan / restore dalam parameter keluar, tetapi yang lain menggunakan panggilan dengan referensi. Definisi Bahasa memungkinkan baik pilihan, yang membuat semantik sedikit kabur.

KLIEN DAN SERVER Rintisan Ide dibalik RPC adalah untuk membuat panggilan prosedur remote terlihat sebanyak mungkin seperti satu lokal. Dengan kata lain, kita ingin RPC menjadi transparan prosedur menelepon tidak harus menyadari bahwa prosedur yang disebut dijalankan pada mesin yang berbeda atau sebaliknya. Misalkan sebuah program perlu membaca beberapa data dari file. Programmer menempatkan

panggilan untuk membaca dalam kode untuk mendapatkan data. Dalam sistem tradisional, rutin dibaca exctracted dari perpustakaan oleh linker dan dimasukkan ke dalam program objek. Ini adalah prosedur yang singkat, yang umumnya dilaksanakan dengan memanggil panggilan membaca sistem yang setara. Dengan kata lain, prosedur baca adalah jenis antarmuka antara kode dan sistem operasi lokal. Meskipun membaca melakukan system call, hal itu disebut dengan cara yang biasa, dengan mendorong parameter ke stack, sebagaimana shoun di ara. Sehingga programmer tidak tahu bahwa membaca benar-benar melakukan sesuatu yang mencurigakan, RPC mencapai transparenchy dalam cara analog. Ketika membaca sebenarnya adalah sebuah prosedur remote versi yang berbeda dari baca, disebut menggunakan urutan memanggil Juga Lika yang asli, juga, melakukan panggilan ke sistem operasi lokal. Hanya berbeda satu, tidak meminta sistem operasi untuk memberikan data. Sebaliknya, itu bungkus parameter dalam pesan dan meminta agar pesan yang akan dikirim ke server seperti yang diilustrasikan pada gambar. Setelah panggilan untuk mengirim, rintisan klien panggilan menerima, memblokir sendiri sampai balasan datang kembali. Ketika pesan tiba di server, sistem operasi server dibagikan hingga rintisan memutuskan. Sebuah rintisan server adalah sisi server setara dengan stub client, yang merupakan plece kode yang mengubah permintaan datang melalui jaringan menjadi panggilan prosedur lokal. Biasanya rintisan server akan memiliki calle menerima dan akan diblokir menunggu untuk pesan masuk yang membongkar rintisan server parameter dari pesan dan kemudian memanggil prosedur server dalam cara yang biasa dari titik server pandang, itu seolah-olah ia sedang dipanggil langsung oleh klien parameter dan adreess semua kembali pada tumpukan mana kemudian mengembalikan hasilnya ke pemanggil dengan cara yang biasa. Sebagai contoh, dalam kasus baca server akan mengisi buffer,

arahkan oleh parameter kedua, dengan data. Buffer ini akan internal untuk rintisan server. Ketika rintisan server yang mendapatkan kontrol kembali setelah panggilan telah selesai, itu bungkus hasil dalam pesan dan panggilan kirim kembali ke klien. Setelah itu, rintisan server biasanya melakukan panggilan untuk menerima lagi, menunggu untuk permintaan yang masuk berikutnya. Ketika pesan akan kembali kontrol ke mesin klien, sistem operasi klien melihat bahwa itu ditujukan kepada proses klien. Pesan akan disalin ke buffer menunggu dan proses klien diblokir. Rintisan klien memeriksa pesan, membongkar hasilnya, salinan ke pemanggil, dan mengembalikan cara yang biasa inthe, saat penelepon mendapatkan kontrol setelah panggilan untuk membaca, semua itu tahu adalah bahwa data yang avaibel. Ini memiliki tidak tahu bahwa pekerjaan itu dilakukan dari jarak jauh bukan oleh sistem operasi lokal. Ini ketidaktahuan bahagia pada bagian dari klien adalah keindahan seluruh skema. Sejauh ini yang bersangkutan, layanan remote diakses dengan membuat panggilan prosedur biasa. Bukan dengan menelepon mengirim dan diakses, sama seperti yang lewat pesan yang tersembunyi di perpustakaan tradisional. Untuk meringkas, panggilan prosedur remote terjadi dalam langkah-langkah berikut; 1. Prosedur klien memanggil rintisan klien dengan cara biasa. 2. Rintisan klien membangun pesan dan sistem operasi lokal. 3. Klien OS mengirimkan pesan ke OS remote. 4. The OS jarak jauh memberikan mesage ke rintisan server. 5. Rintisan Server membongkar parameter dan memanggil server. 6. Server melakukan pekerjaan dan mengembalikan hasilnya ke stub. 7. Rintisan Server kemasan dalam pesan dan panggilan OS lokal. 8. Server OS mengirim pesan ke OS client

9. OS client memberikan pesan ke client stub. 10. Stub membongkar hasil dan kembali ke klien.

Efek bersih dari semua langkah ini adalah untuk mengkonversi lokal dengan prosedur klien ke klien stub, untuk panggilan lokal ke server tanpa prosedur baik client atau server menyadari langkah-langkah perantara.

.2.2 Parameter passing Fungsi rintisan klien untuk mengambil parameter, pak mereka ke dalam pesan. Dan mengirim mereka ke rintisan server. Sementara ini terdengar sederhana, tidak sesederhana itu pada awalnya muncul. Dalam bagian ini kita akan melihat beberapa isu terkait dengan parameter passing di RPCsystems.

MENGADILI PARAMETER NILAI parameter ke dalam pesan disebut mashaling parameter. Sebagai contoh yang sangat sederhana, mempertimbangkan prosedur remote, yang mengambil dua parameter intege i dan j dan mengembalikan jumlah arhitmetic mereka sebagai hasilnya. Panggilan untuk menambah, ditampilkan di bagian tangan kiri pada gambar 2-8 rintisan klien nama atau jumlah prosedur yang akan dipanggil dalam bacause pesan server mungkin mendukung panggilan yang berbeda, dan itu harus diberitahu mana yang diperlukan. Ketika pesan tiba di server, stub memeriksa pesan untuk melihat mana prosedur yang diperlukan dan membuat panggilan oppropriate. Jika server juga mendukung procesure terpencil lainnya, rintisan serner mungkin memiliki pernyataan switch di dalamnya untuk memilih prosedur yang akan dipanggil tergantung pada field pertama dari pesan. Panggilan sebenarnya dari rintisan ke server terlihat sangat mirip dengan panggilan klien asli, kecuali bahwa parameter adalah variabel diinisialisasi dari pesan yang masuk. Ketika server telah fiised, keuntungan Server stub mengendalikan lagi.

Dibutuhkan hasil yang disediakan oleh server dan paket ke pesan. Pesan ini dikirim kembali ke stub klien, yang membongkar dan mengembalikan nilai prosedur klien. Selama manhines client dan server yang identik dan semua parameter dan hasil yang skalar jenis, seperti bilangan bulat, karakter, dan boolean, model ini bekerja dengan baik. Howefer, dalam sistem terdistribusi yang besar,, itu adalah umum bahwa beberapa jenis mesin yang hadir. Masing-masing mesin sering memiliki representasi sendiri untuk angka, karakter, dan data lainnya item. Misalnya. Mainframe IBM menggunakan kode karakter EBCDIC, sedangkan IBM personalcomputers menggunakan ASCII. Sebagai akibatnya, tidak mungkin untuk melewati parameter fron karakter klien PC IBM ke server mainframe IBM menggunakan skema sederhana ara 2-8. Server akan menafsirkan karakter salah. Masalah serupa dapat terjadi wih representasi integer dan angka floating point. Selain itu, masalah yang bahkan lebih menjengkelkan ada karena beberapa mesin seperti jumlah pentium intel byte mereka dari kanan ke kiri, sedangkan lainnya seperti jumlah SPARC matahari mereka dengan cara lain, format intel disebut little endian dan format SPARC adalah disebut big endian, setelah politisi dalam perjalanan gulliver s yang pergi berperang di mana ujung telur untuk istirahat. (Cohan, 1981). Sebagai contoh perhatikan prosedur dengan dua parameter, integer dan string karakter empat. Setiap parameter membutuhkan satu 32-bit word. Gambar 2-9 menunjukkan apa bagian parameter pesan yang dibangun oleh stub klien pada pentium intel mungkin terlihat seperti. Kata pertama berisi parameter integer, 5 dalam hal ini, dan yang kedua berisi string "JILL". Karena pesan ditransfer byte selama lebih dari jaringan, byte pertama dikirim adalah byte firct tiba. Dalam ara 2-9 kita menunjukkan apa pesan ara 29 akan terlihat seperti jika diterima oleh SPARC, yang nomor byte dengan 0 byte di sebelah kiri (urutan byte tinggi) bukan (urutan byte rendah) tepat seperti

yang dilakukan semua intel chip. Ketika rintisan server yang membaca parameter di alamat 0 dan 4, masing-masing, ia akan menemukan integer sama dengan 83.886.080 (5 * 2 ^ 24) dan string "JILL". Satu yang jelas, tapi sayangnya tidak benar, pendekatan adalah hanya membalikkan byte dari setiap kata setelah mereka diterima, mengarah ke ara 2-9 sekarang integer adalah 5 dan string adalah "LLIJ" masalah di sini adalah bahwa bilangan bulat dibalik oleh byte yang berbeda memesan, tapi string tidak. Tanpa informasi tambahan tentang apa yang string dan apa adalah integer, tidak ada cara untuk memperbaiki kerusakan.

MENGADILI PARAMETER REPERENCE Kita sekarang sampai pada masalah yang sulit: bagaimana pointer, atau secara umum, referensi berlalu? jawabannya adalah: hanya dengan kesulitan besar, jika sama sekali. Ingat bahwa pointer bermakna hanya dalam ruang alamat dari proses yang sedang digunakan. Mendapatkan kembali ke contoh kita membaca dibahas sebelumnya, jika parameter kedua (alamat buffer) terjadi menjadi 1000 pada klien, seseorang tidak bisa hanya melewati angka 1000 hingga server dan mengharapkan untuk bekerja. Alamat 1000 di server mungkin di tengah-tengah teks program. Salah satu solusinya adalah hanya untuk melarang pointer dan parameter referensi pada umumnya howefer, ini sangat penting bahwa solusi ini sangat tidak diinginkan. Padahal, itu tidak perlu baik. Pada contoh membaca, ctub klien tahu bahwa titik parameter kedua ke karakter array. Misalkan, untuk saat ini, bahwa ia juga tahu seberapa besar array. Satu startegy kemudian menjadi jelas: copy array ke dalam pesan dan mengirimkannya ke server. rintisan server dapat menyebutnya server whit a ti pointer array ini, meskipun pointer ini memiliki nilai numerik yang berbeda dari parameter kedua membaca memiliki. Perubahan membuat server menggunakan pointer secara langsung mempengaruhi penyangga themessage dalam rintisan server. Ketika server

selesai, pesan asli dapat dikirim kembali ke client stub, yang kemudian salinan kembali ke klien. Akibatnya, callit referensi telah digantikan oleh copy / restore. Meskipun hal ini tidak selalu identicial, sering cukup baik. Salah satu optimasi membuat mekanisme ini dua kali lebih efisien. Jika stub mengetahui apakah buffer adalah parameter masukan atau parameter output ke server, salah satu salinan cam dihilangkan. Jika array adalah masukan ke server itu tidak perlu disalin kembali. Jika itu adalah output, tidak perlu dikirim melalui tempat inthe pertama. Sebagai komentar terakhir, perlu dicatat bahwa meskipun kita sekarang dapat menangani pointer ke array sederhana dan struktur, kita stillcannot menangani kasus yang paling umum dari pointer ke struktur data yang sewenang-wenang seperti grafik yang kompleks. Beberapa upaya sistem untuk menangani kasus ini dengan actualli melewati pointer ke stub theserver dan menghasilkan kode khusus dalam prosedur server untuk menggunakan pointer. Misalnya, permintaan dapat dikirim kembali ke klien untuk menyediakan data yang direferensikan.

PARAMETER SPESIFIKASI DAN GENERASI rintisan. Dari apa yang sudah dijelaskan sejauh ini, jelas itis yang menyembunyikan panggilan permintaan prosedur remote bahwa pemanggil dan callee menyepakati format pesan yang mereka bertukar, dan bahwa mereka mengikuti langkah yang sama ketika datang ke, misalnya, melewati cimplex struktur data. Dengan kata lain, kedua belah pihak dalam RPC harus mengikuti protokol yang sama. Sebagai contoh sederhana, considerthe prosedur ara 2-10. Ini memiliki tiga parameter karakter, sejumlah floating-point, dan sebuah array dari lima bilangan bulat. Dengan asumsi sebuah kata adalah empat byte, protokol RPC mungkin meresepkan bahwa kita harus mengirimkan karakter dalam byte righmost dari kata (meninggalkan 3 berikutnya byte kosong), pelampung

sebagai seluruh kata, dan sebuah array sebagai kelompok kata yang sama dengan panjang array, perceded dengan kata memberikan panjang, seperti yang ditunjukkan pada gambar 2-10 sehingga diberikan aturan-aturan ini, rintisan klien untuk foobar tahu bahwa ia harus menggunakan format ara. 2-10, dan rintisan server yang tahu bahwa pesan yang masuk untuk footbar akan memiliki format ara 2-10. format pesan merupakan salah satu aspek dari protokol RPC, tetapi tidak cukup. Apa yang kita alsoneed adalah klien dan server untuk menyepakati representasi dari struktur data sederhana, seperti integer, karakter, boolean, dll Sebagai contoh, protokol bisa menentukan bahwa bilangan bulat terwakili dalam melengkapi dua itu, karakter dalam 16-bit unicode , dan flost dalam standar IEEE # 754 format, dengan segala sesuatu yang tersimpan dalam little endian. Dengan informasi tambahan ini, pesan dapat ditafsirkan jelas. Dengan aturan encoding sekarang disematkan ke bit terakhir, satu-satunya hal yang masih harus dilakukan adalah bahwa pemanggil dan callee menyepakati pertukaran aktual pesan. Sebagai contoh, mungkin akan memutuskan untuk menggunakan layanan koneksi transport berorientasi seperti TCP / IP. Sebuah alternatif adalah dengan menggunakan layanan datagram tidak dapat diandalkan dan membiarkan klien dan server menerapkan sheme kesalahan kontrol sebagai bagian dari protokol RPC. Dalam prakteknya, beberapa varian ada. Setelah protokol RPC telah sepenuhnya didefinisikan, Rintisan bertopik klien dan server harus dilaksanakan. Untungnya, bertopik untuk protokol yang sama tetapi prosedur yang berbeda pada umumnya berbeda hanya dalam antarmuka mereka ke aplikasi. Sebuah antarmuka terdiri dari kumpulan prosedur yang dapat dipanggil oleh klien, dan yang dilaksanakan oleh server. interface umumnya tersedia dalam bahasa pemrograman yang sama seperti yang di mana klien atau server yang tertulis (meskipun hal ini benar-benar berbicara, tidak perlu). Untuk menyederhanakan masalah, antarmuka sering ditentukan melalui

suatu bahasa definisi antarmuka. Sebuah antarmuka yang ditentukan dalam seperti IDL, kemudian kemudian disusun menjadi sebuah rintisan klien dan rintisan server, bersama dengan waktu kompilasi yang tepat atau menjalankan antarmuka waktu. Praktek menunjukkan bahwa menggunakan bahasa definisi antarmuka sangat menyederhanakan aplikasi client server berbasis RPC. Karena mudah untuk sepenuhnya menghasilkan bertopik klien dan server, semua sistem RPC middleware berbasis menawarkan IDL untuk mendukung pengembangan aplikasi. Dalam beberapa kasus, menggunakan IDL bahkan wajib, seperti yang akan kita lihat di bab berikutnya.