implementasi komunikasi antar server pada bisnis … · operator telekomunikasi seluler telkomsel...

Makalah Seminar Tugas Akhir Periode Juli 2010

Yudha Ari Sasongko - 5107100606 1

IMPLEMENTASI KOMUNIKASI ANTAR SERVER PADA BISNIS PULSA ELEKTRIK MENGGUNAKAN ZEROMQ

Yudha Ari Sasongko – Wahyu Suadi S.Kom, M.Kom Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember Surabaya,

Email: [email protected] Abstrak

Untuk mendistribusikan stok voucher isi ulang pulsa, pihak operator telekomunikasi seluler menunjuk authorized dealer di setiap region atau propinsi yang kemudian didistribusikan kepada beberapa supplier atau

server oleh authorized dealer. Dalam pendistribusian stok berdasarkan region, server-server pulsa mengalami

kendala karena tidak semua pengguna seluler yang melakukan pengisian ulang pulsa berada di region atau

tempat nomor seluler yang digunakan terdaftar. Untuk mendapatkan stok region lain, server pada suatu region

harus terhubung dan dapat berkomunikasi dengan server yang berada pada region lain.

ZeroMQ sebagai sistem messaging merupakan implementasi dari lightweight messaging yang

mendukung beberapa model messaging berbeda dan mampu mengirim/menerima pesan hingga 4.100.000 pesan

per detik digunakan sebagai framework dan library perangkat lunak yang dibangun untuk menyelesaikan

permasalahan yang ada dalam komunikasi antar server pada bisnis pulsa elektrik. Dari pengujian yang telah

dilakukan, ZeroMQ dengan lebih dari satu client mampu meningkatkan kinerja latency hingga 97,16% dari

socket linux. Kata kunci: ZeroMQ, client, server, HLR, seluler

1. Pendahuluan

Pada penggunaan sehari-hari, telpon seluler memerlukan pulsa untuk dapat digunakan. Seiring berkembangnya teknologi, pihak operator telekomunikasi seluler menyediakan voucher elektrik untuk mempermudah para pengguna dalam melakukan pengisian ulang pulsa. Dalam pendistribusian stok voucher isi ulang pulsa pihak operator telekomunikasi seluler menunjuk authorized dealer di setiap region atau propinsi. Untuk memenuhi kuantitas dan ketertiban pendistribusian stok berdasarkan region masing-masing, authorized dealer melakukan distribusi kepada supplier atau server.

Server-server pulsa mengalami kendala pendistribusian stok berdasarkan region karena tidak semua pengguna seluler yang melakukan pengisian ulang pulsa berada di region atau tempat nomor seluler yang digunakan terdaftar. Hal ini mengakibatkan mereka harus menyediakan stok untuk region lain dimana stok tersebut hanya dapat digunakan di region stok tersebut berasal. Untuk mendapatkan stok region lain, server pada suatu region harus terhubung dan dapat berkomunikasi dengan server yang berada pada region lain. Middleware dalam bentuk messaging server (messaging middleware), merupakan platform dimana perangkat-perangkat lunak dapat membuat aplikasi berskala besar dengan menggabungkan aplikasi-aplikasi yang dibuat dengan teknologi yang berbeda, berjalan di lingkungan yang berbeda. ZeroMQ sebagai sistem messaging merupakan implementasi dari lightweight messaging yang mendukung beberapa model messaging berbeda

sehingga memudahkan penentuan model messaging dalam suatu perangkat lunak. ZeroMQ mampu mengirim/menerima pesan hingga 4.100.000 pesan per detik digunakan sebagai framework dan library perangkat lunak yang dibangun untuk menyelesaikan permasalahan yang ada dalam komunikasi antar server pada bisnis pulsa elektrik. Beberapa batasan yang ada adalah sebagai berikut: - Komunikasi server mencakup dikirimnya data

transaksi oleh server region pengirim ke server region penyedia stok sampai diterimanya status pemrosesan data transaksi oleh server region pengirim.

- Pengiriman data transaksi ke operator telekomunikasi seluler diasumsikan berhasil tanpa adanya pengiriman data tersebut ke operator telekomunikasi seluler.

- Hanya mencakup bisnis pulsa elektrik untuk operator telekomunikasi seluler Telkomsel Simpati.

- Aplikasi ini diimplementasikan pada sistem operasi Linux Ubuntu Desktop 9.04.

- Media penyimpanan data transaksi menggunakan database server MySQL.

- Menggunakan bahasa C++ untuk server pusat (aplikasi server) dan Java untuk server region (aplikasi client).

2. ZeroMQ

ZeroMQ merupakan implementasi dari lightweight messaging dengan socket seperti API. ZeroMQ sangat cepat, mampu mengirim/menerima pesan hingga 4.100.000 pesan per detik. Hanya membutuhkan sepasang pages pada memory yang ada, sehingga



dapat berjalan pada platform dengan memory terbatas. Penggunaan sedikit memory juga penting untuk mengoptimalkan penggunaan L1i cache. Ketika ukuran kode cukup kecil, processor dapat menahan seluruh kode messaging dalam L1i cache menghindari akses lambat pada physical memory untuk mendapatkan potongan kode baru. ZeroMQ adalah software open source berlisensi LGPL yang ditulis dalam bahasa C++ menyediakan API bahasa C, C++, Common Lisp, Java, Python dan Ruby serta mendukung protokol transport yang berbeda seperti TCP, UCP, PGM, IPC, inter-thread dan lain-lain [10]. Inti dari ZeroMQ mengimplementasikan beberapa fitur low-level, yaitu: - Bagaimana menempatkan titik akhir (endpoints)

dari aliran pesan pada jaringan. - Bagaimana membentuk koneksi antara

endpoints. - Bagaimana menutup koneksi. - Bagaimana melewatkan pesan antara koneksi

