RELIABLE DATA TRANSFER (RDT)

Reliable Data Transfer (RDT) adalah suatu mekanisme TCP yang menyediakan
komunikasi logis antara proses aplikasi yang berjalan pada host yang berbeda.
Dinamakan reliable karena TCP menjamin bahwa data tersebut pasti diterima sesuai
dengan yang dikirimkan. Secara dasar, RDT menggunakan protokol Stop-and Wait.
Namun, karena alasan jarak yang jauh, muncul berbagai versi update yang ada di RDT
yaitu rdt 1.0, rdt 2.1, rdt 2.2, rdt 3.0, dan lain-lain.

RDT 1.0 : RELIABLE TRANSFER MELALUI RELIABLE CHANNEL

RDT 1.0 dalam melakukan transfer data menggunakan atau melewati channel.
Channel yang mendasari tersebut diasumsikan merupakan reliable secara sempurna, yang
mana tidak akan terjadi bit error dan packet loss. RDT 1.0 juga menggunakan FSM (Finite
State Machines) yang terpisah untuk masing-masing pengirim (sender) maupun penerima
(receiver).

Dari gambar diatas menunjukan bagaimana di sisi pengirim mengirimkan data ke

channel yang mendasarinya dengan detailnya pada sisi sender (rdt_send) menunggu
panggilan dari atas (layer aplikasi), ketika ada perintah maka jalankan fungsi packet =
make_pkt yaitu membuat paket yang akan dikirimkan melalui udt_send.
Lalu di sisi penerima membaca data dari channel yang mendasarinya dengan
detailnya pada sisi reveiver (rdt_rcv) menunggu panggilan dari bawah(layer data link),
ketika ada sinyal maka dia menerima paket yang selanjutnya akan dijalankan fungsi
extract yaitu mengekstrak paket data untuk selanjutnya dikirim ke layer aplikasi.
Kelemahan RDT 1.0 : Tidak terdapat pengecekan bit eror pada setiap paket.

RDT 2.0 : CHANNEL DENGAN BIT ERROR

Tidak jauh berbeda dengan RDT 1.0, RDT 2.0 juga dalam melakukan transfer
data menggunakan atau melewati channel. Channel yang mendasari tersebut dalam versi
ini bisa menyebabkan flipped bits pada packets. Memperbaiki kelembahan RDT 1.0, RDT
2.0 dapat mendeteksi bit error dengan menggunakan checksum.
RDT 2.0 diasumsikan mencoba meniru bagaimana cara manusia berdialog, yaitu
ketika 2 orang sedang berbicara jika salah satunya kurang mengerti maka orang tersebut
akan bertanya ‘maaf bisa kamu ulangi perkataanmu? ‘ hal tersebut menandakan bahwa
orang tersebut sebelumnya tidak menangkap pembicaraan.
Mengatasi adanya error tersebut bisa dengan recover data yang hilang yaitu
dengan adanya pemberitahuan, yaitu :
- Acknowledgements (ACKs): Penerima secara eksplisit memberi tahu pengirim bahwa
data atau packet diterima dengan baik.

1
- Negative Acknowledgements (NAKs): Penerima secara eksplisit memberiitahu pengirim
kalau paketnya terdapat bit-bit yang eror atau hilang.
- Dengan begitu, pengirim mengirimkan ulang packet setelah menerima NAK.
Terdapat mekanisme baru pada RDT 2.0 :
RDT2.0 : Spesifikasi FSM

Memiliki mekanisme yang sama dengan RDT 1.0 hanya saja terdapat tambahan
ACK dan NAK pada sisi pengirim.
RDT 2.0 : Scenario Tanpa Error

Dari gambar di atas, pada sisi sender/pengirim menunggu panggilan dari atas
(layer aplikasi), ketika ada perintah maka jalankan fungsi
packet=make_pkt(data,checksum) yaitu membuat paket dan menyertakan checksum
yang akan dikirimkan lewat udt_send.
Lalu paada sisi reveiver rdt_rcv menunggu panggilan dari bawah(layer data link),
ketika ada sinyal maka dia menerima paket dan mengeceknya rusak atau tidak, jika tidak
maka selanjutnya akan dijalankan fungsi extract yaitu mengekstrak paket data untuk
selanjutnya dikirim ke layer aplikasi(di sisi penerima) dan juga mengirim ACK melalui
udt_send, jadi di sisi sender menerima pemberitahuan paket sampai dan tidak rusak.

2
RDT 2.0 : Scenario Dengan Error

