요약

  • Kermit은 1981년 컬럼비아에서, 학생과 교직원이 사용하는 마이크로컴퓨터가 늘어나는 가운데 메인프레임과의 파일 교환에 대한 실용적인 해답으로 시작되었습니다.
  • 작고 명시적으로 인정된 패킷 코어가 직렬 회선 위에서 동작했고, 문자 집합, 레코드, 터미널 동작, 선택적 기능에 관한 규약들이 원시 연결로는 해결되지 않는 차이를 연결해 주었습니다.

최초의 Kermit 파일 전송 시연에서는 두 개의 Kermit-20 프로그램이 동일한 DECSYSTEM-20의 직렬 포트 사이를 널모뎀 케이블로 연결해 파일을 주고받았습니다. Kermit Project는 이를 개념 증명이라고 불렀습니다. 한 컴퓨터에서 파일을 복사하는 쪽이 더 쉬웠습니다. 결정적인 시험은 몇 주 뒤에 왔습니다. 한쪽 끝은 TOPS-20을 구동하는 DEC-20이었고, 다른 쪽은 CP/M-80을 구동하는 Intertec Superbrain이었습니다. 두 기계는 프로세서, 운영체제, 파일 표현 방식이 달랐습니다. 바이트를 보내는 것은 문제의 가시적인 일부일 뿐이었습니다.

컬럼비아의 컴퓨팅 그룹은 자신들의 시스템을 누가 사용하는지에 대한 변화에 직면해 있었습니다. 마이크로컴퓨터가 연구실, 학과, 가정, 기숙사 방에 등장하는 동안, 중앙 시분할 시스템은 여전히 사람들이 필요로 하는 파일과 서비스를 보유하고 있었습니다. 1983년에 준비한 논문에서 Frank da Cruz와 Bill Catchings는 수업이나 학기 ID가 오래 유지되는 디스크 저장 공간을 보장하지 못하는 학생들을 언급했습니다. 플로피 드라이브가 있는 마이크로컴퓨터는 작업을 로컬에 보관할 방법을 제공했지만, 사용자가 작은 기계와 메인프레임 사이에서 작업을 안정적으로 옮길 수 있어야 했습니다. 이 글은 한 기관의 설계 문제를 설명할 뿐이며, 대학 전반의 보편적 패턴을 확립하지는 않습니다.

통신 회선은 이런 불일치를 더 악화시켰습니다. 일반 비동기 직렬 회선은 잡음, 손실 문자, 버퍼 포화, 간헐적 캐리어 손실에 대해 거의 보호를 제공하지 못했습니다. 그래서 Kermit은 전송을 패킷으로 나누고 각 패킷을 대화의 일부로 만들었습니다. 송신자는 매개변수를 알리는 Send-Init 패킷으로 시작하고, 수신자가 자신의 패킷으로 응답합니다. 파일 헤더가 파일 이름을 지정하고, 데이터 패킷이 파일을 순차적으로 나눠 전송하며, 별도의 패킷이 파일 끝과 전송 끝을 표시합니다. 확인 응답을 받아야 송신자가 진행할 수 있고, 부정 확인 응답이나 타임아웃이 발생하면 패킷이 재전송됩니다.

이 절차는 의도적으로 소박했습니다. 패킷 번호는 64를 주기로 순환하므로 두 프로그램 모두 어떤 단위가 확인되었는지 인식하고 현재 교환 내에서 누락되거나 반복된 단계를 감지할 수 있었습니다. 필수인 한 문자 산술 검사는 변경된 패킷을 탐지하는 데 도움이 되었습니다. 이것은 현대적인 암호학적 체크섬이 아니었고, 어느 쪽 터미널의 사용자도 식별하지 않았습니다. 두 프로그램이 많은 전송 오류를 알아차리고 다시 시도할 수 있을 만큼은 충분했습니다. 신뢰성은 직렬 회선이 믿음직해진 것이 아니라 송신자와 수신자가 협력하는 데서 나왔습니다.

Kermit의 더 큰 상호운용성 문제는 그 회선 위에 있었습니다. 기계들이 통신 중에는 ASCII 문자를 공유할 수 있어도 파일 내용에 대해서는 불일치할 수 있었습니다. DEC-20과 CP/M 컴퓨터는 서로 다른 운영 환경을 사용했고, IBM 메인프레임은 추가적인 제약을 가져왔습니다. 파일이 단순한 바이트 스트림이 아니라 레코드를 담을 수도 있었고, 텍스트 인코딩이 다를 수도 있었으며, 호스트 터미널이 에코를 내거나 줄을 바꾸거나 대소문자를 변환하거나 제어 문자를 소비할 수도 있었습니다. 프로그램이 모든 연결을 투명한 파이프로 취급하면, 파일 내용이 수신 디스크에 도착하기 전에 변경될 수 있었습니다.

