KOMUNIKASI 

SISTEM TERDISTRIBUSI

 Outline 

Komunikasio Jenis IPC (Inter Process Communication)o Arsitektur Komunikasi dengan Protokol Berlapiso Jenis Komunikasi Protokol High Level

RPC RMI MOM Streaming 

  IPC(Inter Process Communication) 

Secara Garis besar ada 2 macam IPC dasar:o Shared Memory

Terutama pada sistem yang dimana proses yang saling berkomunikasi terletak pada satu node komputer

o Message Passing Mekanisme yang dipakai untuk berkomunikasi antar proses yang terletak

pada node komputer yang sama maupun berbeda. Pada sistem Terdistribusi, IPC pada level bawah hanya dimungkingkan dengan message

passing.

 

 Interprocess Communication (IPC) 

“Jantungnya” dari setiap sistem terdistribusi Pertanyaan: Bagaimana proses-proses pada mesin komputer yang berbeda saling

mempertukarkan informasi? Jawaban: dengan susah payah ? Menggunakan fasilitas jaringan komputer terlalu kuno, menghasilkan suatu sistem

terdistribusi yang sangat sukar untuk dikembangkan. Jadi suatu model baru butuh dikembangkan.

Ada 4 model IPC yang popular:o RPCo RMIo MOMo Streams

  Protokol Berlapis 

Lapisan, antarmuka dan protokol pada Model OSI.

 TCP Client-Server 

Normal operation of TCP. Transactional TCP.

    

Protokol Middleware 

Model referensi adaptasi untuk komunikasi jaringan

 RPC: Remote Procedure Call 

Dikemukakan oleh Birrell and Nelson (1984) 

“Mengizinkan program untuk memanggil prosedur yang terletak pada komputer lain”

Secara efektif membebaskan programmer dari kerumitan berurusan dengan detil pemrograman jaringan (tidak perlu pusing tentang pemakaian socket)

 

Komplikasi pada RPC 

Arsitektur antar 2 mesin yang berbeda mungkin tidak sama. 

Tiap mesin memiliki ruang alamat yang berbeda. 

Bagaimana parameter (tipe yang kompleks dan beragam) dilewatkan dari/ke prosedur remote. 

Apa yang akan terjadi jika, salah satu mesin atau bahkan keduanya crash prosedur lagi dipanggil.

    

Bagaiamana RPC bekerja: Bagian 1 

Bagi pemrograman, pemanggilan prosedur remote harus kelihatan bekerja seperti halnya pemanggilan prosedur lokal.

 

Dengan cara ini, maka tranparansi tercapai

 

Sebelum melihat Aksi RPC, mari kita pertimbangkan sebuah pemanggilan prosedur lokal konvensional.

    

Pemanggilan Prosedur lokal “Konventional” 

Pelewatan parameter pada prosedur lokal:

Keadaan stack sebelum prosedur dipanggil Isi stack ketika prosedur lokal lagi aktif.

    

Bagaimana RPC bekerja: Bagian 2 

Prosedur ini dibagi menjadi 2 bagian.o Stub CLIENT – mengimplementasikan antarmuka pada mesin lokal untuk

memanggil fungsi remoteo Stub SERVER – mengimplementasikan fungsionalitas yang

sesungguhnya.

 

Parameter di “marshal” oleh client sebelum ditransmisikan ke server.

  

  

Stub Client dan Server  

Prinsip RPC antara program client dan server

    

10 Langkah RPC 

Prosedur client memanggil stub client secara normal Stub client membentuk pesan, memanggil OS lokal OS client mengirimkan pesan ke OS remote OS remote meneruskan pesan ke stub Server Stub server melakukan “unpacking” parameter dan memanggil server. Server melakukan kerja (kerja prosedur) dan hasilnya dikembalikan ke stub. Stub server meng-”pack” ke dalam pesan, dan memanggil OS lokal (server) OS server mengirimkan pesan ke OS Client OS Client meneruskan pesan ke stub client Stub client meng-”unpack” hasil prosedur dan mengembalikan ke client.

    

Langkah-langkah RPC

    

Masalah RPC: Passing Value Parameter 

RPC bekerja sangat baik jika semua mesinnya adalah sama Komplikasi muncul ketika dua mesin menggunakan pengkodean karakter yang

