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). •
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,
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
• 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
• 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
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
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
‐ 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.
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.
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.
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.
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
