요약

  • FTP의STRU P는 불연속 파일을 독립적인 인덱스 페이지로 표현했다. 페이지 인덱스는 논리적 위치를 기술할 뿐, 전송 순서를 기술하지 않았다.
  • 누락된 페이지 테이블 항목은 단순히 전송되지 않은 것이고, 존재하면서 0을 담고 있는 페이지는 여전히 데이터였다. RFC 959는 구멍이 0의 페이지와 같지 않다고 명시적으로 경고했다.
  • 페이지 구조는 주로 TOPS-20과 NLS의 필요에서 나왔다. RFC 1123은 나중에 일반 구현을 권장하지 않으면서도, 임의 접근 파일이나 구멍 파일이 실제로 필요할 때는 사적 대체물이 아닌 표준 형식을 요구했다.

데이터 연결을 건너지 않은 페이지

수신자가 한 페이지 헤더를 본 뒤, 논리적 인덱스가 한 자리를 건너뛴 다음 헤더를 본다고 하자. 패킷 중심의 진단은 손실을 찾는 데서 시작한다. 바이트 스트림 재구성은 그 간격을 0으로 채울 수 있다. 둘 다 틀릴 수 있다.

RFC 959는 불연속 파일, 즉 임의 접근 파일 또는 "구멍 파일(holey)"을 위해 페이지 구조를 정의했다. 페이지 인덱스 필드는 파일 내 논리적 페이지 번호였으며, 전송 순서 번호가 아니라고 명시했다. 따라서 인덱스의 건너뜀은 전송 중 손상이 아니라 원본 파일의 특성을 기술할 수 있다.

부록은 이 구분을 이례적으로 단호하게 밝힌다. TOPS-20 페이지 맵의 빈 페이지는 전송되지 않았고, "구멍은 0의 페이지와 같지 않다(NOT the same)"고 했다. 하나는 구조적 부재다. 다른 하나는 값이 우연히 0인, 점유된 페이지다. 첫째를 둘째로 바꾸면, 어떤 시스템에서 응용이 두 경우를 비슷하게 읽더라도 파일 자체는 달라진다.

이것이 이 글의 중심 역사적 사실이다. FTP는 한때, 그곳에 데이터 페이지가 존재하지 않는다는 사실 자체가 의미를 갖는 무언가에 대한 회선 표현이 필요했다.

세 구조, 파일에 관한 세 가지 주장

FTP는 표현 유형, 파일 구조, 전송 모드를 분리했다. 이들은 상호작용했지만 서로 다른 질문에 답했다.TYPE은 논리적 표현을 기술했다.STRU는 내부 조직을 기술했다.MODE는 전송 바이트가 데이터 연결에서 어떻게 프레임되는지를 기술했다.

프로토콜은 세 가지 구조를 정의했다. 파일 구조는 파일을 하나의 연속된 데이터 바이트 열로 취급하며 기본값이었다. 레코드 구조는 파일을 순차적 레코드로 취급했다. 페이지 구조는 파일을 독립적인 인덱스 페이지로 취급했다.

이 선택지는 분류학적 열정이 아니라 이기종 저장소에서 나왔다. RFC 959는 소스 코드를 고정 길이 레코드로 자연스럽게 저장하는 IBM 메인프레임과, 문자를 줄로 나뉜 스트림으로 표현하는 TOPS-20 호스트를 대비시켰다. 서로 다른 시스템이 유용한 파일을 교환하려면, 각 측은 상대가 어떤 가정을 했는지 알아야 했다.

변환은 허용되었지만, 되돌릴 수 있어야 했다. 레코드 구조를 받는 파일 지향 호스트는 레코드를 로컬에서 유용한 형태로 바꿀 수 있었지만, 같은 파일을 다시 레코드 구조로 가져올 때는 그 변환을 되돌릴 수 있어야 했다. 이후RFC 1123도 같은 원칙을 유지했다. 레코드 구조와 파일 구조 간의 변환은 실용적인 범위에서 가역적이면서 대상 호스트에서 유용해야 한다.

바이트만으로는 어떤 변환이 적용되었는지 알 수 없었다. 활성 파라미터 튜플이 증거의 일부였다.

인덱스는 위치이지 도착 순서가 아니었다