dan thread aplikasi. Persistence bukan merupakan prioritas utama pada ZeroMQ karena menurut developer ZeroMQ sendiri hal tersebut bertentangan dengan messaging latensi rendah (low latency).

2.1. Distributed Broker

Ada beberapa keuntungan pada model broker-based yang tidak tersedia pada model broker-less. Aplikasi pengirim dan aplikasi penerima tidak harus tumpang tindih selamanya. Pesan disimpan pada broker ketika pengirim sudah mati (off) dan penerima belum juga nyala (on). Begitu juga jika aplikasi mengalami kegagalan, pesan yang sudah dikirim ke broker tidak hilang. Untuk membentuk perilaku yang semacam ini hanya perlu mempunyai beberapa aplikasi (broker) di tengah di antara aplikasi pengirim dan aplikasi penerima. Akibatnya, pesan yang dikirim harus melewati 2 lompatan jaringan. Arsitektur distributed broker

digunakan untuk menanggulangi permasalahan broker sebagai hambatan (bottleneck).

Gambar 2.1 Diagram Distributed Broker

Seperti pada Gambar 2.1, setiap antrian (queue) pesan diimplementasikan sebagai aplikasi terpisah. Hal itu

dapat dijalankan pada kotak yang sama sebagai satu dari aplikasi yang sedang terhubung, atau dimungkinkan juga terletak pada kotak yang sama sekali berbeda. Beberapa queue mungkin berjalan pada kotak tunggal dimana kotak tersebut didedikasikan khusus untuk menjadi tempat sebuah queue tunggal. Queue teregistrasi dengan broker (directory service) sehingga dapat diakses oleh semua aplikasi pada jaringan. Selain itu, queue adalah bagian yang sangat sederhana dari aplikasi yang mendapatkan pesan dari pengirim dan mendistribusikan kepada penerima. Sehingga kemungkinan terjadinya kegagalan lebih rendah dibandingkan dengan aplikasi yang penuh dengan bussines logic komplek. Distributed broker pada ZeroMQ diimplementasikan pada contoh aplikasi instant messaging pembahasan selanjutnya, dimana contoh aplikasi instant messaging tersebut mengemulasikan arsitektur broker-based klasik dengan menggunakan arsitektur broker-less ZeroMQ.

2.2. Instant Messaging

Messaging tanpa broker sedikit asing bagi para developer yang terbiasa dengan produk messaging biasa seperti IBM WebSphere MQ. Meskipun ZeroMQ melakukan yang terbaik untuk membuat perbedaan antara model broker-based dan broker-less lebih pada sebuah detail teknis daripada sesuatu yang para developer harus repot-repot lakukan, masih ada beberapa aspek yang harus dipertimbangkan. Yang terpenting, jika pengirim pesan dan penerima pesan tidak berjalan pada waktu yang bersamaan, maka tidak ada tempat sementara untuk menyimpan pesan-pesan. Dengan arsitektur broker-based pesan-pesan dapat disimpan pada broker, tetapi, tidak ada broker dalam kasus ini, developer harus membuat aplikasi penyimpanan pesan sendiri. Jika Anda menerapkan instant messaging (IM) dengan arsitektur broker-based klasik star messaging (satu broker sebagai pemusatan diskusi antar banyak client), broker akan menahan pesan-pesan dan semua IM client akan terhubung pada broker untuk mengakses chatroom.

Gambar 2.2 ZeroMQ IM Example Components

Dengan arsitektur broker-less kita akan membuat aplikasi menyimpan pesan sendiri. Sehingga secara langsung Anda akan menerapkan ulang arsitektur star sendiri. Desain yang dihasilkan akan menjadi aplikasi terdistribusi dengan tiga jenis komponen: 1. chatroom menerima dan mendistribusi ulang

pesan-pesan dari pengguna.



2. prompt menerima input pengguna dan mengirimkannya ke chatroom.

3. display terhubung pada chatroom dan menampilkan pesan-pesan yang berasal dari chatroom.

3. Bisnis Pulsa Elektrik

Bisnis pulsa elektrik adalah bisnis yang bergerak di bidang jasa pelayanan isi ulang pulsa dengan menggunakan media elektronik. Media elektronik di sini dapat berupa sms atau jaringan internet. Ada 3 kategori pendistribusi dalam bisnis ini: 1. Authorized dealer, merupakan badan usaha di

setiap region atau propinsi yang ditunjuk oleh operator telekomunikasi seluler untuk melayani pengguna dalam melakukan isi ulang pulsa.

Authorized Dealer

Pengguna

Supplier/Server

Agen

Supplier/Server

Operator Telekomunikasi

Seluler

Gambar 3.1 Distribusi Stok

Authorized dealer diberikan kewenangan untuk mendistribusikan dan menjual persediaan (stok) isi ulang pulsa sesuai dengan aturan yang telah ditetapkan oleh pihak operator telekomunikasi seluler karena kebijakan setiap region atau propinsi berbeda. Contohnya dalam penetapan harga jual. Stok isi ulang pulsa berbentuk unit yang tersimpan dalam chip atau SIM Card seperti halnya pulsa yang ada pada setiap SIM Card para pengguna seluler. Stok tersebut dapat digunakan dengan melakukan sms yang format dan nomor tujuannya telah ditentukan oleh pihak operator telekomunikasi seluler. Authorized dealer melakukan distribusi ke beberapa supplier atau server yang melayani isi ulang pulsa.

2. Supplier atau server merupakan badan usaha atau perorangan yang ditunjuk oleh authorized dealer untuk membantu melakukan pendistribusian stok isi ulang pulsa. Server tidak selalu mendapatkan stok dari authorized dealer tapi bisa juga dari server-server lain. Stok yang diperoleh dari authorized dealer berbentuk unit yang tersimpan dalam chip atau SIM Card. Sedangkan stok yang

