IMPLEMENTASI BIDIRECTIONAL HTTP PADA APLIKASI CHAT BERBASIS WEB MENGGUNAKAN PROTOKOL BAYEUX
FITRA ADITYA PRADANA
DEPARTEMEN ILMU KOMPUTER FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM INSTITUT PERTANIAN BOGOR BOGOR 2014
PERNYATAAN MENGENAI SKRIPSI DAN SUMBER INFORMASI SERTA PELIMPAHAN HAK CIPTA Dengan ini saya menyatakan bahwa skripsi berjudul Implementasi Bidirectional HTTP pada Aplikasi Chat Berbasis Web Menggunakan Protokol Bayeux adalah benar karya saya dengan arahan dari komisi pembimbing dan belum diajukan dalam bentuk apa pun kepada perguruan tinggi mana pun. Sumber informasi yang berasal atau dikutip dari karya yang diterbitkan maupun tidak diterbitkan dari penulis lain telah disebutkan dalam teks dan dicantumkan dalam Daftar Pustaka di bagian akhir skripsi ini. Dengan ini saya melimpahkan hak cipta dari karya tulis saya kepada Institut Pertanian Bogor. Bogor, Agustus 2014 Fitra Aditya Pradana NIM G64080013
ABSTRAK FITRA ADITYA PRADANA. Implementasi Bidirectional HTTP pada Aplikasi Chat Berbasis Web Menggunakan Protokol Bayeux. Dibimbing oleh SRI WAHJUNI. Teknologi web awalnya diciptakan berdasarkan prinsip REST (representational state transfer) dimana interaksi antara client dan server terjadi secara synchronous melalui mekanisme request dan response. Namun dalam perkembangannya, protokol HTTP yang menjadi jalur komunikasi web memungkinkan interaksi antara client dan server terjadi secara bidirectional dan asynchronous. Hal ini dikarenakan adanya mekanisme server push. Salah satu protokol yang mengimplementasikan server push adalah protokol bayeux. Protokol bayeux memiliki beberapa keunggulan dibandingkan dengan protokol lainnya, di antaranya low latency dan dapat bekerja dengan baik pada client yang berada di balik proxy. Protokol bayeux dapat dimanfaatkan ke dalam aplikasi berbasis web yang membutuhkan komunikasi real time, salah satunya adalah aplikasi chat. Dalam penelitian ini bidirectional HTTP diimplementasikan ke dalam aplikasi chat sederhana berbasis web menggunakan protokol bayeux dengan menyediakan fitur group chat dan private chat. Kata kunci: REST, bidirectional HTTP, protokol bayeux, aplikasi chat
ABSTRACT FITRA ADITYA PRADANA. Bidirectional HTTP Implementation on WebBased Chat Application using Bayeux Protocol. Supervised by SRI WAHJUNI. Web technology was originally created based on REST (representational state transfer) principles, where the interaction between client and server occurs through a synchronous request and response mechanism. However, the development of web technology cause interaction between client and server can occurs bidirectionally and asynchronously. This is enabled by server push mechanism. Bayeux protocol is an example of server push implementation. The main advantages of bayeux are its low latency and works well behind proxy. Bayeux can be implemented into serveral web based application that requires real time communication, such as chat application. The objective of this research is how to implement bidirectional HTTP into web based chat application using bayeux protocol by providing group chat and private chat function. Keywords: REST, bidirectional HTTP, bayeux protocol, chat application
IMPLEMENTASI BIDIRECTIONAL HTTP PADA APLIKASI CHAT BERBASIS WEB MENGGUNAKAN PROTOKOL BAYEUX
FITRA ADITYA PRADANA
Skripsi sebagai salah satu syarat untuk memperoleh gelar Sarjana Komputer pada Departemen Ilmu Komputer
DEPARTEMEN ILMU KOMPUTER FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM INSTITUT PERTANIAN BOGOR BOGOR 2014
Penguji: 1 Dr Eng Heru Sucoko, SSi, MT 2 Endang Purnama Giri, SKom, MKom
Judul Skripsi : Implementasi Bidirectional HTTP pada Aplikasi Chat Berbasis Web Menggunakan Protokol Bayeux Nama : Fitra Aditya Pradana NIM : G64080013
Disetujui oleh
Dr Ir Sri Wahjuni, MT Pembimbing
Diketahui oleh
Dr Ir Agus Buwono, MSi, MKom Ketua Departemen
Tanggal Lulus:
PRAKATA Alhamdulillah, puji dan syukur penulis ucapkan kepada Allah subhanallahu wa ta’ala, atas segala rahmat dan karunia-Nya sehingga penelitian yang berjudul Implementasi Bidirectional HTTP pada Aplikasi Chat Berbasis Web Menggunakan Protokol Bayeux ini berhasil diselesaikan. Terima kasih penulis ucapkan kepada seluruh pihak yang telah mambantu dan terlibat dalam proses penyelesaian penelitian ini, di antaranya Ibu Dr Ir Sri Wahjuni, MT selaku dosen pembimbing, juga kepada Bapak Endang Purnama Giri, SKom, MKom dan Bapak Dr Eng Heru Sukoco, SSi, MT selaku dosen penguji. Ucapan terima kasih juga penulis haturkan kepada keluarga besar di Pamekasan, Ayah Arief Syuhada, Mama Ribut Yuliarti, Bude Evi Rufaida, dan seluruh saudara di sana. Tak lupa pula kepada Annisa Anastasia, istri tercinta yang selalu menemani dan mengingatkan untuk segera menyelesaikan penelitian ini, juga bidadari kecilku yang kini bersiap untuk hadir di dunia. Terima kasih juga kepada seluruh rekan-rekan Ilkom 45, GASISMA, KPLI Bogor, Tim Pengembang BlankOn, serta seluruh pihak-pihak yang tidak bisa disebutkan satupersatu. Akhir kata, penulis berharap penelitian ini tidak hanya berhenti sampai di sini, tetapi terus dikembangkan sehingga dapat memberikan manfaat bagi masyarakat.
Bogor, Agustus 2014 Fitra Aditya Pradana
DAFTAR ISI DAFTAR TABEL
viii
DAFTAR GAMBAR
viii
PENDAHULUAN
1
Latar Belakang
1
Tujuan Penelitian
1
Ruang Lingkup Penelitian
1
TINJAUAN PUSTAKA
2
Server Push
2
Bayeux
4
METODE PENELITIAN
6
Pendefinisian Masalah
6
Analisis Sistem
7
Perancangan Sistem
7
Implementasi
7
Pemeliharaan
8
HASIL DAN PEMBAHASAN
8
Analisis Protokol Bayeux
8
Analisis Sistem
10
Perancangan Sistem
13
Implementasi
16
Pemeliharaan
22
SIMPULAN DAN SARAN
22
Simpulan
22
Saran
23
DAFTAR PUSTAKA
23
LAMPIRAN
25
RIWAYAT HIDUP
40
DAFTAR TABEL
1 2 3 4 5
Keterangan tampilan antarmuka chat Skenario pengujian Hasil pengujian Pengujian tingkat keberhasilan pengiriman pesan Rata-rata jeda waktu pengiriman masing-masing pesan
19 19 20 21 21
DAFTAR GAMBAR 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Periodic polling, long polling, dan streaming (Kuhn et al. 2008) Mekanisme HTTP transport pada protokol bayeux (Russel et al. 2007) Alur publish/subscribe (Sun Microsystem 2002) Format channel pada Bayeux (Russel et al. 2007) Hirarki channel dan wildcard channel (Russel et al. 2007) Contoh pesan subscribe request (Russel et al. 2007) Notasi karakter yang sesuai dengan BNF (Russel et al. 2007) Tahapan berdasarkan the system life cycle Format pesan pada saat subscribe request dalam bentuk objek JSON dan notasi BNF Format pesan pada proses publish Contoh penggunaan field ext untuk tujuan autentikasi Struktur data pada aplikasi chat milik Kuhn (2008) Skema public channel dan private channel Mekanisme publish / subscribe pada group channel Mekanisme publish / subscribe pada private channel Regular expression untuk username Alur pendaftaran user Alur autentikasi pada saat subscribe Alur autentikasi pada saat publish pesan Alur subscribe private channel dan group channel Alur publish pesan pada group channel dan private channel Tampilan command prompt pada Windows 8 ketika server dijalankan Halaman depan aplikasi chat Tampilan halaman chat Grafik waktu pengiriman pesan pada jeda pengiriman 500 ms menggunakan jaringan IPB
3 4 5 5 5 6 6 7 9 9 10 11 11 12 12 13 13 14 14 15 16 17 18 18 22
DAFTAR LAMPIRAN 1 2
Message fields pada protokol bayeux Message definition pada protokol bayeux
25 26
3 4 5 6
ERD pada aplikasi chat yang dikembangkan File program Tangkapan layar aplikasi chat Tabel histogram hasil pengujian
29 30 32 37
PENDAHULUAN Latar Belakang Perkembangan teknologi internet kian hari kian pesat terutama pada teknologi web. Teknologi web yang berkembang salah satunya adalah protokol HTTP, yang menjadi jalur komunikasi web, saat ini telah mendukung komunikasi dua arah atau yang disebut bidirectional HTTP. Bidirectional HTTP merupakan suatu mekanisme dimana client dan server dapat berkomunikasi dalam dua arah secara real time. Bidirectional HTTP dapat terjadi karena adanya mekanisme server-side push. Pemanfaatan server-side push banyak diadopsi oleh beberapa situs seperti situs lelang eBay 1 , di mana pengunjung tidak perlu melakukan refresh halaman untuk mendapatkan informasi penawar tertinggi. Pemanfaatan lainnya adalah penggunaan server-side push dalam aplikasi chat berbasis web (Mesbah dan Deursen 2008). Bjorgulfsson (2008) dan Kuhn et al. (2008) dalam penelitiannya berhasil mengimplementasikan server-side push ke dalam aplikasi chat menggunakan protokol bayeux. Protokol bayeux dikembangkan terutama untuk web, sehingga sesuai dengan karakteristik dan batasan web browser, web server, serta protokol HTTP (Kuhn et al. 2008). Selain itu juga protokol bayeux mampu bekerja dengan baik di belakang proxy serta mudah untuk diimplementasikan (Bjorgulfsson 2008). Terdapat perbedaan antara penelitian yang dilakukan oleh kedua penelitian sebelumnya. Kuhn et al. (2008) berhasil mengimplementasikan bayeux ke dalam aplikasi chat berbasis web, sedangkan Bjorgulfsson (2008) berhasil mengimplementasikan bayeux ke dalam aplikasi chat menggunakan framework Greenfoot. Namun demikian kedua penelitian tersebut hanya menyediakan fungsi group chat, dan tidak menyediakan fungsi private chat. Dari kedua penelitian yang telah dilakukan sebelumnya, penelitian kali ini akan mencoba untuk mengimplementasikan protokol bayeux ke dalam sebuah aplikasi chat berbasis web. Pemilihan aplikasi chat berbasis web ini sesuai dengan karakteristik bayeux yang bekerja pada protokol HTTP. Perbedaan dengan dua penelitian sebelumnya adalah adanya penambahan fungsi private chat. Tujuan Penelitian Penelitian ini bertujuan untuk mengimplementasikan protokol bayeux ke dalam sebuah aplikasi chat berbasis web sehingga dapat digunakan pada lintas web browser. Perbedaan penelitian kali ini dengan dua penelitian sebelumnya yang dilakukan oleh Kuhn et al. (2008) dan Bjorgulfsson (2008) adalah penambahan fungsi private chat. Ruang Lingkup Penelitian Aplikasi yang dikembangkan pada penelitian kali ini menggunakan protokol bayeux. Fungsi yang dikembangkan dalam aplikasi ini sesuai dengan fungsi yang 1
http://ebay.com
2 dijelaskan oleh Kuhn et al. (2008) dalam penelitiannya, yaitu pemilihan username, log in ke dalam aplikasi, pembuatan channel, join channel, dan pengiriman pesan ke channel. Uji coba dilakukan dengan menggunakan fasilitas public cloud dan jaringan internet, serta diakses menggunakan web browser Google Chrome, Mozilla Firefox, dan Internet Explorer. Pemilihan ketiga web browser di atas berdasarkan popularitas penggunaan web browser2 yang disadur dari situs StatCounter3.
TINJAUAN PUSTAKA Server Push HTTP (RFC 2616) merupakan protokol yang bekerja berdasarkan prinsip request / response. Protokol ini memiliki entitas client, proxy, dan server. Client bertugas mengirimkan HTTP request kepada server. Server bertugas untuk menerima request yang dikirimkan oleh client dan kemudian mengirim balik response atas request tersebut. Sedangkan proxy bertindak sebagai penghubung antara client ke server, dan begitu pula sebaliknya. Semua prosedur di atas terjadi secara synchronous (IETF 2011). Batasan utama dari protokol HTTP adalah prinsip bahwa client harus melakukan inisiasi terlabih dahulu untuk mendapatkan informasi dari server (disebut dengan pull). Prinsip ini mengakibatkaan server tidak memungkinkan untuk mengirim informasi kepada client tanpa adanya inisiasi dari client (disebut dengan push), meskipun hal ini sangat dibutuhkan pada beberapa aplikasi yang bergantung pada informasi real time. Beberapa aplikasi menggunakan AJAX dan melakukan pull secara berkala dengan interval waktu tertentu (periodic polling) untuk mendapatkan informasi terbaru (Kuhn et al. 2008). Namun teknik ini memiliki kekurangan yaitu penggunaan bandwith yang kurang efisien dan informasi yang didapatkan tidak terjadi secara real time karena adanya latency (Sampathkumar 2010). Untuk mengatasi permasalahan di atas, dikembangkanlah beberapa metode server-side push, yang memungkinkan server mengirimkan informasi kepada client secara real time. Bozdag et al. (2007) menyebutkan bahwa terdapat dua metode yang dapat digunakan dalam implementasi server-side push, yaitu HTTP streaming dan long polling. HTTP Streaming HTTP streaming merupakan metode yang paling sederhana dan sudah diperkenalkan sejak tahun 1992. Terdapat dua metode streaming yang umum digunakan, yaitu page straming dan service streaming. Page streaming bekerja dengan cara membuat server melakukan looping secara terus menerus terhadap request yang diterima. Cara ini mengakibatkan koneksi antar client dan server terus terbuka. Server akan mendeteksi setiap state dan event yang terjadi dan mengirimkan setiap informasi terbaru kepada client. 2 3
Periode Juni 2013 sampai dengan Juni 2014 http://gs.statcounter.com
3 Sedangkan client (dalam hal ini adalah web browser) harus memastikan bahwa setiap informasi yang ditampilkan adalah informasi terbaru. Service streaming bekerja mirip dengan page streaming. Yang menjadi perbedaan adalah service streaming bekerja secara background menggunakan XMLHttpRequest. Long polling Long polling dikenal juga dengan istilah asynchronous polling. Pada long polling setiap request akan ditahan oleh server dan dibiarkan terbuka selama waktu tertentu (default 45 detik). Apabila selama waktu yang telah ditentukan tidak ada event yang terjadi, server akan memberikan response timeout dan meminta client untuk melakukan request ulang. Sedangkan apabila terdapat event yang terjadi, server akan langsung mengirimkan informasi terbaru kepada client dan meminta client untuk melakukan request ulang. Perbedaan antara periodic polling, long polling, dan streaming dapat dilihat pada Gambar 1.
Gambar 1 Periodic polling, long polling, dan streaming (Kuhn et al. 2008) Dari ketiga metode transport yang disebutkan di atas, streaming memiliki low latency yang paling rendah dari ketiganya. Namun demikian, penggunaan sumber daya yang digunakan oleh streaming pada server maupun client lebih besar dalam hal konsumsi CPU dan memori dibandingkan dengan long polling.
4 Bjorgulfsson (2008) dalam penelitiannya lebih memilih long polling untuk digunakan dalam implementasi aplikasi chat, karena long polling berjalan dengan baik di belakang proxy. Bayeux Bayeux merupakan salah satu protokol yang mengimplementasikan bidirectional HTTP dengan menggunakan teknik long polling. Bayeux sendiri dikembangkan dengan tujuan untuk mempermudah proses routing pesan dari client ke server, dan begitu pula sebaliknya. Protokol ini memungkinkan terjadinya pengiriman pesan dari client ke server, server ke client, dan client ke client (melalui perantara server). Bayeux bersifat terbuka, sehingga pengembang bebas untuk mengembangkan atau memodifikasinya sesuai dengan kebutuhan (Russel et al. 2007). Komunikasi pada protokol bayeux terjadi berdasarkan mekanisme request / response antara client dan server seperti yang digambarkan pada Gambar 2. Pada komunikasi tersebut, entitas yang berperan di antaranya bayeux client (BC), useragent (U), proxy (P), origin server (O), dan bayeux server (BS). Komunikasi diawali dengan request yang dilakukan oleh BC melalui U kepada O yang kemudian diteruskan BS. Adanya kalanya komunikasi terjadi melalui proxy (P). Saat melakukan request, BC mengirimkan pesan (M) berupa event (E) yang dienkapsulasi menjadi M0(E). Setelah M0(E) diterima oleh BS, BS kemudian membalas request tersebut dengan response M1 yang dikirimkan kepada BS. BC ---------- U ---------- P -----------| --M0(E)--> | | | | ---HTTP request(M0(E))--> | | | | | | | | <---HTTP response(M1)---| <---M1--- | | | | |
O ---------- BS | | | | | --M0(E)--> | | <---M1---- | | | | | | |
Gambar 2 Mekanisme HTTP transport pada protokol bayeux (Russel et al. 2007) Bayeux bekerja berdasarkan prinsip publish / subscribe. Agar antar client dapat berkomunikasi secara dua arah, client yang tersambung ke server bayeux harus melakukan publish / subscribe pada topik yang sama. Topik ini biasa disebut dengan channel. Alur publish / subscribe dijelaskan oleh Gambar 3. Mekanisme publish / subscribe dilakukan berdasarkan mekanisme request / response seperti yang telah dijelaskan pada Gambar 2.
5
Gambar 3 Alur publish/subscribe (Sun Microsystem 2002) Channel direpresentasikan dengan absolute path pada URI segment tanpa disertai dengan parameter. Format channel pada bayeux dijelaskan pada Gambar 4 yang ditulis dalam notasi BNF. Terdapat reserved channel yang tidak boleh digunakan dalam implementasi, yaitu channel ‘/meta/’ dan channel ‘/service/’. Channel pada bayeux juga bersifat hirarki, dimana masing-masing segment mewakili satu tingkat. Selain itu juga, terdapat wildcard channel yang memungkinkan sebuah channel bertindak sebagai channel yang memiliki tingkat di bawahnya. Aturan hirarki dan wildcard channel digambarkan pada Gambar 5.
:= ‘/’ channel_segments := * (‘/’ ) :=
Gambar 4 Format channel pada bayeux (Russel et al. 2007) /foo /foo/bar /foo/bar/x /foo/* /foo/**
= = = = =
top level channel 1st level channel 2nd level channel single wildcard /foo/bar multiple wildcard /foo/bar, /foo/bar/x
Gambar 5 Hirarki channel dan wildcard channel (Russel et al. 2007) Untuk saling berkomunikasi, baik antara client-server maupun server-client, pesan yang dipertukarkan dalam protokol bayeux harus berbentuk JSON (javascript object notation). Objek JSON tersebut terdiri dari beberapa field yang masing-masing memiliki parameter dan nilai. Terdapat enam belas jenis field yang digunakan pada protokol bayeux sebagaimana tertera pada Lampiran 1. Selain itu juga, penulisan objek JSON tersebut harus sesuai dengan notasi BNF (backus naur form). Gambar 6 merupakan contoh dari format pesan pada saat melakukan subscribe request, sedangkan Gambar 7 menjelaskan notasi karakter yang digunakan oleh protokol bayeux yang sesuai dengan notasi BNF.
6 [ { "channel": "/meta/subscribe", "clientId": "Un1q31d3nt1f13r", "subscription": "/foo", "successful": true, "error": "" } ]
Gambar 6 Contoh pesan subscribe request (Russel et al. 2007) := | := 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' | 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' | 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' := 'A' | 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' | 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | 'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z' := '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' := | <mark> := '-' | '_' | '!' | '~' | '(' | ')' | '$' | '@' <string> := * ( | <mark> | ' ' | '/' | '*' | '.') := ( | <mark>) * ( | <mark>) := * ()
Gambar 7 Notasi karakter yang sesuai dengan BNF (Russel et al. 2007)
METODE PENELITIAN Penelitian ini dilakukan melalui lima proses tahapan dengan menggunakan konsep The System Life Cycle, yaitu pendefinisian masalah, analisis sistem, perancangan sistem, implementasi, dan pemeliharaan (Mc Leod 1993). Alur dari kelima proses tersebut digambarkan melalui Gambar 8. Pendefinisian Masalah Protokol bayeux hanya mengatur bagaimana sebuah protokol HTTP dapat digunakan untuk berkomunikasi secara dua arah melalui channel yang telah ditentukan baik dengan melakukan proses publish ataupun subscribe. Bjorgulfsson (2008) dan Kuhn et al. (2008) sebelumnya telah berhasil mengimplementasikan protokol bayeux ke dalam aplikasi chat. Namun aplikasi chat yang dihasilkan dari penelitian tersebut masih terbatas pada fungsi group chat.
7
Gambar 8 Tahapan berdasarkan the system life cycle Analisis Sistem Protokol yang digunakan dalam pengembangan aplikasi chat pada penelitian ini menggunakan adalah bayeux. Analisis terhadap protokol bayeux sangat diperlukan untuk mengetahui bagaimana proses pertukaran pesan antara client dan server, khususnya pada proses publish dan subscribe. Tahapan analisis terhadap kedua penelitian yang telah dilakukan sebelumnya juga dibutuhkan untuk menjawab masalah yang muncul dari tahapan pendefinisian masalah di atas. Perancangan Sistem Aplikasi yang akan dikembangkan pada penelitian kali ini diharapkan mampu menyediakan baik fungsi group chat maupun private chat. Detil mengenai fungsi yang akan dikembangkan berdasarkan penelitian yang telah dilakukan sebelumnya oleh Kuhn et al. (2008) yaitu pemilihan username, log in ke dalam aplikasi, pembuatan channel, join channel, dan pengiriman pesan ke channel. Implementasi Lingkungan implementasi yang digunakan pada penelitian ini dibagi menjadi ke dalam dua fase, yaitu fase pengembangan dan fase produksi. Fase pengembangan Pada fase ini implementasi dilakukan dengan menggunakan mesin lokal (localhost) dengan spesifikasi sebagai berikut:
8 1 Perangkat keras: a Prosesor AMD Quad Core A6-1450M 1.0 GHz b Memori RAM 6 GB c Media penyimpanan 500 GB 2 Perangkat lunak: a Sistem operasi Windows 8 b Editor teks Geany 1.23.1 c Bahasa pemrograman Javascript dengan menggunakan framework Node.js 0.10.24 pada sisi server d MongoDB 2.4.9 sebagai basis data e Faye sebagai modul Bayeux pada Node.js f HTML5 dan framework Twitter Bootstrap 3.1.1 untuk antarmuka client g Git sebagai control versioning system Fase produksi Pada fase produksi, aplikasi yang telah diimplementasikan pada fase pengembangan akan diletakkan pada public cloud agar dapat dilakukan uji coba. Public cloud yang digunakan memiliki spesifikasi sebagai berikut: Openshift Cloud Service Sistem operasi Red Hat Enterprise Memori 512 MB dengan kapasitas penyimpanan 1 GB Web server Apache 2.2.22 Node.js 0.10 Pemeliharaan Hasil dari penelitian ini diharapkan akan terus dikembangkan baik dari sisi fitur maupun fungsionalitas. Pemeliharaan dilakukan dengan cara membuka kode sumber dari hasil penelitian pada public repository agar pengembang lain dapat melakukan review dan memberikan saran terhadap peningkatan kinerja sistem. Kode sumber dari hasil penelitian ini akan dirilis dengan lisensi terbuka, dalam hal ini MIT, sehingga pengembang lain dapat menggunakan serta mengembangkannya lebih lanjut.
HASIL DAN PEMBAHASAN Analisis Protokol Bayeux Russel et al. (2007) menjelaskan bahwa protokol bayeux bekerja berdasarkan mekanisme publish / subscribe. Kedua mekanisme tersebut dilakukan dengan cara mengirimkan pesan request melalui metode HTTP POST dari client ke server. Apabila request tersebut berhasil, server akan mengirimkan pesan response balik dari server ke client. Proses subscribe dimulai dengan mengirimkan pesan subscribe request. Pesan tersebut harus berbentuk JSON yang berisi beberapa field di dalamnya. Pada subscribe request, field yang wajib disertakan di antaranya adalah channel,
9 clientId, serta subscription. Field channel berisi channel kemana pesan akan dikirimkan, clientId berisi unique id yang didapatkan masing-masing client setelah berhasil melakukan handshake, dan subscription yang berisi channel kemana client akan melakukan subscribe. Sebagai contoh, Gambar 9 menunjukkan pesan dalam bentuk JSON dan BNF ketika sebuah client dengan clientId ‘123abc’ yang ingin melakukan subscribe pada channel ‘/worldcup’. JSON: [ { "channel": "/meta/subscribe", "clientId": "123abc", "subscription": "/worldcup" }
] BNF: <message> <subscription>
:= := := :=
| | <subscription> '/' * ('/' ) '/' * ('/' )
Gambar 9 Format pesan pada saat subscribe request dalam bentuk objek JSON dan notasi BNF Apabila proses subscribe request berhasil, server akan memberikan response yang juga dalam bentuk JSON. Setelah itu client akan melakukan inisiasi koneksi long polling dengan server. Dengan demikian dapat kita simpulkan bahwa subscribe request sebenarnya merupakan long polling request. Proses publish dilakukan dengan mengirimkan pesan publish request melalui HTTP POST dari client ke server. Sama seperti subscribe request, pesan pada publish request juga harus berbentuk JSON, namun dengan field yang sedikit berbeda di dalamnya. Field yang dibutuhkan pada saat melakukan publish request adalah channel yang merupakan channel tujuan kemana pesan akan di-publish, clientId, serta data yang berisi pesan yang hendak di-publish. Gambar 10 menunjukkan format pesan dalam bentuk JSON dan BNF pada saat melakukan publish pesan. JSON: [ { "channel": "/worldcup", "clientId": "123abc", "data": "Hello world!" } ] BNF: <message>
:= := := :=
| | '/' * ('/' ) <string>
Gambar 10 Format pesan pada proses publish
10 Daftar lengkap dari format pesan yang terdapat pada protokol bayeux dapat dilihat pada Lampiran 2. Bayeux menyediakan field tambahan yang bisa disertakan dalam pesan yang dipertukarkan, yaitu field ext. Field ini bersifat fleksibel dan memiliki format JSON juga. Dengan field ini, pengembang yang ingin melakukan implementasi menggunakan protokol bayeux bebas untuk membuat field baru yang diinginkan, selama field tersebut berada di dalam field ext. Sebagai contoh, Gambar 11 menunjukkan penggunaan field ext yang berisi field username dan password untuk tujuan autentikasi pesan. [ { "channel": "/worldcup", "clientId": "123abc", "data": "Hello world!", "ext": {"username": "abc", "password": "123"} } ]
Gambar 11 Contoh penggunaan field ext untuk tujuan autentikasi Pada dasarnya protokol bayeux tidak memiliki mekanisme khusus mengenai autentikasi pada client maupun channel. Namun demikian Russel et al. (2007) memberikan tiga alternatif yang dapat digunakan untuk mengatasi kebutuhan autentikasi pada implementasi bayeux, yaitu: 1 Tidak menggunakan autentikasi. 2 Autentikasi dasar pada teknologi web (cookie atau session). 3 Autentikasi pada proses publish maupun subscribe dengan memanfaatkan kolom ext pada pesan. Analisis Sistem Aplikasi chat yang dibuat oleh Kuhn et al. (2008) dikembangkan menggunakan protokol bayeux. Aplikasi ini dibangun dengan menggunakan bahasa pemrograman JavaScript. Fungsi utama dari aplikasi tersebut di yaitu pemilihan username, login, pembuatan channel, join channel, dan pengiriman pesan. Pada aplikasi tersebut terdapat tiga entitas utama yang menjadi inti dari sebuah aplikasi chatting, yaitu channel, user, dan message. Channel dan user digunakan untuk mengidentifikasi siapa yang mengirimkan pesan dan kemana pesan tersebut dikirimkan. Struktur data dari ketiga entitas tersebut dijelaskan pada Gambar 12.
11
Gambar 12 Struktur data pada aplikasi chat milik Kuhn (2008) Pembagian channel Kuhn et al. (2008) dan Bjorgulfsson (2008) dalam penelitiannya hanya menjelaskan bagaimana pengiriman pesan terjadi di dalam group. Tidak ada mekanisme pengiriman pesan seacara private dan semua komunikasi terjadi pada group channel. Implementasi private chat dapat dilakukan dengan melakukan pembagian channel. Pembagian channel dapat dilakukan dengan mengelompokkan channel ke dalam dua kelompok, yaitu group channel dan private channel. Pembagian channel ini mengadopsi pembagian channel pada RFC 2811 mengenai channel managament protokol IRC (internet relay chat). Group channel merupakan channel dimana semua client bebas untuk melakukan publish dan subscribe. Private channel merupakan channel dimana hanya client tertentu yang dapat melakukan subscribe. Agar memudahkan dalam identifikasi dan implementasi, kedua kelompok channel tersebut digambarkan pada skema yang tertera pada Gambar 13. Group channel Private channel
= /group/ = /private/<private_channel>
Gambar 13 Skema public channel dan private channel Bagaimana client berkomunikasi dengan client lainnya Berdasarkan pembagian channel di atas, dapat ditentukan bagaimana client berkomunikasi dengan client lainnya, yaitu melalui group chat dan private chat. Group chat terjadi pada group channel. Komunikasi pada group channel terjadi secara publik, dimana pesan yang di-publish oleh suatu client akan di-broadcast ke seluruh client yang melakukan subscribe pada channel yang sama. Seluruh client dapat melakukan subscribe pada seluruh group channel yang ada. Tidak ada mekanisme khusus pada group channel ini. Gambar 14 menunjukkan bagaimana sebuah pesan yang di-publish oleh suatu client dan client lainnya menerima pesan tersebut.
12
Gambar 14 Mekanisme publish / subscribe pada group channel Private chat terjadi pada private channel. Mekanisme publish pada private chat mengacu kepada message routing pada electronic mail. Masing-masing client memiliki tepat satu private channel, dimana hanya client tersebut yang dapat melakukan subscribe pada channel miliknya. Ketika suatu client ingin mengirimkan pesan secara private kepada client lainnya, pengiriman dapat dilakukan dengan cara publish pesan ke pada channel client tujuan. Pertukaran pesan melalui private channel ini mengharuskan client mengetahui channel dari client tujuan sebelum mengirimkan (publish) pesan. Informasi mengenai client yang lainnya disampaikan oleh server ketika client baru bergabung pada channel yang sama. Gambar 15 menunjukkan bagaimana dua client saling berkomunikasi melalui private channel-nya masing-masing.
Gambar 15 Mekanisme publish / subscribe pada private channel Autentikasi client Setiap client ditandai dengan sebuah username sebagai pengenal antar-client. Username ini harus didaftarkan terlebih dahulu agar dapat digunakan. Agar dapat berkomunikasi dengan client lainnya, baik pada group channel maupun private channel, suatu client harus melakukan autentikasi terlebih dahulu. Autentikasi
13 dilakukan berdasarkan username yang digunakan. Selain itu juga, autentikasi ini bertujuan agar hanya client yang tepat yang mampu melakukan subscribe pada private channel miliknya. Autentikasi dilakukan pada saat client melakukan subscribe channel dan publish pesan. Perancangan Sistem Pemilihan Username Pada sistem yang akan dikembangkan, fungsi pemilihan username direpresentasikan ke dalam sebuah proses pendaftaran (registrasi). Setiap client (user) diwakili oleh satu username. Selain berfungsi sebagai identifier, username juga berfungsi sebagai private channel segment. Penamaan username mengikuti aturan penamaan channel. Namun agar lebih mudah dimengerti, karakter yang digunakan pada username dibatasi hanya pada karakter alphanumeric dengan panjang karakter antara lima sampai enam belas karakter. Format username yang dapat digunakan dijelaskan oleh regular expression seperti Gambar 16. Username
= ^[a-zA-Z0-9]{4,16}$
Gambar 16 Regular expression untuk username Sebelum dapat digunakan, user harus mendaftarkan username-nya terlebih dahulu. Selain username, informasi yang dibutuhkan dalam proses pendaftaran adalah password yang akan digunakan. Data mengenai user kemudian akan disimpan ke dalam basis data. Alur pendaftaran user dijelaskan pada Gambar 17.
Gambar 17 Alur pendaftaran user Log in Sistem yang akan dikembangkan menggunakan mekanisme autentikasi publish maupun subscribe sesuai dengan alternatif yang diberikan oleh Russel (2007). Mekanisme ini dilakukan dengan menambahkan dua kolom pada pesan yang akan dikirimkan baik pada subscribe maupun pada saat publish. Dua kolom
14 tersebut masing-masing berisi username dan password. Dengan cara ini, apabila username dan password yang diberikan tidak sesuai, user tidak akan dapat melakukan subscribe maupun publish pesan. Alur dari autentikasi ini dijelaskan pada Gambar 18 dan Gambar 19.
Gambar 18 Alur autentikasi pada saat subscribe
Gambar 19 Alur autentikasi pada saat publish pesan Pembuatan Channel Berdasarkan analisis sistem yang telah dilakukan di atas, channel dibagi menjadi dua, yaitu private channel dan group channel. Private channel merupakan channel pribadi yang dimiliki masing-masing user yang akan otomatis
15 dibuat ketika user melakukan pendaftaran usernam. Sedangkan untuk group channel, channel dibuat ketika user melakukan subscribe pada channel tersebut. Join Channel Mekanisme subscribe channel dibagi menjadi dua, yaitu subscribe pada private channel dan subscribe pada group channel. Pada private channel, subscribe hanya dapat dilakukan apabila user telah terautentikasi, dalam hal ini username dan password yang diberikan sesuai. Apabila tidak sesuai, user tidak dapat melakukan subscribe pada channel miliknya. Sedangkan pada group channel, subscribe hanya dapat dilakukan apabila user telah berhasil melakukan subscribe pada private channel miliknya. Setiap user bisa melakukan subscribe pada lebih dari satu group channel. Mekanisme subscribe pada private channel dan group channel digambarkan pada Gambar 20.
Gambar 20 Alur subscribe private channel dan group channel Saat user telah berhasil melakukan subscribe pada suatu group channel, server akan memberikan notifikasi kepada seluruh user lainnya yang berada dalam group channel yang sama. Notifikasi ini bertujuan untuk memberitahukan
16 tentang kehadiran user tersebut. Notifikasi juga akan diberikan ketika terdapat user yang meninggalkan channel. Server juga akan menyimpan siapa saja yang terhubung ke dalam masing-masing group channel ke dalam basis data. Hal ini bertujuan agar suatu user dapat mengambil informasi siapa saja yang sedang melakukan subscribe pada group channel yang sama dengan dirinya pada saat itu. Lampiran 3 menggambarkan ERD dari basis data yang digunakan pada penelitian ini. Publish Channel Sama halnya dengan subscribe channel, publish pesan juga terdiri dari publish pada private channel dan publish pada grchanneoup channel. Proses publish hanya bisa dilakukan setelah client telah log in ke dalam sistem sebagaimana digambar pada alur Gambar 21.
Gambar 21 Alur publish pesan pada group channel dan private channel Implementasi Implementasi dalam penelitian ini dibagi menjadi ke dalam dua bagian, yaitu implementasi server dan client. Server Program untuk server terdiri dari empat buah file yaitu package.json, config.js, model.js, dan server.js. File package.json merupakan file yang wajib ada pada sebuah aplikasi berbasis Node.js. File ini berisi meta data mengenai aplikasi yang dibuat serta dependensi yang dibutuhkan untuk menjalankan aplikasi. Dengan adanya file ini, proses instalasi aplikasi pada server akan lebih mudah. File kedua yaitu config.js. File ini berisi baris konfigurasi yang akan digunakan server agar dapat berjalan dengan baik, di antaranya alamat host, port
17 dimana server akan menjalankan servicenya, dan path URI dimana bayeux akan bekerja. Sedangkan file ketiga yaitu model.js yang berfungsi untuk melakukan abstraksi basis data yang digunakan, dalam hal ini adalah sqlite3. File server.js merupakan file utama dan memegang tugas penting, di antaranya inisiasi web server, routing URI, autentikasi user, dan routing pesan. File tersebut berisi baris perintah untuk melakukan inisiasi modul faye sebagai implementor bayeux, inisiasi basis data, inisiasi server, integrasi bayeux ke dalam server, dan menjalankan server di port yang sudah ditentukan. Agar dapat menampilkan halaman web yang menjadi antarmuka client, server harus mampu menangani routing URI. Dalam penelitian ini, server hanya mampu mengenali URI segment ‘/’, ‘/signup’, ‘/signin’, ‘/chat’, dan ‘/userlist’. Setiap URI segment yang dipanggil oleh client, server akan memanggil fungsi yang telah ditentukan. Fungsi autentikasi berada pada file server.js. Fungsi autentikasi dilakukan dengan cara membandingkan nilai field username dan password dengan nilai yang sudah tersimpan di dalam basis data. Apabila terjadi kesalahan yang diakibatkan oleh tidak sesuainya username dan password, server akan memberikan nilai error pada user. Seluruh potongan kode dari file config.js dan server.js dapat dilihat di Lampiran 4. Untuk menjalankan aplikasi pada komputer, file server.js harus dipanggil melalui command prompt atau terminal seperti yang terlihat pada Gambar 22. Perintah untuk memanggilnya adalah node server.js.
Gambar 22 Tampilan command prompt pada Windows 8 ketika server dijalankan Client Program untuk client berupa halaman web yang dijalankan melalui web server. Perancangan halaman web untuk client menggunakan framework Twitter Bootstrap. Terdapat dua file utama untuk menangani halaman client ini, yaitu index.html dan chat.html. File index.html merupakan halaman depan dari client Di sini terdapat berbagai menu yang bisa digunakan, yaitu menu ‘Masuk’ untuk login dan menu ‘Daftar’ untuk registrasi user. Tampilan untuk halaman depan client dapat dilihat pada Gambar 23 dan untuk halaman chat dapat dilihat pada
18 Gambar 24. Keterangan dari tampilan Gambar 23 dan Gambar 24 dijelaskan pada Tabel 1. .
Gambar 23 Halaman depan aplikasi chat
Gambar 24 Tampilan halaman chat
19 Tabel 1 Keterangan tampilan antarmuka chat No 1 2 3 4 5 6 7 8 9 10 11
Keterangan Tautan beranda (home) Tautan tentang panduan penggunaan aplikasi Tautan kode sumber aplikasi yang diletakkan di layanan GitHub Tombol masuk (login) Tombol daftar (registrasi) Tombol join (bergabung) ke group channel Tombol keluar (logout) Daftar tab chat Daftar user yang melakukan subscribe ke group channel Daftar chat Kolom input chat
Skenario Pengujian Pengujian dilakukan dengan menggunakan satu buah komputer dengan sistem operasi Windows 8 dan tiga buah web browser yang berbeda, masingmasing adalah Google Chrome, Mozilla Firefox, dan Internet Explorer. Aplikasi chat yang telah dikembangkan diletakkan pada fasilitas public cloud, sehingga membutuhkan sambungan internet untuk mengaksesnya. Alamat aplikasi chat tersebut adalah http://bayeux.html5.web.id/. Tahapan pengujian dijelaskan pada Tabel 2. Tabel 2 Skenario pengujian No 1
2
3 4 5 6
7
8
Skenario Registrasi user pada masing-masing web browser dengan username yang berbeda. - Alice - Barbara - Charlie Ketiga user yang telah dibuat sebelumnya melakukan subscribe pada group Ilkom dan IPB Alice mengirimkan pesan bertuliskan ‘Hai’ pada group Ilkom. Barbara mengirimkan pesan bertuliskan ‘Hai juga’ pada group Ilkom. Charlie mengirimkan pesan bertuliskan ‘Halo’ pada group IPB. Alice memulai private chat dengan Barbara dan mengirimkan pesan ‘Apa kabar?’. Barbara membalas pesan Alice melalui private chat dan mengirimkan pesan ‘Kabarku baik’. Charlie meninggalkan aplikasi chat dengan cara log out.
Hasil yang diharapkan Proses registrasi berhasil, dan user akan otomatis log in.
Proses subscribe berhasil, muncul tab masing-masing group, serta muncul notifikasi bahwa masing-masing user bergabung ke dalam group tersebut. Semua user mendapatkan pesan tersebut pada tab group Ilkom. Semua user mendapatkan pesan tersebut pada tab group Ilkom. Semua user mendapatkan pesan tersebut pada tab group IPB. Hanya Barbara yang menerima pesan tersebut pada tab baru yang otomatis muncul. Hanya Alice yang menerima pesan tersebut. Alice dan Barbara menerima notifikasi bahwa Charlie meninggalkan group Ilkom dan group IPB.
20 Pengujian Pada Jaringan Publik Sesuai dengan skenario yang telah dibuat, pengujian dilakukan dengan menggunakan tiga buah web browser yang berbeda pada satu komputer yang sama. Adapun hasil pengujian berdasarkan pada skenario yang telah dibuat dijabarkan pada Tabel 3. Tabel 3 Hasil pengujian No 1
2
3
4
5
6
7
8
Skenario Registrasi user pada masingmasing web browser dengan username yang berbeda. - Alice - Barbara - Charlie Ketiga user yang telah dibuat sebelumnya melakukan subscribe pada group Ilkom dan IPB
Alice mengirimkan pesan bertuliskan ‘Hai’ pada group Ilkom. Barbara mengirimkan pesan bertuliskan ‘Hai juga’ pada group Ilkom. Charlie mengirimkan pesan bertuliskan ‘Halo’ pada group IPB. Alice memulai private chat dengan Barbara dan mengirimkan pesan ‘Apa kabar?’. Barbara membalas pesan Alice melalui private chat dan mengirimkan pesan ‘Kabarku baik’. Charlie meninggalkan aplikasi chat dengan cara log out.
Hasil yang diharapkan Proses registrasi berhasil, dan user akan otomatis log in.
Sesuai / Tidak Sesuai (Lampiran 5)
Proses subscribe berhasil, muncul tab masing-masing group, serta muncul notifikasi bahwa masingmasing user bergabung ke dalam group tersebut. Semua user mendapatkan pesan tersebut pada tab group Ilkom. Semua user mendapatkan pesan tersebut pada tab group Ilkom. Semua user mendapatkan pesan tersebut pada tab group IPB. Hanya Barbara yang menerima pesan tersebut pada tab baru yang otomatis muncul. Hanya Alice yang menerima pesan tersebut.
Sesuai (Lampiran 5)
Alice dan Barbara menerima notifikasi bahwa Charlie meninggalkan group Ilkom dan group IPB.
Sesuai (Lampiran 5)
Sesuai (Lampiran 5) Sesuai (Lampiran 5) Sesuai (Lampiran 5) Sesuai (Lampiran 5)
Sesuai (Lampiran 5)
Dari delapan poin pengujian di atas, seluruhnya berhasil dan sesuai dengan hasil yang diharapkan. Pengujian juga dilakukan untuk mengetahui tingkat keberhasilan pengiriman pesan yang dilakukan oleh aplikasi chat yang berhasil dikembangkan. Pengujian dilakukan dengan mengirimkan 100 pesan secara berurutan dengan jeda waktu antar pesan yang berbeda, yaitu 500 ms, 1000 ms, 1500 ms, dan 2000 ms. Pengujian ini dilakukan dengan menggunakan dua buah koneksi internet yang berbeda, yaitu jaringan IPB dan Telkom Speedy dengan bandwith 3 Mbps, sehingga total pesan yang dikirimkan berjumlah 800 pesan. Waktu pengujian dilakukan pada pukul 12.30 WIB sampai dengan 14.00 WIB
21 untuk jaringan IPB dan pukul 15.00 WIB sampai dengan 16.30 WIB untuk jaringan Telkom Speedy. Tabel 4 Pengujian tingkat keberhasilan pengiriman pesan Write delay (miliseconds )
Pengujia n ke-1 (%)
500 ms 1000 ms 1500 ms 2000 ms
98 99 99 99
Jaringan IPB Pengujia Pengujia n ke-2 n ke-3 (%) (%)
98 99 99 99
98 99 99 99
Telkom Speedy 3Mbps Pengujia Pengujia Pengujia n ke-1 n ke-2 n ke-3 (%) (%) (%)
98 99 99 99
98 99 99 99
98 99 99 99
Rata -rata
98 99 99 99
Tabel 4 menunjukkan tingkat keberhasilan pengiriman pesan berdasarkan jeda waktu pengiriman antar pesan. Terlihat tidak ada perbedaan yang signifikan antara keempat rentang waktu tersebut. Tabel 5 Rata-rata jeda waktu pengiriman masing-masing pesan Write delay (miliseconds) 500 ms 1000 ms 1500 ms 2000 ms
Jaringan IPB
Telkom Speedy 3Mbps
Rata-rata
1387.878 996.478 937.249 959.946
1545.102 1027.290 1024.485 1000.313
1466.490 1011.884 980.867 980.130
Tabel 5 menunjukkan rata-rata waktu yang dibutuhkan setiap pesan untuk sampai ke user lainnya. Terdapat jeda waktu yang cukup besar. Jeda waktu yang cukup besar ini salah satunya dipengaruhi oleh kecepatan internet yang digunakan pada saat pengujian. Gambar 25 menggambarkan rata-rata waktu pengiriman pesan pada jeda pengiriman tiap 500 milidetik menggunakan jaringan IPB. Data ditampilkan dalam bentuk grafik CDF. Data yang digunakan pada Gambar 25 tersedia pada Lampiran 6.
22 120.00% 100.00%
Frequency
80.00% 60.00%
Percobaan 1 Percobaan 2
40.00%
Percobaan 3
20.00%
847 1347 1847 2347 2847 3347 3847 4347 4847 5347 5847 6347 6847 7347 7847 More
0.00%
Waktu Pengiriman (ms)
Gambar 25 Grafik waktu pengiriman pesan pada jeda pengiriman 500ms menggunakan jaringan IPB Pemeliharaan Agar dapat terus dikembangkan, kode sumber dari penelitian ini diletakkan pada public repository dengan menggunakan layanan GitHub. Repository tersebut dapat diakses melalui alamat https://github.com/fitraditya/roompy. Kode sumber dari penelitian ini dirilis menggunakan lisensi MIT, sehingga pengembang lain bebas memanfaatkannya.
SIMPULAN DAN SARAN Simpulan Dari penelitian yang telah dilakukan, dapat diambil kesimpulan, yaitu: 1 Protokol bayeux dapat digunakan dengan baik pada pengembangan aplikasi chat. Hal ini didasari kemampuannya dalam melakukan routing pesan baik pada group channel dan private channel. 2 Implementasi fungsi pemilihan username, log in ke dalam aplikasi, pembuatan channel, join channel, dan pengiriman pesan ke channel berjalan baik pada penelitian ini. 3 Notifikasi ketika user join maupun log out, berhasil dikirimkan oleh server kepada user lainnya.
23 4
5
Tingkat keberhasilan pengiriman pesan pada aplikasi yang dikembangkan mencapai 98% pada interval pesan 500 milidetik. Sedangkan untuk interval di atas 1000 milidetik, tingkat keberhasilan mencapai 99%. Rata-rata delay pengiriman pesan pada interval 500 milidetik mencapai 1,4 detik. Semakin besar interval pengiriman pesan, semakin kecil waktu delaynya. Saran
Penelitian ini masih terbatas dan bersifat sederhana. Untuk itu dalam pengembangan ke tahap selanjutnya, khususnya dalam pengembangan aplikasi chat, ada beberapa saran yang dapat dilakukan. Di antaranya: 1 Rancangan aplikasi pada sisi client yang mendukung mobile platform. 2 Notifikasi yang lebih lengkap, seperti apakah pesan berhasil dikirimkan atau diterima. 3 Alternatif protokol lainnya yang mendukung bidirectional HTTP.
DAFTAR PUSTAKA Bjorgulfsson B. 2006. Greenfoot networking support [disertasi]. Canterbury (UK): University of Kent. Bozdag E, Mesbah A, Van Deursen A. 2007. A comparison of push and pull techniques for AJAX. Di dalam: 9th IEEE International Workshop on Web Site Evolution, WSE 2007; 2007 Okt 5-6; Paris, Perancis. Washington (US): IEEE. hlm 15-22. [IETF] Internet Engineering Task Force. 2011. RFC 6202 - Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP. [diunduh 2014 Maret 8]. Tersedia pada: http://tools.ietf.org/html/rfc6202. Kuhn E, Riemer J, Mordinyl R, Lechner L. 2008. Integration of XVSM spaces with the web to meet the challenging interaction demands in pervasive scenarios. Ubiquitous Computing and Communication Journal (UbiCC). 3(2008). McLeod R Jr. 1993. Management Information System: A Study of ComputerBased Information System. Ed Ke-5. New York (US): MacMillan. Mesbah A, Van Deursen A. 2008. A component- and push-based architectural style for AJAX applications. Journal of Systems and Software. 81(12): 21942209. Russell A, Wilkins G, Davis D, Nesbitt M. 2007. The Bayeux Specification: Bayeux Protocol – Bayeux 1.0.0. [diunduh 2014 Maret 8]. Tersedia dari: http://svn.cometd.org/ trunk/bayeux/bayeux.html. Sampathkumar PK. 2010. Implementing Web messaging: Connect Ajax clients to near-real-time data with Web Sphere Application Server Community Edition. [diunduh 2014 Maret 8]. Tersedia dari: http://www.ibm.com/developerworks/websphere/techjournal/1008_ sampathkumar/ 1008_sampathkumar.html.
24 [Sun Microsystems]. 2002. JavaTM Message Service Tutorial. [diunduh 2014 Maret 30]. Tersedia dari: http://docs.oracle.com/javaee/1.3/jms/tutorial/1_3_1fcs/doc/basics.html.
25 Lampiran 1 Message fields pada protokol bayeux Message fields pada protokol bayeux Field channel
Keterangan Field ini berisi tujuan kemana pesan akan dikirimkan baik dari client maupun server. Setiap pesan yang dikirimkan, wajib memiliki field ini. version Field ini menandakan versi dari protokol Bayeux yang digunakan. Field ini wajib disertakan pada channel ‘/meta/handshake’. minimumVersion Sama seperti field version. Field ini berisi minimum versi yang digunakan oleh client / server. supportedConnectionTypes Field ini berisi metode yang dapat digunakan oleh HTTP transport. Field ini harus disertakan pada saat handshake request. clientId Field ini merupakan unique id dari client yang diberikan oleh server. Field ini wajib disertakan di setiap pesan yang dikirimkan, kecuali pada saat proses saat handshake request. advice Field ini berisi metode yang disarankan oleh server kepada client dalam melakukan komunikasi. connectionType Field ini merupakan field yang wajib diisi pada saat client melakukan connect request. Field ini berisi metode apa yang akan digunakan pada saat client berkomunikasi dengan server. id Field ini merupakan field yang wajib digunakan pada seluruh proses request yang dilakukan oleh client. Nilai dari field Id ini diberikan ketika client menerima connect request dari server. timestamp Berisi nilai waktu dalam format GMT. Field ini bersifat optional. data Field ini berisi pesan yang dikirimkan client pada saat melakukan publish. Field ini berbentuk JSON. connectionId Deprecated, hanya digunakan pada saat pengembangan protokol bayeux. successful Field ini bertipe boolean. Field ini disertakan pada saat server mengirimkan response kepada client. eubscription Field ini berisi channel tujuan kemana client akan melakukan subscribe. error Field ini bertipe boolean. Field ini disertakan pada saat server mengirimkan response kepada client. ext Field ini merupakan field tambahan yang bisa digunakan secara bebas dalam implementasinya. Field ini berbentuk JSON. json-comment-filtered Deprecated, hanya digunakan pada saat pengembangan protokol bayeux.
26 Lampiran 2 Message definition pada protokol bayeux [ { "channel": "/meta/handshake", "version": "1.0", "minimumVersion": "1.0beta", "supportedConnectionTypes": ["long-polling", "callback-polling", "iframe"] } ]
Handshake request [ { "channel": "/meta/handshake", "version": "1.0", "minimumVersion": "1.0beta", "supportedConnectionTypes": ["long-polling","callback-polling"], "clientId": "Un1q31d3nt1f13r", "successful": true, "authSuccessful": true, "advice": { "reconnect": "retry" } } ]
Successful handshake response [ { "channel": "/meta/handshake", "version": "1.0", "minimumVersion": "1.0beta", "supportedConnectionTypes": ["long-polling","callback-polling"], "successful": false, "error": "Authentication failed", "advice": { "reconnect": "none" } } ]
Unsuccessful handshake response [ { "channel": "/meta/connect", "clientId": "Un1q31d3nt1f13r", "connectionType": "long-polling" } ]
Connect request [ { "channel": "/meta/connect", "successful": true, "error": "", "clientId": "Un1q31d3nt1f13r", "timestamp": "12:00:00 1970", "advice": { "reconnect": "retry" } } ]
Successful connect response
27 Lanjutan [ { "channel": "/meta/disconnect", "clientId": "Un1q31d3nt1f13r"
} ]
Disconnect request [ { "channel": "/meta/disconnect", "clientId": "Un1q31d3nt1f13r", "successful": true } ]
Successful disconnect response [ { "channel": "/meta/subscribe", "clientId": "Un1q31d3nt1f13r", "subscription": "/foo/**" } ]
Subscribe request [ { "channel": "/meta/subscribe", "clientId": "Un1q31d3nt1f13r", "subscription": "/foo/**", "successful": true, "error": "" } ]
Successful subscribe response [ { "channel": "/meta/subscribe", "clientId": "Un1q31d3nt1f13r", "subscription": "/bar/baz", "successful": false, "error": "403:/bar/baz:Permission Denied" } ]
Failed subscribe response [ { "channel": "/meta/unsubscribe", "clientId": "Un1q31d3nt1f13r", "subscription": "/foo/**" } ]
Unsubscribe request
28 Lanjutan [ { "channel": "/meta/unsubscribe", "clientId": "Un1q31d3nt1f13r", "subscription": "/foo/**", "successful": true, "error": "" } ]
Successful unsubscribe response [ { "channel": "/some/channel", "clientId": "Un1q31d3nt1f13r", "data": "some application string or JSON encoded object", "id": "some unique message id" } ]
Publish request [ { "channel": "/some/channel", "successful": true, "id": "some unique message id" } ]
Successful publish response
29 Lampiran 3 ERD pada aplikasi chat yang dikembangkan
ERD aplikasi Roompy chat
30 Lampiran 4 File program { "name": "bayeux-chat", "version": "0.1.0", "description": "Simple chat application using node.js and faye", "author": "Fitra Aditya ", "repository": { "url": "https://github.com/fitraditya/bayeux-chat" }, "engines": { "node": ">=0.10.28" }, "dependencies": { "faye": ">=1.0.1", "sqlite3": ">=2.2.3", "mime": ">=1.2.11" }, "license": "MIT" }
File package.json … var bayeux = new faye.NodeAdapter({mount: config.path, timeout: 45}); … var db = new model(); … // Handle requests var server = http.createServer(function(request, response) { … }); … bayex.attach(server); server.listen(config.port, config.ip); …
Potongan kode pada file server.js … bayeux.addExtension({ incoming: function(message, callback) { var username = ''; var password = ''; … db.signin(username, password, function(error, result) { if (result) { //none } else { message.error = 'System Error: Account not authorized'; } }); … } });
Fungsi autentikasi pada file server.js
31 … // Handle requests var server = http.createServer(function(request, response) { var url_parts = url.parse(request.url); // Routes switch(url_parts.pathname) { case '/': display_page('/index.html', request, response); break; case '/signup': handle_signup(url_parts.pathname, request, response); break; case '/signin': handle_signin(url_parts.pathname, request, response); break; case '/chat': display_page('/chat.html', request, response); break; case '/userlist': handle_userlist(url_parts.pathname, request, response); break; default: display_page(url_parts.pathname, request, response); } return; … }); …
Fungsi routing URI pada server.js
32
Lampiran 5 Tangkapan layar aplikasi chat
Tampilan halaman depan menggunakan browser Google Chrome
Tampilan halaman depan menggunakan browser Mozilla Firefox
33 Lanjutan
Tampilan halaman depan menggunakan browser Internet Explorer
Tampilan halaman chat setelah user berhasil log in (user Alice browser Chrome)
34 Lanjutan
Tampilan ketika user berhasil melakukan subscribe pada group channel. Muncul notifikasi tentang siapa saja yang baru bergabung (user Alice browser Chrome)
Tampilan ketika user Alice mengirimkan pesan 'Hai' pada group Ilkom (user Barbara browser Firefox)
35 Lanjutan
Tampilan ketika user Barbara mengirimkan pesan 'Hai juga' pada group Ilkom (user Charlie browser Internet Explorer)
Tampilan ketika user Charlie mengirimkan pesan 'Halo' pada group IPB (user Alice browser Chrome)
36 Lanjutan
Tampilan ketika user Alice mengirimkan pesan 'Apa Kabar?' kepada Barbara secara private (user Barbara browser Firefox)
Tampilan ketika user Barbara membalas pesan Alice secara private (user Alice browser Chrome)
37 Lanjutan
Tampilan ketika user Charlie log out (user Barbara browser Firefox)
38 Lampiran 6 Tabel histogram hasil pengujian Histogram hasil pengujian berdasarkan waktu pengiriman pesan menggunakan Jaringan IPB Jaringan IPB 1 847 1347 1847 2347 2847 3347 3847 4347 4847 5347 5847 6347 6847 7347 7847
F 0 48 47 2 0 1 0 0 0 0 0 0 0 0 0
C 0.00% 48.98% 96.94% 98.98% 98.98% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
500 ms 2 F 0 46 51 1 0 0 0 0 0 0 0 0 0 0 0
C 0.00% 46.94% 98.98% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
Keterangan: - F: Frequency - C: Cumulative - 1: Pengulangan ke-1 - 2: Pengulangan ke-2 - 3: Pengulangan ke-3
3 F 0 42 49 4 3 0 0 0 0 0 0 0 0 0 0
C 0.00% 42.86% 92.86% 96.94% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
F 0 93 5 1 0 0 0 0 0 0 0 0 0 0 0
1
1000 ms 2
C 0.00% 93.94% 98.99% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
F 0 91 6 1 1 0 0 0 0 0 0 0 0 0 0
C 0.00% 91.92% 97.98% 98.99% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
3 F 0 84 14 1 0 0 0 0 0 0 0 0 0 0 0
C 0.00% 84.85% 98.99% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
F 1 97 0 1 0 0 0 0 0 0 0 0 0 0 0
1
1500 ms 2
C 1.01% 98.99% 98.99% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
F 0 98 0 1 0 0 0 0 0 0 0 0 0 0 0
C 0.00% 98.99% 98.99% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
3 F 0 95 2 0 1 1 0 0 0 0 0 0 0 0 0
C 0.00% 95.96% 97.98% 97.98% 98.99% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
1 F 0 98 0 1 0 0 0 0 0 0 0 0 0 0 0
C 0.00% 98.99% 98.99% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
2000 ms 2 F 0 91 2 1 3 0 1 1 0 0 0 0 0 0 0
C 0.00% 91.92% 93.94% 94.95% 97.98% 98.98% 98.99% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
3 F 0 98 0 1 0 0 0 0 0 0 0 0 0 0 0
C 0.00% 98.99% 98.99% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
39 Lanjutan Histogram hasil pengujian berdasarkan waktu pengiriman pesan menggunakan Telkom Speedy 3Mbps
1 847 1347 1847 2347 2847 3347 3847 4347 4847 5347 5847 6347 6847 7347 7847
F 0 39 52 7 0 0 0 0 0 0 0 0 0 0 0
C 0.00% 39.80% 92.86% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
500 ms 2 F 0 30 43 14 6 3 0 1 0 0 0 0 0 0 1
C 0.00% 30.61% 74.49% 88.78% 94.90% 97.96% 97.96% 98.98% 98.98% 98.98% 98.98% 98.98% 98.98% 98.98% 100.00%
Keterangan: - F: Frequency - C: Cumulative - 1: Pengulangan ke-1 - 2: Pengulangan ke-2 - 3: Pengulangan ke-3
3 F 0 37 47 14 0 0 0 0 0 0 0 0 0 0 0
C 0.00% 37.76% 85.71% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
F 0 91 7 1 0 0 0 0 0 0 0 0 0 0 0
1
Telkom Speedy 3Mbps 1000 ms 2 3 1
1500 ms 2
C 0.00% 91.92% 98.99% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
F 0 91 7 0 0 1 0 0 0 0 0 0 0 0 0
F 0 87 5 6 0 0 0 0 0 0 0 0 0 0 0
C 0.00% 91.92% 98.99% 98.99% 98.99% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
F 0 90 7 2 0 0 0 0 0 0 0 0 0 0 0
C 0.00% 90.91% 97.98% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
F 1 97 1 1 0 0 0 0 0 0 0 0 0 0 0
C 1.01% 97.98% 98.99% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
C 0.00% 87.88% 92.93% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
3 F 0 97 1 1 0 0 0 0 0 0 0 0 0 0 0
C 0.00% 97.98% 98.99% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
1 F 0 96 2 1 0 0 0 0 0 0 0 0 0 0 0
C 0.00% 96.97% 98.99% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
2000 ms 2 F 0 98 1 0 0 0 0 0 0 0 0 0 0 0 0
C 0.00% 96.97% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
3 F 0 97 1 1 0 0 0 0 0 0 0 0 0 0 0
C 0.00% 97.98% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
40
RIWAYAT HIDUP Penulis dilahirkan di Surabaya 25 April 1990, merupakan anak pertama dari pasangan Arief Syuhada dan Ribut Yuliarti. Setelah menamatkan pendidikannya di Sekolah Menengah Atas Negeri 1 Pamekasan, penulis melanjutkan pendidikannya di Departemen Ilmu Komputer Institut Pertanian Bogor melalui Undangan Seleksi Masuk IPB (USMI). Selama menjadi mahasiswa, penulis aktif mengikuti organisasi di dalam kampus yaitu Koran Kampus, Badan Eksekutif Mahasiswa, serta Himpunan Mahasiswa Ilmu Komputer. Selain itu, penulis juga sering mengikuti organisasi di luar kampus, seperti Komunitas Pengguna Linux Indonesia (KPLI) Bogor, Tim Pengembang BlankOn Linux, serta komunitas penggiat TI lainnya. Penulis juga aktif mengisi seminar dan workshop baik yang diadakan oleh instansi pemerintah, swasta, lembaga pendidikan, serta komunitas.
