Komunikasi Antar Proses

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 kemudian  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 asinkron. Pada  komunikasi sinkron, proses send dan receive akan melakukan sinkronisasi pada setiap  pengiriman pesan. Dalam keadaan ini kedua proses merupakan operasi blocking, yaitu 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. Proses 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 mendukung 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 time.  Dengan ini servis bisa direlokasi namun tidak sepenuhnya ‘migrasi’ (berpindah  sementara sistem masih running).  Sistem operasi menyediakan identifier untuk tujuan pesan, memetakannya ke dalam  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 utuh 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 oleh beberapa  aplikasi. 

4.2.2 Socket 

  Komunikasi antar proses terdiri atas transmisi pesan diantara socket pada salah satu proses dan socket  lain pada proses lain, seperti yang digambarkan pada gambar di atas. Untuk menerima pesan, socket  harus terhubung dengan local port dan alamat internet computer. Pesan dikirim ke suatu 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 menerima 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 untuk proses IP multicast.  Sebaliknya berapapun proses bisa mengirimkan pesan ke satu port yang sama. Setiap 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 receive 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 blocking  Timeouts  Beberapa proses tidak diperkenankan menunggu terlalu lama, sehingga digunakan timeout 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 Socket.   Format DatagramPacket terdiri atas:  Array pesan  Panjang pesan  DatagramSocket terdiri atas metode berikut:  • • •

Alamat internet 

Nomor port 

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 atau  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 sampai.  Pengaturan Flow  Digunakan untuk mengatur kecepatan TCP protokol dan proses agar tetap bisa cocok. Ketika  salah satu terlalu cepat maka akan diblock.  Pengurutan dan penggandaan pesan  Setiap pesan yang memiliki identifier yang terasosiasi pada setiap paket IP. Ini berguna untuk  mendeteksi dan menolak duplikasi dan melakukan pengurutan pesan yang sampai   Tujuan Pesan  Sepasang proses terkomunikasi akan membuat satu kobeksi sebelum mereka melakukan  komunikasi lewat stream. 

Komunikasi Stream melakukan metode berikut:  •

•

•

Pencocokan data  Dua proses harus melakukan persetujuan atyas isi data ada sebuah stream. Jika pasangan 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 mengantri pada  socket melebihi yang bisa ditampung protokolnya.  Thread  Thread akan digunakan ketika berkomunikasi dengan klien baru. Keuntunganmenggunakan   thread yang berbeda adalah server bisa melakukan blocking ketika menunggu suatu 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 dan  kesalahan proses pada sisi lain  Proses yang berkomunikasi tidak bisa mengetahui apakah pesan sebelumnya diterima  atau tidak 

Kegunaan TCP  Banyak servis yang berjalan dengan koneksi TCP, dengan jumlah port tertentu. Termasuk  protokol berikut:  •

HTTP  Hypertext transfer protocol digunakan untuk komunikasi antara browser dan web server 

•

• •

FTP  File transfer protocol digunakan untuk membuat direktori pada computer remote untuk  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 Socket.  • •

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 diconvert ke  format local; jika dua computer diketahui memiliki jenis yang sama, konversi bisa dilakukan  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 dalam sebuah bentuk  yang bisa dilakukan transmisi. Unmarshallling adalah proses pembongkaran data ketika 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 merepresentasikan  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 terkoneksi secara serial.  Sementara itu deserialisasi adalah mengembalikan keasaan obyek dari bentuk serialisasinya. 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 seperti gambar berikut.  Nilai ini harus bersifat unik. 

   

4.4 Komunikasi Client­Server  Bentuk komunikasi didisain untuk mendukung peran dan pertukaran pesan dalam interaksi 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 setelahnya.   Protocol Request­reply 

