큰 파일은
조금씩 보내야 합니다.

01

보낸 양과 받은 양을 따로 셉니다.

화면은 두 숫자를 각각 표시합니다. 보내는 쪽 코드에서 전송 함수가 성공을 돌려줬다고 해서 상대가 그만큼 받아 처리한 것이 아니기 때문입니다. 그 사이의 차이가 어딘가에 머물러 있고, 그 머무는 곳이 메모리입니다. 두 숫자를 합쳐 진행률 하나로만 보여줬다면 이 문제가 화면에서 사라졌을 것입니다.

02

버퍼는 무한하지 않습니다.

쌓이는 양에 상한을 두고 그 비율을 막대로 표시합니다. 상한이 없다고 가정하면 메모리가 계속 늘다가 프로그램이 죽는데, 실제로 큰 파일을 다룰 때 겪는 대표적인 사고가 이것입니다. 화면에서 막대가 가득 차는 장면에 위험 판정을 붙여 둔 이유이고, 이 지점이 곧 생산을 멈춰야 하는 시점입니다.

03

멈추고 다시 시작하는 것이 제어입니다.

제어를 켠 설계에서는 버퍼가 일정 수준에 도달하면 보내는 쪽이 잠시 멈추고, 비워지면 다시 보냅니다. 속도를 미리 정해 두고 맞추는 것이 아니라 받는 쪽의 상태를 보고 그때그때 조절하는 방식입니다. 화면에서 일시 정지 표시가 켜졌다 꺼졌다 반복하는 것이 정상 동작이며, 그 리듬 자체가 이 설계의 모습입니다.

04

조각에 번호가 있어야 이어받습니다.

연결이 끊겼을 때 처음부터 다시 보내지 않으려면 어디까지 확정됐는지 알아야 합니다. 그래서 조각마다 번호를 붙이고 받는 쪽이 확정한 마지막 번호를 기억합니다. 화면이 끊김 장면에서 받은 개수를 그대로 유지하는 것은 그 지점부터 이어서 받을 수 있다는 표현입니다.

05

개수만으로 완료를 판단하지 않습니다.

마지막에 검증 단계를 따로 둔 이유는, 조각 수가 맞아도 내용이 온전하다는 보장이 없기 때문입니다. 전체 길이와 내용 요약값을 함께 확인해야 파일이 제대로 도착했다고 말할 수 있습니다. 화면에서 검증 결과를 통과와 실패로 나눠 표시하는 것이 이 단계를 생략하면 안 된다는 표시입니다.

06

경계는 직접 만들어야 합니다.

바이트가 흐르는 통로에는 여기까지가 한 조각이라는 표시가 없습니다. 보낸 쪽이 나눠 보낸 단위와 받는 쪽이 한 번에 읽어 오는 단위가 일치하지 않으므로, 길이나 구분자를 직접 붙여야 조각을 다시 나눌 수 있습니다. 화면에서 조각 단위로 세는 것이 가능한 이유도 그런 표시를 붙였다고 가정하기 때문입니다.

07

두 설계의 결말이 같지 않습니다.

제어가 없는 쪽은 빠르게 끝나는 것처럼 보이다가 문제를 만들고, 제어가 있는 쪽은 멈췄다 가기를 반복해 느려 보이지만 끝까지 갑니다. 화면에서 두 설계의 마지막 판정을 비교하면 속도와 완주가 다른 목표라는 점이 드러납니다.

08

메모리는 조용히 늘어납니다.

버퍼가 차오르는 동안 프로그램은 오류를 내지 않고 정상적으로 동작합니다. 그래서 개발 중 작은 파일로 시험할 때는 아무 문제가 보이지 않다가, 운영에서 큰 파일이나 느린 회선을 만났을 때 갑자기 죽습니다. 화면이 버퍼 막대를 항상 띄워 두는 것은 평소에 보이지 않는 값을 눈에 보이게 만들려는 것이고, 실제 코드에서도 이 값을 지표로 내보내 두는 편이 좋습니다.

09

받는 쪽 속도는 통제할 수 없습니다.

받는 쪽이 느린 이유는 디스크가 바쁘거나 CPU 가 부족하거나 그 프로그램이 다른 일을 하고 있어서일 수 있고, 보내는 쪽에서는 어느 쪽인지 알 수 없습니다. 그래서 원인을 알아내려 하지 않고 상태만 보고 반응하는 구조를 씁니다. 상대가 왜 느린지 몰라도 옳게 동작한다는 점이 이 방식이 오래 쓰이는 이유입니다.