Memanggil prosedur jarak jauh (rpc - Panggilan Prosedur Jarak Jauh). Prosedur Jarak Jauh: Panggilan Prosedur Jarak Jauh, Definisi dan Fitur Langkah Eksekusi RPC

Kuliah 4

4.1 Konsep Panggilan Prosedur Jarak Jauh

Gagasan untuk memanggil prosedur jarak jauh (Panggilan Prosedur Jarak Jauh - RPC) terdiri dari perluasan mekanisme yang terkenal dan dipahami untuk mentransfer kendali dan data dalam program yang berjalan pada satu mesin hingga mentransfer kendali dan data melalui jaringan. Alat panggilan prosedur jarak jauh dirancang untuk memfasilitasi organisasi komputasi terdistribusi. Efisiensi terbesar penggunaan RPC dicapai dalam aplikasi yang terdapat komunikasi interaktif antara komponen jarak jauh dengan waktu respons yang cepat dan jumlah data yang ditransfer relatif kecil. Aplikasi seperti ini disebut berorientasi RPC.

Ciri-ciri pemanggilan prosedur lokal adalah: asimetris, yaitu salah satu pihak yang berinteraksi adalah pemrakarsa; sinkronisitas, yaitu eksekusi prosedur pemanggilan berhenti sejak permintaan dikeluarkan dan dilanjutkan hanya setelah prosedur pemanggilan kembali.

Menerapkan panggilan jarak jauh jauh lebih rumit daripada menerapkan panggilan prosedur lokal. Pertama-tama, karena pemanggilan dan prosedur yang dipanggil dijalankan pada mesin yang berbeda, keduanya memiliki ruang alamat yang berbeda, dan ini menimbulkan masalah saat meneruskan parameter dan hasil, terutama jika mesin tersebut tidak identik. Karena RPC tidak dapat mengandalkan memori bersama, ini berarti parameter RPC tidak boleh berisi penunjuk ke lokasi memori non-stack dan nilai parameter harus disalin dari satu komputer ke komputer lain. Perbedaan berikutnya antara RPC dan panggilan lokal adalah bahwa ia harus menggunakan sistem komunikasi yang mendasarinya, namun hal ini tidak boleh terlihat secara eksplisit baik dalam definisi prosedur maupun dalam prosedur itu sendiri. Keterpencilan menimbulkan masalah tambahan. Eksekusi program pemanggil dan prosedur lokal yang dipanggil pada mesin yang sama diimplementasikan dalam satu proses. Namun implementasi RPC melibatkan setidaknya dua proses - satu pada setiap mesin. Jika salah satu dari mereka crash, situasi berikut mungkin timbul: jika prosedur pemanggilan crash, prosedur yang dipanggil dari jarak jauh akan menjadi “yatim piatu”, dan jika prosedur jarak jauh crash, prosedur pemanggilan akan menjadi “orang tua yatim piatu”, menunggu dengan sia-sia untuk a respons dari prosedur jarak jauh.

Selain itu, ada sejumlah masalah yang terkait dengan heterogenitas bahasa pemrograman dan lingkungan operasi: struktur data dan struktur panggilan prosedur yang didukung dalam satu bahasa pemrograman tidak didukung dengan cara yang sama di semua bahasa lainnya.

Masalah ini dan beberapa masalah lainnya diselesaikan dengan meluasnya penggunaan teknologi RPC yang mendasari banyak sistem operasi terdistribusi.

Operasi RPC Dasar

Untuk memahami cara kerja RPC, pertama-tama mari kita pertimbangkan untuk membuat panggilan prosedur lokal pada mesin biasa yang berjalan offline. Misalnya, ini adalah panggilan sistem

hitungan=baca(fd,buf,nbyte);

dimana fd adalah bilangan bulat;

buf – susunan karakter;

nbytes adalah bilangan bulat.

Untuk melakukan panggilan, prosedur pemanggilan mendorong parameter ke tumpukan dalam urutan terbalik. Setelah panggilan baca dijalankan, ia menempatkan nilai yang dikembalikan ke dalam register, memindahkan alamat pengirim, dan mengembalikan kontrol ke prosedur pemanggilan, yang mengeluarkan parameter dari tumpukan, mengembalikannya ke keadaan semula. Perhatikan bahwa dalam bahasa C, parameter dapat dipanggil dengan referensi (berdasarkan nama) atau berdasarkan nilai (berdasarkan nilai). Sehubungan dengan prosedur yang dipanggil, parameter nilai diinisialisasi dengan variabel lokal. Prosedur yang dipanggil dapat mengubahnya tanpa mempengaruhi nilai asli variabel-variabel ini dalam prosedur pemanggilan.

Jika pointer ke suatu variabel diteruskan ke prosedur yang dipanggil, maka mengubah nilai variabel ini dengan prosedur yang dipanggil berarti mengubah nilai variabel ini untuk prosedur pemanggilan. Fakta ini sangat penting bagi RPC.

Ada juga mekanisme lain untuk meneruskan parameter yang tidak digunakan di C. Ini disebut call-by-copy/restore, yang mengharuskan pemanggil untuk menyalin variabel ke tumpukan sebagai nilai, dan kemudian menyalinnya kembali setelah panggilan selesai. nilai asli dari prosedur pemanggilan.

Keputusan tentang mekanisme penerusan parameter mana yang akan digunakan dibuat oleh pengembang bahasa. Terkadang hal ini bergantung pada jenis data yang ditransfer. Di C, misalnya, bilangan bulat dan data skalar lainnya selalu diteruskan berdasarkan nilai, dan array selalu diteruskan berdasarkan referensi.

Ide di balik RPC adalah membuat panggilan prosedur jarak jauh terlihat semirip mungkin dengan panggilan prosedur lokal. Dengan kata lain, buatlah RPC transparan: prosedur pemanggilan tidak perlu mengetahui bahwa prosedur yang dipanggil ada di komputer lain, dan sebaliknya.

RPC mencapai transparansi dengan cara berikut. Ketika prosedur yang dipanggil benar-benar jarak jauh, versi lain dari prosedur tersebut, yang disebut stub klien, ditempatkan di perpustakaan, bukan di prosedur lokal. Seperti prosedur aslinya, stub dipanggil menggunakan urutan panggilan, dan interupsi terjadi saat mengakses kernel. Hanya saja, tidak seperti prosedur aslinya, prosedur ini tidak menempatkan parameter dalam register dan tidak meminta data dari kernel; sebaliknya, prosedur ini menghasilkan pesan untuk dikirim ke kernel mesin jarak jauh.

Tahapan Eksekusi RPC

Interaksi komponen perangkat lunak saat melakukan panggilan prosedur jarak jauh diilustrasikan pada Gambar 2.

Gambar 2. Panggilan Prosedur Jarak Jauh