diperoleh dari server lain berbentuk nominal saldo. Selain bentuk stok, mekanisme penggunaan stok juga berbeda antara server ke authorized dealer dengan server ke server. Untuk server ke authorized dealer menggunakan sms melalui chip dengan format dan nomor tujuan yang telah ditentukan oleh operator telekomunikasi seluler. Sedangkan untuk server ke server menggunakan jaringan internet.

internet

Supplier/Server Supplier/Server


Seluler

Gambar 3.2 Pengambilan Stok Server

*777*hp*nominal*pin# adalah contoh format sms yang dikirim server ke operator telekomunikasi seluler. Keterangan: 777 : nomor tujuan untuk permintaan stok

simpati hp : nomor seluler yang akan diisi ulang

pulsa nominal : besar nominal pulsa yang akan

diisikan pin : kode rahasia pengaman transaksi

pengisian pulsa yang ada di setiap chip yang digunakan

*777*08123456789*10*1234# menunjukkan permintaan stok pulsa 10.000 (sepuluh ribu) untuk nomor simpati 08123456789.

3. Agen merupakan perorangan yang membantu server dalam pendistribusian stok ke pengguna dengan melakukan registrasi nomor seluler dan data identitas terlebih dahulu pada server yang dikehendaki. Agen memperoleh stok dari server berbentuk nominal saldo.

internet

Supplier/Server Supplier/Server


Seluler

PenggunaAgen Gambar 3.3 Pengambilan Stok Agen



Untuk mekanisme penggunaan stok, agen mengirim sms melalui nomor seluler yang telah diregistrasikan dengan format dan nomor tujuan yang telah ditentukan oleh server. Setelah agen mengirim sms kemudian server meneruskan permintaan tersebut ke operator telekomunikasi seluler untuk dilakukan proses pengisian pulsa pada nomor pengguna. i.nominal.hp.pin adalah contoh format sms yang dikirim agen ke server. Keterangan: i : kode untuk permintaan stok pulsa nominal : besar nominal pulsa yang akan

diisikan hp : nomor seluler yang akan diisi ulang

pulsa pin : kode rahasia pengaman transaksi

pengisian pulsa yang diberikan server kepada agen

i.5.08123456789.2345 menunjukkan permintaan stok pulsa 5.000 (lima ribu) untuk nomor 08123456789.

4. Deskripsi Umum Sistem

Perangkat lunak yang dikembangkan adalah suatu sistem yang mengimplementasikan komunikasi antar server pada bisnis pulsa elektrik dengan menggunakan ZeroMQ. Perangkat lunak ini berfungsi untuk menghubungkan server-server region yang terletak di setiap region atau propinsi agar dapat saling bertukar persediaan (stok) isi ulang pulsa elektrik. Server-server region dibagi berdasarkan data Home

Location Register (HLR) yang telah ditetapkan oleh operator telekomunikasi seluler. Data HLR yang digunakan hanya berasal dari operator telekomunikasi seluler Telkomsel Simpati. Sistem yang dibangun berjalan secara online yang berarti membutuhkan sebuah network atau jaringan. Proses dimulai ketika server region (aplikasi client) melakukan koneksi ke database dan melakukan penge cekan data transaksi dengan status belum terproses, jika pada database terdapat data transaksi dengan status belum terproses maka aplikasi client akan mengirimkan data transaksi tersebut pada server pusat (aplikasi server) dan mengubah status data transaksi tersebut menjadi terproses. Aplikasi server melakukan parsing dan melakukan matching terhadap nomor seluler yang ada pada data transaksi yang dikirim oleh aplikasi client untuk menentukan region tujuan. Kemudian aplikasi server mengirimkan data transaksi tersebut pada aplikasi client dengan region yang sama dengan region tujuan yang telah ditentukan. Dimana region aplikasi client telah teregistrasi sebelumnya pada aplikasi server ketika aplikasi client melakukan koneksi ke aplikasi server. Setelah menerima data transaksi, aplikasi client tujuan mengirimkan pesan balasan pada aplikasi server kemudian aplikasi server meneruskan pesan balasan pada aplikasi client tempat data transaksi tersebut berasal.

Aplikasi client berfungsi mengirim/menerima data transaksi dan status pemrosesan data transaksi sedangkan aplikasi server berfungsi sebagai penghubung (broker) aplikasi-aplikasi client dan penentu tujuan dikirimnya data transaksi (forwarder).

Server

Client Region 1

Data

Transaksi

Data HLR

get

and

update

load

Parse

Message

Match HLR

send send

Client Region 2

Data

Transaksi

get

and

update

receivereceive

Define

Destination

Gambar 4.1 Deskripsi Umum Sistem

5. Desain Aplikasi Server

