Komunikasi Antar Proses id. docx
Komunikasi Antar Proses
Alvi Syahrina (32890) & Atika Fauziyah (32895)
4.2 API untuk Protokol Internet
Pada bagian ini kita akan membahas karakteristik umum komunikasi antar proses k
emudian memperlihatkan contohnya pada Internet protocol.
4.2.1 Karakteristik Komunikasi Antar Proses
Pertukaran pesan antara sepasang proses bisa dilakukan dengan menjalankan dua
operasi penting: send and receive.
Komunikasi Sinkron dan Asinkron
Komunikasi diantara proses send dan receive bisa dengan cara sinkron maupun asin
kron. Pada
komunikasi sinkron, proses send dan receive akan melakukan sinkronisasi pada seti
ap
pengiriman pesan. Dalam keadaan ini kedua proses merupakan operasi blocking, ya
itu jika send
sedang dijalankan maka operasi receive akan di block sampai operasi send selesai.
Pada komunikasi asinkron penggunaan operasi send yang bersifat non‐
blocking bisa berjalan
prosesnya setelah pesan disimpan pada local buffer, sehingga transmisi pesan nya
bisa bersamaan dengan proses send.
Tujuan Pesan
Pada protokol internet pengiriman pesan ditujukan pada pasangan (Internet address
, local port).
Local port adalah tujuan pengiriman pesan pada internal computer, memiliki format
integer.
Sebuah port memiliki satu penerima namun bisa menerima dari berbagai sender. Pr
oses apapun yang mengetahui alamat port bisa mengirimkan pesan ke dalamnya.
Jika klien menggunakan alamat Internet yang tetap untuk suatu servis, maka servis
tersebut
harus berjalan pada computer yang sama agar alamatnya tetap valid. Untuk mendu
kung hal ini bisa dilakukan salah satu cara berikut:
•
Program client menunjjuk pada servis berdasarkan nama dan menggunakan nama
server atau binder untuk menerjemahkan nama mereka ke lokasi server dan run tim
e. Dengan ini servis bisa direlokasi namun tidak sepenuhnya ‘migrasi’ (berpindah
sementara sistem masih running). •
Sistem operasi menyediakan identifier untuk tujuan pesan, memetakannya ke dala
m alamat yang berada dalam level rendah untuk mengirim pesan pada port.
Reliabilitas
Komunikasi dengan reliabilitas adalah suatu komunikasi yang memiliki nilai validitas
dan
integritas yang baik. Suatu pesan memiliki reliabilitas baik jika ia terkirim secara utu
h dan tidak ada duplikasi.
Pengurutan
Beberapa aplikasi membutuhkan pesan yang dapat dikirimkan dengan urutan, yaitu
urutan
transmisi dari sender. Pengiriman pesan yang tidak sesuai urutan dianggap gagal ol
eh beberapa aplikasi.
4.2.2 Socket
Komunikasi antar proses terdiri atas transmisi pesan diantara socket pada salah sat
u proses dan socket
lain pada proses lain, seperti yang digambarkan pada gambar di atas. Untuk meneri
ma pesan, socket
harus terhubung dengan local port dan alamat internet computer. Pesan dikirim ke s
uatu alamat
Internet dan port tertentu bisa diterima oleh proses yang socketnya terkait dengan
alamat internet dan
nomor port. Proses bisa menggunakan socket yang sama untuk mengirim dan mene
rima pesan. Proses
bisa menggunakan lebih dari satu port untuk menerima pesan, namun suatu proses
tidak bisa berbagi
port dengan proses lain dalam computer yang sama. Namun ada perkecualian untu
k proses IP multicast.
Sebaliknya berapapun proses bisa mengirimkan pesan ke satu port yang sama. Seti
ap socket terkait dengan protokol khusus, bisa UDP atau TCP.
Java api untuk alamat internet
Java memberikan kelas untuk merepresentasikan alamat internet yaitu InetAddress.
Pengguna
kelas menunjuk pada computer berdasarkan Domain Name Service (DNS). Sebagai
contoh,
instans dari InetAddress yang mengandung alamat internet bisa dibuat dengan cara
memanggil metode static, dengan memberikan hostname DNS sebagai argument.
InetAddress aComputer = InetAddress.getByName(“Bruno.dcs.qmw.ac.uk”)
4.2.3 Komunikasi Datagram UDP
Sebuah datagram yang dikirim oleh UDP ditransmisikan dari proses send ke proses r
eceive tanpa acknowledgement atau coba‐
coba. Jika gagal, pesan bisa tidak diterima. Berikut adalah beberapa
pembahasan mengenai komunikasi datagram:
• Message size
Ukuran pesan harus ditentukan agar bisa menyesuaikan dengan array • Blocking
UDP menggunakan perintah send yang non‐blocking dan perintah receive yang bloc
king • Timeouts
Beberapa proses tidak diperkenankan menunggu terlalu lama, sehingga digunakan t
imeout pada socket untuk membatasi waktunya • Receive from any
Metode ini bisa menerima pesan dari manapun karena asalnya tidak dipertanyakan
Failure Model Failure model pada UDP:
• Ommision failure Ketika pengiriman pesan kadang‐
kadang terhenti begitu saja karena tidak ada sisa tempat • Ordering
Pesan sering terkirim sering keluar dari perintah sender
Penggunaan UDP Pengiriman pesan bisa berasal dari overhead berikut:
1. Kebutuhan untuk menyimpan informasi dari source ke tujuan 2.
Transmisi pesan ekstra 3. Latency pengirim
JAVA API UNTUK Datagram
Java API menyediakan dua kelas untuk datagram: DatagramPacket dan Datagram S
ocket.
Format DatagramPacket terdiri atas:
Array pesan Panjang pesan Alamat internet Nomor port
DatagramSocket terdiri atas metode berikut:
• Send dan receive
Metode ini digunakan untuk mentransmit diagram diantara sepasang socket. •
setSiTimeout Metode ini akan mengeset timeout • connect
metode ini digunakan untuk menghubungkan dengan port dan alamat internet yang
remote.
4.2.4 Komunikasi TCP STREAM Karakteristik dari stream TCP meliputi:
• Ukuran pesan
Aplikasi bisa memilih seberapa banyak data yang ditulis pada sebuah stream data a
tau membacanya. Ukuran pesan bisa sangat kecil maupun sangat besar.
• Status hilang
Protokol TCP menggunakan skema acknowledgement. Ketika sebuah packet terkirim
pihak
penerima akan memberikan acknowledgement atas semua paket yang sudah samp
ai. • Pengaturan Flow
Digunakan untuk mengatur kecepatan TCP protokol dan proses agar tetap bisa coco
k. Ketika salah satu terlalu cepat maka akan diblock. •
Pengurutan dan penggandaan pesan
Setiap pesan yang memiliki identifier yang terasosiasi pada setiap paket IP. Ini berg
una untuk
mendeteksi dan menolak duplikasi dan melakukan pengurutan pesan yang sampai
• Tujuan Pesan
Sepasang proses terkomunikasi akan membuat satu kobeksi sebelum mereka melak
ukan komunikasi lewat stream.
Komunikasi Stream melakukan metode berikut:
• Pencocokan data
Dua proses harus melakukan persetujuan atyas isi data ada sebuah stream. Jika pas
angan proses
tidak berkooperasi dengan benar, maka proses pembacaan bisa terjadi eror ketika
menginterpretasikan data. • Blocking
Data yang dituliskan pada stream disimpan pada antrian pada socket tujuan. Proses
yang
menulis data pada suatu stream akan diblock oleh TCP flow control jika data menga
ntri pada socket melebihi yang bisa ditampung protokolnya. • Thread
Thread akan digunakan ketika berkomunikasi dengan klien baru. Keuntunganmengg
unakan
thread yang berbeda adalah server bisa melakukan blocking ketika menunggu suat
u input tanpa harus mendelay klien lain.
Failure Model
Ketika koneksi terputus, sebuah proses akan diberitahu jika ia berusaha melakukan
read atau write. Pengaruhnya adalah seperti berikut:
•
Proses menggunakan koneksi tidak bisa membedakan antara kesalahan jaringan da
n kesalahan proses pada sisi lain •
Proses yang berkomunikasi tidak bisa mengetahui apakah pesan sebelumnya diteri
ma atau tidak
Kegunaan TCP
Banyak servis yang berjalan dengan koneksi TCP, dengan jumlah port tertentu. Term
asuk protokol berikut:
• HTTP
Hypertext transfer protocol digunakan untuk komunikasi antara browser dan web se
rver
• FTP
File transfer protocol digunakan untuk membuat direktori pada computer remote un
tuk mengakses file dan folder. File ini juga bisa ditransferkan ke computer. • Telnet
Menyediakan akses dengan sesi ke computer remote • SMTP
Simple mail transfer protokol digunakan untuk mengirim mail diantara computer‐
komputer.
Java API untuk STREAMING TCP
Java API menyediakan dua kelas untuk TCP stream yaitu kelas ServerSocket dan Soc
ket.
• Server SOCKET
Digunakan oleh server untuk membuat socket pada sebuah portnya. • SOCKET
Digunakan oleh sepasang proses yang terkoneksi.
4.3 Representasi data eksternal dan marshalling
Ada dua cara untuk computer bertukar data:
•
Nilai diconvert ke dalam format yang berbeda sebelum melakukan transmisi dan dic
onvert ke
format local; jika dua computer diketahui memiliki jenis yang sama, konversi bisa dil
akukan • Nilai yang ditransmisi menggunakan format pengirim
Sebuah standar yang disetujui oleh struktur data dan nilai primitive disebut dengan
representasi data eksternal.
Marshalling adalah proses untuk mengambil koleksi data dan menyusunnya ke dala
m sebuah bentuk
yang bisa dilakukan transmisi. Unmarshallling adalah proses pembongkaran data ke
tika sudah sampai untuk memproduksi sebuah koleksi yang sama pada tujuan.
4.3.1 Representasi data umum pada CORBA
CORBA CDR adalah representasi data yang didefinisikan dengan CORBA 2.0 yang m
erepresentasikan
semua jenis data yang digunakan sebagai argument dan mengembalikan nilai pada
invokasi CORBA. Gambar di bawah ini menjelaskan format pesan CORBA CDR.
4.3.2 Java object Serialization
Serialisasi berarti melakukan flattening obyek atau sekumpulan obyek yang terkone
ksi secara serial.
Sementara itu deserialisasi adalah mengembalikan keasaan obyek dari bentuk seria
lisasinya. Gambar di bawah ini adalah bentuk serialisasi pada Java.
4.3.3 Referensi remote obyek
Sebuah remote obyek reference adalah sebuah identifier untuk remote obyek yang
valid pada
keseluruhan sistem terdistribusi. Remote obyek referencememiliki representasi sepe
rti gambar berikut. Nilai ini harus bersifat unik.
4.4 Komunikasi ClientServer
Bentuk komunikasi didisain untuk mendukung peran dan pertukaran pesan dalam in
teraksi client‐server yang khusus. Pada kasus normal, komunikasi request‐
reply bersifat sinkron karena client memproses
blok hingga reply sampai di server. Komunikasi dapat diandalkan karena reply dari
server berupa acknowledgement ke client. Komunikasi request‐
reply asinkron adalah sebuah alternative yang
mungkin sangat berguna dalam situasi dimana client dapat menerima reply setelah
nya.
Protocol Requestreply
Protocol ini didasari trio komunikasi promitif :doOperation, getRequest, dan sendRep
ly.
Protocol yang akan dibahas di sini adalah protocol yang mendukung komunikasi pad
a RMI
dimana metode RMI ini melewatkan referensi remote objek ke suatu objek yang me
miliki metode untuk diminta dalam request message.
Metode doOperation digunakan pada sisi klien untuk meminta operasi remote. Argu
mennya
menjelaskan metode dan remote objek yang mana yang akan diminta. Hasilnya ad
alah reply
RMI. Dapat diasumsikan bahwa klien yang memanggil doOPeration membungkus ar
gument
dalam byte array dan membuka bungkus hasil dari byte array yang dikembalikan. A
rgument
pertama dari doOperation adalah instans dari kelas RemoteObjectRef yang merepre
sentasikan
referensi untuk remote objek. Kelas ini menyediakan metode untuk mendapatkan i
nternet
address dan port server dari remote objek. Metode doOperation mengirim pesan re
quest ke
server yang memiliki alamat internet dan port yang dijelaskan dalam referensi remo
te objek
reference sebagai argument. Setelah mengirim pesan request, doOperation meman
ggil receive
untuk mendapat pesan reply, dimana ia mengekstrak hasil dan mengembalikan ke
pada
pemanggil. Pemanggil dari doOperation diblok sampai remote objek pada server m
elakukan
operasi yang diminta dan mentransmisinya sebagai pesan reply ke proses klien.
Sementara itu, metode getRequest digunakan di sisi server. Saat server telah mem
anggil
metode pada objek tertentu, server menggunakan sendReply untuk mengirim pesan
reply ke
klien. Saat pesan reply diterima klien, doOperation tidak diblok, dan eksekusi progr
am klien dilanjutkan.
Berikut ini adalah struktur pesan request‐reply
MESSAGETYPE
REQUESTID
OBJECTREFERENCE
METHODID
ARGUMENTS
Filed messageType mengindikasikan apakah pesan merupakan pesan reply atau req
uest. Field
requestId mengandung indentifier pesan. Field yang ketiga adalah referensi remote
objek yang
dibungkus. Field keempat (methodId) adalah indentifier untuk metode yang dipang
gil.
Model Kegagalan Protokol Requestreply
Apabila tiga operasi doOperation, getRequest, sendReply diimplementasikan pada d
atagram
UDP, ketiganya akan mengalami kegagalan komunikasi. Kegagalan tersebut antara
lain :
‐ Ketiganya akan mengalami kegagalan omission (omission failure) ‐
Pesan tidak dijamin terkirim sesuai urutan di pengirim.
‐ Sebagai tambahan, protokol dapat mengalami kegagalan proses. Hal ini dapat
diasumsikan bahwa proses mengalami crash failure.
Untuk mengatasinya, doOperation menggunakan timeout ketika menunggu mendap
atkan
jawaban server. Aksi yang diambil ketika timeout terjadi tergantung jaminan pengiri
man yang ditawarkan.
Timeout : ada beberapa pilihan yang doOperation dapat lakukan setelah terjadi
timeout. Pilihan paling sederhana adalah mengembalikan ke client bahwa operasi
doOperation telah gagal. Akantetapi, ini bukanlah cara yang umum digunakan.
Penanggulangan kemungkinan hilangnya pesan adalah doOperation mengirim pesa
n
request secara berulang hingga ia mendapatkan jawaban atau terjadi delay. Pada
akhirnya, saat doOperation memberikan kembalian, ia akan mengindikasikan ke klie
n melalui eksepsi bahwa tidak ada hasil yang diterima.
Membuang pesan request terduplikasi : apabila tidak ada pesan request yang
ditransmisi ulang, server mungkin menerimanya lebih dari satu kali. Misalnya, serv
er
mungkin menerima pesan request pertama tetapi memerlukan waktu eksekusi lebih
lama dari timeout yang dimiliki klien. Hal ini dapat membuat server mengeksekusi
lebih
dari sekali untuk request yang sama. Untuk menghindarinya, protocol perlu didesai
n untuk mengenali pesan dari klien yang sama.
Menghilangkan pesan reply : apabila server telah mengirim reply ketika ia menerim
a duplikat request, server perlu mengeksekusi operasi lagi untuk mendapat hasil.
Beberapa server dapat mengeksekusi operasi mereka lebih dari sekali dan menerim
a
hasil yang sama tiap waktunya. Sebuah idempotent operation adalah operasi yang
dilakukan berulang dengan hasil sama.
History : istilah history digunakan untuk menunjuk kepada suatu struktur yang me
miliki
rekaman pesan reply yang telah ditransmisikan. Permulaan history memiliki reques
t
indentifier, pesan, dan identifier klien tujuan. Tujuannya adalah untuk mengijinkan
server untuk mentransmisi ulang pesan reply ketika klien memproses request mere
ka.
Masalah yang ditimbulkan oleh history ini adalah biaya memori yang diperlukan terl
alu besar.
Penggunaan Stream TCP untuk Implementasi Protokol RequestReply
Keinginan untuk menghindari pengimplementasian protocol multi‐paket adalah alas
an mengapa memilih penggunaan protocol request‐
reply melalui stream TCP yang mengijinkan argument
dan hasil dengan ukuran berapapun ditransmisi. Secara khusus, Java object serializ
ation adalah
protocol stream yang mengijinkan argument dan hasil dikirim melalui stream antara
klien dan
server, memungkinkan koleksi objek dengan ukuran berapapun ditransmisi secara h
andal. Jadi,
tidak diperlukan transmisi ulang dan penggunaan history. Oleh karena itu, TCP prot
ocol dipilih untuk mengimplemensikan protocol request‐
reply karena protocol ini dapat menyederhanakan implementasi.
HTTP: Contoh Protokol RequestReply
Metode HTTP : setiap request klien menjelaskan nama metode untuk diaplikasikan
ke sumber
pada sever dan URL sumber. Reply memberi report status request. Request dan re
ply
mengandung data sumber, output program sumber yang dijalankan pada server we
b.
Metode yang termasuk dalam HTTP adalah :
GET : meminta sumber dimana URL berfungsi sebagai argument.
HEAD : request ini hampir sama dengan GET tetapi tidak mengembalikan data.
POST : menjelaskan URL dari sumber yang berhubungan dengan data. Prosesnya
tergantung pada fungsi program yang dijelaskan dalam URL. Metode ini didisain un
tuk berhubungan dengan :
‐ Penyediaan blok data untuk proses data‐handling, misalnya servlet atau
program cgi ‐ Memposkan pesan ke bulletin board, mailing list, atau newsgroup ‐
Memperluas database dengan operasi append
PUT : melakuan request bahwa data disimpan dengan URLnya sebagai identifier.
DELETE : server menghapus sumber yang diidentifikasi oleh URL. Server tidak bole
h selalu mengijinkan operasi ini dimana reply mengindikasikan kegagalan.
OPTIONS : server menyediakan client dengan daftar metode.
TRACE : server mengirim kembali pesan request. Metode ini digunakan untuk tujua
n tertentu.
Message Contents : pesan request menjelaskan nama metode, URL atau sumberny
a, versi
protocol, header, dan badan pesan. Berikut ini adalah gambar pesan reply HTTP :
HTTP VERSION
STATUS CODE REASON HEADERS
MESSAGE BODY
HTTP/1.1 200 OK RESOURCE DATA
4.5 Komunikasi Grup
Dalam komunikasi grup ini dikenal multicast operation, yaitu operasi yang mengirim
pesan tunggal dari
proses tunggal ke suatu grup. Terdapat banyak kemungkinan untuk mengadakan ko
munikasi multicast.
Yagn paling sederhana adalah komunikasi grup yang tidak memberikan jaminan uru
tan dan pengiriman pesan.
Pesan multicast menyediakan infrastruktur untuk mengkonstruksi sistem terdistribu
si dengan karakteristik sebagai berikut :
1. Toleransi Fault berdasar services replicated
Replicated service terdiri dari satu grup server. Request client adalah multicast ke s
eluruh anggota grup. Tiap‐
tiap request melakukan operasi yang serupa. Apabila beberapa anggota
gagal, client lain tetap dapat dilayani. 2.
Menemukan discovery server dalam jaringan spontaneous
Pesan multicast digunakan oleh sever dan klien untuk menentukan service discover
y yang
tersedia guna mendaftarkan interface atau melihat interface layanan lainnya dalam
sistem terdistribusi. 3. Performansi yang lebih baik melalui data replikasi
Data direplikasi untuk meningkatkan performansi layanan. Tiap waktu data beruba
h, nilai baru dimulticast ke proses untuk mengatur replica. 4.
Propagasi dari event notifications
Multicast ke grup dapat digunakan untuk memberitahu proses ketika sesuatu terjadi
. Misalnya,
suatu sistem baru mungkin memberitahu user ketika pesan baru telah dikiri ke new
sgroup
tertentu. Sistem Jini menggunakan multicast untuk menginformasikan client tertent
u ketika layanan baru memberi tahu keberadaannya.
4.5.1 IP Multicast—Implementasi dari Komunikasi Grup
IP Multicast
IP multicast dibangun pada bagian atas protocol internet, IP. IP multicast mengijinka
n pengirim
untuk mentransmisi paket IP tunggal ke sekumpulan computer yang membentuk gr
up multicast.
Pengirim tidak mempedulikan identitas tiap penerima dan ukuran grup. Grup multic
ast digolongkan dalam alamat internet kelas D.
Menjadi anggota grup multicast membuat suatu computer untuk dapat menerima p
aket IP yang
dikirim ke grup. Keanggotaan pada grup multicast bersifat dinamis. Suatu compute
r dapat bergabung atau meninggalkan grup.
Model Kegagalan dari Multicast Diagram
Multicast datagram melalui IP multicast memiliki karakteristik kegagalan seperti dat
agram UDP.
Akibatnya, pesan tidak dijamin terkirim ke anggota grup tertentu. Beberapa anggot
a grup saja
yang mungkin dapat menerimanya. Hal ini disebut unreliable multicast. Multicast y
ang reliable dibahas di bab 11.
Java API pada IP Multicast
Java API menyediakan interface datagram untuk multicast IP melalui kelas Multicast
Socket yang
merupakan subkelas dari DatagramSocket dengan kemampuan tambahan mampu b
ergabung ke
grup multicast. Kelas MulticastSocket menyediakan dua alternative konstruktor, me
ngijinkan
socket diciptakan untuk menggunakan local port tertentu atau local port manapun s
ecara
bebas. Suatu proses dapat bergabung ke grup multicast melalui alamat multicast d
engan
memanggil metode joinGroup milik multicast socket. Suatu proses dapat meninggal
kan grup tertentu dengan memanggil metode leaveGroup milik multicast soket.
4.5.2 Kehandalan dan Urutan Multicast
Berikut adalah beberapa contoh efek dari Reliabillity dan Ordering
1. Toleransi Fault berdasar services replicated
Suatu aplikasi multicast memerlukan bahwa seluruh anggota atau tidak satupun har
us menerima tiap request untuk melakukan operasi –
bila salah satunya tidak mendapat
request, akan terjadi inkonsistensi. Pada sebagian besar kasus, seluruh anggota gru
p harus menerima pesan request dengan urutan yang sama seluruhnya. 2.
Menemukan discovery server dalam jaringan spontaneous
Misalnya suatu proses ingin meletakkan discovery server multicast request pada int
erval
periodis tertentu selama waktu setelah discovery server starts up. Jini mengunakan
IP multicast dalam protokol multicast request untuk menemukan discovery server.
3. Performansi yang lebih baik melalui data replikasi
Apabila terjadi dimana data replikasi,bukan operasi pada data, didistribusikan melal
ui pesan
multicast. Resiko kehilangan pesan dan inconsistensi urutan akan tergantung pada
metode
replikasi dan tingkat kepentingan seluruh replica. Misalnnya replica dari newsgroup
tidak selamanya konsisten satu sama lain pada satu waktu—
pesan mungkin muncul dalam rurutan yang berbeda. 4.
Propagasi dari event notifications
Aplikasi khusus menentukan kualitas yang diperlukan dari multicast. Misalnya Jini
announcement service menginformasikan pihak‐pihak berkaitan tentang service ya
ng
tersedia melalui IP multicast untuk membuat pengumuman pada frekuensi interval
yang sering. a
Alvi Syahrina (32890) & Atika Fauziyah (32895)
4.2 API untuk Protokol Internet
Pada bagian ini kita akan membahas karakteristik umum komunikasi antar proses k
emudian memperlihatkan contohnya pada Internet protocol.
4.2.1 Karakteristik Komunikasi Antar Proses
Pertukaran pesan antara sepasang proses bisa dilakukan dengan menjalankan dua
operasi penting: send and receive.
Komunikasi Sinkron dan Asinkron
Komunikasi diantara proses send dan receive bisa dengan cara sinkron maupun asin
kron. Pada
komunikasi sinkron, proses send dan receive akan melakukan sinkronisasi pada seti
ap
pengiriman pesan. Dalam keadaan ini kedua proses merupakan operasi blocking, ya
itu jika send
sedang dijalankan maka operasi receive akan di block sampai operasi send selesai.
Pada komunikasi asinkron penggunaan operasi send yang bersifat non‐
blocking bisa berjalan
prosesnya setelah pesan disimpan pada local buffer, sehingga transmisi pesan nya
bisa bersamaan dengan proses send.
Tujuan Pesan
Pada protokol internet pengiriman pesan ditujukan pada pasangan (Internet address
, local port).
Local port adalah tujuan pengiriman pesan pada internal computer, memiliki format
integer.
Sebuah port memiliki satu penerima namun bisa menerima dari berbagai sender. Pr
oses apapun yang mengetahui alamat port bisa mengirimkan pesan ke dalamnya.
Jika klien menggunakan alamat Internet yang tetap untuk suatu servis, maka servis
tersebut
harus berjalan pada computer yang sama agar alamatnya tetap valid. Untuk mendu
kung hal ini bisa dilakukan salah satu cara berikut:
•
Program client menunjjuk pada servis berdasarkan nama dan menggunakan nama
server atau binder untuk menerjemahkan nama mereka ke lokasi server dan run tim
e. Dengan ini servis bisa direlokasi namun tidak sepenuhnya ‘migrasi’ (berpindah
sementara sistem masih running). •
Sistem operasi menyediakan identifier untuk tujuan pesan, memetakannya ke dala
m alamat yang berada dalam level rendah untuk mengirim pesan pada port.
Reliabilitas
Komunikasi dengan reliabilitas adalah suatu komunikasi yang memiliki nilai validitas
dan
integritas yang baik. Suatu pesan memiliki reliabilitas baik jika ia terkirim secara utu
h dan tidak ada duplikasi.
Pengurutan
Beberapa aplikasi membutuhkan pesan yang dapat dikirimkan dengan urutan, yaitu
urutan
transmisi dari sender. Pengiriman pesan yang tidak sesuai urutan dianggap gagal ol
eh beberapa aplikasi.
4.2.2 Socket
Komunikasi antar proses terdiri atas transmisi pesan diantara socket pada salah sat
u proses dan socket
lain pada proses lain, seperti yang digambarkan pada gambar di atas. Untuk meneri
ma pesan, socket
harus terhubung dengan local port dan alamat internet computer. Pesan dikirim ke s
uatu alamat
Internet dan port tertentu bisa diterima oleh proses yang socketnya terkait dengan
alamat internet dan
nomor port. Proses bisa menggunakan socket yang sama untuk mengirim dan mene
rima pesan. Proses
bisa menggunakan lebih dari satu port untuk menerima pesan, namun suatu proses
tidak bisa berbagi
port dengan proses lain dalam computer yang sama. Namun ada perkecualian untu
k proses IP multicast.
Sebaliknya berapapun proses bisa mengirimkan pesan ke satu port yang sama. Seti
ap socket terkait dengan protokol khusus, bisa UDP atau TCP.
Java api untuk alamat internet
Java memberikan kelas untuk merepresentasikan alamat internet yaitu InetAddress.
Pengguna
kelas menunjuk pada computer berdasarkan Domain Name Service (DNS). Sebagai
contoh,
instans dari InetAddress yang mengandung alamat internet bisa dibuat dengan cara
memanggil metode static, dengan memberikan hostname DNS sebagai argument.
InetAddress aComputer = InetAddress.getByName(“Bruno.dcs.qmw.ac.uk”)
4.2.3 Komunikasi Datagram UDP
Sebuah datagram yang dikirim oleh UDP ditransmisikan dari proses send ke proses r
eceive tanpa acknowledgement atau coba‐
coba. Jika gagal, pesan bisa tidak diterima. Berikut adalah beberapa
pembahasan mengenai komunikasi datagram:
• Message size
Ukuran pesan harus ditentukan agar bisa menyesuaikan dengan array • Blocking
UDP menggunakan perintah send yang non‐blocking dan perintah receive yang bloc
king • Timeouts
Beberapa proses tidak diperkenankan menunggu terlalu lama, sehingga digunakan t
imeout pada socket untuk membatasi waktunya • Receive from any
Metode ini bisa menerima pesan dari manapun karena asalnya tidak dipertanyakan
Failure Model Failure model pada UDP:
• Ommision failure Ketika pengiriman pesan kadang‐
kadang terhenti begitu saja karena tidak ada sisa tempat • Ordering
Pesan sering terkirim sering keluar dari perintah sender
Penggunaan UDP Pengiriman pesan bisa berasal dari overhead berikut:
1. Kebutuhan untuk menyimpan informasi dari source ke tujuan 2.
Transmisi pesan ekstra 3. Latency pengirim
JAVA API UNTUK Datagram
Java API menyediakan dua kelas untuk datagram: DatagramPacket dan Datagram S
ocket.
Format DatagramPacket terdiri atas:
Array pesan Panjang pesan Alamat internet Nomor port
DatagramSocket terdiri atas metode berikut:
• Send dan receive
Metode ini digunakan untuk mentransmit diagram diantara sepasang socket. •
setSiTimeout Metode ini akan mengeset timeout • connect
metode ini digunakan untuk menghubungkan dengan port dan alamat internet yang
remote.
4.2.4 Komunikasi TCP STREAM Karakteristik dari stream TCP meliputi:
• Ukuran pesan
Aplikasi bisa memilih seberapa banyak data yang ditulis pada sebuah stream data a
tau membacanya. Ukuran pesan bisa sangat kecil maupun sangat besar.
• Status hilang
Protokol TCP menggunakan skema acknowledgement. Ketika sebuah packet terkirim
pihak
penerima akan memberikan acknowledgement atas semua paket yang sudah samp
ai. • Pengaturan Flow
Digunakan untuk mengatur kecepatan TCP protokol dan proses agar tetap bisa coco
k. Ketika salah satu terlalu cepat maka akan diblock. •
Pengurutan dan penggandaan pesan
Setiap pesan yang memiliki identifier yang terasosiasi pada setiap paket IP. Ini berg
una untuk
mendeteksi dan menolak duplikasi dan melakukan pengurutan pesan yang sampai
• Tujuan Pesan
Sepasang proses terkomunikasi akan membuat satu kobeksi sebelum mereka melak
ukan komunikasi lewat stream.
Komunikasi Stream melakukan metode berikut:
• Pencocokan data
Dua proses harus melakukan persetujuan atyas isi data ada sebuah stream. Jika pas
angan proses
tidak berkooperasi dengan benar, maka proses pembacaan bisa terjadi eror ketika
menginterpretasikan data. • Blocking
Data yang dituliskan pada stream disimpan pada antrian pada socket tujuan. Proses
yang
menulis data pada suatu stream akan diblock oleh TCP flow control jika data menga
ntri pada socket melebihi yang bisa ditampung protokolnya. • Thread
Thread akan digunakan ketika berkomunikasi dengan klien baru. Keuntunganmengg
unakan
thread yang berbeda adalah server bisa melakukan blocking ketika menunggu suat
u input tanpa harus mendelay klien lain.
Failure Model
Ketika koneksi terputus, sebuah proses akan diberitahu jika ia berusaha melakukan
read atau write. Pengaruhnya adalah seperti berikut:
•
Proses menggunakan koneksi tidak bisa membedakan antara kesalahan jaringan da
n kesalahan proses pada sisi lain •
Proses yang berkomunikasi tidak bisa mengetahui apakah pesan sebelumnya diteri
ma atau tidak
Kegunaan TCP
Banyak servis yang berjalan dengan koneksi TCP, dengan jumlah port tertentu. Term
asuk protokol berikut:
• HTTP
Hypertext transfer protocol digunakan untuk komunikasi antara browser dan web se
rver
• FTP
File transfer protocol digunakan untuk membuat direktori pada computer remote un
tuk mengakses file dan folder. File ini juga bisa ditransferkan ke computer. • Telnet
Menyediakan akses dengan sesi ke computer remote • SMTP
Simple mail transfer protokol digunakan untuk mengirim mail diantara computer‐
komputer.
Java API untuk STREAMING TCP
Java API menyediakan dua kelas untuk TCP stream yaitu kelas ServerSocket dan Soc
ket.
• Server SOCKET
Digunakan oleh server untuk membuat socket pada sebuah portnya. • SOCKET
Digunakan oleh sepasang proses yang terkoneksi.
4.3 Representasi data eksternal dan marshalling
Ada dua cara untuk computer bertukar data:
•
Nilai diconvert ke dalam format yang berbeda sebelum melakukan transmisi dan dic
onvert ke
format local; jika dua computer diketahui memiliki jenis yang sama, konversi bisa dil
akukan • Nilai yang ditransmisi menggunakan format pengirim
Sebuah standar yang disetujui oleh struktur data dan nilai primitive disebut dengan
representasi data eksternal.
Marshalling adalah proses untuk mengambil koleksi data dan menyusunnya ke dala
m sebuah bentuk
yang bisa dilakukan transmisi. Unmarshallling adalah proses pembongkaran data ke
tika sudah sampai untuk memproduksi sebuah koleksi yang sama pada tujuan.
4.3.1 Representasi data umum pada CORBA
CORBA CDR adalah representasi data yang didefinisikan dengan CORBA 2.0 yang m
erepresentasikan
semua jenis data yang digunakan sebagai argument dan mengembalikan nilai pada
invokasi CORBA. Gambar di bawah ini menjelaskan format pesan CORBA CDR.
4.3.2 Java object Serialization
Serialisasi berarti melakukan flattening obyek atau sekumpulan obyek yang terkone
ksi secara serial.
Sementara itu deserialisasi adalah mengembalikan keasaan obyek dari bentuk seria
lisasinya. Gambar di bawah ini adalah bentuk serialisasi pada Java.
4.3.3 Referensi remote obyek
Sebuah remote obyek reference adalah sebuah identifier untuk remote obyek yang
valid pada
keseluruhan sistem terdistribusi. Remote obyek referencememiliki representasi sepe
rti gambar berikut. Nilai ini harus bersifat unik.
4.4 Komunikasi ClientServer
Bentuk komunikasi didisain untuk mendukung peran dan pertukaran pesan dalam in
teraksi client‐server yang khusus. Pada kasus normal, komunikasi request‐
reply bersifat sinkron karena client memproses
blok hingga reply sampai di server. Komunikasi dapat diandalkan karena reply dari
server berupa acknowledgement ke client. Komunikasi request‐
reply asinkron adalah sebuah alternative yang
mungkin sangat berguna dalam situasi dimana client dapat menerima reply setelah
nya.
Protocol Requestreply
Protocol ini didasari trio komunikasi promitif :doOperation, getRequest, dan sendRep
ly.
Protocol yang akan dibahas di sini adalah protocol yang mendukung komunikasi pad
a RMI
dimana metode RMI ini melewatkan referensi remote objek ke suatu objek yang me
miliki metode untuk diminta dalam request message.
Metode doOperation digunakan pada sisi klien untuk meminta operasi remote. Argu
mennya
menjelaskan metode dan remote objek yang mana yang akan diminta. Hasilnya ad
alah reply
RMI. Dapat diasumsikan bahwa klien yang memanggil doOPeration membungkus ar
gument
dalam byte array dan membuka bungkus hasil dari byte array yang dikembalikan. A
rgument
pertama dari doOperation adalah instans dari kelas RemoteObjectRef yang merepre
sentasikan
referensi untuk remote objek. Kelas ini menyediakan metode untuk mendapatkan i
nternet
address dan port server dari remote objek. Metode doOperation mengirim pesan re
quest ke
server yang memiliki alamat internet dan port yang dijelaskan dalam referensi remo
te objek
reference sebagai argument. Setelah mengirim pesan request, doOperation meman
ggil receive
untuk mendapat pesan reply, dimana ia mengekstrak hasil dan mengembalikan ke
pada
pemanggil. Pemanggil dari doOperation diblok sampai remote objek pada server m
elakukan
operasi yang diminta dan mentransmisinya sebagai pesan reply ke proses klien.
Sementara itu, metode getRequest digunakan di sisi server. Saat server telah mem
anggil
metode pada objek tertentu, server menggunakan sendReply untuk mengirim pesan
reply ke
klien. Saat pesan reply diterima klien, doOperation tidak diblok, dan eksekusi progr
am klien dilanjutkan.
Berikut ini adalah struktur pesan request‐reply
MESSAGETYPE
REQUESTID
OBJECTREFERENCE
METHODID
ARGUMENTS
Filed messageType mengindikasikan apakah pesan merupakan pesan reply atau req
uest. Field
requestId mengandung indentifier pesan. Field yang ketiga adalah referensi remote
objek yang
dibungkus. Field keempat (methodId) adalah indentifier untuk metode yang dipang
gil.
Model Kegagalan Protokol Requestreply
Apabila tiga operasi doOperation, getRequest, sendReply diimplementasikan pada d
atagram
UDP, ketiganya akan mengalami kegagalan komunikasi. Kegagalan tersebut antara
lain :
‐ Ketiganya akan mengalami kegagalan omission (omission failure) ‐
Pesan tidak dijamin terkirim sesuai urutan di pengirim.
‐ Sebagai tambahan, protokol dapat mengalami kegagalan proses. Hal ini dapat
diasumsikan bahwa proses mengalami crash failure.
Untuk mengatasinya, doOperation menggunakan timeout ketika menunggu mendap
atkan
jawaban server. Aksi yang diambil ketika timeout terjadi tergantung jaminan pengiri
man yang ditawarkan.
Timeout : ada beberapa pilihan yang doOperation dapat lakukan setelah terjadi
timeout. Pilihan paling sederhana adalah mengembalikan ke client bahwa operasi
doOperation telah gagal. Akantetapi, ini bukanlah cara yang umum digunakan.
Penanggulangan kemungkinan hilangnya pesan adalah doOperation mengirim pesa
n
request secara berulang hingga ia mendapatkan jawaban atau terjadi delay. Pada
akhirnya, saat doOperation memberikan kembalian, ia akan mengindikasikan ke klie
n melalui eksepsi bahwa tidak ada hasil yang diterima.
Membuang pesan request terduplikasi : apabila tidak ada pesan request yang
ditransmisi ulang, server mungkin menerimanya lebih dari satu kali. Misalnya, serv
er
mungkin menerima pesan request pertama tetapi memerlukan waktu eksekusi lebih
lama dari timeout yang dimiliki klien. Hal ini dapat membuat server mengeksekusi
lebih
dari sekali untuk request yang sama. Untuk menghindarinya, protocol perlu didesai
n untuk mengenali pesan dari klien yang sama.
Menghilangkan pesan reply : apabila server telah mengirim reply ketika ia menerim
a duplikat request, server perlu mengeksekusi operasi lagi untuk mendapat hasil.
Beberapa server dapat mengeksekusi operasi mereka lebih dari sekali dan menerim
a
hasil yang sama tiap waktunya. Sebuah idempotent operation adalah operasi yang
dilakukan berulang dengan hasil sama.
History : istilah history digunakan untuk menunjuk kepada suatu struktur yang me
miliki
rekaman pesan reply yang telah ditransmisikan. Permulaan history memiliki reques
t
indentifier, pesan, dan identifier klien tujuan. Tujuannya adalah untuk mengijinkan
server untuk mentransmisi ulang pesan reply ketika klien memproses request mere
ka.
Masalah yang ditimbulkan oleh history ini adalah biaya memori yang diperlukan terl
alu besar.
Penggunaan Stream TCP untuk Implementasi Protokol RequestReply
Keinginan untuk menghindari pengimplementasian protocol multi‐paket adalah alas
an mengapa memilih penggunaan protocol request‐
reply melalui stream TCP yang mengijinkan argument
dan hasil dengan ukuran berapapun ditransmisi. Secara khusus, Java object serializ
ation adalah
protocol stream yang mengijinkan argument dan hasil dikirim melalui stream antara
klien dan
server, memungkinkan koleksi objek dengan ukuran berapapun ditransmisi secara h
andal. Jadi,
tidak diperlukan transmisi ulang dan penggunaan history. Oleh karena itu, TCP prot
ocol dipilih untuk mengimplemensikan protocol request‐
reply karena protocol ini dapat menyederhanakan implementasi.
HTTP: Contoh Protokol RequestReply
Metode HTTP : setiap request klien menjelaskan nama metode untuk diaplikasikan
ke sumber
pada sever dan URL sumber. Reply memberi report status request. Request dan re
ply
mengandung data sumber, output program sumber yang dijalankan pada server we
b.
Metode yang termasuk dalam HTTP adalah :
GET : meminta sumber dimana URL berfungsi sebagai argument.
HEAD : request ini hampir sama dengan GET tetapi tidak mengembalikan data.
POST : menjelaskan URL dari sumber yang berhubungan dengan data. Prosesnya
tergantung pada fungsi program yang dijelaskan dalam URL. Metode ini didisain un
tuk berhubungan dengan :
‐ Penyediaan blok data untuk proses data‐handling, misalnya servlet atau
program cgi ‐ Memposkan pesan ke bulletin board, mailing list, atau newsgroup ‐
Memperluas database dengan operasi append
PUT : melakuan request bahwa data disimpan dengan URLnya sebagai identifier.
DELETE : server menghapus sumber yang diidentifikasi oleh URL. Server tidak bole
h selalu mengijinkan operasi ini dimana reply mengindikasikan kegagalan.
OPTIONS : server menyediakan client dengan daftar metode.
TRACE : server mengirim kembali pesan request. Metode ini digunakan untuk tujua
n tertentu.
Message Contents : pesan request menjelaskan nama metode, URL atau sumberny
a, versi
protocol, header, dan badan pesan. Berikut ini adalah gambar pesan reply HTTP :
HTTP VERSION
STATUS CODE REASON HEADERS
MESSAGE BODY
HTTP/1.1 200 OK RESOURCE DATA
4.5 Komunikasi Grup
Dalam komunikasi grup ini dikenal multicast operation, yaitu operasi yang mengirim
pesan tunggal dari
proses tunggal ke suatu grup. Terdapat banyak kemungkinan untuk mengadakan ko
munikasi multicast.
Yagn paling sederhana adalah komunikasi grup yang tidak memberikan jaminan uru
tan dan pengiriman pesan.
Pesan multicast menyediakan infrastruktur untuk mengkonstruksi sistem terdistribu
si dengan karakteristik sebagai berikut :
1. Toleransi Fault berdasar services replicated
Replicated service terdiri dari satu grup server. Request client adalah multicast ke s
eluruh anggota grup. Tiap‐
tiap request melakukan operasi yang serupa. Apabila beberapa anggota
gagal, client lain tetap dapat dilayani. 2.
Menemukan discovery server dalam jaringan spontaneous
Pesan multicast digunakan oleh sever dan klien untuk menentukan service discover
y yang
tersedia guna mendaftarkan interface atau melihat interface layanan lainnya dalam
sistem terdistribusi. 3. Performansi yang lebih baik melalui data replikasi
Data direplikasi untuk meningkatkan performansi layanan. Tiap waktu data beruba
h, nilai baru dimulticast ke proses untuk mengatur replica. 4.
Propagasi dari event notifications
Multicast ke grup dapat digunakan untuk memberitahu proses ketika sesuatu terjadi
. Misalnya,
suatu sistem baru mungkin memberitahu user ketika pesan baru telah dikiri ke new
sgroup
tertentu. Sistem Jini menggunakan multicast untuk menginformasikan client tertent
u ketika layanan baru memberi tahu keberadaannya.
4.5.1 IP Multicast—Implementasi dari Komunikasi Grup
IP Multicast
IP multicast dibangun pada bagian atas protocol internet, IP. IP multicast mengijinka
n pengirim
untuk mentransmisi paket IP tunggal ke sekumpulan computer yang membentuk gr
up multicast.
Pengirim tidak mempedulikan identitas tiap penerima dan ukuran grup. Grup multic
ast digolongkan dalam alamat internet kelas D.
Menjadi anggota grup multicast membuat suatu computer untuk dapat menerima p
aket IP yang
dikirim ke grup. Keanggotaan pada grup multicast bersifat dinamis. Suatu compute
r dapat bergabung atau meninggalkan grup.
Model Kegagalan dari Multicast Diagram
Multicast datagram melalui IP multicast memiliki karakteristik kegagalan seperti dat
agram UDP.
Akibatnya, pesan tidak dijamin terkirim ke anggota grup tertentu. Beberapa anggot
a grup saja
yang mungkin dapat menerimanya. Hal ini disebut unreliable multicast. Multicast y
ang reliable dibahas di bab 11.
Java API pada IP Multicast
Java API menyediakan interface datagram untuk multicast IP melalui kelas Multicast
Socket yang
merupakan subkelas dari DatagramSocket dengan kemampuan tambahan mampu b
ergabung ke
grup multicast. Kelas MulticastSocket menyediakan dua alternative konstruktor, me
ngijinkan
socket diciptakan untuk menggunakan local port tertentu atau local port manapun s
ecara
bebas. Suatu proses dapat bergabung ke grup multicast melalui alamat multicast d
engan
memanggil metode joinGroup milik multicast socket. Suatu proses dapat meninggal
kan grup tertentu dengan memanggil metode leaveGroup milik multicast soket.
4.5.2 Kehandalan dan Urutan Multicast
Berikut adalah beberapa contoh efek dari Reliabillity dan Ordering
1. Toleransi Fault berdasar services replicated
Suatu aplikasi multicast memerlukan bahwa seluruh anggota atau tidak satupun har
us menerima tiap request untuk melakukan operasi –
bila salah satunya tidak mendapat
request, akan terjadi inkonsistensi. Pada sebagian besar kasus, seluruh anggota gru
p harus menerima pesan request dengan urutan yang sama seluruhnya. 2.
Menemukan discovery server dalam jaringan spontaneous
Misalnya suatu proses ingin meletakkan discovery server multicast request pada int
erval
periodis tertentu selama waktu setelah discovery server starts up. Jini mengunakan
IP multicast dalam protokol multicast request untuk menemukan discovery server.
3. Performansi yang lebih baik melalui data replikasi
Apabila terjadi dimana data replikasi,bukan operasi pada data, didistribusikan melal
ui pesan
multicast. Resiko kehilangan pesan dan inconsistensi urutan akan tergantung pada
metode
replikasi dan tingkat kepentingan seluruh replica. Misalnnya replica dari newsgroup
tidak selamanya konsisten satu sama lain pada satu waktu—
pesan mungkin muncul dalam rurutan yang berbeda. 4.
Propagasi dari event notifications
Aplikasi khusus menentukan kualitas yang diperlukan dari multicast. Misalnya Jini
announcement service menginformasikan pihak‐pihak berkaitan tentang service ya
ng
tersedia melalui IP multicast untuk membuat pengumuman pada frekuensi interval
yang sering. a