Thursday, May 10, 2012

Flow Control pada TCP

Sebagian besar diskusi tentang Sliding Window pada TCP sama dengan yang dibahas pada sliding window, perbedaan utamanya hanya pada bagian ini kita mempertimbangkan fakta bahwa proses pada aplikasi pengirim adalah memenuhi buffer dan penerima adalah mengosongkan buffer mereka masing-masing. Pembahasan mencakup fakta bahwa data yang tiba dari sebuah node upstream adalah memenuhi buffer pengirim dan data yang sedang dikirim pada node downstream adalah mengosongkan buffer penerima.
Yang harus anda pastikan untuk mengerti hal tersebut sebelum melanjutkan karena sekarang ketika masuk pada bagian dimana dua algoritma berbeda secara lebih signifikan. Pada bab berikutnya, kita memperkenalkan kembali fakta bahwa kedua buffer mempunyai ukuran yang terbatas, dengan notasi MaxSendBuffer dan MaxRcvBuffer, walaupun kita tidak terlalu memperhatikan detail bagaimana keduanya diimplementasikan. Dengan kata lain, kita hanya tertarik pada jumlah byte yang sedang dibuffer, bukan dimana sebenarnya kedua byte tersebut disimpan.
Perlu diingat bahwa pada protocol sliding window,  ukuran window disesuaikan dengan jumlah data yang bisa dikirim tanpa harus menunggu ACK dari receiver. Oleh karena itu, receiver/penerima menekan pengirim dengan menawarkan sebuah window yang tidak lebih besar dari jumlah data yang bisa disimpan. Amati bahwa TCP pada sisi penerima harus menjaga kondisi bahwa
LastByteRcvd−LastByteRead ≤ MaxRcvBuffer
untuk menghindari terlalu membanjiri buffer penerima. Oleh karena itu, penerima menawarkan sebuah ukuran window
AdvertisedWindow = MaxRcvBuffer−((NextByteExpected−1)−LastByteRead)
yang mana mewakili jumlah ruang kosong yang tersisa dalam buffernya. Ketika data tiba, penerima meng-ACK selama semua byte yang mendahului sudah juga sudah tiba. Sebagai tambahan, LastByteRcvd bergerak ke kana (nilainya naik), yang berarti bahwa window yang ditawarkan(Advertised Window) berpotensi untuk berkurang. Apakah ukuran window jadi berkurang atau tidak tergantung seberapa cepat proses aplikasi local mengkonsumsi data. Jika proses loka sedang membaca data seketika setelah datang yang menyebabkan LastByteRead selalu naik bersamaan dengan laju LastByteRcvd, maka ukuran window yang ditawarkan akan selalu terbuka(open, AdvertisedWindow = MaxRcvBuffer). Namun, jika proses yang menerima tertinggal dibelakang, mungkin karena sedang melakukan operasi yang berat pada setiap byte data yang dibaca, maka ukuran window yang ditawarkan menjadi lebih kecil setiak kali segmen tiba, sampai pada akhirnya ukurannya menjadi 0.

TCP pada sisi pengirim harus menyesuaikan ukuran window yang ditawarkan, yang didapat dari penerima. Hal ini berarti bahwa pada suatu waktu tertentu, pengirim harus menjamin bahwa

