요약

  • RFC 1921은 Bull VIP 터미널 세션을 화면, 프린터, 화면 복사 흐름으로 나누었으며, 각 흐름은 자체 주소를 가지고 동시에 최대 하나의 미완료 요청만 허용했습니다.
  • 같은 주소에 대한 두 번째 요청은 삭제되었지만, 그PROTOCOL-VIOLATION응답은 첫 번째 요청에 대한 응답 뒤에 이어져야 했습니다. 트랜잭션 식별자 대신 순서가 그 역할을 대신했습니다.
  • Telnet 협상과EOR는 공통 문법을 확립했습니다.ACK,BUSY,PURGED,READY는 여전히 한정된 흐름 상태만을 기술했으며, 사용자 권한, 호스트 결과, 인쇄된 페이지를 의미하지 않았습니다.

오류는 먼저 말할 수 없었다

두 개의 프린터 봉투가 같은 슬롯으로 들어오는 상황을 상상해 보십시오. 첫 번째는 처리 중입니다. 두 번째는 너무 이르게 도착합니다. 처리량만을 걱정하는 시스템은 이를 버퍼에 넣을 수 있습니다. 징계만을 걱정하는 시스템은 즉시 거부할 수 있습니다. TNVIP는 더 정확한 순서를 선택했습니다. 두 번째 봉투를 버리고, 첫 번째 교환을 끝낸 뒤, 그제서야 두 번째가 프로토콜을 위반했다고 보고하는 것입니다.

1996년 3월에 Informational 문서로 발표된RFC 1921의 이 순서는 예의가 아니었습니다. 이는 다음 응답의 의미를 보호한 것입니다. TNVIP 요청은 일반적인 트랜잭션 번호를 담지 않았습니다. 송신자가 어떤 응답이 어느 작업에 답하는지 알 수 있었던 이유는 각 장치 주소가 한 번에 하나의 현재 요청만 가질 수 있었기 때문입니다. 두 번째 요청에 대한 오류가 첫 번째 요청의 결과보다 앞서가면, 수신자는 거부에 대한 정직함은 유지하면서 어느 쪽 답변도 유용하게 만들어 주는 연관성을 파괴하게 됩니다.

따라서 이 프로토콜은 기묘한 약속을 했습니다. 잘못된 입력은 보고되지만, 이미 전송 중인 증거를 훼손하는 대가로는 보고되지 않는다는 것입니다.

하나의 Telnet 연결에 세 개의 장부가 있었다

TNVIP는 Bull Visual Information Projection 터미널을 위한 Telnet 프로필이었습니다. 이 터미널들은 일반적인 NVT(Network Virtual Terminal) 모델과 달랐습니다. 블록 단위로 작동했으며 화면과 연결된 프린터를 결합할 수 있었습니다. 터미널 관리자는 논리적 스테이션과 논리적 장치를 통해 물리적 장치를 호스트 애플리케이션에 제공할 수 있었고, 하나의 프린터가 여러 논리적 스테이션에서 공유될 수도 있었습니다.

RFC 1921은 그 구성을 서로 교환 가능한 메시지의 단일 스트림으로 평탄화하지 않았습니다. 2바이트 TNVIP 헤더는 주소로 시작했습니다.0x60은 화면 흐름,0x68은 프린터 흐름,0x69는 화면 복사 인쇄 흐름을 지정했습니다. 다음 바이트는 명령을 지정했으며, 그 두 개의 하위 비트는 메시지가 indication, request, response, response-and-request 중 어느 것인지를 나타냈습니다.

하나의 미완료 요청만 허용한다는 규칙은 주어진 주소에 범위가 한정되어 있었습니다. 대기 중인 화면 요청은 화면 장부를 점유하고, 프린터 요청은 프린터 장부에 속했습니다. 올바른 추적은 연결 순서만으로는 부족했습니다. 주소, 그 주소의 현재 요청, 메시지 유형이 필요했습니다. 같은 바이트 스트림이 여러 개의 로컬 대화를 나르면서도, 그것을 하나의 전역 큐처럼 가장하지 않았습니다.

