1. Latar Belakang
Media streaming adalah teknik yang digunakan untuk men-download objek media dari internet untuk segala jenis perangkat komunikasi. Sejak objek multimedia tidak perlu disimpan dalam memori, hal ini terutama cocok untuk alat komunikasi portable misalnya: mp3 player, ponsel, Personal Digital Assistant (PDA), perangkat navigasi Global Positioning System (GPS), dan seterusnya. Gadget ini biasanya termasuk komunikasi nirkabel yang terstruktur. Sebuah protokol standar yang digunakan untuk media streaming adalah Real Time Streaming Protocol (RTSP) [1]. Namun ada standar lain, termasuk HiperText Transfer Protocol (HTTP) [2], TCP Friendly [3], Stream Control Protocol Transmission (SCTP) [4] atau protokol tertentu seperti Microsoft Media Services (MMS). Semua dari sesi protokol tersebut terorientasi (sementara pengguna men-download objek media, sesi dibuka di media server). Jika komunikasi antara klien (pengguna) dan server rusak selama transmisi pada waktu periode tertentu, server menutup sesi.
Kejadian tak terduga dari saluran nirkabel waktu ke waktu [5] (teknologi yang biasa menderita masalah ini khususnya WiFi [6]) kejadian tak terduga ini menghambat klien terminal untuk memprovokasi kemampuan komunikasi (pengguna) untuk sementara. Ini berarti ada kemungkinan besar bahwa klien akan terputus selama transmisi jika cakupan hilang untuk periode waktu tertentu. Dalam hal ini, komunikasi rusak dan server memutuskan untuk menutup sesi (mempengaruhi waktu-off dan melompat jarak [7] negatif). Jika tidak, server akan mempertahankan dan membuka sesi untuk jumlah waktu yang tak tentu (tidak dapat diketahui kapan klien akan kembali) dengan mengorbankan sumber daya server. Yang terburuk adalah bahwa ketika klien terhubung kembali harus mulai menerima kembali objek media dari awal. Kemudian teknik media streaming sendiri menghasilkan kinerja yang sangat buruk. Kami pikir ini adalah masalah yang menantang yang harus dipecahkan secara efisien harus dipastikan bahwa klien akan menerima informasi yang hilang dan mereproduksi objek media saat menghubungkan di titik server.
2. Identifikasi Masalah
Pada identifikasi masalah ini tidak ada upaya yang mengenkapsulasi pesan RTSP menggunakan multiagen dan pesan sistem transportasi dan juga yang menggunakan buffer proaktif untuk memecahkan masalah ketidaksinambungan berselang. Dalam hal ini kami mengeksplorasi penggunaan JADE yang merupakan open source. Multi Agent System (MAS) yang benar-benar memenuhi rekomendasi Foundation for Intelligent Physical Agents (FIPA). JADE merupakan sebuah platform yang menarik karena mencakup Lightweight Extensible Agent Platform (LEAP) yang sedang digunakan untuk program telepon PDA dan mobile. Sampai saat ini, kinerja JADE belum dipelajari mengenai sesi streaming secara otomatis. Topik lainnya adalah untuk mengkaji kinerja platform JADE serta Message Transport Protocol (MTP) yang bisa membantu memberikan solusi tingkat tinggi untuk pemutusan berselang, dan menampilkan sebuah mekanisme kontrol proaktif pemutusan sesekali link WiFi berdasarkan proaktif buffer yang dikelola oleh agen JADE (satu untuk klien dan satu lagi untuk server RTSP). Kami telah menunjukkan kami Hasil mengeksekusi perangkat lunak pada dua komputer portabel interkoneksi oleh link WiFi. Awalnya kami amati bahwa kinerja JADE's sesuai dan MTP cukup baik.
3. Batasan Masalah
Agar penelitian terfokus dan tidak melebar maka ditetapkan batasan/ruang lingkup penelitian yang mencakup hal-hal sebagai berikut.
· Bagaimana menggunakan Multi Agent System(MAS)
· Penguraian karakteristik penting dari MAS untuk memecahkan masalah yang berasal dari intermiten nirkabel pemutusan.
· Mengevaluasi kinerja MTP dari JADE
· Mekanisme Automatic Resuming
· Keuntungan Mekanisme Yang Baru
4. Tujuan
Dari penelitian diatas untuk menggambarkan solusi yang efisien berdasarkan agen yang berjalan lebih dari komputer portabel yang dihubungkan oleh Wireless Fidelity (WiFi). Dalam percobaan praktis kami, dua agen dalam JADE platform (diinstal di komputer portabel). Mereka mengenkapsulasi standar sesi dari pesan kontrol Real Time Streaming Protocol (RTSP) dan multimedia datagrams untuk mencegat lalu lintas yang original antara klien dan server RTSP.
5. Landasan Teori
JADE
JADE (Java Agent Development Framework) adalah middleware yang dapat digunakan untuk mengembangkan dan menjalankan aplikasi peer to peer yang berdasarkan pada paradigma agent. Sesuai namanya bahasa pemrograman yang digunakan untuk mengembangkan agent dalam JADE adalah Java. JADE sebagai middleware yang memberikan fasilitas untuk pengembangan sistem berbasiskan agent menyediakan :
- Runtime environment yang menjadi tempat di mana agent dapat berjalan dan harus aktif pada host dimana agent akan bekerja.
- Pustaka berupa kelas-kelas yang dapat/harus digunakan untuk mengembangkan agent.
- Sekumpulan graphic tool yang digunakan untuk melakukan administrasi dan monitoring terhadap aktivitas agent yang sedang berjalan pada runtime environment.
Runtime environement dalam JADE dikenal dengan istilah container. Satu host dapat menjalankan lebih dari satu container dan setiap container bisa menangani beberapa agent. Sekumpulan container yang aktif disebut sebagai platform. Sebuah platform dapat memiliki container yang berasal dari host yang berbeda-beda. Satu platform harus memiliki satu container yang memiliki atribut sebagai main container yang aktif. Semua container yang aktif dan ingin bergabung dalam sebuah platform harus bergabung dengan mendaftarkan diri pada main container dan tidak boleh beratribut sebagai main container atau disebut juga normal container.
Selain menerima pendaftaran dari normal container sebuah main container selalu memiliki dua buah agent yang aktif secara otomatis ketika main container dijalankan. Kedua agent itu adalah:
- AMS (Agent Management Sistem) yang menyediakan naming service yang memastikan setiap agent dalam platform memiliki identitas yang unik. Selain itu AMS dapat merepresentasikan otoritas dalam platform di mana melalui AMS kita dapat menjalankan atau menghentikan agent dalam container yang terdaftar.
- DF (Directory Facilitator) adalah agent yang berfungsi sebagai “yellow pages” bagi platform. Melalui DF sebuah agent dapat mencari agent yang aktif dan layanan yang diberikan agent tersebut.
Multi Agent System(MAS)
Untuk pengetahuan karakteristik utama dari agen perangkat lunak (Otonomi, belajar, proactiveness, skalabilitas, fleksibilitas dan kehandalan) belum diteliti untuk mendapatkan metode cerdas streaming distribusi jaringan nirkabel menggunakan sistem pesan lewat untuk merangkum kontrol RTSP pesan. Agen dapat bekerja sama dalam memprediksi perilaku komunikasi nirkabel untuk menghindari (atau setidaknya mengurangi) dampak penurunan kinerja komunikasi di hadapan ketidaksinambungan nirkabel intermiten. Salah satu manfaat menggunakan MAS adalah bahwa hal itu menyederhanakan aplikasi desain. Hal ini karena layanan yang ditawarkan oleh MAS platform memungkinkan tingkat tinggi abstraksi untuk desain rincian messenger dan / atau Remote Method Invocation (RMI). Dengan cara ini perancangan aplikasi hanya untuk mengatasi pelaksanaan aturan bisnis (video streaming). Manfaat lainnya adalah MAS menawarkan: modularitas (mengurangi kerumitan perancangan perangkat lunak), skalabilitas, fleksibilitas (menambahkan atau menghapus agen sangat perilaku sederhana) dan pra-mapan agen (mengizinkan agen untuk menunjukkan perilaku baik proaktif dan reaktif). Untuk mengambil keuntungan dari manfaat di atas, penting untuk menggunakan platform MAS yang mencakup semuanya. JADE adalah sebuah platform tunggal terdiri dari satu atau lebih wadah yang dapat terletak di host yang berbeda dengan unik utama wadah menjalankan layanan RMI. Menawarkan yang berbeda implementasi tergantung pada ketersediaan sumber daya perangkat yang akan digunakan, yang membuat pilihan yang menarik. Sebuah solusi yang bekerja dengan baik pada Java 2 Platform, Standard Edition (J2SE) memiliki peluang bagus untuk bekerja sama dengan baik pada Java 2 Platform, Micro Edition (J2ME), menggunakan LEAP. Sebuah Manfaat tambahan adalah bahwa MTP dari JADE jaminan komunikasi antara agen tinggal di terdistribusi kontainer, sehingga menawarkan layanan kegagalan pemulihan.
6. Desain Arsitektur
Gambar. 1 menunjukkan arsitektur umum implementasi mekanisme. Jaringan akses terdiri dari sel wireles di mana salah satu gadget mobile dapat dihubungkan (untuk Misalnya menggunakan teknologi WiFi). Kami kira tepi Internet router yang Access Point WiFi dan komputer yang terhubung. Tepi router tersambung ke Jaringan Metropolitan tetap yang akses ke Internet Tetap di mana multimedia server streaming tersambung. Kami menganggap portabel komputer yang menerapkan multimedia streaming klien menggunakan RTSP sinyal dan Real Time Protocol (RTP) untuk media transmisi datagram. Klien ini menggunakan link WiFi untuk mengakses multimedia streaming server.
Gambar.1 Arsitektur Utama dari Mekanisme Sistem
Gambar. 2 Actions to Automatic resuming streaming sessions
Gambar. 2 menunjukkan langkah-langkah utama dari mekanisme pembukaan kembali untuk memecahkan ketidaksinambungan intermiten diuraikan dalam bagian I. Pertama (tindakan ditandai sebagai 1), klien isu permintaan RTSP (RTSP "SETUP URL" pesan). Kedua, APC (2) mengenkapsulasi dalam suatu jenis INFORM pesan dan pengalihan itu untuk APS yang mengirim (3) ke server (lagi sebagai RTSP "SETUP URL" pesan). Setelah server menerima bahwa pesan, ia mengirim kembali respon (yaitu RTSP "200 OK"). Kami kemudian menduga bahwa pada langkah 4 server telah menerima RTSP PLAY ketertiban dan mengirimkan kembali data menggunakan protokol RTP (setelah mengirimkan RTSP "200 OK" pesan). Data dicegat oleh APS yang menyimpan mereka sementara (5) dalam sebuah dimensioned penyangga dan juga mengirim mereka ke APC menggunakan USULAN jenis pesan. Pada titik ini APC menerima mereka (6) dan meneruskan yang datagrams media untuk klien (7), tetapi juga mengirim balik ACK jenis pesan ke APS (8) untuk mengkonfirmasi penerimaan blok terakhir dari media data yang diterima. Pesan ini dikemas dalam pesan INFORM. Setelah menerima APSACK jenis pesan yang akan menghapus data tersebut diakui dalam penyangga proaktif (ditandai sebagai buffer kosong pada langkah 9). Langkah-langkah ini dapat diulang untuk blok pengingat media data (10). Mari kita perhatikan bahwa tindakan 7 dan 9 yang tumpang tindih dengan penyimpanan data baru dalam tindakan 5. Dengan cara ini kita menyembunyikan mungkin overhead mekanisme kami. Ini serangkaian tindakan yang bisa dicapai sampai akhir proses streaming. Mari kita periksa tindakan untuk menangani intermittent pemutusan dari klien WiFi portabel (11) mempengaruhi multimedia komunikasi data. MTP berkala polling di langkah 8 dan 9 APC dan APS untuk menguji apakah mereka masih hidup. APS menambahkan temporal menyimpan frame media di buffer nya. Ukuran maksimal yang tepat buffer ini tergantung pada jumlah waktu klien terputus (dengan mesin server powered kami dapat mendukung beberapa menit disconecction) dan resolusi media frame (teknik kompresi).
7. Daftar Pustaka
[1] H. Schulzrinne, A. Rao, R. Lanphier, “Real Time Streaming Protocol (RTSP)”, Request for Comments: 2326, Standards Track, 1998.
[2] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, “HiperText Transfer Protocol (HTTP/1.1)”, Request for Comments: 2616, Standards Track, 1999.
[3] Deepak Bansal, Hari Balakrishnan, “TCP-friendly Congestion Control for Real-time Streaming Applications”, MIT Technical Report, MIT-LCS-TR806, May 2000.
[4] Randall R. Stewart, Qiaobing Xie, Stream Control Transmission Protocol (SCTP): A Reference Guide. Addison-Wesley, 2001.
[5] David Tse, Pramod Viswanath, Fundamentals of Wireless Communication. Cambridge University Press, 2005.
[6] IEEE P802.11, “The Working Group for Wireless LANs”, Available: http://grouper.ieee.org/groups/802/11/.
0 komentar