요약

  • RFC 1116는 행 편집과 신호 처리의 일부를 클라이언트로 옮겼습니다. 네트워크가 더 이상 키 입력 하나하나를 보지 않게 되면서 체감 지연과 패킷 수가 줄었습니다.
  • DO/WILL 합의는 하위 협상을 허용했고, MODE_ACK는 모드 마스크를 정렬하며, SLC_ACK는 문자 연결을 확정했습니다. 이 어느 하나도 명령 실행에 대해서는 아무것도 보증하지 않았습니다.
  • 행 종료 또는 전송 문자는 로컬 버퍼의 일부를 되돌릴 수 없게 만들었습니다. 그 후에도 데이터를 서버 쪽에서 운반하고, 디코딩하고, 수용하고, 실행하는 과정이 남아 있었습니다.

근접감은 클라이언트가 만들었다

RFC 1116은 눈에 보이는 비용에서 출발했습니다. 문자 단위 Telnet에서는 키 입력 하나마다 여러 패킷이 따라붙을 수 있었습니다. Linemode에서는 명령행 한 줄에 몇 개의 패킷이면 충분했습니다. 지연이 큰 링크에서 사용자는 입력 중에는 즉각적인 반응을 느끼고, 입력을 마친 뒤에야 전송 지연을 겪었습니다. 패킷 단위로 과금되는 네트워크에서는 비용 절감도 직접적이었습니다.

이 전환은 원격 컴퓨터의 부담도 덜어 주었습니다. 프런트엔드가 지우기, 재출력, 고립된 문자들을 흡수하여 매 키 입력마다 슈퍼컴퓨터를 가로막지 않아도 되었습니다. Linemode는 곧 아키텍처 결정이었습니다. 사용자 경험의 일부를 가장자리가 담당하게 된 것입니다.

RFC Editor 페이지는 1989년 8월의 제안과 그 후속 문서를 보존하고 있습니다.IETF Datatracker는 문서적 맥락을 제공합니다. 1990년 10월에 발표된RFC 1184는 RFC 1116을 폐기(obsolète)로 만들고 모드와 시각 편집 기능을 추가했지만, 로컬 편집과 원격 처리 사이의 분리는 그대로 두었습니다.

옵션 수락이 곧 편집 활성화는 아니었다

RFC 855의 일반 문법은 두 단계를 요구합니다. DO와 WILL은 양측이 한 옵션에 대해 논의하기로 합의했음을 나타냅니다. 그다음 SB와 SE가 매개변수를 감쌉니다. DONT 또는 WONT는 이 허가를 철회할 수 있습니다.

Linemode의 기본값은 정확히 WONT와 DONT였습니다. Telnet 연결의 존재, 그리고 옵션 번호 34에 대한 지식조차도 편집이 실제로 어디에서 이루어지는지에 대해 아무것도 말해 주지 않았습니다. DO/WILL 쌍은 협상의 문을 열 뿐, 그 결과를 정하지 않았습니다.

하위 모드 MODE는 또 하나의 단계를 추가했습니다. 보통 서버가 마스크를 요청하고 클라이언트가 이를 확인했습니다. EDIT는 행 처리를 담당했고, TRAPSIG는 인터럽트 문자를 로컬에서 Telnet 명령으로 변환할지 결정했습니다. MODE_ACK는 이 비트들을 일치시키는 역할이었습니다. 그 대상은 두 Telnet 프로세스의 설정이지, 사용자가 입력한 행이 아니었습니다.

따라서 신뢰할 만한 기록은 “옵션이 허용됨”, “EDIT 활성화”, “명령 성공”을 하나로 묶지 않습니다. 첫째는 프로토콜상의 동의, 둘째는 처리 상태, 셋째는 응용 계층의 주장입니다.

“완료”는 로컬 행을 가리켰다

EDIT가 활성화되면 클라이언트는 문자들을 보관하고 편집 기능을 적용한 뒤 완성된 행을 전송했습니다. RFC 1184에서 로컬 종결자는 회선 위에서 CR LF가 됩니다. 이 시점까지 사용자는 서버에 아무것도 취소하라고 요청하지 않고도 문자를 제거하거나 바꿀 수 있었습니다.

