Reliable Data Transfer(RDT)

실사용되는 것은 아니지만 TCP와 유사한 가상의 프로토콜 RDT를 알아보자.

 

TCP가 채널을 reliable하게 유지시켜주기 때문에 어플리케이션 레이어는 데이터전송시 신뢰성 있다고만 생각한다.

 

reliable하기 위해서는 아래 두 가지를 해결해야한다.

-메시지(패킷) 에러: 비트에러 발생

-메시지(패킷) 로스

 

(우리는 rdt에서 단방향 통신이라 가정하자)

 

rdt1.0

bit error가 발생하지 않고, 패킷 loss가 발생하지 않는 환경이라고 가정.

환경자체가 reliable하기 기능 없어도 reliable함

 

rdt2.0

bit error가 발생하는 환경(패킷로스는 일어나지않음)

Error detection이 필요함.

 

checksum 필드를 통해서 비트에러가 있는지 판단할 수 있다.

receiver는 비트에러 없이 잘 받은 경우 ACK을, 비트에러가 발생한 경우 NAK을 전달한다.

 

이러한 방식을 Stop and wait 프로토콜이라고 한다.

이 방식은 속도가 느릴 수 있다.

 

또한, Ack 또는 Nak에서 비트에러가 발생한 경우 sender는 데이터를 재전송한다.

그런데, receiver 입장에서는 같은 데이터를 두번 받은 경우, 똑같은 데이터를 두 번 보낸건지, Ack에서 비트에러가 발생해서 재전송한건지 알 수가 없다. receiver는 중복된 패킷을 알 수 있어야 한다.

 

rdt2.1

위 문제를 해결하기 위해 패킷에 시퀀스넘버를 추가한다.

같은 데이터를 두 번 받았을 때, 시퀀스넘버를 확인하여 두 패킷의 시퀀스넘버가 같으면 중복된 패킷(즉, ack이 비트에러가 나서 sender가 다시 보낸 경우), 시퀀스넘버가 다른경우는 정상적으로 데이터를 두 번 보낸 경우로 판단한다.

 

이 때 시퀀스넘버는 1개의 비트로 0,1만 표현할 수 있으면 된다.

 

rdt2.2

프로토콜 관점에서 효율성을 위해 NAK을 사용하지 않는 방식이다.

(프로토콜이 간단할수록 좋음)

NAK대신, 마지막으로 성공적으로 수신한 시퀀스 넘버를 ACK과 함께 전송한다.

그럼, 비트에러가 발생한 경우 ACK 세그먼트에 중복된 시퀀스넘버를 보내게 되니, sender는 이를 NAK으로 해석할 수 있다.

 

rdt3.0

패킷로스가 발생할 수 있는 환경.

timer의 time-out이 발생하면 패킷을 재전송한다.

Sender가 bit error가 발생한 ACK을 수신할 경우, 이를 무시하고 timer가 expire되면 재전송한다.

또한, Sender입장에서 Pkt0을 보냈는데 ACK1이 수신될 경우 역시 이를 무시하고 timer가 expire되면 Pkt0을 재전송한다.

 

timer가 너무 짧으면 불필요한 재전송이 많아질 수 있고, 타이머가 너무 길면 딜레이가 오래걸릴 수 있다.