1

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: andarini.kd@gmail.com, ary.shiddiqi@gmail.com, bazz.04@gmail.com

S

Gambar 1. Sistem Streaming

2

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. PERANCANGAN DAN IMPLEMENTASI

PERANGKAT LUNAK

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)

3

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. UJI COBA DAN ANALISIS

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.4192.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

ServerKlien

Router

Switch

(a) (b)

4

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

5

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

6

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.

New Jersey: Prentice Hall.

7

[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.