STRU P의 모든 페이지는 헤더를 담았다. 최소 헤더는 네 개의 논리 필드를 담았다: 헤더 길이, 페이지 인덱스, 데이터 길이, 페이지 유형. 각 필드는 하나의 논리 바이트를 차지했고, 그 비트 폭은 수신기의 기계 워드 가정이 아니라TYPE에서 왔다.

페이지 인덱스는 파일 맵에서의 목적지를 알려주었다. "이것이 일곱 번째로 보내진 단위다"라고 말하지 않았다. 연결상의 순서가 다르더라도 페이지는 선언된 위치로 해석될 수 있었다. 도착 순서와 파일 순서는 별개의 사실이었다.

데이터 길이는 0일 수 있었다. 이때 페이지 유형이 그 숫자가 모든 의미를 지니는 것을 막았다. 마지막 페이지는 네 필드 헤더와 0 데이터로 페이지 전송을 닫았다. 단순 페이지는 일반 페이지 데이터를 나타냈다. 기술자 페이지는 파일 전체에 대한 기술 정보를 담았다. 접근 제어 페이지는 페이지 수준 제어 정보를 위한 필드를 추가했다.

그러므로 "길이 0"은 "아무것도 없음"의 보편적 동의어가 아니었다. 0 데이터의 종료 헤더에는 프로토콜적 의미가 있었다. 기술자 페이지는 파일 전체에 관한 것일 수 있었다. 생략된 인덱스는 구멍을 나타낼 수 있었다. 해석은 단일 개수가 아니라 유형과 맵 위치에 의존했다.

TOPS-20에 이 구분이 왜 필요했나

RFC 765와 RFC 959의 페이지 구조 부록은 그 출처를 밝힌다. 이 필요는 주로 TOPS-20 시스템 간의 효율적인 파일 전송, 특히 NLS에서 사용되는 파일에서 비롯되었다.

TOPS-20 디스크 파일은 경로명, 페이지 테이블, 비어 있을 수도 있는 페이지 집합, 속성으로 이루어졌다. 페이지 테이블은 최대 2^18개 항목을 가질 수 있었다. 항목은 비어 있거나 페이지를 가리킬 수 있었고, 점유된 항목은 페이지별 접근 비트를 담을 수 있었다. 파일 속성에는 타임스탬프, 바이트 크기, EOF 포인터, 카운터, 백업 정보가 포함되었다.

페이지 맵도 끝부분도 컴팩트한 바이트 배열처럼 보일 필요가 없었다. 빈 테이블 항목이 점유된 항목 사이에 있을 수 있었다. EOF 포인터는 숫자였고 마지막 데이터를 가리킬 필요가 없었다. NLS 파일은 이 두 가지 이례적 경우를 모두 사용했다.

그 환경을 위해 표준은TYPE L 36, STRU P, MODE S를 문서화했다. 36비트 논리 유형은 TOPS-20 워드와 일치했다. 페이지 헤더는 맵 인덱스, 데이터 길이, 페이지 종류, 그리고 데이터 페이지의 경우 접근 비트를 담았다. 별도의 기술자 페이지가 파일 전체 정보를 담을 수 있었다.

이는 모든 호스트가 TOPS-20이 되어야 한다는 주장이 아니었다. 어느 한 호스트의 의미 있는 구조가, 다른 호스트가 저장소를 다르게 조직한다는 이유만으로 평평하게 눌리지 않도록 하려는 시도였다.

구멍, 0 페이지, 잘린 데이터

부록은 무심한 정규화기가 합쳐 버릴 수 있는 세 가지 경우를 구분한다.

첫째, 빈 페이지 맵 항목은 구멍이며 전송에서 생략된다. 둘째, 점유된 페이지에는 0 값 워드가 있을 수 있으며, 그래도 페이지로 남는다. 셋째, 점유된 TOPS-20 페이지 내 후행 0은 데이터 길이를 통상의 512 워드 아래로 줄여 폐기할 수 있었다.

세 경우 모두 회선상의 0이 아닌 값의 수를 줄일 수 있다. 그러나 같은 진술이 아니다. 구멍은 그 맵 위치에 페이지가 없었다고 말한다. 명시적 페이지는 그곳에 저장소가 있었다고 말한다. 잘린 페이지는 존재하는 페이지가 문서화된 규칙에 따라 더 작은 전송 데이터 범위를 가졌다고 말한다.

