User Stories - Alat dan Bahan - METODOLOGI PENELITIAN

METODOLOGI PENELITIAN

3.1. Alat dan Bahan

4.1.6. User Stories

Dari hasil analisis user stories sebelumnya dapat disimpulkan bahwa terdapat

beberapa user stories yang dapat dibagi, di antaranya :

1. Konfigurasi qdisc HTB dan RED dengan TC

3. Penggunaan TC untuk mengambil data kecepatan tiap node. 4. Penggunaan TC untuk setting qdisc sebelumnya.

4.2. Design

4.2.1 Class Design

Proses desain akan dilakukan menggunakan Class Responsibilities, and Collaboration (CRC) Card. Penggunaan CRC card untuk mengarahkan berpikir

secara objek dibanding secara prosedural. Tiap-tiap CRC card akan merepresentasikan tiap objek yang dibutuhkan. Proses desain di sini akan lebih fokus pada bagaimana tiap objek saling berinteraksi bukan bagaimana membuat objek tersebut.

Dari user stories pada tahap planning, penulis membuat beberapa class yaitu : 1. HTB, digunakan untuk mengenerate TC statement.

2. RED, digunakan untuk mengenerate TC statement.

3. TC, digunakan untuk mengeksekusi TC statement yang sebelumnya dibuat oleh class lain.

4. BWGUI, digunakan untuk menangani GUI dari aplikasi. 5. Client, digunakan untuk menangani informasi tiap klien.

6. BandwidthConsumption, digunakan untuk menangani penggunaan bandwidth tiap client.

HTB

RED

Client Generate tc statement untuk

root qdisc.

Generate tc statement untuk tambah/edit/hapus client. BWGUI TC HTB RED Client BandwidthConsumtpion Generate tc statement sesuai

dengan algoritma RED yang sudah ditetapkan.

Generate tc statement untuk edit dan hapus RED qdisc.

Eksekusi statement untuk TC. Parsing output untuk

kecepatan aktual tiap-tiap class.

Client

Menangani GUI untuk aplikasi.

Setting TC dengan tampilan grafis.

Memberikan laporan

penggunaan bandwidth tiap client dengan plot.

Gambar 4.4 Class HTB

Gambar 4.5 Class RED

Gambar 4.6 Class TC

Class BWGUI akan menggunakan class HTB, RED dan TC. Karena class BWGUI yang nantinya akan menangani input dan output dari pengguna. Karena

Client

BandwidthConsumption

TC Client Menangani informasi tiap

client, di antaranya: - IP address

- Rate

Parsing kecepatan aktual tiap kelas dari TC.

Menyimpan kecepatan tiap class untuk ditampilkan pada plot. HTB RED TC Client BandwidthConsumption Gambar 4.8 Class Client

Gambar 4.9 Class BandwidthConsumption

Gambar 4.10 Desain Class BWGUI

input berupa nilai bandwidth rate dan informasi client. Maka class BWGUI memerlukan class tersebut. Class HTB menggunakan class client untuk menampung informasi client berupa IP, bandwidth rate dan lainnya. Class TC hanya berkomunikasi dengan BWGUI dan BandwidthConsumption. Karena BandwidthConsumption memerlukan class TC untuk mengambil bandwidth rate dari tiap class dan melakukan parsing terhadap outputnya.

4.2.2 GUI design

Gambar 4.11 Layout BWTC tab Gateway

Layout untuk GUI memiliki beberapa widget, di antaranya menu, plot, tab, dan beberapa textbox dan button. Untuk tampilan awal dari aplikasi, terlihat dari gambar 4.11 Terdapat tab gateway yang aktif, di dalamnya memiliki 2 group frame.

Sebelah kiri adalah NAT settings yang berguna untuk mengeset PC sebagai gateway atau hanya melewatkan paket. Dan terdapat 2 textbox untuk setting network interface yang digunakan untuk terhubung ke internet dan jaringan local.

