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.
4.2.2 Socket 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. 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 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 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 computerkomputer. 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 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 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.