Aplikasi server yang dibangun berfungsi sebagai forwarder atau penentu tujuan dari pesan yang dikirim oleh aplikasi client. Selain itu juga, aplikasi server juga bertindak sebagai broker aplikasi-aplikasi client yang ada pada sistem. Ketika aplikasi server menerima pesan yang berisi data transaksi yang dikirim oleh aplikasi client, aplikasi server melakukan pengolahan terhadap pesan terlebih dahulu untuk menentukan aplikasi client yang merupakan tujuan dari pesan tersebut. Penentuan aplikasi client yang dituju dilakukan berdasarkan data HLR yang telah disimpan pada file teks yang kemudian di-load dan disimpan dalam variabel saat aplikasi server dijalankan. Seperti pada Gambar 5.1, setiap pesan yang diterima oleh aplikasi server akan di-parse dan diambil nomor seluler yang ada pada pesan tersebut. Kemudian nomor seluler yang telah diambil dicocokan dengan data HLR untuk menentukan region terdaftarnya nomor seluler sekaligus untuk menentukan aplikasi client tujuan pengiriman pesan. Saat aplikasi server dijalankan, proses yang pertama kali dilakukan adalah melakukan inisialisasi infrastruktur dari ZeroMQ. Proses inisialisasi infrastruktur ZeroMQ dilakukan untuk membentuk koneksi ke ZeroMQ server dan menyediakan jalur komunikasi antar thread ZeroMQ yang terbentuk. Setelah infrastruktur ZeroMQ terinisialisasi, selanjutnya dilakukan inisialisasi layout thread. Inisialisasi layout thread bertujuan untuk membentuk handling I/O thread lalu lintas jaringan dengan menggunakan mekanisme polling optimal pada platform (sistem operasi) yang digunakan. Proses selanjutnya adalah membuat queue global. Queue digunakan untuk menerima pesan dari exchange-exchange yang telah ter-bind. Agar queue tersebut dapat di-bind oleh exchange yang terdapat pada aplikasi lain, maka queue yang dibuat harus visible di seluruh jaringan atau bersifat global.



Mulai

Inisialisasi

infrastruktur

ZeroMQ

Inisialisasi layout

thread ZeroMQBuat queue global

Load data HLR

Buat exchange

globalTerima pesan

Ambil nomor

seluler, match

HLR dan tentukan

tujuan

Data HLR

Tentukan tujuan

Buat pesan keluar

Selesai

Data transaksi

baru

Parse pesan

ya tidak

Kirim pesan

Gambar 5.1 Desain Proses Aplikasi Server

Selanjutnya aplikasi server me-load data HLR yang kemudian disimpan dalam variabel. Data HLR yang di-load berisi nama region dan prefix region nomor seluler sesuai dengan masing-masing region yang ada. Tujuannya yaitu: nama region digunakan untuk penamaan identitas exchange yang akan dibuat, dan untuk menentukan tujuan pengiriman pesan; dan prefix region nomor seluler digunakan untuk proses match HLR yang hasilnya juga digunakan untuk menentukan region tujuan pengiriman pesan. Exchange dibuat untuk digunakan mengirim pesan pada queue yang telah di-bind. Variabel yang digunakan untuk menyimpan data HLR berbentuk linked list yang mempunyai 2 member, yaitu region dan HLR. Region digunakan untuk menyimpan nama region, dan HLR untuk menyimpan prefix region nomor seluler.

region HLR

Gambar 5.2 Linked List

Operasi string yang digunakan untuk pengolahan pesan pada proses parse pesan; ambil nomor seluler, match HLR dan tentukan tujuan adalah operasi string explode untuk memecah kata atau kalimat menjadi huruf atau kata berdasarkan tanda pemisah (separator) yang ditentukan; operasi string find and replace untuk mengubah karakter atau kata yang dicari pada suatu kata atau kalimat dengan karakter atau kata yang ditentukan; dan operasi string find. Pada standar string library C++ operasi string explode dan operasi string

find and replace belum tersedia. Berikut adalah pseudocode operasi string explode.

1 StringExplode(str, separator) 2 res[] ← null 3 i ← 1 4 j ← 0 5 for k ← 1 to str.length 6 do if str.substr(k, 1) = separator 7 then res[j] ← str.substr(i, k - i) 8 i ← k + 1 9 j ← j + 1 10 k ← k + 1 11 res[j] ← str.substr(i, k - i) 12 return res

Dan berikut adalah pseudocode operasi string find and

replace. 1 StringFindReplace(str, find, replace) 2 for i ← 1 to str.length 3 do if str.substr(i, 1) = find 4 then str.substr(i, 1) ← replace 5 return str

Pada proses parse pesan operasi string explode digunakan untuk memecah pesan yang diterima oleh aplikasi server yang berisi data transaksi. Setelah terpecah menjadi beberapa bagian selanjutnya dicek apakah pesan tersebut merupakan pesan yang berisi data transaksi baru atau berisi balasan status pemrosesan. Hal ini dapat dibedakan dari tujuan pengiriman yang ada pada pesan. Jika berisi balasan status pemrosesan maka akan dilakukan proses tentukan tujuan. Namun jika berisi data transaksi baru maka proses ambil nomor seluler, match HLR dan tentukan tujuan dilakukan. Pesan yang telah terpecah salah satu bagiannya merupakan nomor seluler, selanjutnya nomor seluler tersebut disimpan pada sebuah variabel. Nomor seluler yang telah tersimpan pada variabel digunakan sebagai patokan pencocokan prefix region nomor seluler dengan menggunakan operasi string find. Dalam proses ini yang dimaksud dengan match HLR adalah proses pencocokan 7 digit pertama nomor seluler dengan data prefix region nomor seluler yang ada pada data HLR. Jika telah ditemukan prefix region nomor seluler yang sesuai, maka tujuan pengiriman pesan juga telah ditemukan. Setelah tujuan pengiriman ditemukan selanjutnya dilakukan proses pembuatan pesan keluar dan kemudian pesan tersebut dikirim pada aplikasi client tujuan.

6. Desain Aplikasi Client

Aplikasi client yang dibangun pada sistem berfungsi sebagai pengirim/penerima pesan yang berisi data transaksi baru, dan status pemrosesan data transaksi. Pada aplikasi client terdapat beberapa proses yang telah digambarkan pada Gambar 6.1. Proses pada aplikasi client diawali dengan proses inisialisasi koneksi pada database, dan dilanjutkan dengan proses inisialisasi koneksi pada ZeroMQ server dan server



