요약

  • FTP의ALLO명령은 클라이언트가 이어지는STOR또는APPE에 필요한 논리적 저장 용량을 선언하게 했으며, 레코드 또는 페이지 구조 파일에는 추가 크기를 함께 전달할 수 있었다.
  • 사전 할당이 필요 없는 서버는 이 명령을 no-operation으로 처리하도록 되어 있었다. 그202응답이 긍정적인 이유는 클라이언트가 계속 진행할 수 있기 때문이지, 바이트가 예약되었기 때문이 아니었다.
  • 저장 용량의 증거는 이후의 데이터 전송, 최종 응답, 쿼터 상태 및 결과로 생긴 파일에 속한다. 이러한 단계들을 하나의 성공 플래그로 뭉개면 프로토콜에서 가장 유용한 구분이 사라진다.

파일은 목적지보다 먼저 크기를 알고 있었다

송신자는 데이터 연결을 열기 전에 파일의 길이를 이미 알고 있는 경우가 많다. 미리 수신자에게 알려주는 것이 효율적으로 보인다. 필요한 공간을 예약하고, 맞지 않으면 작업을 거절하며, 어차피 실패할 전송에 네트워크 시간을 쓰지 않는 것이다. 그러나 이 이야기는 모든 호스트가 같은 종류의 예약 기능을 노출한다고 가정한다.

초기 인터넷은 저장 시스템의 전제가 서로 다른 기계들을 연결했다. 어떤 호스트는 파일을 쓰기 전에 공간을 할당해야 했다. 또 다른 호스트는 “이만큼의 바이트를 예약하라”는 별도 동작 없이 데이터가 도착하는 대로 파일을 확장했다. 모든 곳에 첫 번째 방식을 강제하는 프로토콜은 특정 로컬 저장 설계를 네트워크 접근 규칙으로 만들어 버린다.

1972년에 발표된RFC 354는 두 모델을 모두ALLOCATE (ALLO)의 정의 안에 넣었다. 어떤 서버는 새 파일을 위한 충분한 저장 공간을 이 명령으로 예약해야 할 수도 있었다. 십진수 인수는 선택된 바이트 크기를 기준으로 바이트를 나타냈고, 이어서STORE또는APPEND명령이 따라와야 했다.

같은 정의는 최대 크기를 미리 선언할 필요가 없는 서버가ALLO를 no-operation으로 처리하도록 지시했다. 이는 구현자가 수습하도록 남겨둔 누락이 아니었다. 상호운용성 선택이었다. 클라이언트는 서버의 저장 모델에 대한 권한을 얻지 않으면서도 계획상의 필요를 표현할 수 있었다.

1980년에 발표된RFC 765는 선언을 더 정밀하게 만들었다. 첫 번째 정수는 파일의 저장 용량을 논리 바이트로 나타냈다. 레코드 또는 페이지 구조 파일에는 공백,R, 공백으로 시작하는 최대 레코드 또는 페이지 크기를 추가로 실을 수 있었다. 그 두 번째 수치에만 관심이 있는 서버는 첫 번째 값을 더미로 받아 무시하도록 되어 있었다.

문법은 이 숫자의 한계를 드러냈다. 논리 바이트 수는 반드시 파일시스템 블록 수도, 쿼터 차감액도, 압축된 전송 길이도, 영구적인 물리 할당도 아니었다. 그것은 활성 FTP 표현에서의 서술이며, 이를 로컬 자원 동작으로 번역할지 모르는 서버에 제시되는 값이었다.

일어나지 않은 동작에 대한 긍정적 응답

RFC 959는 1985년에 이 명령을 유지했다. 문법은 하나의 십진 정수를 요구하고R과 두 번째 값을 허용했다.ALLO뒤에는STOR또는APPE가 따라야 했고, 사전 최대 크기 선언을 요구하지 않는 서버는 이를NOOP처럼 처리해야 했다.

응답 규칙이 더 날카로운 경계를 제공했다.TYPE이나ALLO처럼 성공적으로 실행되어도 사용자 프로세스에 새 정보를 주지 않는 명령은200을 받는다. 어떤 서버에서 할당이 그 컴퓨터 시스템과 무관해서ALLO를 구현하지 않았더라도, 여전히 긍정적 완료가 바람직했다. 단순한 사용자 프로세스는 의도한 순서대로 진행할 수 있음을 알게 된다. 지정된 응답은202이며, 예시 텍스트는 “No storage allocation necessary(저장 할당이 불필요함)”였다.

202의 일반적 설명은 “Command not implemented, superfluous at this site(명령이 구현되지 않음, 이 사이트에서는 불필요)”이다. 두 부분 모두 중요하다. 서버는 요청된 동작이 구현되지 않았음을 밝히면서도, 그 부재가 사용자의 진행을 막지 않는 이유를 함께 밝혔다. 긍정적 속성은 물리적 예약이 아니라 프로토콜상의 진행에 속한다.

RFC 959는 이 경우를502— 사이트 고유가 아닌 요청 동작이 미구현일 때 — 및504— 사용 가능한 명령의 미구현 매개변수에 쓰일 때 — 와 구분했다. 응답 분류 체계는 지원하지 않는 모든 동작을 무조건 녹색으로 칠하지 않았다. 그 시스템에서 누락된 동작이 중요한지를 물었다.

200을 범용 영구 영수증으로 부풀려서도 안 된다. 서버가 실제 예약을 수행했을 수 있지만, 코드 자체만으로는 물리 블록 수, 보유 기간, 쿼터 상호작용, 동시 쓰기 또는 지속성에 대해 아무 것도 말해주지 않는다. 사양은 성공적 실행이 클라이언트에게 새 정보를 가져다주지 않는 지점에서 정확히 이 코드를 사용한다. 더 강한 의미는 구현과 운영 증거를 필요로 한다.