LastByteSent−LastByteAcked ≤ AdvertisedWindow
menurut sisi yang lain, pengirim menghitung sebuah ukuran window yang membatasi seberapa banyak data yang bisa dikirim:
EffectiveWindow = AdvertisedWindow−(LastByteSent−LastByteAcked)
Secara jelas, EffectiveWindow harus lebih besar dari pada 0 sebelum sumber bisa mengirim lebih banyak data. Sehingga dimungkinkan, oleh karena itu, sebuah segmen tiba yang meng-ACK x buah byte, yang nantinya memungkinkan sender untuk meningkatkan LastByteAcked sebanyak x, namun karena proses penerima tidak membaca data apapun, ukuran window yang ditawarkan sekarang x byte lebih kecil dari sebelumnya. Pada situasi ini, pengirim akan bisa mengosongkan ruang buffer, namun bukan untuk mengirim data lagi.
Ketika semua hal ini terjadi, pada sisi penerima harus menjamin bahwa proses aplikasi local tidak membanjiri buffer pengirim, sehingga
LastByteWritten−LastByteAcked ≤ MaxSendBuffer
Jika proses pengirim mencoba menulis y byte pada TCP, namun
(LastByteWritten−LastByteAcked)+y > MaxSendBuffer
Maka TCP mem-blok proses pengirim dan tidak membiarkan proses pengirim untuk meng-hasilkan lebih banyak data.
Sekarang dimungkinkan untuk mengerti bagaimana sebuah proses yang lambat dalam menerima pada akhirnya menghentikan proses pengiriman yang cepat. Pertama, buffer penerima menjadi penuh, yang mana window yang ditawarkan menjadi 0. Kondisi ukuran window yang ditawarkan 0 berarti pada sisi pengirim tidak bisa mengirimkan data, walaupun data yang sebelumnya berhasil terkirim telah sukses di-ACK. Terakhir, tidak berhasil mengirim data apapun berarti buffer pengirim juga penuh, yang mana membuat TCP menghentikan proses pengiriman. Sesegera setelah proses pengiriman mulai melakukan pembacaan data lagi, sisi pengirim pada TCP bisa window kembali, yang mana memungkinkan TCP pada sisi pengirim mengirimkan data keluar dari buffernya. Ketika data ini pada akhirnya di-ACK, LastByteAcked dinaikkan nilainya, ruang buffer yang menjaga data yang diACK ini menjadi bebas, dan proses aplikasi pengiriman menjadi tidak diblok dan memperbolehkan untuk melanjutkan pengiriman.
Terdapat satu detail tersisa yang harus dipecahkan, bagaimana sisi pengirim tahu bahwa ukuran window yang ditawarkan tidak lagi 0? Seperti yang disebutkan di atas, TCP selalu mengirim sebuah segmen sebagai jawaban dari sebuah segmen data yang diterima, dan jawaban(response) ini berisi nilai terbaru dari AdvertisedWindow field untuk ACK, bahkan jika nilai ini tidak berubah sejak terakhir kali data terkirim. Permasalahannya adalah, ketika sisi penerima mempunyai ukuran window yang ditawarkan bernilai 0, dan pengirim tidak diizinkan untuk mengirim data lagi, yang mana berarti tidak ada cara  untuk mengetahui bahwa ukuran window yang ditawarkan tidak lagi 0 pada beberapa waktu kedepan. TCP pada sisi penerima tidak secara tiba-tiba mengirim segmen nondata; penerima hanya mengirimkan segmen nondata(ACK) sebagai jawaban pada sebuah segmen data yang tiba.
TCP menghadapi permasalahan tersebut sebagai berikut. Setiap kali sisi lain menawarkan sebuah ukuran window 0, sisi pengirim terus menerus mengirimkan sebuah segmen dengan ukuran 1 byte secara sering dan terus menerus. Pengirim tahu bahwa data ini mungkin tidak akan diterima, namun pengirim tetap mencoba, karena setiap satu byte segmen memacu sebuah respons yang berisi ukuran window yang ditawarkan saat ini. Pada akhirnya, satu dari 1-byte pengurkur ini memacu respons yang melaporkan sebuah ukuran window yang ditawarkan berukuran tidak 0.

1 comment:

Labels

AdMob Adobe Adsense Aero Buster Air Buster Airpush Al-Ghozali Amazon Appstore Amerika Android Android App Animasi apa itu App Application Arsitektur Asimetris asus AutoArtikel Bahasa Indonesia Bahasa Inggris Blogger Blogspot Browser Bus Cara akses Cara kerja cat CERN Chiper Chrome command Contoh CORBA cPanel CS3 diff Diffie-Hellman Distance Vector domain download e-book e-book Jaringan Komputer e-book Ketidaklogisan para Filsuf e-book Sistem Operasi ebook Einstein Engineering Design Process Enkripsi file Filosofi Firefox fisika Flow Control frame Game genap 2011-2012 Gerbang Quantum getaran gif Google google nexus 7 Google Play Gratis GRE grep GSM Handoff Handover head Hosting HTML5 Hypnolearning IDL IM3 IMS Interface Definition Language Internet internet dan bisnis telekomunikasi Internet Explorer iPad 3 jadwal Jaringan Jaringan Komputer Java JDBC JSP Judul Justin Bieber Kamera Kapsel Kecepatan Cahaya Ketidaklogisan Para Filsuf kisi-kisi Komputer Kriptografi LAN Linux Manajemen Manajemen Memori mediafire Memori Mesh Model View Controller MoonViewer Motivation Multicast Routing MVC MySql Near Field Communication Network Programming Neutrino New Technology File System Nilai NTFS OPERA Organisasi dan arsitektur komputer osilasi page Partai Peduli Rakyat PC pegas Pemasaran pembuat artikel Pemrograman Bahasa Tingkat Rendah Pemrograman Jaringan Pemrograman Web Penjadwalan Penyandian Perang Sipil perintah Pertukaran Kunci Photoshop PHP Physics PKS Power Point Process Producer Consumer Programming Protokol Proyek Akhir PSTN Quantum Information Quiz Quotes RAM review Ring RMI Safari Scheduling Security Sega Genesis Sejarah Servlet Shooter Simetris Singkronisasi Sistem File Sistem Koordinat Sistem Operasi slide SlideMe Socket Solaris sort source code SPIN spinner Star Studium Generale Superkonduktor Switch tablet Tahafut Al-Falasif tail TCP Terjemah test GRE Tolak Kenaikan Harga BBM Topologi Tugas Akhir tween Twitter UAS Ubuntu Ulasan Ulasan Nokia 808 PureView UNIBBA uniq UNIX UNIX SVR4 UTS Verbal Virtual Router Redundancy Protocol Vocab Vocabulary VRRP Web Services WiMAX Windows wired.com Wireless Sensor Network Words WSN