이는 여러 작업의 인터리빙을 허용하고 Message ID로 응답과 작업을 다시 결합한 LDAP 같은 프로토콜과 정반대입니다. TNVIP는 더 적은 식별자 공간을 사용하고 더 엄격한 스케줄링 규칙을 감수했습니다. 동시성이 한정되어 있었기 때문에 공통 상태도 작았습니다.

협상은 문법을 만들었을 뿐 권한을 만들지 않았다

TNVIP 메시지가 의미를 가지려면, 피어들이 터미널 유형과 Telnet의 End-of-Record 옵션을 먼저 협상해야 했습니다. 터미널 문자열은 지원되는 모델을 지명했고@Mailbox-name을 덧붙일 수 있었습니다. DSA 게이트웨이에서 이 선택적 Mailbox는 특정 접속 지점을 선택했으며, 없으면 서버가 일반 접속을 사용할 수 있었습니다. 이 필드는 길이가 제한되고 대소문자가 정규화되었습니다. 서버의 터미널 세계 안에서의 라우팅 지시이지, 인증이 아니었습니다.

Binary Transmission은 에뮬레이션이 8비트 값을 필요로 할 때 선택적이었습니다. Suppress-Go-Ahead는 클라이언트가 DSA 턴이나 ISO 세션 토큰과 전송을 동기화하기 위해 TelnetGA가 필요하지 않을 때 선택적이었습니다. 이 선택들은 바이트와 턴이 이동하는 방식을 바꿨습니다. 그러나 어떤 사람이 터미널 앞에 앉아 있는지, 그 사람이 Mailbox를 사용할 자격이 있는지 증명하지 않았습니다. RFC 1921의 보안 고려 사항은 보안이 다루어지지 않았다고 명시하고, 바로 그 문제를 위해 이후의 인증을 예상했습니다.

EOR는 또 하나의 좁은 사실을 제공했습니다. VIP 통신은 블록 지향적이었으므로,IAC EOR가 모든 TNVIP 메시지를 닫았습니다. 수신자는 완전한 레코드의 위치를 찾을 수 있었습니다. 그러나 그 레코드에 무슨 일이 일어났는지 말하기 위해서는 여전히 TNVIP 응답 어휘가 필요했습니다. 프레이밍은 곧 처리가 아니었습니다.

RFC는 TNVIP 메시지 내부에 Telnet 명령을 넣는 것을 권하지 않으며 이 경계를 다시 드러냈습니다. 이스케이프된IAC IAC를 제외하면, 포함된 명령은 처리되어야 했지만 구현은 이를 즉시 처리하거나 현재 메시지가 끝난 뒤로 미룰 수 있었습니다. 따라서 동일한 옥텟 순서가 서로 다른 제어/데이터 순서를 만들 수 있었습니다. 명령을 레코드 사이에 두는 것은EOR만으로는 해결할 수 없는 모호성을 제거했습니다.

네 가지 메시지 유형이 보편적 접수증을 대체했다

Indication은 응답을 기대하지 않았습니다. Request는 자신의 주소에 하나의 응답 슬롯을 열었습니다. Response는 그 슬롯을 닫고 피어가 또 다른 요청을 보내도록 허용했습니다. 네 번째 유형인 response-and-request는 두 전이를 동시에 수행했습니다. 현재 요청에 긍정적으로 답하고, 반대 방향에 새 요청을 만드는 것입니다.

이 문법이 중요한 이유는 익숙한 단어들이 보편적 의미를 갖지 않았기 때문입니다. 화면의ACK는 화면 데이터가 처리되었음을 말할 수도 있고, LOCAL 상태 요청이 접수되었음을 말할 수도 있었습니다. 화면의BUSY는 터미널이 로컬이었기 때문에 데이터가 삭제되었음을 말했습니다. 프린터의BUSY는 앞선 인쇄 작업이 아직 끝나지 않은 상태에서 새 프린터 요청이 삭제되었음을 말했습니다.READY는 프린터 상태 질의에 대한 응답이었으며, 프린터 데이터에 대한 확인 응답이 아니었습니다.

