sender → receiver

( - ) send pkt0 ➡️ rcv pkt0 && send ack 0

rcv ack 0 && send pkt 1 ➡️ rcv pkt 1 && send ack 1

rcv ack 1 && send pkt 0 ➡️ rcv pkt 0 && send ack 0

( … 반복)

발생 가능한 재전송 경우의 수

  1. 센더의 패킷이 유실된 경우

    1. 리시버는 암것도 모르고 기다림
    2. 센더는 ack 응답을 기다리는 타이머가 expired되고 재전송

  2. 리시버의 ack가 유실된 경우

    1. 리시버는 이미 보냈음
    2. 센더는 ack 응답을 기다리는 타이머가 expired되고 재전송

  3. 리시버가 응답을 늦게 보낸 경우

    1. 리시버가 보낸것이 도달하기 전에 응답이 또 와버림
    2. 센더는 ack 응답을 기다리는 타이머가 expired되고 재전송

스크린샷 2024-11-24 오후 5.22.39.png

타이머 매커니즘을 통해서 in order를 구현했음. 새로운 패킷을 보냈어. 실젤는 그렇게 동작 안할것 이렇게 하면 너무나 비효율적이어버려. 피드백을 받고 나서야 보내면 나머지 시간동안 링크 쓰지않고 내비두고 있죠. 낭비가 엄청난거라고 효율성이 떨어지죠. 효율성을 갖추려면 ack받지 않고 패킷 한꺼번에 쏟아부어. 꽉채우면 채울수록 좋잖아. tcp 같은 경우에는 아까처럼 동작하지 않고, 파이프라인이라고해서 한꺼번에 붇고 피드백도 한꺼번에 받음. 이렇게 동작해야 시간축이 꽉 채워지면서 효율적으로 동작할거라고. 타이머 다 있지만 파이프라인 방식으로 동작하기 때문에 약간ㄷ ㅓ 복잡하기는 해요. 기본적인 원리는 위의 이야기에 베이스를 두고 있어요.

파이프라인

go back N 이랑 selective repeat 이라는 프로토콜이 교육 목적으로 파이프라인 프로토콜이 두가지 generic form이 존재해요. 이것을 수업시간에 다루지 않는 이유는 이 두 프로토콜 자체가 이해하고 나면 별거 아닌데 이해하기까지 시간이 좀 걸리거든요. 학기 끝나고 나면 저 두 프로토콜만 기억하는 사람이 많아서.

Overview