Sebelah kanan adalah Max Upload & Download Rate yang digunakan untuk mengatur kecepatan maksimum upload dan download yang dimiliki. Terdapat 2 Textbox, satu untuk mengatur upload dan untuk mengatur download. Satuan yang digunakan dalam textbox tersebut adalah kbps.

Gambar 4.12 Layout BWTC tab Download Rate

Pada tab selanjutnya atau tab Download Rate, terdapat beberapa tombol dan table. Tombol Add Client berfungsi menambah informasi klien dan mengatur kecepatan klien tersebut. Tombol Edit Client berfungsi mengubah informasi klien yang sudah

masuk. Tombol Delete Client berfungsi menghapus klien dari table dan melepas pengaturan kecepatan.

Fungsi dari table di bawahnya adalah untuk menampilkan klien yang telah ditambah. Informasi klien ditampilkan pada table tersebut. Dan ketika dipilih akan menampilkan log berupa plot di bagian atas.

Gambar 4.12 Layout BWTC tab Upload Rate

Pada Tab ini terdapat sebuah group frame Upload Settings yang berisi textbox untuk upload limit, probability dan latency. Tidak seperti download rate, pada tab upload rate tidak bergantung pada berapa klien karena menggunakan RED yang tidak memiliki fungsi classifier. Proses nantinya akan mengenerate RED ke dalam network interface yang sebelumnya disetting sebagai inet interface.

Gambar 4.13 Layout BWTC dialogbox Client.

Pada tab Download Rate, terdapat button Add Client dan Edit Client. Aksi dari kedua button tersebut akan memunculkan dialogbox seperti di atas. Dialogbox akan muncul untuk meminta informasi terkait klien yang ingin diatur kecepatan downloadnya.

Gambar 4.14 Layout BWTC menu File.

Menu file digunakan untuk membuat setting baru ataupun mengambil setting yang sudah ada dan menyimpannya ketika ada perubahan.

Gambar 4.15 Layout BWTC menu Help

Gambar 4.16 Layout BWTC plot log rate.

Plot akan muncul ketika pengguna memilih salah satu klien yang ada dalam table. Ketika terpilih plot akan memunculkan diagram garis untuk menunjukkan penggunaan bandwidth dari klien tersebut. Plot akan terupdate tiap 1 detik dan memberikan log realtime kepada pengguna.

4.3. Coding

Setelah desain selesai, masuk ke tahap coding. Tahap ini tidak langsung membuat code dari tiap objek dari hasil desain sebelumnya. Pembuatan Unit Test untuk menguji tiap class didahulukan. Contoh Unit Test yang akan dibuat adalah sebagai berikut :

import unittest

def test_qdisc(self):

red = RED()

self.assertEqual(red.qdisc, 'root red')

def test_red(self):

red = RED()

