TUGAS Mata Kuliah : Sistem Terdistribusi
OLEH :
Nama NIM Kelas Dosen Prodgi
: TARSO : 090103193 : C (Week End) : Ardy Mulya Iswardani, S.Kom : S1 –Teknik Informatika
SEKOLAH TINGGI MANAJEMEN INFORMATIKA DAN KOMPUTER
DUTA BANGSA SURAKARTA 2011
PROSEDUR PANGGILAN REMOTE
Salah satu bentuk yang paling biasa dari pelayanan remote adalah paradigma RPC. RPC dirancang sebagai sebuah cara untuk memisahkan mekanisme prosedur panggilan dalam penggunaan antar system koneksi jaringan. Hal ini sama dalam beberapa mekanisme IPC dan ini bisaanya dibangun diatas seperti sebuah system. Disini karena kita berhadapan dengan sebuah lingkungan dimana atau yang mana proses-prosesnya terlaksana dalam system yang terpasang, kita harus menggunakan sebuah skema komunikasi berbasis pesan untuk menyediakan layanan remote. Sebaliknya dengan fasilitas IPC, pesanpesannya dalam komunikasi RPC yang disusun dengan baik dan oleh karena itu tidak lebih dari sebuah paket data. Masing- masing pesan ditujukan dalam sebuah listening Daemon RPC menuju sebuah port dalam system remote, dan masingmasing berisi sebuah petunjuk dari fungsi untuk melaksanakan dan parameter untuk melewati fungsi itu. Fungsi ini kemudian dilaksanakan sebagai permintaan dan output dikirim kembali untuk pengguna dalam sebuah pesan terpisah. Sebuah port secara sederhana adalah sebuah nomer yang termasuk dalam start paket pesan dimana sebuah system secara normal satu alat jaringan, system ini mempunyai banyak port yang dimana alat itu untuk membedakan layananlayanan jaringan yang mendukungnya. Jika sebuah proses remote membutuhkan sebuah layanan ini membawa sebuah pesan menuju port yang tepat. Sebagai contoh jika sebuah system diterapkan untuk membuat system lain mampu untuk mengenali pengguna-pengguna tertentu ini akan membuat sebuah daemn pendukung seperti sebuah RPC yang didekatkan pada sebuah port, seperti port 3027. System remote bisa mematuhi informasi yang dibutuhkan (daftar penggunapengguna tertentu) dengan mengirimkan sebuah pesan RPC kepada port 3027 pada server, datanya akan diterima pada pesan balasan. Semantic-semantic dari RPC mengijinkan seorang client untuk mengikuti procedure dari host remote saat semantic RPC akan menjalankan prosedur secara local. System RPC menyembunyikan secara detail yang mengijinkan komunikasi terjadi dengan memberikan sebuah stub pada client, sebuah stub yang terpisah
hadir untuk sebuah prosedur remote yang terpisah ketika client menjalankan sebuah prosedur system RPC memanggil stub yang tepat melewati parameterparameternya yang disediakan pada prosedur remote. Stub ini meletakkan port pada server dan marshaling parameter melibatkan pengemasan parameter menjadi sebuah bentuk yang bisa di ditransmisikan melalui sebuah jaringan stub ini mengirim sebuah pesan kepada server pasing pengguna pesan. Sebuah stub yang sama pada server menerima pesan ini dan melaksanakan prosedur pada server. Jika perlu mengembalikan nilai- nilai pada client yang menggunakan teknik yang sama. Suatu masalah yang harus dihadapi yang berhubungan dalam perbedaan dalam representasi data pada client dan mesin server mempertimbangkan dari 32 bit integer. Beberapa system yang dikenal dengan endian bit menggunakan memori tinggi untuk menyimpan bit yang paling signifikan, sementara system yang lain dikenal endian little menyimpan bit yang signifikan paling kecil di address memori tinggi. Untuk memecahkan perbedaan seperti ini, banyak system RPC mempersembahkan sebuah data dari sebuah representasi data independent. Representasi seperti ini dikenal dengan representasi data eksternal atau SDR pada client marshal parameter melibatkan perubahan pada data mesin dependent menuju SDR sebelum data dikirim kepada server. Pada server, data SDR tak tersusun dan diubah menuju representasi mesin dependen untuk server. Isu lain yang penting melibatkan semantic dari sebuah prosedur panggilan local gagal hanya karena keadaan ekstrim, RPCS bisa gagal, atau diduplikatkan dan dilaksanakan lebih dari satu kali, sebagai sebuah hasil dari kesalahan jaringan biasa. Satu cara untuk mengatasi masalah ini adalah dengan mengoperasikan system untuk memastikan bahwa pesan dikirimkan pada satu kali. Pertama, pertimbangkan “at most once”. Semantic ini bisa dijamin dengan menempelkan sebuah perangko waktu untuk masing- masing pesan. Server harus menjaga histori dari semua perangko pesan yang sudah diproses atau histori yang cukup besar untuk menjamin bahwa pesan yang diulang terdeteksi. Pesan yang masuk yang mempunyai history terabaikan. Client kemudian bisa mengirim satu kali atau lebih dan dijamin ini hanya akan terkirim satu kali untuk “exactly once”,
kita perlu menghilangkan resiko bahwa server tidak pernah menerima balasan. Untuk mengatasinya, server harus mengimplementasikan “at most once” Protocol digambarkan diatas tapi harus diakui client bahwa panggilan RPC diterima dan dilaksanakan. Pesan ACK ini biasanya melalui jaringan. Client harus mengirim kembali masing- masing panggilan RPC secara periodik sampai client menerima ACK untuk panggilan itu. Isu penting lain berhubungan dengan komunikasi antara seorang server dan seorang client. Dengan prosedur panggilan standard, beberapa bentuk binding ditempatkan selama link, proses, atau waktu pelaksanaan sehingga sebuah nama panggilan prosedur ditempatkan oleh alamat memori dari panggilan prosedur. Skema RPC memerlukan sebuah binding yang sama dengan client dan port server, tapi bagaimana seorang client tahu jumlah port pada server ? bukan sistem yang mempunyai informasi penuh tentang yang lain karena sistem tidak membagi memori. Dua pendekatan. Pertama, informasi terikat mungkin ditentukan di awal, dalam bentuk alamat port tetap. Dalam waktu yang tersusun, sebuah port tetap yang diasosiasikan dengan panggilan RPC. Satu kali program tersusun, server tidak bisa mengubah nomor port dari servis yang diminta. Kedua, ikatan bisa dilakukan secara dinamis dengan rendevu. Secara tipikal, sebuah sistem operasi menyediakan rendevu daemon pada port RPC yang tetap. Seorang client kemudian mengirimkan sebuah pesan yang berisi nama RPC pada Daemon rendevu yang meminta alamat port dari RPC, ini perlu untuk dilaksanakan. Nomor port kembali, dan panggilan RPC bisa dikirim ke port sampai proses berakhir. Metode ini membutuhkan ongkos extra pada permintaan paraf tapi ini lebih flexible daripada pendekatan pertama.
Gambar 1. Execution of a remote procedure call (RPC)
Skema RPC berguna dalam pengimplementasian sebuah sistem data distribusi. Seperti sistem yang bisa diimplementasikan sebagai sebuah set dari daemon RPC dan client. Pesan dialamatkan/ditujukan pada port sistem data distribusi pada sebuah server pengoperasian data. Pesan berisi operasi disk yang dipertunjukkan. Pengoperasian disk bisa “menulis, membaca, mengubah nama, menghapus atau status terhubung dengan data biasanya yang terhubung dengan panggilan sistem. Pesan yang kembali berisi suatu data yang dihasilkan dari panggilan itu, yang yang dilaksanakan oleh Daemon DFS atas nama client. Sebagai contoh, sebuah pesan mungkin berisi sebuah permintaan untuk mengirim semua data kepada client atau dibatasi pada sebuah permintaan yang sederhana. Masalahnya, beberapa permintaan mungkin dibutuhkan jika semua data dikirim.
INVOCATION METODE REMOTE
Invocation metode remote adalah sebuah fitur java yang sama dengan RPCS. RMI melakukan sebuah urutan untuk melaksanakan sebuah metode pada objek remote. Objek adalah remote jika mereka berada di mesin virtual java yang berbeda (JVM). Oleh karena itu, objek remote mungkin dalam sebuah JVM yang berbeda pada komputer yang sama atau pada host remote yang dihubungkan dengan sebuah jaringan. RMI dan RPCS dibedakan dalam 2 cara fundamental. Pertama RPCS mendukung program prosedur dimana hanya prosedur atau fungsi remote yang bisa dipanggil. Contrastnya, RMI berdasarkan obyek. RMI mendukung pelaksanaan metode pada objek remote. Kedua, parameter untuk prosedur remote adalah susunan data biasa dalam RPC, dengan RMI, ini mungkin untuk melewati objek sebagai parameter untuk metode remote. Dengan mengijinkan sebuah program java untuk melaksanakan metode pada objek remote, RMI membuat hal ini mungkin kepada pengguna untuk mengembangkan aplikasi java yang didistribusikan melalui sebuah jaringan. Untuk membuat metode remote transparan untuk client maupun server, RMI
mengimplementasikan
objek
remote
menggunakan
“(stub)”
dan
“(skeleton)”. Sebuah stub adalah sebuah perwakilan dari objek remote, ini berada dengan client. Ketika seorang client menggunakan melaksanakan metode remote, stub untuk objek remote dipanggil. Stub yang berada di client bertanggung jawab untuk menciptakan parcel yang berisi nama dari metode untuk dilaksanakan pada server dan parameter marshal untuk metode. Stub kemudian mengirimkan parcel ini kepada server dimana skeleton pada objeck remote menerimanya. Skeleton bertanggung jawab untuk parameter yang tak tersusun dan melaksanakan metode yang diinginkan pada server. Skeleton kemudian menyusun nilai kembali atau pengecualian dalam sebuah parcel dan mengembalikan parcel kepada client. Stub tak menyusun nilai yang kembali dan melewatinya menuju ke client.
Mari lihat lebih dekat bagaimana proses ini bekerja. Anggaplah seorang klien berharap untuk melaksanakan sebuah metode pada server objek remote dengan sebuah tanda yang mengembalikan nilai boolean. Clien melaksanakan pernyataan boolean val = server, somemetho (A,B) Panggilan untuk beberapa metoda dengan parameter A dan B melaksanakan stub untuk objek remote. Stub menyusun kedalam sebuah parcel parameter A dan B dan nama dari metode yang dilaksanakan pada server, kemudian mengirimkan parcel ini kepada server. Skeleton pada server tak menyusun parameter dan meliatan metode “some method”. Implementasi aktual dari “some method” ada pada server. Satu kali metode dilengkapi, skeleton menyusun nilai boolean dikembalikan dari “some method”
dan mengirimkan
nilai ini kembali pada klien. Stub tak menyusun nilai kembali ini dan melewatinya pada clien.
Gambar 2. Remote Method Invocation
Gambar 3. Marshalling parameters
Untungnya, level abstraksi di RMI membuat stub dan skeleton transparan, mengizinkan pengembang java menulis program yang melibatkan metode distribusi hanya saat mereka melibatkan metode lokal. Ini penting, bagaimanapun untuk memahami sedikit aturan tentang melewati parameter. Jika parameter yang tersusun adalah objek lokal (non remote), mereka dilewati oleh copi yang menggunakan tenknik yang dikenal dengan “serialisasi objek”. Bagaimanapun jika parameter adalah objek remote, mereka dilewati oleh referensi. Contohnya, jika A adalah objek lokal dan B adalah objek remote, A diserialkan and dilewati oleh copy, dan B dilewati oleh referensi. Ini membuat server melibatkan metode B secara remote. Jika objek lokal dilewati
sebagai parameter
untuk
objek
remote,
mereka
harus
mengimplementasikan java i.o interface, yang diserialkan. Banyak objek dalam API Java Core mengimplementasikan seri, membuatnya bisa digunakan dengan RMI. Serialisasi objek membuat keadaan sebuah objek ditulis dalam sebuah “Stream byte”.
Diambil dari Buku ”Operating System Concepts” sevent edition ? ? ?
Abraham Silberschatz Greg Gagne Peter Boer Galvin
Halaman 111 - 115
