요약

  • RFC 1041은 하나의3270-REGIME텔넷 옵션을 제안했으나, RFC 1576은 이를 구현한 개발자가 매우 적었다고 기록했다. 실제 운영 시스템은 대신 Terminal-Type, Binary, EOR을 결합한 전통적 TN3270을 사용했다.
  • 세 옵션 관례는 사용 가능한 표시 체계와 메시지 경계를 확립했다. 그러나 요청된 장치/LU 이름, 게이트웨이 뒤의 SNA BIND, 상관된 처리 응답, ATTN과 SYSREQ의 보편적 의미를 드러내지는 못했다.
  • TN3270E는 나중에 장치 할당, BIND 상태, 긍정/부정 응답을 별도로 협상 가능하게 만들었다. 그러나 더 풍부한 기록도 사용자를 인증하거나, 모든 기능을 보장하거나, 사람 또는 비즈니스 결과를 증명하지는 못했다.

그 일을 위해 설계된 옵션은 패배했다

1988년 1월,RFC 1041은 어려운 전환에 대한 깔끔한 해법을 제안했다. 텔넷은 평소 네트워크 가상 단말(NVT)을 표시했다. IBM 3270 디스플레이는 다른 세계를 사용했다. NVT ASCII가 아닌 EBCDIC, 일반 문자 스트림이 아닌 블록 지향 명령, 그리고 그 차원과 기능이 호스트가 보낼 수 있는 내용에 영향을 주는 다양한 단말 모델이었다.

새 텔넷 옵션 29인3270-REGIME은 클라이언트가 정렬된 체계(regime) 목록을 제시하고 서버가 양쪽이 지원하는 하나를 선택하게 해 줬다. 합의는 이진 데이터와IAC EOR레코드 경계를 함의했다. 같은 옵션은 NVT ASCII로 되돌아가는 방법과 단말 유형을 재협상하는 방법도 기술했다.

RFC 1041은 전환의 순간에 이례적으로 세심한 주의를 기울였다. 협상에 들어가는 클라이언트는 사용자 데이터 수신을 중단해야 했다. 서버는 체계가 미정인 동안 데이터 전송을 피해야 했다. 서버는 미처리 바이트가 모두 전송된 후에만 새 체계를 알릴 수 있었고, 각 측은 지정된 송신 또는 수신 이벤트에서 해석 방식을 바꿨다. 전환에는 양방향 데이터 플러시가 필요할 수 있었다. 이 문서는 한순간이라도 이르게 붙은 라벨이 유효한 바이트를 잘못된 문법으로 해석하게 만들 수 있음을 이해하고 있었다.

설계는 일관성이 있었다. 그러나 설치된 중심이 되지는 못했다. 1994년 1월로 기록되고 Informational로 분류되는RFC 1576은,RFC Editor 기록에 따르면 RFC 1041을 구현한 개발자와 벤더가 매우 적었다고 말한다.

이 진술에는 경계가 있다. “매우 적다”는 “없다”가 아니며, Informational 문서는 조사 결과가 아니다. 그럼에도 RFC 1576이 이전 표준을 운영 사실로 취급하는 대신 다른 실무를 문서화한 이유를 설명하기에 충분하다.

기존의 세 스위치가 하나의 체계가 되었다

전통적 TN3270은 세 개의 텔넷 옵션을 재사용했다.

  • Terminal-Type은 특정 모델과 화면 크기 같은 3270 에뮬레이션을 식별했다.
  • Binary는 3270 스트림에 필요한 8비트 데이터 경로를 허용했다.
  • End of Record는 각 블록의 끝을IAC EOR로 드러나게 했다.

기본텔넷 사양,Binary Transmission 옵션,End of Record 옵션이 구성 요소를 제공했다. 그중 어느 하나만으로 “TN3270”을 의미하지는 않았다. 운영 구현들이 이들을 조합했다.

RFC 1091은 Terminal-Type을 의도적으로 비대칭으로 만들었다. 서버가 물으면 클라이언트가 답하며 대안들을 순환할 수 있었다. 새 유형을 보내는 것은 클라이언트가 에뮬레이터를 바꾸는 것을 요구할 수 있었지만, 이름을 받는 것이 곧 서버의 즉각적인 처리 변경을 강제하지는 않았다. Binary와 EOR 역시 각자의 텔넷 협상 상태와 방향을 가졌다.

RFC 1576은 세 협상의 순서를 중요하지 않다고 취급했다. 적절한 단말 유형, 이진 전송, EOR이 갖춰지면 양쪽은 EOR로 종료되는 완전한 3270 명령을 교환했다. 서버가 나중에 Binary나 EOR 중 하나를 철회하면 연결은 더 이상 TN3270 체계를 만족하지 않았고, 클라이언트는 이후 서버 데이터를 NVT ASCII로 해석했다.