Kermit은 공통 전송 표현과 양쪽 끝에서의 명시적 변환으로 이에 응답했습니다. 기본 패킷 문법은 인쇄 가능한 문자를 사용했고, 데이터 안의 제어 바이트는 인쇄 가능한 시퀀스로 인코딩될 수 있었습니다. Kermit 프로그램은 이 교환 형식과 자신의 로컬 파일 규약 사이를 번역했습니다. 프로토콜 매뉴얼은 직렬 회선의 공통 전제를 좁게 기술합니다. 즉, 일반 비동기 회선 위의 ASCII였습니다. 이 매뉴얼은 모든 컴퓨터를 똑같이 만들지 않았습니다. 저장 방식, 인코딩, 터미널 동작이 달라도 각 기계의 Kermit 프로그램이 파일을 교환할 수 있도록 제한된 언어를 제공했을 뿐입니다.

설계는 또한 서로 같은 기능 집합을 갖고 있지 않은 구현들에 걸쳐 확장될 수 있어야 했습니다. 1983년 11월 매뉴얼에 따르면 프로젝트는 분산된 구현자들에게 하나의 고정된 프로토콜 버전을 강요할 수 없었습니다. 매뉴얼은 기본 기능과 선택적 기능을 기술하면서, 초기 교환의 필드를 통해 기능을 알리도록 했습니다. 매뉴얼의 설계 목표는 원시적인 구현이라도 더 고급 구현과 동작할 수 있어야 한다는 것이었습니다. 이는 설계자들이 표현한 야망이었으며, 모든 Kermit 프로그램 쌍이 상호운용되었다는 증거가 아니었습니다.

코어를 작게 유지하는 것이 프로토콜을 동결시키지는 않았습니다. 이후 버전은 더 긴 패킷, 더 강한 블록 검사, 전이중 슬라이딩 윈도우 같은 옵션을 추가했습니다. 매뉴얼은 슬라이딩 윈도우 작업을 1985–86년으로 기록하고 The Source Telecomputing의 그룹에게 그 공을 돌립니다. 이 확장은 다른 성능 조건을 다뤘습니다. 패킷마다 확인 응답을 기다리는 방식은 지연이 큰 경로에서 시간을 낭비할 수 있었습니다. 이 기능은 조용히 가정되는 것이 아니라 협상되었습니다. 이 옵션이 없는 수신자는 기본 교환 방식을 그대로 유지할 수 있었습니다. 그래서 이후 매뉴얼은 1981년의 첫 전송에 소급 적용되어서는 안 되는 기능이 아니라, 성장하는 구현 계열을 보여줍니다.

1984년까지 Kermit Project 연표는 ARPANET 상의 FTP 사이트와 Info-Kermit 메일링 리스트를 기록합니다. 프로토콜은 네트워크를 통해 배포하고 논의하기 쉬워졌지만, 원래 존재 이유는 구체적으로 남았습니다. 어떤 종류의 컴퓨터 앞에 앉은 사용자가 파일을 다른 컴퓨터로 옮겨야 한다는 것이었습니다. Kermit은 인터넷 표준이 아니었고 네트워크 프로토콜을 대체하지도 않았습니다. 직렬 연결, 나중에는 네트워크 서비스로 서로 도달할 수 있는 시스템들 사이에서 파일 전송을 사용 가능하게 만드는, 서로 다른 층위의 역할을 맡았습니다.

이 역사는 연결성과 상호운용성이 동의어가 아니라는 점을 일깨워 줍니다. 캐리어 신호가 두 터미널을 이어도 그들의 파일은 호환되지 않을 수 있습니다. 패킷 검사는 일부 손상을 잡을 수 있지만 데이터를 보낸 사람이 누구인지는 증명하지 못합니다. 공유된 명세가 교환을 가능하게 해도, 모든 구현이 모든 옵션을 채택했다는 보장은 되지 못합니다. Kermit의 기여는 이런 이음매를 명시적이고 구현 가능한 대화로 만든 것입니다.

출처