berbeda seperti EBCIDC atau ASCII Pengurutan byte juga menjadi satu masalah:

o Mesin Intel menggunakan “big-endian”.o Mesin Sun Sparc menggunakan “little-endian”.

Mekanisme tambahan butuh dimasukkan ke mekanisme RPC untuk menangani kondisi seperti diatas (ini menambah kompleksitas)

    

Masalah RPC: Passing Value Parameter 

Pesan asli pada Mesin Intel (Pentium) Pesan setelah diterima pada Mesin SPARC Pesan setelah dibalik – dimana tetap belum benar sebagaimana seharusnya.

Nb: bilangan dalam kotak menunjukkan alamat dari tiap byte.

    

Variasi RPC Pada mesin lokal: Doors 

Prinsip penggunaan doors sebagai mekanisme IPC:o Proses-proses berada pada mesin yang sama

Keuntungan: mekanisme tunggal untuk pemrograman Sistem Terdistribusi Kekurangan: kehilangan akan transparansi transparensi

    

RPC Asinkron 

Interkoneksi antara client dan server pada RPC tradisional – perhatikan – BLOCKING terjadi – client harus menunggu

Interaksi dengan menggunakan RPC asinkron – tidak ada BLOCKING; berguna jika client tidak memerlukan/mengharapkan adanya hasil kembalian.

 

2-12

  

  

RPC Asinkron: RPC Sinkron Tertunda 

Client dan server berinteraksi lewat dua RPC asinkron- mengizinkan client untuk melakukan kerja lainnya ketika menunggu hasil kembalian.

    

Interface Definition Language (IDL) 

RPC umumnya memerlukan pengembangan antarmuka (interface) protokol kustom agar bisa efektif.

 

Antarmuka protokol dideskripsikan dengan menggunakan sebuah Bahasa Definisi Antarmuka atau Interface Definition Language (IDL).

 

IDL netral terhadap bahasa tertentu – yaitu tidak mengasumsikan pemakaian bahasa pemrograman tertentu.

 

Namun, kebanyakan IDL nampak seperti C….

    

Contoh RPC : DCE 

Merupakan standar Open Group untuk mekanisme RPC Selain RPC, DCE juga menyediakan :

o Distributed File Service.o Directory Service (name lookups).o Security Service.o Distributed Time Service.

    

DCE: Menulis Client dan Server 

Langkah-langkah menulis client dan server pada RPCE DCE

    

DCE: “Binding” Client ke Server 

Binding (pengikatan) client ke server pada DCEo Sebuah “directory service”menyediakan cara bagi client untuk

menemukan server

    

Ringkasan RPC 

Merupakan standar defacto Sistem Terdistribusi untuk komunikasi dan aplikasi terdistribusi ( pada level prosedural)

 

Sudah matang

 

Mudah dimengerti

 

Bekerja dengan baik.

    

RMI: Remote Method Invocation 

“Objek Remote” dapat dipikir sebagai ekpansi dari mekanisme RPC ( untuk mendukung sistem OO ).

Salah satu aspek pentind ari objek adalah definisi dari antarmuka untuk menyembunyikan fungsionalitas.

Pemanggilan method mendukung perubahan state dalam objek lewat antarmuka yang terdefinisi.

Semua objek dapat menawarkan sejumlah antarmuka. Sebuah antarmuka dapat diimplementasikan oleh sejumlah objek. Dalam Sistem Terdistribusi, sebuah antarmuka objek berada pada satu mesin

dan implementasi objek berada pada mesin lainnya.

    

Objek Terdistribusi 

Pengaturan umum untuk objek remote disisi client adalah “proxy” Proxy dapat dibayangkan sebagai stub client Skeleton dapat dibayangkan sebagai stub server

    

Objek Compile-time vs. Objeyk Run-time 

Objek compile-time tedistribusi umumnya mengasumsikan penggunaan suatu bahasa pemrograman (java atau C++)

Hal diatas sering dipandang sebagai kelemahan (tidak fleksibel)

 

Objek run-time terdistribusi menyediakan adaptor objek bagi objek-objek, yang dirancang untuk meniadakan batasan bahasa pemrograman dari objek compile-time

Menggunakan adaptor objek memungkinkan implementasi objek dikembangkan dengan sembarang cara- sepanjang implementasi yang dihasilkan tampak sebagai objek, maka segala sesuatu dianggap baik-baik saja.

  

  