Protocol ini didasari trio komunikasi promitif :doOperation, getRequest, dan sendReply.   Protocol yang akan dibahas di sini adalah protocol yang mendukung komunikasi pada RMI  dimana metode RMI ini melewatkan referensi remote objek ke suatu objek yang memiliki  metode untuk diminta dalam request message.  Metode doOperation digunakan pada sisi klien untuk meminta operasi remote.  Argumennya  menjelaskan metode dan remote objek yang mana yang akan diminta.  Hasilnya adalah reply  RMI.  Dapat diasumsikan bahwa klien yang memanggil doOPeration membungkus argument  dalam byte array dan membuka bungkus hasil dari byte array yang dikembalikan.  Argument  pertama dari doOperation adalah instans dari kelas RemoteObjectRef yang merepresentasikan  referensi untuk remote objek.  Kelas ini menyediakan metode untuk mendapatkan internet  address dan port server dari remote objek.  Metode doOperation mengirim pesan request ke  server yang memiliki alamat internet dan port yang dijelaskan dalam referensi remote objek  reference sebagai argument.  Setelah mengirim pesan request, doOperation memanggil receive  untuk mendapat pesan reply, dimana ia mengekstrak  hasil dan mengembalikan kepada  pemanggil.  Pemanggil dari doOperation diblok sampai remote objek pada server melakukan  operasi yang diminta dan mentransmisinya sebagai pesan reply ke proses klien.  Sementara itu, metode getRequest digunakan di sisi server.  Saat server telah memanggil  metode pada objek tertentu, server menggunakan sendReply untuk mengirim pesan reply ke  klien.  Saat pesan reply diterima klien, doOperation tidak diblok, dan eksekusi program klien  dilanjutkan.  Berikut ini adalah struktur pesan request‐reply  MESSAGETYPE  REQUESTID  OBJECTREFERENCE  METHODID  ARGUMENTS  Filed messageType mengindikasikan apakah pesan merupakan pesan reply atau request.  Field  requestId mengandung indentifier pesan.  Field yang ketiga adalah referensi remote objek yang  dibungkus.  Field keempat (methodId) adalah indentifier untuk metode yang dipanggil.  Model Kegagalan Protokol Request­reply  Apabila tiga operasi doOperation, getRequest, sendReply diimplementasikan pada datagram  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 mendapatkan  jawaban server.  Aksi yang diambil ketika timeout terjadi tergantung jaminan pengiriman 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 pesan  request secara berulang hingga ia mendapatkan jawaban atau terjadi delay.  Pada  akhirnya, saat doOperation memberikan kembalian, ia akan mengindikasikan ke klien  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, server  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 didesain  untuk mengenali pesan dari klien yang sama.  Menghilangkan pesan reply  : apabila server telah mengirim reply ketika ia menerima  duplikat request, server perlu mengeksekusi operasi lagi untuk mendapat hasil.   Beberapa server dapat mengeksekusi operasi mereka lebih dari sekali dan menerima  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 memiliki  rekaman pesan reply yang telah ditransmisikan.  Permulaan history memiliki request  indentifier, pesan, dan identifier klien tujuan.  Tujuannya adalah untuk mengijinkan  server untuk mentransmisi ulang pesan reply ketika klien memproses request mereka.   Masalah yang ditimbulkan oleh history ini adalah biaya memori yang diperlukan terlalu  besar.   Penggunaan Stream TCP untuk Implementasi Protokol Request­Reply  Keinginan untuk menghindari pengimplementasian protocol multi‐paket adalah alasan mengapa  memilih penggunaan protocol request‐reply melalui stream TCP yang mengijinkan argument  dan hasil dengan ukuran berapapun ditransmisi.  Secara khusus, Java object serialization adalah  protocol stream yang mengijinkan argument dan hasil dikirim melalui stream antara klien dan  server, memungkinkan koleksi objek dengan ukuran berapapun ditransmisi secara handal.  Jadi,  tidak diperlukan transmisi ulang dan penggunaan history.  Oleh karena itu, TCP protocol dipilih  untuk mengimplemensikan protocol request‐reply karena protocol ini dapat menyederhanakan  implementasi.  

HTTP: Contoh Protokol Request­Reply  Metode HTTP  : setiap request klien  menjelaskan nama metode untuk diaplikasikan ke sumber  pada sever dan URL sumber.  Reply memberi report status request.  Request dan reply  mengandung data sumber, output program sumber yang dijalankan pada server web.    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 untuk  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 boleh  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 tujuan  tertentu.    Message Contents :  pesan request menjelaskan nama metode, URL atau sumbernya, versi  protocol, header, dan badan pesan.  Berikut ini adalah gambar pesan reply HTTP :  HTTP  VERSION 

STATUS  CODE 

HTTP/1.1 

200 

REASON 

OK 

HEADERS 

MESSAGE  BODY 

 

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 komunikasi multicast.  

Yagn paling sederhana adalah komunikasi grup yang tidak memberikan jaminan urutan dan pengiriman  pesan.  Pesan multicast menyediakan infrastruktur untuk mengkonstruksi sistem terdistribusi dengan  karakteristik sebagai berikut :  1. Toleransi Fault berdasar services replicated  Replicated service terdiri dari satu grup server.  Request client adalah multicast ke seluruh  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 discovery 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 berubah, 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 newsgroup  tertentu.  Sistem Jini menggunakan multicast untuk menginformasikan client tertentu 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 mengijinkan pengirim  untuk mentransmisi paket IP tunggal ke sekumpulan computer yang membentuk grup multicast.   Pengirim tidak mempedulikan identitas tiap penerima dan ukuran grup.  Grup multicast   digolongkan dalam alamat internet kelas D.  Menjadi anggota grup multicast membuat suatu computer untuk dapat menerima paket IP yang  dikirim ke grup.  Keanggotaan pada grup multicast bersifat dinamis.  Suatu computer dapat  bergabung atau meninggalkan grup.  Model Kegagalan dari Multicast Diagram  Multicast datagram melalui IP multicast memiliki karakteristik kegagalan seperti datagram UDP.   Akibatnya, pesan tidak dijamin terkirim ke anggota grup tertentu.  Beberapa anggota grup saja  yang mungkin dapat menerimanya.  Hal ini disebut unreliable multicast.  Multicast yang reliable  dibahas di bab 11.  Java API pada IP Multicast  Java API menyediakan interface datagram untuk multicast IP melalui kelas MulticastSocket yang  merupakan subkelas dari DatagramSocket dengan kemampuan tambahan mampu bergabung ke 

grup multicast.  Kelas MulticastSocket menyediakan dua alternative konstruktor, mengijinkan  socket diciptakan untuk menggunakan local port tertentu atau local port manapun secara  bebas.  Suatu proses dapat bergabung ke grup multicast melalui alamat multicast dengan  memanggil metode joinGroup milik multicast socket.  Suatu proses dapat meninggalkan 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 harus  menerima tiap request untuk melakukan operasi –bila salah satunya tidak mendapat  request, akan terjadi inkonsistensi.  Pada sebagian besar kasus, seluruh anggota grup 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 interval  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 melalui 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 yang  tersedia melalui IP multicast untuk membuat pengumuman pada frekuensi interval yang  sering.