center (aplikasi server). Proses ini dilakukan untuk membentuk koneksi pada database yang berfungsi menyimpan data-data transaksi, dan membentuk koneksi pada ZeroMQ server dan aplikasi server. Setelah koneksi database, ZeroMQ server dan aplikasi server terbentuk selanjutnya dilakukan proses pembuatan queue dan exchange. Pada aplikasi client queue dan exchange yang dibuat bersifat lokal karena queue dan exchange tersebut hanya digunakan pada aplikasi client itu saja dan tidak untuk diakses oleh aplikasi lain. Queue dan exchange yang telah terbentuk kemudian di-bind pada queue dan exchange yang ada pada aplikasi server. Binding bertujuan untuk mengikat atau membentuk komunikasi antara queue dan exchange sehingga dapat dilakukan

pertukaran pesan dapat dilakukan.

Mulai

Inisialisasi koneksi

database

Inisialisasi koneksi

ZeroMQ dan

server center

Buat queue lokalBuat exchange

lokal

BindingSelect data

transaksi

Buat pesan data

transaksi

Kirim pesan data

transaksi

Update data

transaksiTerima pesan

Data transaksi

baru dari client

lain

Kirim balasan

status

pemrosesan

Buat pesan

balasan status

pemrosesan

Selesai

ya

tidak

Data

Transaksi

Gambar 6.1 Desain Proses Aplikasi Client

Selanjutnya aplikasi client melakukan pengecekan data transaksi yang ada pada database. Jika pada database ditemukan data transaksi dengan status belum terproses, maka data transaksi tersebut akan diambil (select) dan diformat dalam sebuah pesan yang nantinya akan dikirim pada aplikasi server. Setelah proses pengiriman pesan dilakukan selanjutnya status data transaksi di-update. Selain mengirim pesan, aplikasi client juga menerima pesan yang berisi data transaksi baru, dan balasan status pemrosesan dari aplikasi client lain. Pesan yang diterima diolah dengan menggunakan operasi string. Operasi string yang digunakan untuk pengolahan pesan adalah operasi string split. Operasi string split berfungsi untuk memecah kata atau kalimat menjadi huruf atau kata berdasarkan tanda pemisah (separator) yang ditentukan sama halnya dengan operasi string explode pada aplikasi server. Pesan yang telah diolah kemudian dicek apakah pesan yang diterima merupakan pesan data transaksi baru atau pesan balasan status pemrosesan

data transaksi. Jika pesan yang diterima merupakan pesan data transaksi baru, maka aplikasi client akan membuat pesan balasan status pemrosesan untuk dikirim pada aplikasi client pengirim data transaksi.

6.1. Perancangan Data

Pesan yang dikirim oleh aplikasi client terdiri dari dua jenis, yaitu pesan yang berisi data transkasi baru dan pesan yang berisi status pemrosesan data transaksi. Berikut format pesan yang dikirim oleh aplikasi client: 1. Format pesan data transaksi baru

<src><dst><nom><hp><refid>

Keterangan: <src> : pengirim pesan <dst> : penerima pesan <nom> : nominal pulsa <hp> : nomor seluler <refid> : referensi id transaksi dari pengirim

pesan data transaksi 2. Format pesan balasan status pemrosesan

<src><dst><hp><refid><OK> Keterangan: <src> : pengirim pesan <dst> : penerima pesan <hp> : nomor seluler <refid> : referensi id transaksi dari pengirim

pesan data transaksi <OK> : status pemrosesan data transaksi

Data nominal, nomor seluler dan referensi id transaksi yang ada pada pesan berasal dari data yang ada pada database. Struktur tabel pada database yang digunakan aplikasi client dirancang berdasarkan struktur tabel pada database yang digunakan oleh sistem isi ulang pulsa elektrik yang telah dikembangkan oleh para developer perangkat lunak bisnis pulsa elektrik. Berikut struktur tabel pada database yang digunakan.

Tabel 6.1 Struktur Tabel Data Transaksi

No. Atribut Tipe Ukura

n Null Ket.

1 id_transaksi integer

unsigned zerofill

2 nominal integer

3 no_hp varchar

15

4 ref_id_transaksi

integer

unsigned zerofill

5 status_transaksi

integer

7. Uji Coba dan Evaluasi

Pengujian dilakukan dengan tujuan untuk mengetahui perbandingan performa average latency atau selisih rata-rata waktu kirim dan terima paket atau pesan, dan average throughput atau tingkat rata-rata jumlah



diterimanya pesan dalam satuan waktu dengan single client maupun multi client yang terhubung dan beraktifitas pada server antara sistem yang menggunakan ZeroMQ dengan domain socket linux Internet networking socket (AF_INET).

n-times Snd msg

n-times Rcv msgServerClient

3 timesrepetitions

Gambar 7.1 Uji Average Latency Single Client

Snd first msg

n-times Rcv msgServerClient

3 timesrepetitions

Gambar 7.2 Uji Average Throughput Single Client

n-times Snd msg

n-times Rcv msg

Server

Client 1

3 timesrepetitions

Client n

Gambar 7.3 Uji Average Latency Multi Client

Snd first msg

n-times Rcv msg

Server

Client 1

3 timesrepetitions

Client n

Gambar 7.4 Uji Average Throughput Multi Client

Untuk memperoleh hasil yang optimal, masing-masing proses pengukuran dilakukan sebanyak tiga kali dimana satu proses pengukuran dengan proses pengukuran yang lain diberikan jeda waktu selama 5 detik. Kemudian nilai rata-rata dari ketiga hasil pengukuran tersebut dijadikan sebagai hasil uji coba.

7.1. Lingkungan Uji Coba

Uji coba dilakukan menggunakan komputer yang berbeda dan jaringan inter koneksi dengan intranet point-to-point. Komputer untuk aplikasi server dan aplikasi client terhubung tanpa switch dengan menggunakan kabel UTP cross. Berikut spesifikasi perangkat keras dan perangkat lunak yang digunakan untuk aplikasi server: - Spesifikasi perangkat keras