FORWARDMASK는 이 경계를 더 풍부하게 만들었습니다. 서버는 버퍼를 내보내야 할 문자들을 지정할 수 있었고, SLC_FORW1과 SLC_FORW2가 두 개를 더했습니다. 로컬 터미널 드라이버가 요청된 마스크를 정확히 재현할 수 없다면, 클라이언트는 더 넓은 범위의 제어 문자에 대해 전송하면서 이를 수용할 수 있었습니다.

따라서 합의가 항상 서버 의도의 정확한 복제를 만들어 내는 것은 아니었습니다. 합의는 자신의 능력에 맞는 로컬 구현을 허용한 것입니다. 버퍼의 해당 부분이 전송되고 나면 RFC 1184는 더 이상 편집할 수 없다고 경고했습니다.

이 비가역성은 클라이언트에서 끝났습니다. 바이트들은 여전히 TCP를 통과하고, Telnet 데이터로 인식되고, 접속된 프로세스에 도달하고, 그 프로세스의 문법과 정책을 만족시키고, 경우에 따라 작업을 개시하고, 응답을 만들어 내야 했습니다. 로컬 행은 이 사실들에 직접 접근할 방법이 없었습니다.

SLC_ACK는 키보드 규칙 하나를 확인했다

SLC는 기능, 수정자, ASCII 문자 하나를 연결했습니다. 선언 수준은 기능이 없음, 있으나 고정됨, 값이 지정됨, 기본값으로 되돌아감을 표시했습니다. 한쪽이 제안을 수용하면 같은 연결을 SLC_ACK와 함께 되돌려 보냈습니다.

이 확인 응답은 미래의 효과에 대한 영수증이 아니었습니다. 그것은 쌍방이 한 키를 해석하는 방식에 합의했다는 뜻이었습니다. 그 키가 실제로 눌렸다는 말, 대응하는 Telnet 명령이 상대방에 도달했다는 말, 그쪽에서 프로세스가 반응했다는 말은 아니었습니다.

RFC 1184는 시스템이 해당 기능을 제공하지 않을 경우 ABORT, EOF, SUSP를 무시하는 것조차 허용했습니다. SLC_FLUSHIN과 SLC_FLUSHOUT의 표시는 참고용이었고 인터페이스가 이를 무시할 수 있었습니다. 기능의 이름과 그 전송만으로는 인터럽트, 파일 끝, 버퍼 비움을 증명하기에 부족했습니다.

에코와 흐름은 서버를 대신하여 증언하지 않았다

RFC 857은 상대 끝단을 위해 수행하는 에코와, 시스템이 자체적으로 에코하기로 선택하는 것을 구분합니다. 즉시 눈에 보이는 문자는 논리적 키보드나 클라이언트를 떠나지 않았을 수도 있었습니다. 반응성 있는 표시는 Linemode의 이점이지 네트워크 수신 확인이 아니었습니다.

출력 흐름 제어 역시 자신만의 상태 기계를 유지했습니다. RFC 1116과 1184는 로컬 Telnet 프로세스가 XON과 XOFF를 소비하는지를 결정하기 위해 별개의RFC 1080옵션을 참조했습니다. 이 옵션은 키보드 편집도, 응용 중단도, TCP 창도, 혼잡도 아니었습니다.

이런 경계들은 하나의 “터미널 활성” 지표가 에코, 버퍼, 신호, 출력, 원격 프로세스를 모두 대변하지 못하게 막았습니다.

결과는 Linemode가 기술한 경계 너머에서 시작되었다

IANA Telnet 옵션 레지스트리는 지금도 34를 Linemode에 할당하고 RFC 1184를 인용합니다. 이 레지스트리는 코드를 조율할 뿐, 세션을 관찰하지도 소프트웨어를 인증하지도 않습니다.

RFC 854는 NVT와 제어 명령을 제공합니다. 데이터와 신호를 어떻게 운반하는지를 설명하지만, 응용이 한 행을 유효하거나 허용된 것으로 판단하는 방법은 설명하지 않습니다. RFC 1184는 보안 문제는 다루지 않는다고 명시합니다.

따라서 증거의 연쇄는 길게 유지되어야 합니다. 버퍼 완성, 접두부 전송, 바이트 도착, Telnet 디코딩, 수신 프로세스 확인, 입력 수용, 작업 개시, 결과 생성, 응답 수신 및 올바른 대응. Linemode는 앞쪽 단계의 비용을 줄였을 뿐, 뒤쪽 단계에 서명하지 않았습니다.

출처