이것이 작동한 이유는 공통 계약이 좁게 유지되었기 때문이다. EOR은 결과가 아니라 경계를 제공했다. Binary는 의미가 아니라 옥텟을 보존했다. Terminal-Type은 물리적 장비가 아니라 표현 방식을 선택했다. 텔넷 쪽 클라이언트와 호스트 애플리케이션에 이르는 SNA 또는 비SNA 경로 사이의 변환은 여전히 게이트웨이가 담당했다.

화면 뒤에는 두 세션이 있었다

SNA 환경에서 3270 단말은 평소 호스트 애플리케이션과의 세션 하나, 그리고 시스템 서비스 제어점(SSCP)과의 세션 하나를 가졌다. 두 번째 경로는 제어와 서비스 상호작용을 전달했다. TN3270은 클라이언트에게 텔넷 연결 하나만 보여 줬다. SNA의 분할을 드러내지 않았고, 에뮬레이터가 서버 자체의 접속 방식을 알아내게 하지도 않았다.

누락된 식별 정보는 구체적이었다. SNA 세션은 논리 장치(LU) 이름을 사용했다. 전통적 TN3270은 클라이언트가 자신의 연결을 특정 3270 장치 이름과 연결해 달라고 표준적으로 요청할 방법도, SNA 연결 서버 뒤에서 할당된 LU를 알아내는 정의된 방법도 제공하지 않았다. RFC 1576은 TN3270 환경에서 클라이언트의 IP 주소가 LU 이름에 가장 가까운 것이라고 말한다. “가장 가까운” 것은 동등한 것이 아니다. 주소는 하나의 네트워크 엔드포인트를 위치시킬 뿐, 애플리케이션이 세션을 구분하는 데 쓰는 호스트 측 논리 장치의 이름이 아니다.

이 공백이 중요했던 이유는 호스트 애플리케이션이 단말의 네트워크 이름에 따라 다르게 동작할 수 있었기 때문이다. 3278 모델 같은 단말 유형 문자열은 에뮬레이터가 제공하는 표현을 답했다. 서버가 어떤 논리 장치를 할당했는지는 답하지 않았다.

-E접미사는 또 하나의 경계가 명확한 단서를 만들었다. 이는 클라이언트가 구조화 필드를 처리할 수 있음을 나타냈고, 종종 확장 속성 지원으로 읽혔다. 그러나 RFC 1576은 구현들이 이를 모두 동일하게 해석하지는 않았다고 지적한다. 익숙한 단말 이름은 결국 피어 간의 관례일 뿐, 완전한 기능 목록이 아니었다.

레코드의 끝은 처리 영수증이 아니었다

EOR은 프레이밍을 해결했다. 전통적 TN3270에서 3270 명령과 그 데이터는 외부 길이를 갖지 않았으므로,IAC EOR는 수신자에게 하나의 완전한 블록이 끝나는 지점을 알려 줬다. 이는 소중한 증거다. 블록을 분리하고 수신자가 한 메시지의 해석을 시작하게 해 준다.

그러나 경계 이후에 무슨 일이 일어났는지는 말해 주지 않는다. RFC 1576은 전통적 TN3270이 지원하지 않은 것들 중 SNA의 긍정/부정 응답 과정을 명시적으로 꼽는다. 연결을 통해 전송된 데이터는 처리되었거나 무시되었다고 가정되었다. SNA 긍정 응답은 이전 데이터가 처리되었음을 보고할 수 있었다. 부정 응답은 잘못된 명령이나 클라이언트 측 기계적 실패를 드러낼 수 있었다. 전통적 TN3270은 그 결과를 되돌려 보내지 않았다.

이것이 설계에서 가장 예리한 증거 경계다. TCP 전달과 EOR은 구획된 블록이 피어의 텔넷 경로에 도달했음을 확립할 수 있다. 그러나 에뮬레이터가 명령을 수용했는지, 올바른 화면을 그렸는지, 프린터가 동작했는지, 호스트 애플리케이션이 회신을 보았는지, 사람이 화면을 이해했는지는 확립하지 않는다.

존재 확인은 더 좁았다. 일부 서버는 클라이언트 프로세스가 여전히 도달 가능한지 알아보려 텔넷 NOP을 보내거나 Timing Mark를 사용했다. NOP은 응답을 요구하지 않았다. 비정상 종료된 클라이언트는 결국 TCP 송신 오류로 드러날 수 있었다. 살아 있는 연결은 애플리케이션 영수증이 아니며, 결코 사람의 존재도 아니다.

특수 키는 어댑터를 드러냈다

ATTN과 SYSREQ는 키처럼 보였지만 여러 권한 경계를 넘었다. 많은 SNA 호스트 애플리케이션은 ATTN을 현재 처리를 중단해 달라는 요청으로 해석했다. 많은 TN3270 서버는 이를 텔넷 BREAK에서 매핑하고 그 명령을 호스트 쪽으로 번역했다. 비SNA 서버는 BREAK를 단순히 무시할 수 있었다.