Jadi pada sisi sender/pengirim menunggu panggilan dari atas (layer aplikasi),
ketika ada perintah maka jalankan fungsi packet=make_pkt(data,checksum) yaitu
membuat paket dan menyertakan checksum yang akan dikirimkan lewat udt_send.
Lalu di sisi reveiver atau peneriman rdt_rcv menunggu panggilan dari
bawah(layer data link), ketika ada sinyal maka dia menerima paket dan mengeceknya
rusak atau tidak,karena rusak maka selanjutnya akan dijalankan
fungsi rdt_rcv(rcv_pkt)&&corrupt(rcv_pkt) maka udt_send mengirim NAK.
Selanjutnya pada sisi sender berada di state Menunggu ACD/NAK, karena
menerima NAK maka udt_send mentransmisikan ulang yaitu pada fungsi
rdt_rcv(rcvpkt)&&is NAK(rcv_pkt) dan udt_send yang mengirimkan file itu lagi.
Kemudian di sisi reveiver rdt_rcv menunggu panggilan dari bawah(layer data
link), ketika ada sinyal maka dia menerima paket dan mengeceknya rusak atau tidak, jika
tidak maka selanjutnya akan dijalankan fungsi extract yaitu mengekstrak paket data
untuk selanjutnya dikirim ke layer aplikasi(di sisi penerima) dan ia juga mengirim ACK
melalui udt_send, jadi disisi sender menerima pemberitahuan paket sampai dan tidak
rusak.
Kelemahan RDT 2.0 : Fatal yaitu jika ACK/NAK rusak, maka sender/pengirim
tidak tahu apa yang terjadi di sisi receiver/penerima. Solusinya adalah diberi waktu
(misalnya jika setelah 3 sekon tidak menerima file ACK/NAK) maka file akan
ditransmisikan ulang. Namun hal ini menyebabkan duplikasi data.
RDT 2.1 : Pengirim, Menangani ACK/NAK Yang Rusak
Memperbaiki kelemahan rdt 2.0 yaitu dengan menambahkan sequence number
pada setiap paket. Cara kerjanya samadengan 2.0 hanya saja ada 2 paket dan diberikan
sequence number yaitu ‘0’ dan ‘1’.
Pada sisi pengirim :

3
 Pada state 1 disisi sender menunggu panggilan dari atas (layer aplikasi), ketika
ada perintah maka jalankan fungsi packet=make_pkt(0,data,checksum) yaitu membuat
paket dan memberi sequence number 0 dan menyertakan checksum yang akan
dikirimkan lewat udt_send.
Lalu berada pada state ke 2 yaitu menunggu untuk ACK atau NAK dimana ada 2
kemungkinan yaitu jika NAK maka data rusak dan segera kembali mentransmisikan paket
0 melalui udt_send lagi. Jika ACK maka paket 0 telah selesai.
Lalu berada pada state ke 3 yaitu menunggu panggilan dari atas (layer aplikasi)
lagi, ketika ada perintah maka jalankan fungsi packet=make_pkt(1,data,checksum) yaitu
membuat paket dan memberi sequence number 1 dan menyertakan checksum yang akan
dikirimkan lewat udt_send.
Lalu berada pada state ke 4 yaitu menunggu untuk ACK atau NAK dimana ada 2
kemungkinan yaitu jika NAK maka data rusak dan segera kembali mentransmisikan paket
1 melalui udt_send lagi. Jika ACK maka paket 1 telah selesai.
Pada sisi penerima :

Pada state 1 disisi reveiver rdt_rcv menunggu panggilan 0 dari bawah(layer data
link), ketika ada sinyal maka dia menerima paket dan mengeceknya rusak atau tidak, ada
2 kemungkinan yaitu jika NAK maka data rusak dan menjalankan fungsi
rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)) dan mengirimkan paket NAK dengan checksum