Objek Persistent vs Objek Transient 

Objek persistent terdistribusi tetap ada bahkan setelah tidak berada lagi dalam ruang alamat server.

Objek persistent disimpan (mungkin pada storage sekunder) dan dapat diinstanisasi lagi di waktu lain dengan proses server yang baru

 

Objek transient terdistribusi tidak terus menerus ada. Begitu server berhenti, objek transient turut dimusnahkan

 

Mana yang lebih baik masih menjadi subjek perbantahan

    

Invokasi Static vs Invokasi Dinamis 

Definisi antarmuka yang terdefinisi sebelumnya mendukung invokasi statis: Semua antarmuka harus diketahui terlebih dulu Perubahan pada antarmuka memerlukan semua aplikasi (client) untuk

dikompilasi ulang.

 

Invokasi dinamis membentuk method pada saat run-time Antarmuka dapat “datang dan pergi” seperlunya Antarmuka dapat berubah tanpa perlu memaksa aplikasi client untuk dikompilasi

ulang.

    

Objek Remote: Parameter Passing 

Situasi ketika melewatkan objek secara referensi atau dengan nilai

o Catatan: O1 dilewatkan dengan nilai; O2 dilewatkan dengan referensi

    

Contoh : Objek remote DCE 

Mekanisme RPC DCE dikembangkan lebih lanjut untuk mendukung invokasi method secara remote

Objek DCE = xIDL plus C++. Yaitu , IDL DCE telah diperluas untuk mendukung objek yang diimplementasikan

dalam C++ Dua tipe Objek DCE yang didukung:

o Objek Dinamis Terdistribusi – sebuah objek private yang dibuat oleh server untuk client

o Objek Bernama terdistribusi – sebyag objek yang dipakai bersama yang hidup pada server dan dapat diakses oleh lebih dari satu client.

    

Model Objek Terdistribusi DCE 

Ada dua macam Objek DCE :

Objek dinamis (Dynamic Object) – permintaan pembuatan objek lewat RPC Objek bernama (Named Object)– diregister ke suatu layanan penamaan (naming

service)

    

Contoh: Java RMI 

Dalam java, objek terdistribusi dapat diintegrasikan ke dalam bahasa yang jelas Ini menghasilkan transparensi distribusi yang sangat tinggi (kecuali jika ada

pertimbangan perbaikan efisiensi) Java tidak mendukung RPC, tetapi hanya objek terdistribusi State dari objek terdistribusi disimpan di server, dengan antarmuka dibuat dapat

diakses lewat client remote ( proxi objek terdistribusi)

Untuk membangun aplikasi sistem terdistribusi, programmer hanya butuh mengimplementasikan proxy client sebagai kelas dan skeleton server sebagai kelas lainnya.

    

Pertanyaan 1 

Berikut yang bukan fungsi dari Stub dan Skeleton pada Arsitektur Remote Invocation!

o Mengubah parameter fungsi ke bentuk message maupun sebaliknyao Mengirimkan atau menerima message ke/dari mesin remoteo melakukan pemanggilan ataupun eksekusi kode fungsi.

    

Pertanyaan 2 

Proses marshalling adalah proses:

o Meneruskan pemanggilan fungsi ke proxyo Mengubah parameter fungsi ke bentuk messageo Mengirim message ke proxy (stub atau skeleton)

    

Pertanyaan 3 

Objek diatas adalah jenis objek:

o Named Objecto Dynamic Objecto Static Object

   

Object

    

Message-Oriented Middleware: MOM 

Sebagai mekanisme komunikasi, RPC/RMI sering dianggap tidak tepat pada kondisi tertentu.

 

Contoh: apa yang terjadi jika kita tidak dapat mengandaikan sisi penerima dapat keadaan “siap” dan menunggu untuk berkomunikasi.

Juga: sifat default “ Sinkron, blocking” dari RPC/RMI sering terlalu membatasi Sesuatu yang lain dibutuhkan : MESSAGING

    

Terminologi Komunikasi Sistem Terdistribusi 

Komunikasi persistent:o Sekali dikirim, pengirim dapat berhenti mengeksekusi. Penerima tidak

mesti sedang beroperasi – sistem komunikasi menampung pesan seperlunya (sampai dapat dikirimkan ke pengirim)

