RFC 1235: 한 번의 방송과 수신기별 누락 블록

요약

RFC 1235은 실험용 패킷 무선망에서 디스크 없는 컴퓨터 여러 대를 동시에 부팅하는 문제를 바탕으로, 파일 하나를 여러 수신자에게 방송하는 CFDP를 제안했다.
클라이언트는 이미 진행 중인 전송을 먼저 듣고, 없으면 전체 파일을 요청했다. 이후 빠진 블록이 있으면 자기에게 없는 번호만 따로 요구했다.

세 컴퓨터가 같은 시작 파일을 원해도, 방송 한 번이 끝난 뒤에는 서로 다른 누락표 세 장이 남을 수 있다. John Ioannidis와 Gerald Maguire Jr.는 1991년 6월 RFC 1235에서 바로 그 수신 차이를 설계 문제로 다뤘다. 디스크 없는 워크스테이션들이 동일한 시작 파일을 원한다. 서버가 각각에 개인 전송을 열면 같은 바이트를 기계 수만큼 되풀이한다. 방송이 가능한 매체라면 큰 파일을 한 흐름으로 내보낼 수 있다.

출발점은 실험용 패킷 무선망의 동시 부팅이었다. 여러 컴퓨터의 소프트웨어 갱신, 전자 수업에서 같은 그림이나 문서를 모두에게 보내는 일도 예로 들었다. 이 사례들은 파일 내용이 같고 받는 사람이 많은 구조를 공유한다. CFDP가 줄이려 한 것은 서버와 네트워크가 치르는 반복 비용이었다. 참여하지 않는 기계까지 방송을 듣는 부담은, 장차 IP 멀티캐스트가 널리 쓰이면 줄일 수 있다고 봤다.

수신 전에 클라이언트는 파일 이름에 대응하는 32비트 티켓과 파일 크기, 블록 크기를 받는다. BOOTP나 TFTP를 고친 앞단 서비스가 이 일을 맡을 수 있고, 이름을 티켓으로 바꾸는 절차는 CFDP 전송의 핵심 밖에 있다. 티켓을 얻은 뒤에는 같은 티켓의 패킷이 이미 흐르는지 먼저 듣는다. 다른 컴퓨터가 전송을 시작했다면 중간부터 합류한다. 일정 시간 아무것도 들리지 않을 때 FULREQ를 보내 전체 파일 방송을 시작하게 한다.

서버는 번호가 붙은 UDP 블록을 방송한다. 각 컴퓨터는 받은 패킷을 검사하고 번호에 맞는 자리에 저장한다. 늦게 들어온 기계는 앞부분이 비고, 먼저 들어온 기계도 중간 패킷 하나를 놓칠 수 있다. 흐름이 잠잠해졌는데 파일이 완성되지 않으면 PARREQ에 자기의 누락 번호를 적어 보낸다. RFC의 세 클라이언트 예시는 큰 전송을 공유해도 누락 목록은 각자 다르다는 점을 보여준다.

늦게 합류한 기계가 앞부분을 놓쳐도 방송 도중에는 그 빈칸을 바로 채울 수 없다. 같은 파일을 보내는 중 들어온 새 요청을 서버가 무시하기 때문이다. 클라이언트는 흐름이 멎고 대기 시간이 지난 뒤 빠진 번호를 다시 요청한다. 전송량을 아끼는 선택이 한 기계의 완료 시각을 뒤로 밀 수 있다. 설계자들은 수신기마다 따로 속도를 조절하는 대신 서버 패킷 사이에 간격을 두었다. 권장 간격은 인터페이스가 패킷 하나를 내보내는 시간의 약 두 배였다. 실험에서 대기 시간은 그 전송 시간의 여섯~여덟 배가 가장 잘 맞았다고 썼다. 보내는 쪽의 속도만 높여서는 느린 수신기의 빈칸을 없앨 수 없다.

512바이트 블록을 쓰면 전체 패킷이 문서가 인용한 IP 최소 MTU 576바이트 아래에 머문다. 블록 번호는 16비트라 논리 파일 하나의 상한은 32MB이고, 1024바이트 블록을 쓰면 64MB다. 더 큰 파일은 나눠야 한다. 전송을 묶는 방식에도 크기와 복구 단위의 제한이 붙어 있었다.

RFC Editor 기록은 CFDP를 Experimental로 분류한다. 문서에는 참조 구현이 언급되지만 실제 보급 대수나 부팅 완료 성적은 없다. 남는 장면은 단순하다. 서버가 마지막 블록을 뿌린 순간, 어떤 컴퓨터의 화면에는 여전히 한 칸이 비어 있을 수 있다.