4
melalui udt_send agar disisi sender menerima pemberitahuan paket rusak. Jika ACK
maka data utuh dan menjalankan fungsi rdt_rcv(rcvpkt)&&(not corrupt(rcvpkt)) ||
has_seq0 dan mengirimkan paket ACK dengan checksum melalui udt_send agar disisi
sender menerima pemberitahuan paket sampai dan tidak rusak.
Jika paket utuh dan tidak eror maka selanjutnya akan dijalankan fungsi extract
yaitu mengekstrak paket data dengan seq 0 untuk selanjutnya dikirim ke layer aplikasi(di
sisi penerima).
Setelah itu masuk pada state ke2 yaitu menunggu panggilan 1 dari bawah(layer
data link), ketika ada sinyal maka dia menerima paket dan mengeceknya rusak atau tidak,
ada 2 kemungkinan yaitu jika NAK maka data rusak dan menjalankan fungsi
rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)) dan mengirimkan paket NAK dengan checksum
melalui udt_send agar disisi sender menerima pemberitahuan paket rusak. Jika ACK
maka data utuh dan menjalankan fungsi rdt_rcv(rcvpkt)&&(not corrupt(rcvpkt)) ||
has_seq1 dan mengirimkan paket ACK dengan checksum melalui udt_send agar disisi
sender menerima pemberitahuan paket sampai dan tidak rusak.
Jika paket utuh dan tidak eror maka selanjutnya akan dijalankan fungsi extract
yaitu mengekstrak paket data dengan seq 1 untuk selanjutnya dikirim ke layer aplikasi(di
sisi penerima).
Kelemahan RDT 2.1 : Sama dengan 2.0 yaitu sisi sender tidak tau apa yang terjadi
di receiver jika NAK/ACK tidak sampai dan sisi receiver juga tidak tau apakah
NAK/ACK sampai dengan baik disisi sender.
RDT 2.2: Protokol Tanpa NAK

Pada sisi pengirim :

Pada state 1 disisi sender menunggu panggilan dari atas (layer aplikasi), ketika
ada perintah maka jalankan fungsi packet=make_pkt(0,data,checksum) yaitu membuat
paket dan memberi sequence number 0 dan menyertakan checksum yang akan
dikirimkan lewat udt_send.
Lalu berada pada state ke 2 yaitu menunggu untuk ACK 0 dimana ada 2
kemungkinan yaitu jika menerima paket 1 maka data rusak dan segera kembali
mentransmisikan paket 0 melalui udt_send lagi. Jika menerima paket 0 maka sudah benar
dan telah selesai.

5
 Pada sisi penerima:
Pada state 1 disisi reveiver rdt_rcv menunggu panggilan 0 dari bawah(layer data
link), ketika ada sinyal maka dia menerima paket dan mengeceknya rusak atau tidak, ada
2 kemungkinan yaitu jika data rusak maka menjalankan fungsi
rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||has_seq1(rcvpkt)).
Jika data utuh maka menjalankan fungsi rdt_rcv(rcvpkt)&&(not corrupt(rcvpkt))
|| has_seq1(rcvpkt) lalu menjalankan fungsi extract yaitu mengekstrak paket data untuk
selanjutnya dikirim ke layer aplikasi(di sisi penerima). Receiver juga mengirimkan paket
ACK1 dengan checksum melalui udt_send agar disisi sender menerima pemberitahuan
paket sampai dan tidak rusak.
Kelemahan rdt 2.2 :Ketika pengiriman paket ack ternyata proses itu butuh
waktu(delay) lagi.

RDT 3.0: Channels Dengan Errors Dan Loss

RDT 3.O ini dilengkapi dengan errors dan loss. Sehingga sender memberikan
waktu(timer) bagi ACK. Hal yang akan dilakukan adalah :
a. Jika tidak ada ACK yang tiba akan retransmit paket tersebut
b. Jika seandainya ACKnya tidak hilang tapi hanya macet(delay) akan menyebabkan paket
terduplikasi, namun ada sequence number jadi paket ke 2 yang dating dapat dikenali
identik dengan yang pertama sehingga tidak perlu menjalankan fungsi ekstrak apalagi
sampai mengirimkannya ke layer aplikasi.

Terdapat 4 kondisi yaitu :

a. No Loss
1. Sender mengirim paket 0
2. Receiver menerima paket 0 dan mengirim ack 0
3. Sender menerima ack 0 dan mengirim paket 1
4. Receiver menerima paket 1 dan mengirim ack 1
5. Sender menerima ack 1 dan mengirim paket 0
6. Receiver menerima paket 0 dan mengirim ack 0 dst

6
 b. Packet Loss