o [Apa contohnya?]

 

Kebalikannya, Komunikasi Transiento Pesan hanya disimpan sepanjang pengirim dan penerima lagi berjalan.

Jika masalah timbul, pesan dibuang begitu saja.

    

Terminologi Komunikasi Sistem Terdistribusi 

Komunikasi Asinkrono Pengirim meneruskan kerja lainnya segera setelah mengirim pesan ke

penerima

 

Komunikasi Sinkron:o Pengirim memblok, menunggu balasan dari penerima sebelum bisa

melakukan kerja lainnya. (Ini cenderung menjadi model default untuk teknologi RPC/RMI)

    

Klasifikasi Komunikasi Terdistribusi 

Komunikasi Asinkron persistent Komunikasi Sinkron persistent

    

Klasifikasi Komunikasi Terdistribusi 

Komunikasi Asinkron Transient Komunikasi Sinkron Transient berbasis penerimaan

    

Klasifikasi Komunikasi Terdistribusi 

Komunikasi sinkron transient berbasis pengiriman pada pengiriman pesan Komunikasi sinkron transient berbasis tanggapan

  

  

Sistem Message Passing (MP) 

Secara fundamental pendekatan yang berbeda

 

Semua operasi komunikasi didefinisikan dalam konteks penyampaian pesan

 

Awalnya sistem MP adalah transient, tetapi ini tidak skala baik secara geografi

 

Sekarang ini, penekanannya pada solusi persistent.

    

 Komunikasi transient berorientasi Pesan/Message 

Usaha awal bergantung pada API Socket

 

Bagaimanapun, Pengembang Sistem Terdistribusi menolak Socket

Level abstraksi yang salah (hanya “send” dan “receive’) Terlalu tergantung pada jaringan TCP/IP – tidak cukup divergen

    

The Message-Passing Interface (MPI) 

Vendor middleware umumnya menyediakan abstraksi level tinggi. Tiap vendor menggunakan mekanisme yang tersendiri.

Hal ini mengakibatkan masalah portabilitas karena tidak ada produk vendor yang antarmukanya sama

 

solusinya?o “Message-Passing Interface” (MPI).

    

The MPI API 

Beberapa operasi message-passing yang berguna (nb: masih banyak lagi selain yang dibawah ini)

 

Check if there is an incoming message, but do not block. 

MPI_irecv 

Receive a message; block if there are none. 

MPI_recv 

Pass reference to outgoing message, and wait until receipt starts. 

MPI_issend 

Pass reference to outgoing message, and continue. 

MPI_isend 

Send a message and wait for reply. 

MPI_sendrecv 

Send a message and wait until receipt starts. 

MPI_ssend  

Send a message and wait until copied to local or remote buffer. 

MPI_send 

Append outgoing message to a local send buffer. 

MPI_bsend 

Makna 

Operasi

    

Komunikasi Persistent berorientasi message 

Dikenal juga sebagai : “message-queuing systems”.

 

Sistem ini mendukung komunikasi asinkron persisten Umumnya, transpor dapat berlangsung bermenit-menit (jam –jaman) ,

bandingkan dengan umumnya yang hanya dalam jangka detik/milidetik.

 

Konsep dasar; aplikasi berkomunikasi dengan memasukkan dan mengambil pesan dari antrian pesan (“message queue”)

 

Hanya memastikan: suatu message pada akhirnya akan masuk ke antrian pesan penerima

 

Ini memimpin kepada komunikasi yang bersifat longgar (loosely-coupled)

    

Model Message-Queuing 

Empat kombinasi komunikasi terikat longgar menggunakan antrian pesan (message queque)

    

API dari Message-Queuing 

Antarmuka dasar dari antrian pada sistem messae queuing : sangat sederhana namun merupakan abstraksi yang bagus

 

Install a handler to be called when a message is put into the specified queue. 

Notify 

Check a specified queue for messages, and remove the first. Never block. 

Poll 

Block until the specified queue is nonempty, and remove the first message. 

Get 

Append a message to a specified queue. 

Put 

Makna 

Operasi

    

Arsitektur sistem Message-Queuing 

Pesan diletakkan pada antrian sumber Pesan pada akhirnya harus diambil dari suatu antrian tujuan

 