self.assertEqual(red.setRed(128000),'/sbin/tc qdisc add dev

eth0 root red limit 64000 min 4000 max 8000 burst 5 avpkt 1000

probability 0.02 bandwidth 128')

if __name__ == '__main__':

unittest.main()

Terlihat pengujian terhadap class RED dilakukan untuk menguji attribute qdisc dan fungsi setRed. Penggunaan fungsi assert equal digunakan untuk membandingkan antara hasil output dan nilai seharusnya yang keluar. Pengujian dilakukan untuk semua class yang ada. Setelah beberapa unit test dibuat, implementasi dari desain bisa dilakukan. Tahap penulisan kode dimaksimalkan untuk lolos dari unit test. Hal ini berguna untuk mencegah dari adanya bug pada kode yang ditulis. Berikut contoh kode untuk RED :

class RED():

def __init__(self, dev = 'eth0', bandwidth=384000):

self.bandwidth = bandwidth # bps

self.maxupload = bandwidth / 8 # Byte

self.limit = 0

self.max = 0

self.burst = 0

self.latency = 0.5 # detik

self.avpkt = 1000 # 1000 nilai default dari red

self.probability = 0.02 # probabilitas untuk mark dan drop

20%

self.tc = '/sbin/tc'

self.command = 'qdisc add'

self.dev = dev

self.qdisc = 'root red'

self.space = ' '

def setRed(self, bandwidth, probability=0.02, latency=0.5):

try: self.latency = latency self.probability = probability self.bandwidth = bandwidth self.maxupload = bandwidth / 8

self.max = self.maxupload * self.latency

self.min = self.max / 2

self.limit = self.max * 8

self.burst = (2 * self.min + self.max) / (3 *

self.avpkt)

self.burst = self.burst

val = self.addQdisc()

except:

print 'bad value'

def getRED(self):

return self.setRed(self.bandwidth)

def addQdisc(self):

perintah = self.tc + self.space

perintah += self.command + self.space

perintah += 'dev ' + self.dev + self.space

perintah += self.qdisc + self.space

perintah += 'limit' + self.space + str(int(self.limit)) +

self.space

perintah += 'min' + self.space + str(int(self.min)) +

self.space

perintah += 'max' + self.space + str(int(self.max)) +

self.space

perintah += 'burst' + self.space + str(self.burst) +

self.space

perintah += 'avpkt' + self.space + str(self.avpkt) +

self.space

perintah += 'probability' + self.space +

str(self.probability) + self.space

perintah += 'bandwidth' + self.space +

str(self.bandwidth/1000)

return perintah

return '/sbin/tc qdisc del dev ' + self.dev + ' root'

Setelah kode ditulis, langsung dilakukan pengetesan dengan test case yang sebelumnya dibuat. Berikut hasil dari eksekusi unit test tersebut :

..F.

=================================================================

=====

FAIL: test_red (__main__.TestRED)

---

Traceback (most recent call last):

File "test.py", line 28, in test_red

self.assertEqual(red.setRed(128000),'/sbin/tc qdisc add dev

eth0 root red limit 64000 min 4000 max 8000 burst 5 avpkt 1000

probability 0.02 bandwidth 128')

AssertionError: '/sbin/tc qdisc add dev eth0 root red limit 64000

min 4000 max 8000 burst 5.33333333333 avpkt 1000 probability 0.02

bandwidth 128' != '/sbin/tc qdisc add dev eth0 root red limit 64000

min 4000 max 8000 burst 5.33 avpkt 1000 probability 0.02 bandwidth

128'

---

Ran 4 tests in 0.000s

Terlihat ada gagal pada unit test tersebut. Hal ini karena terdapat perbedaan antara hasil output dan nilai yang seharusnya keluar. Terdapat perbedaan pada statement burst yang seharusnya bernilai 5 tapi output dari fungsi yang diuji adalah 5.33333333333. Untuk itu perlu diperbaiki fungsi tersebut. Nilai burst yang seharusnya bilangan bulat bukannya pecahan. Sehingga kode berikut self.burst = self.burst dirubah menjadi self.burst = int(math.ceil(self.burst)).

Eksekusi kembali unit test sebelumnya dan didapat hasil berikut : ....

---

Ran 4 tests in 0.000s

Proses perubahan kode secara terus menerus sampai didapat kode yang sederhana dinamakan refactoring. Refactoring merupakan aspek penting pada metode Extreme Programming. Karena detil kode untuk tiap class tidak dijelaskan, maka pada tahap inilah penulisan kode akan melebihi desain dan terus mengembangkan desain tersebut.

Lakukan terus perubahan dan pecahkan fungsi yang memiliki terlalu banyak baris kode menjadi beberapa fungsi. Dengan begitu fungsi akan mudah dimengerti cara kerjanya. Secara tidak langsung mengembangkan desain sederhana yang sebelumnya dibuat tanpa merubah cara program berjalan.

4.4. Testing

Untuk menguji bug pada kode yang ditulis sebelumnya, unit test yang sebelumnya telah dibuat dieksekusi. Lakukan refactoring terus menerus sampai bug hilang. Untuk menguji fungsionalitas dari aplikasi digunakan BlackBox Testing.

4.4.1 Unit Testing

Setelah semua kode ditulis, lakukan eksekusi terhadap unit test yang telah dibuat. Sebaiknya tambahkan lebih banyak test case untuk tiap unit case. Hal ini diperlukan untuk mendeteksi bug yang kemungkinan muncul akibat proses refactoring sebelumnya.

Setelah beberapa iterasi dihasilkan test case untuk beberapa fungsi. Berikut adalah potongan test case yang akan diuji,

class TestRED(unittest.TestCase):

"RED tests"

def test_red(self):

red = RED('eth0', 128000)

self.assertEqual(red.getRED(),'/sbin/tc qdisc add dev eth0

root red limit 64000 min 4000 max 8000 burst 5 avpkt 1000

probability 0.02 bandwidth 128')

red = RED()

self.assertEqual(red.delRED(), '/sbin/tc qdisc del dev eth0

root')

class TestHTB(unittest.TestCase):

"HTB tests"

def test_class(self):

classifier = Classifier('eth0', '1:1', '1:2', '64Kbit',

'1Mbit')

self.assertEqual(classifier.getClass(), '/sbin/tc class add

dev eth0 parent 1:1 classid 1:2 htb rate 64Kbit ceil 1Mbit')

class TestClient(unittest.TestCase): "Client tests" def test_client(self): self.client = Client('Client 1','192.168.1.10', 64000, 64000, 512000, 128000,'00:FF:00:10:AF:89') self.assertEqual(self.client.get_name(), 'Client 1') self.assertEqual(self.client.get_ip(), '192.168.1.10') self.assertEqual(self.client.get_dload(), 64000) self.assertEqual(self.client.get_uload(), 64000) self.assertEqual(self.client.get_dmax(), 512000) self.assertEqual(self.client.get_umax(), 128000) self.assertEqual(self.client.get_mac(), '00:FF:00:10:AF:89')

class TestBandwidthConsumption(unittest.TestCase): "BandwidthConsumption tests" def test_BConsumption(self): bc = BandwidthConsumption() class TestTC(unittest.TestCase): "TC tests" def test_TC(self): tc = TC()

Dan hasil yang didapat setelah mengeksekusi test case di atas adalah sebagai berikut, .... --- --- Ran 6 tests in 0.000s OK 4.4.2 BlackBox Testing

Pada blackbox testing penulis mencoba melakukan tes terhadap semua fungsionalitas dari aplikasi ini. Berikut beberapa hasil tes yang penulis lakukan terhadap aplikasi dan hasilnya,

1. Pengujian Set firewall untuk fungsi SNAT atau Masquerade.

Gambar 4.17 pengujian firewall feature

Pengguna mengisi ip public yang digunakan yang nantinya akan digunakan sebagai source NAT. Interface yang berhubungan dengan internet dan jaringan lokal diatur di sini.

Gambar 4.18 cek firewall

Pengecekan apakah SNAT di iptables berhasil dieksekusi atau tidak. Hasilnya menunjukkan berhasil memberikan satu rule untuk SNAT.

Gambar 4.19 pengujian masquerade

Berbeda dengan yang tadi, di sini dilakukan pengetesan untuk masquerade. Perubahan SNAT secara dinamis dan pengaturan interface. Cara yang dilakukan hampir sama dengan sebelumnya.

Gambar 4.20 cek masquerade

Terlihat pengaturan sebelumnya berhasil memberikan satu rule ke iptables untuk melakukan masquerade.

Gambar 4.21 pengujian max download dan upload

Di sebelah kanan terdapat pengaturan untuk maksimum dan minimum upload yang diijinkan. Pengaturan ini bergantung pada koneksi internet yang kita miliki.

Gambar 4.22 cek tc max rate

Pengaturan untuk download berhasil dan menambah rule pada TC dengan HTB qdisc.

Gambar 4.23 cek tc max rate

Pengaturan upload dengan RED qdisc juga berhasil dilakukan di sini. 3. Pengujian Tambah, Ubah dan Hapus Client.

Gambar 4.24 pengujian tambah node

Di sini dilakukan pengujian untuk menambah client yang ingin diatur alokasi bandwidthnya.

Gambar 4.25 penambahan node

Gambar 4.26 cek tc leaf

Gambar 4.27 pengubahan node

Client yang sebelumnya telah ditambah, dapat diubah parameternya. Pengujian perubahan parameter dilakukan di sini.

Gambar 4.28 cek perubahan pada leaf Perubahan parameter berhasil merubah rule pada tc yang ada.

Gambar 4.29 penghapusan node

Perintah hapus dilakukan di sini. Pengujian untuk menghapus rule client dari table dan rule TC.

Gambar 4.30 cek penghapusan pada tc Terlihat sudah terhapus rule dari client yang dihapus tersebut.

Gambar 4.33 pengujian tampilan plot Tabel 4.4 Pengujian black box

Fungsi Status

Set firewall untuk fungsi SNAT atau Masquerade OK

Set Max Download dan Max Upload rate OK

Tambah, Ubah dan Hapus Client OK

Set Upload Rate OK

4.5. Release

Tahap ini aplikasi sudah dapat diimplementasikan, dan penulis melakukan pengujian implementasi untuk membuktikan apakah aplikasi dapat memenuhi fungsinya sebagai bandwidth limiting.

4.5.1 Implementation Test

Penulis akan melakukan implementation tes dengan beberapa node yang berhubungan langsung dengan gateway. Berikut topologi jaringan yang digunakan :

Gambar 4.34 Topologi jaringan pengujian Pengujian akan dilakukan dengan beberapa parameter, di antaranya:

1. Rate : 64kbps, max rate : 64kbps 2. Rate : 64kbps, max rate : 128kbps 3. Rate : 128kbps, max rate : 128kbps 4. Rate : 128kbps, max rate : 256kbps

Berikut hasil dari pengujian alokasi bandwidth untuk tiap node yang melewati gateway:

1. Pengujian rate : 64kbps, max rate 64kbps

Gambar 4.35 Pengujian node download dan upload 64kbps 2. Pengujian rate : 64kbps, max rate 128kbps

node kecepatan 64kbps, kecepatan maksimum 128kbps. 3. Pengujian rate : 128kbps, max rate 128kbps

Gambar 4.37

Pengujian node kecepatan

128kbps, maksimum 128kbps.

Gambar 4.38 Pengujian node kecepatan 128kbps, maksimum kecepatan 256kbps.

4.5.2 QoS Testing

Setelah pengujian aplikasi berjalan dengan baik dan sesuai dengan desain sebelumnya. Pengujian lanjutan untuk menguji pengaturan QoS berjalan dengan baik atau tidak. Pengujian akan dilakukan dengan 2 situs pengujian, yaitu speedtest.net untuk menguji throughput dan pingtest.net untuk menguji delay, jitter dan packet loss.

Pengujian pertama akan dilakukan dengan menggunakan disiplin antrian HTB saja. Terdapat 3 node yang terhubung dengan gateway dan scenario pengujian menggunakan server lokal dan internasional,

1. Tiap node diberi kecepatan download 128kbps, maksimum 128 kbps dan upload 32 kbps maksimum 32kbps.

Koneksi Node 1 Node 2 Node 3 Upload Download Upload Download Upload Download IIX 30 kbps 126 kbps 34 kbps 127 kbps 24 kbps 118 kbps Internasional 28 kbps 131 kbps 39 kbps 125 kbps 29 kbps 117 kbps

Tabel 4.6 QoS Testing 1, hasil Pingtest.net

2. iap

node diberi kecep atan download 128kbps, maksimum 256kbps dan upload 32kbps

maksimum 64kbps.

Tabel 4.7 QoS Testing 2, hasil Speedtest.net

Koneksi Node 1 Node 2 Node 3

Upload Download Upload Download Upload Download IIX 56 kbps 255 kbps 61 kbps 127 kbps 62 kbps 198 kbps Internasional 48 kbps 244 kbps 48 kbps 185 kbps 58 kbps 211 kbps

Tabel 4.8 QoS Testing 2, hasil Pingtest.net

Node 1 Node 2 Node 3

delay jitter Packet loss

1 56 ms 10 ms 0 % 51 ms 9 ms 0 % 54 ms 11 ms 0 %

delay jitter Packet loss

1 35ms 13ms 0 % 33 ms 11 ms 0% 38ms 15ms 0%

2 33ms 12ms 0 % 38 ms 13 ms 0% 32ms 16ms 0%

3. Tiap node diberi kecepatan 256kbps, maksimum 256kbps dan upload 64 kbps maksimum 64kbps.

Tabel 4.9 QoS Testing 3, hasil Speedtest.net

Koneksi Node 1 Node 2 Node 3

Upload Download Upload Download Upload Download IIX 75 kbps 255 kbps 52 kbps 262 kbps 60 kbps 278 kbps Internasional 70 kbps 244 kbps 64 kbps 248 kbps 62 kbps 286 kbps

Tabel 4.10 QoS Testing 3, hasil Pingtest.net

Node 1 Node 2 Node 3

delay jitter Packet loss

1 25 ms 8ms 0% 28 ms 6ms 0% 27 ms 8ms 0%

2 26 ms 9ms 0% 24 ms 5ms 0% 26 ms 9ms 0%

Pengujian pertama akan dilakukan dengan menggunakan disiplin antrian HTB dan RED untuk leaf class. Terdapat 3 node yang terhubung dengan gateway dan scenario pengujian menggunakan server lokal dan internasional,

1. Tiap node diberi kecepatan download 128kbps, maksimum 128 kbps dan upload 32 kbps maksimum 32kbps

Tabel 4.11 QoS Testing 4, hasil Speedtest.net

Koneksi Node 1 Node 2 Node 3

Upload Download Upload Download Upload Download IIX 32 kbps 127 kbps 34 kbps 127 kbps 32 kbps 128 kbps Internasional 28 kbps 124 kbps 32 kbps 128 kbps 32 kbps 126 kbps

Tabel 4.12 QoS Testing 4, hasil Pingtest.net

Node 1 Node 2 Node 3

delay jitter Packet loss

1 52ms 12ms 0% 65ms 16ms 0% 50ms 15ms 0%

2 77ms 14ms 1% 60ms 17ms 0% 49ms 14ms 0%

2. Tiap node diberi kecepatan download 128kbps, maksimum 256kbps dan upload 32kbps maksimum 64kbps.

Tabel 4.13 QoS Testing 5, hasil Speedtest.net

Koneksi Node 1 Node 2 Node 3

Upload Download Upload Download Upload Download IIX 65 kbps 226 kbps 64 kbps 228 kbps 62 kbps 232 kbps Internasional 60 kbps 222 kbps 59 kbps 209 kbps 58 kbps 218 kbps

Tabel 4.14 QoS Testing 5, hasil Pingtest.net

Node 1 Node 2 Node 3

delay jitter Packet loss

1 40ms 14ms 0% 38ms 14ms 0% 35ms 12ms 0%

2 38ms 13ms 0% 35ms 13ms 0% 40ms 15ms 0%

3. Tiap node diberi kecepatan 256kbps, maksimum 256kbps dan upload 64 kbps maksimum 64kbps.

Tabel 4.15 QoS Testing 6, hasil Speedtest.net

Koneksi Node 1 Node 2 Node 3

Upload Download Upload Download Upload Download IIX 64 kbps 255 kbps 64 kbps 256 kbps 64 kbps 255 kbps Internasional 62 kbps 254 kbps 60 kbps 252 kbps 62 kbps 256 kbps

Tabel 4.16 QoS Testing 6, hasil Pingtest.net

Node 1 Node 2 Node 3

delay jitter Packet loss

1 22ms 1ms 0% 21ms 1ms 0% 24ms 3ms 0%

2 23ms 2ms 0% 21ms 1ms 0% 22ms 2ms 0%

Dalam dokumen Pengembangan aplikasi DiffServ dengan disiplin antrian hierarchy token bucket dan random early detection sebagai bandwidth limiting (Halaman 94-128)