7 PERTIMBANGAN UNTUK MENDESAIN PROTOKOL APLIKASI PILIHAN

Tugas PAJ (Perancangan Aplikasi Jaringan):

TUJUH PERTIMBANGAN

UNTUK MENDESAIN PROTOKOL APLIKASI PILIHAN

Diterjemahkan oleh: Komarudin Tasdik

https://komarudintasdik.wordpress.com

Mendesain Protokol Pilihan

Mendesain protokol pilihan untuk client dan server anda agar dapat menggambarkan layanan apa yang client harus minta dan bagaimana server akan meresponnya. Berikut ini beberapa garis besar pertimbangan ketika mendesain protokol aplikasi pilihan.

1.      What Will the Message Format Be?

Apa format pesannya?

(Berbasis Teks atau Binari?)

Biasanya protokol client-server berbasis teks, sehingga formatnya berbasis delimeters. Contohnya, dalam SMTP, tiap perintah/command diakhiri dengan carriage return/linefeed pair. Tambahan pula, tiap command line terdiri dari command yang diikuti dengan sebuah space dan berbagai parameter.

Pesan-pesan protokol berbasis teks juga tergantung pada sensitivitas konteks. Karena itu, kami mengartikan bahwa susunan parameter dalam sebuah pesan itu penting, terutama ketika menggunakan delimeter. Ketika menguraikan command, aplikasi akan melihat dulu di mana command itu berada. Kemudian, Setelah command itu ditetapkan, aplikasi akan mengetahui bagaimana beberapa parameter berperan. Contohnya, jika command  harus memiliki dua parameter, kemudian delimiter bisa terjadi dalam parameter kedua tanpa diinterpretasikan sebagai delimiter. Ini sangat sesuai ketika delimiter itu merupakan sebuah  space/ruang.

Jika anda memutuskan berdasarkan protokol binari, maka format itu akan lebih penting. Contohnya, anda harus mengalamatkan masalah Big Endian/Little Endian untuk membedakan ukuran tipe data pada arsitektur perangkat keras client-server.

Format pesan kami akan mirip dengan yang digunakan oleh protokol IRC. Protokol ini digambarkan dalam RFC 1459—anda dapat menemukannya dengan menggunakan pencarian Google untuk “IRC+RFC”. Format dasar untuk pesan adalah command yang diikuti oleh satu atau lebih parameter. Tiap parameter dipisahkan dengan space, seluruh command diakhiri dengan carriage return/linefeed pair.

Kami juga akan memanfaatkan sensitivitas konteks. Pesan-pesan yang dikirimkan via chat seringkali mengandungs space. Pada command itu pesan dikirimkan, kami akan membuat pesan itu menjadi parameter terakhir. Dalam hal ini, kami tidak harus mengkhawatirkan space karena parser/pengurai akan mengetahui kesiapan pada parameter akhir dan tidak akan mencari lebih banyak delimiter.

Client command hanya terdiri dari karakter alpha. Server memiliki dua tipe pesan yang akan dikirim ke client: merespon client command dan pesan-pesan independen. Respon terhadap client command akan berupa kode numerik yang diikuti dengan space dan deskripsi yang user-friendly. Ini hanya digunakan untuk memberitahukan sukses atau gagal  dari client command. Pesan-pesan independen dari server akan mengikuti aturan-aturan format yang sama sebagai client command. Dengan server yang mengikuti rule ini, client akan segera mengetahui apakah suatu pesan merupakan sebuah respon terhadap sebuah command atau pesan independen. Ia akan mengecek apakah command itu mulai dengan numeric identifier atau urutan alpha.

2.      Will the Server Be Passive or Active?

Apakah server bersifat pasif atau aktif?

(Server menunggu request client atau tidak)

Jika server pasif, maka hanya akan bertindak ketika direquest oleh client. Komunikasi diawali hanya oleh client melalui submisi command. Setelah server mengeksekusi command dan memberikan respon, kemudian server itu menunggu client untuk mengajukan request/permintaan baru. Ini merupakan bagaimana protokol client-server tradisional didesain. Contohnya, SMTP, POP, dan HTTP semuanya menjalankan cara ini.

Jika server aktif, maka server harus mengkomunikasikan informasi kepada client tanpa menunggu client merequest apapun. Dalam hal ini, server tidak hanya menunggu client untuk menyampaikan request, tapi mungkin juga mengirim pesan ke client ‘dengan kemauan sendiri’. Jadi, client harus selalu terbuka untuk menerima pesan dari server, walaupun ketika client tidak membuat command. Chat server merupakan contoh server aktif. Setelah client terkoneksi, server dapat menyampaikan pesan kepadanya dari user lain tanpa client itu merequest apapun.

Server kita akan aktif. Ketika chatting dengan user lain, server dapat memiliki sebuah pesan untuk disampaikan kepada client kapanpun. Karena itu, kita tidak hanya harus mampu mengirimkan request kepada server, tapi juga harus dipersiapkan untuk menerima respon atas request kita dan pesan independen. Dalam hal ini, pesan-pesan dari server harus ditandai apakah ia merupakan respon terhadap request atau pesan-pesan dari user lain.

3.      Will the Server Handle Multiple Requests?

Apakah server akan menangani berbagai permintaan/request?

(Server bisa menangani beberapa request dalam satu waktu atau menunggu satu request selesai terlebih dahulu)

Banyak sekali protokol tradisional (SMTP, HTTP, POP, dll.) yang disetup hanya untuk menangani satu request dari satu client pada satu waktu. Ini berarti bahwa setelah client menyampaikan/submit command, harus menunggu server merespon command yang disubmit sebelumnya. Isu yang berbeda adalah apakah server dapat menangani request dari berbagai client. Kita lihat solusinya pada  Bab 5.