Setelah stub klien dipanggil oleh program klien, tugas pertamanya adalah mengisi buffer dengan pesan yang dikirim. Dalam beberapa sistem, stub klien memiliki buffer tunggal dengan panjang tetap yang diisi sejak awal dengan setiap permintaan baru. Di sistem lain, buffer pesan adalah kumpulan buffer untuk kolom pesan individual, beberapa di antaranya sudah penuh. Metode ini sangat cocok untuk kasus di mana paket memiliki format yang terdiri dari sejumlah besar bidang, namun nilai dari banyak bidang ini tidak berubah dari panggilan ke panggilan.

Parameter kemudian harus dikonversi ke format yang sesuai dan dimasukkan ke dalam buffer pesan. Pada titik ini, pesan siap dikirim, sehingga interupsi panggilan kernel dijalankan.

Ketika kernel memperoleh kendali, ia mengganti konteks, menyimpan register prosesor dan peta memori (pegangan halaman), dan menginstal peta memori baru yang akan digunakan untuk dijalankan dalam mode kernel. Karena konteks kernel dan pengguna berbeda, kernel harus menyalin pesan secara tepat ke dalam ruang alamatnya sendiri sehingga dapat mengaksesnya, mengingat alamat tujuan (dan mungkin kolom header lainnya), dan harus meneruskannya ke antarmuka jaringan. Ini menyelesaikan pekerjaan di sisi klien. Pengatur waktu transmisi dihidupkan, dan kernel dapat melakukan polling secara siklis untuk mendapatkan respons atau meneruskan kontrol ke penjadwal, yang akan memilih beberapa proses lain untuk dijalankan. Dalam kasus pertama, eksekusi query dipercepat, namun multiprogramming tidak ada.

Di sisi server, bit yang masuk ditempatkan oleh perangkat keras penerima baik di buffer on-chip atau di RAM. Ketika semua informasi telah diterima, interupsi dihasilkan. Pengendali interupsi memeriksa kebenaran data paket dan menentukan ke rintisan mana paket tersebut harus dikirim. Jika tidak ada stub yang mengharapkan paket ini, handler harus melakukan buffering atau membuangnya sama sekali. Jika ada stub yang menunggu, pesan akan disalin ke sana. Akhirnya, peralihan konteks dilakukan, sebagai akibatnya register dan peta memori dipulihkan, mengambil nilai yang dimilikinya pada saat stub melakukan panggilan terima.

Gambar 3 menunjukkan urutan perintah yang harus dijalankan untuk setiap panggilan RPC.

Gambar 3. Langkah-langkah prosedur RPC

) Konsep Panggilan Prosedur Jarak Jauh

Ide dari Panggilan Prosedur Jarak Jauh (RPC) adalah untuk memperluas mekanisme yang diketahui dan dipahami untuk mentransfer kendali dan data dalam program yang berjalan pada satu mesin untuk mentransfer kendali dan data melalui jaringan. Alat panggilan prosedur jarak jauh dirancang untuk memfasilitasi organisasi komputasi terdistribusi. Efisiensi terbesar penggunaan RPC dicapai dalam aplikasi di mana terdapat komunikasi interaktif antara komponen jarak jauh dengan waktu respons yang cepat dan jumlah data yang ditransfer relatif kecil. Aplikasi seperti ini disebut berorientasi RPC.

Ciri khas pemanggilan prosedur lokal adalah:

Asimetri, yaitu salah satu pihak yang berinteraksi menjadi pemrakarsa; Sinkronisasi, yaitu eksekusi prosedur pemanggilan berhenti sejak permintaan dikeluarkan dan dilanjutkan hanya setelah prosedur pemanggilan kembali.

Masalah ini dan beberapa masalah lainnya diselesaikan dengan meluasnya penggunaan teknologi RPC yang mendasari banyak sistem operasi terdistribusi.

Operasi RPC Dasar

Untuk memahami cara kerja RPC, pertama-tama mari kita pertimbangkan untuk membuat panggilan prosedur lokal pada mesin biasa yang berjalan offline. Misalnya, ini adalah panggilan sistem

Hitung=baca(fd,buf,nbytes);

dimana fd adalah bilangan bulat,
buf - susunan karakter,
nbytes adalah bilangan bulat.

Untuk melakukan panggilan, prosedur pemanggilan mendorong parameter ke tumpukan dalam urutan terbalik (Gambar 3.1). Setelah panggilan baca dijalankan, ia menempatkan nilai yang dikembalikan ke dalam register, memindahkan alamat pengirim, dan mengembalikan kontrol ke prosedur pemanggilan, yang mengeluarkan parameter dari tumpukan, mengembalikannya ke keadaan semula. Perhatikan bahwa dalam bahasa C, parameter dapat dipanggil dengan referensi (berdasarkan nama) atau berdasarkan nilai (berdasarkan nilai). Sehubungan dengan prosedur yang dipanggil, parameter nilai diinisialisasi dengan variabel lokal. Prosedur yang dipanggil dapat mengubahnya tanpa mempengaruhi nilai asli variabel-variabel ini dalam prosedur pemanggilan.

Beras. 3.1. a) Tumpukan sebelum panggilan baca dijalankan;
b) Tumpukan selama pelaksanaan prosedur;
c) Tumpukan setelah kembali ke program pemanggil

RPC mencapai transparansi dengan cara berikut. Ketika prosedur yang dipanggil benar-benar jarak jauh, versi lain dari prosedur tersebut, yang disebut stub klien, ditempatkan di perpustakaan, bukan di prosedur lokal. Seperti prosedur aslinya, stub dipanggil menggunakan urutan pemanggilan (seperti pada Gambar 3.1), dan interupsi terjadi saat mengakses kernel. Hanya saja, tidak seperti prosedur aslinya, prosedur ini tidak menempatkan parameter dalam register dan tidak meminta data dari kernel; sebaliknya, prosedur ini menghasilkan pesan untuk dikirim ke kernel mesin jarak jauh.

Tahapan Eksekusi RPC

Interaksi komponen perangkat lunak saat melakukan panggilan prosedur jarak jauh diilustrasikan pada Gambar 3.2. Setelah stub klien dipanggil oleh program klien, tugas pertamanya adalah mengisi buffer dengan pesan yang dikirim. Dalam beberapa sistem, stub klien memiliki buffer tunggal dengan panjang tetap yang diisi sejak awal dengan setiap permintaan baru. Di sistem lain, buffer pesan adalah kumpulan buffer untuk kolom pesan individual, beberapa di antaranya sudah penuh. Metode ini sangat cocok untuk kasus di mana paket memiliki format yang terdiri dari sejumlah besar bidang, namun nilai dari banyak bidang ini tidak berubah dari panggilan ke panggilan.

Parameter kemudian harus dikonversi ke format yang sesuai dan dimasukkan ke dalam buffer pesan. Pada titik ini, pesan siap dikirim, sehingga interupsi panggilan kernel dijalankan.

Beras. 3.2. Panggilan Prosedur Jarak Jauh

