요약

  • RFC 1080은 Telnet의 한쪽 끝이 상대방의 소프트웨어 흐름 제어를 켜거나 끄도록 요청할 수 있게 했으나,DO/WILL합의 이후에만 가능했다.
  • 이 옵션은 사용자 Telnet 프로세스와 자신의 터미널 사이의 로컬 경로를 대상으로 했다. TCP나 원격 애플리케이션을 중단시키지 않았고, 드라이버의 실제 상태를 확인해 주지도 않았다.
  • 합의는 초기 상태를 활성으로 강제했고, 철회는 명령 전송 권한을 제거하며 클라이언트를 구현 고유의 로컬 값으로 되돌릴 수 있었다.

같은 바이트에 대한 두 가지 의미

RFC 854의 가상 터미널 키보드는 US-ASCII 128개 코드를 모두 생성할 수 있었다. 따라서 원격 프로그램은 Control-S와 Control-Q를 다른 문자와 마찬가지로 실제 입력으로 취급할 수 있었다.

로컬 터미널은 이 키에 종종 두 번째 기능을 부여했다. 소프트웨어 흐름 제어는 XOFF(보통 Control-S)를 가로채 출력을 정지시키고, XON(보통 Control-Q)으로 출력을 재개했다. 드라이버는 해당 입력을 소비했다. 서버는 그것을 결코 볼 수 없었다.

이 충돌은 좋은 문자와 나쁜 문자의 대립이 아니었다. 버퍼나 읽기 프로세스가 따라가지 못할 때 가로채기는 화면을 보호했다. 반면 일부 에디터에서는 정당한 명령을 지워버렸다. 따라서 서버가 터미널을 소유한다고 주장하지 않으면서 결정권을 옮길 필요가 있었다.

1988년 11월에 발표된RFC 1080은 코드 33을TOGGLE-FLOW-CONTROL에 부여했다. 이 규격의 힘은 위임이 작다는 데 있다.

조정 전의 허가

RFC 855는 복잡한 옵션을 두 단계로 구성했다. 먼저 양쪽 프로세스가 한 파라미터에 대해 논의하기로 동의하고, 그 다음에야 하위 협상이 이어진다.

보통의 경우 호스트가DO TOGGLE-FLOW-CONTROL을 보냈다. 터미널에 연결된 Telnet 클라이언트는WILL로 응답했다. 전자는 요청을 보낼 준비가 되었음을 선언하고, 후자는 명령에 따라 자신의 흐름 제어를 변경하기로 수용했다.

DONT와WONT는 이 관계를 거부했다. 드라이버가 이미 XON/XOFF를 사용 중인지는 말하지 않았다. 다만 이 프로토콜을 통해 그것을 제어할 가능성을 닫았을 뿐이다.DO와WILL교환이 완전히 끝나기 전에는ON이나OFF하위 협상이 유효하지 않았다.

이 순서는 명령이 스스로 자신의 권한을 만들어내지 못하게 막았다. 이 메커니즘은 양방향으로 작동할 수 있었지만, 보통의 사용은 비대칭적이었다. 원격 애플리케이션은 문자 그대로의 입력이 필요한지 알고 있었고, 로컬 클라이언트는 터미널로 가는 출력을 다루고 있었다.

합의가 알려진 출발점을 만들어 냈다

합의 후에는DO를 보낸 쪽이OFF나ON을 보낼 수 있었다. 이는 TCP 수신 윈도우를 줄이거나 원격 계산을 멈추지 않았다. 사용자 Telnet 프로세스에게 화면으로 가는 출력을 로컬 드라이버가 처리하는 방식을 바꾸라고 요청하는 것이었다.

RFC 1080은 즉시WILL을 보낸 쪽에서 흐름 제어가 활성화되도록 요구했다. 이 세부 사항은 추측된 초기 상태를 피해 준다. 패킷 캡처는 옵션이 없는 상태, 옵션이 방금 활성 모드를 확립한 시점, 그 이후의 상반된 요청 여부를 구분할 수 있다.

반면ON과OFF에는 드라이버가 이를 적용했다는 확인 응답이 없었다. 패킷은 권한 있는 요청을 증명할 뿐, 로컬 레지스터의 상태, 입력 소비 여부나 화면의 가시적 정지를 증명하지 않았다.

알 수 없는 하위 협상 코드는 무시해야 했다. 이 규칙은 프로토콜 확장을 보존했지만, 수신자의 침묵이 능력의 증거가 될 수는 없었다.

옵션을 철회한다는 것은 클라이언트에 권한을 돌려주는 일이었다

어느 시점이든 한쪽 끝은DONT나WONT를 보낼 수 있었다. 그 이후의 하위 협상은 새 합의가 있을 때까지 금지되었다.

RFC는 마지막 모드가 유지될 것을 요구하지 않았다. 옵션이 비활성화되면 흐름 제어는 구현이 정의한 기본값으로 돌아갈 수 있었다. 따라서 로그에 '마지막 명령: OFF'만 남기면 철회, 재연결 또는 재시작 이후에는 거짓 상태가 된다.

이 로컬 복귀는 정치적으로도 흥미롭다. 위임은 동의의 세션과 함께 끝났으며, 원격의 선호를 단말의 영구 규칙으로 바꾸지 않았다. 표준화는 권한의 시작과 끝을 고정하면서도 로컬의 선택을 폐지하지 않았다.