다른 응답들은 다른 실패들을 따로 유지했습니다. 처리 실패에는ERROR, 조작자 또는 리셋에 의한 중단에는ABORTED, purge indication으로 중단된 요청에는PURGED, 지원되지 않는 장치에는NOT-AVAILABLE, 알 수 없는 작업에는UNKNOWN-COMMAND, 잘못된 순서에는PROTOCOL-VIOLATION이 사용되었습니다. 알 수 없는 indication은 단순히 삭제하고 무시할 수 있었지만, 알 수 없는 request는 한정된 답변을 요구했습니다.

ACK나BUSY만 남기는 로그는 프로토콜 자체의 구분을 파괴합니다. 주소와 대기 중인 요청은 사실의 일부입니다.

삭제는 대기열이 아니었다

두 번째 요청 규칙은 재해석 과정에서 완화되기 쉽습니다. 장치가 바쁜 동안 요청이 “보류되었다”고 말하고 싶어지는 것입니다. RFC 1921은 삭제되었다고 말했습니다. 프린터 흐름에서 송신자는 기다려야 했습니다. 클라이언트가 자신의 프린터 버퍼로 데이터를 전송 중이며, 앞선 인쇄가 끝나지 않은 동안 또 다른 프린터 데이터 요청을 받아들일 수 없기 때문입니다. 성급한 요청은 숨겨진 대기열에서 자리를 얻지 못했습니다.

이는 운영적 해석을 바꿉니다. 이후의BUSY나PROTOCOL-VIOLATION은 데이터가 송신자의 새로운 결정을 필요로 한다는 증거였습니다. 자동 재시도에 대한 약속이 아니었습니다. 반대로 두 번째 요청 뒤에 즉각적인 오류가 없다고 해서 수락을 의미하지도 않았습니다. 수신자는 폐기된 두 번째 요청에 대해 말하기 전에 첫 번째 요청의 응답 순서를 유지해야 했습니다.

이렇게 TNVIP는 모니터링이 흔히 압축해 버리는 세 개의 순간을 분리했습니다. 옥텟이 연결에 도달하는 것, 메시지가 현재 장치 흐름에 인가되는 것, 장치별 작업이 처리되는 것. Telnet 엔드포인트로의 전달은 요청 슬롯으로의 인가를 의미하지 않았습니다.

LOCAL 상태는 성공적 전달을 의도적 손실로 끝나게 했다

VIP 클라이언트는 로컬 테스트나 구성을 위해 ONLINE 모드를 벗어날 수 있었습니다. 전환 전에LOCAL-STATE요청을 보냈습니다. 서버는 이를 확인 응답하고, 클라이언트가ONLINE-STATEindication을 보낼 때까지 화면과 프린터 데이터를 중단해야 했습니다.

그런데도 서버에서 시작된 화면 또는 프린터 데이터가 터미널이 로컬인 동안 도착하면, 클라이언트는 그것을 삭제했습니다. request에 대해서는BUSY를 반환할 수 있었습니다. 연결은 살아 있었고, 블록은 올바르게 프레이밍되었으며, 주소와 명령은 인식될 수 있었습니다. 그러나 규정된 결과는 여전히 삭제였습니다.

이 상태는 연결 전체를 얼리지 않았습니다. 클라이언트가 시작한 화면 메시지와 다른 주소의 메시지는 여전히 허용되었습니다. 그래서 “터미널이 바빴다”는 표현은 너무 거칠습니다. 그 제한에는 방향, 장치 범위, 상태 전이가 있었습니다. 하나의 흐름이 들어오는 표시 작업을 거부하는 동안 다른 형태의 통신은 여전히 정당했습니다.

화면 복사에는 권한과 이후의 결과가 필요했다