Gambar 3.3 menunjukkan urutan perintah yang harus dijalankan untuk setiap panggilan RPC, dan Gambar 3.4 menunjukkan berapa proporsi total waktu eksekusi RPC yang dihabiskan untuk masing-masing dari 14 langkah yang dijelaskan. Pengujian dilakukan pada stasiun kerja multi-prosesor DEC Firefly, dan meskipun kehadiran lima prosesor tentu memengaruhi hasil pengukuran, histogram yang ditunjukkan pada gambar memberikan gambaran umum tentang proses eksekusi RPC.

Beras. 3.3. Langkah-langkah untuk melakukan prosedur RPC

Beras. 3.4. Distribusi waktu antara 14 tahap eksekusi RPC

1. Memanggil rintisan

2. Siapkan penyangga

3. Parameter paket

4. Isi kolom judul

5. Hitung checksum dalam pesan

6. Interupsi pada kernel

7. Paket antrian untuk dieksekusi

8. Mengirimkan pesan ke pengontrol melalui bus QBUS

9. Waktu transmisi Ethernet

10. Menerima paket dari pengontrol

11. Prosedur penanganan interupsi

12. Perhitungan checksum

13. Peralihan konteks ke ruang pengguna

14. Melakukan rintisan server

Tautan Dinamis

Mari kita pertimbangkan bagaimana klien menentukan lokasi server. Salah satu metode untuk mengatasi masalah ini adalah dengan langsung menggunakan alamat jaringan server di program klien. Kerugian dari pendekatan ini adalah sangat tidak fleksibel: ketika memindahkan server, atau menambah jumlah server, atau mengubah antarmuka dalam semua kasus ini dan banyak kasus lainnya, semua program yang menggunakan alamat server yang dikodekan secara keras perlu dikompilasi ulang. Untuk menghindari semua masalah ini, beberapa sistem terdistribusi menggunakan apa yang disebut tautan dinamis.

Titik awal untuk pengikatan dinamis adalah definisi formal (spesifikasi) dari server. Spesifikasi tersebut berisi nama file server, nomor versi dan daftar prosedur layanan yang disediakan oleh server ini kepada klien (Gambar 3.5). Untuk setiap prosedur, deskripsi parameternya diberikan, yang menunjukkan apakah parameter ini merupakan input atau output relatif terhadap server. Beberapa parameter dapat berupa input dan output - misalnya, beberapa array yang dikirim oleh klien ke server, dimodifikasi di sana, dan kemudian dikembalikan ke klien (operasi penyalinan/pemulihan).

Beras. 3.5. Spesifikasi Server RPC

Spesifikasi server formal digunakan sebagai masukan ke program generator stub, yang membuat stub klien dan server. Mereka kemudian ditempatkan di perpustakaan yang sesuai. Ketika program pengguna (klien) memanggil prosedur apa pun yang ditentukan dalam spesifikasi server, prosedur rintisan terkait dikaitkan dengan kode biner program. Demikian pula, ketika sebuah server dikompilasi, stub server dikaitkan dengannya.

Saat server dinyalakan, hal pertama yang dilakukannya adalah meneruskan antarmuka servernya ke program khusus yang disebut pengikat. Proses ini, dikenal sebagai proses registrasi server, melibatkan server yang meneruskan nama, nomor versi, pengidentifikasi unik, dan pegangannya. ke lokasi server. Pegangannya tidak bergantung pada sistem dan dapat berupa IP, Ethernet, X.500, atau alamat lainnya, dan mungkin juga berisi informasi lain, seperti informasi terkait autentikasi.

Ketika klien memanggil salah satu prosedur jarak jauh untuk pertama kalinya, misalnya membaca, rintisan klien melihat bahwa ia belum terhubung ke server dan mengirimkan pesan ke program pengikat dengan permintaan untuk mengimpor antarmuka yang diinginkan. versi server yang diinginkan. Jika server seperti itu ada, maka binder meneruskan deskriptor dan pengidentifikasi unik ke stub klien.

Metode mengimpor/mengekspor antarmuka ini sangat fleksibel. Misalnya, mungkin ada beberapa server yang mendukung antarmuka yang sama, dan klien didistribusikan secara acak ke seluruh server. Dalam kerangka metode ini, server dapat disurvei secara berkala, menganalisis kinerjanya dan, jika terjadi kegagalan, dimatikan secara otomatis, yang meningkatkan toleransi kesalahan sistem secara keseluruhan. Metode ini juga dapat mendukung otentikasi klien. Misalnya, server mungkin menentukan bahwa itu hanya dapat digunakan oleh klien dari daftar tertentu.

Namun, pengikatan dinamis memiliki kelemahan, seperti tambahan overhead (waktu) untuk mengekspor dan mengimpor antarmuka. Besarnya biaya ini bisa menjadi signifikan, karena banyak proses klien berlangsung dalam waktu singkat, dan setiap kali proses dimulai, prosedur impor antarmuka harus dilakukan lagi. Selain itu, dalam sistem terdistribusi besar, program pengikat dapat menjadi hambatan, dan membuat beberapa program dengan tujuan serupa juga meningkatkan biaya pembuatan dan sinkronisasi proses.

Semantik RPC jika terjadi kegagalan

Idealnya, RPC harus berfungsi dengan benar meskipun terjadi kegagalan. Pertimbangkan kelas kegagalan berikut:

Klien tidak dapat menemukan server, misalnya, jika server yang diinginkan gagal, atau karena program klien telah dikompilasi sejak lama dan menggunakan antarmuka server versi lama. Dalam hal ini, sebagai tanggapan atas permintaan klien, pesan yang berisi kode kesalahan diterima. Permintaan dari klien ke server hilang. Solusi paling sederhana adalah mengulangi permintaan tersebut setelah waktu tertentu. Pesan respons dari server ke klien hilang. Pilihan ini lebih rumit dari yang sebelumnya, karena beberapa prosedur tidak idempoten. Prosedur idempoten adalah prosedur yang permintaan eksekusinya dapat diulang beberapa kali tanpa mengubah hasilnya. Contoh dari prosedur tersebut adalah membaca file. Namun prosedur penarikan sejumlah tertentu dari rekening bank bukanlah idempoten, dan jika responsnya hilang, permintaan berulang dapat mengubah status rekening klien secara signifikan. Salah satu solusi yang mungkin adalah membuat semua prosedur menjadi idempoten. Namun, dalam praktiknya hal ini tidak selalu memungkinkan, sehingga metode lain dapat digunakan - penomoran berurutan semua permintaan oleh kernel klien. Inti server mengingat nomor permintaan terbaru dari setiap klien, dan setelah menerima setiap permintaan, inti server menganalisis apakah permintaan ini merupakan permintaan utama atau permintaan berulang. Server mogok setelah menerima permintaan. Sifat idempotensi juga penting di sini, namun sayangnya pendekatan dengan penomoran kueri tidak dapat diterapkan. Dalam hal ini, itu penting