1. Sender mengirim paket 0
2. Receiver menerima paket 0 dan mengirim ack 0
3. Sender menerima ack 0 dan mengirim paket 1
(paket 1 hilang)
4. Karena receiver tidak menerima paket maka tidak
mengirim ack 1 setelah sekian waktu sehingga
sender mengirim ulang paket 1
5. Receiver menerima paket 1 dan mengirim ack 1
6. Sender menerima ack 1 dan mengirim paket 0
7. Receiver menerima paket 0 dan mengirim ack 0 dst
c. ACK Loss
1. Sender mengirim paket 0
2. Receiver menerima paket 0 dan mengirim ack 0
3. Sender menerima ack 0 dan mengirim paket 1
4. Receiver menerima paket 1 dan mengirim ack 1
(ack hilang di perjalanan)
5. Karena tidak segera menerima ack 1 setelah sekian
waktu maka sender mengirim ulang paket 1
6. Sender menerima ack 1 dan mengirim paket 0
7. Receiver menerima paket 0 dan mengirim ack 0 dst
d. Premature Timeout / Delay ACK
1. Sender mengirim paket 0
2. Receiver menerima paket 0 dan mengirim ack 0
3. Sender menerima ack 0 dan mengirim paket 1
4. Receiver menerima paket 1 dan mengirim ack 1
5. ACK terlambat sehingga sender mengira data tidak
sampai dan mentransmisikan ulang paket 1
6. Receiver menerima paket 1(terjadi duplikasi data
namun terdeteksi) dan receiver mengirim ack1
sementara si sisi sender menerima ack1 lalu mengirim
paket 0
7. Receiver menerima paket 0 dan mengirimkan ack 0
8. Sender menerima ack 1 dan mengirimkan paket 0
9. Receiver menerima paket 0(terjadi duplikasi data namun
terdeteksi) dan mengirimkan ack0
RDT 3.0 : Operasi Stop and Wait

7
 PIPELINE
Protokol pipeline sendiri adalah sebuah protocol yang memungkinkan klien untuk
membuat beberapa permintaan tanpa menunggu setiap respon, sehingga instruksi lebih
efisien. Pipeline sendiri merupakan suatu cara yang digunakan untuk melakukan sejumlah
kerja secara bersaman tetapi dalam tahap yang berbeda yang dialirkan secara kontinu
pada unit pemrosesan. Dengan cara ini, maka unit pemprosesan selalu bekerja.
Karena performansi rdt 3.0 sangat buruk, yaitu membuang banyak Gigalink dan
hanya mendapatkan beberapa kB maka diperbaiki dengan adanya pipelining, yaitu :
dalam 1 penerbangan langsung mengirim banyak paket, agar mengurangi waktu yang
dibutuhkan untuk mengirimkan data. Namun seq no harus ditingkatkan agar tetap urut
per size window.
Misalnya : dalam 1 penerbangan terdapat 3 size window maka
Usender=[(3L/R)/(RTT+(L/R))]
Ada 2 algoritma yaitu :
- Go Back N
Konsep kerja dari Go Back N Protocol hampir sama dengan Stop and Wait
Protocol. Perbedaannya, Go Back N mengirimkan lebih dari satu paket dalam satu
waktu ke komputer tujuan (N buah paket data dlama satu kurun waktu tertentu),
namun komputer tujuan hanya melakukan buffer (menerima) satu paket saja untuk
setiap waktu (satu per satu), untuk kemudian dikirimkan Acknowledgement (ACK)
dari setiap paket tersebut secara satu per satu.
Go Back N : Sender

Go Back N : Sender Extended FSM

8
Go Back N : Receiver Extended FSM

Go Back N : in action

Kelemahan : Lama nunggunya sampai semua dating(terjadi delay lagi).

- Selective
Selective Repeat (SR) Protocol merupakan protokol perbaikan kinerja dari Go
Back N (GBN) protokol yang diciptakan dalam Transport Layer. Sebagaimana
namanya, Selective Repeat (SR) Protocol memiliki kemampuan untuk memilah
secara selektif semua paket yang akan ditransfer di dalam jaringan secara berulang-
ulang. Apabila ada paket yang rusak atau hilang selama proses transfer, maka paket
tersebut akan dikirim ulang. Itu sebabnya, pada Selective Repeat (SR) Protocol
terdapat 2 buah windows.. Kedua windows tersebut terdiri atas Send Windows dan
Receive Windows

9
Selective Repeat : in action

-Kelebihan: Selective Repeat ARQ memperbaiki Go-Back-N ARQ pada jaringan

kongesti dengan mengurangi retransmisi.
-Kelemahan: Receiver tidak dapat melihat perbedaan antara 2 skenario yaitu paket
yang duplikat atau paket yang baru.

10
 DAFTAR PUSTAKA

Kurose, James F. dan Keith W. Ross. 2013. Computer Networking : A Top-Down

Approach. United States of America: Pearson Education.

RDT http://www2.ic.uff.br/~michael/kr1999/3-transport/3_040-principles_rdt.htm di
akses pada tanggal 7 Oktober 2019

RDT https://you.stonybrook.edu/ylatif/2016/04/04/reliable-data-transfer-rdt/ di akses

pada tanggal 7 Oktober 2019

Pipeline https://www.d.umn.edu/~gshute/net/reliable-data-transfer.xhtml di akses pada

tanggal 8 Oktober 2019

11