Prosesor Intel Pentium 4 1,8GHz Memory DDR 512 MB Hard Disk 40 GB Broadcom NetXtreme Gigabit Ethernet

- Spesifikasi perangkat lunak Gcc versi 4.3 Sistem operasi Linux Ubuntu Desktop 9.04 IP address 192.168.1.113

Untuk aplikasi client perangkat keras yang digunakan adalah Notebook MSI Mega Book S420 dengan spesifikasi: - Prosesor Intel Core 2 Duo T5500 1,66GHz - Memory DDR2-667 2.976 MB - Realtek RTL8139/810x Family Fast Ethernet

NIC Dan untuk spesifikasi perangkat lunak yang digunakan aplikasi client adalah: - Gcc versi 4.3 - ZeroMQ versi 1.0.1 - Sistem operasi Linux Ubuntu Desktop 9.04 - VMware Workstation ACE Edition versi 6.0.0

dengan spesifikasi perangkat keras: Hard Disk 8 GB Memory 512 MB

- IP address 192.168.1.112

7.2. Uji Coba Skenario I

Pesan yang dikirim : test Jumlah pengiriman : 1.000, 2.000, 3.000, . . .

10.000 kali. Jumlah client : 1 Setelah dilakukan pengujian, berikut adalah hasil pengukuran average latency dan average throughput skenario I.

Tabel 7.1 Hasil Pengukuran Average Latency Skenario I

n-kirim Average Latency (µs)

Δ socket linux zeromq

1.000 196,69 291,43 -48,17% 2.000 184,96 275,74 -49,08% 3.000 181,55 273,07 -50,41% 4.000 175,79 266,83 -51,79% 5.000 179,86 268,09 -49,05% 6.000 176,49 267,37 -51,49% 7.000 174,04 266,33 -53,03% 8.000 177,03 265,90 -50,20%



9.000 173,82 266,11 -53,10% 10.000 173,34 265,84 -53,36%

Tabel 7.2 Hasil Pengukuran Average Throughput

Skenario I

n-kirim

Average Throughput (msg/s) Δ socket

linux zeromq

1.000 5.466 4.942.689 90.326,07% 2.000 13.046 4.777.895 36.523,45% 3.000 16.479 4.929.962 29.816,63% 4.000 28.423 4.940.341 17.281,49% 5.000 369.408 4.865.876 1.217,21% 6.000 42.228 4.649.674 10.910,88%

7.000 41.943 3.555.167 8.376,19% 8.000 44.019 3.185.234 7.136,04% 9.000 47.125 3.527.884 7.386,23%

10.000 410.426 2.476.964 503,51% Pada skenario I ini diperoleh hasil pengukuran average latency socket linux lebih baik dari ZeroMQ. Selisih average latency socket linux dengan ZeroMQ antara 88,22 – 94,74 µs atau mengalami penurunan performa hingga 53,36%. Sedangkan untuk hasil uji coba performa average

throughput ZeroMQ jauh lebih baik jika dibandingkan dengan socket linux. Diperoleh nilai selisih yang cukup signifikan dengan angka maksimal 4.937.223 atau mengalami peningkatan performa hingga 90.326,07%.

Gambar 7.5 Grafik Average Latency Skenario I

Gambar 7.6 Grafik Average Throughput Skenario I

7.3. Uji Coba Skenario II

Pesan yang dikirim : <JABODETABEK><JATIM ><10><081331212112><1234>

Jumlah pengiriman : 1.000, 2.000, 3.000, . . . 10.000 kali.

Jumlah client : 1 Pada pengujian kali ini yang membedakan antara skenario I dengan skenario II adalah isi pesan yang dikirim. Tujuannya untuk mengetahui seberapa besar

0

50

100

150

200

250

300

350

Ave

rage

Lat

ency

(mic

rose

con

ds)

Roundtrip Count

zeromq

socket linux

0

1,000,000

2,000,000

3,000,000

4,000,000

5,000,000

6,000,000

1,00

0

2,00

0

3,00

0

4,00

0

5,00

0

6,00

0

7,00

0

8,00

0

9,00

0

10,0

00

Ave

rage

Th

rou

ghp

ut (

msg

/s)

Roundtrip Count

zeromq

socket linux



pengaruh dari panjang pesan yang dikirim dengan hasil uji coba performa yang diperoleh. Setelah dilakukan uji coba dengan menggunakan skenario II, maka diperoleh hasil pengukuran average latency dan average throughput sebagai berikut.

Tabel 7.3 Hasil Pengukuran Average Latency Skenario II



1.000 194,29 303,53 -56,23% 2.000 186,39 288,66 -54,87% 3.000 182,94 284,69 -55,62% 4.000 179,71 282,88 -57,41% 5.000 178,08 282,30 -58,52% 6.000 177,62 281,56 -58,52% 7.000 177,36 279,52 -57,60% 8.000 175,25 280,14 -59,85% 9.000 187,41 279,18 -48,97%

10.000 177,47 295,70 -66,62%

Tabel 7.4 Hasil Pengukuran Average Throughput Skenario II

n-kirim


linux zeromq

1.000 4.525 2.620.967 57.821,92% 2.000 9.612 1.914.359 19.816,34% 3.000 12.834 522.235 3.969,15% 4.000 22.389 883.043 3.844,09% 5.000 383.322 313.736 -18,15% 6.000 40.167 345.247 759,53% 7.000 34.374 323.011 839,70%

8.000 31.459 267.225 749,44% 9.000 51.934 253.171 387,49%

10.000 114.846 276.265 140,55% Hasil pengukuran average latency yang diperoleh pada skenario II ini tidak berbeda jauh dengan hasil yang diperoleh pada skenario I. Dengan perbedaan panjang pesan yang dikirim, hasil performa average latency socket linux masih lebih baik dari ZeroMQ. Pada uji coba skenario II ini selisih average latency