Java RMI sebagai jenis panggilan prosedur jarak jauh, tidak bergantung pada jaringan, langkah-langkah utama bekerja dengannya dan tujuannya. Perbandingan program Java terdistribusi dan tidak terdistribusi. Arsitektur, rintisan dan kerangka, referensi jarak jauh dan lapisan transport Java RMI.

Pra-kompilasi kueri SQL di situs eksekusi. Menggunakan pernyataan prepStatement. Gunakan sintaks definisi panggilan untuk mendapatkan nilai kembalian dari suatu prosedur atau fungsi. Membuat instruksi untuk pengambilan sampel berdasarkan permintaan.

Tujuan dan skema kerja. Komposisi dan instalasi. spesifikasi prosedur paket http.

Prosedur dan fungsi dapat didefinisikan sebagai unit program tertutup yang mengimplementasikan algoritma tertentu. Faktanya, suatu prosedur atau fungsi hampir merupakan sebuah program.

Konfigurasi TCP/IP otomatis, konfigurasi dinamis menggunakan BOOTP. Alamat IP permintaan/respons, kehilangan dan format pesan, fase BOOTP. Protokol DHCP merupakan perpanjangan dari protokol BOOTP. Distribusi dan penetapan alamat IP.

Kita telah menjumpai konsep rekursi: relasi perulangan cukup sering ditemukan dalam ekspresi matematika. Rekursi dalam definisi terdiri dari fakta bahwa konsep yang didefinisikan didefinisikan melalui konsep itu sendiri.

1. Pendahuluan 2 2. Sekilas tentang teknologi COM 2 2.1. Komposisi objek COM 3 2.2. Antarmuka 4 2.3. Properti objek COM 6 2.4. Server COM 6 2.5. Mekanisme Marshalling 7

Studi tentang esensi, prinsip operasi dan tujuan utama database jarak jauh. Model manajemen data jarak jauh (model server file). Jenis paralelisme. Pemicu adalah mekanisme untuk melacak peristiwa khusus yang terkait dengan status database.

Paket metamodel, fakta dan keamanan. Model konseptual klien. Contoh fungsi arsitektur terdistribusi. Kompleksitas implementasi.

Konsep dll. Mari kita ingat proses pemrograman di DOS. Mengubah teks sumber menjadi kode mesin melibatkan dua proses: kompilasi dan penautan. Selama penautan, tidak hanya deklarasi fungsi dan prosedur, tetapi juga kode lengkapnya ditempatkan dalam kode program.

Berfungsi untuk bekerja dengan protokol TCP/IP, Socket, Bind, mendengarkan dan menerima. Deskriptor file. Proses komunikasi. Menerima data. Membaca dari soket. Menulis ke soket. Menutup soket. Teks program yang membuat server Web di sistem operasi QNX.

Akses pengguna jaringan ke pesan elektronik yang disimpan di server. Deskripsi program, otentikasi sederhana, otentikasi APOP dan AUTH. Implementasi fungsi, panduan pengguna, algoritma pengoperasian program, antarmuka grafis.

Prinsip pengoperasian operator utama bahasa pemrograman Turbo-Paskal: operator penugasan, pemilihan kasus, lompatan tanpa syarat, loop, tangkapan, gabungan. Deskripsi formal dan pemanggilan suatu fungsi dan prosedur. Persyaratan untuk daftar parameter aktual.

Prinsip operasi dan tujuan servlet Java, pentingnya dalam meningkatkan fungsionalitas server Web dan meningkatkan pemrogramannya, kelebihan dan kekurangan penggunaannya. Cara memanggil servlet dari browser dan halaman. Menulis dan membaca atribut sesi.

Arsitektur OS Windows NT. Struktur OS berdasarkan mikrokernel. Subsistem yang dilindungi dari Windows NT.

Pesan dasar melewati primitif dalam sistem terdistribusi. Mengatasi metode. Primitif pemblokiran dan non-pemblokiran. Primitif dengan buffer dan non-buffer.

Server aplikasi. Bagian klien.

Dua tahun lalu, AJAX adalah hal baru (dan kata AJAX sendiri belum ditemukan). Sekarang aplikasi web yang halamannya diperbarui dengan cepat adalah hal yang paling penting. Sebaliknya: sulit membayangkan beberapa layanan tanpa AJAX.

Sintaks untuk mendeskripsikan dan memanggil suatu prosedur. Pilihan. Contoh deskripsi prosedur dan panggilan. Jenis parameter. Program.

Mekanisme yang sangat penting untuk aplikasi client-server disediakan oleh RPC ( Panggilan Prosedur Jarak Jauh). RPC dikembangkan oleh Sun Micrsystems dan merupakan kumpulan alat dan fungsi perpustakaan. Secara khusus, NIS (Network Information System) dan NFS (Network File System) bekerja pada RPC.

Server RPC terdiri dari sistem prosedur yang dapat diakses klien dengan mengirimkan permintaan RPC ke server bersama dengan parameter prosedur. Server akan memanggil prosedur yang ditunjuk dan mengembalikan nilai pengembalian prosedur, jika ada. Agar tidak bergantung pada mesin, semua data yang dipertukarkan antara klien dan server diubah menjadi apa yang disebut representasi data eksternal ( Representasi Data Eksternal, XDR). RPC berkomunikasi dengan soket UDP dan TCP untuk mentransfer data dalam format XDR. Sun telah mendeklarasikan RPC sebagai domain publik, dan deskripsinya tersedia dalam serangkaian dokumen RFC.

Terkadang perubahan dalam aplikasi RPC menyebabkan ketidakcocokan pada prosedur panggilan antarmuka. Tentu saja, perubahan sederhana akan menyebabkan server crash pada aplikasi apa pun yang masih menunggu panggilan yang sama. Oleh karena itu, program RPC memiliki nomor versi yang ditetapkan padanya, biasanya dimulai dengan 1. Setiap versi baru RPC melacak nomor versinya. Seringkali server menawarkan beberapa versi secara bersamaan. Klien dalam hal ini menentukan nomor versi yang ingin mereka gunakan.

Komunikasi jaringan antara server RPC dan klien sedikit istimewa. Server RPC menawarkan satu atau lebih prosedur sistem, setiap rangkaian prosedur tersebut disebut program ( program) dan diidentifikasi secara unik dengan nomor program ( nomor program). Daftar nama layanan biasanya disimpan di /etc/rpc, contohnya diberikan di bawah ini.

Contoh 12-4. Contoh file /etc/rpc

# # /etc/rpc - berbagai layanan berbasis RPC # portmapper 100000 portmap sunrpc rstatd 100001 rstat rstat_svc rup perfmeter rusersd 100002 rusers nfs 100003 nfsprog ypserv 100004 ypprog mountd 100005 mount showmount ypbind 10 0007 walld 100008 rwall shutdown yppasswdd 100009 yppasswd bootparam 100026 ypupdated 100028 yaperbarui