SYSREQ는 더 균일하지 않았다. 일부 서버는 텔넷 Interrupt Process를 SYSREQ로 해석했고, 다른 서버는 3270 Test Request를 사용했다. SNA에서 이 키는 단말을 애플리케이션 세션과 SSCP 세션 사이에서 이동시킬 수 있었다. 클라이언트 쪽 텔넷 스트림에는 모든 SSCP 데이터를 위한 직접적인 형식이 없었으므로, 서버가 그 상호작용을 처리하거나 변환하거나 무시해야 했다.

따라서 사용자의 키 입력, 클라이언트의 텔넷 명령, 서버의 매핑, SNA 제어 이벤트, 애플리케이션의 중단, 그 뒤에 나타난 화면은 서로 별개의 사실이었다. “SYSREQ 전송됨”만 기록하면 첫 번째 층에 나머지 전부에 대한 권한을 주게 된다.

TN3270E는 사실들을 하나씩 되돌려 왔다

RFC 1646과RFC 1647은 전통적 TN3270이 생략한 상태를 위한 확장을 빠르게 기술했다. 이후 Standards Track 문서RFC 2355공식 기록으로 식별된다 — 은 1998년에 TN3270E를 통합했다.

TN3270E는 Terminal-Type을 보편적 진실로 재정의하지 않았다. 두 가지 명시적 협상을 지닌 새 옵션을 만들었다. 먼저 클라이언트와 서버가 장치 유형과, 선택적으로 요청된 자원 또는 장치 이름에 합의했다. 서버는 할당된 장치 이름을 수용해 돌려 줄 수도, 이름 미상, 장치 사용 중, 유형/이름 불일치 같은 사유로 요청을 거절할 수도 있었다. 그 후에야 피어들은 기능 집합을 협상했다.

그 기능들은 분리 가능했다.BIND-IMAGE는 SNA 연결 서버가 호스트 애플리케이션 세션의 시작과 종료를 보고하고 수용된 BIND 이미지를 전달하게 했다.RESPONSES는 메시지 헤더, 응답 요청 플래그, 시퀀스 번호를 추가해 긍정 또는 부정 처리 결과를 그것을 야기한 블록과 연결할 수 있게 했다.SYSREQ와 프린터 제어는 각자의 항목을 가졌다. 합의된 목록은 비어 있을 수도 있었다 — 기본 TN3270E.

침묵에도 문법이 있었다.RESPONSES하에서 메시지는 응답을 요청하지 않거나, 오류 시에만 응답하거나, 모든 경우에 응답을 요구할 수 있었다.NO-RESPONSE이후 답이 없는 것은 성공 영수증이 아니었다. 그것은 기대된 부재였다.RESPONSES기능이 없으면 시퀀스 필드는 무시되었다.BIND-IMAGE가 없으면 TN3270E 자체가 협상되었다는 이유만으로 클라이언트가 bind 기록을 얻지는 못했다.

폴백도 여전히 의도적이었다. 어느 한쪽이 TN3270E를 거절하면 전통적 TN3270을 계속 사용할 수 있었다. 더 풍부한 옵션이 설치된 호환성을 지우지 않았다. 어떤 강화된 기록이 실제로 존재하는지 알아내는 방법을 제공했다.

운영 코드는 증거였지, 주권은 아니었다

역사적 유혹은 승자를 고르는 것이다. RFC 1041은 형식적으로 정연했지만 구현이 드물었다. 전통적 TN3270은 문서화할 만큼 충분히 널리 정착되어 있었다. TN3270E는 나중에 빠진 구조를 회복했다.

이 순서는 더 유용한 결론을 지지한다. 사양은 공표만으로 세계를 재구성하지 않는다. 운영 코드는 참여자들이 실제로 유지할 의사가 있었던 더 얇은 합의를 드러낼 수 있다. 그러나 설치된 실무가 자신이 결코 표현하지 않은 사실들에 대한 권위를 얻지는 못한다.

Lu Heng의운영 코드 우선론은 편집적 렌즈를 제공한다. 문서가 현실을 대변하게 두는 대신, 실제로 동작하는 시스템을 관찰하라는 것이다.최소 공통 사양과 지역화된 미래 결정에 관한 그의 글은 세 옵션의 타협이 가치 있을 수 있는 이유를 설명한다. 게이트웨이와 엔드포인트가 지역 제어를 유지하면서 작은 공통 어휘를 재사용했기 때문이다.현실 층위 원칙은 다음 실수 — 표현, 연결, 처리 결과를 “단말”이라는 하나의 상징으로 묶는 실수 — 을 막는다. 이들은 사후적 편집 적용이지, RFC 저자들의 의도에 대한 주장이 아니다.

RFC 1576의 오래된 교훈은 세 옵션이 하나보다 낫다는 것이 아니다. 모든 주장은 자신의 기록이 끝나는 지점에서 멈춰야 한다는 것이다. Terminal-Type은 에뮬레이션을 이름 지을 수 있었다. Binary는 바이트를 보존할 수 있었다. EOR은 블록을 닫을 수 있었다. 장치 이름, SNA bind, 처리 결과, 인터럽트, 사람에 미친 결과는 각각 또 하나의 영수증을 필요로 했다.

출처