Abstrak—Sebuah aplikasi video streaming yang menerapkan
algoritma enkripsi Rivest Cipher 5 (RC5) telah selesai dibuat. Pustaka yang digunakan adalah Java Media Framework untuk memproses video dan Bouncy Castle sebagai alat kriptografi pada IDE Java Netbeans. Aplikasi ini dimanfaatkan untuk mengetahui performa video streaming apabila diujicobakan pada sebuah jaringan komputer untuk pengiriman data secara unicast,
broadcast, dan multicast. Performa yang dimaksud adalah dalam
hal kualitas layanan (Quality of Service) pada jaringan yang meliputi delay, jitter, throughput, serta packet loss. Hasil uji coba menunjukkan bahwa ukuran file mempengaruhi delay dan
throughput, namun tidak mempengaruhi performa umum dari unicast, broadcast, dan broadcast. Unicast lebih unggul daripada broadcast dan multicast jika jumlah klien hanya dua. Namun jika
jumlah klien mencapai 5 buah, maka unicast lebih buruk daripada broadcast dan multicast dalam hal delay, jitter, dan
throughput. Di antara broadcast dan multicast, broadcast lebih
unggul daripada multicast baik untuk dua klien maupun lima klien.
Kata Kunci— streaming, enkripsi, unicast, broadcast, multicast
I. PENDAHULUAN
TREAMING merupakan suatu teknologi yang bisa digunakan untuk memainkan data audio atau video secara langsung maupun tidak langsung yang didapat dari sebuah mesin server [1]. Pemanfaatan video streaming dapat berupa video conference, yaitu telekomunikasi dengan menggunakan audio dan video sehingga terjadi pertemuan di tempat letaknya sangat berjauhan. Bagi perusahaan, teknologi ini dinilai sangat efisien karena menghemat biaya perjalanan untuk keperluan rapat atau pertemuan, biaya penginapan, konsumsi, dan lain-lain. Sedangkan untuk dosen dan pengajar, video streaming dapat diterapkan dalam bentuk e-learning berbasis video sehingga pengajar bisa memberikan materi belajar tanpa harus berada satu ruangan dengan para mahasiswa atau siswa.
Untuk menjaga keamanan pada data video yang dikirimkan melalui jaringan, maka dibutuhkan saluran yang aman dalam melakukan video conference. Salah satu cara yang dapat dilakukan adalah melakukan enkripsi pada data video.
Pengiriman data video itu sendiri dapat dilakukan dengan metode unicast, broadcast, dan multicast. Ketiga cara tersebut memiliki kelebihan dan kekurangan masing-masing. Dalam unicast hanya ada satu pengirim dan satu penerima. Metode broadcast dapat mengirimkan paket kepada seluruh komputer
di jaringan lokal namun router akan kebanjiran data. Multicast terlihat lebih efektif karena hanya mengirimkan paket kepada komputer yang tergabung pada satu grup multicast.
Berdasarkan permasalahan dan ide di atas, maka dibuatlah sebuah aplikasi video streaming yang menerapkan enkripsi untuk menjaga kerahasiaan data. Algoritma enkripsi yang digunakan adalah Rivest Cipher 5 (RC5). Data video akan dikirimkan dari server menuju klien dengan tiga metode yang berbeda, yaitu unicast, broadcast, dan multicast.
II. DASAR TEORI
Pada bagian ini akan dijelaskan beberapa hal mengenai teori yang berkaitan dengan perangkat lunak yang diimplementasikan. Hal ini ditujukan untuk memberikan gambaran secara umum terhadap sistem yang akan dibuat. A. Video Streaming
Video streaming merupakan proses mengalirkan data video dari suatu pengirim kepada satu atau beberapa penerima [3]. Konsep dasa’r dari video streaming adalah membagi paket video menjadi beberapa bagian, mentransmisikan paket-paket tersebut, lalu pihak penerima melakukan decoding pada potongan video tersebut dan dapat memainkannya tanpa harus menunggu seluruh file terkirim ke mesin penerima.
Sistem streaming umumnya tersusun dari kombinasi antara server, perangkat lunak untuk memainkan video, transmisi, serta metode encoding/decoding yang digunakan. Ilustrasi untuk sistem streaming ini dapat digambarkan pada Gambar 1.
user mengunjungi suatu situs dan menemukan file yang ingin dia
mainkan
server web mengirimkan pesan berupa file
spesifik pada server media untuk melakukan strreaming server streaming mengirimkan file ke komputer user, dengan melewati server web
perangkat lunak klien membaca sandi dan
memainkan file
1 2
3
4
Analisis Pengiriman Frame Video Terenkripsi
secara Unicast, Broadcast, dan Multicast
Andarini Kartika D., Ary Mazharuddin S., Baskoro Adi Pratomo
Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember (ITS) Jl. Arief Rahman Hakim, Surabaya 60111
E-mail: [email protected], [email protected], [email protected]
S
B. RC5
Algoritma RC5 merupakan metode enkripsi yang menggunakan metode enkripsi simetrik dan pengolahan data dalam bentuk block cipher. Operasi-operasi yang digunakan pada algoritma RC-5 merupakan operasi-operasi yang sederhana, antara lain modular addition, XOR, dan cyclic rotation. Parameter-parameter yang diperlukan untuk membangun enkripsi RC5 adalah jumlah putaran (round), jumlah word (w), serta kata kunci.
Terdapat tiga proses utama pada algoritma RC5. Yang pertama adalah perluasan kunci, yang kedua adalah proses enkripsi, dan yang terakhir adalah proses dekripsi. Proses perluasan kunci berfungsi untuk memperluas sebuah string yang diberikan oleh pengguna agar mengisi array kunci rahasia.
C. Unicast, Broadcast, dan Multicast
Pengiriman data pada jaringan komputer berdasarkan tujuan dari paket data terbagi menjadi tiga jenis, yakni unicast, broadcast, multicast.
Transmisi unicast merupakan transmisi pesan yang dilakukan dari satu pengirim ke satu host penerima. Istilah broadcast merujuk pada proses dalam jaringan komputer dimana pengiriman datanya bersifat satu arah. Metode multicast adalah sebuah teknik dimana data dikirimkan melalui jaringan kepada komputer-komputer yang tergabung pada grup multicast tertentu. Sebuah grup multicast memiliki sebuah alamat multicast. Alamat multicast pada IPv4 adalah alamat kelas D, sedangkan pada IPv6 alamat multicast sudah otomatis didapatkan dari IPv6. Pada kelas D IPv4, alamat yang direservasikan untuk sebuah grup multicast adalah 224.0.0.0 hingga 239.255.255.255.
D. Kualitas Layanan
Kualitas layanan atau kinerja layanan atau yang lebih dikenal dengan istilah quality of service (QoS) merupakan suatu pengukuran mengenai seberapa baik kinerja dari jaringan. [2]. Parameter yang dapat diukur dalam performa jaringan antara lain delay, jitter, throughput, serta packet loss.
III. PERANCANGANDANIMPLEMENTASI PERANGKATLUNAK
A. Alur Kerja Sistem
Gambar 2 merupakan skema alur kerja sistem secara lengkap dengan melibatkan proses utama yang dilakukan oleh aplikasi ini.
Pada aplikasi ini, data video yang akan dikirimkan dari server menuju klien tidak dapat langsung dikirimkan secara mentah, namun harus melalui proses pembuatan sandi (encoding) dan dienkripsi dahulu. Sebaliknya, pada sisi klien, karena data video yang datang merupakan data video terenkripsi dan tersandi, maka klien harus melakukan dekripsi dan pembacaan sandi (decoding) pada data video untuk mendapatkan data video asli yang bisa ditampilkan.
Tujuan dari encoding ini adalah untuk mendapatkan format data yang cocok untuk dikirimkan melalui jaringan komputer. Setelah melalui proses encoding, data video kemudian dienkripsi dengan algoritma enkripsi RC5. Ciphertext hasil enkripsi ini kemudian dikirimkan kepada klien yang berkepentingan untuk menerima data video tersebut. Data video yang dikirimkan berupa paket-paket datagram.
Proses selanjutnya berjalan pada sisi klien. Paket datagram berisi data video terenkripsi yang datang diterima oleh klien lalu didekripsi. Hasil dekripsi ini adalah data video yang kemudian dibaca sandinya untuk mengkonstruksi sebuah video yang dapat ditampilkan ke layar monitor dengan bantuan sebuah alat pemutar video. Proses Mengirim dan Menerima Video
Proses ini diilustrasikan pada Gambar 3(a). Data video ditampung terlebih dahulu pada sebuah DataSource yang kemudian dibuatkan Processor. Processor merupakan interface yang memiliki fungsi untuk memproses dan mengatur data media yang bebasis waktu. Berbeda dengan Player yang melakukan rendering pada data media, Processor mendukung interface yang bisa diprogram dan memungkinkan kontrol pada saat memproses media, serta memungkinkan akses untuk menghasilkan stream data. Pembuatan Processor ini dilakukan oleh kelas Manager yang dimiliki oleh Java Media Framework. Setelah itu dibuat sebuah transmitter yang digunakan untuk mengirimkan data video.
Gambar 2. Alur Kerja Sistem
Gambar 3. (a) Proses Mengirim Video, (b) Proses Menerima Video (a) (b)
Proses ini diilustrasikan pada Gambar 3(b). Pertama-tama komputer akan memulai tugasnya dengan membentuk suatu sesi terlebih dahulu. Sesi ini digunakan untuk menerima data. Jika ada data yang datang dan data tersebut berhasil didekripsi dan dibentuk ulang menjadi sebuah file video yang dapat dimainkan, maka klien bisa menampilkan video tersebut pada layar monitornya.
B. Proses Enkripsi Dekripsi RC5
Proses enkripsi pada aplikasi ini dilakukan dengan bantuan pustaka Bouncy Castle. Aplikasi ini menggunakan algoritma RC5 untuk melakukan enkripsi secara simetrik. Diagram alir proses enkripsi ini ditunjukkan pada Gambar 4(a).
Sebelum dapat dimasukkan pada proses enkripsi, plaintext dipecah dahulu menjadi blok-blok dengan ukuran tertentu dalam bit. Blok plaintext ini kemudian dienkripsi dengan algoritma RC5 yang telah diinisialisasi dengan mode "encrypt" dan diberi kunci rahasia yang telah diproses. Luaran dari proses enkripsi ini adalah sebuah blok ciphertext. Karena algoritma RC5 yang digunakan adalah RC5 yang menggunakan padding, maka blok ciphertext akan memiliki padding untuk memenuhi blok ciphertext jika ukuran blok ciphertext tidak memenuhi ukuran standard dari blok untuk RC5.
Sama dengan proses enkripsi, proses dekripsi juga dilakukan dengan memanfaatkan pustaka Bouncy Castle. Diagram alir untuk proses dekripsi data bisa dilihat pada Gambar 4(b).
Pertama-tama Cipher diinisialisasi dulu sehingga berada pada mode "decrypt", serta diberi parameter kunci rahasia. Blok ciphertext yang datang didekripsi sehingga menghasilkan blok plaintext. Jika ada padding pada ciphertext yang datang, maka padding ini akan dihilangkan terlebih dahulu sebelum dilakukan proses dekripsi pada ciphertext. Luaran dari proses dekripsi adalah blok plaintext, yang nantinya diterjemahkan sebagai data video dan dimainkan oleh alat pemutar video. C. Implementasi Multicast Routing
Routing multicast bisa diimplementasikan dengan perkakas bernama smcroute yang berjalan sebagai daemon
pada sistem operasi Linux. Perkakas ini menerapkan multicast routing yang bersifat statis. Jadi pengguna harus mendaftarkan seluruh IP yang mungkin akan mengirimkan paket multicast, menggabungkan IP pengirim ke dalam grup multicast, serta pada interface mana paket multicast tersebut akan diteruskan. Perintah pendaftaran ini formatnya adalah:
smcroute -a <InterfaceInput> <IPAddressSrc> <IPAddressGroup> <InterfaceOutput>
[<InterfaceOutput>]...
IV. UJICOBADANANALISIS A. Skenario Uji Coba
Terdapat tiga buah skenario untuk melakukan uji coba performa aplikasi video streaming ini, yang akan dijelaskan sebagai berikut.
1) Skenario Pengujian dengan VariasiUkuran File
192.168.1.4
192.168.1.3
Klien
Server
Gambar 6(a) menerangkan skenario pengujian performa untuk mengetahui pengaruh perbedaan ukuran file terhadap kualitas layanan yang dilakukan pada satu subnet. Dalam pengujian ini digunakan satu server dan satu klien. Server memiliki IP 192.168.1.3, sedangkan IP klien adalah 192.168.1.4. Sedangkan Gambar 6(b) merupakan arsitektur jaringan yang digunakan untuk menguji performa perbedaan ukuran file saat ditransmisikan ke subnet yang berbeda. 2) Skenario Pengujian dengan Variasi Jumlah Klien
192.168.1.4
192.168.1.2
192.168.1.3
Klien Klien
Server
Arsitektur jaringan untuk pengujian performa dengan 2 buah klien ditunjukkan pada Gambar 7(a). Server merupakan komputer dengan IP 192.168.1.3, sedangkan kedua klien memiliki IP 192.168.2 dan 192.168.1.4. Gambar 7(b) merupakan ilustrasi arsitektur untuk pengujian performa dengan melibatkan lima buah klien. Server memiliki IP 192.168.1.3, sedangkan klien berturut-turut memiliki IP 192.168.1.2, 192.168.1.4, 192.168.1.5, 192.168.1.6, dan 192.168.1.7.
B. Hasil Uji Coba Performa dengan Variasi Ukuran File Dari arsitektur yang terdapat pada Gambar 6, dilakukan uji coba performa kualitas layanan yang meliputi delay, jitter, serta (a) (b)
Gambar 4. (a) Proses Enkripsi Video, (b) Proses Dekripsi Video
Gambar 5. Pendaftaran IP Multicast pada Smcroute
Gambar 6. Skenario Pengujian dengan Variasi Ukuran File (a) Satu Subnet, (b) Dua Subnet
Gambar 7. Skenario Pengujian dengan Variasi Jumlah Klien (a) Dua Klien, (b) Lima Klien
192.168.1.4 192.168.1.2 192.168.1.3 Server Klien Switch 192.168.1.5 192.168.1.6 192.168.1.7 Switch
Klien Klien Klien Klien (a) (b) 192.168.0.1 192.168.0.2 192.168.1.1 192.168.1.3 Server Klien Router Switch (a) (b)
throughput. Hasil pengujian dengan lima file yang berbeda diuraikan pada penjelasan di bawah ini.
1) Uji Coba Delay
Gambar 8(a)-(e) merupakan grafik hasil pengujian delay untuk lima file dengan ukuran yang berbeda. Dari grafik pada Gambar 8, dapat dilihat bahwa file kedua memiliki delay rata-rata yang paling kecil, sedangkan file kelima memiliki delay rata-rata yang paling besar.
2) Uji Coba Jitter
Gambar 9(a)-(e) merupakan grafik hasil pengujian jitter untuk lima file dengan ukuran yang berbeda. Dari grafik pada Gambar 9, dapat dilihat bahwa jitter yang dialami ketika pengiriman lima file yang berbedaa nilainya relatif sama.
3) Uji Coba Throughput
Gambar 10(a)-(e) merupakan grafik hasil pengujian throughput untuk lima file dengan ukuran yang berbeda. Dari grafik pada Gambar 10, dapat dilihat bahwa file kedua memiliki throughput rata-rata yang paling besar, sedangkan file kelima memiliki throughput rata-rata yang paling kecil.
4) Uji Coba Packet Loss
Berdasarkan uji coba yang telah dilakukan terhadap 5 file yang berbeda, packet loss yang tercatat sebesar 0% untuk setiap skenario pengujian.
5) Analisis Uji Coba Performa dengan Variasi Ukuran File File pertama yang diujicobakan memiliki ukuran 26,150 KB, frame rate 25,0, dan berdimensi 352 x 288 piksel. File kedua yang diujicobakan memiliki ukuran 1,380 KB, frame rate 24,0, dan ukuran frame 352 x 240 piksel. File ketiga ini memiliki ukuran file sebesar 6,308 KB, frame rate 29,9, serta ukuran frame 320 x 240 piksel. File keempat ini memiliki ukuran file sebesar 817 KB, frame rate 25,0, serta ukuran 384 x 284 piksel. Untuk pengujian file yang terakhir, digunakan file berukuran 22.018 KB, dengan frame rate 30,0, dan dimensi 320 x 240 piksel.
Berdasarkan hasil pengujian performa dengan menggunakan lima buah file video yang berbeda untuk lima buah skenario yang berbeda, didapatkan bahwa ukuran file ternyata berpengaruh terhadap delay, jitter, serta throughput pada saat pengiriman video. Namun ukuran file tidak mempengaruhi performa umum dari arsitektur unicast, broadcast, serta multicast.
Jika dilihat pada grafik dapat diambil suatu pernyataan bahwa semakin besar ukuran file, maka semakin besar pula delay, jitter, namun semakin kecil throughput yang dialami oleh pengirim dan penerima. Namun tidak hanya ukuran file saja yang mempengaruhi performa ini, namun dimensi file dan frame rate juga ikut diperhitungkan. Meskipun ukuran file kecil, namun jika dimensi atau frame rate lebih besar daripada file lain, file tersebut akan mengalami delay dan jitter yang Gambar 8. Grafik Hasil Uji Coba Delay untuk (a) File Pertama, (b) File
Kedua, (c) File Ketiga, (d) File Keempat, dan (e) File Kelima (c) (d) (a) (b) (e) (a) (b) (c) (d) (e)
Gambar 9. Grafik Hasil Uji Coba Jitter untuk (a) File Pertama, (b) File Kedua, (c) File Ketiga, (d) File Keempat, dan (e) File Kelima
(a) (b)
(c) (d)
(e)
Gambar 10. Grafik Hasil Uji Coba Throughput untuk (a) File Pertama, (b) File Kedua, (c) File Ketiga, (d) File Keempat, dan (e) File Kelima
lebih lama, serta throughput yang lebih kecil daripada file lain dengan ukuran sama namun memiliki frame rate dan dimensi yang lebih kecil.
Performa unicast, broadcast, dan multicast tetap sebanding meskipun file yang digunakan untuk pengiriman berbeda-beda ukuran, frame rate, dan dimensinya. Secara umum performa delay dan jitter untuk unicast lebih kecil daripada broadcast dan multicast. throughput untuk unicast, broadcast, dan multicast relatif sama dan sebanding untuk masing-masing file yang dikirimkan.
C. Uji Coba Performa dengan Variasi Jumlah Klien
Dari arsitektur yang terdapat pada Gambar 7, dilakukan uji coba performa kualitas layanan yang meliputi delay, jitter, serta throughput. Hasil pengujian dengan dua klien dan lima klien yang berbeda diuraikan pada penjelasan di bawah ini.
1) Uji Coba Delay
Gambar 11(a)-(f) merupakan grafik hasil pengujian delay untuk dua klien dan lima klien dengan arsitektur yang berbeda. Dari grafik pada Gambar 11, dapat dilihat bahwa delay yang dialami ketika pengiriman file secara unicast untuk lima klien merupakan yang terbesar nilainya di antara yang lain.
2) Uji Coba Jitter
Delay dan jitter merupakan satu satuan yang hampir sama. Delay merupakan keterlambatan dalam waktu transmisi data dari pengirim dan penerima, satuan dari delay adalah sekon (detik) atau milisekon (milidetik). Sedangkan jiter merupakan variasi dari delay atau selisih antara delay pertama dengan delay selanjutnya.
Gambar 12(a)-(f) merupakan grafik hasil pengujian jitter untuk dua klien dan lima klien dengan arsitektur yang berbeda. Dari grafik pada Gambar 12, dapat dilihat bahwa jitter yang dialami ketika pengiriman file secara unicast untuk lima klien merupakan yang terbesar nilainya di antara yang lain, serta yang variasinya paling besar.
3) Uji Coba Throughput (a) (b)
(c) (d)
(e) (f)
Gambar 11. Grafik Hasil Uji Coba Delay untuk (a) Unicast Dua Klien, (b) Unicast Lima Klien, (c) Broadcast Dua Klien, (d) Broadcast Lima Klien, (e) Multicast Dua Klien, dan (f) Multicast Lima Klien
(a) (b)
(c) (d)
Gambar 12. Grafik Hasil Uji Coba Jitter untuk (a) Unicast Dua Klien, (b) Unicast Lima Klien, (c) Broadcast Dua Klien, (d) Broadcast Lima Klien, (e) Multicast Dua Klien, dan (f) Multicast Lima Klien
(e) (f)
(a) (b)
(c) (d)
(e) (f)
Gambar 13. Grafik Hasil Uji Coba Throughput untuk (a) Unicast Dua Klien, (b) Unicast Lima Klien, (c) Broadcast Dua Klien, (d) Broadcast Lima Klien, (e) Multicast Dua Klien, dan (f) Multicast Lima Klien
Gambar 13(a)-(f) merupakan grafik hasil pengujian throughput untuk dua klien dan lima klien dengan arsitektur yang berbeda. Dari grafik pada Gambar 11, dapat dilihat bahwa throughput yang dialami ketika pengiriman file secara unicast untuk lima klien merupakan yang terkecil nilainya di antara yang lain, dan juga yang paling bervariasi.
4) Uji Coba Packet Loss
Nilai packet loss yang didapatkan dari pengujian untuk lima klien dan dua klien mencapai 0%. Packet loss muncul ketika satu paket data atau lebih yang sedang dikirimkan melalui jaringan mengalami kegagalan untuk dapat sampai kepada tujuan. Packet loss dapat menyebabkan masalah yang cukup berarti terutama pada beberapa aplikasi seperti video streaming atau Voice over IP, karena informasi yang hilang tidak dapat dikembalikan. Jika packet loss bernilai 0%, maka dapat dikatakan bahwa hampir tidak ada paket yang hilang atau terbuang pada proses pengiriman video dari server menuju ke klien.
5) Analisis Uji Coba Performa dengan Variasi Jumlah Klien Dalam pengujian performa dengan variasi jumlah klien yang terlibat, dapat disimpulkan bahwa jumlah klien berpengaruh terhadap performa umum dari arsitektur unicast, broadcast, serta multicast. Pada pengujian ini digunakan dua klien dan lima klien untuk setiap arsitektur yang diuji.
Pada pengujian dengan menggunakan dua klien, performa unicast lebihi baik daripada broadcast dan multicast. Hal ini dibuktikan dengan nilai delay dan jitter pada pengiriman secara unicast yang nilainya lebih kecil daripada jika data video dikirimkan secara broadcast dan multicast.
Jika digunakan lima klien sekaligus pada pengujian, performa unicast jauh lebih buruk daripada broadcast dan multicast. Delay untuk unicast dapat mencapai 3 detik, sementara broadcast dan multicast mengalami delay kurang dari 1 detik. Throughput pada masing-masing klien untuk pengiriman secara unicast pada lima klien juga sangat bervariasi untuk setiap klien, dan nilai throughput tersebut tergolong kecil jika dibandingkan dengan throughput yang didapat jika menggunakan arsitektur broadcast dan multicast.
Secara umum untuk perbandingan antara broadcast dan multicast dalam hal delay dan jitter, baik dengan jumlah klien dua buah maupun lima buah klien, broadcast relatif lebih unggul. Hal ini berdasar pada nilai delay dan jitter yang kecil pada saat pengiriman video secara broadcast daripada multicast.
V. KESIMPULAN
Dari hasil pengamatan selama perancangan, pengimplementasian, dan proses uji coba sistem didapatkan kesimpulan sebagai berikut.
1. Algoritma enkripsi RC5 dapat diimplementasikan pada pengiriman video dengan tujuan menjaga kerahasiaan data video yang dikirimkan. Pengimplementasian metode enkripsi RC5 pada aplikasi ini dimudahkan dengan bantuan pustaka Bouncy Castle yang telah memiliki berbagai algoritma kriptografi yang telah siap digunakan, termasuk RC5.
2. Data video dapat dikirimkan kepada penerima secara unicast, broadcast maupun multicast. Untuk penerusan paket multicast yang berbeda subnet, dapat digunakan paket smcroute yang berjalan sebagai daemon pada Linux. 3. Berdasarkan hasil uji coba aplikasi dalam hal performa,
didapatkan hal-hal di bawah ini:
a. Ukuran file yang berbeda tidak mempengaruhi performa umum unicast, broadcast, dan multicast. perbedaan ukuran file ini menyebabkan perbedaan delay, jitter, dan throughput. Semakin besar ukuran file, maka semakin besar delay dan semakin kecil throughput.
b. Jumlah klien mempengaruhi performa umum dari unicast, broadcast, dan multicast. Jika klien hanya 2, unicast lebih unggul daripada broadcast dan multicast dalam hal delay, jitter, dan throughput. Namun jika jumlah klien mencapai 5, maka broadcast dan multicast lebih unggul daripada unicast dalam hal delay, jitter, dan throughput. c. Waktu yang diperlukan untuk melakukan enkripsi
dan dekripsi adalah sekitar 23 nanodetik untuk waktu enkripsi dan 17 nanodetik untuk proses dekripsi.
d. Delay yang terjadi pada aplikasi video streaming masih dapat ditoleransi berdasarkan ketentuan ITU-T, karena delay yang terjadi tidak ada yang melebihi 450 ms.
e. Jitter juga termasuk baik karena rata-rata kurang dari 225 ms.
f. Throughput yang tercatat dapat mencapai 2,5 Mbps. g. Packet loss untuk keseluruhan uji coba pada semua
arsitektur mencapai 0%. Hal ini menandakan performa packet loss sangat baik.
DAFTAR PUSTAKA
[1] Burton S. Kaliski Jr., Yiqun Lisa Yin, 1998. On The Security of the RC5 Encryption Algorithm. USA: RSA Laboratories.
[2] Ze-Nian Li, Mark S. Drew, 2004. Fundamentals of Multimedia. New Jersey: Pearson Education Inc.
[3] Yao Wang, Joern Ostermann, Ya-Qin Zhang, 2002. Video Processing and Communication. New Jersey: Prentice Hall.
[4] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. RTP: A Transport Protocol for Real-Time Applications, IETF, RFC 1889, Januari 1996 [Online]. Tersedia pada http:/www.rfc-editor.org/rfc/rfc1889.txt. [5] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. RTP: A Transport
Protocol for Real-Time Applications, IETF, RFC 3550, Juli 2003 [Online]. Tersedia pada http:/www.rfc-editor.org/rfc/rfc3550.txt. [6] Ronald L. Rivest, 1997. The RC5 Encryption Algorithm. Massachussets:
MIT Laboratory for Computer Science.
[7] Ronald L. Rivest, The MD5 Message-Digest Algorithm, IETF, RFC 1321, April 1992 [Online]. Tersedia pada
http:/www.rfc-editor.org/rfc/rfc1321.txt
[8] Anonim.1999. JMF Guide 2.0. USA: Sun Microsystems, Inc. [9] S. Wenger, M.M. Hannuksela, T. Stockhammer, M. Westerlund, D.
Singer, RTP Payload Format for H.264 Video, IETF, RFC 3984, Februari 2005 [Online]. Tersedia pada
http:/www.rfc-editor.org/rfc/rfc3984.txt.
[10] S.E. Deering, Host extensions for IP multicasting, IETF, RFC 1054, Mei 1988 [Online]. Tersedia pada http:/www.rfc-editor.org/rfc/rfc1054.txt. [11] William Stallings. 1997. Data and Computer Communications. 5th ed.
[12] Andrew S. Tanembaum. 2003. Computer Networks. 4th ed. New Jersey: Prentice Hall.
[13] William Stallings. 2005. Cryptography and Network Security Principles and Practices. 4th ed. New Jersey: Prentice Hall.