Dalam jaringan TCP/IP, penulis RPC dihadapkan pada tugas memetakan nomor program ke layanan jaringan umum. Setiap server menyediakan port TCP dan UDP untuk setiap program dan setiap versi. Secara umum, aplikasi RPC menggunakan UDP untuk mengirimkan data dan melakukan fallback ke TCP ketika data yang akan dikirim tidak sesuai dengan satu datagram UDP.

Tentu saja, program klien harus memiliki cara untuk mengetahui port mana yang sesuai dengan nomor program. Menggunakan file konfigurasi untuk ini akan terlalu tidak fleksibel; Karena aplikasi RPC tidak menggunakan port yang dicadangkan, tidak ada jaminan bahwa port tersebut tidak ditempati oleh beberapa aplikasi dan tersedia untuk kami. Oleh karena itu, aplikasi RPC memilih port mana pun yang dapat mereka terima dan mendaftarkannya daemon portmapper. Seorang klien yang ingin menghubungi layanan dengan nomor program tertentu akan terlebih dahulu membuat permintaan ke portmapper untuk mengetahui nomor port layanan yang diinginkan.

Metode ini memiliki kelemahan yaitu hanya menimbulkan satu titik kegagalan inetd daemon Namun, kasus ini sedikit lebih buruk karena ketika portmapper gagal, semua informasi RPC tentang port tersebut hilang. Ini biasanya berarti Anda harus me-restart semua server RPC secara manual atau me-reboot mesin.

Di Linux, portmapper disebut /sbin/portmap atau /usr/sbin/rpc.portmap . Terlepas dari kenyataan bahwa itu harus diluncurkan dari skrip startup jaringan, portmapper tidak memerlukan pekerjaan konfigurasi apa pun.

Panggilan Prosedur Jarak Jauh RPC Konsep Panggilan Prosedur Jarak Jauh Ide di balik Panggilan Prosedur Jarak Jauh (RPC) adalah untuk memperluas mekanisme yang terkenal dan dipahami untuk mentransfer kendali dan data dalam program yang berjalan pada satu mesin untuk mentransfer kendali dan data melalui jaringan. Alat panggilan prosedur jarak jauh dirancang untuk memfasilitasi pengorganisasian komputasi terdistribusi.Efisiensi terbesar penggunaan RPC dicapai dalam aplikasi di mana terdapat komunikasi interaktif antara komponen jarak jauh dengan waktu respons yang singkat dan jumlah data yang ditransfer relatif kecil.

Aplikasi seperti ini disebut berorientasi RPC. Ciri khas pemanggilan prosedur lokal adalah Asimetri, yaitu salah satu pihak yang berinteraksi adalah pemrakarsa Synchronicity, yaitu pelaksanaan prosedur pemanggilan berhenti sejak permintaan dikeluarkan dan dilanjutkan hanya setelah kembali dari prosedur yang dipanggil. Implementasi panggilan jarak jauh jauh lebih rumit dibandingkan implementasi panggilan ke prosedur lokal.

Pertama-tama, karena pemanggilan dan prosedur yang dipanggil dijalankan pada mesin yang berbeda, keduanya memiliki ruang alamat yang berbeda, dan ini menimbulkan masalah saat meneruskan parameter dan hasil, terutama jika mesin tersebut tidak identik. Karena RPC tidak dapat mengandalkan memori bersama, ini berarti bahwa parameter RPC tidak boleh berisi penunjuk ke lokasi memori non-stack dan nilai parameter harus disalin dari satu komputer ke komputer lain.

Perbedaan berikutnya antara RPC dan panggilan lokal adalah bahwa ia harus menggunakan sistem komunikasi yang mendasarinya, namun hal ini tidak boleh terlihat secara eksplisit baik dalam definisi prosedur maupun dalam prosedur itu sendiri. Keterpencilan menimbulkan masalah tambahan. Eksekusi program pemanggil dan prosedur lokal yang dipanggil pada mesin yang sama diimplementasikan dalam satu proses. Namun implementasi RPC melibatkan setidaknya dua proses - satu di setiap mesin.

Jika salah satu dari mereka crash, situasi berikut mungkin timbul: jika prosedur pemanggilan crash, prosedur yang dipanggil dari jarak jauh akan menjadi yatim piatu, dan jika prosedur jarak jauh crash, prosedur pemanggilan akan menjadi orang tua yatim piatu, yang akan menunggu dengan sia-sia untuk mendapat tanggapan. dari prosedur jarak jauh. Selain itu, ada sejumlah masalah yang terkait dengan heterogenitas bahasa pemrograman dan lingkungan operasi, struktur data dan struktur panggilan prosedur yang didukung dalam satu bahasa pemrograman tidak didukung dengan cara yang sama di semua bahasa lainnya. bahasa.

Masalah ini dan beberapa masalah lainnya diselesaikan dengan meluasnya penggunaan teknologi RPC yang mendasari banyak sistem operasi terdistribusi. Operasi RPC Dasar Untuk memahami cara kerja RPC, pertama-tama mari kita pertimbangkan untuk membuat panggilan prosedur lokal pada mesin biasa yang berjalan secara otonom. Misalkan, jumlah panggilan sistem dibaca fd,buf,nbytes di mana fd adalah bilangan bulat, buf adalah array karakter, nbytes adalah bilangan bulat.

Untuk melakukan panggilan, prosedur pemanggilan mendorong parameter ke tumpukan dalam urutan terbalik dari Gambar 3.1. Setelah panggilan baca dijalankan, ia menempatkan nilai yang dikembalikan ke dalam register, memindahkan alamat pengirim, dan mengembalikan kontrol ke prosedur pemanggilan, yang mengeluarkan parameter dari tumpukan, mengembalikannya ke keadaan semula.Perhatikan bahwa dalam C, parameter dapat dipanggil dengan referensi atau dengan nama, atau dengan nilai. Sehubungan dengan prosedur yang dipanggil, parameter nilai diinisialisasi dengan variabel lokal.

Prosedur yang dipanggil dapat mengubahnya tanpa mempengaruhi nilai asli variabel-variabel ini dalam prosedur pemanggilan. Jika pointer ke suatu variabel diteruskan ke prosedur yang dipanggil, maka mengubah nilai variabel ini dengan prosedur yang dipanggil berarti mengubah nilai variabel ini untuk prosedur pemanggilan.Fakta ini sangat penting bagi RPC. Ada juga mekanisme lain untuk meneruskan parameter yang tidak digunakan dalam C. Ini disebut pemulihan panggilan-demi-salinan dan melibatkan program pemanggil yang menyalin variabel ke tumpukan sebagai nilai, dan kemudian menyalinnya kembali setelah panggilan dilakukan pada yang asli. nilai-nilai prosedur pemanggilan.

Keputusan tentang mekanisme penerusan parameter mana yang akan digunakan dibuat oleh pengembang bahasa. Kadang-kadang hal ini bergantung pada tipe data yang diteruskan. Di C, misalnya, bilangan bulat dan data skalar lainnya selalu diteruskan berdasarkan nilai, dan array selalu diteruskan berdasarkan referensi.