socket linux dengan ZeroMQ adalah 91,76 – 118,23 µs atau mengalami penurunan performa 66,62%. Secara umum average throughput ZeroMQ masih lebih baik dari pada socket linux. Jika dibandingkan dengan hasil uji coba performa average throughput pada skenario I terlihat bahwa panjang pesan yang dikirim cukup berpengaruh pada performa yang dihasilkan terutama pada performa ZeroMQ sebagai sistem lightweight messaging.

7.4. Uji Coba Skenario III


Jumlah pengiriman : 1.000, 2.000, 3.000, . . . 10.000 kali.

Jumlah client : 3 Berdasarkan pengukuran pada skenario II yang menunjukkan bahwa panjang pesan yang dikirim mempunyai pengaruh terhadap hasil yang diperoleh, maka pesan yang dikirim pada uji coba skenario III ini menggunakan pesan yang sama dengan uji coba skenario II. Namun pada skenario III terdapat penambahan jumlah aplikasi client yang terhubung dan beraktifitas pada aplikasi server.

Gambar 7.7 Grafik Average Latency Skenario II

0

50

100

150

200

250

300

350

Ave

rage

Lat

ency

(mic

rose

con

ds)

Roundtrip Count

zeromq

socket linux



Gambar 7.8 Grafik Average Throughput Skenario II

Setelah dilakukan pengujian, maka diperoleh hasil pengukuran average latency dan average throughput skenario III sebagai berikut.

Tabel 7.5 Hasil Pengukuran Average Latency Skenario III



1.000 315,78 14,29 95,47% 2.000 301,05 10,63 96,47% 3.000 296,32 8,62 97,09% 4.000 298,26 9,27 96,89% 5.000 294,34 8,36 97,16% 6.000 296,42 9,08 96,94% 7.000 290,75 9,02 96,90% 8.000 293,08 9,52 96,75% 9.000 293,03 10,36 96,46%

10.000 294,41 9,74 96,69%

Tabel 7.6 Hasil Pengukuran Average Throughput Skenario III

n-kirim


linux zeromq

1.000 6.272 2.309.518 36.722,67% 2.000 13.205 1.561.994 11.728,81% 3.000 13.517 452.518 3.247,77% 4.000 17.941 565.695 3.053,09% 5.000 381.510 229.190 -39,93% 6.000 220.206 180.730 -17,93% 7.000 42.362 162.360 283,27% 8.000 231.439 167.995 -27,41% 9.000 290.477 158.041 -45,59%

10.000 338.988 173.927 -48,69%

Gambar 7.9 Grafik Average Latency Skenario III

0

500,000

1,000,000

1,500,000

2,000,000

2,500,000

3,000,000

1,00

0

2,00

0

3,00

0

4,00

0

5,00

0

6,00

0

7,00

0

8,00

0

9,00

0

10,0

00

Ave

rage

Th

rou

ghp

ut (

msg

/s)

Roundtrip Count

zeromq

socket linux

0

50

100

150

200

250

300

350

Ave

rage

Lat

ency

(mic

rose

con

ds)

Roundtrip Count

zeromq

socket linux



Gambar 7.10 Grafik Average Throughput Skenario III

Berdasarkan hasil yang diperoleh dari pengujian skenario III menunjukkan bahwa performa dari ZeroMQ jauh lebih baik jika dibandingkan dengan hasil yang diperoleh dari socket linux. Hal ini menunjukkan bahwa ZeroMQ menjadi lebih optimal jika digunakan pada sistem komunikasi antar server multi client. Hasil average latency yang diperoleh cukup signifikan dengan adanya peningkatan performa pada sistem yang menggunakan ZeroMQ hingga 97,16%. Sedangkan pada pengukuran average throughput, sekali lagi ZeroMQ terbukti sebagai sistem lightweight messaging. Semakin besar pesan yang dikirimkan maka semakin kecil jumlah pesan yang dikirim/diterima oleh ZeroMQ. Baik satu aplikasi client atau lebih yang terhubung dan beraktifitas pada aplikasi server, performa throughput ZeroMQ masih menunjukkan hasil lebih baik dari socket linux.

7.5. Uji Coba Skenario IV


Jumlah pengiriman : 1.000 kali. Jumlah client : 1, 3, 5, . . . 15 Pada skenario IV pengujian hanya dilakukan untuk mengukur average throughput. Diharapkan hasil yang diperoleh mampu mengukur tingkat kestabilan concurrent access ZeroMQ.

Tabel 7.7 Hasil Pengukuran Average Throughput Skenario IV

n-client


linux zeromq

1 4.525 2.620.967 57.821,92% 3 6.272 2.309.518 36.722,67% 5 9.585 2.194.740 22.797,65% 7 5.998 2.009.021 33.394,85% 9 5.466 2.020.026 36.856,20%

11 92.172 1.342.698 1.356,73% 13 6.576 1.458.435 22.078,15% 15 40.394 1.806.683 4.372,65%

Gambar 7.11 Grafik Average Throughput Skenario IV

0

500,000

1,000,000

1,500,000

2,000,000

2,500,000

1,00

0

2,00

0

3,00

0

4,00

0

5,00

0

6,00

0

7,00

0

8,00

0

9,00

0

10,0

00

Ave

rage

Th

rou

ghp

ut (

msg

/s)

Roundtrip Count

zeromq

socket linux

0

500,000

1,000,000

1,500,000

2,000,000

2,500,000

3,000,000

1 3 5 7 9 11 13 15

Ave

rage

Th

rou

ghp

ut (

msg

/s)

Client Count

zeromq

socket linux