화면 복사 주소는 response-and-request가 존재한 이유를 보여 줍니다. 프린터가 서버의 제어 아래에 있을 수도 있었기 때문에, 사용자는 조율 없이 로컬 화면 복사를 시작할 수 없었습니다. 클라이언트는COPY-REQ를 보냈습니다. 서버가 로컬 복사를 허용하면LOCAL-COPY를 반환했습니다.

그 메시지는 권한 요청을 닫고 결과 요청을 열었습니다. 시작에 대한 승인은 완료가 아니었습니다. 클라이언트는 이후의 결과에 따라ACK,ERROR,BUSY,ABORTED,PURGED,NOT-AVAILABLE로 답해야 했습니다.

이 분리는 이례적으로 깨끗합니다. 서버는 공유 장치의 사용을 승인할 수 있고, 클라이언트는 물리적 동작을 시도할 수 있으며, 이후의 상태가 그 시도를 기술할 수 있습니다. 그러나 그 어떤 기록만으로는 종이에 무엇이 나타났는지, 누가 그것을 받았는지 증명되지 않습니다. RFC 1318의 기존 역사는 하한 경계를 똑같이 분명하게 만듭니다. 물리적 프린터 신호는 문서 결과가 아닙니다. TNVIP는 애플리케이션 교환을 더했을 뿐, 페이지 옆에 서 있는 목격자를 더하지 않았습니다.

purge 권한은 확인 응답에서 만료되었다

화면, 프린터, 화면 복사 흐름은 각각 purge indication을 정의했습니다. 그 효력은 시점이 지배했습니다. 요청이 아직 확인 응답을 받지 못했다면, 수신자는 처리를 중단하려 시도하고PURGED를 반환했습니다. 이미 응답했다면, purge 메시지는 무시되고 삭제되었습니다.

이 규칙은 늦은 취소가 확정된 프로토콜 역사를 다시 쓰는 것을 막았습니다. 또한 물리적 복구를 약속하는 것도 거부했습니다.PURGED는 아직 중단될 수 있는 요청 처리 경로를 기술했습니다. 장치 효과가 이미 그 경로를 벗어났다면, RFC는 보편적인 되돌리기를 제공하지 않았습니다.

바로 여기서Running-Code Primacy는 저자들의 의도에 대한 증거가 아니라 이후의 분석적 규율로서 유용합니다. 공표된 명령 문법은 장치 효과가 아닙니다. 응답은 자신이 구현된 상태 기계 안에서만 실재하며, 구현이 되돌릴 수 없는 계층에 대한 권위를 얻지 못합니다.

출처는 설계를 증명하지 배치를 증명하지 않는다

RFC 1921은 TNVIP 사실을 제공합니다.RFC 854는 Telnet의 기본 명령/협상 모델을 제공하고,RFC 885,RFC 856,RFC 858,RFC 1091은 EOR, 바이너리, go-ahead, 터미널 유형 맥락을 제공합니다.RFC 1576은 서로 다른 터미널 프로필을 문서화하며 이전의 TN3270 문서와의 경계를 표시합니다.

이 문서들은 규정된 동작을 확립합니다. 그러나 설치 수를 세거나, Bull 제품을 검증하거나, 사용자를 인증하거나, 화면을 보여 주거나, 페이지를 인쇄하거나, 호스트 애플리케이션의 성공을 증명하지 않습니다.Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption은 현대적 독해를 정교하게 만듭니다. 공통 상태를 결정적으로 유지한 다음, 장치 정책과 운영 증명은 그것을 관찰할 수 있는 참여자에게 남겨 두라는 것입니다.

RFC 1921의 가장 오래 남을 성취는 거창한 터미널 아키텍처가 아니었습니다. 하나의 응답이 두 개의 요청에 답하도록 두지 않는 규율 있는 거부였습니다. 세 개의 작은 장부, 명시적 손실, 순서화된 오류가 증거를 더 좁게 만들었고, 그래서 사용 가능하게 만들었습니다.