용량은 다음 명령 뒤에 기다리고 있었다

ALLO는 파일 내용을 담지 않았다. 이어지는STOR는 서버에 데이터 연결로 데이터를 받아 경로명 아래 저장할 것을 요청했다. 파일이 이미 존재하면 전송된 데이터가 대체했고, 존재하지 않으면 서버가 생성했다. 계획상의 주장이 이제 연결, 권한, 경로명, 저장 시스템과 마주했다.

응답 순서는 시작과 결과를 분리했다.125는 데이터 연결이 이미 열렸고 전송이 시작 중임을 말했다.150은 파일 상태가 양호하고 데이터 연결이 곧 열릴 것임을 말했다. 둘 다 잠정 응답이었다. 긍정 완료는 나중에226또는250으로 도착할 수 있었고, 연결·로컬 처리·경로명·권한·저장 실패는 각자의 결말을 유지했다.

두 응답이 증거 경계를 명백히 만든다.452는 시스템의 저장 공간이 부족하여 요청된 동작이 취해지지 않았음을 뜻한다.552는 현재 디렉터리 또는 데이터셋의 저장 할당을 초과하여 요청된 파일 동작이 중단되었음을 뜻한다. 따라서 한 세션은ALLO에 긍정적202를 받고STOR에서 실패할 수 있으며, 이는 프로토콜과 모순되지 않는다. 사전 예약은 불필요했고, 이후의 용량은 보장되지 않았다.

증거는 단계적으로 쌓였다.ALLO전에는 클라이언트 자신의 추정만 있었다.202이후에는 그 준비 동작 없이 계속 진행해도 된다는 서버의 허가가 생겼다.125또는150이후에는 데이터 단계가 열렸거나 임박했음을 알았다. 기대한 내용이 실제 저장되었다는 더 강한 주장은 적절한 최종 응답과 결과 파일의 확인만이 뒷받침할 수 있다.

RFC 3659는 기계가 읽을 수 있는 파일 권한을 설명하면서 관련된 경고를 반복했다. 쓰기 권한 표시는 적절한 명령이 동작하리라는 보장을 결코 함의할 수 없었다. 사용 가능한 저장 공간을 포함한 시스템별 한계가 여전히 동작을 실패하게 만들 수 있었다. 권한은 안내일 뿐이었다. 이 구절은ALLO를 재정의하지 않았지만, 겉보기 자격과 실행된 결과 사이의 같은 구분을 지켰다.

선택 지원이 명령을 닿지 않게 만들지는 않았다

1989년 호스트 요구사항인RFC 1123은 서버의ALLO지원을 선택 사항으로 분류했다. 동시에 사용자 FTP 프로그램에QUOTE— 임의의 문자열을 서버에 전달하고 그로부터 오는 모든 응답을 표시하는 기능 — 의 구현을 요구했다.

이 논의는SITE와ALLO를 예로 들었다. 클라이언트가 그 기능을 전담해서 이해하지 못하더라도, 사용자는 시스템 고유 또는 선택 기능에 접근할 수 있었다. 이 배치는 클라이언트의 핵심을 제한하면서 서버 측 다양성을 막지 않았다. 또한 원시 응답을 그대로 보존했으며, 이는202가 일반 성공 표시등보다 더 유용한 의미를 담기 때문에 중요했다.

IANA FTP 명령 및 확장 레지스트리는 여전히ALLO를 기본 명령 “Allocate”로 등재하고 RFC 959를 인용한다. 등록은 어휘와 참조를 확립한다. 그러나 배포 현황을 조사하지 않고, 서버의 할당 동작을 증명하지 않으며, 잔여 용량을 측정하지도, 특정 전송이 저장소에 도달했음을 증명하지도 않는다.

감사 추적은 첫 긍정 코드보다 오래 살아남아야 한다

“ALLO 성공”만 적힌 로그 항목은 설계된 구분을 파괴한다. 유용한 추적은 정확한 명령, 존재하는 경우 두 정수, 활성TYPE과STRU, 수치 응답, 전체 응답 텍스트를 보존한다.200과202는 모두 긍정이지만 서로 다른 로컬 결정을 서술한다.

추적은 그 준비를 이어지는STOR또는APPE와 연관시켜야 한다. 데이터 연결이 열렸는가? 몇 바이트가 지나갔는가? 전송은 중단되었는가? 어떤 최종 응답이 도착했는가? 대상 파일이 기대한 크기와 체크섬으로 존재하는가? 용량 주장에는 또한 해당 시점의 잔여 공간, 계정 쿼터, 디렉터리 한도, 경쟁 활동 증거가 필요하다.

논리 크기에서 로컬 비용으로의 환산은 계속 보여야 한다. 레코드 구조, 문자 표현, 스파스 할당, 메타데이터, 임시 파일 전략은 모두 소비되는 자원을 바꿀 수 있다. 프로토콜 선언은 계획을 조율할 뿐, 저장 회계를 대체하지 않는다.

FTP의 최종 긍정 응답조차 그 자체로 무기한 보존, 복제 또는 미래의 복구 가능성을 증명하지 않는다. 이러한 속성이 중요한 곳에서는 파일을 다시 읽어 확인하고, 필요하면 의도된 사본으로부터 복구해야 한다. 요점은 프로토콜 응답을 불신하라는 것이 아니다. 모든 결론을 그것을 산출한 단계의 범위 안에 유지하라는 것이다.

출처