Jika client dapat mengirim pesan sebelum server memenuhi request sebelumnya, maka mekanisme untuk mengidentifikasi request itu dibutuhkan. Biasanya tiap pesan ditandai dengan nomor identifikasi unik agar ketika server memberikan respon, client tidak harus mengetahui request mana yang telah dipenuhi.

Implementasi menarik dari pengembangan protokol tradisional untuk menangani berbagai request digambarkan dalam RFC 1854: SMTP Service Extension for Command Pipelining. (Anda dapat menemukannya pada web dengan menggunakan pencarian Google untuk “RFC+1854”). Dalam hal ini, apabila server dapat mengatasi berbagai request dari satu client, server itu merespon request secara rapi. Ini mengeliminir kebutuhan atas beberapa nomor identifikasi command/respon, tapi ia meminta client  untuk mencocokkan respon dengan command yang sesuai.

Untuk chat server kita, client harus membuat hanya satu request pada satu waktu. Aplikasi ini tidak harus melakukan kalkulasi ekstensif atau pengumpulan data yang mengharuskan client berada dalam antrian request. Tiap request yang dibuat oleh client akan segera mendapatkan respon sukses/gagal dari server.

4.      Will the Protocol Be Sessioned or Sessionless?

Apakah protokol bersifat sessioned (menyimpan) atau sessionless?

(Nama di Facebook dan YM)

Konsep ini dibahas pada Bab 4, tapi dianggap penting dalam desain protokol pilihan. Berbicara tentang sessionless protocol, state tidak dipelihara di antara client request seperti halnya sessioned protocol.

Kami akan menggunakan session protocol untuk chat server kita. Setelah kita mengikuti prosedur login dengan client, server akan menyimpan nama panggilan client (nickname) dan menghubungkannya dengan koneksi. Sebuah alasan baik atas penggunaan nama panggilan ini. Ketika client melakukan login, akan meminta untuk dikenali oleh nama panggilan tertentu dalam virtual room. Nama panggilan ini harus unik untuk room itu, dan akan diverifikasi berdasarkan nama panggilan yang sedang digunakan. Setelah nama panggilan diterima, user terdaftar dan nama panggilan itu dihubungkan dengan koneksi (session).

Jika kita menggunakan sessionless protocol, maka nama panggilan harus ditransmisikan dengan masing-masing pesan yang terkirim. Dalam kasus ini, tidak mungkin mencegah dua client dari penggunaan nama panggilan yang sama dalam virtual room yang sama pula. Ini akan membuat percakapan sangat kacau!

5.      Will the Protocol Use Plain Text or Binary?

Apakah protocol menggunakan teks atau binary?

(Tulisan pada kotak inbox atau attach file)

Kami akan membahas topik ini secara detil pada Bab 7. Masing-masing memiliki keunggulan dan kelemahannya. Contohnya, ketika teks dapat dibaca manusia, lebih mudah debug, teks biasanya menggunakan lebih besar bandwidth daripada format binari.

Untuk protokol kita, plain text akan menjadi pilihan terbaik. Kita tidak akan mengirim objek-objek atau file-file yang variatif—hanya pesan teks. Juga, ia akan membuat aplikasi lebih mudah debug, seperti akan anda lihat pada Bab 8. Karena kami telah memilih plain text, bagaimanapun, kami harus membuat keputusan berdasarkan layout yang sangat spesifik untuk tiap pesan teks sehingga ia dapat diuraikan dengan mudah.

6.      How Will Authentication Be Handled?

Bagaimana autentikasi ditangani?

(Pembuktian keaslian identitas user atau hanya nickname unik)

Keamanan telah menjadi isu yang semakin penting untuk aplikasi jaringan. Satu aspek dari keamanan adalah autentikasi (pembuktian keaslian) user. Ini mencakup tidak hanya verifikasi bahwa user itu berhak terkoneksi ke server, tapi juga menjamin  bahwa user yang login itu benar-benar user yang memiliki identitas sebenarnya. Kami akan membahas topik ini lebih detil pada Bagian Tiga buku ini.

Untuk tujuan kami, kami akan membolehkan siapapun untuk terkoneksi ke chat server selama orang itu memiliki panggilan nama unik. Jadi, autentikasi kita akan sangat sederhana dan terdiri dari client yang sedang submit agar login dengan nama panggilannya diterima.

7.      What About Privacy?

Bagaimana tentang privacy (jaminan kerahasiaan)?

(enkripsi dan dekrispi: Data dapat dilihat/disadap di jalur komunikasi sebelum sampai ke tujuan atau tidak)

Isu lain untuk address adalah privacy. Ketika client dan server sedang berkomunikasi, mudah bagi seseorang untuk menyadap percakapannya. Ketika mengimplementasikan protokol, anda harus memutuskan apakah enkripsi dapat diterapkan atau tidak. Kami akan membahas topik ini lebih detil pada Bagian Tiga buku ini.

Dalam contoh sederhana, kami tidak akan menyajikan jenis enkripsi apapun untuk komunikasi client-server. Semua command dan respon akan dikirim dalam plain text.

Sumber: Keir Davis, John W. Turner, and Nathan Yocom. The Definitive Guide to Linux Network Programming. USA: Apress. 2004. Hal. 138

Mohon penjelasan lebih lanjut dari sahabat-sahabat, terutama contoh-contoh implementasinya untuk tiap poin di atas! Terimakasih

Download

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s