이 때문에 연결된 페이지 페이로드의 체크섬만으로는 충실한 재구성을 증명할 수 없다. 증거에는 인덱스, 유형, 길이, 기술자 필드, 종료 표시, 변환 정책이 포함되어야 한다. 그렇지 않으면 서로 다른 파일 맵이 기만적으로 비슷한 전송 내용을 만들어낼 수 있다.

표준은 모든 수신 파일 시스템이 구멍을 똑같이 노출한다거나, 생략된 슬롯이 항상 0으로 읽힌다고 말하지 않는다. 페이지 수준 접근 비트가 이질적인 대상에서 강제될 수 있다고도 보장하지 않는다. 그것들은 로컬 저장소와 정책의 문제다. FTP는 구분을 제공했고, 구현은 그 구분을 정직하게 매핑해야 했다.

권장되지 않지만, 마음대로 재발명할 수는 없었다

1989년까지 RFC 1123은 의미 있는 판단을 내렸다. 페이지 구조의 구현은 일반적으로 "권장되지 않음(not recommended)"이었다. 이 메커니즘은 전문적이었고, 폭넓은 상호 운용성은 더 작은 필수 코어에 의존했다.

그러나 그 문서는 사적 재발명을 허가하지 않았다. 어떤 호스트가 임의 접근 파일이나 구멍 파일을 위해 FTP를 실제로 필요로 한다면, 사적인 FTP 표현을 만드는 대신 정의된 페이지 구조 형식을 사용해야 했다.

이는 단순한 폐기보다 날카로운 규칙이다. 일반 구현은 이 기능을 거부할 수 있었다. 전문적 구현은 유지할 수 있었다. 그러나 같은 문제에 FTP를 재사용하면서 호환되지 않는 사적 의미를 부여하는 것은 안 되었다.

최소 호스트 요구사항이 이 경계를 강화했다. 파일 구조는 필수였다. 레코드 구조는 파일 시스템이 지원하는 호스트에만 필수였으며, 다른 호스트는 스트림을 그대로 저장함으로써STRU R을 받아들일 수 있었다. 페이지 지원은 선택 사항으로 남았다. 명령 어휘와 각 인수의 가용성은 같은 약속이 아니었다.

레지스트리 행은 페이지 지원이 아니다

이후RFC 5797은STRU를 FTP의 필수 기본 명령 중 하나로 배치했다.IANA FTP 명령 및 확장 레지스트리는 이를 File Structure, 즉 파라미터 설정 명령으로 기록하며 필수 준수 등급을 부여하고 참조로 RFC 959를 명시한다.

그 행은 동사와 그 역할을 조율한다. 특정 서버가P를 받아들인다거나, 클라이언트가 TOPS-20 페이지 맵을 재구성할 수 있다거나, 페이지 제어가 살아남는다거나, 오늘날 누군가 이 기능을 배포한다는 것을 증명하지 않는다. 필수 명령도 여전히 선택적이거나 시스템 의존적인 파라미터 기능을 가질 수 있다.

이 구분은 파일의 내용을 닮았다. 레지스트리에 이름이 존재하는 것은 구현이 존재하는 것이 아니며, 전송된 페이지의 부재가 0 페이지의 존재가 아니었던 것과 같다.

빈 자리가 여전히 말해주는 것

현대 데이터 시스템은 "존재하지 않음", "0", "알 수 없음", "삭제됨", "해당 없음"을 하나의 편리한 값으로 반복적으로 압축한다. 결과 파일은 파싱되고 체크섬은 정규화된 출력과 일치할 수 있지만, 원래 구조는 사라져 있다.

FTP의 페이지 구조는 전문적이었고, 더 이상 일반적인 인터넷 파일 전송을 정의하지 않는 기계와 응용에 묶여 있었다. 그러나 그 설계 규율은 여전히 유효하다. 부재를 명시적으로 이름 짓는다. 도착 순서와 별개로 위치를 전달한다. 의미를 재구성하는 데 필요한 메타데이터를 보존한다. 어떤 변환이 가역적인지 밝힌다. 형식이 그 추론을 허가하지 않는 한, 침묵에서 내용을 추론하지 않는다.

사라진 페이지는 유용한 정보였다. 그것을 채우는 것은 복구가 아니었다. 그것은 다른 파일이었다.

출처