Jelasnya harus ada mekanisme untuk memindahkan pesan dari antrian sumber ke antrian tujuan.

Ini adalah tugas dari Manager antrian (Queue Manager)

 

Manager antrian ini berupa relay antrian pesan yang berinteraksi dengan aplikasi terdistribusi dan juga satu sama lain. Ini sama halnya pada router yang menggunakan lapisan jaringan.

    

Arsitektur sistem Message-Queuing 

Hubungan antara pengalamatan level antrian dan pengalamatan level jaringan. Lapisan antrian berada pada abstraksi yang lebih tinggi dari lapisan dibawahnya.

    

Arsitektur sistem Message-Queuing 

Konfigurasi umum dari sistem messaged-queuing dengan router. Manager antrian terletak dalam router dan juga pada ujung-ujung dari sistem terdistribusi.

The general organization of a message-queuing system with routers. The Queue Managers can reside within routers as well as within the DS end-systems.

    

Peran dari Message Brokers (Makelar pesan) 

Sering kali ada kebutuhan untuk mengintegrasikan aplikasi baru ataupun yang sudah ada ke dalam Sistem Informasi terdistribusi yang tunggal dan menyatu.

 

Masalah: ada berbagai macam format pesan dalam sistem yang lama . (dimasa lalu, kerjasama dan acuan terhadap standar terbuka bukanlah sesuatu yang umum)

Mungkin tidak enak untuk memaksa sistem lama untuk mengacu pada format pesan yang tunggal dan global.

Sering kali terpaksa harus menerima perbedaan-perbedaan tersebut

 

Bagaimana caranya? Menggunakan “Message Broker”.

    

Konfigurasi Message Broker 

Message broker sering juga disebut degan “interface engine”.

    

Aplikasi Message-Queuing (MQ) 

Sistem MQ mendukung berbagai macam aplikasi termasuk:o Electronic mail.o Workflow.o Groupware.o Batch Processing.

Area aplikasi MQ yang paling penting :o Integrasi koleksi aplikasi basisdata yang tersebar dimana-mana ( yang

tidak mampu dilakukan oleh RPC/RMI)

    

Contoh : IBM MQSeries 

Arsitektur IBM MQSeries

    

IBM MQSeries: Message Channel (Saluran pesan) 

Sejumlah atribut yang berhubungan dengan MCA (Message Channel Agent)

 

Jumlah percobaan maksimum MCA mencoba meletakkan pesan yang diterima ke dalam antrian. 

Delivery retries 

Menentukan jumlah percobaan maksimum untuk memulai MCA remote 

Setup retry count 

Panjang maksimum dari pesan tunggal. 

Message length 

Menunjukkan pesan disampaikan dalam urutan yang sama dengan urutan pengirimannya. 

FIFO delivery 

Menentukan protokol transport yang digunakan 

Transport type 

Deskripsi 

Atribut

    

IBM MQSeries: Message Transfer 

Operation ini didukung pada Antarmuka MQ dari IBM MQseries

  

Mengambil pesan dari sebuah antrian lokal. 

MQget 

Meletakkan pesan ke dalam antrian yang terbuka 

MQput 

Menutup antrian 

MQclose 

Membuka sebuah antrian (bisa remote) 

MQopen 

Deskrpsi 

Operasi

    

Komunikasi berorientasi stream 

Dengan RPC, RMI dan MOM, efek ketepatan waktu tidaklah penting.

 

Namun, data audio dan video adalah aliran data yang tergantung pada waktu. Jika pewaktu dimatikan, maka output yang dihasilkan dari sistem bakalan salah.

 

Informasi yang tergantung pada waktu (time-dependent) dikenal sebagai komunikasi media kontinyu.

 

Contoh : voice: PCM: interval waktu 1/44100 detik saat dimainkan Contoh: video: 30 frames per detik (30-40 milidetik per gambar).

 

Inti masalah :Waktu adalah sangat krusial !

    

Mode Transmisi 

Mode transmisi asinkron – data stream di transmisi dalam urutan yang benar, namun tidak ada batasan waktu ditetapkan pada penyampaian yang sesungguhnya (contoh FTP)

 

Mode transmisi sinkron – delay maksimum dari titik ke titik didefinisikan (data harus bisa ditransmisikan secepatanya.)

 

Mode transmisi Isokron data ditransfer tepat waktu – ada delay maksimum dan minimum antar titik (bounded jitter)