Beras. 3.1. a Tumpukan sebelum panggilan baca dieksekusi b Tumpukan selama eksekusi prosedur c Tumpukan setelah kembali ke program pemanggil Ide di balik RPC adalah membuat panggilan ke prosedur jarak jauh terlihat semirip mungkin dengan panggilan ke a prosedur lokal. Dengan kata lain, untuk membuat RPC transparan, prosedur pemanggilan tidak perlu mengetahui bahwa prosedur yang dipanggil ada di komputer lain, dan sebaliknya.RPC mencapai transparansi dengan cara berikut.

Ketika prosedur yang dipanggil benar-benar jarak jauh, alih-alih prosedur lokal, versi lain dari prosedur tersebut, yang disebut stub klien, ditempatkan di perpustakaan. Mirip dengan prosedur aslinya, stub dipanggil menggunakan urutan pemanggilan seperti pada Gambar 3.1, dan interupsi terjadi saat mengakses kernel. Hanya saja, tidak seperti prosedur aslinya, prosedur ini tidak menempatkan parameter dalam register dan tidak meminta data dari kernel; sebaliknya, prosedur ini menghasilkan pesan untuk dikirim ke kernel mesin jarak jauh. Tahapan Eksekusi RPCInteraksi komponen perangkat lunak saat melakukan panggilan prosedur jarak jauh diilustrasikan pada Gambar 3.2. Setelah stub klien dipanggil oleh program klien, tugas pertamanya adalah mengisi buffer dengan pesan yang dikirim.

Dalam beberapa sistem, stub klien memiliki buffer tunggal dengan panjang tetap yang diisi sejak awal dengan setiap permintaan baru. Di sistem lain, buffer pesan adalah kumpulan buffer untuk kolom pesan individual, beberapa di antaranya sudah penuh.

Metode ini sangat cocok untuk kasus di mana paket memiliki format yang terdiri dari sejumlah besar bidang, namun nilai dari banyak bidang ini tidak berubah dari panggilan ke panggilan. Parameter kemudian harus diubah ke format yang sesuai dan dimasukkan ke dalam buffer pesan.Pada titik ini, pesan siap dikirim, sehingga interupsi panggilan kernel dijalankan. Beras. 3.2. Panggilan Prosedur Jarak Jauh Ketika kernel memperoleh kendali, kernel mengganti konteks, menyimpan register prosesor dan pegangan halaman peta memori, dan menginstal peta memori baru yang akan digunakan untuk dijalankan dalam mode kernel. Karena konteks kernel dan pengguna berbeda, kernel harus menyalin pesan secara tepat ke dalam ruang alamatnya sendiri sehingga dapat mengaksesnya, mengingat alamat tujuan dan mungkin kolom header lainnya, dan harus meneruskannya ke antarmuka jaringan.

Ini menyelesaikan pekerjaan di sisi klien.

Pengatur waktu transmisi dihidupkan, dan kernel dapat melakukan polling secara siklis untuk mendapatkan respons atau meneruskan kontrol ke penjadwal, yang akan memilih beberapa proses lain untuk dijalankan. Dalam kasus pertama, eksekusi query dipercepat, namun multiprogramming tidak ada. Di sisi server, bit yang masuk ditempatkan oleh perangkat keras penerima baik di buffer internal atau di RAM. Ketika semua informasi telah diterima, interupsi dihasilkan.

Penangan interupsi memeriksa validitas data paket dan menentukan stub mana yang akan meneruskannya. Jika tidak ada stub yang mengharapkan paket, penangan interupsi harus melakukan buffer atau membuangnya sama sekali. Jika ada stub yang menunggu, pesan akan disalin ke sana. Akhirnya, peralihan konteks dilakukan, sebagai akibatnya register dan peta memori dipulihkan, mengambil nilai yang dimilikinya pada saat stub melakukan panggilan terima.

Sekarang rintisan server mulai bekerja. Ini membongkar parameter dan mendorongnya dengan tepat ke dalam tumpukan. Ketika semuanya sudah siap, panggilan ke server dilakukan. Setelah menyelesaikan prosedur, server mengirimkan hasilnya ke klien. Untuk melakukan ini, semua langkah yang dijelaskan di atas dilakukan, hanya dalam urutan terbalik. Gambar 3.3 menunjukkan urutan perintah yang harus dijalankan untuk setiap panggilan RPC, dan Gambar 3.4 menunjukkan berapa proporsi total waktu eksekusi RPC yang dihabiskan untuk masing-masing dari 14 langkah yang dijelaskan.

Pengujian dilakukan pada stasiun kerja multi-prosesor DEC Firefly, dan meskipun kehadiran lima prosesor tentu memengaruhi hasil pengukuran, histogram yang ditunjukkan pada gambar memberikan gambaran umum tentang proses eksekusi RPC. Beras. 3.3. Tahapan prosedur RPC Gambar. 3.4. Distribusi waktu antara 14 tahapan eksekusi RPC 1. Panggil stub 2. Siapkan buffer 3. Parameter paket 4. Isi kolom header 5. Hitung checksum dalam pesan 6. Interupsi ke kernel 7. Antrian paket untuk dieksekusi 8. Mentransfer pesan ke pengontrol melalui bus QBUS 9. Waktu transfer melalui jaringan Ethernet 10. Menerima paket dari pengontrol 11. Prosedur penanganan interupsi 12. Perhitungan checksum 13. Peralihan konteks ke ruang pengguna 14. Melakukan stub server Pengikatan dinamis Mari kita pertimbangkan pertanyaan tentang bagaimana klien menentukan lokasi server.

Salah satu metode untuk mengatasi masalah ini adalah dengan langsung menggunakan alamat jaringan server di program klien.

Kerugian dari pendekatan ini adalah sangat tidak fleksibel ketika memindahkan server, atau menambah jumlah server, atau mengubah antarmuka; dalam semua kasus ini dan banyak kasus lainnya, semua program perlu dikompilasi ulang yang menggunakan pengaturan keras server. alamat Untuk menghindari semua masalah ini, di Beberapa sistem terdistribusi menggunakan apa yang disebut tautan dinamis.

Titik awal untuk pengikatan dinamis adalah mendefinisikan spesifikasi server secara formal. Spesifikasi tersebut berisi nama file server, nomor versi dan daftar prosedur layanan yang disediakan oleh server ini kepada klien (Gambar 3.5). Untuk setiap prosedur, deskripsi parameternya diberikan, yang menunjukkan apakah parameter ini merupakan input atau output relatif terhadap server. Beberapa parameter dapat berupa input dan output - misalnya, beberapa array yang dikirim oleh klien ke server diubah sana, dan kemudian kembali ke operasi klien menyalin memulihkan. Beras. 3.5. Spesifikasi Server RPC Spesifikasi server formal digunakan sebagai input ke program generator stub, yang membuat stub klien dan server.

