KOMUNIKASI 

SISTEM TERDISTRIBUSI
 
Outline 

 Komunikasi
o Jenis IPC (Inter Process Communication)
o Arsitektur Komunikasi dengan Protokol Berlapis
o 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 RPC
o RMI
o MOM
o 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 remote
o 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 DCE

o 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 sebaliknya

o Mengirimkan atau menerima message ke/dari mesin remote
o melakukan pemanggilan ataupun eksekusi kode fungsi.

 
 
 
 

Pertanyaan 2 

Proses marshalling adalah proses:

o Meneruskan pemanggilan fungsi ke proxy

o Mengubah parameter fungsi ke bentuk message
o Mengirim message ke proxy (stub atau skeleton)

 
 
 
 

Pertanyaan 3 
Objek diatas adalah jenis objek:

o Named Object
o Dynamic Object
o 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 Transient

 o Pesan hanya disimpan sepanjang pengirim dan penerima lagi berjalan.
Jika masalah timbul, pesan dibuang begitu saja.

 
 
 
 

Terminologi Komunikasi Sistem Terdistribusi 

 Komunikasi Asinkron
o 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!