[Network] 3.4 신뢰적 data 전송의 원리 2

*rdt 2.1 : receiver

# 시퀀스넘버는 중복됬는지 확인해야하므로 0과 1 밖에 없다.

*rdt 2.1

Sender

• pkt에 seq #를 추가한다.
• 두개의 seq #만으로 충분하다. (이전 송신된 pkt와의 중복만을 검사함으로..)
• ACK/NAK의 손상을 검사한다.
• 상태가 rdt 2.0보다 두배 많다.
• 현재 전송 pkt의 seq #가 0인지 1인지 기억하고 있어야 한다.

receiver

• 수신된 pkt의 중복여부를 검사해야한다.
• pkt의 seq #가 0/1인지 검사한다.
• receiver는 sender가 ACK/NAK를 정상적으로 수신했는지 알 수 없다.

*rdt 2.2 : NAK가 없는 rdt

rdt 2.1과의 차이는 ACKs만을 사용하는 것이다.

receiver는 NAK 대신 최근에 정확히 수신된 pkt에 대한 ACK를 전달한다.

Sender는 중복된 ACK를 통해서 중복된 ACK pkt이후에 전송한 pkt이 정상적으로 수신되지 못했음을 안다.

ACK의 누적

누적된 ACK를 사용하는 경우 sender는 마지막 수신한 ACK의 seq # 이전의 pkt는 모두 정상 잔달 되었음을 확인 할 수 있다.

# ack 번호를 집어넣어서 보낸다.

ack 0 : 0번까지 잘 받았다는 뜻이다. - 0번을 잘받았다 그러면 안된다.

누적이기때문이다. 0-5 를 보내는 중 ack3이 온다면 0~3까지 잘받았다는것

# 1번이 왔는데 깨지면 ACK 0 을 보내 1번을 다시 받는다.

NAK를 없애는 계기가 됨.

# NAK는 네거티브 아크널러지먼트라고 불러야한다. - 표준어 나크라 부르면 안됨

*rdt 2.2 : NAK가 없는 rdt

sender

상태) wait for call 0 from above

• 0번을 패킷을 보내기위해 기다리고 있는 상태

이벤트) rdt_send(data)

• TCP는 데이터를 APP에게 받았다.

액션) sndpkt = make_pkt(0, data, checksum)

• TCP는 0번시퀀스와 데이터, 체크섬을 포함한 패킷을 만든다.

액션) udt_send(sndpkt)

• TCP는 세그먼트를 IP에게 보낸다.

상태) wait for ack 0

• TCP는 0번 ACK가 오기를 기다리는 상태로 변경한다.

이벤트) rdt_rvc(rcvpkt) && (corrupt(rcvpkt) || isACK(rcvpkt, 1)) udt_send(sndpkt)

• IP로부터 TCP는 1번 ACK를 받는다.

액션) udt_send(sndpkt)

• 패킷이 깨져서 버리고 0번 패킷을 다시 패킷을 보낸다.

이벤트) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)

• TCP는 IP에게 0번 ACK를 보내 0번 패킷을 받는다.

receiver

# 패킷이 아예 안갈수도 있는데 이것 고려하지않음.

타이머라는 것을 사용해서 이것을 해결한다.

타이머의 모든 프로세스 cpu의 쿨럭발생기를 사용한다.

• cpu의 성능을 깍아먹으므로 되도록 적게 띄우고 싶어한다.

*rdt 3.0 : 채널에 error나 loss가 가능

새로운 가정

하위 채널에 packet loss가 일어 날 수 있는 경우 (data & ACKs)

• checksum, seq #, ACKs만으로는 충분하지 않다.

새로운 접근 방식

sender는 합리적인 시간 만큼 ack를 기다린다.

• 합리적인 시간만큼 기다려도 ACK가 없으면 재전송한다.
• 만일 ACK가 지연된 것이라면
• 중복을 유발하는 재전송이 일어난다. – 이미 중복 처리에 대한 준비가 되어있다.
• receiver는 중복된 pkt에 대한 ACK를 재전송한다.
• 이러한 작업은 실제로 문제를 일으키지는 않는다.
• 위의 구현을 위해 countdown timer를 필요로 한다.

// timer는 CPU에 부담이 매우 크다. sender 만 타이머가 있다.

*rdt 3.0 : sender

// sender 0번 데이터를 보내기 위해 데이타를 기다리고 있다.

// RTT보다 길어야한다. 하지만 RTT는 굉장히 변동적이다.

*rdt 3.0 in action - 시나리오

*rdt 3.0 in action

# 가다가 깨진경우 오다가 없어진경우

*rdt 3.0 의 성능

*rdt 3.0 : stop – and - wait

*Pipelined protocol

Pipelining : sender에게 ACK를 기다리지 않고 여러 개의 pkt를 전송하도록 하용하는것

• seq #의 범위는 증가되어야 한다.
• sender와 receiver는 하나이상의 pkt를 buffering해야 한다.

piplining protocol : go-Back-N, selective repeat