o Dikenal sebagai “streams” – transmisi isokron (isochoronous) sangat berguna untuk sistem multimedia.

    

Tipe stream 

Stream sederhana – runtun data tunggal contoh voice (suara)

 

Stream Kompleks – sejumlah runtun data (substream) yang saling berhubungan secara waktu. (Misalkan movie dengan suara dan sub title)

o Ini memunculkan masalah sinkronisasi, yang sangat tidak mudah ditangani.

  

  

Sinkronisasi Eksplisit 

Prinsip sinkronisasi eksplisit pada level unit data untuk stream jamak (substream)

    

Sinkronisasi Level tinggi. 

Prinsip sinkronisasi yang didukung oleh antarmuka level tinggi dibangun sebagai suatu set layanan streaming middleware multimedia.

    

Sinkronisasi  

Pertanyaan kunci:o Dimanakah sinkronisasi terjadi ?

 

Pada sisi pengirim ? Atau pada sisi penerima ?

 

Pikirkan keuntungan dan kerugiaannya masing-masing!

    

Komponen dari stream 

Ada 2 bagian : “source” dan “sink”: Keduanya dapat berupa perangkat jaringan (a) ataupun perangkat akhir (b)

    

Data stream Partai jamak 

Contoh stream multicasting ke sejumlah penerima. Ini adalah komunikasi partai jamak- kecepatan transfer yang berbeda mungkin dibutuhkan untuk perangkat akhir yang berbeda.

    

Quality of Service (QoS) 

Definisi: “memastikan bawhwa hubungan waktu dalam stream dapat terpenuhi”.

 

QoS memperhatikan 3 hal: (a) Tepat waktu (b) Volume dan c) Keandalan.

 

Tetapi bagaiman Qos dispesifikasikan?

 

Celakanya, semua sistem memakai caranya sendiri-sendiri.

    

Menspesifikasikan QoS dengan Spesifikasi Flow 

Spesifikasi Flow – salah satu cara untuk menspesifikasikan QoS – sedikit kompleks, tetapi bekerja baik (tapi bukan lewat antarmuka yang dikontrol oleh pengguna).

 

Loss sensitivity (bytes) Loss interval (sec) Burst loss sensitivity (data units) Minimum delay noticed (sec) Maximum delay variation (sec) Quality of guarantee

 

maximum data unit size (bytes) Token bucket rate (bytes/sec) Toke bucket size (bytes) Maximum transmission rate (bytes/sec)

 

Layana yang dibutuhkan 

Karakteristik INput

    

Pendekatan implementasi QoS 

Prinsip “ token bucket algorithm” – teknik klasik untuk mengontrol aliran data ( dan mengimplementasikan karakteristik Qos)

    

Managemen Stream 

Mengelola stream adalah tentang mengelola bandwith, buffer dan kapasitas pemrosesan serta prioritas penjadwalan – yang semuanya itu diperlukan untuk menjamin QoS.

 

Tidak tidak semudah kedengarannya, tidak ada kesepakatan bagaimana seharusnya hal ini dapat terlaksana.

 

Contoh : Qos dari ATM dari ATM terbuka tidak bekerja (susah diimplementasikan)

Teknik lain adalah RSVP internet.

    

QoS dari RSVP Internet 

Konfigurasi dasar RSVP untuk reservasi resource pada suatu sistem terdistribusi – protokol kontrol level transport untuk memungkinkan reservasi resource pada router jaringan. Karakteristik menarik: Pengerima diinisiasi.

    

Ringkasan 

Kekuatan dan fleksibilitas adalah penting, sedangkan operasi pemrograman jaringan terlalu kuno (kaku)

 

Komunikasi middleware. Mekanime – menyediakan dukungan abstraksi level tinggi.

 

RPC dan RMI: disinkronisasi, transient. MOM: nyaman, asinkron, persistent. Streams: kasus khusus, berguna untuk menangani “data yang terikat waktu”

(sangat susah).

    

Pertanyaan? 

Andaikan dalam suatu sistem, kita hanya bisa menggunakan operasi komunikasi sinkron. Bagaimana kita bisa mengimplementasikan operasi komunikasi transient asinkron?

Jelaskan mengapa komunikasi sinkron transient memiliki masalah skalabilitas!