Setelah dilakukan pengujian, maka didapatkan hasil pengukuran average throughput pada Tabel 7.7 dan Gambar 7.11. Berdasarkan hasil yang diperoleh menunjukkan bahwa tingkat kestabilan concurrent access ZeroMQ mengalami perubahan berdasarkan jumlah client yang terhubung. Pada Gambar 7.11 dapat dilihat bahwa global minimum terjadi ketika 11 aplikasi client terhubung dan beraktifitas pada aplikasi server. Namun ketika jumlah aplikasi client yang terhubung dan beraktifitas pada aplikasi server lebih dari sebelas sampai sama dengan lima belas, performa throughput mengalami peningkatan. Hal ini menunjukkan bahwa pada jumlah aplikasi client tertentu yang terhubung dan beraktifitas pada aplikasi server performa throughput ZeroMQ mengalami penurunan. Sedangkan untuk perbandingan performa antara socket linux dengan ZeroMQ pada skenario IV menunjukkan bahwa performa throughput ZeroMQ masih lebih baik.

8. Kesimpulan dan Saran

8.1. Kesimpulan

Kesimpulan yang dapat diambil antara lain sebagai berikut. 1. Telah diimplementasikan satu aplikasi bisnis

pulsa elektrik dengan menggunakan ZeroMQ. 2. Pengujian menunjukkan kinerja latency ZeroMQ

dengan satu client tidak lebih baik dari pada socket linux, dan lebih baik dengan lebih dari satu client.

3. Dengan satu client atau lebih kinerja throughput ZeroMQ lebih baik dari socket linux.

8.2. Saran

Saran-saran yang dapat diberikan untuk pengembangan selanjutnya adalah sebagai berikut. 1. Dengan penambahan jenis operator

telekomunikasi seluler dan penambahan proses pengiriman data transaksi ke operator telekomunikasi seluler menjadikan sistem ini dapat diimplementasikan pada bisnis pulsa elektrik.

2. Proses login dapat ditambahkan untuk menjaga keamanan dalam komunikasi data antar server.

3. Penambahan sistem komunikasi persisten membuat sistem ini menjadi lebih reliabel.

9. Daftar Pustaka

[1] http://www.webopedia.com/TERM/m/middleware.html

[2] Wikipedia 2009. "Middleware". <URL: http://en.wikipedia.org/wiki/Middleware>

[3] David E. Bakken. 2003. "Middleware". <URL: http://www.eecs.wsu.edu/~bakken/middleware.htm>

[4] Zeromq 2009. "Background to AMQP". <URL: http://www.zeromq.org/whitepapers:amqp-analysis>

[5] Middleware 2009. "Message Queuing Middleware". <URL: http://www.middleware.org/general/mqm.html>

[6] Wikipedia 2009. "Message-oriented middleware". <URL: http://en.wikipedia.org/wiki/Message_Oriented_Middleware>

[7] "Message-oriented middleware". <URL: http://dsonline.computer.org/portal/site/dsonline/menuitem.9ed3d9999aeb0dcd82ccc6716bbe36ec/index.jsp?&pName=dso_level1&patp=dsonline/topics/middleware&file=intro_MOM.xml&xsl=article.xxs>

[8] Markku Korhonen. 1997. "Message Oriented Middleware (MOM)". Tik- 110.551 Internetworking Seminar, Department of Computer Science, Helsinki University of Technology. <URL: http://www.tml.tkk.fi/Opinnot/Tik-110.551/1997/mqs.htm>

[9] Andrew S. Tanenbaum, Maarten Van Steen. 2002. "Distributed Systems Principles and Pradigms": Prentice-Hall, Inc.

[10] Zeromq 2009. "What's Zeromq?". <URL: http://www.zeromq.org/>

[11] Zeromq 2009. "Y-suite". <URL: http://www.zeromq.org/whitepapers:y-suite>

[12] Zeromq 2009. "Instan Messaging". <URL: http://www.zeromq.org/code:examples-chat>

[13] Apache log4cxx 2010. "Short introduction to Apache log4cxx". <URL: http://logging.apache.org/log4cxx/index.html>

[14] http://www.cplusplus.com/doc/tutorial/ [15] http://www.infernodevelopment.com/perfect-c-

string-explode-split

http://www.webopedia.com/TERM/m/middleware.html

http://www.webopedia.com/TERM/m/middleware.html

http://en.wikipedia.org/wiki/Middleware

http://www.eecs.wsu.edu/~bakken/middleware.htm

http://www.eecs.wsu.edu/~bakken/middleware.htm

http://www.zeromq.org/whitepapers:amqp-analysis

http://www.zeromq.org/whitepapers:amqp-analysis

http://www.middleware.org/general/mqm.html

http://en.wikipedia.org/wiki/Message_Oriented_Middleware

http://en.wikipedia.org/wiki/Message_Oriented_Middleware

http://dsonline.computer.org/portal/site/dsonline/menuitem.9ed3d9999aeb0dcd82ccc6716bbe36ec/index.jsp?&pName=dso_level1&patp=dsonline/topics/middleware&file=intro_MOM.xml&xsl=article.xxs&





http://www.tml.tkk.fi/Opinnot/Tik-110.551/1997/mqs.htm

http://www.tml.tkk.fi/Opinnot/Tik-110.551/1997/mqs.htm

http://www.zeromq.org/

http://www.zeromq.org/whitepapers:y-suite

http://www.zeromq.org/code:examples-chat

http://logging.apache.org/log4cxx/index.html

http://www.cplusplus.com/doc/tutorial/

http://www.infernodevelopment.com/perfect-c-string-explode-split

http://www.infernodevelopment.com/perfect-c-string-explode-split

implementasi komunikasi antar server pada bisnis … · operator telekomunikasi seluler telkomsel...

Documents