네트워크는 화면과 함께 멈추지 않았다

'흐름 제어'라는 용어는 혼란을 부른다. 옵션 33은 사용자 Telnet 프로세스에서 자신의 터미널로 나가는 데이터, 즉 한 구간만을 다뤘다. TCP 수신 윈도우도, 재전송도, 혼잡도 설명하지 않았다.

터미널은 전용 신호선을 사용하는 하드웨어 흐름 제어를 갖출 수 있었으며, 그 경우 Control-S나 Control-Q를 빼앗지 않는다. 터미널에서 클라이언트 방향은 다른 정책을 따를 수 있었다. 원격 애플리케이션은 이미 버퍼에 넣은 데이터를 계속 생산할 수 있었다.

제대로 된 관찰은 방향과 측정 지점을 명시해야 한다. 키보드에서 XOFF를 본다고 해서 그 바이트가 Telnet을 통과한 것은 아니고, 네트워크에서OFF를 본다고 해서 드라이버가 문자를 놓아주었다는 것은 아니다.

Linemode는 나머지 기능을 나누었다

RFC 1184는 이후 줄 단위 로컬 처리를 규정했다. 클라이언트는 사용자 가까이에서 문자를 편집하고 에코한 뒤 완성된 줄을 서버로 보낼 수 있었다. 이 선택은 트래픽을 줄이고 높은 지연 경로에서의 사용성을 개선했다.

그 모드 마스크는 편집과 신호를 다루었다. 흐름 제어는 비슷해 보일 수 있었지만, 규격 본문은 명시적으로 별도의TOGGLE-FLOW-CONTROL옵션을 가리켰다. 새 옵션이 다른 옵션의 상태 머신을 조용히 재정의해서는 안 되는 것이다.

이 분리는 조사에도 도움을 준다. 키보드가 만들고, 드라이버가 소비할 수 있고, 클라이언트가 변환할 수 있고, 서버가 가끔 받는다. 어느 한 캡처 지점만으로는 이 전체 연쇄를 소유하지 못한다.

RFC 1372는 확인 응답의 부재를 드러냈다

1992년RFC 1372는 RFC 1080을 대체했다.ON과OFF를 유지하면서RESTART-XON과RESTART-ANY를 추가했다. 전자는 XON만이 출력을 재개하도록 요구했고, 후자는 새 XOFF를 제외한 모든 문자를 허용했다.

활성 상태는DO/WILL이후에도 알려져 있었지만, 재개 규칙은 시스템에 따른 상태에서 시작되었다. 따라서 서버는 원하는 규칙을 직접 요청해야 했다.

그러나 프로토콜은 결과를 보증할 수 없었다. 두 모드를 모두 지원할 수 없는 클라이언트는 요청을 무시할 수 있었다. 이를 서버에 알릴 수 있는 메시지도 없었다. "가능한 한 노력해야 한다"는 구현 의무를 표현했을 뿐, 텔레메트리가 아니었다.

일반적인 드라이버에서는 XON과 XOFF가 흡수되었다. 모든 문자에서 재개하는 경우, 출력을 재개시킨 그 입력은 이후에 전송될 수 있었다. XON인 경우만 예외였다. 따라서 재개조차 데이터에 대한 효과가 하나뿐이 아니었다.

직렬 포트는 또 다른 표면이었다

RFC 2217은 나중에 직렬 포트용 Telnet 명령을 정의했다. 입출력 흐름 제어 구성과,RESUME까지 데이터와 명령을 모두 멈추는 세션 정지FLOWCONTROL-SUSPEND를 구분했다.

이 메커니즘들은 옵션 33을 소급적으로 설명하지 않는다. UART를 설정하는 것, 세션을 정지하는 것, 로컬 드라이버가 XOFF를 소비하는지 판단하는 것은 서로 다른 세 가지 사실이다.

IANA Telnet 옵션 레지스트리는 코드 33, Remote Flow Control을 RFC 1372 참조와 함께 보관하고 있다. 이는 오래 지속된 조정을 증명할 뿐, 현재의 채택이나 클라이언트의 정상 작동을 증명하지 않는다.

하나의 모드 겉모습에 대한 다섯 가지 증거

다음은 따로 보존해야 한다:

  1. 세션 기간에 대한DO/WILL동의;
  2. ON,OFF또는 재개 요청;
  3. 클라이언트와 드라이버에서 실제로 적용된 상태;
  4. 특정 입력의 운명, 소비되었는지 전송되었는지;
  5. 화면과 애플리케이션에서 관찰된 효과.

RFC 1080은 이 중 처음 두 가지와 초기 상태를 제공했다. 나머지는 로컬 또는 종단 간 관찰이 필요했다.

그 유산은 오래된 터미널에 대한 원격 지배가 아니다. 이는 좁고 철회 가능하며 세션에 묶인 위임으로, 두 바이트를 사용할 수 있게 하면서도 그 의미가 어디서 결정되는지를 감추지 않았다.

출처와 한계

RFC 854는 NVT 프레임을, RFC 855는 동의 문법을, RFC 1080은 최초의 옵션을, RFC 1184는 Linemode의 인접 영역을, RFC 1372는 재개 모드를, RFC 2217은 직렬 및 세션 표면을, IANA는 등록 기록을 제공한다. 이 출처들은 현재의 배포, 인증, 확인된 드라이버 상태, 명명된 사건, 측정된 사용자 결과를 증명하지 않는다.