Mereka kemudian ditempatkan di perpustakaan yang sesuai. Ketika program klien pengguna memanggil prosedur apa pun yang ditentukan dalam spesifikasi server, prosedur rintisan yang sesuai dikaitkan dengan kode biner program.

Demikian pula, ketika sebuah server dikompilasi, stub server dikaitkan dengannya. Ketika server dimulai, tindakan pertama adalah mentransfer antarmuka servernya ke program khusus yang disebut binder. Proses ini, yang dikenal sebagai proses registrasi server, melibatkan server yang mengirimkan nama, nomor versi, pengidentifikasi unik, dan deskripsi lokasi server. Deskriptor tersebut tidak bergantung pada sistem dan dapat berupa IP, Ethernet, X.500, atau semacamnya. alamat lainnya.

Selain itu, mungkin berisi informasi lain, misalnya terkait otentikasi. Ketika klien memanggil salah satu prosedur jarak jauh untuk pertama kalinya, misalnya membaca, stub klien melihat bahwa ia belum terhubung ke server, dan mengirimkan pesan ke program pengikat dengan permintaan untuk mengimpor antarmuka dari prosedur tersebut. versi yang diinginkan dari server yang diinginkan. Jika server tersebut ada, maka pengikat mengirimkan deskriptor dan pengidentifikasi unik untuk rintisan klien.

Saat mengirim pesan dengan permintaan, stub klien menggunakan deskriptor sebagai alamat. Pesan tersebut berisi parameter dan pengidentifikasi unik yang digunakan inti server untuk merutekan pesan masuk ke server yang diinginkan jika ada beberapa pesan di mesin ini. Metode mengimpor dan mengekspor antarmuka ini sangat fleksibel, misalnya mungkin ada beberapa server yang mendukung antarmuka yang sama, dan klien didistribusikan secara acak di antara server.

Dalam kerangka metode ini, server dapat disurvei secara berkala, menganalisis kinerjanya dan, jika terjadi kegagalan, dimatikan secara otomatis, yang meningkatkan toleransi kesalahan sistem secara keseluruhan. Metode ini juga dapat mendukung otentikasi klien. Misalnya, server mungkin menentukan bahwa itu hanya dapat digunakan oleh klien dari daftar tertentu. Namun, pengikatan dinamis memiliki kelemahan, seperti overhead tambahan dan waktu yang dihabiskan untuk mengekspor dan mengimpor antarmuka.

Besarnya biaya ini bisa menjadi signifikan, karena banyak proses klien berlangsung dalam waktu singkat, dan setiap kali proses dimulai, prosedur impor antarmuka harus dilakukan lagi. Selain itu, dalam sistem terdistribusi besar, program pengikat dapat menjadi hambatan, dan membuat beberapa program dengan tujuan yang sama juga meningkatkan biaya pembuatan dan sinkronisasi proses.Semantik RPC jika terjadi kegagalan Idealnya, RPC harus berfungsi dengan benar jika terjadi kegagalan. kegagalan.

Pertimbangkan kelas kegagalan berikut: 1. Klien tidak dapat menemukan server, misalnya, jika server yang diinginkan gagal, atau karena program klien telah dikompilasi sejak lama dan menggunakan antarmuka server versi lama. Dalam hal ini, sebagai tanggapan atas permintaan klien, pesan yang berisi kode kesalahan diterima. 2. Permintaan dari klien ke server hilang. Solusi paling sederhana adalah mengulangi permintaan setelah waktu tertentu. 3. Pesan respon dari server ke klien hilang.

Pilihan ini lebih rumit dari yang sebelumnya, karena beberapa prosedur tidak idempoten. Prosedur idempoten adalah prosedur yang permintaan eksekusinya dapat diulang beberapa kali tanpa mengubah hasilnya. Contoh dari prosedur tersebut adalah membaca file. Namun prosedur untuk menarik sejumlah tertentu dari rekening bank tidak idempoten, dan jika responsnya hilang, permintaan berulang dapat mengubah keadaan rekening klien secara signifikan.

Salah satu solusi yang mungkin adalah membuat semua prosedur menjadi idempoten. Namun, dalam praktiknya hal ini tidak selalu memungkinkan, sehingga metode lain dapat digunakan - penomoran berurutan semua permintaan oleh kernel klien. Inti server mengingat nomor permintaan terbaru dari setiap klien, dan setelah menerima setiap permintaan, inti server menganalisis apakah permintaan ini merupakan permintaan utama atau permintaan berulang. 4. Server crash setelah menerima permintaan Properti idempotensi juga penting di sini, tapi sayangnya pendekatan dengan penomoran permintaan tidak dapat diterapkan.

Dalam hal ini, penting kapan kegagalan terjadi - sebelum atau sesudah operasi. Namun kernel klien tidak dapat mengenali situasi ini; ia hanya mengetahui bahwa waktu respons telah habis. Ada tiga pendekatan untuk masalah ini: Tunggu sampai server reboot dan coba operasi lagi Pendekatan ini memastikan bahwa RPC selesai setidaknya sekali, dan mungkin lebih. Segera laporkan kesalahan tersebut ke aplikasi.

Pendekatan ini memastikan bahwa RPC dijalankan paling banyak satu kali. Pendekatan ketiga tidak menjamin apa pun. Ketika server gagal, tidak ada dukungan yang diberikan kepada klien. RPC mungkin tidak dijalankan sama sekali, atau mungkin dijalankan berkali-kali. Bagaimanapun, metode ini sangat mudah diterapkan. Tak satu pun dari pendekatan ini yang menarik. Dan opsi ideal, yang menjamin satu eksekusi RPC, pada umumnya tidak dapat diterapkan karena alasan prinsip.

Misalnya, operasi jarak jauh mencetak beberapa teks, termasuk memuat buffer printer dan mengatur satu bit di beberapa register kontrol printer, sebagai akibatnya printer mulai. Crash server dapat terjadi baik mikrodetik sebelumnya atau mikrodetik setelah bit kontrol disetel. Momen kegagalan sepenuhnya menentukan prosedur pemulihan, tetapi klien tidak dapat mengetahui momen kegagalan.

Singkatnya, kemungkinan server crash secara radikal mengubah sifat RPC dan jelas mencerminkan perbedaan antara sistem terpusat dan terdistribusi. Dalam kasus pertama, kegagalan server menyebabkan kegagalan klien, dan pemulihan tidak mungkin dilakukan. Dalam kasus kedua, tindakan pemulihan sistem dapat dilakukan dan diperlukan. 1. Klien mogok setelah mengirim permintaan. Dalam hal ini perhitungan dilakukan berdasarkan hasil yang tidak diharapkan oleh siapa pun, perhitungan seperti itu disebut perhitungan yatim piatu. Kehadiran anak yatim dapat menyebabkan berbagai masalah: overhead waktu CPU, pemblokiran sumber daya, substitusi jawaban permintaan saat ini dengan jawaban permintaan yang dikeluarkan oleh mesin klien sebelum sistem di-restart.

Bagaimana cara menghadapi anak yatim piatu? Mari kita lihat 4 kemungkinan solusi. Penghancuran. Sebelum stub klien mengirimkan pesan RPC, ia membuat catatan di log yang menunjukkan apa yang akan dilakukan selanjutnya. Log disimpan di disk atau memori yang memiliki toleransi terhadap kesalahan lainnya.

Setelah kecelakaan, sistem di-boot ulang, log dianalisis dan anak yatim piatu dihilangkan. Kerugian dari pendekatan ini termasuk, pertama, peningkatan overhead yang terkait dengan penulisan setiap RPC ke disk, dan, kedua, kemungkinan inefisiensi karena munculnya anak yatim piatu generasi kedua yang dihasilkan oleh panggilan RPC yang dikeluarkan oleh anak yatim piatu generasi pertama. Reinkarnasi... Dalam hal ini, semua masalah diselesaikan tanpa menggunakan perekaman disk. Metodenya terdiri dari membagi waktu menjadi periode-periode yang diberi nomor urut. Saat klien di-boot ulang, klien menyiarkan pesan ke semua mesin untuk mengumumkan dimulainya periode baru.

Setelah menerima pesan ini, semua perhitungan jarak jauh dihilangkan. Tentu saja, jika jaringannya tersegmentasi, beberapa anak yatim piatu mungkin bisa bertahan. Reinkarnasi lunak mirip dengan kasus sebelumnya, hanya saja tidak semua kalkulasi yang dihapus ditemukan dan dimusnahkan, tetapi hanya kalkulasi dari klien yang melakukan boot ulang. Kedaluwarsa Setiap permintaan diberikan periode waktu standar T yang harus diselesaikan.

Jika permintaan tidak diselesaikan dalam waktu yang ditentukan, maka kuantum tambahan dialokasikan. Meskipun hal ini membutuhkan kerja tambahan, jika setelah klien crash server menunggu interval T sebelum me-reboot klien, maka semua anak yatim piatu akan dimusnahkan. Dalam praktiknya, tidak satu pun dari pendekatan ini yang diinginkan; pada kenyataannya, menghancurkan anak yatim piatu dapat memperburuk situasi . Misalnya, seorang anak yatim piatu telah mengunci satu atau lebih file database.

Jika anak yatim piatu tiba-tiba dimusnahkan, maka kunci-kunci ini akan tetap ada, selain itu anak yatim piatu yang dimusnahkan mungkin tetap berdiri di berbagai antrian sistem, di kemudian hari dapat menyebabkan pelaksanaan proses baru, dll.

Apa yang akan kami lakukan dengan materi yang diterima:

Jika materi ini bermanfaat bagi Anda, Anda dapat menyimpannya ke halaman Anda di jejaring sosial:

Efisiensi terbesar dalam penggunaan RPC dicapai dalam aplikasi yang ada komunikasi interaktif antar komponen jarak jauh Dengan waktu respons yang singkat Dan jumlah data yang dikirimkan relatif kecil.Aplikasi seperti ini disebut berorientasi RPC.

Ciri khas pemanggilan prosedur lokal adalah:

asimetri, yaitu salah satu pihak yang berinteraksi adalah pemrakarsa;

Sinkronisasi, yaitu, pelaksanaan prosedur pemanggilan dihentikan sejak permintaan dikeluarkan dan dilanjutkan hanya ketika prosedur yang dipanggil kembali.

Menerapkan panggilan jarak jauh jauh lebih rumit daripada menerapkan panggilan prosedur lokal.

1. Mari kita mulai dengan fakta bahwa karena pemanggilan dan prosedur yang dipanggil dijalankan pada mesin yang berbeda, maka keduanya mempunyai ruang alamat yang berbeda, dan ini menciptakan masalah saat mentransfer parameter dan hasil, terutama jika mesinnya tidak identik.

Karena RPC tidak dapat mengandalkan memori bersama, artinya demikian Parameter RPC tidak boleh berisi pointer ke lokasi memori non-stack Terus nilai parameter harus disalin dari satu komputer ke komputer lain.

2. Perbedaan berikutnya antara RPC dan panggilan lokal adalah tentu menggunakan sistem komunikasi yang mendasarinya, namun ini tidak boleh terlihat jelas baik dalam definisi prosedur maupun dalam prosedur itu sendiri .

Keterpencilan menimbulkan masalah tambahan. Menjalankan program pemanggil dan prosedur lokal yang dipanggil pada mesin yang sama diimplementasikan di dalamlajang proses. Tetapi terlibat dalam implementasi RPCsetidaknya dua proses - satu di setiap mobil. Jika salah satunya gagal, situasi berikut mungkin terjadi:

Jika prosedur pemanggilan gagal, prosedur yang dipanggil dari jarak jauh akan menjadi "yatim piatu" dan

Jika prosedur jarak jauh berakhir secara tidak normal, prosedur panggilan akan menjadi "orang tua yang miskin" dan menunggu respons dari prosedur jarak jauh tanpa hasil.

Selain itu, ada sejumlah masalah terkait dengan heterogenitas bahasa pemrograman dan lingkungan operasi : Struktur data dan struktur panggilan prosedur yang didukung dalam satu bahasa pemrograman tidak didukung dengan cara yang sama di semua bahasa lainnya.

Masalah ini dan beberapa masalah lainnya diselesaikan dengan meluasnya penggunaan teknologi RPC yang mendasari banyak sistem operasi terdistribusi.

Ide di balik RPC adalah membuat panggilan prosedur jarak jauh terlihat semirip mungkin dengan panggilan prosedur lokal. Dengan kata lain, buatlah RPC transparan: prosedur pemanggilan tidak perlu mengetahui bahwa prosedur yang dipanggil ada di komputer lain, dan sebaliknya.

RPC mencapai transparansi dengan cara berikut. Ketika prosedur yang dipanggil benar-benar jarak jauh, versi lain dari prosedur tersebut, yang disebut stub klien, ditempatkan di perpustakaan, bukan di prosedur lokal. Seperti prosedur aslinya, stub dipanggil menggunakan urutan pemanggilan (seperti pada Gambar 3.1), dan interupsi terjadi saat mengakses kernel. Hanya saja, tidak seperti prosedur aslinya, prosedur ini tidak menempatkan parameter dalam register dan tidak meminta data dari kernel; sebaliknya, prosedur ini menghasilkan pesan untuk dikirim ke kernel mesin jarak jauh..

Beras. 3.2. Panggilan Prosedur Jarak Jauh

Apa yang harus dilakukan jika ponsel Anda jatuh ke air?

Cara meningkatkan kinerja komputer di Windows 10

Mengapa komputer Anda melambat dan apa yang harus dilakukan?

Apakah mouse Anda berhenti bekerja?